Howard Chu skrev, on 27-09-2007 20:09:

[...]

As usual, if you want to know "best practices", the best way to get that is just to ask us or read the docs we've already written...

s/you want/one wants/

Buchan is pretty hip at keeping up with best practices, about 90% judging on his latest Red Hat srpm.

What about the remaining 10%? This is left as an exercise to the reader.

--Tonni

Buchan Milne wrote:

On Thursday 27 September 2007 20:09:19 Howard Chu wrote:

...

...

Unfortunately, they show configuration for slurpd in their section on "Redundant LDAP Servers".

I wonder if it is worthwhile providing CIS with feedback?

Now that you've pointed it out, I went and downloaded it. I find the quality of the editing of this document to be pretty abysmal, but the factual content is at least fixable. I'll be sending some feedback to the editor shortly.

As usual, if you want to know "best practices", the best way to get that is just to ask us or read the docs we've already written...

Indeed, but unfortunately our esteemed security group bases their security standards on the CIS benchmarks (usually their changes reduce the technical quality at the expense of formatting etc.), so I suspect at some stage I'll be getting questions about an OpenLDAP standard (and I'll probably have to fix it up more than I have the Linux one ...).

Understood. As Tony pointed out, when I said "when you want to know" I of course meant "when one wants to know" because obviously you, Buchan, already know what you're doing.

For anyone curious, here's their document as plaintext with my commentary inserted.

Howard Chu wrote:

You really ought to run articles like this by us before publishing, to be sure you've got all the facts correct.

...

Center for Internet Security Benchmark for OpenLDAP v1.0

...

Introduction LDAP stands for Lightweight Directory Access Protocol defined in RFC 2251 and others and is based on X.500 directory services. LDAP servers are very popular including commercial servers such as Microsoft Active Directory, IBM Tivoli Directory Server, Novell eDirectory, and Sun Java System Directory Server. OpenLDAP is the most popular of the open source LDAP servers. LDAP servers are just one part of a typical network infrastructure, and their security depends in part on the security of the rest of the infrastructure. However this benchmark will focus primarily on the secure configuration of the OpenLDAP server.

Applicability The benchmark was developed and tested using OpenLDAP version 2.3 on Fedcora Core 6, however most of the content will apply to other versions of OpenLDAP. In fact, many of the recommendations and principals will apply to other LDAP servers as well.

It would be a good idea to be more specific with version number references. "OpenLDAP 2.3" is too vague and not everybody knows what's in Fedora Core 6. General recommendations may still be broadly relevant across a release stream, but if you need to point out specific security issues, you have to know which actual version you're dealing with.

Completely aside from the technical/factual content, the editing in this document is extremely lax. There are misspellings and grammatical errors all over the document. It doesn't inspire a lot of confidence in the validity of your content when it is presented in such an unpolished form.

...

1 Operating System Level Configuration The following specifies the recommended operating system level installation, configuration and permissions for OpenLDAP

1.1 OS Hardening Security of the LDAP service absolutely depends on having a secured operating system as a foundation. Show Rule XML Discussion: Harden the operating system using appropriate CIS benchmark from http://www.cisecurity.org/

1.2 Non-privileged LDAP Account The -u option is typically set by the rc startup script or a file read by the script. There must be no other usage of the user account except for running ldap servers such as slapd and slurpd. Discussion: Configure slapd to execute under a dedicated non-privileged user account, by ensuring that slapd is started with the -u option, such as "-u ldap".

1.3 Logging Partition In the event that attacks or even normal events causing excessive logs to fill up the file system, other critical system partitions which contain system executables and configuration files should remain unaffected. Discussion: Do not use the root file system partition for the slapd logging file. Instead use a separate file system dedicated to logging and other run time data storage such as the /var file system is typically used for logging, and should be on it's own partition.

There is no such thing as "the slapd logging file" - you really need to be explicit about what you're talking about here. Syslog output, debug output, slurpd replication logs, database transaction logs, what? In the case of DB transaction logs, the OpenLDAP docs already tell you to place them on separate spindles from the main data. Just putting them on separate partitions is insufficient (and will actually degrade performance). Either put them on separate physical disks, or leave them in the same partition as the main database.

...

1.4 The slapd.conf File Ownership Ownership by other users would allow the permissions to be change. Discussion: The slapd.conf configuration file must be owned by root.

1.5 The slapd.conf File Permissions Other users do not need read access. Discussion: The slapd.conf file needs to be read-only for the ldap group with no-access for other. That is: -rw-r----- 1 root ldap slapd.conf

This is pretty standard advice, and already in all of the OpenLDAP documentation and example files. You really should also talk about slapd.d, the slapd configuration directory, since the slapd.conf file is being phased out.

