Guide to the Secure Configuration of Red Hat Enterprise Linux 6

The SCAP Security Guide Project

https://fedorahosted.org/scap-security-guide

Description

This guide presents a catalog of security-relevant configuration settings for Red Hat Enterprise Linux 6. It is a rendering of content structured in the eXtensible Configuration Checklist Description Format (XCCDF) in order to support security automation. The SCAP content is is available in the scap-security-guide package which is developed at http://fedorahosted.org/scap-security-guide.

Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in any operational scenario. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG for RHEL 6, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.

Notices

Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. The creators of this guidance assume no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.

Revision History

Current version: 0.9

draft (as of 2014-08-28)

Platforms

cpe:/o:redhat:enterprise_linux:6
cpe:/o:redhat:enterprise_linux:6::client

Checklist

contains 223 rules

Introductiongroup

The purpose of this guidance is to provide security configuration recommendations and baselines for the Red Hat Enterprise Linux (RHEL) 6 operating system. The guidance provided here should be applicable to all variants (Desktop, Server, Advanced Platform) of the product. Recommended settings for the basic operating system are provided, as well as for many network services that the system can provide to other systems. The guide is intended for system administrators. Readers are assumed to possess basic system administration skills for Unix-like systems, as well as some familiarity with Red Hat's documentation and administration conventions. Some instructions within this guide are complex. All directions should be followed completely and with understanding of their effects in order to avoid serious adverse effects on the system and its security.

General Principlesgroup

The following general principles motivate much of the advice in this guide and should also influence any configuration decisions that are not explicitly covered.

Encrypt Transmitted Data Whenever Possiblegroup

Data transmitted over a network, whether wired or wireless, is susceptible to passive monitoring. Whenever practical solutions for encrypting such data exist, they should be applied. Even if data is expected to be transmitted only over a local network, it should still be encrypted. Encrypting authentication data, such as passwords, is particularly important. Networks of RHEL 6 machines can and should be configured so that no unencrypted authentication data is ever transmitted between machines.

Minimize Software to Minimize Vulnerabilitygroup

The simplest way to avoid vulnerabilities in software is to avoid installing that software. On RHEL, the RPM Package Manager (originally Red Hat Package Manager, abbreviated RPM) allows for careful management of the set of software packages installed on a system. Installed software contributes to system vulnerability in several ways. Packages that include setuid programs may provide local attackers a potential path to privilege escalation. Packages that include network services may give this opportunity to network-based attackers. Packages that include programs which are predictably executed by local users (e.g. after graphical login) may provide opportunities for trojan horses or other attack code to be run undetected. The number of software packages installed on a system can almost always be significantly pruned to include only the software for which there is an environmental or operational need.

Run Different Network Services on Separate Systemsgroup

Whenever possible, a server should be dedicated to serving exactly one network service. This limits the number of other services that can be compromised in the event that an attacker is able to successfully exploit a software flaw in one network service.

Configure Security Tools to Improve System Robustnessgroup

Several tools exist which can be effectively used to improve a system's resistance to and detection of unknown attacks. These tools can improve robustness against attack at the cost of relatively little configuration effort. In particular, this guide recommends and discusses the use of Iptables for host-based firewalling, SELinux for protection against vulnerable services, and a logging and auditing infrastructure for detection of problems.

Least Privilegegroup

Grant the least privilege necessary for user accounts and software to perform tasks. For example, sudo can be implemented to limit authorization to super user accounts on the system only to designated personnel. Another example is to limit logins on server systems to only those administrators who need to log into them in order to perform administration tasks. Using SELinux also follows the principle of least privilege: SELinux policy can confine software to perform only actions on the system that are specifically allowed. This can be far more restrictive than the actions permissible by the traditional Unix permissions model.

How to Use This Guidegroup

Readers should heed the following points when using the guide.

Read Sections Completely and in Ordergroup

Each section may build on information and recommendations discussed in prior sections. Each section should be read and understood completely; instructions should never be blindly applied. Relevant discussion may occur after instructions for an action.

Test in Non-Production Environmentgroup

This guidance should always be tested in a non-production environment before deployment. This test environment should simulate the setup in which the system will be deployed as closely as possible.

Root Shell Environment Assumedgroup

Most of the actions listed in this document are written with the assumption that they will be executed by the root user running the /bin/bash shell. Commands preceded with a hash mark (#) assume that the administrator will execute the commands as root, i.e. apply the command via sudo whenever possible, or use su to gain root privileges if sudo cannot be used. Commands which can be executed as a non-root user are are preceded by a dollar sign ($) prompt.

Formatting Conventionsgroup

Commands intended for shell execution, as well as configuration file text, are featured in a monospaced font. Italics are used to indicate instances where the system administrator must substitute the appropriate information into a command or configuration file.

Reboot Requiredgroup

A system reboot is implicitly required after some actions in order to complete the reconfiguration of the system. In many cases, the changes will not take effect until a reboot is performed. In order to ensure that changes are applied properly and to test functionality, always reboot the system after applying a set of recommendations from this guide.

System Settingsgroup

contains 167 rules

Installing and Maintaining Softwaregroup

The following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates.

contains 12 rules

Disk Partitioninggroup

To ensure separation and protection of data, there are top-level system directories which should be placed on their own physical partition or logical volume. The installer's default partitioning scheme creates separate logical volumes for /, /boot, and swap.

If starting with any of the default layouts, check the box to "Review and modify partitioning." This allows for the easy creation of additional logical volumes inside the volume group already created, though it may require making /'s logical volume smaller to create space. In general, using logical volumes is preferable to using partitions because they can be more easily adjusted later.
If creating a custom layout, create the partitions mentioned in the previous paragraph (which the installer will require anyway), as well as separate ones described in the following sections.

If a system has already been installed, and the default partitioning scheme was used, it is possible but nontrivial to modify it to create separate logical volumes for the directories listed above. The Logical Volume Manager (LVM) makes this possible. See the LVM HOWTO at http://tldp.org/HOWTO/LVM-HOWTO/ for more detailed information on LVM.

contains 5 rules

Ensure /tmp Located On Separate Partitionrule

The /tmp directory is a world-writable directory used for temporary file storage. Ensure it has its own partition or logical volume at installation time, or migrate it using LVM.

identifiers: CCE-26435-8

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 1208,

Ensure /var Located On Separate Partitionrule

The /var directory is used by daemons and other system services to store frequently-changing data. Ensure that /var has its own partition or logical volume at installation time, or migrate it using LVM.

identifiers: CCE-26639-5

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 1208,

Ensure /var/log Located On Separate Partitionrule

System logs are stored in the /var/log directory. Ensure that it has its own partition or logical volume at installation time, or migrate it using LVM.

identifiers: CCE-26215-4

references: AU-9, 1208,

Ensure /var/log/audit Located On Separate Partitionrule

Audit logs are stored in the /var/log/audit directory. Ensure that it has its own partition or logical volume at installation time, or migrate it later using LVM. Make absolutely certain that it is large enough to store all audit logs that will be created by the auditing daemon.

identifiers: CCE-26436-6

references: AU-4, AU-9, 137, 138, 1208,

Ensure /home Located On Separate Partitionrule

If user home directories will be stored locally, create a separate partition for /home at installation time (or migrate it later using LVM). If /home will be mounted from another system such as an NFS server, then creating a separate partition is not necessary at installation time, and the mountpoint can instead be configured later.

identifiers: CCE-26557-9

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 1208,

Updating Softwaregroup

The yum command line tool is used to install and update software packages. The system also provides a graphical software update tool in the System menu, in the Administration submenu, called Software Update.

Red Hat Enterprise Linux systems contain an installed software catalog called the RPM database, which records metadata of installed packages. Consistently using yum or the graphical Software Update for all software installation allows for insight into the current inventory of installed software on the system.

contains 4 rules

Ensure Red Hat GPG Key Installedrule

To ensure the system can cryptographically verify base software packages come from Red Hat (and to connect to the Red Hat Network to receive them), the Red Hat GPG key must properly be installed. To install the Red Hat GPG key, run:

# rhn_register

If the system is not connected to the Internet or an RHN Satellite, then install the Red Hat GPG key from trusted media such as the Red Hat installation CD-ROM or DVD. Assuming the disc is mounted in /media/cdrom, use the following command as the root user to import it into the keyring:

# rpm --import /media/cdrom/RPM-GPG-KEY

identifiers: CCE-26506-6

references: SI-7, MA-1(b), 351,

Ensure gpgcheck Enabled In Main Yum Configurationrule

The gpgcheck option controls whether RPM packages' signatures are always checked prior to installation. To configure yum to check package signatures before installing them, ensure the following line appears in /etc/yum.conf in the [main] section:

gpgcheck=1

identifiers: CCE-26709-6

references: SI-7, MA-1(b), 352, 663,

Ensure gpgcheck Enabled For All Yum Package Repositoriesrule

To ensure signature checking is not disabled for any repos, remove any lines from files in /etc/yum.repos.d of the form:

gpgcheck=0

identifiers: CCE-26647-8

references: SI-7, MA-1(b), 352, 663,

Ensure Software Patches Installedrule

If the system is joined to the Red Hat Network, a Red Hat Satellite Server, or a yum server, run the following command to install updates:

# yum update

If the system is not configured to use one of these sources, updates (in the form of RPM packages) can be manually downloaded from the Red Hat Network and installed using rpm.

identifiers: CCE-27635-2

references: SI-2, MA-1(b), 1227, 1233,

Software Integrity Checkinggroup

Both the AIDE (Advanced Intrusion Detection Environment) software and the RPM package management system provide mechanisms for verifying the integrity of installed software. AIDE uses snapshots of file metadata (such as hashes) and compares these to current system files in order to detect changes. The RPM package management system can conduct integrity checks by comparing information in its metadata database with files installed on the system.

Integrity checking cannot prevent intrusions, but can detect that they have occurred. Requirements for software integrity checking may be highly dependent on the environment in which the system will be used. Snapshot-based approaches such as AIDE may induce considerable overhead in the presence of frequent software updates.

contains 3 rules

Verify Integrity with AIDEgroup

AIDE conducts integrity checks by comparing information about files with previously-gathered information. Ideally, the AIDE database is created immediately after initial system configuration, and then again after any software update. AIDE is highly configurable, with further configuration information located in /usr/share/doc/aide-VERSION.

contains 1 rule

Install AIDErule

Install the AIDE package with the command:

# yum install aide

identifiers: CCE-27024-9

references: CM-3(d), CM-3(e), CM-6(d), SC-28, SI-7, 1069,

Remediation script:

yum -y install aide

Verify Integrity with RPMgroup

The RPM package management system includes the ability to verify the integrity of installed packages by comparing the installed files with information about the files taken from the package metadata stored in the RPM database. Although an attacker could corrupt the RPM database (analogous to attacking the AIDE database as described above), this check can still reveal modification of important files. To list which files on the system differ from what is expected by the RPM database:

# rpm -qVa

See the man page for rpm to see a complete explanation of each column.

contains 2 rules

Verify and Correct File Permissions with RPMrule

The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. After locating a file with incorrect permissions, run the following command to determine which package owns it:

# rpm -qf FILENAME

Next, run the following command to reset its permissions to the correct values:

# rpm --setperms PACKAGENAME

identifiers: CCE-26731-0

references: AC-6, CM-6(d), SI-7, 1493, 1494, 1495

Verify File Hashes with RPMrule

The RPM package management system can check the hashes of installed software packages, including many that are important to system security. Run the following command to list which files on the system have hashes that differ from what is expected by the RPM database:

# rpm -Va | grep '^..5'

A "c" in the second column indicates that a file is a configuration file, which may appropriately be expected to change. If the file was not expected to change, investigate the cause of the change using audit logs or other means. The package can then be reinstalled to restore the file. Run the following command to determine which package owns the file:

# rpm -qf FILENAME

The package can be reinstalled from a yum repository using the command:

yum reinstall PACKAGENAME

Alternatively, the package can be reinstalled from trusted media using the command:

rpm -Uvh PACKAGENAME

identifiers: CCE-27223-7

references: CM-6(d), SI-7, 1496

Additional Security Softwaregroup

Additional security software that is not provided or supported by Red Hat can be installed to provide complementary or duplicative security capabilities to those provided by the base platform. Add-on software may not be appropriate for some specialized systems.

File Permissions and Masksgroup

Traditional Unix security relies heavily on file and directory permissions to prevent unauthorized users from reading or modifying files to which they should not have access.

Several of the commands in this section search filesystems for files or directories with certain characteristics, and are intended to be run on every local partition on a given system. When the variable PART appears in one of the commands below, it means that the command is intended to be run repeatedly, with the name of each local partition substituted for PART in turn.

The following command prints a list of all ext4 partitions on the local system, which is the default filesystem for Red Hat Enterprise Linux 6 installations:

$ mount -t ext4 | awk '{print $3}'

For any systems that use a different local filesystem type, modify this command as appropriate.

contains 44 rules

Restrict Partition Mount Optionsgroup

System partitions can be mounted with certain options that limit what files on those partitions can do. These options are set in the /etc/fstab configuration file, and can be used to make certain types of malicious behavior more difficult.

contains 11 rules

Add nodev Option to Non-Root Local Partitionsrule

The nodev mount option prevents files from being interpreted as character or block devices. Legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of any non-root local partitions.

identifiers: CCE-27045-4

references: CM-7

Add nodev Option to Removable Media Partitionsrule

identifiers: CCE-26860-7

references: AC-19(a), AC-19(d), AC-19(e), CM-7, MP-2

Add noexec Option to Removable Media Partitionsrule

The noexec mount option prevents the direct execution of binaries on the mounted filesystem. Preventing the direct execution of binaries from removable media (such as a USB key) provides a defense against malicious software that may be present on such untrusted media. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of any removable media partitions.

identifiers: CCE-27196-5

references: AC-19(a), AC-19(d), AC-19(e), CM-7, MP-2, 87

Add nosuid Option to Removable Media Partitionsrule

The nosuid mount option prevents set-user-identifier (SUID) and set-group-identifier (SGID) permissions from taking effect. These permissions allow users to execute binaries with the same permissions as the owner and group of the file respectively. Users should not be allowed to introduce SUID and SGID files into the system via partitions mounted from removeable media. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of any removable media partitions.

identifiers: CCE-27056-1

references: AC-19(a), AC-19(d), AC-19(e), CM-7, MP-2

Add nodev Option to /tmprule

The nodev mount option can be used to prevent device files from being created in /tmp. Legitimate character and block devices should not exist within temporary directories like /tmp. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of /tmp.

identifiers: CCE-26499-4

references: CM-7, MP-2

Add noexec Option to /tmprule

The noexec mount option can be used to prevent binaries from being executed out of /tmp. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of /tmp.

identifiers: CCE-26720-3

references: CM-7, MP-2

Add nosuid Option to /tmprule

The nosuid mount option can be used to prevent execution of setuid programs in /tmp. The SUID and SGID permissions should not be required in these world-writable directories. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of /tmp.

identifiers: CCE-26762-5

references: CM-7, MP-2

Add nodev Option to /dev/shmrule

The nodev mount option can be used to prevent creation of device files in /dev/shm. Legitimate character and block devices should not exist within temporary directories like /dev/shm. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of /dev/shm.

identifiers: CCE-26778-1

references: CM-7, MP-2

Add noexec Option to /dev/shmrule

The noexec mount option can be used to prevent binaries from being executed out of /dev/shm. It can be dangerous to allow the execution of binaries from world-writable temporary storage directories such as /dev/shm. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of /dev/shm.

identifiers: CCE-26622-1

references: CM-7, MP-2

Add nosuid Option to /dev/shmrule

The nosuid mount option can be used to prevent execution of setuid programs in /dev/shm. The SUID and SGID permissions should not be required in these world-writable directories. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of /dev/shm.

identifiers: CCE-26486-1

references: CM-7, MP-2

Bind Mount /var/tmp To /tmprule

The /var/tmp directory is a world-writable directory. Bind-mount it to /tmp in order to consolidate temporary storage into one location protected by the same techniques as /tmp. To do so, edit /etc/fstab and add the following line:

/tmp     /var/tmp     none     rw,nodev,noexec,nosuid,bind     0 0

See the mount(8) man page for further explanation of bind mounting.

identifiers: CCE-26582-7

references: CM-7

Restrict Dynamic Mounting and Unmounting of Filesystemsgroup

Linux includes a number of facilities for the automated addition and removal of filesystems on a running system. These facilities may be necessary in many environments, but this capability also carries some risk -- whether direct risk from allowing users to introduce arbitrary filesystems, or risk that software flaws in the automated mount facility itself could allow an attacker to compromise the system.

This command can be used to list the types of filesystems that are available to the currently executing kernel:

# find /lib/modules/`uname -r`/kernel/fs -type f -name '*.ko'

If these filesystems are not required then they can be explicitly disabled in a configuratio file in /etc/modprobe.d.

contains 8 rules

Disable the Automounterrule

The autofs daemon mounts and unmounts filesystems, such as user home directories shared via NFS, on demand. In addition, autofs can be used to handle removable media, and the default configuration provides the cdrom device as /misc/cd. However, this method of providing access to removable media is not common, so autofs can almost always be disabled if NFS is not in use. Even if NFS is required, it may be possible to configure filesystem mounts statically by editing /etc/fstab rather than relying on the automounter.

The autofs service can be disabled with the following command: # chkconfig autofs off

identifiers: CCE-26976-1

references: AC-19(a), AC-19(d), AC-19(e), 1250, 85

Remediation script:

#
# Disable autofs for all run levels
#
chkconfig --level 0123456 autofs off

#
# Stop autofs if currently running
#
service autofs stop

Disable Mounting of cramfsrule

To configure the system to prevent the cramfs kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d: install cramfs /bin/false This effectively prevents usage of this uncommon filesystem.

identifiers: CCE-26340-0

references: CM-7

Remediation script:

echo "install cramfs /bin/false" > /etc/modprobe.d/cramfs.conf

Disable Mounting of freevxfsrule

To configure the system to prevent the freevxfs kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d: install freevxfs /bin/false This effectively prevents usage of this uncommon filesystem.

identifiers: CCE-26544-7

references: CM-7

Remediation script:

echo "install freevxfs /bin/false" > /etc/modprobe.d/freevxfs.conf

Disable Mounting of jffs2rule

To configure the system to prevent the jffs2 kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d: install jffs2 /bin/false This effectively prevents usage of this uncommon filesystem.

identifiers: CCE-26670-0

references: CM-7

Remediation script:

echo "install jffs2 /bin/false" > /etc/modprobe.d/jffs2.conf

Disable Mounting of hfsrule

To configure the system to prevent the hfs kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d: install hfs /bin/false This effectively prevents usage of this uncommon filesystem.

identifiers: CCE-26800-3

references: CM-7

Remediation script:

echo "install hfs /bin/false" > /etc/modprobe.d/hfs.conf

Disable Mounting of hfsplusrule

To configure the system to prevent the hfsplus kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d: install hfsplus /bin/false This effectively prevents usage of this uncommon filesystem.

identifiers: CCE-26361-6

references: CM-7

Remediation script:

echo "install hfsplus /bin/false" > /etc/modprobe.d/hfsplus.conf

Disable Mounting of squashfsrule

To configure the system to prevent the squashfs kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d: install squashfs /bin/false This effectively prevents usage of this uncommon filesystem.

identifiers: CCE-26404-4

references: CM-7

Remediation script:

echo "install squashfs /bin/false" > /etc/modprobe.d/squashfs.conf

Disable Mounting of udfrule

To configure the system to prevent the udf kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d: install udf /bin/false This effectively prevents usage of this uncommon filesystem.

identifiers: CCE-26677-5

references: CM-7

Remediation script:

echo "install udf /bin/false" > /etc/modprobe.d/udf.conf

Verify Permissions on Important Files and Directoriesgroup

Permissions for many files on a system must be set restrictively to ensure sensitive information is properly protected. This section discusses important permission restrictions which can be verified to ensure that no harmful discrepancies have arisen.

contains 19 rules

Verify Permissions on Files with Local Account Information and Credentialsgroup

The default restrictive permissions for files which act as important security databases such as passwd, shadow, group, and gshadow files must be maintained. Many utilities need read access to the passwd file in order to function properly, but read access to the shadow file allows malicious attacks against system passwords, and should never be enabled.

contains 12 rules

Verify User Who Owns shadow Filerule

To properly set the owner of /etc/shadow, run the command: # chown root /etc/shadow

identifiers: CCE-26947-2

references: AC-6, 225,

Remediation script:

chown root /etc/shadow

Verify Group Who Owns shadow Filerule

To properly set the group owner of /etc/shadow, run the command: # chgrp root /etc/shadow

identifiers: CCE-26967-0

references: AC-6, 225,

Remediation script:

chgrp root /etc/shadow

Verify Permissions on shadow Filerule

To properly set the permissions of /etc/shadow, run the command: # chmod 0000 /etc/shadow

identifiers: CCE-26992-8

references: AC-6, 225,

Remediation script:

chmod 0000 /etc/shadow

Verify User Who Owns group Filerule

To properly set the owner of /etc/group, run the command: # chown root /etc/group

identifiers: CCE-26822-7

references: AC-6,

Verify Group Who Owns group Filerule

To properly set the group owner of /etc/group, run the command: # chgrp root /etc/group

identifiers: CCE-26930-8

references: AC-6, 225,

Verify Permissions on group Filerule

To properly set the permissions of /etc/group, run the command: # chmod 644 /etc/group

identifiers: CCE-26954-8

references: AC-6, 225,

Verify User Who Owns gshadow Filerule

To properly set the owner of /etc/gshadow, run the command: # chown root /etc/gshadow

identifiers: CCE-27026-4

references: AC-6, 225,

Verify Group Who Owns gshadow Filerule

To properly set the group owner of /etc/gshadow, run the command: # chgrp root /etc/gshadow

identifiers: CCE-26975-3

references: AC-6, 225,

Verify Permissions on gshadow Filerule

To properly set the permissions of /etc/gshadow, run the command: # chmod 0000 /etc/gshadow

identifiers: CCE-26951-4

references: AC-6, 225,

Verify User Who Owns passwd Filerule

To properly set the owner of /etc/passwd, run the command: # chown root /etc/passwd

identifiers: CCE-26953-0

references: AC-6, 225,

Verify Group Who Owns passwd Filerule

To properly set the group owner of /etc/passwd, run the command: # chgrp root /etc/passwd

identifiers: CCE-26856-5

references: AC-6, 225,

Verify Permissions on passwd Filerule

To properly set the permissions of /etc/passwd, run the command: # chmod 0644 /etc/passwd

identifiers: CCE-26868-0

references: AC-6, 225,

Verify File Permissions Within Some Important Directoriesgroup

Some directories contain files whose confidentiality or integrity is notably important and may also be susceptible to misconfiguration over time, particularly if unpackaged software is installed. As such, an argument exists to verify that files' permissions within these directories remain configured correctly and restrictively.

Verify that All World-Writable Directories Have Sticky Bits Setrule

When the so-called 'sticky bit' is set on a directory, only the owner of a given file may remove that file from the directory. Without the sticky bit, any user with write access to a directory may remove any file in the directory. Setting the sticky bit prevents users from removing each other's files. In cases where there is no reason for a directory to be world-writable, a better solution is to remove that permission rather than to set the sticky bit. However, if a directory is used by a particular application, consult that application's documentation instead of blindly changing modes.

To set the sticky bit on a world-writable directory DIR, run the following command:

# chmod +t DIR

identifiers: CCE-26840-9

references: AC-6,

Remediation script:

df --local -P | awk {'if (NR!=1) print $6'} \
| xargs -I '{}' find '{}' -xdev -type d \
\( -perm -0002 -a ! -perm -1000 \) 2>/dev/null \
| xargs chmod a+t

Ensure No World-Writable Files Existrule

It is generally a good idea to remove global (other) write access to a file when it is discovered. However, check with documentation for specific applications before making changes. Also, monitor for recurring world-writable files, as these may be symptoms of a misconfigured application or user account.

identifiers: CCE-26910-0

references: AC-6

Ensure All SGID Executables Are Authorizedrule

The SGID (set group id) bit should be set only on files that were installed via authorized means. A straightforward means of identifying unauthorized SGID files is determine if any were not installed as part of an RPM package, which is cryptographically verified. Investigate the origin of any unpackaged SGID files.

identifiers: CCE-26769-0

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf

Ensure All SUID Executables Are Authorizedrule

The SUID (set user id) bit should be set only on files that were installed via authorized means. A straightforward means of identifying unauthorized SGID files is determine if any were not installed as part of an RPM package, which is cryptographically verified. Investigate the origin of any unpackaged SUID files.

identifiers: CCE-26497-8

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf

Ensure All Files Are Owned by a Userrule

If any files are not owned by a user, then the cause of their lack of ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate user.

identifiers: CCE-27032-2

references: AC-6, 224

Ensure All Files Are Owned by a Grouprule

If any files are not owned by a group, then the cause of their lack of group-ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate group.

identifiers: CCE-26872-2

references: AC-6, 224

Ensure All World-Writable Directories Are Owned by a System Accountrule

All directories in local partitions which are world-writable should be owned by root or another system account. If any world-writable directories are not owned by a system account, this should be investigated. Following this, the files should be deleted or assigned to an appropriate group.

identifiers: CCE-26642-9

references: AC-6,

Restrict Programs from Dangerous Execution Patternsgroup

The recommendations in this section are designed to ensure that the system's features to protect against potentially dangerous program execution are activated. These protections are applied at the system initialization or kernel level, and defend against certain types of badly-configured or compromised programs.

contains 6 rules

Daemon Umaskgroup

The umask is a per-process setting which limits the default permissions for creation of new files and directories. The system includes initialization scripts which set the default umask for system daemons.

contains 1 rule

Set Daemon Umaskrule

The file /etc/init.d/functions includes initialization parameters for most or all daemons started at boot time. The default umask of 022 prevents creation of group- or world-writable files. To set the default umask for daemons, edit the following line, inserting 022 or 027 for UMASK appropriately:

umask UMASK

Setting the umask to too restrictive a setting can cause serious errors at runtime. Many daemons on the system already individually restrict themselves to a umask of 077 in their own init scripts.

identifiers: CCE-27031-4

references: AC-6

Remediation script:

var_umask_for_daemons=""
grep -q ^umask /etc/init.d/functions && \
  sed -i "s/umask.*/umask $var_umask_for_daemons/g" /etc/init.d/functions
if ! [ $? -eq 0 ]; then
    echo "umask $var_umask_for_daemons" >> /etc/init.d/functions
fi

Disable Core Dumpsgroup

A core dump file is the memory image of an executable program when it was terminated by the operating system due to errant behavior. In most cases, only software developers legitimately need to access these files. The core dump files may also contain sensitive information, or unnecessarily occupy large amounts of disk space.

Once a hard limit is set in /etc/security/limits.conf, a user cannot increase that limit within his or her own session. If access to core dumps is required, consider restricting them to only certain users or groups. See the limits.conf man page for more information.

The core dumps of setuid programs are further protected. The sysctl variable fs.suid_dumpable controls whether the kernel allows core dumps from these programs at all. The default value of 0 is recommended.

contains 2 rules

Disable Core Dumps for All Usersrule

To disable core dumps for all users, add the following line to /etc/security/limits.conf:

*     hard   core    0

identifiers: CCE-27033-0

references: SC-5

Remediation script:

echo "*     hard   core    0" >> /etc/security/limits.conf

Disable Core Dumps for SUID programsrule

To set the runtime status of the fs.suid_dumpable kernel parameter, run the following command: # sysctl -w fs.suid_dumpable=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: fs.suid_dumpable = 0

identifiers: CCE-27044-7

references: SI-11

Remediation script:

#
# Set runtime for fs.suid_dumpable
#
sysctl -q -n -w fs.suid_dumpable=0

#
# If fs.suid_dumpable present in /etc/sysctl.conf, change value to "0"
#	else, add "fs.suid_dumpable = 0" to /etc/sysctl.conf
#
if grep --silent ^fs.suid_dumpable /etc/sysctl.conf ; then
	sed -i 's/^fs.suid_dumpable.*/fs.suid_dumpable = 0/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set fs.suid_dumpable to 0 per security requirements" >> /etc/sysctl.conf
	echo "fs.suid_dumpable = 0" >> /etc/sysctl.conf
fi

Enable ExecShieldgroup

ExecShield describes kernel features that provide protection against exploitation of memory corruption errors such as buffer overflows. These features include random placement of the stack and other memory regions, prevention of execution in memory that should only hold data, and special handling of text buffers. These protections are enabled by default and controlled through sysctl variables kernel.exec-shield and kernel.randomize_va_space.

contains 2 rules

Enable ExecShieldrule

To set the runtime status of the kernel.exec-shield kernel parameter, run the following command: # sysctl -w kernel.exec-shield=1 If this is not the system's default value, add the following line to /etc/sysctl.conf: kernel.exec-shield = 1

identifiers: CCE-27007-4

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf,

Remediation script:

#
# Set runtime for kernel.exec-shield
#
sysctl -q -n -w kernel.exec-shield=1

#
# If kernel.exec-shield present in /etc/sysctl.conf, change value to "1"
#	else, add "kernel.exec-shield = 1" to /etc/sysctl.conf
#
if grep --silent ^kernel.exec-shield /etc/sysctl.conf ; then
	sed -i 's/^kernel.exec-shield.*/kernel.exec-shield = 1/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set kernel.exec-shield to 1 per security requirements" >> /etc/sysctl.conf
	echo "kernel.exec-shield = 1" >> /etc/sysctl.conf
fi

Enable Randomized Layout of Virtual Address Spacerule

To set the runtime status of the kernel.randomize_va_space kernel parameter, run the following command: # sysctl -w kernel.randomize_va_space=2 If this is not the system's default value, add the following line to /etc/sysctl.conf: kernel.randomize_va_space = 2

identifiers: CCE-26999-3

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf,

Remediation script:

#
# Set runtime for kernel.randomize_va_space
#
sysctl -q -n -w kernel.randomize_va_space=2

#
# If kernel.randomize_va_space present in /etc/sysctl.conf, change value to "2"
#	else, add "kernel.randomize_va_space = 2" to /etc/sysctl.conf
#
if grep --silent ^kernel.randomize_va_space /etc/sysctl.conf ; then
	sed -i 's/^kernel.randomize_va_space.*/kernel.randomize_va_space = 2/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set kernel.randomize_va_space to 2 per security requirements" >> /etc/sysctl.conf
	echo "kernel.randomize_va_space = 2" >> /etc/sysctl.conf
fi

Enable Execute Disable (XD) or No Execute (NX) Support on x86 Systemsgroup

Recent processors in the x86 family support the ability to prevent code execution on a per memory page basis. Generically and on AMD processors, this ability is called No Execute (NX), while on Intel processors it is called Execute Disable (XD). This ability can help prevent exploitation of buffer overflow vulnerabilities and should be activated whenever possible. Extra steps must be taken to ensure that this protection is enabled, particularly on 32-bit x86 systems. Other processors, such as Itanium and POWER, have included such support since inception and the standard kernel for those platforms supports the feature.

contains 1 rule

Install PAE Kernel on Supported 32-bit x86 Systemsrule

Systems that are using the 64-bit x86 kernel package do not need to install the kernel-PAE package because the 64-bit x86 kernel already includes this support. However, if the system is 32-bit and also supports the PAE and NX features as determined in the previous section, the kernel-PAE package should be installed to enable XD or NX support:

# yum install kernel-PAE

The installation process should also have configured the bootloader to load the new kernel at boot. Verify this at reboot and modify /etc/grub.conf if necessary.

identifiers: CCE-27010-8

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf

SELinuxgroup

SELinux is a feature of the Linux kernel which can be used to guard against misconfigured or compromised programs. SELinux enforces the idea that programs should be limited in what files they can access and what actions they can take.

The default SELinux policy, as configured on RHEL 6, has been sufficiently developed and debugged that it should be usable on almost any Red Hat machine with minimal configuration and a small amount of system administrator training. This policy prevents system services - including most of the common network-visible services such as mail servers, FTP servers, and DNS servers - from accessing files which those services have no valid reason to access. This action alone prevents a huge amount of possible damage from network attacks against services, from trojaned software, and so forth.

This guide recommends that SELinux be enabled using the default (targeted) policy on every Red Hat system, unless that system has unusual requirements which make a stronger policy appropriate.

contains 5 rules

Ensure SELinux Not Disabled in /etc/grub.confrule

SELinux can be disabled at boot time by an argument in /etc/grub.conf. Remove any instances of selinux=0 from the kernel arguments in that file to prevent SELinux from being disabled at boot.

identifiers: CCE-26956-3

references: AC-3, AC-3(3), AC-6, AU-9, 22, 32,

Remediation script:

sed -i "s/selinux=0//gI" /etc/grub.conf
sed -i "s/enforcing=0//gI" /etc/grub.conf

Ensure SELinux State is Enforcingrule

The SELinux state should be set to enforcing at system boot time. In the file /etc/selinux/config, add or correct the following line to configure the system to boot into enforcing mode:

SELINUX=enforcing

identifiers: CCE-26969-6

references: AC-3, AC-3(3), AC-4, AC-6, AU-9, 22, 32, 26,

Remediation script:

var_selinux_state=""
grep -q ^SELINUX= /etc/selinux/config && \
  sed -i "s/SELINUX=.*/SELINUX=$var_selinux_state/g" /etc/selinux/config
if ! [ $? -eq 0 ]; then
    echo "SELINUX=$var_selinux_state" >> /etc/selinux/config
fi

Configure SELinux Policyrule

The SELinux targeted policy is appropriate for general-purpose desktops and servers, as well as systems in many other roles. To configure the system to use this policy, add or correct the following line in /etc/selinux/config:

SELINUXTYPE=targeted

Other policies, such as mls, provide additional security labeling and greater confinement but are not compatible with many general-purpose use cases.

identifiers: CCE-26875-5

references: AC-3, AC-3(3), AC-4, AC-6, AU-9, 22, 32,

Remediation script:

var_selinux_policy_name=""
grep -q ^SELINUXTYPE /etc/selinux/config && \
  sed -i "s/SELINUXTYPE=.*/SELINUXTYPE=$var_selinux_policy_name/g" /etc/selinux/config
if ! [ $? -eq 0 ]; then
    echo "SELINUXTYPE=$var_selinux_policy_name" >> /etc/selinux/config
fi

Ensure No Daemons are Unconfined by SELinuxrule

Daemons for which the SELinux policy does not contain rules will inherit the context of the parent process. Because daemons are launched during startup and descend from the init process, they inherit the initrc_t context.

To check for unconfined daemons, run the following command:

# ps -eZ | egrep "initrc" | egrep -vw "tr|ps|egrep|bash|awk" | tr ':' ' ' | awk '{ print $NF }'

It should produce no output in a well-configured system.

identifiers: CCE-27111-4

references: AC-6, AU-9, CM-7

Ensure No Device Files are Unlabeled by SELinuxrule

Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device files carry the SELinux type unlabeled_t, investigate the cause and correct the file's context.

identifiers: CCE-26774-0

references: AC-6, AU-9, CM-7, 22, 32,

Account and Access Controlgroup

In traditional Unix security, if an attacker gains shell access to a certain login account, they can perform any action or access any file to which that account has access. Therefore, making it more difficult for unauthorized people to gain shell access to accounts, particularly to privileged accounts, is a necessary part of securing a system. This section introduces mechanisms for restricting access to accounts under RHEL 6.

contains 37 rules

Protect Accounts by Restricting Password-Based Logingroup

Conventionally, Unix shell accounts are accessed by providing a username and password to a login program, which tests these values for correctness using the /etc/passwd and /etc/shadow files. Password-based login is vulnerable to guessing of weak passwords, and to sniffing and man-in-the-middle attacks against passwords entered over a network or at an insecure console. Therefore, mechanisms for accessing accounts by entering usernames and passwords should be restricted to those which are operationally necessary.

contains 9 rules

Restrict Root Loginsgroup

Direct root logins should be allowed only for emergency use. In normal situations, the administrator should access the system via a unique unprivileged account, and then use su or sudo to execute privileged commands. Discouraging administrators from accessing the root account directly ensures an audit trail in organizations with multiple administrators. Locking down the channels through which root can connect directly also reduces opportunities for password-guessing against the root account. The login program uses the file /etc/securetty to determine which interfaces should allow root logins. The virtual devices /dev/console and /dev/tty* represent the system consoles (accessible via the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default installation). The default securetty file also contains /dev/vc/*. These are likely to be deprecated in most environments, but may be retained for compatibility. Root should also be prohibited from connecting via network protocols. Other sections of this document include guidance describing how to prevent root from logging in via SSH.

contains 3 rules

Restrict Virtual Console Root Loginsrule

To restrict root logins through the (deprecated) virtual console devices, ensure lines of this form do not appear in /etc/securetty:

vc/1
vc/2
vc/3
vc/4

identifiers: CCE-26855-7

references: AC-6(2), 770,

Remediation script:

sed -i '/^vc\//d' /etc/securetty

Restrict Serial Port Root Loginsrule

To restrict root logins on serial ports, ensure lines of this form do not appear in /etc/securetty:

ttyS0
ttyS1

identifiers: CCE-27047-0

references: AC-6(2), 770,

Verify Only Root Has UID 0rule

If any account other than root has a UID of 0, this misconfiguration should be investigated and the accounts other than root should be removed or have their UID changed.

identifiers: CCE-26971-2

references: AC-6, IA-2(1), 366,

Remediation script:

awk -F: '$3 == 0 && $1 != "root" { print $1 }' /etc/passwd | xargs passwd -l

Verify Proper Storage and Existence of Password Hashesgroup

By default, password hashes for local accounts are stored in the second field (colon-separated) in /etc/shadow. This file should be readable only by processes running with root credentials, preventing users from casually accessing others' password hashes and attempting to crack them. However, it remains possible to misconfigure the system and store password hashes in world-readable files such as /etc/passwd, or to even store passwords themselves in plaintext on the system. Using system-provided tools for password change/creation should allow administrators to avoid such misconfiguration.

contains 2 rules

Prevent Log In to Accounts With Empty Passwordrule

If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. Remove any instances of the nullok option in /etc/pam.d/system-auth to prevent logins with empty passwords.

identifiers: CCE-27038-9

references: IA-5(b), IA-5(c), IA-5(1)(a),

Remediation script:

sed --follow-symlinks -i 's/\<nullok\>//g' /etc/pam.d/system-auth

Verify All Account Password Hashes are Shadowedrule

If any password hashes are stored in /etc/passwd (in the second field, instead of an x), the cause of this misconfiguration should be investigated. The account should have its password reset and the hash should be properly stored, or the account should be deleted entirely.

identifiers: CCE-26476-2

references: IA-5(h), 201,

Set Password Expiration Parametersgroup

The file /etc/login.defs controls several password-related settings. Programs such as passwd, su, and login consult /etc/login.defs to determine behavior with regard to password aging, expiration warnings, and length. See the man page login.defs(5) for more information.

Users should be forced to change their passwords, in order to decrease the utility of compromised passwords. However, the need to change passwords often should be balanced against the risk that users will reuse or write down passwords if forced to change them too often. Forcing password changes every 90-360 days, depending on the environment, is recommended. Set the appropriate value as PASS_MAX_DAYS and apply it to existing accounts with the -M flag.

The PASS_MIN_DAYS (-m) setting prevents password changes for 7 days after the first change, to discourage password cycling. If you use this setting, train users to contact an administrator for an emergency password change in case a new password becomes compromised. The PASS_WARN_AGE (-W) setting gives users 7 days of warnings at login time that their passwords are about to expire.

For example, for each existing human user USER, expiration parameters could be adjusted to a 180 day maximum password age, 7 day minimum password age, and 7 day warning period with the following command:

# chage -M 180 -m 7 -W 7 USER

contains 3 rules

Set Password Minimum Length in login.defsrule

To specify password length requirements for new accounts, edit the file /etc/login.defs and add or correct the following lines:

PASS_MIN_LEN 14

The DoD requirement is 14. The FISMA requirement is 12. If a program consults /etc/login.defs and also another PAM module (such as pam_cracklib) during a password change operation, then the most restrictive must be satisfied. See PAM section for more information about enforcing password quality requirements.

identifiers: CCE-27002-5

references: IA-5(f), IA-5(1)(a), 205,

Remediation script:

var_accounts_password_minlen_login_defs=""
grep -q ^PASS_MIN_LEN /etc/login.defs && \
  sed -i "s/PASS_MIN_LEN.*/PASS_MIN_LEN     $var_accounts_password_minlen_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]; then
    echo "PASS_MIN_LEN      $var_accounts_password_minlen_login_defs" >> /etc/login.defs
