S 4.383 Secure installation of OpenLDAP
Initiation responsibility: IT Security Officer, Head of IT
Implementation responsibility: Administrator
There are various aspects having a direct influence on security which need to be taken into account when installing OpenLDAP. This safeguard can merely provide information on aspects requiring particular attention. They are based on the installation of OpenLDAP from the source text. Since binary packages from operating system manufacturers or distributors might deviate from this, they generally dissolve the dependencies with other applications automatically. The documentation supplied with OpenLDAP, especially the man pages and the "help" issue of the script "configure" provide further information.
Securing the server
The server on which OpenLDAP is run should also be secured according to IT-Grundschutz. The directory service contents processed using OpenLDAP must be stored on a local storage medium whilst the server operating system is controlled, as several functions required for OpenLDAP are not available on a distributed file system such as NFS (Network File System). On the server, it must be possible to reach port 389. If "ldaps://" is used (see M 5.new23 Secure communication connections when using OpenLDAP), port 636 must also be opened. Other services should not be run on the server (see also S 4.97 One service per server).
Additional software products
During the installation of OpenLDAP, it must be checked if all other applications identified within the planning framework (see S 2.new06 Planning OpenLDAP) are installed in a compatible version. This applies especially to the BerkeleyDB. If the BerkeleyDB has already been installed, the version can be read from the entry DB_VERSION_STRING of the "db.h" file. The storage location of this file depends on the installation of the BerkeleyDB; common locations on a Unix or Linux system are /usr/include/db.h, /usr/local/include/db.h and /usr/local/BerkeleyDB/include/db.h. If an operating system distribution is used, the version can also be called in the package manager.
If additional applications are to be installed, the order of the installations can be of importance to ensure that any required header information can be found for an application in each case. A useful installation order is, for example, the following order:
1. OpenSSL or GnuTLS
2. BerkeleyDB
3. Heimdal Kerberos or MIT Kerberos
4. Cyrus-SASL
5. OpenLDAP
6. Heimdal Kerberos (if already used in step 3)
7. Cyrus-SASL
The double installation of Heimdal Kerberos (not MIT Kerberos) and Cyrus-SASL before and after OpenLDAP can be useful, since these programs can then, in turn, store user data in OpenLDAP.
Compilation and installation of OpenLDAP
The software version must be selected with due care prior to the installation and their integrity must be checked (see S 4.382 Selecting and checking the OpenLDAP installation packages).
A source text package should be unpacked using an unprivileged user account and configured using the script "configure". Unused backends and overlays must be excluded from the installation using configuration parameters, since they bear the risk of weaknesses and incorrect configurations like any installed software. In addition, it must be taken into account that the parameters have an impact on the configuration to be used during the installation or configure-script. For example, backends and overlays might be compiled permanently or dynamically loaded as modules. If dynamic loading is activated, OpenLDAP cannot simply be used with a configuration expecting permanently compiled backends and overlays.
After the package has been configured, dependencies with the applications prepared above must be inserted using the "make depend" program call, before OpenLDAP is compiled using the "make" program call. The compiled software should be checked because of the dependencies described using "make test". Only the last step, the actual installation of the compiled program using "make install" requires the user to have higher privileges. If the unprivileged user account has write authorisations for all target directories of the installation, then even this last step can be performed without "root" authorisations. Thus, the security during the installation is increased, as a defective or manipulated program, if any, is assigned only restricted rights in this way.
If OpenLDAP is compiled from the source text, then the parameters selected must be documented exactly. It is also recommended to create a log of the data output during the configuration and compilation procedures (for example by redirecting this output to a file) and place this log in safekeeping. All installation steps should be documented so that they can be reproduced quickly in emergencies In addition to settings when compiling, this also applies to installation paths, authorisations, changes to the configuration and similar information.
In general, the slapd server should be started from the startup scripts of the operating system. Thus, the slapd server is immediately available after a restart of the servers and it is ensured that no parameters, for instance, can be forgotten when starting the server.
Review questions:
- Are the necessary ports released for the slapd server when a local package filter is used?
- Is the installation of OpenLDAP documented in an understandable manner?
- Are only backends and overlays which are actually used complied for OpenLDAP?
- Is it checked if applications on which OpenLDAP depends are installed in a compatible version?