Stemcell Hardening FAQ

Note: This document applies to stemcell v3263.

Customers and prospects often ask for details on stemcell hardening, i.e., the process by which we secure Pivotal Cloud Foundry 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 Pivotal applies 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. For example: with vSphere, the official stemcell for Ubuntu Trusty is an approximately 500MB VMDK file. With AWS, official stemcells are published as AMIs that can be used in an AWS account. 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, stemcells for one OS (e.g. all Ubuntu Trusty stemcells) are exactly the same for all 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 BOSH team is responsible for producing and maintaining an official set of stemcells. Cloud Foundry currently supports Ubuntu Trusty on vSphere, AWS, OpenStack, Google, and Azure infrastructures.

  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 Pivotal 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, and provide a count of the number of tests currently in each category. Note: The most current description of what has been delivered is always available in the BOSH public Pivotal Trackers.

    1. Baseline Passing: common hardening tests that pass without any changes to the stemcell or to test procedures. (130 tests)
    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. (36 tests)
    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 may include additional security features that were not present in earlier releases. (86 tests)
    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. (20 tests)
  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 via routine BOSH deployments of updated stemcells (obviates apt-get upgrade).
    2. File System Hardening

      1. The /tmp directory is configured to be on a separate partition.
      2. Users cannot create character or block special devices in the /tmp filesystem.
      3. Users cannot create set userid files in the /tmp filesystem.
      4. Users cannot run executable binaries from the /tmp filesystem.
      5. The temporary storage directories such as /tmp and /var/tmp are mounted on a dedicated partition, and configured with appropriately limiting options such as nodev, nosuid, and noexec.
      6. Each of the following directories is in a separate partition, with mount options managed via BOSH agent:
        • /var
        • /var/log
        • /var/log/audit
        • /home
        • /tmp
      7. File system mount options for users’ home directories are limited via appropriate mount options including nodev.
      8. Removable media may not be mounted as character or block special device.
      9. Executable programs may not run from removable media.
      10. setuid and setgid are not allowed on removable media.
      11. Users cannot create special devices in shared memory partitions.
      12. Users cannot put privileged programs onto shared memory partitions.
      13. Users cannot execute programs from shared memory partitions.
      14. Users cannot delete or rename files in world-writable directories such as /tmp that are owned by other users.
      15. Supplementary and exotic Linux file systems that are unused in CF have been disabled.
      16. Additional supplementary and exotic Linux file systems that are unused in CF have been disabled.
      17. 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 disabled.
    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 disabled.
      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 disabled:
        • 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 disabled.
      7. The following network services are not used in CF and are disabled:
        • 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 via the ntpdate utility.
      10. The Samba daemon is not used in CF and is disabled.
      11. The Mail Transfer Agents (MTA) process only local mail.
      12. The rsync service is not used in CF and is disabled.
      13. The biosdevname tool is disabled.
    6. Network Security

      1. IPv4 networking is configured such that IP forwarding is disabled.
      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 disabled:
        • SCTP
        • DCCP
        • TIPC
        • LDAP
        • RDS
      14. Wireless interfaces are disabled.
      15. IPv6 is not used in CF deployments and the IPv6 protocol is disabled.
    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 (via 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 via the hourly, daily, weekly, and monthly directories is limited.
      4. User authorization to schedule cron jobs is limited.
      5. Only the vcap user is whitelisted 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 disabled.
      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. Idle SSH sessions are terminated after 15 minutes. No client “keep alive” messages are sent.
      19. The SSH login banner may be configured to display site-specific text before user authentication is permitted (via BOSH Add-on).
      20. Root login is only permitted via console, not via tty devices.
      21. Only the vcap user is authorized in the sudo group.
      22. 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 may be amended if and as necessary via a BOSH Add-on.
      2. The Message of the Day file /etc/motd is not used, but may be populated via 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 may 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 disabled for system accounts.
      4. The GID for the root account is 0.
      5. User accounts may 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.
Create a pull request or raise an issue on the source for this page in GitHub