Linux Stemcell Hardening

This document applies to currently supported stemcells.

This is the process by which we secure Tanzu Operations Manager by reducing its vulnerability surface from outside access. This document provides responses to some commonly-asked questions regarding the security configuration enhancements and hardening tests that are applied to the Cloud Foundry (“CF”) stemcell. This information will be helpful to customer accreditation teams who are responsible for running configuration scans of a Cloud Foundry deployment, and also to auditors who need a documentation artifact to feed into the customers’ existing security assessment processes.

1. WHAT IS A STEMCELL? A stemcell is a versioned Operating System (“OS”) image wrapped with IaaS specific packaging. A typical stemcell contains a bare minimum OS skeleton with a few common utilities pre-installed, a BOSH Agent, and a few configuration files to securely configure the OS by default. Stemcells do not contain any specific information about any software that will be installed once that stemcell becomes a specialized machine in the cluster; nor do they contain any sensitive information which would make them unable to be shared with other BOSH users. This clear separation between base OS and later-installed software is what makes stemcells a powerful concept. In addition to being generic, a stemcell release contains nearly identical packages for the different infrastructures. This property of stemcells allows BOSH users to quickly and reliably switch between different infrastructures without worrying about the differences between OS images. The CF Foundation is responsible for producing and maintaining an official set of stemcells.

2. WHAT IS STEMCELL HARDENING? Stemcell hardening is the process of securing a stemcell by reducing its surface of vulnerability, which is larger when a system performs more functions; in principle a single-function system is more secure than a multipurpose one. There are various methods of hardening Linux systems. Common techniques include reducing available methods of attack by implementing more restrictive and/or conservative configurations of the OS kernel and system services, changing default passwords, the removal of unnecessary software, unnecessary usernames and logins, and the disabling or removal of unnecessary services.

3. WHAT IS OUR GENERAL APPROACH TO STEMCELL HARDENING? The CF stemcell is essentially a distinct Linux distribution. As such, industry-standard benchmarks are not entirely appropriate when assessing the security posture of the stemcell, but Cloud Foundry has considered and incorporated hardening guidance from various sources both commercial and government. Some parts of the existing recommended industry-standard hardening configurations will certainly apply, but some other parts do not apply. In addition, because each stemcell is a unique Linux distribution, existing industry-standard benchmarks are silent on some important aspects of hardening the stemcell configurations. The following paragraphs describe the different categories of stemcell hardening configurations.

   1. Baseline Passing: common hardening tests that pass without any changes to the stemcell or to test procedures.

   2. Test Amended: Stemcells are optimized for cloud deployment and some configuration settings are not stored in traditionally-expected locations. The industry standard test was changed to conform with stemcell design to accurately check the recommended setting. This new test reflects the changes to the industry standard test but the stemcell adheres to commonly accepted guidance.

   3. Additional Hardening: Configuration hardening improvements that have been made to the stemcell. As with most software, a stemcell’s security improves over time and every stemcell release is tested to ensure that it is suitable for use with its associated CF release. Later releases of a stemcell can include additional security features that were not present in earlier releases.

   4. New CF-specific Tests: New tests that have been added to check CF stemcell-specific configurations. These tests are not yet part of any industry standard Ubuntu benchmark. This category of tests is still under development and additional tests will be added over time.