...

1.6 Client conf File Ownership Ensuring the system client ldap.conf file is owned by root helps prevent unauthorized changes of the file permissions. Discussion: The ldap client file, typically ldap.conf, must be owned by root.

1.7 Client conf File Permissions Prevent unauthorized changes to the files. Discussion:

The ldap client file and directory, ldap.conf, must not be writeable except by root. For example: drwxr-xr-x 4 root root /etc/openldap/ -rw-r--r-- 1 root root ldap.conf

1.8 LDAP Schema Files The LDAP schema files define the types and semantics of how data is communicated. Therefore it is important to preventing write access to the schemas except by root Discussion: The ldap schema files must not be writeable except by root. For example: drwxr-xr-x 3 root root /etc/openldap/schema/ -rw-r--r-- 1 root root corba.schema -rw-r--r-- 1 root root core.ldif -rw-r--r-- 1 root root core.schema 1.9 Permissions for Rootdn Password In order to protect the powerful Root Distinguished Name password from disclosure except to the ldap server group and root. Discussion: The database or configuration file that contains the Root Distinguished Name password should be owned by root, must read-only for the ldap group, and not readable by other users. That is : root:ldap 0640

1.10 Protect the LDAP Database Inappropriate direct access to the LDAP database makes it easy to copy and crack passwords or to directly update the database depending on the access. Also keep in mind that different types of database may be used such as a SASL database. Discussion: The directory and files storing the LDAP database should be owned by the ldap user and the ldap group, and have permission 0600. For example: drwx------ 2 ldap ldap 4096 /var/lib/ldap/ -rw------- 1 ldap ldap 24576 __db.001

The mention of SASL deserves more attention. In most cases the separate SASL database shouldn't be used at all, since slapd provides an integrated SASL password access module.

...

1.11 Protect LDAP Export/Import Files

Rather than attack the LDAP database directly it's often easier to obtain the information through backup files or import/export files typically stored in LDIF format. Look for such files on the local system and review any import or export processes that are being used. Discussion: Any backup, export, import or other files containing the LDAP database must be removed when no longer needed, and protected with minimal read access, such as owned by root with permissions 600.

It's important to identify what "no longer needed" means. The OpenLDAP software generally doesn't need these files at all, so this is a site-local policy question.

...

1.12 Dedicated System In order to reduce the risk of potential vulnerabilities in other services jeopardizing the LDAP server, consider installing OpenLDAP on a dedicated system, or a server with minimal services. Discussion: System should be dedicated to running OpenLDAP. If possible, only administrative services like SSH and other closely related authentication services such as radius should be running on the same system.

...

1.13 Restricted File System Access In case the slapd service is exploited remotely file systems access restrictions will prevent the exploit from getting access to system files and executables. Discussion: Consider running slapd in a chroot environment, or using SELinux, or Solaris RBAC, to restrict access to system files for the slapd user (typically ldap).

1.14 Restricted Network Access Consider listening on the local loopback interface, using Unix domain sockets if only local access is required, or consider restricting access based on source IP addresses if network access is required Discussion: Restrict network access using host based IP filtering to the minimal networks or systems requiring access. This may be accomplished with tcpwrappers, iptables, bpf or ipf depending on the platofrm.

Host-IP based access control is generally useless since IP addresses are so easily spoofed. No serious security document has any business recommending this mechanism.

...

2 Slapd Configuration File - slapd.conf The following configuration directives are made to the slapd.conf file typically found in /etc/openldap/

2.1 LDAPv2 Bind Note the bind_v2 option is not enabled by default. It allows the old version 2 bind, and does not enable support for the entire LDAPv2 protocol. Discussion: Do not allow the older ldapv2 bind request unless compatibility with old LDAP clients is absolutely necessary. Do NOT specify allow bind_v2 in the slapd.conf file.

2.2 RootDN Password Storage Since the Root Distinguished Name password provides full unrestricted administrative access to the ldap data, it needs to be carefully protected with a secure salted hash value. The slappasswd(8) command may be used to generate the hash. Administrators will need to update and may need to share the contents of the slapd.conf file, placing the rootdn password in a separate file helps protects it from accidental disclosure. Discussion: The Root Distinguished Name password must NOT be stored directly in the slapd.conf file. It may stored in an alternative database or service such as SALS or included from a separate protected file using a salted MD5 hash value. Such as: rootdn "cn=Manager,dc=example,,dc=com" rootpw {SMD5}sK9tP8eUpB. . .Cq4gFk=

