In addition to the CentOS 6.8 and 7.3 images that we released earlier in January 2017, we are happy to announce updated images for our security-hardened offerings. These enhanced security images include the same support that is included with our other images that are available in the AWS Marketplace.
What does Rogue Wave mean by security-hardened images?
We have taken our standard images and modified them to increase the security of the images by minimizing your system’s exposure to outside threats and taking full advantage of mature solutions like SELinux and auditing.
Are security-hardened images difficult to use?
Not at all! You can have an instance of any of our images up and running in minutes. Here’s a demo on how to launch one of our security-hardened images, but the process is the same for our standard images:
As with our standard images, our security-hardened AWS images are minimal by design, taking up as little space as is necessary to provide a fully-functional AWS instance. This maximizes the available space for you to customize the instance to meet your specific needs.
What security standards are they hardened to?
Are these images 100 percent compliant with these standards?
There are certain security measures that cannot be applied to AWS images or are not appropriate for AWS images. The complete exclusion list is detailed below.
Our AWS images consist of a single partition, excluding the following:
• CIS 1.1.1 – Separate Partition for /tmp
• CIS 1.1.2 – Add nodev Option to /tmp
• CIS 1.1.3 – Add nosuid Option to /tmp
• CIS 1.1.4 – Add noexec Option to /tmp
• CIS 1.1.5 – Separate Partition for /var
• CIS 1.1.7 – Separate Partition for /var/log
• CIS 1.1.8 – Separate Partition for /var/log/audit
• CIS 1.1.9 – Separate Partition for /home
AWS images do not have removable media, excluding the following:
• CIS 1.1.11 – Add nodev Option to Removable Media Partitions
• CIS 1.1.12 – Add noexec Option to Removable Media Partitions
• CIS 1.1.13 – Add nosuid Option to Removable Media Partitions
AWS instances do not allow access to the bootloader or console when the instance is started, excluding the following:
• CIS 1.5.3 – Set Boot Loader Password
• STIGs – Encrypt Partitions
Our AWS images are fresh installs from official media, excluding the following:
• CIS 1.2.3 – Ensure Software Patches are Installed
• CIS 1.2.4 – RPM Package Integrity
• CIS 9.1.1 – Verify System File Permissions
• STIGs – Ensure No Device Files are Unlabeled by SELinux
Our AWS images include the chrony package and do not include the NTP package, excluding the following:
• CIS 3.6 – Configure NTP
AWS images do not have wireless interfaces:
• CIS 4.3.1 – Deactivate Wireless Network Interfaces
Our AWS images do not use TCP Wrappers (since it is impossible to know where our customers will connect to the instances from), excluding the following:
• CIS 4.5.4 – Create /etc/hosts.deny
AWS images are firewalled by the EC2 security groups, excluding the following:
• CIS 4.7 – Enable iptables/firewalld
• CIS 4.8 – Enable ip6tables
• STIGs – Set Default iptables Policy for Forwarded Packets
• STIGs – Set Default iptables/ip6tables Policy for Incoming Packets
CIS and STIGs conflict, excluding the following:
• CIS 126.96.36.199 – Configure auditd admin_space_left Action on Low Disk Space
• STIGs – Configure auditd admin_space_left Action on Low Disk Space
• STIGs – Configure LDAP Client To Use TLS For All Transactions
Our AWS images only have a single user account (centos) created by the CentOS installer, so we do not restrict user access, excluding the following:
• CIS 6.2.13 – Limit Access via SSH
• CIS 9.2.16 – Check That Reserved UIDs Are Assigned to System Accounts
Our AWS images are explicitly configured to not display a SSH banner, excluding the following:
• CIS 6.2.14 – Set SSH Banner
Our AWS images do not contain any non-open source software, excluding the following:
• STIGs – Endpoint Protection Software
• McAfee VirusScan Enterprise for Linux
• McAfee Host-based Security System (HBSS) – not generally available to non-US Government entities
Even with these exceptions, our images pass well over 200 security tests prescribed in the CIS 1, CIS 2 and STIGs profiles. The results of the tests is available within the instances in the /var/log/hardened/ directory.
Why should I use Rogue Wave security hardened images instead of hardening an instance myself?
Our automated image hardening process enables us to replicate our image building process with both speed and accuracy. Before we automated the process, it would take us over 8 hours to manually apply the security hardening recommendations to each image that we built, which was then put through rigorous quality assurance (QA) to ensure that we did not miss any steps and that each step was correctly applied.
Even after automating our hardening process, we still put our images through the same rigorous QA to ensure that each image that we release is complete, functional, and hardened the same way.
Sure, you could spend hours performing all of these steps yourself each time a new CentOS release is announced, but why would you want to? Our images are vetted, available and, best of all, include support from our team of Tier 3/4 open source architects and engineers.