4. WHAT ARE THE MAJOR FOCUS AREAS FOR OUR STEMCELL HARDENING APPROACH?

   1. Maintenance, Updates, and Patching

      1. Regular patches and feature enhancements are delivered through routine BOSH deployments of updated stemcells (obviates apt-get upgrade).

   2. File System Hardening

      1. The temporary storage directories such as /tmp and /var/tmp are mounted on a separate partition, and configured with appropriately limiting options such as nodev, nosuid, and noexec.

      2. Each of the following directories is in a separate mount, with mount options managed through BOSH agent:

         • /var/log
         • /home
         • /tmp

      3. File system mount options for users’ home directories are limited through appropriate mount options including nodev.

      4. Removable media might not be mounted as character or block special device.

      5. Executable programs might not run from removable media.

      6. setuid and setgid are not allowed on removable media.

      7. Users cannot create special devices in shared memory partitions.

      8. Users cannot put privileged programs onto shared memory partitions.

      9. Users cannot execute programs from shared memory partitions.

      10. Users cannot delete or rename files in world-writable directories such as /tmp that are owned by other users.

      11. Supplementary and exotic Linux file systems that are unused in CF have been deactivated.

      12. Automount of USB drives or disks is not permitted.

   3. Boot Security

      1. The owner and group for the bootloader config (/boot/grub/grub.cfg) is set to root. Only root has read and write access to this file.

      2. Boot loader has been configured so that a password is required to reboot the system.

      3. Unauthorized users cannot reboot the system into single user mode.

   4. Process Security

      1. Users cannot override the soft limit for core dumps.

      2. Randomized virtual memory region placement is enabled.

      3. Prelinking of shared libraries is deactivated.

   5. Minimization of Attack Surface

      1. The Network Information Service (“NIS”) is not used in CF and is not installed.

      2. The Berkeley rsh-server package is not used in CF and is deactivated.

      3. Classic rsh-related tools are not used in CF and are not installed.

      4. The following servers are not used on CF stemcells and are deactivated:

         • talk server
         • telnet server
         • tftp-server
         • Avahi
         • print
         • DHCP
         • DNS
         • FTP
         • IMAP
         • POP
         • HTTP
         • SNMP

      5. The talk client is not used in CF and is not installed.

      6. The eXtended InterNET Daemon (xinetd) is not used in CF and is deactivated.

      7. The following network services are not used in CF and are deactivated:

         • chargen
         • daytime
         • echo
         • discard
         • time

      8. The X Window system is not used in CF and is not installed.

      9. NTP time setting is synchronized on the stemcell through the chrony utility.

      10. The Samba daemon is not used in CF and is deactivated.

      11. The Mail Transfer Agents (MTA) process only local mail.

      12. The rsync service is not used in CF and is deactivated.

      13. The biosdevname tool is deactivated.

   6. Network Security

      1. IPv4 networking is configured such that IP forwarding is deactivated.

      2. The IPv4 networking has been configured such that the host cannot send ICMP redirects.

      3. IPv4 networking has been configured such that the system does not accept source routed packets.

      4. IPv4 networking is configured such that ICMP redirects are not accepted.

      5. ICMP echo and timestamp requests with broadcast or multicast destinations will be ignored.

      6. The stemcell will ignore malformed ICMP error responses.

      7. IPv4 networking is configured for source route validation.

      8. TCP SYN cookies are enabled.

      9. Stemcells are set to refuse IPv6 router advertisements.

      10. The /etc/hosts.allow file exists and is empty.

      11. The /etc/hosts.allow and /etc/hosts.deny files are protected from unauthorized write access.

      12. The /etc/hosts.deny file exists and is empty.

      13. The following protocols are not used in CF and are deactivated:

          • SCTP
          • DCCP
          • TIPC
          • LDAP
          • RDS

      14. Wireless interfaces are deactivated.

      15. IPv6 is not used in CF deployments and the IPv6 protocol is deactivated.

   7. Auditing

      1. Audit log file size is configured for a manageable maximum size of 6 MB.

      2. The system auditd logs have been configured such that the system is resilient in the event of a denial of service attack on the auditd daemon.

      3. Auditd daemon is configured such that all auditd logs are kept after rotation.

      4. The auditd service is enabled.

      5. Auditing of successful and failed login/logout events is enabled.

      6. The Linux auditing subsystem has been configured in accordance with best practice industry guidance to capture all security-relevant events. The /etc/audit/audit.rules configuration now contains more than 50 monitoring rules.

      7. Audit records are created for loading and unloading of kernel modules and for system calls.

      8. File Integrity Monitoring can be done on the stemcell (through a BOSH Add-on).

   8. Authentication and Authorization

      1. The cron daemon is enabled.

      2. Access to the /etc/crontab file is limited to root.

      3. Access to the cron utility configuration through the hourly, daily, weekly, and monthly directories is limited.

      4. User authorization to schedule cron jobs is limited.

      5. Only the vcap user is allowlisted to use the cron and at utilities.

      6. Password requirements follow industry best practice guidance and enforce a minimum length of 14 characters, with at least one each of: digit, uppercase, lowercase and special characters.

      7. Password reuse: users cannot reuse their twenty most recent passwords.

      8. SSH protocol version is configured for SSH-2.

      9. Logging level for SSH event is INFO.

      10. Minimum permissions are set on /etc/ssh/sshd_config.

      11. SSH X11 forwarding is deactivated.

      12. The MaxAuthTries parameter for SSH is set to 3 attempts per connection.

      13. SSH is configured to require passwords and ignore host-based authentication.

      14. Root logins are not allowed over SSH.

      15. Users cannot set environment variables through the SSH daemon.

      16. SSH has been configured to use strong ciphers:

          • aes128-ctr
          • aes192-ctr
          • aes256-ctr

      17. Idle SSH sessions are terminated after 15 minutes, and no client “keep alive” messages are sent.

      18. The SSH login banner might be configured to display site-specific text before user authentication is permitted (through BOSH Add-on).

      19. Root login is only permitted through console, not through tty devices.

      20. Only the vcap user is authorized in the sudo group.

      21. Only users in the root group (a.k.a. wheel) are authorized to run the su command.

   9. Compliance

      1. Contents of /etc/issue and /etc/issue.net have been configured to the phrase: “’Unauthorized use is strictly prohibited. All access and activity is subject to logging and monitoring.” This might be amended if and as necessary through a BOSH Add-on.

      2. The Message of the Day file /etc/motd is not used, but might be populated through a BOSH Add-on if needed.

      3. Identification of the OS and/or version information about the OS does not appear in any login banners.

   10. File System Permissions

       1. The /etc/passwd, /etc/shadow, and /etc/group files are protected from unauthorized write access.

       2. Use and/or presence of any world-writable files has been audited, and minimized to the extent possible for CF.

       3. By default, all stemcell files are owned by a known user and group, and might not belong to a non-existent user or group.

       4. Use of SUID and GUID is restricted, and only the /usr/bin/sudo and /bin/su programs are authorized as SUID and/or GUID programs.

   11. User Account Management

       1. Users cannot change their password more than once a day.

       2. Users are notified 7 days before their passwords expire.

       3. Interactive logins are deactivated for system accounts.

       4. The GID for the root account is 0.

       5. User accounts might not have empty passwords.

       6. NIS is not used in CF, and integration of OS security configuration with legacy NIS permissioning is not enabled (e.g., for /etc/passwd, shadow, and group).

       7. By default, the only UID 0 account present is root.

       8. By default, the root PATH does not include any risky directory such as the current working (.) or any writable directory.

       9. Minimum privileges are applied to all users’ hidden configuration (“dot”) files.

       10. The .netrc and .rhosts and .forward files are not used in CF and are not present in any user home directory.

       11. Any group present in the /etc/passwd file must also exist in the /etc/group file.

       12. Users defined in /etc/password must have a valid home directory.

       13. Users must own their home directories.

       14. All references to user and group names, as well as UID and/or GID identifiers, are self consistent, with no duplicates or orphans allowed.

       15. By default, the shadow group is not used in CF and must be empty.