OpenLDAP defaults to using SSHA. It's probably not a good idea to mention MD5 in any security recommendations any more, since it was fully broken in 2004. (e.g. http://csrc.nist.gov/pki/twg/y2004/Presentations/twg-04-14.pdf)

...

2.3 Other Password Storage Any application and other special passwords including administrative or operator passwords should be stored in a database which uses a salted secure hash. Storing them in the same database as the users is acceptable, but a separate OU is recommended. Discussion: No other LDAP passwords including application passwords must be stored directly in the slapd.conf file, or in any file included by the slapd.conf file.

Unfortunately administrators cannot follow this recommendation, since slurpd and syncrepl replication requires access to a plaintext password (for password-based authentication mechanisms). You probably need to place stronger emphasis on certificate or ticket-based authentication if you want to avoid this issue.

...

2.4 RootDN Password Policy

The LDAP RootDN password is easily overlooked with regard to password policies for administrative access. Discussion: The password used for the rootdn must comply with the organizations policies for administrative passwords especially with regard to password complexity and periodic changes.

You probably ought to say a few things about the OpenLDAP password policy overlay here. Of course, this module completely ignores policy settings for the rootDN. Since slapd is designed to be self-contained and fully administrable remotely through LDAP, it would be self-defeating to allow the administrator to lock themselves out simply because their admin password expired.

...

2.5 Administrative Access Individual accounts are necessary for accountability, and reduces the risk of password disclosure. Discussion: Administrators and operators with privileged access should use individual accounts for day-to-day tasks rather than the rootdn account or a shared account.

2.6 Application Access Individual accounts are also necessary for applications, to ensure minimal access, and to help track possible abuses. Discussion: When applications accounts are required, the accounts should provide minimal required access and not be shared with other applications or users.

2.7 Log Configuration The LogLevel is configured as the sum of the following binary flags represented by their decimal values below: See slapd.conf(5) for details. 1 = Trace function calls 2 = Debug packet handling 4 = Heavy Trace debug 8 = Connection Management 16 = Print Packets sent and received 32 = Search Filter processing 64 = Configuration File processing 128 = Access Control List processing 256 = Statistics for connections, operations and results 512 = Statistics for entries sent 1024 = Print communication with shell backends 2048 = Entry parsing

The LogLevel must be set to include the following flags. 8 = Connection Management 64 = Configuration File processing 256 = Statistics for connections, operations and results In addition, the search processing flag is highly recommended provided performance and log space allow. 32 = Search Filter processing For example the following is the sum of above values (8+32+64+256): LogLevel 360

Some explanation for why your recommended settings are being recommended would be useful here.

...

2.8 TLS / SSL Configuration Historically, SSL was developed by Netscape and then accepted as an open standard and renamed to TLS. Therefore in many contexts the names are synonymous. As noted below theSSLv2 protocol is weak while SSLv3 and TLSv1 are both acceptably strong. However many clear text protocols including ldap often use the term TLS or STARTTLS to refer to a protocol which switches to encryption mode after the initial clear text connection, and before authenticating. While SSL is sometimes used to refer to a complete encapsulation of the cleartext protocol in SSL/TLS such as ldaps does on port 636 and https does on port 443. Discussion: The ldap servers must be configured to support either TLS typically on port TCP/389 or (ldaps protocol port TCP/636) in order to allow clients to authenticate the server, and to protect the passwords and other information from disclosure on the network. Of the 2 protocols, TLS is preferred.

The terminology here has always been confusing, and the above text does nothing to help the situation. "TLS" is the secure (transport-layer)communication protocol, "STARTTLS" is an application-level request to enable the TLS protocol.

...

2.9 SSL / TLS Certificate A trusted CA may be one that your organization established; The Certificate Authority must be carefully protected and the systems connecting to the LDAP server need to be configured to trust the same CA. Also consider if requiring client certificates for authentication might be suitable for the implementation. Discussion: SSL / TLS X.509 Certificate must be a valid, non-expired certificate that signed by Trusted Certificate Authority (CA) with a X.509 common name (CN) that matches the hosts fully qualified domain name (FQDN).

2.10 TLS Certificate File Permissions The private key file must be protected carefully from disclosure. Intercepted SSL communications may be decrypted using this key. Encryption of the key file is

encouraged if reasonable, however having the file encrypted will require someone to enter the password every time the slapd server is started. Discussion: The certificate authority, certificate and key file are configured in slapd.conf as show below, and must by owned by root and writable only by root, The private key file should be readable only the ldap user, while the ca and certificate are public information and may be readable by anyone. Encryption of the key file is recommended but not required. TLSCACertificateFile /etc/pki/tls/cacert.crt TLSCertificateFile /etc/pki/tls/ldap.example.net.crt TLSCertificateKeyFile /etc/pki/tls/ldap.example.net.key root:ldap 644 cacert.crt root:ldap 644 ldap.example.net.crt root:ldap 640 ldap.example.net.key

