misc - Miscellaneous security controls¶

Deployer/Auditor notes¶

The security role already deploys a login banner for console logins with tasks from another STIG:

• The Standard Mandatory DoD Notice and Consent Banner must be displayed immediately prior to, or as part of, remote access logon prompts. (V-72225)

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

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:

• Systems with a Basic Input/Output System (BIOS) must require authentication upon booting into single-user and maintenance modes. (V-71961)

Deployer/Auditor notes¶

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

Deployer/Auditor notes¶

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).

Deployer/Auditor notes¶

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

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

Deployers should examine any filesystem mounts that contain home directories to ensure that the nosetuid option is set.

Deployer/Auditor notes¶

Deployers should examine any filesystem mounts of removable media to ensure that the nosetuid option is set.

Deployer/Auditor notes¶

Deployers should examine any filesystem mounts of NFS imports to ensure that the nosetuid option is set.

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

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)

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

Deployers must take manual steps to add or remove syslog reception configuration lines depending on a server’s role:

• If the server is a log aggregation server, deployers must configure the server to receive syslog output from the other servers via TCP connections.
• If the server is not a log aggregation server, deployers must configure the server so that it does not accept syslog output from other servers.

Deployer/Auditor notes¶

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

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

Deployers should review each firewall rule on a regular basis to ensure that each port is open for a valid reason.

Deployer/Auditor notes¶

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

Deployer/Auditor notes¶

The tasks in the security role make the following changes on each host:

• The chrony package is installed.
• The service (chronyd on Red Hat, CentOS, SLE and openSUSE Leap, chrony on Ubuntu) is started and enabled at boot time.
• A configuration file template is deployed that includes maxpoll 10 on each server line.

Deployers can opt out of these changes by setting the following Ansible variable:

security_rhel7_enable_chrony: no

Deployer/Auditor notes¶

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

Deployer/Auditor notes¶

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

Deployer/Auditor notes¶

If a server has fewer than two nameservers configured in /etc/resolv.conf, a warning is printed in the Ansible output.

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

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

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

The firewalld service is optionally enabled and configured in the tasks for another STIG control:

• The operating system must enable an application firewall, if available. (V-72273)

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.

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

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.

Deployer/Auditor notes¶

The STIG requires that multifactor authentication is used for graphical user logon, but this change requires custom configuration based on the authentication solution that is used.

Deployers should review the available options, such as traditional smartcards, USB devices (such as Yubikeys), or software token systems, and use one of these solutions on each system.