fi

Set Password Maximum Agerule

To specify password maximum age for new accounts, edit the file /etc/login.defs and add or correct the following line, replacing DAYS appropriately:

PASS_MAX_DAYS DAYS

A value of 180 days is sufficient for many environments. The DoD requirement is 60.

identifiers: CCE-26985-2

references: IA-5(f), IA-5(g), IA-5(1)(d), 180, 199,

Remediation script:

var_accounts_maximum_age_login_defs=""
grep -q ^PASS_MAX_DAYS /etc/login.defs && \
  sed -i "s/PASS_MAX_DAYS.*/PASS_MAX_DAYS     $var_accounts_maximum_age_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]; then
    echo "PASS_MAX_DAYS      $var_accounts_maximum_age_login_defs" >> /etc/login.defs
fi

Set Password Warning Agerule

To specify how many days prior to password expiration that a warning will be issued to users, edit the file /etc/login.defs and add or correct the following line, replacing DAYS appropriately:

PASS_WARN_AGE DAYS

The DoD requirement is 7.

identifiers: CCE-26988-6

references: IA-5(f),

Remediation script:

var_accounts_password_warn_age_login_defs=""
grep -q ^PASS_WARN_AGE /etc/login.defs && \
  sed -i "s/PASS_WARN_AGE.*/PASS_WARN_AGE     $var_accounts_password_warn_age_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]; then
    echo "PASS_WARN_AGE      $var_accounts_password_warn_age_login_defs" >> /etc/login.defs
fi

Set Account Expiration Parametersgroup

Accounts can be configured to be automatically disabled after a certain time period, meaning that they will require administrator interaction to become usable again. Expiration of accounts after inactivity can be set for all accounts by default and also on a per-account basis, such as for accounts that are known to be temporary. To configure automatic expiration of an account following the expiration of its password (that is, after the password has expired and not been changed), run the following command, substituting NUM_DAYS and USER appropriately:

# chage -I NUM_DAYS USER

Accounts, such as temporary accounts, can also be configured to expire on an explicitly-set date with the -E option. The file /etc/default/useradd controls default settings for all newly-created accounts created with the system's normal command line utilities.

contains 1 rule

Set Account Expiration Following Inactivityrule

To specify the number of days after a password expires (which signifies inactivity) until an account is permanently disabled, add or correct the following lines in /etc/default/useradd, substituting NUM_DAYS appropriately:

INACTIVE=NUM_DAYS

A value of 35 is recommended. If a password is currently on the verge of expiration, then 35 days remain until the account is automatically disabled. However, if the password will not expire for another 60 days, then 95 days could elapse until the account would be automatically disabled. See the useradd man page for more information. Determining the inactivity timeout must be done with careful consideration of the length of a "normal" period of inactivity for users in the particular environment. Setting the timeout too low incurs support costs and also has the potential to impact availability of the system to legitimate users.

identifiers: CCE-27283-1

references: AC-2(2), AC-2(3), 16, 17, 795

Remediation script:

var_account_disable_post_pw_expiration=""
grep -q ^INACTIVE /etc/default/useradd && \
  sed -i "s/INACTIVE.*/INACTIVE=$var_account_disable_post_pw_expiration/g" /etc/default/useradd
if ! [ $? -eq 0 ]; then
    echo "INACTIVE=$var_account_disable_post_pw_expiration" >> /etc/default/useradd
fi

Protect Accounts by Configuring PAMgroup

PAM, or Pluggable Authentication Modules, is a system which implements modular authentication for Linux programs. PAM provides a flexible and configurable architecture for authentication, and it should be configured to minimize exposure to unnecessary risk. This section contains guidance on how to accomplish that.

PAM is implemented as a set of shared objects which are loaded and invoked whenever an application wishes to authenticate a user. Typically, the application must be running as root in order to take advantage of PAM, because PAM's modules often need to be able to access sensitive stores of account information, such as /etc/shadow. Traditional privileged network listeners (e.g. sshd) or SUID programs (e.g. sudo) already meet this requirement. An SUID root application, userhelper, is provided so that programs which are not SUID or privileged themselves can still take advantage of PAM.

PAM looks in the directory /etc/pam.d for application-specific configuration information. For instance, if the program login attempts to authenticate a user, then PAM's libraries follow the instructions in the file /etc/pam.d/login to determine what actions should be taken.

One very important file in /etc/pam.d is /etc/pam.d/system-auth. This file, which is included by many other PAM configuration files, defines 'default' system authentication measures. Modifying this file is a good way to make far-reaching authentication changes, for instance when implementing a centralized authentication service.

contains 10 rules

Set Password Quality Requirementsgroup

The default pam_cracklib PAM module provides strength checking for passwords. It performs a number of checks, such as making sure passwords are not similar to dictionary words, are of at least a certain length, are not the previous password reversed, and are not simply a change of case from the previous password. It can also require passwords to be in certain character classes.

The pam_passwdqc PAM module also provides the ability to enforce stringent password strength requirements. It is provided in an RPM of the same name.

The man pages pam_cracklib(8) and pam_passwdqc(8) provide information on the capabilities and configuration of each.

contains 6 rules

Set Password Quality Requirements, if using pam_cracklibgroup

The pam_cracklib PAM module can be configured to meet requirements for a variety of policies.

For example, to configure pam_cracklib to require at least one uppercase character, lowercase character, digit, and other (special) character, locate the following line in /etc/pam.d/system-auth:

password requisite pam_cracklib.so try_first_pass retry=3

and then alter it to read:

password required pam_cracklib.so try_first_pass retry=3 maxrepeat=3 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 difok=4

If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth. The arguments can be modified to ensure compliance with your organization's security policy. Discussion of each parameter follows.

contains 6 rules

Set Password Retry Prompts Permitted Per-Sessionrule

To configure the number of retry prompts that are permitted per-session:

Edit the pam_cracklib.so statement in /etc/pam.d/system-auth to show retry=3, or a lower value if site policy is more restrictive.

The DoD requirement is a maximum of 3 prompts per session.

identifiers: CCE-27123-9

references: IA-5(c), 1092,

Set Password Strength Minimum Digit Charactersrule

The pam_cracklib module's dcredit parameter controls requirements for usage of digits in a password. When set to a negative number, any password will be required to contain that many digits. When set to a positive number, pam_cracklib will grant +1 additional length credit for each digit. Add dcredit=-1 after pam_cracklib.so to require use of a digit in passwords.

identifiers: CCE-26374-9

references: IA-5(b), IA-5(c), 194, 194,

Remediation script:

var_password_pam_cracklib_dcredit=""
if grep -q "dcredit=" /etc/pam.d/system-auth; then   
	sed -i --follow-symlink "s/\(dcredit *= *\).*/\1$var_password_pam_cracklib_dcredit/" /etc/pam.d/system-auth
else
	sed -i --follow-symlink "/pam_cracklib.so/ s/$/ dcredit=$var_password_pam_cracklib_dcredit/" /etc/pam.d/system-auth
fi

Set Password Strength Minimum Uppercase Charactersrule

The pam_cracklib module's ucredit= parameter controls requirements for usage of uppercase letters in a password. When set to a negative number, any password will be required to contain that many uppercase characters. When set to a positive number, pam_cracklib will grant +1 additional length credit for each uppercase character. Add ucredit=-1 after pam_cracklib.so to require use of an upper case character in passwords.

identifiers: CCE-26601-5

references: IA-5(b), IA-5(c), IA-5(1)(a), 192,

Remediation script:

var_password_pam_cracklib_ucredit=""
if grep -q "ucredit=" /etc/pam.d/system-auth; then   
	sed -i --follow-symlink "s/\(ucredit *= *\).*/\1$var_password_pam_cracklib_ucredit/" /etc/pam.d/system-auth
else
	sed -i --follow-symlink "/pam_cracklib.so/ s/$/ ucredit=$var_password_pam_cracklib_ucredit/" /etc/pam.d/system-auth
fi

Set Password Strength Minimum Special Charactersrule

The pam_cracklib module's ocredit= parameter controls requirements for usage of special (or ``other'') characters in a password. When set to a negative number, any password will be required to contain that many special characters. When set to a positive number, pam_cracklib will grant +1 additional length credit for each special character. Add ocredit=-1 after pam_cracklib.so to require use of a special character in passwords.

identifiers: CCE-26409-3

references: IA-5(b), IA-5(c), IA-5(1)(a), 1619,

Remediation script:

var_password_pam_cracklib_ocredit=""
if grep -q "ocredit=" /etc/pam.d/system-auth; then   
	sed -i --follow-symlink "s/\(ocredit *= *\).*/\1$var_password_pam_cracklib_ocredit/" /etc/pam.d/system-auth
else
	sed -i --follow-symlink "/pam_cracklib.so/ s/$/ ocredit=$var_password_pam_cracklib_ocredit/" /etc/pam.d/system-auth
fi

Set Password Strength Minimum Lowercase Charactersrule

The pam_cracklib module's lcredit= parameter controls requirements for usage of lowercase letters in a password. When set to a negative number, any password will be required to contain that many lowercase characters. When set to a positive number, pam_cracklib will grant +1 additional length credit for each lowercase character. Add lcredit=-1 after pam_cracklib.so to require use of a lowercase character in passwords.

identifiers: CCE-26631-2

references: IA-5(b), IA-5(c), IA-5(1)(a), 193,

Remediation script:

var_password_pam_cracklib_lcredit=""
if grep -q "lcredit=" /etc/pam.d/system-auth; then   
	sed -i --follow-symlink "s/\(lcredit *= *\).*/\1$var_password_pam_cracklib_lcredit/" /etc/pam.d/system-auth
else
	sed -i --follow-symlink "/pam_cracklib.so/ s/$/ lcredit=$var_password_pam_cracklib_lcredit/" /etc/pam.d/system-auth
fi

Set Password Strength Minimum Different Charactersrule

The pam_cracklib module's difok parameter controls requirements for usage of different characters during a password change. Add difok=NUM after pam_cracklib.so to require differing characters when changing passwords, substituting NUM appropriately. The DoD requirement is 4.

identifiers: CCE-26615-5

references: IA-5(b), IA-5(c), IA-5(1)(b), 195,

Remediation script:

var_password_pam_cracklib_difok=""
if grep -q "difok=" /etc/pam.d/system-auth; then   
	sed -i --follow-symlink "s/\(difok *= *\).*/\1$var_password_pam_cracklib_difok/" /etc/pam.d/system-auth
else
	sed -i --follow-symlink "/pam_cracklib.so/ s/$/ difok=$var_password_pam_cracklib_difok/" /etc/pam.d/system-auth
fi

Set Lockouts for Failed Password Attemptsgroup

The pam_faillock PAM module provides the capability to lock out user accounts after a number of failed login attempts. Its documentation is available in /usr/share/doc/pam-VERSION/txts/README.pam_faillock.

contains 2 rules

Set Deny For Failed Password Attemptsrule

To configure the system to lock out accounts after a number of incorrect login attempts using pam_faillock.so:

Add the following lines immediately below the pam_unix.so statement in AUTH section of both /etc/pam.d/system-auth and /etc/pam.d/password-auth:

auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 fail_interval=900

auth required pam_faillock.so authsucc deny=3 unlock_time=604800 fail_interval=900

identifiers: CCE-26844-1

references: AC-7(a), 44

Limit Password Reuserule

Do not allow users to reuse recent passwords. This can be accomplished by using the remember option for the pam_unix PAM module. In the file /etc/pam.d/system-auth, append remember=24 to the line which refers to the pam_unix.so module, as shown:

password sufficient pam_unix.so existing_options remember=24

The DoD and FISMA requirement is 24 passwords.

identifiers: CCE-26741-9

references: IA-5(f), IA-5(1)(e), 200,

Set Password Hashing Algorithmgroup

The system's default algorithm for storing password hashes in /etc/shadow is SHA-512. This can be configured in several locations.

contains 2 rules

Set Password Hashing Algorithm in /etc/pam.d/system-authrule

In /etc/pam.d/system-auth, the password section of the file controls which PAM modules execute during a password change. Set the pam_unix.so module in the password section to include the argument sha512, as shown below:

password    sufficient    pam_unix.so sha512 other arguments...

This will help ensure when local users change their passwords, hashes for the new passwords will be generated using the SHA-512 algorithm. This is the default.

identifiers: CCE-26303-8

references: IA-5(b), IA-5(c), IA-5(1)(c), IA-7, 803,

Set Password Hashing Algorithm in /etc/login.defsrule

In /etc/login.defs, add or correct the following line to ensure the system will use SHA-512 as the hashing algorithm:

ENCRYPT_METHOD SHA512

identifiers: CCE-27228-6

references: IA-5(b), IA-5(c), IA-5(1)(c), IA-7, 803,

Secure Session Configuration Files for Login Accountsgroup

When a user logs into a Unix account, the system configures the user's session by reading a number of files. Many of these files are located in the user's home directory, and may have weak permissions as a result of user error or misconfiguration. If an attacker can modify or even read certain types of account configuration information, they can often gain full access to the affected user's account. Therefore, it is important to test and correct configuration file permissions for interactive accounts, particularly those of privileged users such as root or system administrators.

contains 7 rules

Ensure that No Dangerous Directories Exist in Root's Pathgroup

The active path of the root account can be obtained by starting a new root shell and running:

# echo $PATH

This will produce a colon-separated list of directories in the path.

Certain path elements could be considered dangerous, as they could lead to root executing unknown or untrusted programs, which could contain malicious code. Since root may sometimes work inside untrusted directories, the . character, which represents the current directory, should never be in the root path, nor should any directory which can be written to by an unprivileged or semi-privileged (system) user.

It is a good practice for administrators to always execute privileged commands by typing the full path to the command.

contains 2 rules

Ensure that Root's Path Does Not Include Relative Paths or Null Directoriesrule

Ensure that none of the directories in root's path is equal to a single . character, or that it contains any instances that lead to relative path traversal, such as .. or beginning a path without the slash (/) character. Also ensure that there are no "empty" elements in the path, such as in these examples:

PATH=:/bin
PATH=/bin:
PATH=/bin::/sbin

These empty elements have the same effect as a single . character.

identifiers: CCE-26826-8

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf

Ensure that Root's Path Does Not Include World or Group-Writable Directoriesrule

For each element in root's path, run:

# ls -ld DIR

and ensure that write permissions are disabled for group and other.

identifiers: CCE-26768-2

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf

Ensure that Users Have Sensible Umask Valuesgroup

