Operating Systems
When you deploy Directory Services software, secure the host operating system. The suggestions that follow are not exhaustive. Also familiarize yourself with the specific recommendations for the host operating systems you use.
System Updates
Over the lifetime of a directory services deployment, the operating system might be subject to vulnerabilities. Some vulnerabilities require system upgrades, whereas others require only configuration changes. All updates require proactive planning and careful testing.
For the operating systems used in production, put a plan in place for avoiding and resolving security issues. The plan should answer the following questions:
How does your organization become aware of system security issues early?
This could involve following bug reports, mailing lists, forums, and other sources of information.
How do you test security fixes, including configuration changes, patches, service packs, and system updates?
Validate the changes first in development, then in one or more test environments, then in production in the same way you would validate other changes to the deployment.
How do you roll out solutions for security issues?
In some cases, fixes might involve both changes to the service, and specific actions by those who use the service.
What must you communicate about security issues?
How must you respond to security issues?
Software providers often do not communicate what they know about a vulnerability until they have a way to mitigate or fix the problem. Once they do communicate about security issues, the information is likely to become public knowledge quickly. Make sure that you can expedite resolution of security issues.
To resolve security issues quickly, make sure that you are ready to validate any changes that must be made. When you validate a change, check that the fix resolves the security issue. Validate that the system and DS software continue to function as expected in all the ways they are used.
Disable Unused Features
By default, operating systems include many features, accounts, and services that DS software does not require. Each optional feature, account, and service on the system brings a risk of additional vulnerabilities. To reduce the surface of attack, enable only required features, system accounts, and services. Disable or remove those that are not needed for the deployment.
The features needed to run and manage DS software securely include the following:
A Java runtime environment, required to run DS software.
Software to secure access to service management tools; in particular, when administrators access the system remotely.
Software to secure access for remote transfer of software updates, backup files, and log files.
Software to manage system-level authentication, authorization, and accounts.
Firewall software, intrusion-detection/intrusion-prevention software.
Software to allow auditing access to the system.
System update software to allow updates that you have validated previously.
If required for the deployment, system access management software such as SELinux.
If the DS server sends email alerts locally, mail services.
If you use SNMP with DS servers, an SNMP agent.
Any other software that is clearly indispensable to the deployment.
Consider the minimal installation options for your operating system, and the options to turn off features.
Consider configuration options for system hardening to further limit access even to required services.
For each account used to run a necessary service, limit the access granted to the account to what is required. This reduces the risk that a vulnerability in access to one account affects multiple services across the system.
Make sure that you validate the operating system behavior every time you deploy new or changed software. When preparing the deployment and when testing changes, maintain a full operating system with DS software that is not used for any publicly available services, but only for troubleshooting problems that might stem from the system being too minimally configured.
Administrative Access
Limit access to the system by protecting network ports and reducing access granted to administrative accounts. This further reduces the attack surface and reduces the advantage to be gained from exploiting a vulnerability.
DS servers listen for protocols listed in the following table. When protecting network ports, you must open some to remote client applications, and for replication. If administrators can connect over SSH, you can restrict access to the administrative port to the localhost only.
| Protocols | Ports[a] | Active by Default? | Description |
|---|---|---|---|
LDAP |
| No | Port for insecure LDAP requests and for StartTLS requests to enable a secure connection. The reserved LDAP port number is If LDAP is used, leave this port open to client applications. |
LDAPS |
| No | Port for secure LDAPS requests. The standard LDAPS port number is If LDAPS is used, leave this port open to client applications. |
HTTP, HTTPS |
| No | Port for HTTP client requests, such as RESTful API calls. The standard HTTP port number is If HTTP or HTTPS is used, leave this port open to client applications. For production deployments, use HTTPS instead of HTTP. |
Administration |
| Yes | Port for administrative requests, such as requests from the dsconfig command. Initial setup secures access to this port. |
Replication |
| No | Port for replication requests, using the DS-specific replication protocol. If replication is used, leave this port open to other replicas. For production deployments, secure access to this port. |
JMX |
| No | Port for Java Management Extensions requests ( The default setting for the JMX RMI port is If used in production deployments, secure access to this port. |
SNMP |
| No | Reserved ports are If used in production deployments, secure access to these ports. |
[a] You choose actual port numbers at setup time. | |||
When setting up system accounts to manage directory services:
Set up a separate DS system account for the server.
Prevent other system accounts from accessing DS files.
Configure the system to prevent users from logging in as the DS system account user.
Configure the system to restrict the DS account to server management operations.
System Audits
DS logs provide a record of directory service events, but they do not record system-level events. Use the auditing features of the host operating system to record access that is not recorded in DS logs.
System audit logs make it possible to uncover system-level security policy violations, such as unauthorized access to DS files. Such violations are not recorded in DS logs or monitoring information.
Also consider how to prevent or at least detect tampering. A malicious user violating security policy is likely to try to remove evidence of how security was compromised.