UCS Security Hardening - A Collection
This is a collection of security related best practices and configurations for Univention Corporate Server.
The first draft of this guide originated from a project with a customer to make UCS compliant with the Payment Card Industry Data Security Standard (PCI DSS). All mentioned PCI DSS requirements refer to version 3.2 of PCI DSS. The security requirements of PCI DSS can of course also be used as a guideline for organisations that don’t deal with payment card data, but please be aware that compliance to a standard does not necessarily increase the security in every case. Please don’t blindly follow this guide. Review every setting and make sure you understand the consequences. It is recommended to perform your own risk analysis and then apply those security measures that are relevant to your situation.
Disclaimer: This collection comes WITHOUT WARRANTY and WITHOUT ANY CLAIM OF COMPLETENESS. Feel free to report errors below in the comments. Contributions are welcome
This collection is for UCS 4.2. If you are running an older version of UCS we strongly recommend to upgrade to the latest version to benefit from the recent security improvements and up-to-date packages (e.g. GnuTLS and OpenSSL, just to name a few).
Please note that security measures can only be a risk reduction. They do not a guarantee that you are safe from attacks or data breaches.
This is independent from UCS, but overall security needs to be taken into account, of course.
PCI DSS has the following overall requirements:
- Maintain a secure network
- For Firewalls, Routers, Switches, Printers, BIOS/UEFI, Lights Out Management (LOM) → replace default passwords, replace/review default settings
- Protect sensitive information (e.g. cardholder data)
- encryption at rest (e.g. encrypted LVM)
- encryption in transmit (e.g. enforcing encrypted network traffic)
- Maintain a Vulnerability Management Program
- Protect all systems against malware
- Develop and maintain secure systems and applications
- Implement strong Access Control
- Restrict access to sensitive data
- Identify and authenticate access to system components
- Restrict physical access to sensitive data (e.g. lock up your server room)
- Regularly monitor and test Networks
- Track and monitor all access to network resources and sensitive information
- Regularly test security systems and processes (config file integrity monitor, vulnerability scanner, pen-testing …)
- Maintain an Information Security Policy
- Maintain a policy that addresses information security for all personnel
Independently of PCI DSS:
- Have a look at https://decentsecurity.com/enterprise/ for a collection of good practical advice
- Disable all services that are not explicitly relevant
- Use different passwords for root and Domain Admins (to separate machine and domain administration)
- Use different passwords for root on each system (to avoid lateral movement of an attacker)
- Do not use Administrator and root for daily operation. Use personalized administration accounts instead (e.g. with
- Use separate administration accounts for Domain controller and client administration
- IT staff uses un-privileged accounts for their usual tasks (e.g. reading mail) and only use privileged accounts if necessary (e.g. adding a new user)
- Have a look at this Univention blog post that also deals with reducing attack vectors with focus on Kerberos and Pass-the-hash
- Have recent backups
- Limit access to backups (control access, encrypt them)
- Ensure you can restore your backups
Integrity monitoring - you need to know when things change and who changed what.
- For the changes made to the OpenLDAP directory, use univention-directory-logger. This is part of the default UCS features (no additional costs) but needs to be installed manually:
- Use a component that logs all (privileged) commands executed on the shell
- e.g. Snoopy Logger to log all executed commands (+ arguments) to syslog
- or auditd, the Linux Audit System
Use a configuration file monitoring such as OSSEC, Tripwire or etckeeper
Use a central monitoring tool with alerting and reporting (for PCI DSS compliance, there is http://www.wazuh.com/pci-dss/)
Keep an eye on all session timeouts. You might to ensure that people are logged out after a certain time of inactivity (e.g. if an admin forgot to lock their desktop). Please balance the pros and cons here. Short timeouts force people to re-enter their passwords more often which is a higher risk for so-called Shoulder Surfing.
PCI DSS allows max. 15 minutes (900 seconds) of idle time.
- Since UCS 4.2 the UMC session timeout defaults to 28800 seconds (8 hours) and needs to be adjusted. The timeout can be altered via the UCR variable
- SSH sessions are closed after 3 x 60 seconds (= 3 minutes) of inactivity by default. This value can be altered via these two UCR variables:
sshd/config/ClientAliveInterval (defaults to ‘60’)
sshd/config/ClientAliveCountMax (defaults to ‘3’)
- Please note that this configuration does not apply if a terminal multiplexer like
tmux is used, which keep the session alive.
- If the UCS Self Service is used, the token lifetime has to be reduced to 15 minutes (
- PCI DSS requires at least 7 characters, a password history of at least 4 and a validity of max. 90 days.
- The UCS default is at least 8 characters, a password history of 3 and an unlimited validity. Learn more about password policies in UCS. Please balance the pros and cons here. Short validity of passwords might be counterproductive, because people start noting down their passwords.
- PCI DSS requires to activate a password complexity check. To enable this on UCS, use the check mark at the user object. To alter the complexity requirements, use these UCR variables:
→ Example: if
password/quality/credit/digits is set to
3, the password must contain at least 3 digits.
→ change at least three of the UCR variables to the value ‘1’ to meet the PCI DSS requirements.
PCI DSS requires at least SHA-256 as password hash algorithm. Current UCS versions use SHA-512 by default. For LDAP user accounts, check the following UCR variable, especially if you installed with an older version of UCS:
If you have not changed the password of local (non-LDAP) accounts such as
root after updating to UCS 4.1-3 errata 302, their passwords might still be hashed with md5crypt. Please change the password after updating to a recent UCS version to automatically change the hashed password to sha512crypt.
- PCI DSS requires that user accounts MUST be deactivated after 90 days of inactivity
- There is no automated way to this in UCS or Active Directory and needs a custom check.
- useful OpenLDAP attributes might be:
- useful Samba/AD attributes:
- PCI DSS requires that users MUST be locked out from accessing systems and services after 6 unsuccessful login attempts. The lockout duration has to be at least 30 minutes or until an administrator enables the user account again. This can be configured in UCS via the faillog feature.
- Please note, that if Samba is used as Active Directory Domain Controller, additional steps have to be made to also activate the account lockout feature of Active Directory (see https://technet.microsoft.com/en-us/library/hh994563(v=ws.11).aspx for details).
- if an Administrator needs to reset a user password, the user MUST be forced to set a new one at the next login. UCS comes with a ceckbox at the user account for this.
Further SSH configuration
sshd/Protocol MUST NOT be “1” (UCS default is SSH protocol version 2)
- SSH access for root SHOULD be disabled (
sshd/permitroot). Before you lock out root, make sure you can log in with another account.
- SSH X-Forwarding MUST be disabled (
- The following UCRVs should meet modern defaults (the UCS 4.2 defaults are fine):
- It is recommended to renew the SSH keys:
sshd/HostKey/rsa=4096 && univention-openssh-recreate-host-keys
- For monitoring and auditing reasons, it’s important that all system clocks are in sync.
- You MUST configure at least one external time server for the UCS Master (
timeserver). Other UCS server roles will default to use the UCS Master as upstream time server.
- PCI DSS requires that NTP must be configured with peers (bi-directional sync between servers of same stratum inside a corporate network for redundancy). For UCS, that means you will have to modify the UCR template of
Services that might store sensitive data
Samba Active Directory Domain Controller
Samba uses GnuTLS for TLS based transport encryption. The used TLS ciphers can be configured to exclude broken protocols and algorithms:
This variable can be set to a string describing the TLS protocols to be
supported in the parts of Samba that use GnuTLS, specifically the AD DC.
The string must be in the format of a GnuTLS supported priority string
(see man smb.conf)
The default is
NORMAL:-VERS-SSL3.0, which excludes SSLv3.
For more information on GnuTLS and its priority strings see: http://gnutls.org/manual/html_node/Priority-Strings.html and http://blog.lighttpd.net/gnutls-priority-strings.html
You can test the current configuration:
univention-install gnutls-bin # install the CLI package
gnutls-cli -l # lists all available ciphers
gnutls-cli --priority "NORMAL:-VERS-SSL3.0" -p 636 $(hostname -f) # connect to the Samba/AD service
A more strict configuration that only allows TLS 1.2 with AES GCM would be:
ucr set samba/tls/priority="NORMAL:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1:-CIPHER-ALL:-SHA1:-MD5:-RSA:-ARCFOUR-128:+AES-256-GCM:+AES-128-GCM:%SERVER_PRECEDENCE"
Important: This configuration has not been tested for broad client compatibility and will likely deny access to older clients such as Windows XP.
To be able to use Diffie-Hellman key exchanges, we need a DH-Param file:
This variable can be set to the name of a file with Diffie-Hellman parameters
(PEM format) which will be used with EDH ciphers (see man dhparam).
openssl dhparam -out /etc/univention/ssl/samba_dhparams.pem 2048
ucr set samba/tls/dh/params/file="/etc/univention/ssl/samba_dhparams.pem"
For security reasons, the SMB signing should be mandatory and we should disable NTLMv1 and disable SMBv1:
ucr set samba/server/signing='mandatory' \
OpenLDAP uses OpenSSL for TLS based transport encryption. The used TLS ciphers can be configured to exclude broken protocols and algorithms:
This configures the cryptopgraphic algorithms which are offered to clients
during a SSL handshake. The format is described at
If the variable is unset, 'HIGH:MEDIUM:!aNULL:!MD5:!RC4' is used.
This configures the minimum version for the SSL/TLS protocol. For TLS
1.0/1.1/1.2 the value 3.1/3.2/3.3 must be specified. Default is 3.1 for TLSv1.0.
The TLS protocol version SHOULD be upgraded to at least TLS 1.2:
ucr set ldap/tls/minprotocol='3.3'
Other important UCR variables:
Cronjob interval for recreating DH parameter files (forward secrecy).
This configures the name of the file containing the parameters for Diffie-Hellman ephemeral key exchange. Default is
Automatically restart the LDAP server, after a new DH parameter file has been generated. Disabled by default.
It is recommend to enforce HTTPS and configure Apache to only offer modern TLS ciphers, e.g.:
mail/postfix/tls/client/exclude_ciphers: RC4, aNULL
List of ciphers or cipher types to exclude from the Postfix SMTP client cipher list at all TLS security levels as described in <http://www.postfix.org/postconf.5.html#smtp_tls_exclude_ciphers>. Defaults to "RC4, aNULL"
This variable configures the use of TLS encryption in SMTP: 'may' uses TLS if the other server offers it, 'none' deactivates it. Further configuration directives are documented at <http://www.postfix.org/postconf.5.html#smtp_tls_security_level>.
List of SSL/TLS protocols that the Postfix SMTP client will use with mandatory TLS encryption. (default: '!SSLv2') <http://www.postfix.org/postconf.5.html#smtp_tls_mandatory_protocols>
List of TLS protocols that the Postfix SMTP client will exclude or include with opportunistic TLS encryption. (default: '!SSLv2') <http://www.postfix.org/postconf.5.html#smtp_tls_protocols>
If set to 'yes' the Postfix SMTP server uses its own cipher preference order instead of the remote client's cipher preference order.
How often to regenerate the SSL parameters file in hours, 0 disables regeneration. Defaults to "168" (once per week).
Prefer the server's order of ciphers over client's. Defaults to "yes".
SSL protocols to use. Defaults to "!SSLv2 !SSLv3".
The MySQL server package in UCS will automatically create and configure a password for the MySQL superuser (root) during installation. This password is stored in
/etc/mysql.secret - if you change the root password in MySQL, don’t forget to also change it in that file.
After the installation, run
mysql_secure_installation. This will …
- Remove anonymous users
- Disallow root login remotely
- Remove test database and access to it
Depending on whether you installed
univention-mysql, the MySQL daemon is either listening on localhost only (
127.0.0.1) or on all interfaces (
0.0.0.0). The latter ist useful for applications inside a Docker container. For
univention-mysql you can restrict the access via the UCR variable
mysql/config/mysqld/bind_address. The port is
3306 and there is NO default firewall rule. That means accessing MySQL from another system has to be allowed through a custom packetfilter rule, making it more secure by default.
PostgreSQL is usually installed via the meta package
univention-postgresql. PostgreSQL is listening on port
5432 on all network interfaces (
0.0.0.0) by default, but only allows connections from localhost (
127.0.0.1), the Docker interface (
172.17.42.1/16) and a local socket. There is also a default firewall rule that allows remote systems to access port 5432 (
security/packetfilter/package/univention-postgresql-9.4/tcp/5432/all). If necessary, this default rule can be disabled and replaced by a custom iptables rule in
To access the databases, you need to use the user
postgres (or a dedicated user per database).
Starting with UCS 4.2 errata 64, SSLv3 is now disabled for the UMC server (Port 6670). The OpenSSL ciphers can be configured via the UCR variable