The umask setting controls the default permissions for the creation of new files. With a default umask setting of 077, files and directories created by users will not be readable by any other user on the system. Users who wish to make specific files group- or world-readable can accomplish this by using the chmod command. Additionally, users can make all their files readable to their group by default by setting a umask of 027 in their shell configuration files. If default per-user groups exist (that is, if every user has a default group whose name is the same as that user's username and whose only member is the user), then it may even be safe for users to select a umask of 007, making it very easy to intentionally share files with groups of which the user is a member.

contains 4 rules

Ensure the Default Bash Umask is Set Correctlyrule

To ensure the default umask for users of the Bash shell is set properly, add or correct the umask setting in /etc/bashrc to read as follows:

umask 077

identifiers: CCE-26917-5

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 366,

Remediation script:

var_accounts_user_umask=""
grep -q umask /etc/bashrc && \
  sed -i "s/umask.*/umask $var_accounts_user_umask/g" /etc/bashrc
if ! [ $? -eq 0 ]; then
    echo "umask $var_accounts_user_umask" >> /etc/bashrc
fi

Ensure the Default C Shell Umask is Set Correctlyrule

To ensure the default umask for users of the C shell is set properly, add or correct the umask setting in /etc/csh.cshrc to read as follows:

umask 077

identifiers: CCE-27034-8

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 366,

Remediation script:

var_accounts_user_umask=""
grep -q umask /etc/csh.cshrc && \
  sed -i "s/umask.*/umask $var_accounts_user_umask/g" /etc/csh.cshrc
if ! [ $? -eq 0 ]; then
    echo "umask $var_accounts_user_umask" >> /etc/csh.cshrc
fi

Ensure the Default Umask is Set Correctly in /etc/profilerule

To ensure the default umask controlled by /etc/profile is set properly, add or correct the umask setting in /etc/profile to read as follows:

umask 077

identifiers: CCE-26669-2

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 366,

Remediation script:

var_accounts_user_umask=""
grep -q umask /etc/profile && \
  sed -i "s/umask.*/umask $var_accounts_user_umask/g" /etc/profile
if ! [ $? -eq 0 ]; then
    echo "umask $var_accounts_user_umask" >> /etc/profile
fi

Ensure the Default Umask is Set Correctly in login.defsrule

To ensure the default umask controlled by /etc/login.defs is set properly, add or correct the UMASK setting in /etc/login.defs to read as follows:

UMASK 077

identifiers: CCE-26371-5

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 366,

Remediation script:

var_accounts_user_umask=""
grep -q UMASK /etc/login.defs && \
  sed -i "s/UMASK.*/UMASK $var_accounts_user_umask/g" /etc/login.defs
if ! [ $? -eq 0 ]; then
    echo "UMASK $var_accounts_user_umask" >> /etc/login.defs
fi

Ensure that User Home Directories are not Group-Writable or World-Readablerule

For each human user of the system, view the permissions of the user's home directory:

# ls -ld /home/USER

Ensure that the directory is not group-writable and that it is not world-readable. If necessary, repair the permissions:

# chmod g-w /home/USER
# chmod o-rwx /home/USER

identifiers: CCE-26981-1

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf

Protect Physical Console Accessgroup

It is impossible to fully protect a system from an attacker with physical access, so securing the space in which the system is located should be considered a necessary step. However, there are some steps which, if taken, make it more difficult for an attacker to quickly or undetectably modify a system from its console.

contains 9 rules

Set Boot Loader Passwordgroup

During the boot process, the boot loader is responsible for starting the execution of the kernel and passing options to it. The boot loader allows for the selection of different kernels - possibly on different partitions or media. The default RHEL boot loader for x86 systems is called GRUB. Options it can pass to the kernel include single-user mode, which provides root access without any authentication, and the ability to disable SELinux. To prevent local users from modifying the boot parameters and endangering security, protect the boot loader configuration with a password and ensure its configuration file's permissions are set properly.

contains 4 rules

Verify /etc/grub.conf User Ownershiprule

The file /etc/grub.conf should be owned by the root user to prevent destruction or modification of the file. To properly set the owner of /etc/grub.conf, run the command: # chown root /etc/grub.conf

identifiers: CCE-26995-1

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 225,

Verify /etc/grub.conf Group Ownershiprule

The file /etc/grub.conf should be group-owned by the root group to prevent destruction or modification of the file. To properly set the group owner of /etc/grub.conf, run the command: # chgrp root /etc/grub.conf

identifiers: CCE-27022-3

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 225,

Verify /boot/grub/grub.conf Permissionsrule

File permissions for /boot/grub/grub.conf should be set to 600, which is the default. To properly set the permissions of /boot/grub/grub.conf, run the command: # chmod 600 /boot/grub/grub.conf

identifiers: CCE-26949-8

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 225,

Set Boot Loader Passwordrule

The grub boot loader should have password protection enabled to protect boot-time settings. To do so, select a password and then generate a hash from it by running the following command:

# grub-crypt --sha-512

When prompted to enter a password, insert the following line into /etc/grub.conf immediately after the header comments. (Use the output from grub-crypt as the value of password-hash):

password --encrypted password-hash

NOTE: To meet FISMA Moderate, the bootloader password MUST differ from the root password.

identifiers: CCE-26911-8

references: IA-2(1), IA-5(e), 213,

Configure Screen Lockinggroup

When a user must temporarily leave an account logged-in, screen locking should be employed to prevent passersby from abusing the account. User education and training is particularly important for screen locking to be effective, and policies can be implemented to reinforce this.

Automatic screen locking is only meant as a safeguard for those cases where a user forgot to lock the screen.

contains 4 rules

Configure GUI Screen Lockinggroup

In the default GNOME desktop, the screen can be locked by choosing Lock Screen from the System menu.

The gconftool-2 program can be used to enforce mandatory screen locking settings for the default GNOME environment. The following sections detail commands to enforce idle activation of the screensaver, screen locking, a blank-screen screensaver, and an idle activation time.

Because users should be trained to lock the screen when they step away from the computer, the automatic locking feature is only meant as a backup. The Lock Screen icon from the System menu can also be dragged to the taskbar in order to facilitate even more convenient screen-locking.

The root account cannot be screen-locked, but this should have no practical effect as the root account should never be used to log into an X Windows environment, and should only be used to for direct login via console in emergency circumstances.

For more information about configuring GNOME screensaver, see http://live.gnome.org/GnomeScreensaver. For more information about enforcing preferences in the GNOME environment using the GConf configuration system, see http://projects.gnome.org/gconf and the man page gconftool-2(1).

contains 4 rules

Set GNOME Login Inactivity Timeoutrule

Run the following command to set the idle time-out value for inactivity in the GNOME desktop to 15 minutes:

# gconftool-2 \
  --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --type int \
  --set /desktop/gnome/session/idle_delay 15

identifiers: CCE-26828-4

references: AC-11(a), 57

GNOME Desktop Screensaver Mandatory Userule

Run the following command to activate the screensaver in the GNOME desktop after a period of inactivity:

# gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --type bool \
  --set /apps/gnome-screensaver/idle_activation_enabled true

identifiers: CCE-26600-7

references: AC-11(a), 57

Enable Screen Lock Activation After Idle Periodrule

Run the following command to activate locking of the screensaver in the GNOME desktop when it is activated:

# gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --type bool \
  --set /apps/gnome-screensaver/lock_enabled true

identifiers: CCE-26235-2

references: AC-11(a), 57

Implement Blank Screensaverrule

Run the following command to set the screensaver mode in the GNOME desktop to a blank screen:

# gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --type string \
  --set /apps/gnome-screensaver/mode blank-only

identifiers: CCE-26638-7

references: AC-11(b), 60

Configure Console Screen Lockinggroup

A console screen locking mechanism is provided in the screen package, which is not installed by default.

Hardware Tokens for Authenticationgroup

The use of hardware tokens such as smart cards for system login provides stronger, two-factor authentication than using a username and password. In Red Hat Enterprise Linux servers and workstations, hardware token login is not enabled by default and must be enabled in the system settings.

Disable Interactive Bootrule

To disable the ability for users to perform interactive startups, edit the file /etc/sysconfig/init. Add or correct the line:

PROMPT=no

The PROMPT option allows the console user to perform an interactive system startup, in which it is possible to select the set of services which are started on boot.

identifiers: CCE-27043-9

references: SC-2, 213,

Remediation script:

grep -q ^PROMPT /etc/sysconfig/init && \
  sed -i "s/PROMPT.*/PROMPT=no/g" /etc/sysconfig/init
if ! [ $? -eq 0 ]; then
    echo "PROMPT=no" >> /etc/sysconfig/init
fi

Warning Banners for System Accessesgroup

Each system should expose as little information about itself as possible.

System banners, which are typically displayed just before a login prompt, give out information about the service or the host's operating system. This might include the distribution name and the system kernel version, and the particular version of a network service. This information can assist intruders in gaining access to the system as it can reveal whether the system is running vulnerable software. Most network services can be configured to limit what information is displayed.

Many organizations implement security policies that require a system banner provide notice of the system's ownership, provide warning to unauthorized users, and remind authorized users of their consent to monitoring.

contains 2 rules

Implement a GUI Warning Bannergroup

In the default graphical environment, users logging directly into the system are greeted with a login screen provided by the GNOME Display Manager (GDM). The warning banner should be displayed in this graphical environment for these users. The following sections describe how to configure the GDM login banner.

contains 1 rule

Enable GUI Warning Bannerrule

To enable displaying a login warning banner in the GNOME Display Manager's login screen, run the following command:

sudo gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --type bool \
  --set /apps/gdm/simple-greeter/banner_message_enable true

To display a banner, this setting must be enabled and then banner text must also be set.

identifiers: CCE-27195-7

references: AC-8(a), AC-8(b), AC-8(c), 48, 50

Modify the System Login Bannerrule

To configure the system login banner:

Edit /etc/issue. Replace the default text with a message compliant with the local site policy or a legal disclaimer. The DoD required text is either:

You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions:

-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

-At any time, the USG may inspect and seize data stored on this IS.

-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

-This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy.

-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.

OR:

I've read & consent to terms in IS user agreem't.

identifiers: CCE-26974-6

references: AC-8(a), AC-8(b), AC-8(c), 48, 1384, 1385, 1386, 1387, 1388,

Remediation script:

login_banner_text=""
cat <<EOF >/etc/issue
$login_banner_text
EOF

Network Configuration and Firewallsgroup

Most machines must be connected to a network of some sort, and this brings with it the substantial risk of network attack. This section discusses the security impact of decisions about networking which must be made when configuring a system.

This section also discusses firewalls, network access controls, and other network security frameworks, which allow system-level rules to be written that can limit an attackers' ability to connect to your system. These rules can specify that network traffic should be allowed or denied from certain IP addresses, hosts, and networks. The rules can also specify which of the system's network services are available to particular hosts or networks.

contains 31 rules

Disable Unused Interfacesgroup

Network interfaces expand the attack surface of the system. Unused interfaces are not monitored or controlled, and should be disabled.

If the system does not require network communications but still needs to use the loopback interface, remove all files of the form ifcfg-interface except for ifcfg-lo from /etc/sysconfig/network-scripts:

# rm /etc/sysconfig/network-scripts/ifcfg-interface

If the system is a standalone machine with no need for network access or even communication over the loopback device, then disable this service. The network service can be disabled with the following command: # chkconfig network off

Kernel Parameters Which Affect Networkinggroup

The sysctl utility is used to set parameters which affect the operation of the Linux kernel. Kernel parameters which affect networking and have security implications are described here.

contains 14 rules

Network Parameters for Hosts Onlygroup

If the system is not going to be used as a router, then setting certain kernel parameters ensure that the host will not perform routing of network traffic.

contains 3 rules

Disable Kernel Parameter for Sending ICMP Redirects by Defaultrule

To set the runtime status of the net.ipv4.conf.default.send_redirects kernel parameter, run the following command: # sysctl -w net.ipv4.conf.default.send_redirects=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.default.send_redirects = 0

identifiers: CCE-27001-7

references: AC-4, CM-7, SC-5, SC-7, 1551,

Remediation script:

#
# Set runtime for net.ipv4.conf.default.send_redirects
#
sysctl -q -n -w net.ipv4.conf.default.send_redirects=0

#
# If net.ipv4.conf.default.send_redirects present in /etc/sysctl.conf, change value to "0"
#	else, add "net.ipv4.conf.default.send_redirects = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.default.send_redirects /etc/sysctl.conf ; then
	sed -i 's/^net.ipv4.conf.default.send_redirects.*/net.ipv4.conf.default.send_redirects = 0/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set net.ipv4.conf.default.send_redirects to 0 per security requirements" >> /etc/sysctl.conf
	echo "net.ipv4.conf.default.send_redirects = 0" >> /etc/sysctl.conf
fi

Disable Kernel Parameter for Sending ICMP Redirects for All Interfacesrule

To set the runtime status of the net.ipv4.conf.all.send_redirects kernel parameter, run the following command: # sysctl -w net.ipv4.conf.all.send_redirects=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.all.send_redirects = 0

identifiers: CCE-27004-1

references: CM-7, 1551,

Remediation script:

#
# Set runtime for net.ipv4.conf.all.send_redirects
#
sysctl -q -n -w net.ipv4.conf.all.send_redirects=0

#
# If net.ipv4.conf.all.send_redirects present in /etc/sysctl.conf, change value to "0"
#	else, add "net.ipv4.conf.all.send_redirects = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.all.send_redirects /etc/sysctl.conf ; then
	sed -i 's/^net.ipv4.conf.all.send_redirects.*/net.ipv4.conf.all.send_redirects = 0/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set net.ipv4.conf.all.send_redirects to 0 per security requirements" >> /etc/sysctl.conf
	echo "net.ipv4.conf.all.send_redirects = 0" >> /etc/sysctl.conf
fi

Disable Kernel Parameter for IP Forwardingrule

To set the runtime status of the net.ipv4.ip_forward kernel parameter, run the following command: # sysctl -w net.ipv4.ip_forward=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.ip_forward = 0

identifiers: CCE-26866-4

references: CM-7, SC-5, 366,

Network Related Kernel Runtime Parameters for Hosts and Routersgroup

Certain kernel parameters should be set for systems which are acting as either hosts or routers to improve the system's ability defend against certain types of IPv4 protocol attacks.

contains 11 rules

Disable Kernel Parameter for Accepting ICMP Redirects for All Interfacesrule

To set the runtime status of the net.ipv4.conf.all.accept_redirects kernel parameter, run the following command: # sysctl -w net.ipv4.conf.all.accept_redirects=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.all.accept_redirects = 0

identifiers: CCE-27027-2

references: CM-7, 1503, 1551,

Remediation script:

#
# Set runtime for net.ipv4.conf.all.accept_redirects
#
sysctl -q -n -w net.ipv4.conf.all.accept_redirects=0

#
# If net.ipv4.conf.all.accept_redirects present in /etc/sysctl.conf, change value to "0"
#	else, add "net.ipv4.conf.all.accept_redirects = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.all.accept_redirects /etc/sysctl.conf ; then
	sed -i 's/^net.ipv4.conf.all.accept_redirects.*/net.ipv4.conf.all.accept_redirects = 0/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set net.ipv4.conf.all.accept_redirects to 0 per security requirements" >> /etc/sysctl.conf
	echo "net.ipv4.conf.all.accept_redirects = 0" >> /etc/sysctl.conf
fi

Disable Kernel Parameter for Accepting Secure Redirects for All Interfacesrule

To set the runtime status of the net.ipv4.conf.all.secure_redirects kernel parameter, run the following command: # sysctl -w net.ipv4.conf.all.secure_redirects=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.all.secure_redirects = 0

identifiers: CCE-26854-0

references: AC-4, CM-7, 1503, 1551,

Remediation script:

#
# Set runtime for net.ipv4.conf.all.secure_redirects
#
sysctl -q -n -w net.ipv4.conf.all.secure_redirects=0

#
# If net.ipv4.conf.all.secure_redirects present in /etc/sysctl.conf, change value to "0"
#	else, add "net.ipv4.conf.all.secure_redirects = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.all.secure_redirects /etc/sysctl.conf ; then
	sed -i 's/^net.ipv4.conf.all.secure_redirects.*/net.ipv4.conf.all.secure_redirects = 0/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set net.ipv4.conf.all.secure_redirects to 0 per security requirements" >> /etc/sysctl.conf
	echo "net.ipv4.conf.all.secure_redirects = 0" >> /etc/sysctl.conf
fi

Enable Kernel Parameter to Log Martian Packetsrule

To set the runtime status of the net.ipv4.conf.all.log_martians kernel parameter, run the following command: # sysctl -w net.ipv4.conf.all.log_martians=1 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.all.log_martians = 1

identifiers: CCE-27066-0

references: AC-3(10), CM-7, 126,

Remediation script:

#
# Set runtime for net.ipv4.conf.all.log_martians
#
sysctl -q -n -w net.ipv4.conf.all.log_martians=1

#
# If net.ipv4.conf.all.log_martians present in /etc/sysctl.conf, change value to "1"
#	else, add "net.ipv4.conf.all.log_martians = 1" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.all.log_martians /etc/sysctl.conf ; then
	sed -i 's/^net.ipv4.conf.all.log_martians.*/net.ipv4.conf.all.log_martians = 1/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set net.ipv4.conf.all.log_martians to 1 per security requirements" >> /etc/sysctl.conf
	echo "net.ipv4.conf.all.log_martians = 1" >> /etc/sysctl.conf
fi

Disable Kernel Parameter for Accepting Source-Routed Packets By Defaultrule

To set the runtime status of the net.ipv4.conf.default.accept_source_route kernel parameter, run the following command: # sysctl -w net.ipv4.conf.default.accept_source_route=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.default.accept_source_route = 0

identifiers: CCE-26983-7

references: AC-4, CM-7, SC-5, SC-7, 1551,

Remediation script:

#
# Set runtime for net.ipv4.conf.default.accept_source_route
#
sysctl -q -n -w net.ipv4.conf.default.accept_source_route=0

#
# If net.ipv4.conf.default.accept_source_route present in /etc/sysctl.conf, change value to "0"
#	else, add "net.ipv4.conf.default.accept_source_route = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.default.accept_source_route /etc/sysctl.conf ; then
	sed -i 's/^net.ipv4.conf.default.accept_source_route.*/net.ipv4.conf.default.accept_source_route = 0/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set net.ipv4.conf.default.accept_source_route to 0 per security requirements" >> /etc/sysctl.conf
	echo "net.ipv4.conf.default.accept_source_route = 0" >> /etc/sysctl.conf
fi

Disable Kernel Parameter for Accepting ICMP Redirects By Defaultrule

To set the runtime status of the net.ipv4.conf.default.accept_redirects kernel parameter, run the following command: # sysctl -w net.ipv4.conf.default.accept_redirects=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.default.accept_redirects = 0

identifiers: CCE-27015-7

references: AC-4, CM-7, SC-5, SC-7, 1551,

Remediation script:

#
# Set runtime for net.ipv4.conf.default.accept_redirects
#
sysctl -q -n -w net.ipv4.conf.default.accept_redirects=0

#
# If net.ipv4.conf.default.accept_redirects present in /etc/sysctl.conf, change value to "0"
#	else, add "net.ipv4.conf.default.accept_redirects = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.default.accept_redirects /etc/sysctl.conf ; then
	sed -i 's/^net.ipv4.conf.default.accept_redirects.*/net.ipv4.conf.default.accept_redirects = 0/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set net.ipv4.conf.default.accept_redirects to 0 per security requirements" >> /etc/sysctl.conf
	echo "net.ipv4.conf.default.accept_redirects = 0" >> /etc/sysctl.conf
fi

Disable Kernel Parameter for Accepting Secure Redirects By Defaultrule

To set the runtime status of the net.ipv4.conf.default.secure_redirects kernel parameter, run the following command: # sysctl -w net.ipv4.conf.default.secure_redirects=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.default.secure_redirects = 0

identifiers: CCE-26831-8

references: AC-4, CM-7, SC-5, SC-7, 1551,

Remediation script:

#
# Set runtime for net.ipv4.conf.default.secure_redirects
#
sysctl -q -n -w net.ipv4.conf.default.secure_redirects=0

#
# If net.ipv4.conf.default.secure_redirects present in /etc/sysctl.conf, change value to "0"
#	else, add "net.ipv4.conf.default.secure_redirects = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.default.secure_redirects /etc/sysctl.conf ; then
	sed -i 's/^net.ipv4.conf.default.secure_redirects.*/net.ipv4.conf.default.secure_redirects = 0/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set net.ipv4.conf.default.secure_redirects to 0 per security requirements" >> /etc/sysctl.conf
	echo "net.ipv4.conf.default.secure_redirects = 0" >> /etc/sysctl.conf
fi

Enable Kernel Parameter to Ignore ICMP Broadcast Echo Requestsrule

To set the runtime status of the net.ipv4.icmp_echo_ignore_broadcasts kernel parameter, run the following command: # sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.icmp_echo_ignore_broadcasts = 1

identifiers: CCE-26883-9

references: CM-7, SC-5, 1551,

Remediation script:

#
# Set runtime for net.ipv4.icmp_echo_ignore_broadcasts
#
sysctl -q -n -w net.ipv4.icmp_echo_ignore_broadcasts=1

#
# If net.ipv4.icmp_echo_ignore_broadcasts present in /etc/sysctl.conf, change value to "1"
#	else, add "net.ipv4.icmp_echo_ignore_broadcasts = 1" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.icmp_echo_ignore_broadcasts /etc/sysctl.conf ; then
	sed -i 's/^net.ipv4.icmp_echo_ignore_broadcasts.*/net.ipv4.icmp_echo_ignore_broadcasts = 1/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set net.ipv4.icmp_echo_ignore_broadcasts to 1 per security requirements" >> /etc/sysctl.conf
	echo "net.ipv4.icmp_echo_ignore_broadcasts = 1" >> /etc/sysctl.conf
fi

Enable Kernel Parameter to Ignore Bogus ICMP Error Responsesrule

To set the runtime status of the net.ipv4.icmp_ignore_bogus_error_responses kernel parameter, run the following command: # sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.icmp_ignore_bogus_error_responses = 1

identifiers: CCE-26993-6

references: CM-7, SC-5,

Remediation script:

#
# Set runtime for net.ipv4.icmp_ignore_bogus_error_responses
#
sysctl -q -n -w net.ipv4.icmp_ignore_bogus_error_responses=1

#
# If net.ipv4.icmp_ignore_bogus_error_responses present in /etc/sysctl.conf, change value to "1"
#	else, add "net.ipv4.icmp_ignore_bogus_error_responses = 1" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.icmp_ignore_bogus_error_responses /etc/sysctl.conf ; then
	sed -i 's/^net.ipv4.icmp_ignore_bogus_error_responses.*/net.ipv4.icmp_ignore_bogus_error_responses = 1/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set net.ipv4.icmp_ignore_bogus_error_responses to 1 per security requirements" >> /etc/sysctl.conf
	echo "net.ipv4.icmp_ignore_bogus_error_responses = 1" >> /etc/sysctl.conf
fi

Enable Kernel Parameter to Use TCP Syncookiesrule

To set the runtime status of the net.ipv4.tcp_syncookies kernel parameter, run the following command: # sysctl -w net.ipv4.tcp_syncookies=1 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.tcp_syncookies = 1

identifiers: CCE-27053-8

references: AC-4, 1092, 1095,

Remediation script:

#
# Set runtime for net.ipv4.tcp_syncookies
#
sysctl -q -n -w net.ipv4.tcp_syncookies=1

#
# If net.ipv4.tcp_syncookies present in /etc/sysctl.conf, change value to "1"
#	else, add "net.ipv4.tcp_syncookies = 1" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.tcp_syncookies /etc/sysctl.conf ; then
	sed -i 's/^net.ipv4.tcp_syncookies.*/net.ipv4.tcp_syncookies = 1/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set net.ipv4.tcp_syncookies to 1 per security requirements" >> /etc/sysctl.conf
	echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
fi

Enable Kernel Parameter to Use Reverse Path Filtering for All Interfacesrule

To set the runtime status of the net.ipv4.conf.all.rp_filter kernel parameter, run the following command: # sysctl -w net.ipv4.conf.all.rp_filter=1 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.all.rp_filter = 1

identifiers: CCE-26979-5

references: AC-4, SC-5, SC-7, 1551,

Remediation script:

#
# Set runtime for net.ipv4.conf.all.rp_filter
#
sysctl -q -n -w net.ipv4.conf.all.rp_filter=1

#
# If net.ipv4.conf.all.rp_filter present in /etc/sysctl.conf, change value to "1"
#	else, add "net.ipv4.conf.all.rp_filter = 1" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.all.rp_filter /etc/sysctl.conf ; then
	sed -i 's/^net.ipv4.conf.all.rp_filter.*/net.ipv4.conf.all.rp_filter = 1/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set net.ipv4.conf.all.rp_filter to 1 per security requirements" >> /etc/sysctl.conf
	echo "net.ipv4.conf.all.rp_filter = 1" >> /etc/sysctl.conf
fi

Enable Kernel Parameter to Use Reverse Path Filtering by Defaultrule

To set the runtime status of the net.ipv4.conf.default.rp_filter kernel parameter, run the following command: # sysctl -w net.ipv4.conf.default.rp_filter=1 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.default.rp_filter = 1

identifiers: CCE-26915-9

references: AC-4, SC-5, SC-7,

Remediation script:

#
# Set runtime for net.ipv4.conf.default.rp_filter
#
sysctl -q -n -w net.ipv4.conf.default.rp_filter=1

#
# If net.ipv4.conf.default.rp_filter present in /etc/sysctl.conf, change value to "1"
#	else, add "net.ipv4.conf.default.rp_filter = 1" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.default.rp_filter /etc/sysctl.conf ; then
	sed -i 's/^net.ipv4.conf.default.rp_filter.*/net.ipv4.conf.default.rp_filter = 1/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set net.ipv4.conf.default.rp_filter to 1 per security requirements" >> /etc/sysctl.conf
	echo "net.ipv4.conf.default.rp_filter = 1" >> /etc/sysctl.conf
fi

Wireless Networkinggroup

Wireless networking, such as 802.11 (WiFi) and Bluetooth, can present a security risk to sensitive or classified systems and networks. Wireless networking hardware is much more likely to be included in laptop or portable systems than in desktops or servers.

Removal of hardware provides the greatest assurance that the wireless capability remains disabled. Acquisition policies often include provisions to prevent the purchase of equipment that will be used in sensitive spaces and includes wireless capabilities. If it is impractical to remove the wireless hardware, and policy permits the device to enter sensitive spaces as long as wireless is disabled, efforts should instead focus on disabling wireless capability via software.

contains 4 rules

Disable Wireless Through Software Configurationgroup

If it is impossible to remove the wireless hardware from the device in question, disable as much of it as possible through software. The following methods can disable software support for wireless networking, but note that these methods do not prevent malicious software or careless users from re-activating the devices.

contains 4 rules

Disable WiFi or Bluetooth in BIOSrule

Some systems that include built-in wireless support offer the ability to disable the device through the BIOS. This is system-specific; consult your hardware manual or explore the BIOS setup during boot.

identifiers: CCE-26878-9

references: AC-18(a), AC-18(d), AC-18(3), CM-7, 85

Deactivate Wireless Network Interfacesrule

Deactivating wireless network interfaces should prevent normal usage of the wireless capability.

First, identify the interfaces available with the command:

# ifconfig -a

Additionally, the following command may be used to determine whether wireless support is included for a particular interface, though this may not always be a clear indicator:

# iwconfig

After identifying any wireless interfaces (which may have names like wlan0, ath0, wifi0, em1 or eth0), deactivate the interface with the command:

# ifdown interface

These changes will only last until the next reboot. To disable the interface for future boots, remove the appropriate interface file from /etc/sysconfig/network-scripts:

# rm /etc/sysconfig/network-scripts/ifcfg-interface

identifiers: CCE-27057-9

references: AC-18(a), AC-18(d), AC-18(3), CM-7, 85,

Disable Bluetooth Servicerule

The bluetooth service can be disabled with the following command: # chkconfig bluetooth off

# service bluetooth stop

identifiers: CCE-27081-9

references: AC-18(a), AC-18(d), AC-18(3), CM-7, 85, 1551,

Remediation script:

#
# Disable bluetooth for all run levels
#
chkconfig --level 0123456 bluetooth off

#
# Stop bluetooth if currently running
#
service bluetooth stop

Disable Bluetooth Kernel Modulesrule

The kernel's module loading system can be configured to prevent loading of the Bluetooth module. Add the following to the appropriate /etc/modprobe.d configuration file to prevent the loading of the Bluetooth module:

install net-pf-31 /bin/false
install bluetooth /bin/false

identifiers: CCE-26763-3

references: AC-18(a), AC-18(d), AC-18(3), CM-7, 85, 1551,

IPv6group

The system includes support for Internet Protocol version 6. A major and often-mentioned improvement over IPv4 is its enormous increase in the number of available addresses. Another important feature is its support for automatic configuration of many network settings.

contains 4 rules

Disable Support for IPv6 Unless Neededgroup

Despite configuration that suggests support for IPv6 has been disabled, link-local IPv6 address auto-configuration occurs even when only an IPv4 address is assigned. The only way to effectively prevent execution of the IPv6 networking stack is to instruct the system not to activate the IPv6 kernel module.

contains 2 rules

Disable IPv6 Networking Support Automatic Loadingrule

To prevent the IPv6 kernel module (ipv6) from loading the IPv6 networking stack, add the following line to /etc/modprobe.d/disabled.conf (or another file in /etc/modprobe.d):

options ipv6 disable=1

This permits the IPv6 module to be loaded (and thus satisfy other modules that depend on it), while disabling support for the IPv6 protocol.

identifiers: CCE-27153-6

references: CM-7, 1551,

Disable Support for RPC IPv6rule

RPC services for NFSv4 try to load transport modules for udp6 and tcp6 by default, even if IPv6 has been disabled in /etc/modprobe.d. To prevent RPC services such as rpc.mountd from attempting to start IPv6 network listeners, remove or comment out the following two lines in /etc/netconfig:

udp6       tpi_clts      v     inet6    udp     -       -
tcp6       tpi_cots_ord  v     inet6    tcp     -       -

identifiers: CCE-27232-8

references: CM-7

Configure IPv6 Settings if Necessarygroup

A major feature of IPv6 is the extent to which systems implementing it can automatically configure their networking devices using information from the network. From a security perspective, manually configuring important configuration information is preferable to accepting it from the network in an unauthenticated fashion.

contains 2 rules

Disable Automatic Configurationgroup

Disable the system's acceptance of router advertisements and redirects by adding or correcting the following line in /etc/sysconfig/network (note that this does not disable sending router solicitations):

IPV6_AUTOCONF=no

contains 2 rules

Disable Accepting IPv6 Router Advertisementsrule

To set the runtime status of the net.ipv6.conf.default.accept_ra kernel parameter, run the following command: # sysctl -w net.ipv6.conf.default.accept_ra=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv6.conf.default.accept_ra = 0

identifiers: CCE-27164-3

references: CM-7

Remediation script:

#
# Set runtime for net.ipv6.conf.default.accept_ra
#
sysctl -q -n -w net.ipv6.conf.default.accept_ra=0

#
# If net.ipv6.conf.default.accept_ra present in /etc/sysctl.conf, change value to "0"
#	else, add "net.ipv6.conf.default.accept_ra = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv6.conf.default.accept_ra /etc/sysctl.conf ; then
	sed -i 's/^net.ipv6.conf.default.accept_ra.*/net.ipv6.conf.default.accept_ra = 0/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set net.ipv6.conf.default.accept_ra to 0 per security requirements" >> /etc/sysctl.conf
	echo "net.ipv6.conf.default.accept_ra = 0" >> /etc/sysctl.conf
fi

Disable Accepting IPv6 Redirectsrule

To set the runtime status of the net.ipv6.conf.default.accept_redirects kernel parameter, run the following command: # sysctl -w net.ipv6.conf.default.accept_redirects=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv6.conf.default.accept_redirects = 0

identifiers: CCE-27166-8

references: CM-7, 1551

Remediation script:

#
# Set runtime for net.ipv6.conf.default.accept_redirects
#
sysctl -q -n -w net.ipv6.conf.default.accept_redirects=0

#
# If net.ipv6.conf.default.accept_redirects present in /etc/sysctl.conf, change value to "0"
#	else, add "net.ipv6.conf.default.accept_redirects = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv6.conf.default.accept_redirects /etc/sysctl.conf ; then
	sed -i 's/^net.ipv6.conf.default.accept_redirects.*/net.ipv6.conf.default.accept_redirects = 0/g' /etc/sysctl.conf
else
	echo "" >> /etc/sysctl.conf
	echo "# Set net.ipv6.conf.default.accept_redirects to 0 per security requirements" >> /etc/sysctl.conf
	echo "net.ipv6.conf.default.accept_redirects = 0" >> /etc/sysctl.conf
fi

Limit Network-Transmitted Configuration if Using Static IPv6 Addressesgroup

To limit the configuration information requested from other systems and accepted from the network on a system that uses statically-configured IPv6 addresses, add the following lines to /etc/sysctl.conf:

net.ipv6.conf.default.router_solicitations = 0
net.ipv6.conf.default.accept_ra_rtr_pref = 0
net.ipv6.conf.default.accept_ra_pinfo = 0
net.ipv6.conf.default.accept_ra_defrtr = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.dad_transmits = 0
net.ipv6.conf.default.max_addresses = 1

The router_solicitations setting determines how many router solicitations are sent when bringing up the interface. If addresses are statically assigned, there is no need to send any solicitations.

The accept_ra_pinfo setting controls whether the system will accept prefix info from the router.

The accept_ra_defrtr setting controls whether the system will accept Hop Limit settings from a router advertisement. Setting it to 0 prevents a router from changing your default IPv6 Hop Limit for outgoing packets.

The autoconf setting controls whether router advertisements can cause the system to assign a global unicast address to an interface.

The dad_transmits setting determines how many neighbor solicitations to send out per address (global and link-local) when bringing up an interface to ensure the desired address is unique on the network.

The max_addresses setting determines how many global unicast IPv6 addresses can be assigned to each interface. The default is 16, but it should be set to exactly the number of statically configured global addresses required.

iptables and ip6tablesgroup

A host-based firewall called netfilter is included as part of the Linux kernel distributed with the system. It is activated by default. This firewall is controlled by the program iptables, and the entire capability is frequently referred to by this name. An analogous program called ip6tables handles filtering for IPv6.

Unlike TCP Wrappers, which depends on the network server program to support and respect the rules written, netfilter filtering occurs at the kernel level, before a program can even process the data from the network packet. As such, any program on the system is affected by the rules written.

This section provides basic information about strengthening the iptables and ip6tables configurations included with the system. For more complete information that may allow the construction of a sophisticated ruleset tailored to your environment, please consult the references at the end of this section.

contains 4 rules

Inspect and Activate Default Rulesgroup

View the currently-enforced iptables rules by running the command:

# iptables -nL --line-numbers

The command is analogous for ip6tables.

If the firewall does not appear to be active (i.e., no rules appear), activate it and ensure that it starts at boot by issuing the following commands (and analogously for ip6tables):

# service iptables restart

The default iptables rules are:

Chain INPUT (policy ACCEPT)
num  target     prot opt source       destination
1    ACCEPT     all  --  0.0.0.0/0    0.0.0.0/0    state RELATED,ESTABLISHED 
2    ACCEPT     icmp --  0.0.0.0/0    0.0.0.0/0
3    ACCEPT     all  --  0.0.0.0/0    0.0.0.0/0
4    ACCEPT     tcp  --  0.0.0.0/0    0.0.0.0/0    state NEW tcp dpt:22 
5    REJECT     all  --  0.0.0.0/0    0.0.0.0/0    reject-with icmp-host-prohibited 

Chain FORWARD (policy ACCEPT)
num  target     prot opt source       destination
1    REJECT     all  --  0.0.0.0/0    0.0.0.0/0    reject-with icmp-host-prohibited 

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source       destination

The ip6tables default rules are essentially the same.

contains 2 rules

Verify ip6tables Enabled if Using IPv6rule

The ip6tables service can be enabled with the following command: # chkconfig --level 2345 ip6tables on

identifiers: CCE-27006-6

references: AC-4, CA-3(c), CM-7, 32, 66, 1115, 1118, 1092, 1117, 1098, 1100, 1097, 1414,

Remediation script:

#
# Enable ip6tables for all run levels
#
chkconfig --level 0123456 ip6tables on

#
# Start ip6tables if not currently running
#
service ip6tables start

Verify iptables Enabledrule

The iptables service can be enabled with the following command: # chkconfig --level 2345 iptables on

identifiers: CCE-27018-1

references: AC-4, CA-3(c), CM-7, 32, 66, 1115, 1118, 1092, 1117, 1098, 1100, 1097, 1414,

Remediation script:

#
# Enable iptables for all run levels
#
chkconfig --level 0123456 iptables on

#
# Start iptables if not currently running
#
service iptables start

Strengthen the Default Rulesetgroup

The default rules can be strengthened. The system scripts that activate the firewall rules expect them to be defined in the configuration files iptables and ip6tables in the directory /etc/sysconfig. Many of the lines in these files are similar to the command line arguments that would be provided to the programs /sbin/iptables or /sbin/ip6tables - but some are quite different.

The following recommendations describe how to strengthen the default ruleset configuration file. An alternative to editing this configuration file is to create a shell script that makes calls to the iptables program to load in rules, and then invokes service iptables save to write those loaded rules to /etc/sysconfig/iptables.

The following alterations can be made directly to /etc/sysconfig/iptables and /etc/sysconfig/ip6tables. Instructions apply to both unless otherwise noted. Language and address conventions for regular iptables are used throughout this section; configuration for ip6tables will be either analogous or explicitly covered.

contains 2 rules

Restrict ICMP Message Typesgroup

In /etc/sysconfig/iptables, the accepted ICMP messages types can be restricted. To accept only ICMP echo reply, destination unreachable, and time exceeded messages, remove the line:

-A INPUT -p icmp --icmp-type any -j ACCEPT

and insert the lines:

-A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
-A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
-A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT

To allow the system to respond to pings, also insert the following line:

-A INPUT -p icmp --icmp-type echo-request -j ACCEPT

Ping responses can also be limited to certain networks or hosts by using the -s option in the previous rule. Because IPv6 depends so heavily on ICMPv6, it is preferable to deny the ICMPv6 packets you know you don't need (e.g. ping requests) in /etc/sysconfig/ip6tables, while letting everything else through:

-A INPUT -p icmpv6 --icmpv6-type echo-request -j DROP

If you are going to statically configure the machine's address, it should ignore Router Advertisements which could add another IPv6 address to the interface or alter important network settings:

-A INPUT -p icmpv6 --icmpv6-type router-advertisement -j DROP

Restricting ICMPv6 message types in /etc/sysconfig/ip6tables is not recommended because the operation of IPv6 depends heavily on ICMPv6. Thus, great care must be taken if any other ICMPv6 types are blocked.

Log and Drop Packets with Suspicious Source Addressesgroup

Packets with non-routable source addresses should be rejected, as they may indicate spoofing. Because the modified policy will reject non-matching packets, you only need to add these rules if you are interested in also logging these spoofing or suspicious attempts before they are dropped. If you do choose to log various suspicious traffic, add identical rules with a target of DROP after each LOG. To log and then drop these IPv4 packets, insert the following rules in /etc/sysconfig/iptables (excepting any that are intentionally used):

-A INPUT -s 10.0.0.0/8 -j LOG --log-prefix "IP DROP SPOOF A: "
-A INPUT -s 172.16.0.0/12 -j LOG --log-prefix "IP DROP SPOOF B: "
-A INPUT -s 192.168.0.0/16 -j LOG --log-prefix "IP DROP SPOOF C: "
-A INPUT -s 224.0.0.0/4 -j LOG --log-prefix "IP DROP MULTICAST D: "
-A INPUT -s 240.0.0.0/5 -j LOG --log-prefix "IP DROP SPOOF E: "
-A INPUT -d 127.0.0.0/8 -j LOG --log-prefix "IP DROP LOOPBACK: "

Similarly, you might wish to log packets containing some IPv6 reserved addresses if they are not expected on your network:

-A INPUT -i eth0 -s ::1 -j LOG --log-prefix "IPv6 DROP LOOPBACK: "
-A INPUT -s 2002:E000::/20 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
-A INPUT -s 2002:7F00::/24 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
-A INPUT -s 2002:0000::/24 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
-A INPUT -s 2002:FF00::/24 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
-A INPUT -s 2002:0A00::/24 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
-A INPUT -s 2002:AC10::/28 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
-A INPUT -s 2002:C0A8::/32 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "

If you are not expecting to see site-local multicast or auto-tunneled traffic, you can log those:

-A INPUT -s FF05::/16 -j LOG --log-prefix "IPv6 SITE-LOCAL MULTICAST: "
-A INPUT -s ::0.0.0.0/96 -j LOG --log-prefix "IPv4 COMPATIBLE IPv6 ADDR: "

If you wish to block multicasts to all link-local nodes (e.g. if you are not using router auto-configuration and do not plan to have any services that multicast to the entire local network), you can block the link-local all-nodes multicast address (before accepting incoming ICMPv6):

-A INPUT -d FF02::1 -j LOG --log-prefix "Link-local All-Nodes Multicast: "

However, if you're going to allow IPv4 compatible IPv6 addresses (of the form ::0.0.0.0/96), you should then consider logging the non-routable IPv4-compatible addresses:

-A INPUT -s ::0.0.0.0/104 -j LOG --log-prefix "IP NON-ROUTABLE ADDR: "
-A INPUT -s ::127.0.0.0/104 -j LOG --log-prefix "IP DROP LOOPBACK: "
-A INPUT -s ::224.0.0.0.0/100 -j LOG --log-prefix "IP DROP MULTICAST D: "
-A INPUT -s ::255.0.0.0/104 -j LOG --log-prefix "IP BROADCAST: "

If you are not expecting to see any IPv4 (or IPv4-compatible) traffic on your network, consider logging it before it gets dropped:

-A INPUT -s ::FFFF:0.0.0.0/96 -j LOG --log-prefix "IPv4 MAPPED IPv6 ADDR: "
-A INPUT -s 2002::/16 -j LOG --log-prefix "IPv6 6to4 ADDR: "

The following rule will log all traffic originating from a site-local address, which is deprecated address space:

-A INPUT -s FEC0::/10 -j LOG --log-prefix "SITE-LOCAL ADDRESS TRAFFIC: "

Set Default iptables Policy for Incoming Packetsrule

To set the default policy to DROP (instead of ACCEPT) for the built-in INPUT chain which processes incoming packets, add or correct the following line in /etc/sysconfig/iptables:

:INPUT DROP [0:0]

identifiers: CCE-26444-0

references: CM-7, 66, 1109, 1154, 1414

Remediation script:

sed -i 's/^:INPUT ACCEPT.*/:INPUT DROP [0:0]/g' /etc/sysconfig/iptables

Set Default iptables Policy for Forwarded Packetsrule

To set the default policy to DROP (instead of ACCEPT) for the built-in FORWARD chain which processes packets that will be forwarded from one interface to another, add or correct the following line in /etc/sysconfig/iptables:

:FORWARD DROP [0:0]

identifiers: CCE-27186-6

references: CM-7, 1109

Remediation script:

sed -i 's/^:FORWARD ACCEPT.*/:FORWARD DROP [0:0]/g' /etc/sysconfig/iptables

Transport Layer Security Supportgroup

Support for Transport Layer Security (TLS), and its predecessor, the Secure Sockets Layer (SSL), is included in RHEL in the OpenSSL software (RPM package openssl). TLS provides encrypted and authenticated network communications, and many network services include support for it. TLS or SSL can be leveraged to avoid any plaintext transmission of sensitive data.

For information on how to use OpenSSL, see http://www.openssl.org/docs/HOWTO/. Information on FIPS validation of OpenSSL is available at http://www.openssl.org/docs/fips/fipsvalidation.html and http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm.

Uncommon Network Protocolsgroup

The system includes support for several network protocols which are not commonly used. Although security vulnerabilities in kernel networking code are not frequently discovered, the consequences can be dramatic. Ensuring uncommon network protocols are disabled reduces the system's risk to attacks targeted at its implementation of those protocols.

contains 4 rules

Disable DCCP Supportrule

The Datagram Congestion Control Protocol (DCCP) is a relatively new transport layer protocol, designed to support streaming media and telephony. To configure the system to prevent the dccp kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d: install dccp /bin/false

identifiers: CCE-26448-1

references: CM-7, 382,

Remediation script:

echo "install dccp /bin/false" > /etc/modprobe.d/dccp.conf

Disable SCTP Supportrule

The Stream Control Transmission Protocol (SCTP) is a transport layer protocol, designed to support the idea of message-oriented communication, with several streams of messages within one connection. To configure the system to prevent the sctp kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d: install sctp /bin/false

identifiers: CCE-26410-1

references: CM-7, 382,

Remediation script:

echo "install sctp /bin/false" > /etc/modprobe.d/sctp.conf

Disable RDS Supportrule

The Reliable Datagram Sockets (RDS) protocol is a transport layer protocol designed to provide reliable high- bandwidth, low-latency communications between nodes in a cluster. To configure the system to prevent the rds kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d: install rds /bin/false

identifiers: CCE-26239-4

references: CM-7, 382,

Remediation script:

echo "install rds /bin/false" > /etc/modprobe.d/rds.conf

Disable TIPC Supportrule

The Transparent Inter-Process Communication (TIPC) protocol is designed to provide communications between nodes in a cluster. To configure the system to prevent the tipc kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d: install tipc /bin/false

identifiers: CCE-26696-5

references: CM-7, 382,

Remediation script:

echo "install tipc /bin/false" > /etc/modprobe.d/tipc.conf

IPSec Supportgroup

Support for Internet Protocol Security (IPsec) is provided in RHEL 6 with Openswan.

Disable Zeroconf Networkingrule

Zeroconf networking allows the system to assign itself an IP address and engage in IP communication without a statically-assigned address or even a DHCP server. Automatic address assignment via Zeroconf (or DHCP) is not recommended. To disable Zeroconf automatic route assignment in the 169.254.0.0 subnet, add or correct the following line in /etc/sysconfig/network:

NOZEROCONF=yes

identifiers: CCE-27151-0

references: CM-7

Remediation script:

echo "NOZEROCONF=yes" >> /etc/sysconfig/network

Configure Sysloggroup

The syslog service has been the default Unix logging mechanism for many years. It has a number of downsides, including inconsistent log format, lack of authentication for received messages, and lack of authentication, encryption, or reliable transport for messages sent over a network. However, due to its long history, syslog is a de facto standard which is supported by almost all Unix applications.

In RHEL 6, rsyslog has replaced ksyslogd as the syslog daemon of choice, and it includes some additional security features such as reliable, connection-oriented (i.e. TCP) transmission of logs, the option to log to database formats, and the encryption of log data en route to a central logging server. This section discusses how to configure rsyslog for best effect, and how to use tools provided with the system to maintain and monitor logs.

contains 8 rules

Ensure Proper Configuration of Log Filesgroup

The file /etc/rsyslog.conf controls where log message are written. These are controlled by lines called rules, which consist of a selector and an action. These rules are often customized depending on the role of the system, the requirements of the environment, and whatever may enable the administrator to most effectively make use of log data. The default rules in RHEL 6 are:

*.info;mail.none;authpriv.none;cron.none                /var/log/messages
authpriv.*                                              /var/log/secure
mail.*                                                  -/var/log/maillog
cron.*                                                  /var/log/cron
*.emerg                                                 *
uucp,news.crit                                          /var/log/spooler
local7.*                                                /var/log/boot.log

See the man page rsyslog.conf(5) for more information. Note that the rsyslog daemon can be configured to use a timestamp format that some log processing programs may not understand. If this occurs, edit the file /etc/rsyslog.conf and add or edit the following line:

$ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

contains 3 rules

Ensure Log Files Are Owned By Appropriate Userrule

The owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. For each log file LOGFILE referenced in /etc/rsyslog.conf, run the following command to inspect the file's owner:

$ ls -l LOGFILE

If the owner is not root, run the following command to correct this:

# chown root LOGFILE

identifiers: CCE-26812-8

references: AC-6, 1314,

Ensure Log Files Are Owned By Appropriate Grouprule

The group-owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. For each log file LOGFILE referenced in /etc/rsyslog.conf, run the following command to inspect the file's group owner:

$ ls -l LOGFILE

If the owner is not root, run the following command to correct this:

# chgrp root LOGFILE

identifiers: CCE-26821-9

references: AC-6, 1314,

Ensure System Log Files Have Correct Permissionsrule

The file permissions for all log files written by rsyslog should be set to 600, or more restrictive. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. For each log file LOGFILE referenced in /etc/rsyslog.conf, run the following command to inspect the file's permissions:

$ ls -l LOGFILE

If the permissions are not 600 or more restrictive, run the following command to correct this:

# chmod 0600 LOGFILE

identifiers: CCE-27190-8

references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 1314,

Rsyslog Logs Sent To Remote Hostgroup

If system logs are to be useful in detecting malicious activities, it is necessary to send logs to a remote server. An intruder who has compromised the root account on a machine may delete the log entries which indicate that the system was attacked before they are seen by an administrator.

However, it is recommended that logs be stored on the local host in addition to being sent to the loghost, especially if rsyslog has been configured to use the UDP protocol to send messages over a network. UDP does not guarantee reliable delivery, and moderately busy sites will lose log messages occasionally, especially in periods of high traffic which may be the result of an attack. In addition, remote rsyslog messages are not authenticated in any way by default, so it is easy for an attacker to introduce spurious messages to the central log server. Also, some problems cause loss of network connectivity, which will prevent the sending of messages to the central server. For all of these reasons, it is better to store log messages both centrally and on each host, so that they can be correlated if necessary.

contains 1 rule

Ensure Logs Sent To Remote Hostrule

To configure rsyslog to send logs to a remote log server, open /etc/rsyslog.conf and read and understand the last section of the file, which describes the multiple directives necessary to activate remote logging. Along with these other directives, the system can be configured to forward its logs to a particular log server by adding or correcting one of the following lines, substituting loghost.example.com appropriately. The choice of protocol depends on the environment of the system; although TCP and RELP provide more reliable message delivery, they may not be supported in all environments.

To use UDP for log message delivery:

*.* @loghost.example.com

To use TCP for log message delivery:

*.* @@loghost.example.com

To use RELP for log message delivery:

*.* :omrelp:loghost.example.com

identifiers: CCE-26801-1

references: AU-3(2), AU-9, 1348, 136

Configure rsyslogd to Accept Remote Messages If Acting as a Log Servergroup

By default, rsyslog does not listen over the network for log messages. If needed, modules can be enabled to allow the rsyslog daemon to receive messages from other systems and for the system thus to act as a log server. If the machine is not a log server, then lines concerning these modules should remain commented out.

contains 1 rule

Ensure rsyslog Does Not Accept Remote Messages Unless Acting As Log Serverrule

The rsyslog daemon should not accept remote messages unless the system acts as a log server. To ensure that it is not listening on the network, ensure the following lines are not found in /etc/rsyslog.conf:

$ModLoad imtcp
$InputTCPServerRun port
$ModLoad imudp
$UDPServerRun port
$ModLoad imrelp
$InputRELPServerRun port

identifiers: CCE-26803-7

references: AU-9(2)

Ensure All Logs are Rotated by logrotategroup

Edit the file /etc/logrotate.d/syslog. Find the first line, which should look like this (wrapped for clarity):

/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler \
  /var/log/boot.log /var/log/cron {

Edit this line so that it contains a one-space-separated listing of each log file referenced in /etc/rsyslog.conf.

All logs in use on a system must be rotated regularly, or the log files will consume disk space over time, eventually interfering with system operation. The file /etc/logrotate.d/syslog is the configuration file used by the logrotate program to maintain all log files written by syslog. By default, it rotates logs weekly and stores four archival copies of each log. These settings can be modified by editing /etc/logrotate.conf, but the defaults are sufficient for purposes of this guide.

Note that logrotate is run nightly by the cron job /etc/cron.daily/logrotate. If particularly active logs need to be rotated more often than once a day, some other mechanism must be used.

contains 1 rule

Ensure Logrotate Runs Periodicallyrule

The logrotate utility allows for the automatic rotation of log files. The frequency of rotation is specified in /etc/logrotate.conf, which triggers a cron task. To configure logrotate to run daily, add or correct the following line in /etc/logrotate.conf:

# rotate log files frequency
daily

identifiers: CCE-27014-0

references: AU-9, 366

Configure Logwatch on the Central Log Servergroup

Is this machine the central log server? If so, edit the file /etc/logwatch/conf/logwatch.conf as shown below.

Ensure rsyslog is Installedrule

Rsyslog is installed by default. The rsyslog package can be installed with the following command: # yum install rsyslog

identifiers: CCE-26809-4

references: AU-9(2), 1311, 1312,

Remediation script:

yum -y install rsyslog

Enable rsyslog Servicerule

The rsyslog service provides syslog-style logging by default on RHEL 6. The rsyslog service can be enabled with the following command: # chkconfig --level 2345 rsyslog on

identifiers: CCE-26807-8

references: AU-12, 1557, 1312, 1311,

Remediation script:

#
# Enable rsyslog for all run levels
#
chkconfig --level 0123456 rsyslog on

#
# Start rsyslog if not currently running
#
service rsyslog start

System Accounting with auditdgroup

The audit service provides substantial capabilities for recording system activities. By default, the service audits about SELinux AVC denials and certain types of security-relevant events such as system logins, account modifications, and authentication events performed by programs such as sudo. Under its default configuration, auditd has modest disk space requirements, and should not noticeably impact system performance.

Government networks often have substantial auditing requirements and auditd can be configured to meet these requirements. Examining some example audit records demonstrates how the Linux audit system satisfies common requirements. The following example from Fedora Documentation available at http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages.html shows the substantial amount of information captured in a two typical "raw" audit messages, followed by a breakdown of the most important fields. In this example the message is SELinux-related and reports an AVC denial (and the associated system call) that occurred when the Apache HTTP Server attempted to access the /var/www/html/file1 file (labeled with the samba_share_t type):

type=AVC msg=audit(1226874073.147:96): avc:  denied  { getattr } for pid=2465 comm="httpd"
path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 
tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file

type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13 
a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48
gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd"
exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)

msg=audit(1226874073.147:96)
- The number in parentheses is the unformatted time stamp (Epoch time) for the event, which can be converted to standard time by using the date command.
{ getattr }
- The item in braces indicates the permission that was denied. getattr indicates the source process was trying to read the target file's status information. This occurs before reading files. This action is denied due to the file being accessed having the wrong label. Commonly seen permissions include getattr, read, and write.
comm="httpd"
- The executable that launched the process. The full path of the executable is found in the exe= section of the system call (SYSCALL) message, which in this case, is exe="/usr/sbin/httpd".
path="/var/www/html/file1"
- The path to the object (target) the process attempted to access.
scontext="unconfined_u:system_r:httpd_t:s0"
- The SELinux context of the process that attempted the denied action. In this case, it is the SELinux context of the Apache HTTP Server, which is running in the httpd_t domain.
tcontext="unconfined_u:object_r:samba_share_t:s0"
- The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of file1. Note: the samba_share_t type is not accessible to processes running in the httpd_t domain.
From the system call (SYSCALL) message, two items are of interest:
- success=no: indicates whether the denial (AVC) was enforced or not. success=no indicates the system call was not successful (SELinux denied access). success=yes indicates the system call was successful - this can be seen for permissive domains or unconfined domains, such as initrc_t and kernel_t.
- exe="/usr/sbin/httpd": the full path to the executable that launched the process, which in this case, is exe="/usr/sbin/httpd".

contains 30 rules

Configure auditd Data Retentiongroup

The audit system writes data to /var/log/audit/audit.log. By default, auditd rotates 5 logs by size (6MB), retaining a maximum of 30MB of data in total, and refuses to write entries when the disk is too full. This minimizes the risk of audit data filling its partition and impacting other services. This also minimizes the risk of the audit daemon temporarily disabling the system if it cannot write audit log (which it can be configured to do). For a busy system or a system which is thoroughly auditing system activity, the default settings for data retention may be insufficient. The log file size needed will depend heavily on what types of events are being audited. First configure auditing to log all the events of interest. Then monitor the log size manually for awhile to determine what file size will allow you to keep the required data for the correct time period.

Using a dedicated partition for /var/log/audit prevents the auditd logs from disrupting system functionality if they fill, and, more importantly, prevents other activity in /var from filling the partition and stopping the audit trail. (The audit logs are size-limited and therefore unlikely to grow without bound unless configured to do so.) Some machines may have requirements that no actions occur which cannot be audited. If this is the case, then auditd can be configured to halt the machine if it runs out of space. Note: Since older logs are rotated, configuring auditd this way does not prevent older logs from being rotated away before they can be viewed. If your system is configured to halt when logging cannot be performed, make sure this can never happen under normal circumstances! Ensure that /var/log/audit is on its own partition, and that this partition is larger than the maximum amount of data auditd will retain normally.

references: AU-11, 138

Configure auditd Rules for Comprehensive Auditinggroup

The auditd program can perform comprehensive monitoring of system activity. This section describes recommended configuration settings for comprehensive auditing, but a full description of the auditing system's capabilities is beyond the scope of this guide. The mailing list linux-audit@redhat.com exists to facilitate community discussion of the auditing system.

The audit subsystem supports extensive collection of events, including:

Tracing of arbitrary system calls (identified by name or number) on entry or exit.
Filtering by PID, UID, call success, system call argument (with some limitations), etc.
Monitoring of specific files for modifications to the file's contents or metadata.

Auditing rules at startup are controlled by the file /etc/audit/audit.rules. Add rules to it to meet the auditing requirements for your organization. Each line in /etc/audit/audit.rules represents a series of arguments that can be passed to auditctl and can be individually tested during runtime. See documentation in /usr/share/doc/audit-VERSION and in the related man pages for more details.

If copying any example audit rulesets from /usr/share/doc/audit-VERSION, be sure to comment out the lines containing arch= which are not appropriate for your system's architecture. Then review and understand the following rules, ensuring rules are activated as needed for the appropriate architecture.

After reviewing all the rules, reading the following sections, and editing as needed, the new rules can be activated as follows:

# service auditd restart

contains 28 rules

Records Events that Modify Date and Time Informationgroup

Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time. All changes to the system time should be audited.

contains 5 rules

Record attempts to alter time through adjtimexrule

On a 32-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b32 -S adjtimex -k audit_time_rules

On a 64-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b64 -S adjtimex -k audit_time_rules

The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls:

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules

identifiers: CCE-26242-8

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 1487, 169

Record attempts to alter time through settimeofdayrule

On a 32-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b32 -S settimeofday -k audit_time_rules

On a 64-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b64 -S settimeofday -k audit_time_rules

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules

identifiers: CCE-27203-9

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 1487, 169

Record Attempts to Alter Time Through stimerule

On a 32-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b32 -S stime -k audit_time_rules

On a 64-bit system, the "-S stime" is not necessary. The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls:

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules

identifiers: CCE-27169-2

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 1487, 169

Record Attempts to Alter Time Through clock_settimerule

On a 32-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b32 -S clock_settime -k audit_time_rules

On a 64-bit system, add the following to /etc/audit/audit.rules:

# audit_time_rules
-a always,exit -F arch=b64 -S clock_settime -k audit_time_rules

-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules

identifiers: CCE-27170-0

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 1487, 169

Record Attempts to Alter the localtime Filerule

Add the following to /etc/audit/audit.rules:

-w /etc/localtime -p wa -k audit_time_rules

The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport and should always be used.

identifiers: CCE-27172-6

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 1487, 169

Record Events that Modify the System's Discretionary Access Controlsgroup

At a minimum the audit system should collect file permission changes for all users and root. Note that the "-F arch=b32" lines should be present even on a 64 bit system. These commands identify system calls for auditing. Even if the system is 64 bit it can still execute 32 bit system calls. Additionally, these rules can be configured in a number of ways while still achieving the desired effect. An example of this is that the "-S" calls could be split up and placed on separate lines, however, this is less efficient. Add the following to /etc/audit/audit.rules:

-a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod
    -a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod
    -a always,exit -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

If your system is 64 bit then these lines should be duplicated and the arch=b32 replaced with arch=b64 as follows:

-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod
    -a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod
    -a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

contains 13 rules

Record Events that Modify the System's Discretionary Access Controls - chmodrule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules:

-a always,exit -F arch=b32 -S chmod -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

-a always,exit -F arch=b64 -S chmod  -F auid>=500 -F auid!=4294967295 -k perm_mod

identifiers: CCE-26280-8

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - chownrule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules:

-a always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

-a always,exit -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 -k perm_mod

identifiers: CCE-27173-4

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - fchmodrule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules:

-a always,exit -F arch=b32 -S fchmod -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

-a always,exit -F arch=b64 -S fchmod -F auid>=500 -F auid!=4294967295 -k perm_mod

identifiers: CCE-27174-2

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - fchmodatrule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules:

-a always,exit -F arch=b32 -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

-a always,exit -F arch=b64 -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod

identifiers: CCE-27175-9

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - fchownrule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules:

-a always,exit -F arch=b32 -S fchown -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

-a always,exit -F arch=b64 -S fchown -F auid>=500 -F auid!=4294967295 -k perm_mod

identifiers: CCE-27177-5

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - fchownatrule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules:

-a always,exit -F arch=b32 -S fchownat -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

-a always,exit -F arch=b64 -S fchownat -F auid>=500 -F auid!=4294967295 -k perm_mod

identifiers: CCE-27178-3

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - fremovexattrrule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules:

-a always,exit -F arch=b32 -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

-a always,exit -F arch=b64 -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

identifiers: CCE-27179-1

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - fsetxattrrule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules:

-a always,exit -F arch=b32 -S fsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

-a always,exit -F arch=b64 -S fsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

identifiers: CCE-27180-9

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - lchownrule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules:

-a always,exit -F arch=b32 -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

-a always,exit -F arch=b64 -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod

identifiers: CCE-27181-7

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - lremovexattrrule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules:

-a always,exit -F arch=b32 -S lremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

-a always,exit -F arch=b64 -S lremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

identifiers: CCE-27182-5

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - lsetxattrrule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules:

-a always,exit -F arch=b32 -S lsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

-a always,exit -F arch=b64 -S lsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

identifiers: CCE-27183-3

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - removexattrrule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules:

-a always,exit -F arch=b32 -S removexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

-a always,exit -F arch=b64 -S removexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

identifiers: CCE-27184-1

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126

Record Events that Modify the System's Discretionary Access Controls - setxattrrule

At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules:

-a always,exit -F arch=b32 -S setxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

If the system is 64 bit then also add the following:

-a always,exit -F arch=b64 -S setxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

identifiers: CCE-27185-8

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126

Record Events that Modify User/Group Informationrule

Add the following to /etc/audit/audit.rules, in order to capture events that modify account changes:

# audit_account_changes
-w /etc/group -p wa -k audit_account_changes
-w /etc/passwd -p wa -k audit_account_changes
-w /etc/gshadow -p wa -k audit_account_changes
-w /etc/shadow -p wa -k audit_account_changes
-w /etc/security/opasswd -p wa -k audit_account_changes

identifiers: CCE-26664-3

references: AC-2(4), AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 18, 1403, 1404, 1405, 1684, 1683, 1685, 1686

Record Events that Modify the System's Network Environmentrule

Add the following to /etc/audit/audit.rules, setting ARCH to either b32 or b64 as appropriate for your system:

# audit_network_modifications
-a always,exit -F arch=ARCH -S sethostname -S setdomainname -k audit_network_modifications
-w /etc/issue -p wa -k audit_network_modifications
-w /etc/issue.net -p wa -k audit_network_modifications
-w /etc/hosts -p wa -k audit_network_modifications
-w /etc/sysconfig/network -p wa -k audit_network_modifications

identifiers: CCE-26648-6

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5

Record Events that Modify the System's Mandatory Access Controlsrule

Add the following to /etc/audit/audit.rules:

-w /etc/selinux/ -p wa -k MAC-policy

identifiers: CCE-26657-7

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5

Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful)rule

