Some of the security controls provided by the STIG are difficult to group together. The following documentation includes STIG requirements which do not easily fit into one of the other hardening domains.
Reliable time synchronization is a requirement in the STIG and the chrony
package will be installed to handle NTP for systems secured with the openstack-
ansible-security role. The default settings will work for most environments,
but some deployers may prefer to use NTP servers which are geographically
closer to their servers.
The role configures the chrony daemon to listen only on localhost
. To allow
chrony to listen on all addresses (the upstream default for chrony),
set the security_ntp_bind_local_interfaces_only
variable to False
.
The default configuration allows RFC1918 addresses to reach the NTP server
running on each host. That could be changed by using the
security_allowed_ntp_subnets
parameter.
All of the tasks for these STIG requirements are included in
tasks/rhel7stig/misc.yml
.
The security role already deploys a login banner for console logins with tasks from another STIG:
Although the STIG requires that GRUB 2 asks for a password whenever a user attempts to enter single-user or maintenance mode, this change might be disruptive in an emergency situation. Therefore, this change is not applied by default.
Deployers that wish to opt in for this change should set two Ansible variables:
security_require_grub_authentication: yes
security_grub_password_hash: grub.pbkdf2.sha512.10000.7B21785BEAFEE3AC...
The default password set in the security role is ‘secrete’, but deployers
should set a much more secure password for production environments. Use the
grub2-mkpasswd-pbkdf2
command to create a password hash string and use it
as the value for the Ansible variable security_grub_password_hash
.
Warning
This change must be tested in a non-production environment first. Requiring authentication in GRUB 2 without proper communication to users could cause extensive delays in emergency situations.
The tasks in the security role for V-71961 will also apply changes to systems that use UEFI. For more details, refer to the following documentation:
The autofs
service is stopped and disabled if it is found on the system.
Deployers can opt out of this change by setting the following Ansible variable:
security_rhel7_disable_autofs: no
The SELinux targeted policy is enabled on CentOS 7 and Red Hat systems. AppArmor only has one set of policies, so this change has no effect on Ubuntu, openSUSE Leap and SUSE systems running AppArmor.
For more information on this change and how to opt out, refer to The operating system must enable SELinux. (V-71989).
The tasks in the security role disable the control-alt-delete key sequence by masking its systemd service unit.
Deployers can opt out of this change by setting the following Ansible variable:
security_rhel7_disable_ctrl_alt_delete: no
Although the STIG requires that all initialization files must contain executable search paths that resolve to the user’s home directory, this change be disruptive for most users. The tasks in the security role do not make any changes to user initialization files.
Deployers should examine any filesystem mounts that contain home directories to
ensure that the nosetuid
option is set.
Deployers should examine any filesystem mounts of removable media to ensure
that the nosetuid
option is set.
Deployers should examine any filesystem mounts of NFS imports to ensure that
the nosetuid
option is set.
Ubuntu, CentOS, Red Hat Enterprise Linux, openSUSE Leap and SUSE Linux Enterprise already capture the logs from cron.
Ubuntu systems collect cron job logs into the main syslog file
(/var/log/syslog
) rather than separate them into their own log file.
CentOS and Red Hat Enterprise Linux systems collect cron logs in
/var/log/cron
.
openSUSE Leap and SUSE Linux Enterprise collect cron job in
/var/log/messages
.
Deployers should not need to adjust these configurations unless a specific
environment requires it. The tasks in the security role do not make changes to
the rsyslog
configuration.
The group ownership for /etc/cron.allow
is already set by the task for the
following STIG control:
If the cron.allow file exists it must be owned by root. (V-72053)
Deployers should consider using filesystem mounts for home directories during the initial server provisioning process. Adding filesystem mounts after a system is provisioned might lead to downtime.
The tasks in the security role do not take action on filesystem mounts. If the
server does not mount /home
as a separate filesystem, a warning is printed
in the Ansible output.
Deployers should consider using filesystem mounts for /var
during
the initial server provisioning process. Adding filesystem mounts after a
system is provisioned might lead to downtime.
The tasks in the security role do not take action on filesystem mounts. If the
server does not mount /var
as a separate filesystem, a warning is printed
in the Ansible output.
Deployers should consider using filesystem mounts for /var/log/audit
during
the initial server provisioning process. Adding filesystem mounts after a
system is provisioned might lead to downtime.
The tasks in the security role do not take action on filesystem mounts. If the
server does not mount /var/log/audit
as a separate filesystem, a warning is
printed in the Ansible output.
Deployers should consider using filesystem mounts for /tmp
during
the initial server provisioning process. Adding filesystem mounts after a
system is provisioned might lead to downtime.
The tasks in the security role do not take action on filesystem mounts. If the
server does not mount /tmp
as a separate filesystem, a warning is
printed in the Ansible output.
The tasks in the Ansible role install the dracut-fips
(RHEL and SLE) and
dracut-fips-aesni
(RHEL) packages and check to see if FIPS is enabled on the
system. If it is not enabled, a warning message is printed in the Ansible
output.
Enabling FIPS at boot time requires additional manual configuration. Refer to Chapter 7. Federal Standards and Regulations in the Red Hat documentation for more details. Section 7.1.1 contains the steps required for updating the bootloader configuration and regenerating the initramfs.
Note
This change only applies to CentOS, Red Hat Enterprise Linux, openSUSE Leap and SUSE Linux Enterprise. Ubuntu does not use dracut by default and the process for enabling the FIPS functionality at boot time is more complex.
When a server is initially provisioned, deployers should avoid storing the boot loader on removable media. It is not possible to change this via automated tasks.
The tasks in the security role check for uncommented lines in the rsyslog
configuration that contain @
or @@
, which signifies that a remote
logging configuration is in place. If these lines are not found, a warning
message is printed in the Ansible output.
Deployers must take manual steps to add or remove syslog reception configuration lines depending on a server’s role:
The STIG requires that a virus scanner is installed and running, but the value of a virus scanner within an OpenStack control plane or on a hypervisor is negligible in many cases. In addition, the disk I/O impact of a virus scanner can impact a production environment negatively.
The security role has tasks to deploy ClamAV with automatic updates, but the tasks are disabled by default.
Deployers can enable the ClamAV virus scanner by setting the following Ansible variable:
security_enable_virus_scanner: yes
Warning
The ClamAV packages are provided in the EPEL repository. Setting the
security_enable_virus_scanner
will also cause the EPEL repository to
be installed by the role.
By default, CentOS 7, Red Hat Enterprise Linux 7, openSUSE Leap and SUSE Linux Enterprise 12 check for virus database updates 12 times a day. Ubuntu servers have a default of 24 checks per day.
The tasks in the security role do not adjust these defaults as they are more secure than the STIG’s requirement.
Deployers should review each firewall rule on a regular basis to ensure that each port is open for a valid reason.
The tasks in the security role set a 600 second (10 minute) timeout for network connections associated with a communication session. Deployers can change the timeout value by setting the following Ansible variable:
# Example: shorten the timeout to 5 minutes (300 seconds)
security_rhel7_session_timeout: 300
The tasks in the security role make the following changes on each host:
chrony
package is installed.chronyd
on Red Hat, CentOS, SLE and openSUSE Leap,
chrony
on Ubuntu) is started and enabled at boot time.maxpoll 10
on
each server line.Deployers can opt out of these changes by setting the following Ansible variable:
security_rhel7_enable_chrony: no
Note
Although the STIG mentions the traditional ntpd
service, this role uses
chrony
, which is a more modern implementation.
Although the STIG requires that incoming TCP connections are rate limited with
firewalld
, this setting can cause problems with certain applications which
handle large amounts of TCP connections. Therefore, the tasks in the security
role do not apply the rate limit by default.
Deployers can opt in for this change by setting the following Ansible variable:
security_enable_firewalld_rate_limit: yes
The STIG recommends a limit of 25 connection per minute and allowing bursts up to 100 connections. Both of these options are adjustable with the following Ansible variables:
security_enable_firewalld_rate_limit_per_minute: 25
security_enable_firewalld_rate_limit_burst: 100
Warning
Deployers should test rate limiting in a non-production environment first before applying it to production systems. Ensure that the application running on the system is receiving a large volume of requests so that the rule can be thoroughly tested.
The STIG requires that a firewall is configured on each server. This might be
disruptive to some environments since the default firewall policy for
firewalld
is very restrictive. Therefore, the tasks in the security role
do not install or enable the firewalld
daemon by default.
Deployers can opt in for this change by setting the following Ansible variable:
security_enable_firewalld: yes
Warning
Deployers must pre-configure firewalld
or copy over a working XML file
in /etc/firewalld/zones/
from another server. The default firewalld
restrictions on Ubuntu, CentOS, Red Hat Enterprise Linux and openSUSE Leap
are highly restrictive.
If a server has fewer than two nameservers configured in /etc/resolv.conf
,
a warning is printed in the Ansible output.
All interfaces are examined to ensure they are not in promiscuous mode. A warning message is printed in the Ansible output if any promiscuous interfaces are found.
The smtpd_client_restrictions
configuration in postfix is set to
permit_mynetworks, reject
to meet the STIG’s requirements.
Deployers can opt out of this change by setting the following Ansible variable:
security_rhel7_restrict_mail_relaying: no
The tasks in the security role examine the TFTP server configuration file (if
it exists) to verify that the secure operation flag (-s
) is listed on the
server_args
line. If it is missing, a warning message is printed in the
Ansible output.
Deployers using NFS should examine their mounts to ensure krb5:krb5i:krb5p
is provided with the sec
option. Kerberos must be installed and configured
before making the change.
The tasks in the security role examine the contents of the
/etc/snmp/snmpd.conf
file (if it exists) and search for the default
community strings: public
and private
. If either default string is
found, a message is printed in the Ansible output.
The firewalld
service is optionally enabled and configured in the tasks for
another STIG control:
Deployers should review their firewalld
ruleset regularly to ensure that
each firewall rule is specific as possible. Each rule should allow the smallest
number of hosts to access the smallest number of services.
Deployers should review all tunneled connections on a regular basis to ensure each is valid and properly secured. This requires careful verification that cannot be done with automated Ansible tasks.
Deployers should review their NFS mounts to ensure they are mounted with the
noexec
option. Deployers should skip this change if they execute
applications from NFS mounts.
Deployers should review the configuration of any wireless networking device connected to the system to ensure it must be enabled. The STIG requires that all wireless network devices are enabled unless required.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.