Re: Center for Internet Security benchmark for OpenLDAP

[Howard Chu <hyc@symas.com>]

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.


--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP     http://www.openldap.org/project/