At a minimum the audit system should collect unauthorized file accesses for all users and root. Add the following to /etc/audit/audit.rules:

-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k access
-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access
-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k access
-a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access

identifiers: CCE-26712-0

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126

Ensure auditd Collects Information on the Use of Privileged Commandsrule

At a minimum the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid / setgid programs:

# find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null

Then, for each setuid / setgid program on the system, add a line of the following form to /etc/audit/audit.rules, where SETUID_PROG_PATH is the full path to each setuid / setgid program in the list:

-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged

identifiers: CCE-26457-2

references: AC-3(10)), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AC-6(9), IR-5, 40,

Ensure auditd Collects Information on Exporting to Media (successful)rule

At a minimum the audit system should collect media exportation events for all users and root. Add the following to /etc/audit/audit.rules, setting ARCH to either b32 or b64 as appropriate for your system:

-a always,exit -F arch=ARCH -S mount -F auid>=500 -F auid!=4294967295 -k export

identifiers: CCE-26573-6

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126,

Ensure auditd Collects File Deletion Events by Userrule

At a minimum the audit system should collect file deletion events for all users and root. Add the following to /etc/audit/audit.rules, setting ARCH to either b32 or b64 as appropriate for your system:

-a always,exit -F arch=ARCH -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295 -k delete