This discussion is next to useless because it offers no explanation of which certificates you're talking about. Either you should explicitly state "it is assumed that you understand what TLS certificates are" or you really need to point people at some place to get more information.

...

2.11 Strong TLS Ciphers The HIGH and MEDIUM ciphers include those that 128 bit or stronger. The !ADH prevents the weak Anonymous Diffie-Hellman key exchange from being used, while the -SSLv2 removes the weaker ciphers used with the SSLv2 protocol. It is recommended that you use the openssl command below to validate the actual list of ciphers defined by any cipher string on the system as different openssl compilations may differ. openssl ciphers -v 'cipher-string' The servers must be configured to not allow weak ciphers. The following configuration allows only 128 bit or stronger ciphers and is expected to be compatible with most ldap clients. TLSCipherSuite HIGH:MEDIUM:!ADH:-SSLv2

Here you're making the assumption that OpenSSL is available on the system, but your readers may be using something else, e.g. Netscape NSS or GnuTLS. (OpenLDAP 2.4 has full native support for GnuTLS, and systems like Debian really don't support OpenSSL.)

...

2.12 Security Strength Factors Allowing bind operations with password authentication without requiring SSL/TLS encryption would open clients up to man-in-the-middle attacks as well as allow for eavesdropping of passwords and other information. Discussion: The Security Strength Factors (SSF) indicates the relative strength of protection required for different types of access, such as bind, read-only or update access. The SSF flag indicates the overall strength required, while simple_bind is the strength factor required for a simple bind operation. Refer to the slapd.conf(8) man page for details. The number indicates the strength of the encryption in terms of the approximate number of effective

cipher bits. For example, 112 allows usage of triple DES or stronger, while 128 requires the stronger 128bit ciphers such as blowfish and RC4. Minimal recommended setting is 112 for all operations. security ssf=112 update_ssf=112 simple_bind=112

2.13 Disallow Anonymous Access Although bind_anon is disabled by default in current OpenLDAP implementations, is recommended that the directive be included for additional assurance. Discussion: Use the following directive to disallow anonymous bind access to the LDAP server, which provides access with no user name or password. disallow bind_anon

2.14 Disallow Unauthenticated Access Allow access only for those authenticated with both a valid username and a password. Discussion: Use the "require authc" directive to disallow unauthenticated access, which provides a valid user name, but no password. require authc

2.15 Require Protection For Simple Bind Although this directive is redundant the to the simple_bind security factor, it is still recommended as it is vital to protect the authentication process. Of course the SSF setting allows greater control of the ciphers used. Discussion: The 'disallow bind_simple_unprotected' directive requires at least some level of encryption before simple password bind operations are allowed. disallow bind_simple_unprotected

There is no such directive in OpenLDAP. Where did this recommendation come from?

...

2.16 Password Access Controls

Read access to the password field should not be granted except for special circumstances which should also require additional mitigating controls. For example a radius server using ldap accounts for authentication may need to read passwords, however in addition to requiring user/name and password over TLS, additional controls such as client certificates and IP address filtering can further reduce the risks of password disclosure. Discussion: Access to password attributes must be limited to authentication for anonymous, write access for self and administrator's authorized to reset user passwords. For example: access to attrs=userPassword by self write by dn="cn=joeadmin,dc=rd1,dc=net" write by * auth

2.17 Password Hash Usage of a secure hash algorithm such as SHA or MD5 along with a random salt prefix is best practice. The salt prefix makes the fast precomputed dictionary attacks unfeasible, however if the hash is disclosed, password guessing and brute force attacks can still be used to crack the password. Therefore protecting the hash from disclosure and using strong complex passwords are still required. Discussion: The password-hash directive defines the secure hash used to store passwords. The default value is {SSHA} which is the SHA-1 algorithm with a random salt, while {SMD5} is the MD5 hash also with a salt. Either {SSHA} or {SMD5} are recommended. For example: password-hash {SSHA}

No MD5-based algorithms should be recommended.

...

2.18 Size Limit Reducing the sizelimit may be useful in some cases to increase the work required in attacks like ldap injection where the intent is to dump the entire database. However care should be used not prevent legitimate queries. Discussion: The sizelimit directive specifies the maximum number of entries to return to a search request.

It's worth pointing out that sizelimits can be applied on a per-user basis. Generally the default sizelimit is sufficient, but it may be useful to further restrict anonymous queries vs authenticated queries.