identifiers: CCE-26651-0

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126

Ensure auditd Collects System Administrator Actionsrule

At a minimum the audit system should collect administrator actions for all users and root. Add the following to /etc/audit/audit.rules:

-w /etc/sudoers -p wa -k actions

identifiers: CCE-26662-7

references: AC-2(7)(b), AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126,

Ensure auditd Collects Information on Kernel Module Loading and Unloadingrule

Add the following to /etc/audit/audit.rules in order to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system:

-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=ARCH -S init_module -S delete_module -k modules

identifiers: CCE-26611-4

references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, 126

Make the auditd Configuration Immutablerule

Add the following to /etc/audit/audit.rules in order to make the configuration immutable:

-e 2

With this setting, a reboot will be required to change any audit rules.

identifiers: CCE-26612-2

references: AC-6, AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5

Enable auditd Servicerule

The auditd service is an essential userspace component of the Linux Auditing System, as it is responsible for writing audit records to disk. The auditd service can be enabled with the following command: # chkconfig --level 2345 auditd on

identifiers: CCE-27058-7

references: AC-17(1), AU-1(b), AU-10, AU-12(a), AU-12(c), IR-5, 347, 157, 172, 880, 1353, 1462, 1487, 1115, 1454, 067, 158, 831, 1190, 1312, 1263, 130, 120, 1589,

Remediation script:

#
# Enable auditd for all run levels
#
chkconfig --level 0123456 auditd on

#
# Start auditd if not currently running
#
service auditd start

Enable Auditing for Processes Which Start Prior to the Audit Daemonrule

To ensure all processes can be audited, even those which start prior to the audit daemon, add the argument audit=1 to the kernel line in /etc/grub.conf, in the manner below:

kernel /vmlinuz-version ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet audit=1

identifiers: CCE-26785-6

references: AC-17(1), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-10, IR-5, 1464, 130

Remediation script:

/sbin/grubby --update-kernel=ALL --args="audit=1"

Servicesgroup

The best protection against vulnerable software is running less software. This section describes how to review the software which Red Hat Enterprise Linux 6 installs on a system and disable software which is not needed. It then enumerates the software packages installed on a default RHEL 6 system and provides guidance about which ones can be safely disabled.

RHEL 6 provides a convenient minimal install option that essentially installs the bare necessities for a functional system. When building RHEL 6 servers, it is highly recommended to select the minimal packages and then build up the system from there.

contains 56 rules

Obsolete Servicesgroup

This section discusses a number of network-visible services which have historically caused problems for system security, and for which disabling or severely limiting the service has been the best available guidance for some time. As a result of this, many of these services are not installed as part of RHEL 6 by default.

Organizations which are running these services should switch to more secure equivalents as soon as possible. If it remains absolutely necessary to run one of these services for legacy reasons, care should be taken to restrict the service as much as possible, for instance by configuring host firewall software such as iptables to restrict access to the vulnerable service to only those remote hosts which have a known need to use it.

contains 9 rules

Xinetdgroup

The xinetd service acts as a dedicated listener for some network services (mostly, obsolete ones) and can be used to provide access controls and perform some logging. It has been largely obsoleted by other features, and it is not installed by default. The older Inetd service is not even available as part of RHEL 6.

contains 2 rules

Disable xinetd Servicerule

The xinetd service can be disabled with the following command: # chkconfig xinetd off

identifiers: CCE-27046-2

references: CM-7, 305,

Uninstall xinetd Packagerule

The xinetd package can be uninstalled with the following command:

# yum erase xinetd

identifiers: CCE-27005-8

references: CM-7, 305,

Remediation script:

if rpm -qa | grep -q xinetd; then
	yum -y remove xinetd
fi

Telnetgroup

The telnet protocol does not provide confidentiality or integrity for information transmitted on the network. This includes authentication information such as passwords. Organizations which use telnet should be actively working to migrate to a more secure protocol.

contains 2 rules

Disable telnet Servicerule

The telnet service can be disabled with the following command: # chkconfig telnet off

identifiers: CCE-26836-7

references: CM-7, IA-5(1)(c), 68, 1436, 197, 877, 888,

Uninstall telnet-server Packagerule

The telnet-server package can be uninstalled with the following command:

# yum erase telnet-server

identifiers: CCE-27073-6

references: CM-7, 305, 381,

Remediation script:

if rpm -qa | grep -q telnet-server; then
	yum -y remove telnet-server
fi

Rlogin, Rsh, and Rexecgroup

The Berkeley r-commands are legacy services which allow cleartext remote access and have an insecure trust model.

contains 1 rule

Uninstall rsh-server Packagerule

The rsh-server package can be uninstalled with the following command:

# yum erase rsh-server

identifiers: CCE-27062-9

references: CM-7, 305, 381,

NISgroup

The Network Information Service (NIS), also known as 'Yellow Pages' (YP), and its successor NIS+ have been made obsolete by Kerberos, LDAP, and other modern centralized authentication services. NIS should not be used because it suffers from security problems inherent in its design, such as inadequate protection of important authentication information.

contains 2 rules

Uninstall ypserv Packagerule

The ypserv package can be uninstalled with the following command:

# yum erase ypserv

identifiers: CCE-27079-3

references: CM-7, 305, 381,

Remediation script:

if rpm -qa | grep -q ypserv; then
	yum -y remove ypserv
fi

Disable ypbind Servicerule

The ypbind service, which allows the system to act as a client in a NIS or NIS+ domain, should be disabled. The ypbind service can be disabled with the following command: # chkconfig ypbind off

identifiers: CCE-26894-6

references: CM-7, 305,

TFTP Servergroup

TFTP is a lightweight version of the FTP protocol which has traditionally been used to configure networking equipment. However, TFTP provides little security, and modern versions of networking operating systems frequently support configuration via SSH or other more secure protocols. A TFTP server should be run only if no more secure method of supporting existing equipment can be found.

contains 2 rules

Disable tftp Servicerule

The tftp service should be disabled. The tftp service can be disabled with the following command: # chkconfig tftp off

identifiers: CCE-27055-3

references: CM-7, 1436,

Uninstall tftp-server Packagerule

The tftp-server package can be removed with the following command: # yum erase tftp-server

identifiers: CCE-26946-4

references: CM-7, 305,

Chat/Messaging Servicesgroup

The talk software makes it possible for users to send and receive messages across systems through a terminal session.

Base Servicesgroup

This section addresses the base services that are installed on a RHEL 6 default installation which are not covered in other sections. Some of these services listen on the network and should be treated with particular discretion. Other services are local system utilities that may or may not be extraneous. In general, system services should be disabled if not required.

contains 3 rules

Disable KDump Kernel Crash Analyzer (kdump)rule

The kdump service provides a kernel crash dump analyzer. It uses the kexec system call to boot a secondary kernel ("capture" kernel) following a system crash, which can load information from the crashed kernel for analysis. The kdump service can be disabled with the following command: # chkconfig kdump off

identifiers: CCE-26850-8

references: CM-7

Remediation script:

#
# Disable kdump for all run levels
#
chkconfig --level 0123456 kdump off

#
# Stop kdump if currently running
#
service kdump stop

Disable Portreserve (portreserve)rule

The portreserve service is a TCP port reservation utility that can be used to prevent portmap from binding to well known TCP ports that are required for other services. The portreserve service can be disabled with the following command: # chkconfig portreserve off

identifiers: CCE-27258-3

references: CM-7,

Remediation script:

#
# Disable portreserve for all run levels
#
chkconfig --level 0123456 portreserve off

#
# Stop portreserve if currently running
#
service portreserve stop

Disable Red Hat Network Service (rhnsd)rule

The Red Hat Network service automatically queries Red Hat Network servers to determine whether there are any actions that should be executed, such as package updates. This only occurs if the system was registered to an RHN server or satellite and managed as such. The rhnsd service can be disabled with the following command: # chkconfig rhnsd off

identifiers: CCE-26846-6

references: CM-7, 382,

Remediation script:

#
# Disable rhnsd for all run levels
#
chkconfig --level 0123456 rhnsd off

#
# Stop rhnsd if currently running
#
service rhnsd stop

Cron and At Daemonsgroup

The cron and at services are used to allow commands to be executed at a later time. The cron service is required by almost all systems to perform necessary maintenance tasks, while at may or may not be required on a given system. Both daemons should be configured defensively.

contains 2 rules

Restrict at and cron to Authorized Users if Necessarygroup

The /etc/cron.allow and /etc/at.allow files contain lists of users who are allowed to use cron and at to delay execution of processes. If these files exist and if the corresponding files /etc/cron.deny and /etc/at.deny do not exist, then only users listed in the relevant allow files can run the crontab and at commands to submit jobs to be run at scheduled intervals. On many systems, only the system administrator needs the ability to schedule jobs. Note that even if a given user is not listed in cron.allow, cron jobs can still be run as that user. The cron.allow file controls only administrative access to the crontab command for scheduling and modifying cron jobs.

To restrict at and cron to only authorized users:

Remove the cron.deny file:
```
# rm /etc/cron.deny
```
Edit /etc/cron.allow, adding one line for each user allowed to use the crontab command to create cron jobs.
Remove the at.deny file:
```
# rm /etc/at.deny
```
Edit /etc/at.allow, adding one line for each user allowed to use the at command to create at jobs.

Enable cron Servicerule

The crond service is used to execute commands at preconfigured times. It is required by almost all systems to perform necessary maintenance tasks, such as notifying root of system activity. The crond service can be enabled with the following command: # chkconfig --level 2345 crond on

identifiers: CCE-27070-2

references: CM-7,

Remediation script:

#
# Enable crond for all run levels
#
chkconfig --level 0123456 crond on

#
# Start crond if not currently running
#
service crond start

Disable At Service (atd)rule

The at and batch commands can be used to schedule tasks that are meant to be executed only once. This allows delayed execution in a manner similar to cron, except that it is not recurring. The daemon atd keeps track of tasks scheduled via at and batch, and executes them at the specified time. The atd service can be disabled with the following command: # chkconfig atd off

identifiers: CCE-27249-2

references: CM-7, 381

Remediation script:

#
# Disable atd for all run levels
#
chkconfig --level 0123456 atd off

#
# Stop atd if currently running
#
service atd stop

SSH Servergroup

The SSH protocol is recommended for remote login and remote file transfer. SSH provides confidentiality and integrity for data exchanged between two systems, as well as server authentication, through the use of public key cryptography. The implementation included with the system is called OpenSSH, and more detailed documentation is available from its website, http://www.openssh.org. Its server program is called sshd and provided by the RPM package openssh-server.

contains 10 rules

Configure OpenSSH Server if Necessarygroup

If the system needs to act as an SSH server, then certain changes should be made to the OpenSSH daemon configuration file /etc/ssh/sshd_config. The following recommendations can be applied to this file. See the sshd_config(5) man page for more detailed information.

contains 10 rules

Strengthen Firewall Configuration if Possiblegroup

If the SSH server is expected to only receive connections from the local network, then strengthen the default firewall rule for the SSH service to only accept connections from the appropriate network segment(s).

Determine an appropriate network block, netwk, and network mask, mask, representing the machines on your network which will be allowed to access this SSH server.

Edit the files etc/sysconfig/iptables and /etc/sysconfig/ip6tables (if IPv6 is in use). In each file, locate the line:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

and replace it with:

-A INPUT -s netwk/mask -m state --state NEW -p tcp --dport 22 -j ACCEPT

Allow Only SSH Protocol 2rule

Only SSH protocol version 2 connections should be permitted. The default setting in /etc/ssh/sshd_config is correct, and can be verified by ensuring that the following line appears:

Protocol 2

identifiers: CCE-27072-8

references: AC-3(10), IA-5(1)(c), 776, 774, 1436,

Set SSH Idle Timeout Intervalrule

SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out.

To set an idle timeout interval, edit the following line in /etc/ssh/sshd_config as follows:

ClientAliveInterval interval

The timeout interval is given in seconds. To have a timeout of 15 minutes, set interval to 900.

If a shorter timeout has already been set for the login shell, that value will preempt any SSH setting made here. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle.

identifiers: CCE-26919-1

references: 879, 1133,

Remediation script:

sshd_idle_timeout_value="(N/A)"
grep -q ^ClientAliveInterval /etc/ssh/sshd_config && \
  sed -i "s/ClientAliveInterval.*/ClientAliveInterval $sshd_idle_timeout_value/g" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
    echo "ClientAliveInterval $sshd_idle_timeout_value" >> /etc/ssh/sshd_config
fi

Set SSH Client Alive Countrule

To ensure the SSH idle timeout occurs precisely when the ClientAliveCountMax is set, edit /etc/ssh/sshd_config as follows:

ClientAliveCountMax 0

identifiers: CCE-26282-4

references: 879, 1133,

Remediation script:

grep -q ^ClientAliveCountMax /etc/ssh/sshd_config && \
  sed -i "s/ClientAliveCountMax.*/ClientAliveCountMax 0/g" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
    echo "ClientAliveCountMax 0" >> /etc/ssh/sshd_config
fi

Disable SSH Support for .rhosts Filesrule

SSH can emulate the behavior of the obsolete rsh command in allowing users to enable insecure access to their accounts via .rhosts files.

To ensure this behavior is disabled, add or correct the following line in /etc/ssh/sshd_config:

IgnoreRhosts yes

identifiers: CCE-27124-7

references: 765, 766

Remediation script:

grep -q ^IgnoreRhosts /etc/ssh/sshd_config && \
  sed -i "s/IgnoreRhosts.*/IgnoreRhosts yes/g" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
    echo "IgnoreRhosts yes" >> /etc/ssh/sshd_config
fi

Disable Host-Based Authenticationrule

SSH's cryptographic host-based authentication is more secure than .rhosts authentication. However, it is not recommended that hosts unilaterally trust one another, even within an organization.

To disable host-based authentication, add or correct the following line in /etc/ssh/sshd_config:

HostbasedAuthentication no

identifiers: CCE-27091-8

references: 765, 766,

Remediation script:

grep -q ^HostbasedAuthentication /etc/ssh/sshd_config && \
  sed -i "s/HostbasedAuthentication.*/HostbasedAuthentication no/g" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
    echo "HostbasedAuthentication no" >> /etc/ssh/sshd_config
fi

Disable SSH Root Loginrule

The root user should never be allowed to login to a system directly over a network. To disable root login via SSH, add or correct the following line in /etc/ssh/sshd_config:

PermitRootLogin no

identifiers: CCE-27100-7

references: AC-6(2), IA-2(1), 770,

Remediation script:

grep -q ^PermitRootLogin /etc/ssh/sshd_config && \
  sed -i "s/PermitRootLogin.*/PermitRootLogin no/g" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
    echo "PermitRootLogin "no >> /etc/ssh/sshd_config
fi

Disable SSH Access via Empty Passwordsrule

To explicitly disallow remote login from accounts with empty passwords, add or correct the following line in /etc/ssh/sshd_config:

PermitEmptyPasswords no

Any accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords.

identifiers: CCE-26887-0

references: 765, 766,

Remediation script:

grep -q ^PermitEmptyPasswords /etc/ssh/sshd_config && \
  sed -i "s/PermitEmptyPasswords.*/PermitEmptyPasswords no/g" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
    echo "PermitEmptyPasswords no" >> /etc/ssh/sshd_config
fi

Enable SSH Warning Bannerrule

To enable the warning banner and ensure it is consistent across the system, add or correct the following line in /etc/ssh/sshd_config:

Banner /etc/issue

Another section contains information on how to create an appropriate system-wide warning banner.

identifiers: CCE-27112-2

references: 48,

Remediation script:

grep -q ^Banner /etc/ssh/sshd_config && \
  sed -i "s/Banner.*/Banner \/etc\/issue/g" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
    echo "Banner /etc/issue" >> /etc/ssh/sshd_config
fi

Do Not Allow SSH Environment Optionsrule

To ensure users are not able to present environment options to the SSH daemon, add or correct the following line in /etc/ssh/sshd_config:

PermitUserEnvironment no

identifiers: CCE-27201-3

references: 1414,

Remediation script:

grep -q ^PermitUserEnvironment /etc/ssh/sshd_config && \
  sed -i "s/PermitUserEnvironment.*/PermitUserEnvironment no/g" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
    echo "PermitUserEnvironment no" >> /etc/ssh/sshd_config
fi

Use Only Approved Ciphersrule

Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

The man page sshd_config(5) contains a list of supported ciphers.

identifiers: CCE-26555-3

references: AC-3, AC-17(2), SI-7, IA-5(1)(c), IA-7, 803, 1144, 1145, 1146,

Remediation script:

grep -q ^Ciphers /etc/ssh/sshd_config && \
  sed -i "s/Ciphers.*/Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc/g" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
    echo "Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc" >> /etc/ssh/sshd_config
fi

X Window Systemgroup

The X Window System implementation included with the system is called X.org.

Disable X Windowsgroup

Unless there is a mission-critical reason for the system to run a graphical user interface, ensure X is not set to start automatically at boot and remove the X Windows software packages. There is usually no reason to run X Windows on a dedicated server machine, as it increases the system's attack surface and consumes system resources. Administrators of server systems should instead login via SSH or on the text console.

Avahi Servergroup

The Avahi daemon implements the DNS Service Discovery and Multicast DNS protocols, which provide service and host discovery on a network. It allows a system to automatically identify resources on the network, such as printers or web servers. This capability is also known as mDNSresponder and is a major part of Zeroconf networking.

contains 1 rule

Disable Avahi Server if Possiblegroup

Because the Avahi daemon service keeps an open network port, it is subject to network attacks. Disabling it can reduce the system's vulnerability to such attacks.

contains 1 rule

Disable Avahi Server Softwarerule

The avahi-daemon service can be disabled with the following command: # chkconfig avahi-daemon off

identifiers: CCE-27087-6

references: CM-7, 366

Configure Avahi if Necessarygroup

If your system requires the Avahi daemon, its configuration can be restricted to improve security. The Avahi daemon configuration file is /etc/avahi/avahi-daemon.conf. The following security recommendations should be applied to this file: See the avahi-daemon.conf(5) man page, or documentation at http://www.avahi.org, for more detailed information about the configuration options.

Print Supportgroup

The Common Unix Printing System (CUPS) service provides both local and network printing support. A system running the CUPS service can accept print jobs from other systems, process them, and send them to the appropriate printer. It also provides an interface for remote administration through a web browser. The CUPS service is installed and activated by default. The project homepage and more detailed documentation are available at http://www.cups.org.

Configure the CUPS Service if Necessarygroup

CUPS provides the ability to easily share local printers with other machines over the network. It does this by allowing machines to share lists of available printers. Additionally, each machine that runs the CUPS service can potentially act as a print server. Whenever possible, the printer sharing and print server capabilities of CUPS should be limited or disabled. The following recommendations should demonstrate how to do just that.

DHCPgroup

The Dynamic Host Configuration Protocol (DHCP) allows systems to request and obtain an IP address and other configuration parameters from a server.

This guide recommends configuring networking on clients by manually editing the appropriate files under /etc/sysconfig. Use of DHCP can make client systems vulnerable to compromise by rogue DHCP servers, and should be avoided unless necessary. If using DHCP is necessary, however, there are best practices that should be followed to minimize security risk.

contains 2 rules

Disable DHCP Servergroup

The DHCP server dhcpd is not installed or activated by default. If the software was installed and activated, but the system does not need to act as a DHCP server, it should be disabled and removed.

contains 2 rules

Disable DHCP Servicerule

The dhcpd service should be disabled on any system that does not need to act as a DHCP server. The dhcpd service can be disabled with the following command: # chkconfig dhcpd off

identifiers: CCE-27074-4

references: CM-7, 366,

Uninstall DHCP Server Packagerule

If the system does not need to act as a DHCP server, the dhcp package can be uninstalled. The dhcp package can be removed with the following command: # yum erase dhcp

identifiers: CCE-27120-5

references: CM-7, 366,

Disable DHCP Servergroup

If the system must act as a DHCP server, the configuration information it serves should be minimized. Also, support for other protocols and DNS-updating schemes should be explicitly disabled unless needed. The configuration file for dhcpd is called /etc/dhcp/dhcpd.conf. The file begins with a number of global configuration options. The remainder of the file is divided into sections, one for each block of addresses offered by dhcpd, each of which contains configuration options specific to that address block.

Minimize Served Informationgroup

Edit /etc/dhcp/dhcpd.conf. Examine each address range section within the file, and ensure that the following options are not defined unless there is an operational need to provide this information via DHCP:

option domain-name
option domain-name-servers
option nis-domain
option nis-servers
option ntp-servers
option routers
option time-offset

references: CM-7

Disable DHCP Clientgroup

DHCP is the default network configuration method provided by the system installer, and common on many networks. Nevertheless, manual management of IP addresses for systems implies a greater degree of management and accountability for network activity.

Configure DHCP Client if Necessarygroup

If DHCP must be used, then certain configuration changes can minimize the amount of information it receives and applies from the network, and thus the amount of incorrect information a rogue DHCP server could successfully distribute. For more information on configuring dhclient, see the dhclient(8) and dhclient.conf(5) man pages.

Minimize the DHCP-Configured Optionsgroup

Create the file /etc/dhcp/dhclient.conf, and add an appropriate setting for each of the ten configuration settings which can be obtained via DHCP. For each setting, do one of the following:

If the setting should not be configured remotely by the DHCP server, select an appropriate static value, and add the line:

supersede setting value;

If the setting should be configured remotely by the DHCP server, add the lines:

request setting;
require setting;

For example, suppose the DHCP server should provide only the IP address itself and the subnet mask. Then the entire file should look like:

supersede domain-name "example.com";
supersede domain-name-servers 192.168.1.2;
supersede nis-domain "";
supersede nis-servers "";
supersede ntp-servers "ntp.example.com ";
supersede routers 192.168.1.1;
supersede time-offset -18000;
request subnet-mask;
require subnet-mask;

Network Time Protocolgroup

The Network Time Protocol is used to manage the system clock over a network. Computer clocks are not very accurate, so time will drift unpredictably on unmanaged systems. Central time protocols can be used both to ensure that time is consistent among a network of machines, and that their time is consistent with the outside world.

If every system on a network reliably reports the same time, then it is much easier to correlate log messages in case of an attack. In addition, a number of cryptographic protocols (such as Kerberos) use timestamps to prevent certain types of attacks. If your network does not have synchronized time, these protocols may be unreliable or even unusable.

Depending on the specifics of the network, global time accuracy may be just as important as local synchronization, or not very important at all. If your network is connected to the Internet, using a public timeserver (or one provided by your enterprise) provides globally accurate timestamps which may be essential in investigating or responding to an attack which originated outside of your network.

A typical network setup involves a small number of internal systems operating as NTP servers, and the remainder obtaining time information from those internal servers.

More information on how to configure the NTP server software, including configuration of cryptographic authentication for time data, is available at http://www.ntp.org.

contains 2 rules

Enable the NTP Daemonrule

The ntpd service can be enabled with the following command: # chkconfig --level 2345 ntpd on

identifiers: CCE-27093-4

references: AU-8(1), 160,

Remediation script:

#
# Enable ntpd for all run levels
#
chkconfig --level 0123456 ntpd on

#
# Start ntpd if not currently running
#
service ntpd start

Specify a Remote NTP Serverrule

To specify a remote NTP server for time synchronization, edit the file /etc/ntp.conf. Add or correct the following lines, substituting the IP or hostname of a remote NTP server for ntpserver:

server ntpserver

This instructs the NTP software to contact that remote server to obtain time data.

identifiers: CCE-27098-3

references: AU-8(1), 160,

Mail Server Softwaregroup

Mail servers are used to send and receive email over the network. Mail is a very common service, and Mail Transfer Agents (MTAs) are obvious targets of network attack. Ensure that machines are not running MTAs unnecessarily, and configure needed MTAs as defensively as possible.

Very few systems at any site should be configured to directly receive email over the network. Users should instead use mail client programs to retrieve email from a central server that supports protocols such as IMAP or POP3. However, it is normal for most systems to be independently capable of sending email, for instance so that cron jobs can report output to an administrator. Most MTAs, including Postfix, support a submission-only mode in which mail can be sent from the local system to a central site MTA (or directly delivered to a local account), but the system still cannot receive mail directly over a network.

The alternatives program in RHEL permits selection of other mail server software (such as Sendmail), but Postfix is the default and is preferred. Postfix was coded with security in mind and can also be more effectively contained by SELinux as its modular design has resulted in separate processes performing specific actions. More information is available on its website, http://www.postfix.org.

contains 2 rules

Configure SMTP For Mail Clientsgroup

This section discusses settings for Postfix in a submission-only e-mail configuration.

contains 1 rule

Disable Postfix Network Listeningrule

Edit the file /etc/postfix/main.cf to ensure that only the following inet_interfaces line appears:

inet_interfaces = localhost

identifiers: CCE-26780-7

references: CM-7, 382,

Configure Operating System to Protect Mail Server group

The guidance in this section is appropriate for any host which is operating as a site MTA, whether the mail server runs using Sendmail, Postfix, or some other software.

Configure SSL Certificates for Use with SMTP AUTHgroup

If SMTP AUTH is to be used, the use of SSL to protect credentials in transit is strongly recommended. There are also configurations for which it may be desirable to encrypt all mail in transit from one MTA to another, though such configurations are beyond the scope of this guide. In either event, the steps for creating and installing an SSL certificate are independent of the MTA in use, and are described here.

Ensure Security of Postfix SSL Certificategroup

Create the PKI directory for mail certificates, if it does not already exist:

# mkdir /etc/pki/tls/mail
# chown root:root /etc/pki/tls/mail
# chmod 755 /etc/pki/tls/mail

Using removable media or some other secure transmission format, install the files generated in the previous step onto the mail server:

/etc/pki/tls/mail/serverkey.pem: the private key mailserverkey.pem
/etc/pki/tls/mail/servercert.pem: the certificate file mailservercert.pem

Verify the ownership and permissions of these files:

# chown root:root /etc/pki/tls/mail/serverkey.pem
# chown root:root /etc/pki/tls/mail/servercert.pem
# chmod 600 /etc/pki/tls/mail/serverkey.pem
# chmod 644 /etc/pki/tls/mail/servercert.pem

Verify that the CA's public certificate file has been installed as /etc/pki/tls/CA/cacert.pem, and has the correct permissions:

# chown root:root /etc/pki/tls/CA/cacert.pem
# chmod 644 /etc/pki/tls/CA/cacert.pem

Configure Postfix if Necessarygroup

Postfix stores its configuration files in the directory /etc/postfix by default. The primary configuration file is /etc/postfix/main.cf.

Configure Postfix Resource Usage to Limit Denial of Service Attacksgroup

Edit /etc/postfix/main.cf. Edit the following lines to configure the amount of system resources Postfix can consume:

default_process_limit = 100
smtpd_client_connection_count_limit = 10
smtpd_client_connection_rate_limit = 30
queue_minfree = 20971520
header_size_limit = 51200
message_size_limit = 10485760
smtpd_recipient_limit = 100

The values here are examples.

Control Mail Relayinggroup

Postfix's mail relay controls are implemented with the help of the smtpd recipient restrictions option, which controls the restrictions placed on the SMTP dialogue once the sender and recipient envelope addresses are known. The guidance in the following sections should be applied to all machines. If there are machines which must be allowed to relay mail, but which cannot be trusted to relay unconditionally, configure SMTP AUTH with SSL support.

Configure Trusted Networks and Hostsgroup

Edit /etc/postfix/main.cf, and configure the contents of the mynetworks variable in one of the following ways:

If any machine in the subnet containing the MTA may be trusted to relay messages, add or correct the following line:
```
mynetworks_style = subnet
```
This is also the default setting, and is in effect if all my_networks_style directives are commented.
If only the MTA host itself is trusted to relay messages, add or correct the following line:
```
mynetworks_style = host
```
If the set of machines which can relay is more complicated, manually specify an entry for each netblock or IP address which is trusted to relay by setting the mynetworks variable directly:
```
mynetworks = 10.0.0.0/16, 192.168.1.0/24, 127.0.0.1
```

Enact SMTP Relay Restrictionsgroup

To configure Postfix to restrict addresses to which it will send mail, see: http://www.postfix.org/SMTPD_ACCESS_README.html#danger

The full contents of smtpd_recipient_restrictions will vary by site, since this is a common place to put spam restrictions and other site-specific options. The permit_mynetworks option allows all mail to be relayed from the machines in mynetworks. Then, the reject_unauth_destination option denies all mail whose destination address is not local, preventing any other machines from relaying. These two options should always appear in this order, and should usually follow one another immediately unless SMTP AUTH is used.

Enact SMTP Recipient Restrictionsgroup

Require SMTP AUTH Before Relaying from Untrusted Clientsgroup

SMTP authentication allows remote clients to relay mail safely by requiring them to authenticate before submitting mail. Postfix's SMTP AUTH uses an authentication library called SASL, which is not part of Postfix itself. To enable the use of SASL authentication, see http://www.postfix.org/SASL_README.html

Use TLS for SMTP AUTHgroup

Postfix provides options to use TLS for certificate-based authentication and encrypted sessions. An encrypted session protects the information that is transmitted with SMTP mail or with SASL authentication. To configure Postfix to protect all SMTP AUTH transactions using TLS, see http://www.postfix.org/TLS_README.html.

Uninstall Sendmail Packagerule

Sendmail is not the default mail transfer agent and is not installed by default. The sendmail package can be removed with the following command: # yum erase sendmail

identifiers: CCE-27515-6

references: CM-7,

LDAPgroup

LDAP is a popular directory service, that is, a standardized way of looking up information from a central database. RHEL 6 includes software that enables a system to act as both an LDAP client and server.

contains 3 rules

Configure OpenLDAP Clientsgroup

This section provides information on which security settings are important to configure in OpenLDAP clients by manually editing the appropriate configuration files. RHEL 6 provides an automated configuration tool called authconfig and a graphical wrapper for authconfig called system-config-authentication. However, these tools do not provide as much control over configuration as manual editing of configuration files. The authconfig tools do not allow you to specify locations of SSL certificate files, which is useful when trying to use SSL cleanly across several protocols. Installation and configuration of OpenLDAP on RHEL 6 is available at https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Directory_Servers.html.

contains 2 rules

Configure LDAP Client to Use TLS For All Transactionsrule

Configure LDAP to enforce TLS use. First, edit the file /etc/pam_ldap.conf, and add or correct the following lines:

ssl start_tls

Then review the LDAP server and ensure TLS has been configured.

identifiers: CCE-26690-8

references: CM-7, 776, 778, 1453,

Configure Certificate Directives for LDAP Use of TLSrule

Ensure a copy of a trusted CA certificate has been placed in the file /etc/pki/tls/CA/cacert.pem. Configure LDAP to enforce TLS use and to trust certificates signed by that CA. First, edit the file /etc/pam_ldap.conf, and add or correct either of the following lines:

tls_cacertdir /etc/pki/tls/CA

tls_cacertfile /etc/pki/tls/CA/cacert.pem

Then review the LDAP server and ensure TLS has been configured.

identifiers: CCE-27189-0

references: CM-7, 776, 778, 1453,

Configure OpenLDAP Servergroup

This section details some security-relevant settings for an OpenLDAP server. Installation and configuration of OpenLDAP on RHEL 6 is available at: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Directory_Servers.html.

contains 1 rule

Install and Protect LDAP Certificate Filesgroup

Create the PKI directory for LDAP certificates if it does not already exist:

# mkdir /etc/pki/tls/ldap
# chown root:root /etc/pki/tls/ldap
# chmod 755 /etc/pki/tls/ldap

Using removable media or some other secure transmission format, install the certificate files onto the LDAP server:

/etc/pki/tls/ldap/serverkey.pem: the private key ldapserverkey.pem
/etc/pki/tls/ldap/servercert.pem: the certificate file ldapservercert.pem

Verify the ownership and permissions of these files:

# chown root:ldap /etc/pki/tls/ldap/serverkey.pem
# chown root:ldap /etc/pki/tls/ldap/servercert.pem
# chmod 640 /etc/pki/tls/ldap/serverkey.pem
# chmod 640 /etc/pki/tls/ldap/servercert.pem

Verify that the CA's public certificate file has been installed as /etc/pki/tls/CA/cacert.pem, and has the correct permissions:

# mkdir /etc/pki/tls/CA
# chown root:root /etc/pki/tls/CA/cacert.pem
# chmod 644 /etc/pki/tls/CA/cacert.pem

As a result of these steps, the LDAP server will have access to its own private certificate and the key with which that certificate is encrypted, and to the public certificate file belonging to the CA. Note that it would be possible for the key to be protected further, so that processes running as ldap could not read it. If this were done, the LDAP server process would need to be restarted manually whenever the server rebooted.

Uninstall openldap-servers Packagerule

The openldap-servers package should be removed if not in use. Is this machine the OpenLDAP server? If not, remove the package.

# yum erase openldap-servers

The openldap-servers RPM is not installed by default on RHEL 6 machines. It is needed only by the OpenLDAP server, not by the clients which use LDAP for authentication. If the system is not intended for use as an LDAP Server it should be removed.

identifiers: CCE-26858-1

references: CM-7, 366,

NFS and RPCgroup

The Network File System is a popular distributed filesystem for the Unix environment, and is very widely deployed. This section discusses the circumstances under which it is possible to disable NFS and its dependencies, and then details steps which should be taken to secure NFS's configuration. This section is relevant to machines operating as NFS clients, as well as to those operating as NFS servers.

contains 7 rules

Disable All NFS Services if Possiblegroup

If there is not a reason for the system to operate as either an NFS client or an NFS server, follow all instructions in this section to disable subsystems required by NFS.

contains 4 rules

Disable Services Used Only by NFSgroup

If NFS is not needed, disable the NFS client daemons nfslock, rpcgssd, and rpcidmapd.

All of these daemons run with elevated privileges, and many listen for network connections. If they are not needed, they should be disabled to improve system security posture.

contains 3 rules

Disable Network File System Lock Service (nfslock)rule

The Network File System Lock (nfslock) service starts the required remote procedure call (RPC) processes which allow clients to lock files on the server. If the local machine is not configured to mount NFS filesystems then this service should be disabled. The nfslock service can be disabled with the following command: # chkconfig nfslock off

identifiers: CCE-27104-9

Remediation script:

#
# Disable nfslock for all run levels
#
chkconfig --level 0123456 nfslock off

#
# Stop nfslock if currently running
#
service nfslock stop

Disable Secure RPC Client Service (rpcgssd)rule

The rpcgssd service manages RPCSEC GSS contexts required to secure protocols that use RPC (most often Kerberos and NFS). The rpcgssd service is the client-side of RPCSEC GSS. If the system does not require secure RPC then this service should be disabled. The rpcgssd service can be disabled with the following command: # chkconfig rpcgssd off

identifiers: CCE-26864-9

Remediation script:

#
# Disable rpcgssd for all run levels
#
chkconfig --level 0123456 rpcgssd off

#
# Stop rpcgssd if currently running
#
service rpcgssd stop

Disable RPC ID Mapping Service (rpcidmapd)rule

The rpcidmapd service is used to map user names and groups to UID and GID numbers on NFSv4 mounts. If NFS is not in use on the local system then this service should be disabled. The rpcidmapd service can be disabled with the following command: # chkconfig rpcidmapd off

identifiers: CCE-26870-6

Remediation script:

#
# Disable rpcidmapd for all run levels
#
chkconfig --level 0123456 rpcidmapd off

#
# Stop rpcidmapd if currently running
#
service rpcidmapd stop

Disable netfs if Possiblegroup

To determine if any network filesystems handled by netfs are currently mounted on the system execute the following command:

# mount -t nfs,nfs4,smbfs,cifs,ncpfs

If the command did not return any output then disable netfs.

contains 1 rule

Disable Network File Systems (netfs)rule

The netfs script manages the boot-time mounting of several types of networked filesystems, of which NFS and Samba are the most common. If these filesystem types are not in use, the script can be disabled, protecting the system somewhat against accidental or malicious changes to /etc/fstab and against flaws in the netfs script itself. The netfs service can be disabled with the following command: # chkconfig netfs off

identifiers: CCE-27137-9

Remediation script:

#
# Disable netfs for all run levels
#
chkconfig --level 0123456 netfs off

#
# Stop netfs if currently running
#
service netfs stop

Configure All Machines which Use NFSgroup

The steps in this section are appropriate for all machines which run NFS, whether they operate as clients or as servers.

Make Each Machine a Client or a Server, not Bothgroup

If NFS must be used, it should be deployed in the simplest configuration possible to avoid maintainability problems which may lead to unnecessary security exposure. Due to the reliability and security problems caused by NFS (specially NFSv3 and NFSv2), it is not a good idea for machines which act as NFS servers to also mount filesystems via NFS. At the least, crossed mounts (the situation in which each of two servers mounts a filesystem from the other) should never be used.

Configure NFS Services to Use Fixed Ports (NFSv3 and NFSv2)group

Firewalling should be done at each host and at the border firewalls to protect the NFS daemons from remote access, since NFS servers should never be accessible from outside the organization. However, by default for NFSv3 and NFSv2, the RPC Bind service assigns each NFS service to a port dynamically at service startup time. Dynamic ports cannot be protected by port filtering firewalls such as iptables.

Therefore, restrict each service to always use a given port, so that firewalling can be done effectively. Note that, because of the way RPC is implemented, it is not possible to disable the RPC Bind service even if ports are assigned statically to all RPC services.

In NFSv4, the mounting and locking protocols have been incorporated into the protocol, and the server listens on the the well-known TCP port 2049. As such, NFSv4 does not need to interact with the rpcbind, lockd, and rpc.statd daemons, which can and should be disabled in a pure NFSv4 environment. The rpc.mountd daemon is still required on the NFS server to setup exports, but is not involved in any over-the-wire operations.

Configure NFS Clientsgroup

The steps in this section are appropriate for machines which operate as NFS clients.

contains 3 rules

Disable NFS Server Daemonsgroup

There is no need to run the NFS server daemons nfs and rpcsvcgssd except on a small number of properly secured machines designated as NFS servers. Ensure that these daemons are turned off on clients.

contains 1 rule

Disable Secure RPC Server Service (rpcsvcgssd)rule

The rpcsvcgssd service manages RPCSEC GSS contexts required to secure protocols that use RPC (most often Kerberos and NFS). The rpcsvcgssd service is the server-side of RPCSEC GSS. If the system does not require secure RPC then this service should be disabled. The rpcsvcgssd service can be disabled with the following command: # chkconfig rpcsvcgssd off

identifiers: CCE-27122-1

references:

Remediation script:

#
# Disable rpcsvcgssd for all run levels
#
chkconfig --level 0123456 rpcsvcgssd off

#
# Stop rpcsvcgssd if currently running
#
service rpcsvcgssd stop

Mount Remote Filesystems with Restrictive Optionsgroup

Edit the file /etc/fstab. For each filesystem whose type (column 3) is nfs or nfs4, add the text ,nodev,nosuid to the list of mount options in column 4. If appropriate, also add ,noexec.

See the section titled "Restrict Partition Mount Options" for a description of the effects of these options. In general, execution of files mounted via NFS should be considered risky because of the possibility that an adversary could intercept the request and substitute a malicious file. Allowing setuid files to be executed from remote servers is particularly risky, both for this reason and because it requires the clients to extend root-level trust to the NFS server.

contains 2 rules

Mount Remote Filesystems with nodevrule

Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts.

identifiers: CCE-27090-0

references:

Mount Remote Filesystems with nosuidrule

Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts.

identifiers: CCE-26972-0

references:

Configure NFS Serversgroup

The steps in this section are appropriate for machines which operate as NFS servers.

Configure the Exports File Restrictivelygroup

Linux's NFS implementation uses the file /etc/exports to control what filesystems and directories may be accessed via NFS. (See the exports(5) manpage for more information about the format of this file.)

The syntax of the exports file is not necessarily checked fully on reload, and syntax errors can leave your NFS configuration more open than intended. Therefore, exercise caution when modifying the file.

The syntax of each line in /etc/exports is:

/DIR	host1(opt1,opt2) host2(opt3)

where /DIR is a directory or filesystem to export, hostN is an IP address, netblock, hostname, domain, or netgroup to which to export, and optN is an option.

Use Access Lists to Enforce Authorization Restrictionsgroup

When configuring NFS exports, ensure that each export line in /etc/exports contains a list of hosts which are allowed to access that export. If no hosts are specified on an export line, then that export is available to any remote host which requests it. All lines of the exports file should specify the hosts (or subnets, if needed) which are allowed to access the exported directory, so that unknown or remote hosts will be denied.

Authorized hosts can be specified in several different formats:

Name or alias that is recognized by the resolver
Fully qualified domain name
IP address
IP subnets in the format address/netmask or address/CIDR

Export Filesystems Read-Only if Possiblegroup

If a filesystem is being exported so that users can view the files in a convenient fashion, but there is no need for users to edit those files, exporting the filesystem read-only removes an attack vector against the server. The default filesystem export mode is ro, so do not specify rw without a good reason.

DNS Servergroup

Most organizations have an operational need to run at least one nameserver. However, there are many common attacks involving DNS server software, and this server software should be disabled on any system on which it is not needed.

contains 2 rules

Disable DNS Servergroup

DNS software should be disabled on any machine which does not need to be a nameserver. Note that the BIND DNS server software is not installed on RHEL 6 by default. The remainder of this section discusses secure configuration of machines which must be nameservers.

contains 2 rules

Disable DNS Serverrule

The named service can be disabled with the following command: # chkconfig named off

identifiers: CCE-26873-0

references: CM-7, 366

Uninstall bind Packagerule