...

2.19 Idle Timeout

Reducing the timeout reduces the resources incurred from idle sessions. Discussion: Timeout connection after 120 seconds. Example: idletimeout 120

2.20 Time Limit Reducing the timelimit may be useful to increase the work required in attacks like ldap injection, as well as limit the impact of injecting intentionally expensive queries. However care must be taken to not prevent legitimate usage that would exceed the limit. Discussion: If possible, reduce the maximum time slapd will spend answering a search request to 15 seconds. timelimit 15

This is unlikely to have any effect on most installations, since a properly configured slapd will process most queries in under one second.

...

2.21 Redundent LDAP Servers Consider deploying redundant replicated LDAP servers if the LDAP authentication is a necessary part of the infrastructure for your organization's mission. Discussion: Additional LDAP servers can be maintained with updates automatically replicated from the master by using slurpd to distribute the updates to slave LDAP servers. The configuration of the slave LDAP servers should be configured with same security requirements as the master, except that a special dedicated distinguished name should be used specifically for authenticating master slurpd which distributes the updates to the slave LDAP servers. Master slapd.conf replogfile /var/lib/ldap/openldap-master-replog replica uri=ldap://ldap2.example.com:389 starttls=yes binddn="cn=Replicator,ou=services,dc=example,dc=com" bindmethod=simple credentials=xxxxxxxxxxx

Slave slapd.conf access to * by dn="cn=Replicator,ou=services,dc=example,dc=com" write updatedn "cn=Replicator,ou=services,example,dc=com" updateref "ldap://ldap1.example.com

Slurpd has long been deprecated. A document written as recently as this should be discussing syncrepl.

On 9/28/07, Howard Chu hyc@symas.com wrote:

Buchan Milne wrote:

...

On Thursday 27 September 2007 20:09:19 Howard Chu wrote:

...

...

Unfortunately, they show configuration for slurpd in their section on "Redundant LDAP Servers".

I wonder if it is worthwhile providing CIS with feedback?

Now that you've pointed it out, I went and downloaded it. I find the quality of the editing of this document to be pretty abysmal, but the factual content is at least fixable. I'll be sending some feedback to the editor shortly.

As usual, if you want to know "best practices", the best way to get that is just to ask us or read the docs we've already written...

Indeed, but unfortunately our esteemed security group bases their security standards on the CIS benchmarks (usually their changes reduce the technical quality at the expense of formatting etc.), so I suspect at some stage I'll be getting questions about an OpenLDAP standard (and I'll probably have to fix it up more than I have the Linux one ...).

Understood. As Tony pointed out, when I said "when you want to know" I of course meant "when one wants to know" because obviously you, Buchan, already know what you're doing.

For anyone curious, here's their document as plaintext with my commentary inserted.

Howard Chu wrote:

...

You really ought to run articles like this by us before publishing, to be sure you've got all the facts correct.

...

Center for Internet Security Benchmark for OpenLDAP v1.0

...

Introduction LDAP stands for Lightweight Directory Access Protocol defined in RFC 2251 and others and is based on X.500 directory services. LDAP servers are very popular including commercial servers such as Microsoft Active Directory, IBM Tivoli Directory Server, Novell eDirectory, and Sun Java System Directory Server. OpenLDAP is the most popular of the open source LDAP servers. LDAP servers are just one part of a typical network infrastructure, and their security depends in part on the security of the rest of the infrastructure. However this benchmark will focus primarily on the secure configuration of the OpenLDAP server.

Applicability The benchmark was developed and tested using OpenLDAP version 2.3 on Fedcora Core 6, however most of the content will apply to other

...

Thanks for reproducing this document. I'm glad I didn't fill anything out to download it.

Am I the only one who noticed this: <quote> What is the Benchmark? The Benchmark is a compilation of security configuration actions and settings that "harden" MySQL databases. It recommends Level 1 Benchmark guidance, representing the prudent level of minimum due care for operating system security. </quote> ?

From this example, I would have to recommend strongly against

following the advice of this site.

Quanah Gibson-Mount wrote:

--On Thursday, September 27, 2007 11:49 PM -0700 Howard Chu hyc@symas.com wrote:

...

...

...

disallow bind_simple_unprotected

...

...

There is no such directive in OpenLDAP. Where did this recommendation come from?

There used to be, though.

Hm, a grep through my source tree shows it was added in 2.1.5 and removed around 2.1.7, October 2002. It was only in the code for a month or two. For a document written in August 2007 purportedly about OpenLDAP 2.3, there's really no basis for this recommendation; it's the equivalent of folklore and old wives' tales. Not exactly a sound foundation for a security policy.