To remove the bind package, which contains the named service, run the following command:

# yum erase bind

identifiers: CCE-27030-6

references: CM-7, 366

Isolate DNS from Other Servicesgroup

This section discusses mechanisms for preventing the DNS server from interfering with other services. This is done both to protect the remainder of the network should a nameserver be compromised, and to make direct attacks on nameservers more difficult.

Run DNS Software on Dedicated Serversgroup

Since DNS is a high-risk service which must frequently be made available to the entire Internet, it is strongly recommended that no other services be offered by machines which act as organizational DNS servers.

Run DNS Software in a chroot Jailgroup

Install the bind-chroot package:

# yum install bind-chroot

Place a valid named.conf file inside the chroot jail:

# cp /etc/named.conf /var/named/chroot/etc/named.conf
# chown root:root /var/named/chroot/etc/named.conf
# chmod 644 /var/named/chroot/etc/named.conf

Create and populate an appropriate zone directory within the jail, based on the options directive. If your named.conf includes:

options {
directory "/path/to/DIRNAME ";
...
}

then copy that directory and its contents from the original zone directory:

# cp -r /path/to/DIRNAME /var/named/chroot/DIRNAME

Add or correct the following line within /etc/sysconfig/named:

ROOTDIR=/var/named/chroot

Protect DNS Data from Tampering or Attackgroup

This section discusses DNS configuration options which make it more difficult for attackers to gain access to private DNS data or to modify DNS data.

Run Separate DNS Servers for External and Internal Queriesgroup

Is it possible to run external and internal nameservers on separate machines? If so, follow the configuration guidance in this section. On the external nameserver, edit /etc/named.conf to add or correct the following directives:

options {
  allow-query { any; };
  recursion no;
  ...
};
zone "example.com " IN {
  ...
};

On the internal nameserver, edit /etc/named.conf. Add or correct the following directives, where SUBNET is the numerical IP representation of your organization in the form xxx.xxx.xxx.xxx/xx:

acl internal {
  SUBNET ;
  localhost;
};
options {
  allow-query { internal; };
  ...
};
zone "internal.example.com " IN {
  ...
};

Use Views to Partition External and Internal Informationgroup

If it is not possible to run external and internal nameservers on separate physical machines, run BIND9 and simulate this feature using views. Edit /etc/named.conf. Add or correct the following directives (where SUBNET is the numerical IP representation of your organization in the form xxx.xxx.xxx.xxx/xx):

acl internal {
  SUBNET ;
  localhost;
};
view "internal-view" {
  match-clients { internal; };
  zone "." IN {
    type hint;
    file "db.cache";
  };
  zone "internal.example.com " IN {
    ...
  };
};

view "external-view" {
  match-clients { any; };
  recursion no;
  zone "example.com " IN {
    ...
  };
};

FTP Servergroup

FTP is a common method for allowing remote access to files. Like telnet, the FTP protocol is unencrypted, which means that passwords and other data transmitted during the session can be captured and that the session is vulnerable to hijacking. Therefore, running the FTP server software is not recommended.

However, there are some FTP server configurations which may be appropriate for some environments, particularly those which allow only read-only anonymous access as a means of downloading data available to the public.

contains 2 rules

Disable vsftpd if Possiblegroup

contains 2 rules

Disable vsftpd Servicerule

The vsftpd service can be disabled with the following command: # chkconfig vsftpd off

identifiers: CCE-26948-0

references: CM-7, 1436

Remediation script:

if service vsftpd status >/dev/null; then
	service vsftpd stop
fi

Uninstall vsftpd Packagerule

The vsftpd package can be removed with the following command: # yum erase vsftpd

identifiers: CCE-26687-4

references: CM-7, 1436

Use vsftpd to Provide FTP Service if Necessarygroup

The primary vsftpd configuration file is /etc/vsftpd.conf, if that file exists, or /etc/vsftpd/vsftpd.conf if it does not.

Restrict the Set of Users Allowed to Access FTPgroup

This section describes how to disable non-anonymous (password-based) FTP logins, or, if it is not possible to do this entirely due to legacy applications, how to restrict insecure FTP login to only those users who have an identified need for this access.

Limit Users Allowed FTP Access if Necessarygroup

If there is a mission-critical reason for users to access their accounts via the insecure FTP protocol, limit the set of users who are allowed this access. Edit the vsftpd configuration file. Add or correct the following configuration options:

userlist_enable=YES
userlist_file=/etc/vsftp.ftpusers
userlist_deny=NO

Edit the file /etc/vsftp.ftpusers. For each user USERNAME who should be allowed to access the system via FTP, add a line containing that user's name:

USERNAME

If anonymous access is also required, add the anonymous usernames to /etc/vsftp.ftpusers as well.

anonymous
ftp

Configure Firewalls to Protect the FTP Servergroup

By default, iptables blocks access to the ports used by the web server. To configure iptables to allow port 21 traffic one must edit /etc/sysconfig/iptables and /etc/sysconfig/ip6tables (if IPv6 is in use). Add the following line, ensuring that it appears before the final LOG and DROP lines for the INPUT chain: -A INPUT -m state --state NEW -p tcp --dport 21 -j ACCEPT Edit the file /etc/sysconfig/iptables-config. Ensure that the space-separated list of modules contains the FTP connection tracking module:

IPTABLES_MODULES="ip_conntrack_ftp"

Web Servergroup

The web server is responsible for providing access to content via the HTTP protocol. Web servers represent a significant security risk because:

The HTTP port is commonly probed by malicious sources
Web server software is very complex, and includes a long history of vulnerabilities
The HTTP protocol is unencrypted and vulnerable to passive monitoring

The system's default web server software is Apache 2 and is provided in the RPM package httpd.

contains 2 rules

Disable Apache if Possiblegroup

If Apache was installed and activated, but the system does not need to act as a web server, then it should be disabled and removed from the system.

contains 2 rules

Disable httpd Servicerule

The httpd service can be disabled with the following command: # chkconfig httpd off

identifiers: CCE-27075-1

references: CM-7

Uninstall httpd Packagerule

The httpd package can be removed with the following command: # yum erase httpd

identifiers: CCE-27133-8

references: CM-7

Install Apache if Necessarygroup

If httpd was not installed and activated, but the system needs to act as a web server, then it should be installed on the system. Follow these guidelines to install it defensively. The httpd package can be installed with the following command:

# yum install httpd

This method of installation is recommended over installing the "Web Server" package group during the system installation process. The Web Server package group includes many packages which are likely extraneous, while the command-line method installs only the required httpd package itself.

Confirm Minimal Built-in Modules Installedgroup

The default httpd installation minimizes the number of modules that are compiled directly into the binary (core prefork http_core mod_so). This minimizes risk by limiting the capabilities allowed by the web server. Query the set of compiled-in modules using the following command:

$ httpd -l

If the number of compiled-in modules is significantly larger than the aforementioned set, this guide recommends re-installing httpd with a reduced configuration. Minimizing the number of modules that are compiled into the httpd binary, reduces risk by limiting the capabilities allowed by the webserver.

Secure Apache Configurationgroup

The httpd configuration file is /etc/httpd/conf/httpd.conf. Apply the recommendations in the remainder of this section to this file.

Restrict Web Server Information Leakagegroup

The ServerTokens and ServerSignature directives determine how much information the web server discloses about the configuration of the system.

Minimize Web Server Loadable Modulesgroup

A default installation of httpd includes a plethora of dynamically shared objects (DSO) that are loaded at run-time. Unlike the aforementioned compiled-in modules, a DSO can be disabled in the configuration file by removing the corresponding LoadModule directive.

Note: A DSO only provides additional functionality if associated directives are included in the httpd configuration file. It should also be noted that removing a DSO will produce errors on httpd startup if the configuration file contains directives that apply to that module. Refer to http://httpd.apache.org/docs/ for details on which directives are associated with each DSO.

Following each DSO removal, the configuration can be tested with the following command to check if everything still works:

# service httpd configtest

The purpose of each of the modules loaded by default will now be addressed one at a time. If none of a module's directives are being used, remove it.

httpd Core Modulesgroup

These modules comprise a basic subset of modules that are likely needed for base httpd functionality; ensure they are not commented out in /etc/httpd/conf/httpd.conf:

LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule authn_default_module modules/mod_authn_default.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_default_module modules/mod_authz_default.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule logio_module modules/mod_logio.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mome.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
LoadModule alias_module modules/mod_alias.so

Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.

Minimize Modules for HTTP Basic Authenticationgroup

The following modules are necessary if this web server will provide content that will be restricted by a password.

Authentication can be performed using local plain text password files (authn_file), local DBM password files (authn_dbm) or an LDAP directory. The only module required by the web server depends on your choice of authentication. Comment out the modules you don't need from the following:

LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authn_dbm_module modules/mod_authn_dbm.so

authn_alias allows for authentication based on aliases. authn_anon allows anonymous authentication similar to that of anonymous ftp sites. authz_owner allows authorization based on file ownership. authz_dbm allows for authorization based on group membership if the web server is using DBM authentication.

If the above functionality is unnecessary, comment out the related module:

#LoadModule authn_alias_module modules/mod_authn_alias.so
#LoadModule authn_anon_module modules/mod_authn_anon.so
#LoadModule authz_owner_module modules/mod_authz_owner.so
#LoadModule authz_dbm_module modules/mod_authz_dbm.so

Minimize Various Optional Componentsgroup

The following modules perform very specific tasks, sometimes providing access to just a few additional directives. If such functionality is not required (or if you are not using these directives), comment out the associated module:

External filtering (response passed through external program prior to client delivery)
```
#LoadModule ext_filter_module modules/mod_ext_filter.so
```

User-specified Cache Control and Expiration

#LoadModule expires_module modules/mod_expires.so

Compression Output Filter (provides content compression prior to client delivery)
```
#LoadModule deflate_module modules/mod_deflate.so
```

HTTP Response/Request Header Customization

#LoadModule headers_module modules/mod_headers.so

User activity monitoring via cookies

#LoadModule usertrack_module modules/mod_usertrack.so

Dynamically configured mass virtual hosting

#LoadModule vhost_alias_module modules/mod_vhost_alias.so

Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.

Minimize Configuration Files Includedgroup

The Include directive directs httpd to load supplementary configuration files from a provided path. The default configuration loads all files that end in .conf from the /etc/httpd/conf.d directory.

To restrict excess configuration, the following line should be commented out and replaced with Include directives that only reference required configuration files:

#Include conf.d/*.conf

If the above change was made, ensure that the SSL encryption remains loaded by explicitly including the corresponding configuration file:

Include conf.d/ssl.conf

If PHP is necessary, a similar alteration must be made:

Include conf.d/php.conf

Explicitly listing the configuration files to be loaded during web server start-up avoids the possibility of unwanted or malicious configuration files to be automatically included as part of the server's running configuration.

Directory Restrictionsgroup

The Directory tags in the web server configuration file allow finer grained access control for a specified directory. All web directories should be configured on a case-by-case basis, allowing access only where needed.

Use Appropriate Modules to Improve httpd's Securitygroup

Among the modules available for httpd are several whose use may improve the security of the web server installation. This section recommends and discusses the deployment of security-relevant modules.

Deploy mod_sslgroup

Because HTTP is a plain text protocol, all traffic is susceptible to passive monitoring. If there is a need for confidentiality, SSL should be configured and enabled to encrypt content.

Note: mod_nss is a FIPS 140-2 certified alternative to mod_ssl. The modules share a considerable amount of code and should be nearly identical in functionality. If FIPS 140-2 validation is required, then mod_nss should be used. If it provides some feature or its greater compatibility is required, then mod_ssl should be used.

Deploy mod_securitygroup

The security module provides an application level firewall for httpd. Following its installation with the base ruleset, specific configuration advice can be found at http://www.modsecurity.org/ to design a policy that best matches the security needs of the web applications. Usage of mod_security is highly recommended for some environments, but it should be noted this module does not ship with Red Hat Enterprise Linux itself, and instead is provided via Extra Packages for Enterprise Linux (EPEL). For more information on EPEL please refer to http://fedoraproject.org/wiki/EPEL.

Use Denial-of-Service Protection Modulesgroup

Denial-of-service attacks are difficult to detect and prevent while maintaining acceptable access to authorized users. However, some traffic-shaping modules can be used to address the problem. Well-known DoS protection modules include:

mod_cband mod_bwshare mod_limitipconn mod_evasive

Denial-of-service prevention should be implemented for a web server if such a threat exists. However, specific configuration details are very dependent on the environment and often best left at the discretion of the administrator.

Configure PHP Securelygroup

PHP is a widely-used and often misconfigured server-side scripting language. It should be used with caution, but configured appropriately when needed.

Review /etc/php.ini and make the following changes if possible:

# Do not expose PHP error messages to external users
display_errors = Off

# Enable safe mode
safe_mode = On

# Only allow access to executables in isolated directory
safe_mode_exec_dir = php-required-executables-path

# Limit external access to PHP environment
safe_mode_allowed_env_vars = PHP_

# Restrict PHP information leakage
expose_php = Off

# Log all errors
log_errors = On

# Do not register globals for input data
register_globals = Off

# Minimize allowable PHP post size
post_max_size = 1K

# Ensure PHP redirects appropriately
cgi.force_redirect = 0

# Disallow uploading unless necessary
file_uploads = Off

# Disallow treatment of file requests as fopen calls
allow_url_fopen = Off

# Enable SQL safe mode
sql.safe_mode = On

Configure Operating System to Protect Web Servergroup

The following configuration steps should be taken on the machine which hosts the web server, in order to provide as safe an environment as possible for the web server.

Restrict File and Directory Accessgroup

Minimize access to critical httpd files and directories.

Configure iptables to Allow Access to the Web Servergroup

By default, iptables blocks access to the ports used by the web server. To configure iptables to allow port 80 traffic one must edit /etc/sysconfig/iptables and /etc/sysconfig/ip6tables (if IPv6 is in use). Add the following line, ensuring that it appears before the final LOG and DROP lines for the INPUT chain: -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT To configure iptables to allow port 443 traffic one must edit /etc/sysconfig/iptables and /etc/sysconfig/ip6tables (if IPv6 is in use). Add the following line, ensuring that it appears before the final LOG and DROP lines for the INPUT chain: -A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT

Run httpd in a chroot Jail if Practicalgroup

Running httpd inside a chroot jail is designed to isolate the web server process to a small section of the filesystem, limiting the damage if it is compromised. Versions of Apache greater than 2.2.10 (such as the one included with RHEL 6) provide the ChrootDir directive. To run Apache inside a chroot jail in /chroot/apache, add the following line to /etc/httpd/conf/httpd.conf:

ChrootDir /chroot/apache

This necessitates placing all files required by httpd inside /chroot/apache , including httpd's binaries, modules, configuration files, and served web pages. The details of this configuration are beyond the scope of this guide. This may also require additional SELinux configuration.

IMAP and POP3 Servergroup

Dovecot provides IMAP and POP3 services. It is not installed by default. The project page at http://www.dovecot.org contains more detailed information about Dovecot configuration.

contains 2 rules

Disable Dovecotgroup

If the system does not need to operate as an IMAP or POP3 server, the dovecot software should be disabled and removed.

contains 2 rules

Disable Dovecot Servicerule

The dovecot service can be disabled with the following command: # chkconfig dovecot off

identifiers: CCE-26922-5

Uninstall dovecot Packagerule

The dovecot package can be uninstalled with the following command:

# yum erase dovecot

identifiers: CCE-27039-7

Configure Dovecot if Necessarygroup

If the system will operate as an IMAP or POP3 server, the dovecot software should be configured securely by following the recommendations below.

Support Only the Necessary Protocolsgroup

Dovecot supports the IMAP and POP3 protocols, as well as SSL-protected versions of those protocols. Configure the Dovecot server to support only the protocols needed by your site. Edit /etc/dovecot/dovecot.conf. Add or correct the following lines, replacing PROTOCOL with only the subset of protocols (imap, imaps, pop3, pop3s) required:

protocols = PROTOCOL

If possible, require SSL protection for all transactions. The SSL protocol variants listen on alternate ports (995 instead of 110 for pop3s, and 993 instead of 143 for imaps), and require SSL-aware clients. An alternate approach is to listen on the standard port and require the client to use the STARTTLS command before authenticating.

Enable SSL Supportgroup

SSL should be used to encrypt network traffic between the Dovecot server and its clients. Users must authenticate to the Dovecot server in order to read their mail, and passwords should never be transmitted in clear text. In addition, protecting mail as it is downloaded is a privacy measure, and clients may use SSL certificates to authenticate the server, preventing another system from impersonating the server.

Allow IMAP Clients to Access the Servergroup

The default iptables configuration does not allow inbound access to any services. This modification will allow remote hosts to initiate connections to the IMAP daemon, while keeping all other ports on the server in their default protected state. To configure iptables to allow port 143 traffic one must edit /etc/sysconfig/iptables and /etc/sysconfig/ip6tables (if IPv6 is in use). Add the following line, ensuring that it appears before the final LOG and DROP lines for the INPUT chain: -A INPUT -m state --state NEW -p tcp --dport 143 -j ACCEPT

Samba(SMB) Microsoft Windows File Sharing Servergroup

When properly configured, the Samba service allows Linux machines to provide file and print sharing to Microsoft Windows machines. There are two software packages that provide Samba support. The first, samba-client, provides a series of command line tools that enable a client machine to access Samba shares. The second, simply labeled samba, provides the Samba service. It is this second package that allows a Linux machine to act as an Active Directory server, a domain controller, or as a domain member. Only the samba-client package is installed by default.

contains 3 rules

Disable Samba if Possiblegroup

Even after the Samba server package has been installed, it will remain disabled. Do not enable this service unless it is absolutely necessary to provide Microsoft Windows file and print sharing functionality.

contains 1 rule

Disable Sambarule

The smb service can be disabled with the following command: # chkconfig smb off

identifiers: CCE-27143-7

references: 1436

Configure Samba if Necessarygroup

All settings for the Samba daemon can be found in /etc/samba/smb.conf. Settings are divided between a [global] configuration section and a series of user created share definition sections meant to describe file or print shares on the system. By default, Samba will operate in user mode and allow client machines to access local home directories and printers. It is recommended that these settings be changed or that additional limitations be set in place.

contains 2 rules

Restrict SMB File Sharing to Configured Networksgroup

Only users with local user accounts will be able to log in to Samba shares by default. Shares can be limited to particular users or network addresses. Use the hosts allow and hosts deny directives accordingly, and consider setting the valid users directive to a limited subset of users or to a group of users. Separate each address, user, or user group with a space as follows for a particular share or global:

[share]
  hosts allow = 192.168.1. 127.0.0.1
  valid users = userone usertwo @usergroup

It is also possible to limit read and write access to particular users with the read list and write list options, though the permissions set by the system itself will override these settings. Set the read only attribute for each share to ensure that global settings will not accidentally override the individual share settings. Then, as with the valid users directive, separate each user or group of users with a space:

[share]
  read only = yes
  write list = userone usertwo @usergroup

Restrict Printer Sharinggroup

By default, Samba utilizes the CUPS printing service to enable printer sharing with Microsoft Windows workstations. If there are no printers on the local machine, or if printer sharing with Microsoft Windows is not required, disable the printer sharing capability by commenting out the following lines, found in /etc/samba/smb.conf:

[global]
  load printers = yes
  cups options = raw
[printers]
  comment = All Printers
  path = /usr/spool/samba
  browseable = no
  guest ok = no
  writable = no
  printable = yes

There may be other options present, but these are the only options enabled and uncommented by default. Removing the [printers] share should be enough for most users. If the Samba printer sharing capability is needed, consider disabling the Samba network browsing capability or restricting access to a particular set of users or network addresses. Set the valid users parameter to a small subset of users or restrict it to a particular group of users with the shorthand @. Separate each user or group of users with a space. For example, under the [printers] share:

[printers]
  valid users = user @printerusers

Require Client SMB Packet Signing, if using smbclientrule

To require samba clients running smbclient to use packet signing, add the following to the [global] section of the Samba configuration file, /etc/samba/smb.conf:

client signing = mandatory

Requiring samba clients such as smbclient to use packet signing ensures they can only communicate with servers that support packet signing.

identifiers: CCE-26328-5

Require Client SMB Packet Signing, if using mount.cifsrule

Require packet signing of clients who mount Samba shares using the mount.cifs program (e.g., those who specify shares in /etc/fstab). To do so, ensure signing options (either sec=krb5i or sec=ntlmv2i) are used.

See the mount.cifs(8) man page for more information. A Samba client should only communicate with servers who can support SMB packet signing.

identifiers: CCE-26792-2

Proxy Servergroup

A proxy server is a very desirable target for a potential adversary because much (or all) sensitive data for a given infrastructure may flow through it. Therefore, if one is required, the machine acting as a proxy server should be dedicated to that purpose alone and be stored in a physically secure location. The system's default proxy server software is Squid, and provided in an RPM package of the same name.

contains 2 rules

Disable Squid if Possiblegroup

If Squid was installed and activated, but the system does not need to act as a proxy server, then it should be disabled and removed.

contains 2 rules

Disable Squidrule

The squid service can be disabled with the following command: # chkconfig squid off

identifiers: CCE-27146-0

Uninstall squid Packagerule

The squid package can be removed with the following command: # yum erase squid

identifiers: CCE-26977-9

SNMP Servergroup

The Simple Network Management Protocol allows administrators to monitor the state of network devices, including computers. Older versions of SNMP were well-known for weak security, such as plaintext transmission of the community string (used for authentication) and usage of easily-guessable choices for the community string.

contains 2 rules

Disable SNMP Server if Possiblegroup

The system includes an SNMP daemon that allows for its remote monitoring, though it not installed by default. If it was installed and activated but is not needed, the software should be disabled and removed.

contains 2 rules

Disable snmpd Servicerule

The snmpd service can be disabled with the following command: # chkconfig snmpd off

identifiers: CCE-26906-8

Uninstall net-snmp Packagerule

The net-snmp package provides the snmpd service. The net-snmpd package can be removed with the following command: # yum erase net-snmpd

identifiers: CCE-26332-7

Configure SNMP Server if Necessarygroup

If it is necessary to run the snmpd agent on the system, some best practices should be followed to minimize the security risk from the installation. The multiple security models implemented by SNMP cannot be fully covered here so only the following general configuration advice can be offered:

use only SNMP version 3 security models and enable the use of authentication and encryption
write access to the MIB (Management Information Base) should be allowed only if necessary
all access to the MIB should be restricted following a principle of least privilege
network access should be limited to the maximum extent possible including restricting to expected network addresses both in the configuration files and in the system firewall rules
ensure SNMP agents send traps only to, and accept SNMP queries only from, authorized management stations
ensure that permissions on the snmpd.conf configuration file (by default, in /etc/snmp) are 640 or more restrictive
ensure that any MIB files' permissions are also 640 or more restrictive

Documentation to Support DISA OS SRG Mappinggroup

These groups exist to document how the Red Hat Enterprise Linux product meets (or does not meet) requirements listed in the DISA OS SRG, for those cases where Groups or Rules elsewhere in scap-security-guide do not clearly relate.

Red Hat and Red Hat Enterprise Linux are either registered trademarks or trademarks of Red Hat, Inc. in the United States and other countries. All other names are registered trademarks or trademarks of their respective companies.