Guide to the Secure Configuration of Red Hat Enterprise Linux 6

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 Red Hat Enterprise Linux 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.

Selected profile

TitleC2S for Red Hat Enterprise Linux 6
IDxccdf_org.ssgproject.content_profile_C2S

Revision History

Current version: 0.9

  • draft (as of 2015-09-28)

Platforms

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

Checklist

contains 177 rules

System Settingsgroup

contains 143 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 14 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, DISA FSO RHEL-06-000001

references:  SC-32, 1208, Test attestation on 20120928 by MM

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, DISA FSO RHEL-06-000002

references:  SC-32, 1208, Test attestation on 20120928 by MM

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, DISA FSO RHEL-06-000003

references:  AU-9, SC-32, 1208, Test attestation on 20120928 by MM

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, DISA FSO RHEL-06-000004

references:  AU-4, AU-9, SC-32, 137, 138, 1208, Test attestation on 20120928 by MM

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, DISA FSO RHEL-06-000007

references:  SC-32, 1208, Test attestation on 20120928 by MM

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 3 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: $ sudo 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: $ sudo rpm --import /media/cdrom/RPM-GPG-KEY

identifiers:  CCE-26506-6, DISA FSO RHEL-06-000008

references:  SI-7, MA-1(b), 351, Test attestation on 20120928 by MM

Remediation script:
# The two fingerprints below are retrieved from https://access.redhat.com/security/team/key
readonly REDHAT_RELEASE_2_FINGERPRINT="567E 347A D004 4ADE 55BA 8A5F 199E 2F91 FD43 1D51"
readonly REDHAT_AUXILIARY_FINGERPRINT="43A6 E49C 4A38 F4BE 9ABF 2A53 4568 9C88 2FA6 58E0"
# Location of the key we would like to import (once it's integrity verified)
readonly REDHAT_RELEASE_KEY="/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release"

RPM_GPG_DIR_PERMS=$(stat -c %a "$(dirname "$REDHAT_RELEASE_KEY")")

# Verify /etc/pki/rpm-gpg directory permissions are safe
if [ "${RPM_GPG_DIR_PERMS}" -le "755" ]
then
  # If they are safe, try to obtain fingerprints from the key file
  # (to ensure there won't be e.g. CRC error)
  IFS=$'\n' GPG_OUT=($(gpg --with-fingerprint "${REDHAT_RELEASE_KEY}"))
  GPG_RESULT=$?
  # No CRC error, safe to proceed
  if [ "${GPG_RESULT}" -eq "0" ]
  then
    for ITEM in "${GPG_OUT[@]}"
    do
      # Filter just hexadecimal fingerprints from gpg's output from
      # processing of a key file
      RESULT=$(echo ${ITEM} | sed -n "s/[[:space:]]*Key fingerprint = \(.*\)/\1/p" | tr -s '[:space:]')
      # If fingerprint matches Red Hat's release 2 or auxiliary key import the key
      if [[ ${RESULT} ]] && ([[ ${RESULT} = "${REDHAT_RELEASE_2_FINGERPRINT}" ]] || \
                             [[ ${RESULT} = "${REDHAT_AUXILIARY_FINGERPRINT}" ]])
      then
        rpm --import "${REDHAT_RELEASE_KEY}"
      fi
    done
  fi
fi

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, DISA FSO RHEL-06-000013

references:  SI-7, MA-1(b), 352, 663, Test attestation on 20120928 by MM

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, DISA FSO RHEL-06-000015

references:  SI-7, MA-1(b), 352, 663, Test attestation on 20120928 by MM

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 6 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 4 rules

Install AIDErule

Install the AIDE package with the command: $ sudo yum install aide

identifiers:  CCE-27024-9, DISA FSO RHEL-06-000016

references:  CM-3(d), CM-3(e), CM-6(d), SC-28, SI-7, 1069, Test attestation on 20121024 by DS

Remediation script:
yum -y install aide

Disable Prelinkingrule

The prelinking feature changes binaries in an attempt to decrease their startup time. In order to disable it, change or add the following line inside the file /etc/sysconfig/prelink: PRELINKING=no Next, run the following command to return binaries to a normal, non-prelinked state: $ sudo /usr/sbin/prelink -ua

identifiers:  CCE-27221-1

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

Remediation script:
#
# Disable prelinking altogether
#
if grep -q ^PRELINKING /etc/sysconfig/prelink
then
  sed -i 's/PRELINKING.*/PRELINKING=no/g' /etc/sysconfig/prelink
else
  echo -e "\n# Set PRELINKING=no per security requirements" >> /etc/sysconfig/prelink
  echo "PRELINKING=no" >> /etc/sysconfig/prelink
fi

#
# Undo previous prelink changes to binaries
#
/usr/sbin/prelink -ua

Build and Test AIDE Databaserule

Run the following command to generate a new database: $ sudo /usr/sbin/aide --init By default, the database will be written to the file /var/lib/aide/aide.db.new.gz. Storing the database, the configuration file /etc/aide.conf, and the binary /usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity. The newly-generated database can be installed as follows: $ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz To initiate a manual check, run the following command: $ sudo /usr/sbin/aide --check If this check produces any unexpected output, investigate.

identifiers:  CCE-27135-3, DISA FSO RHEL-06-000018

references:  CM-3(d), CM-3(e), CM-6(d), SC-28, SI-7, 374, 416, 1069, 1263, 1297, 1589

Configure Periodic Execution of AIDErule

To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab: 05 4 * * * root /usr/sbin/aide --check AIDE can be executed periodically through other means; this is merely one example.

identifiers:  CCE-27222-9, DISA FSO RHEL-06-000306

references:  CM-3(d), CM-3(e), CM-6(d), SC-28, SI-7, 374, 416, 1069, 1263, 1297, 1589

Remediation script:
echo "05 4 * * * root /usr/sbin/aide --check" >> /etc/crontab

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: $ sudo rpm --setperms PACKAGENAME

identifiers:  CCE-26731-0, DISA FSO RHEL-06-000518

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: $ sudo yum reinstall PACKAGENAME Alternatively, the package can be reinstalled from trusted media using the command: $ sudo rpm -Uvh PACKAGENAME

identifiers:  CCE-27223-7, DISA FSO RHEL-06-000519

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

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 42 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

Remediation script:

# NOTE: Run-time reconfiguration of partitions' mount options is not possible.
# After performing this remediation be sure to also subsequently reboot the
# system as soon as possible for the remediation to take the effect!

# Shortened ID for frequently used character class
SP="[:space:]"

# Load /etc/fstab's content with LABEL= and UUID= tags expanded to real
# device names into FSTAB_REAL_DEVICES array splitting items by newline
IFS=$'\n' FSTAB_REAL_DEVICES=($(findmnt --fstab --evaluate --noheadings))

for line in ${FSTAB_REAL_DEVICES[@]}
do
    # For each line:
    # * squeeze multiple space characters into one,
    # * split line content info four columns (target, source, fstype, and
    #   mount options) by space delimiter
    IFS=$' ' read TARGET SOURCE FSTYPE MOUNT_OPTIONS <<< "$(echo $line | tr -s ' ')"

    # Filter the targets according to the following criteria:
    # * don't include record for root partition,
    # * include the target only if it has the form of '/word.*' (not to include
    #   special entries like e.g swap),
    # * include the target only if its source has the form of '/dev.*'
    #   (to process only local partitions)
    if [[ ! $TARGET =~ ^\/$ ]] 		&&	# Don't include root partition
       [[ $TARGET =~ ^\/[A-Za-z0-9_] ]] &&	# Include if target =~ '/word.*'
       [[ $SOURCE =~ ^\/dev ]]			# Include if source =~ '/dev.*'
    then

        # Check the mount options column if it doesn't contain 'nodev' keyword yet
        if ! grep -q "nodev" <<< "$MOUNT_OPTIONS"
        then
            # Check if current mount options is empty string ('') meaning
            # particular /etc/fstab row contain just 'defaults' keyword
            if [[ ${#MOUNT_OPTIONS} == "0" ]]
            then
                # If so, add 'defaults' back and append 'nodev' keyword
                MOUNT_OPTIONS="defaults,nodev"
            else
                # Otherwise append just 'nodev' keyword
                MOUNT_OPTIONS="$MOUNT_OPTIONS,nodev"
            fi

            # Escape possible slash ('/') characters in target for use as sed
            # expression below
            TARGET_ESCAPED=${TARGET//$'/'/$'\/'}
            # This target doesn't contain 'nodev' in mount options yet (and meets
            # the above filtering criteria). Therefore obtain particular /etc/fstab's
            # row into FSTAB_TARGET_ROW variable separating the mount options field with
            # hash '#' character
            FSTAB_TARGET_ROW=$(sed -n "s/\(.*$TARGET_ESCAPED[$SP]\+$FSTYPE[$SP]\+\)\([^$SP]\+\)/\1#\2#/p" /etc/fstab)
            # Split the retrieved value by the hash '#' delimiter to get the
            # row's head & tail (i.e. columns other than mount options) which won't
            # get modified
            IFS=$'#' read TARGET_HEAD TARGET_OPTS TARGET_TAIL <<< "$FSTAB_TARGET_ROW"
            # Replace old mount options for particular /etc/fstab's row (for this target
            # and fstype) with new mount options
            sed -i "s#${TARGET_HEAD}\(.*\)${TARGET_TAIL}#${TARGET_HEAD}${MOUNT_OPTIONS}${TARGET_TAIL}#" /etc/fstab

        fi
    fi
done

Add nodev Option to Removable Media 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 removable media partitions.

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, DISA FSO RHEL-06-000271

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

Remediation script:

# Load /etc/fstab's /dev/shm row into DEV_SHM_FSTAB variable separating start &
# end of the filesystem mount options (4-th field) with the '#' character
DEV_SHM_FSTAB=$(sed -n "s/\(.*[[:space:]]\+\/dev\/shm[[:space:]]\+tmpfs[[:space:]]\+\)\([^[:space:]]\+\)/\1#\2#/p" /etc/fstab)

# Save the:
# * 1-th, 2-nd, 3-rd fields into DEV_SHM_HEAD variable
# * 4-th field into DEV_SHM_OPTS variable, and
# * 5-th, and 6-th fields into DEV_SHM_TAIL variable
# splitting DEV_SHM_FSTAB variable value based on the '#' separator
IFS='#' read DEV_SHM_HEAD DEV_SHM_OPTS DEV_SHM_TAIL <<< "$DEV_SHM_FSTAB"

# Replace occurrence of 'defaults' key with the actual list of mount options
# for Red Hat Enterprise Linux 6
DEV_SHM_OPTS=${DEV_SHM_OPTS//defaults/rw,suid,dev,exec,auto,nouser,async,relatime}

# 'dev' option (not prefixed with 'no') present in the list?
echo $DEV_SHM_OPTS | grep -q -P '(?<!no)dev'
if [ $? -eq 0 ]
then
        # 'dev' option found, replace with 'nodev'
        DEV_SHM_OPTS=${DEV_SHM_OPTS//dev/nodev}
fi

# at least one 'nodev' present in the options list?
echo $DEV_SHM_OPTS | grep -q -v 'nodev'
if [ $? -eq 0 ]
then
        # 'nodev' not found yet, append it
        DEV_SHM_OPTS="$DEV_SHM_OPTS,nodev"
fi

# DEV_SHM_OPTS now contains final list of mount options. Replace original form of /dev/shm row
# in /etc/fstab with the corrected version
sed -i "s#${DEV_SHM_HEAD}\(.*\)${DEV_SHM_TAIL}#${DEV_SHM_HEAD}${DEV_SHM_OPTS}${DEV_SHM_TAIL}#" /etc/fstab

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

Remediation script:

# Load /etc/fstab's /dev/shm row into DEV_SHM_FSTAB variable separating start &
# end of the filesystem mount options (4-th field) with the '#' character
DEV_SHM_FSTAB=$(sed -n "s/\(.*[[:space:]]\+\/dev\/shm[[:space:]]\+tmpfs[[:space:]]\+\)\([^[:space:]]\+\)/\1#\2#/p" /etc/fstab)

# Save the:
# * 1-th, 2-nd, 3-rd fields into DEV_SHM_HEAD variable
# * 4-th field into DEV_SHM_OPTS variable, and
# * 5-th, and 6-th fields into DEV_SHM_TAIL variable
# splitting DEV_SHM_FSTAB variable value based on the '#' separator
IFS='#' read DEV_SHM_HEAD DEV_SHM_OPTS DEV_SHM_TAIL <<< "$DEV_SHM_FSTAB"

# Replace occurrence of 'defaults' key with the actual list of mount options
# for Red Hat Enterprise Linux 6
DEV_SHM_OPTS=${DEV_SHM_OPTS//defaults/rw,suid,dev,exec,auto,nouser,async,relatime}

# 'exec' option (not prefixed with 'no') present in the list?
echo $DEV_SHM_OPTS | grep -q -P '(?<!no)exec'
if [ $? -eq 0 ]
then
        # 'exec' option found, replace with 'noexec'
        DEV_SHM_OPTS=${DEV_SHM_OPTS//exec/noexec}
fi

# at least one 'noexec' present in the options list?
echo $DEV_SHM_OPTS | grep -q -v 'noexec'
if [ $? -eq 0 ]
then
        # 'noexec' not found yet, append it
        DEV_SHM_OPTS="$DEV_SHM_OPTS,noexec"
fi

# DEV_SHM_OPTS now contains final list of mount options. Replace original form of /dev/shm row
# in /etc/fstab with the corrected version
sed -i "s#${DEV_SHM_HEAD}\(.*\)${DEV_SHM_TAIL}#${DEV_SHM_HEAD}${DEV_SHM_OPTS}${DEV_SHM_TAIL}#" /etc/fstab

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

Remediation script:

# Load /etc/fstab's /dev/shm row into DEV_SHM_FSTAB variable separating start &
# end of the filesystem mount options (4-th field) with the '#' character
DEV_SHM_FSTAB=$(sed -n "s/\(.*[[:space:]]\+\/dev\/shm[[:space:]]\+tmpfs[[:space:]]\+\)\([^[:space:]]\+\)/\1#\2#/p" /etc/fstab)

# Save the:
# * 1-th, 2-nd, 3-rd fields into DEV_SHM_HEAD variable
# * 4-th field into DEV_SHM_OPTS variable, and
# * 5-th, and 6-th fields into DEV_SHM_TAIL variable
# splitting DEV_SHM_FSTAB variable value based on the '#' separator
IFS='#' read DEV_SHM_HEAD DEV_SHM_OPTS DEV_SHM_TAIL <<< "$DEV_SHM_FSTAB"

# Replace occurrence of 'defaults' key with the actual list of mount options
# for Red Hat Enterprise Linux 6
DEV_SHM_OPTS=${DEV_SHM_OPTS//defaults/rw,suid,dev,exec,auto,nouser,async,relatime}

# 'suid' option (not prefixed with 'no') present in the list?
echo $DEV_SHM_OPTS | grep -q -P '(?<!no)suid'
if [ $? -eq 0 ]
then
        # 'suid' option found, replace with 'nosuid'
        DEV_SHM_OPTS=${DEV_SHM_OPTS//suid/nosuid}
fi

# at least one 'nosuid' present in the options list?
echo $DEV_SHM_OPTS | grep -q -v 'nosuid'
if [ $? -eq 0 ]
then
        # 'nosuid' not found yet, append it
        DEV_SHM_OPTS="$DEV_SHM_OPTS,nosuid"
fi

# DEV_SHM_OPTS now contains final list of mount options. Replace original form of /dev/shm row
# in /etc/fstab with the corrected version
sed -i "s#${DEV_SHM_HEAD}\(.*\)${DEV_SHM_TAIL}#${DEV_SHM_HEAD}${DEV_SHM_OPTS}${DEV_SHM_TAIL}#" /etc/fstab

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

Remediation script:
# Delete particular /etc/fstab's row if /var/tmp is already configured to
# represent a mount point (for some device or filesystem other than /tmp)
if grep -q -P '.*\/var\/tmp.*' /etc/fstab
then
  sed -i '/.*\/var\/tmp.*/d' /etc/fstab
fi

# Bind-mount /var/tmp to /tmp via /etc/fstab (preserving the /etc/fstab form)
printf "%-24s%-24s%-8s%-32s%-3s\n" "/tmp" "/var/tmp" "none" "rw,nodev,noexec,nosuid,bind" "0 0" >> /etc/fstab

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 7 rules

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/true This effectively prevents usage of this uncommon filesystem.

identifiers:  CCE-26340-0

references:  CM-7

Remediation script:
echo "install cramfs /bin/true" > /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/true This effectively prevents usage of this uncommon filesystem.

identifiers:  CCE-26544-7

references:  CM-7

Remediation script:
echo "install freevxfs /bin/true" > /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/true This effectively prevents usage of this uncommon filesystem.

identifiers:  CCE-26670-0

references:  CM-7

Remediation script:
echo "install jffs2 /bin/true" > /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/true This effectively prevents usage of this uncommon filesystem.

identifiers:  CCE-26800-3

references:  CM-7

Remediation script:
echo "install hfs /bin/true" > /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/true This effectively prevents usage of this uncommon filesystem.

identifiers:  CCE-26361-6

references:  CM-7

Remediation script:
echo "install hfsplus /bin/true" > /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/true This effectively prevents usage of this uncommon filesystem.

identifiers:  CCE-26404-4

references:  CM-7

Remediation script:
echo "install squashfs /bin/true" > /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/true This effectively prevents usage of this uncommon filesystem.

identifiers:  CCE-26677-5

references:  CM-7

Remediation script:
echo "install udf /bin/true" > /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: $ sudo chown root /etc/shadow

identifiers:  CCE-26947-2, DISA FSO RHEL-06-000033

references:  AC-6, 225, Test attestation on 20121026 by DS

Remediation script:
chown root /etc/shadow

Verify Group Who Owns shadow Filerule

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

identifiers:  CCE-26967-0, DISA FSO RHEL-06-000034

references:  AC-6, 225, Test attestation on 20121026 by DS

Remediation script:
chgrp root /etc/shadow

Verify Permissions on shadow Filerule

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

identifiers:  CCE-26992-8, DISA FSO RHEL-06-000035

references:  AC-6, 225, Test attestation on 20121026 by DS

Remediation script:
chmod 0000 /etc/shadow

Verify User Who Owns group Filerule

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

identifiers:  CCE-26822-7, DISA FSO RHEL-06-000042

references:  AC-6, Test attestation on 20121026 by DS

Remediation script:
chown root /etc/group

Verify Group Who Owns group Filerule

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

identifiers:  CCE-26930-8, DISA FSO RHEL-06-000043

references:  AC-6, 225, Test attestation on 20121026 by DS

Remediation script:
chgrp root /etc/group

Verify Permissions on group Filerule

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

identifiers:  CCE-26954-8, DISA FSO RHEL-06-000044

references:  AC-6, 225, Test attestation on 20121026 by DS

Remediation script:
chmod 644 /etc/group

Verify User Who Owns gshadow Filerule

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

identifiers:  CCE-27026-4, DISA FSO RHEL-06-000036

references:  AC-6, 225, Test attestation on 20121026 by DS

Remediation script:
chown root /etc/gshadow

Verify Group Who Owns gshadow Filerule

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

identifiers:  CCE-26975-3, DISA FSO RHEL-06-000037

references:  AC-6, 225, Test attestation on 20121026 by DS

Remediation script:
chgrp root /etc/gshadow

Verify Permissions on gshadow Filerule

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

identifiers:  CCE-26951-4, DISA FSO RHEL-06-000038

references:  AC-6, 225, Test attestation on 20121026 by DS

Remediation script:
chmod 0000 /etc/gshadow

Verify User Who Owns passwd Filerule

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

identifiers:  CCE-26953-0, DISA FSO RHEL-06-000039

references:  AC-6, 225, Test attestation on 20121026 by DS

Remediation script:
chown root /etc/passwd

Verify Group Who Owns passwd Filerule

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

identifiers:  CCE-26856-5, DISA FSO RHEL-06-000040

references:  AC-6, 225, Test attestation on 20121026 by DS

Remediation script:
chgrp root /etc/passwd

Verify Permissions on passwd Filerule

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

identifiers:  CCE-26868-0, DISA FSO RHEL-06-000041

references:  AC-6, 225, Test attestation on 20121026 by DS

Remediation script:
chmod 0644 /etc/passwd

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.

contains 1 rule

Verify that System Executables Have Restrictive Permissionsrule

System executables are stored in the following directories by default: /bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin All files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command: $ sudo chmod go-w FILE

identifiers:  CCE-27289-8, DISA FSO RHEL-06-000047

references:  AC-6, 1499

Remediation script:
DIRS="/bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin"
for dirPath in $DIRS; do
	find $dirPath -perm /022 -exec chmod go-w '{}' \;
done

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: $ sudo chmod +t DIR

identifiers:  CCE-26840-9, DISA FSO RHEL-06-000336

references:  AC-6, Test attestation on 20120929 by swells

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, DISA FSO RHEL-06-000282

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:  AC-6(1)

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:  AC-6(1)

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

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 5 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 027 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, DISA FSO RHEL-06-000346

references:  AC-6, Test attestation on 20140912 by JL

Remediation script:
var_umask_for_daemons="027"
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, DISA FSO RHEL-06-000308

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: $ sudo 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
#
/sbin/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 -e "\n# 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: $ sudo 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, DISA FSO RHEL-06-000079

references:  SC-39, 2530, Test attestation on 20121024 by DS

Remediation script:
#
# Set runtime for kernel.exec-shield
#
/sbin/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 -e "\n# 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: $ sudo 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, DISA FSO RHEL-06-000078

references:  SC-30(2), Test attestation on 20121024 by DS

Remediation script:
#
# Set runtime for kernel.randomize_va_space
#
/sbin/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 -e "\n# Set kernel.randomize_va_space to 2 per security requirements" >> /etc/sysctl.conf
	echo "kernel.randomize_va_space = 2" >> /etc/sysctl.conf
fi

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 Red Hat Enterprise Linux 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 6 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, DISA FSO RHEL-06-000017

references:  AC-3, AC-3(3), AC-6, AU-9, 22, 32, Test attestation on 20121024 by DS

Remediation script:
sed -i --follow-symlinks "s/selinux=0//gI" /etc/grub.conf
sed -i --follow-symlinks "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, DISA FSO RHEL-06-000020

references:  AC-3, AC-3(3), AC-4, AC-6, AU-9, 22, 32, 26, Test attestation on 20121024 by DS

Remediation script:
var_selinux_state="enforcing"
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, DISA FSO RHEL-06-000023

references:  AC-3, AC-3(3), AC-4, AC-6, AU-9, 22, 32, Test attestation on 20121024 by DS

Remediation script:
var_selinux_policy_name="targeted"
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

Uninstall setroubleshoot Packagerule

The SETroubleshoot service notifies desktop users of SELinux denials. The service provides information around configuration errors, unauthorized intrusions, and other potential errors. The setroubleshoot package can be removed with the following command: $ sudo yum erase setroubleshoot

identifiers:  CCE-

Uninstall mcstrans Packagerule

The mcstransd daemon provides category label information to client processes requesting information. The label translations are defined in /etc/selinux/targeted/setrans.conf. The mcstrans package can be removed with the following command: $ sudo yum erase mcstrans

identifiers:  CCE-

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: $ sudo 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

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 Red Hat Enterprise Linux 6.

contains 26 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 12 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 4 rules

Direct root Logins Not Allowedrule

To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to login to. If the file does not exist at all, the root user can login through any communication device on the system, whether via the console or via a raw network interface. This is dangerous as user can login to his machine as root via Telnet, which sends the password in plain text over the network. By default, Red Hat Enteprise Linux's /etc/securetty file only allows the root user to login at the console physically attached to the machine. To prevent root from logging in, remove the contents of this file. To prevent direct root logins, remove the contents of this file by typing the following command: $ sudo echo > /etc/securetty

identifiers:  CCE-26891-2

references:  IA-2(1), Test attestation on 20121024 by DS

Ensure that System Accounts Do Not Run a Shell Upon Loginrule

Some accounts are not associated with a human user of the system, and exist to perform some administrative function. Should an attacker be able to log into these accounts, they should not be granted access to a shell. The login shell for each local account is stored in the last field of each line in /etc/passwd. System accounts are those user accounts with a user ID less than 500. The user ID is stored in the third field. If any system account SYSACCT (other than root) has a login shell, disable it with the command: $ sudo usermod -s /sbin/nologin SYSACCT

identifiers:  CCE-26966-2

references:  AC-2, 178, Test attestation on 20121024 by DS

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, DISA FSO RHEL-06-000032

references:  AC-6, IA-2(1), 366, Test attestation on 20121024 by DS

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

Root Path Must Be Vendor Defaultrule

Assuming root shell is bash, edit the following files: ~/.profile ~/.bashrc Change any PATH variables to the vendor default for root and remove any empty PATH entries or references to relative paths.

identifiers:  CCE-27125-4

references:  SA-8, Test attestation on 20121024 by DS

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 3 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 onto 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, DISA FSO RHEL-06-000030

references:  IA-5(b), IA-5(c), IA-5(1)(a), Test attestation on 20121024 by DS

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

All GIDs referenced in /etc/passwd must be defined in /etc/grouprule

Add a group to the system for each GID referenced without a corresponding group.

identifiers:  CCE-27379-7, DISA FSO RHEL-06-000294

references:  366, Test attestation on 20121024 by DS

Verify No netrc Files Existrule

The .netrc files contain login information used to auto-login into FTP servers and reside in the user's home directory. These files may contain unencrypted passwords to remote FTP servers making them susceptible to access by unauthorized users and should not be used. Any .netrc files should be removed.

identifiers:  CCE-27225-2, DISA FSO RHEL-06-000347

references:  IA-5(h), AC-3, 196

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: $ sudo chage -M 180 -m 7 -W 7 USER

contains 3 rules

Set Password Minimum Agerule

To specify password minimum age for new accounts, edit the file /etc/login.defs and add or correct the following line: PASS_MIN_DAYS 7 A value of 1 day is considered for sufficient for many environments. The DoD requirement is 1.

identifiers:  CCE-27013-2, DISA FSO RHEL-06-000051

references:  IA-5(f), IA-5(1)(d), 198, Test attestation on 20121026 by DS

Remediation script:
var_accounts_minimum_age_login_defs="7"
grep -q ^PASS_MIN_DAYS /etc/login.defs && \
  sed -i "s/PASS_MIN_DAYS.*/PASS_MIN_DAYS     $var_accounts_minimum_age_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]; then
    echo "PASS_MIN_DAYS      $var_accounts_minimum_age_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: PASS_MAX_DAYS 90 A value of 180 days is sufficient for many environments. The DoD requirement is 60.

identifiers:  CCE-26985-2, DISA FSO RHEL-06-000053

references:  IA-5(f), IA-5(g), IA-5(1)(d), 180, 199, 76, Test attestation on 20121026 by DS

Remediation script:
var_accounts_maximum_age_login_defs="90"
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: PASS_WARN_AGE 7 The DoD requirement is 7.

identifiers:  CCE-26988-6, DISA FSO RHEL-06-000054

references:  AC-2(2), IA-5(f), Test attestation on 20121026 by DS

Remediation script:
var_accounts_password_warn_age_login_defs="7"
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: $ sudo 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 2 rules

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=UNDEFINED_SUB 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, DISA FSO RHEL-06-000334

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

Remediation script:
var_account_disable_post_pw_expiration="35"
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

Ensure All Accounts on the System Have Unique Namesrule

Change usernames, or delete accounts, so each has a unique name.

identifiers:  CCE-27609-7, DISA FSO RHEL-06-000296

references:  770, 804

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 2 rules

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, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows: Add the following line immediately before the pam_unix.so statement in the AUTH section: auth required pam_faillock.so preauth silent deny=3 unlock_time=604800 fail_interval=900 Add the following line immediately after the pam_unix.so statement in the AUTH section: auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 fail_interval=900 Add the following line immediately before the pam_unix.so statement in the ACCOUNT section: account required pam_faillock.so

identifiers:  CCE-26844-1, DISA FSO RHEL-06-000061

references:  AC-7(a), 44

Remediation script:
var_accounts_passwords_pam_faillock_deny="3"
AUTH_FILES[0]="/etc/pam.d/system-auth"
AUTH_FILES[1]="/etc/pam.d/password-auth"

for pamFile in "${AUTH_FILES[@]}"
do
	
	# pam_faillock.so already present?
	if grep -q "^auth.*pam_faillock.so.*" $pamFile; then

		# pam_faillock.so present, deny directive present?
		if grep -q "^auth.*[default=die].*pam_faillock.so.*authfail.*deny=" $pamFile; then

			# both pam_faillock.so & deny present, just correct deny directive value
			sed -i --follow-symlink "s/\(^auth.*required.*pam_faillock.so.*preauth.*silent.*\)\(deny *= *\).*/\1\2$var_accounts_passwords_pam_faillock_deny/" $pamFile
			sed -i --follow-symlink "s/\(^auth.*[default=die].*pam_faillock.so.*authfail.*\)\(deny *= *\).*/\1\2$var_accounts_passwords_pam_faillock_deny/" $pamFile

		# pam_faillock.so present, but deny directive not yet
		else

			# append correct deny value to appropriate places
			sed -i --follow-symlink "/^auth.*required.*pam_faillock.so.*preauth.*silent.*/ s/$/ deny=$var_accounts_passwords_pam_faillock_deny/" $pamFile
			sed -i --follow-symlink "/^auth.*[default=die].*pam_faillock.so.*authfail.*/ s/$/ deny=$var_accounts_passwords_pam_faillock_deny/" $pamFile
		fi

	# pam_faillock.so not present yet
	else

		# insert pam_faillock.so preauth & authfail rows with proper value of the 'deny' option
		sed -i --follow-symlink "/^auth.*sufficient.*pam_unix.so.*/i auth        required      pam_faillock.so preauth silent deny=$var_accounts_passwords_pam_faillock_deny" $pamFile
		sed -i --follow-symlink "/^auth.*sufficient.*pam_unix.so.*/a auth        [default=die] pam_faillock.so authfail deny=$var_accounts_passwords_pam_faillock_deny" $pamFile
		sed -i --follow-symlink "/^account.*required.*pam_unix.so/i account     required      pam_faillock.so" $pamFile
	fi
done

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=5 to the line which refers to the pam_unix.so module, as shown: password sufficient pam_unix.so existing_options remember=5 The DoD STIG requirement is 5 passwords.

identifiers:  CCE-26741-9, DISA FSO RHEL-06-000274

references:  IA-5(f), IA-5(1)(e), 200, Test attestation on 20121024 by DS

Remediation script:
var_password_pam_unix_remember="5"
if grep -q "remember=" /etc/pam.d/system-auth; then   
	sed -i --follow-symlink "s/\(remember *= *\).*/\1$var_password_pam_unix_remember/" /etc/pam.d/system-auth
else
	sed -i --follow-symlink "/^password[[:space:]]\+sufficient[[:space:]]\+pam_unix.so/ s/$/ remember=$var_password_pam_unix_remember/" /etc/pam.d/system-auth
fi

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 3 rules

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 2 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 027

identifiers:  CCE-26917-5, DISA FSO RHEL-06-000342

references:  SA-8, 366, Test attestation on 20140912 by JL

Remediation script:
var_accounts_user_umask="027"
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 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 027

identifiers:  CCE-26669-2, DISA FSO RHEL-06-000344

references:  SA-8, 366, Test attestation on 20120929 by swells

Remediation script:
var_accounts_user_umask="027"
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 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: $ sudo ls -ld /home/USER Ensure that the directory is not group-writable and that it is not world-readable. If necessary, repair the permissions: $ sudo chmod g-w /home/USER $ sudo chmod o-rwx /home/USER

identifiers:  CCE-26981-1

references:  AC-6(7)

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 6 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 Red Hat Enterprise Linux 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: $ sudo chown root /etc/grub.conf

identifiers:  CCE-26995-1, DISA FSO RHEL-06-000065

references:  AC-6(7), 225, Test attestation on 20121026 by DS

Remediation script:
chown root /etc/grub.conf

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: $ sudo chgrp root /etc/grub.conf

identifiers:  CCE-27022-3, DISA FSO RHEL-06-000066

references:  AC-6(7), 225, Test attestation on 20121026 by DS

Remediation script:
chgrp root /etc/grub.conf

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: $ sudo chmod 600 /boot/grub/grub.conf

identifiers:  CCE-26949-8, DISA FSO RHEL-06-000067

references:  AC-6(7), 225, Test attestation on 20121026 by DS

Remediation script:
chmod 600 /boot/grub/grub.conf

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, DISA FSO RHEL-06-000068

references:  IA-2(1), IA-5(e) AC-3, 213, Test attestation on 20121026 by DS

Require Authentication for Single User Moderule

Single-user mode is intended as a system recovery method, providing a single user root access to the system by providing a boot option at startup. By default, no authentication is performed if single-user mode is selected. To require entry of the root password even if the system is started in single-user mode, add or correct the following line in the file /etc/sysconfig/init: SINGLE=/sbin/sulogin

identifiers:  CCE-27040-5, DISA FSO RHEL-06-000069

references:  IA-2(1), AC-3, 213, Test attestation on 20121024 by DS

Remediation script:
grep -q ^SINGLE /etc/sysconfig/init && \
  sed -i "s/SINGLE.*/SINGLE=\/sbin\/sulogin/g" /etc/sysconfig/init
if ! [ $? -eq 0 ]; then
    echo "SINGLE=/sbin/sulogin" >> /etc/sysconfig/init
fi

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, DISA FSO RHEL-06-000070

references:  SC-2, AC-3, 213, Test attestation on 20121024 by DS

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 3 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 2 rules

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, DISA FSO RHEL-06-000324

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

Remediation script:
# Install GConf2 package if not installed
if ! rpm -q GConf2; then
  yum -y install GConf2
fi

# Enable displaying of a login warning banner in the GNOME Display Manager's
# login screen
gconftool-2 --direct \
            --config-source "xml:readwrite:/etc/gconf/gconf.xml.mandatory" \
            --type bool \
            --set /apps/gdm/simple-greeter/banner_message_enable true

Set GUI Warning Banner Textrule

To set the text shown by the GNOME Display Manager in the login screen, run the following command: $ sudo gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type string \ --set /apps/gdm/simple-greeter/banner_message_text \ "Text of the warning banner here" When entering a warning banner that spans several lines, remember to begin and end the string with ". This command writes directly either to the /etc/gconf/gconf.xml.mandatory/%gconf-tree.xml if it exists or to the file /etc/gconf/gconf.xml.mandatory/apps/gdm/simple-greeter/%gconf.xml. Either of these files can later be edited directly if necessary.

identifiers:  CCE-27017-3, DISA FSO RHEL-06-000326

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

Remediation script:
login_banner_text="(N/A)"
# Install GConf2 package if not installed
if ! rpm -q GConf2; then
  yum -y install GConf2
fi

# Expand the login_banner_text value - there was a regular-expression
# matching various banners, needs to be expanded
banner_expanded=$(echo "$login_banner_text" | sed 's/\[\\s\\n\][*+]/ /g;s/\\//g;')

# Set the text shown by the GNOME Display Manager in the login screen
gconftool-2 --direct \
            --config-source "xml:readwrite:/etc/gconf/gconf.xml.mandatory" \
            --type string \
            --set /apps/gdm/simple-greeter/banner_message_text "${banner_expanded}"

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, DISA FSO RHEL-06-000073

references:  AC-8(a), AC-8(b), AC-8(c), 48, 1384, 1385, 1386, 1387, 1388, Test attestation on 20121026 by DS

Remediation script:
login_banner_text="(N/A)"
# There was a regular-expression matching various banners, needs to be expanded
expanded=$(echo "$login_banner_text" | sed 's/\[\\s\\n\][+*]/ /g;s/\\//g;s/[^-]- /\n\n-/g')
formatted=$(echo "$expanded" | fold -sw 80)

cat <<EOF >/etc/issue
$formatted
EOF

printf "\n" >> /etc/issue

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 26 rules

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 15 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: $ sudo 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, DISA FSO RHEL-06-000080

references:  AC-4, CM-7, SC-5, SC-7, 1551, Test attestation on 20121024 by DS

Remediation script:
#
# Set runtime for net.ipv4.conf.default.send_redirects
#
/sbin/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 -e "\n# 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: $ sudo 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, DISA FSO RHEL-06-000081

references:  CM-7, SC-5(1), 1551, Test attestation on 20121024 by DS

Remediation script:
#
# Set runtime for net.ipv4.conf.all.send_redirects
#
/sbin/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 -e "\n# 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: $ sudo 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, DISA FSO RHEL-06-000082

references:  CM-7, SC-5, 366, Test attestation on 20121024 by DS

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 12 rules

Disable Kernel Parameter for Accepting Source-Routed Packets for All Interfacesrule

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

identifiers:  CCE-27037-1, DISA FSO RHEL-06-000083

references:  CM-7, SC-5, 1551, Test attestation on 20121024 by DS

Remediation script:
#
# Set runtime for net.ipv4.conf.all.accept_source_route
#
/sbin/sysctl -q -n -w net.ipv4.conf.all.accept_source_route=0

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

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: $ sudo 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, DISA FSO RHEL-06-000084

references:  CM-7, SC-5, 1503, 1551, Test attestation on 20121024 by DS

Remediation script:
#
# Set runtime for net.ipv4.conf.all.accept_redirects
#
/sbin/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 -e "\n# 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: $ sudo 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, DISA FSO RHEL-06-000086

references:  AC-4, CM-7, SC-5, 1503, 1551, Test attestation on 20121024 by DS

Remediation script:
#
# Set runtime for net.ipv4.conf.all.secure_redirects
#
/sbin/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 -e "\n# 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: $ sudo 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, DISA FSO RHEL-06-000088

references:  AC-3(10), CM-7, SC-5(3), 126, Test attestation on 20121024 by DS

Remediation script:
#
# Set runtime for net.ipv4.conf.all.log_martians
#
/sbin/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 -e "\n# 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: $ sudo 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, DISA FSO RHEL-06-000089

references:  AC-4, CM-7, SC-5, SC-7, 1551, Test attestation on 20121024 by DS

Remediation script:
#
# Set runtime for net.ipv4.conf.default.accept_source_route
#
/sbin/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 -e "\n# 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: $ sudo 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, DISA FSO RHEL-06-000091

references:  AC-4, CM-7, SC-5, SC-7, 1551, Test attestation on 20121024 by DS

Remediation script:
#
# Set runtime for net.ipv4.conf.default.accept_redirects
#
/sbin/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 -e "\n# 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: $ sudo 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, DISA FSO RHEL-06-000090

references:  AC-4, CM-7, SC-5, SC-7, 1551, Test attestation on 20121024 by DS

Remediation script:
#
# Set runtime for net.ipv4.conf.default.secure_redirects
#
/sbin/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 -e "\n# 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: $ sudo 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, DISA FSO RHEL-06-000092

references:  CM-7, SC-5, 1551, Test attestation on 20121024 by DS

Remediation script:
#
# Set runtime for net.ipv4.icmp_echo_ignore_broadcasts
#
/sbin/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 -e "\n# 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: $ sudo 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, DISA FSO RHEL-06-000093

references:  CM-7, SC-5, Test attestation on 20121024 by DS

Remediation script:
#
# Set runtime for net.ipv4.icmp_ignore_bogus_error_responses
#
/sbin/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 -e "\n# 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: $ sudo 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, DISA FSO RHEL-06-000095

references:  AC-4, SC-5(2), SC-5(3), 1092, 1095, Test attestation on 20121024 by DS

Remediation script:
#
# Set runtime for net.ipv4.tcp_syncookies
#
/sbin/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 -e "\n# 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: $ sudo 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, DISA FSO RHEL-06-000096

references:  AC-4, SC-5, SC-7, 1551, Test attestation on 20121024 by DS

Remediation script:
#
# Set runtime for net.ipv4.conf.all.rp_filter
#
/sbin/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 -e "\n# 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: $ sudo 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, DISA FSO RHEL-06-000097

references:  AC-4, SC-5, SC-7, Test attestation on 20121024 by DS

Remediation script:
#
# Set runtime for net.ipv4.conf.default.rp_filter
#
/sbin/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 -e "\n# 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 2 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 2 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: $ sudo 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: $ sudo rm /etc/sysconfig/network-scripts/ifcfg-interface

identifiers:  CCE-27057-9

references:  AC-18(a), AC-18(d), AC-18(3), CM-7, 85, Test attestation on 20121025 by DS

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 3 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 1 rule

Disable Interface Usage of IPv6rule

To disable interface usage of IPv6, add or correct the following lines in /etc/sysconfig/network: NETWORKING_IPV6=no IPV6INIT=no

identifiers:  CCE-27161-9

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: $ sudo 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
#
/sbin/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 -e "\n# 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: $ sudo 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, DISA FSO RHEL-06-000099

references:  CM-7, 1551

Remediation script:
#
# Set runtime for net.ipv6.conf.default.accept_redirects
#
/sbin/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 -e "\n# 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

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 2 rules

Inspect and Activate Default Rulesgroup

View the currently-enforced iptables rules by running the command: $ sudo 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): $ sudo 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: $ sudo chkconfig --level 2345 ip6tables on

identifiers:  CCE-27006-6, DISA FSO RHEL-06-000103

references:  AC-4, CA-3(c), CM-7, 32, 66, 1115, 1118, 1092, 1117, 1098, 1100, 1097, 1414, Test attestation on 20121024 by DS

Remediation script:
#
# Enable ip6tables for all run levels
#
/sbin/chkconfig --level 0123456 ip6tables on

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

Verify iptables Enabledrule

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

identifiers:  CCE-27018-1, DISA FSO RHEL-06-000117

references:  AC-4, CA-3(c), CM-7, 32, 66, 1115, 1118, 1092, 1117, 1098, 1100, 1097, 1414, Test attestation on 20121024 by DS

Remediation script:
#
# Enable iptables for all run levels
#
/sbin/chkconfig --level 0123456 iptables on

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

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/true

identifiers:  CCE-26448-1, DISA FSO RHEL-06-000124

references:  CM-7, 382, Test attestation on 20121024 by DS

Remediation script:
echo "install dccp /bin/true" > /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/true

identifiers:  CCE-26410-1, DISA FSO RHEL-06-000125

references:  CM-7, 382, Test attestation on 20121024 by DS

Remediation script:
echo "install sctp /bin/true" > /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/true

identifiers:  CCE-26239-4, DISA FSO RHEL-06-000126

references:  CM-7, 382, Test attestation on 20121024 by DS

Remediation script:
echo "install rds /bin/true" > /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/true

identifiers:  CCE-26696-5, DISA FSO RHEL-06-000127

references:  CM-7, 382, Test attestation on 20121024 by DS

Remediation script:
echo "install tipc /bin/true" > /etc/modprobe.d/tipc.conf

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 Red Hat Enterprise Linux 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 6 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 Red Hat Enterprise Linux 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 1 rule

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: $ sudo chmod 0600 LOGFILE

identifiers:  CCE-27190-8, DISA FSO RHEL-06-000135

references:  SI-11, 1314, Test attestation on 20121024 by DS

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, DISA FSO RHEL-06-000136

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), AC-4

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, DISA FSO RHEL-06-000138

references:  AU-9, 366

Ensure rsyslog is Installedrule

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

identifiers:  CCE-26809-4

references:  AU-9(2), 1311, 1312, Test attestation on 20121024 by DS

Remediation script:
yum -y install rsyslog

Enable rsyslog Servicerule

The rsyslog service provides syslog-style logging by default on Red Hat Enterprise Linux 6. The rsyslog service can be enabled with the following command: $ sudo chkconfig --level 2345 rsyslog on

identifiers:  CCE-26807-8

references:  AU-12, 1557, 1312, 1311, Test attestation on 20121024 by DS

Remediation script:
#
# Enable rsyslog for all run levels
#
/sbin/chkconfig --level 0123456 rsyslog on

#
# Start rsyslog if not currently running
#
/sbin/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 23 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

contains 5 rules

Configure auditd Max Log File Sizerule

Determine the amount of audit data (in megabytes) which should be retained in each log file. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting the correct value of 6 for STOREMB: max_log_file = STOREMB Set the value to 6 (MB) or higher for general-purpose systems. Larger values, of course, support retention of even more audit data.

identifiers:  CCE-27550-3, DISA FSO RHEL-06-000160

references:  AU-1(b), AU-11, IR-5, Test attestation on 20121024 by DS

Configure auditd max_log_file_action Upon Reaching Maximum Log Sizerule

The default action to take when the logs reach their maximum size is to rotate the log files, discarding the oldest one. To configure the action taken by auditd, add or correct the line in /etc/audit/auditd.conf: max_log_file_action = ACTION Possible values for ACTION are described in the auditd.conf man page. These include: ignoresyslogsuspendrotatekeep_logs Set the ACTION to rotate to ensure log rotation occurs. This is the default. The setting is case-insensitive.

identifiers:  CCE-27237-7, DISA FSO RHEL-06-000161

references:  AU-1(b), AU-4, AU-11, IR-5, Test attestation on 20121024 by DS

Configure auditd space_left Action on Low Disk Spacerule

The auditd service can be configured to take an action when disk space starts to run low. Edit the file /etc/audit/auditd.conf. Modify the following line, substituting ACTION appropriately: space_left_action = ACTION Possible values for ACTION are described in the auditd.conf man page. These include: ignoresyslogemailexecsuspendsinglehalt Set this to email (instead of the default, which is suspend) as it is more likely to get prompt attention. Acceptable values also include suspend, single, and halt.

identifiers:  CCE-27238-5, DISA FSO RHEL-06-000005

references:  AU-1(b), AU-4, AU-5(b), IR-5, 140, 143, Test attestation on 20121024 by DS

Remediation script:
var_auditd_space_left_action="email"
#
# If space_left_action present in /etc/audit/auditd.conf, change value
# to var_auditd_space_left_action, else
# add "space_left_action = $var_auditd_space_left_action" to /etc/audit/auditd.conf
#

if grep --silent ^space_left_action /etc/audit/auditd.conf ; then
        sed -i 's/^space_left_action.*/space_left_action = '"$var_auditd_space_left_action"'/g' /etc/audit/auditd.conf
else
        echo -e "\n# Set space_left_action to $var_auditd_space_left_action per security requirements" >> /etc/audit/auditd.conf
        echo "space_left_action = $var_auditd_space_left_action" >> /etc/audit/auditd.conf
fi

Configure auditd admin_space_left Action on Low Disk Spacerule

The auditd service can be configured to take an action when disk space is running low but prior to running out of space completely. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting ACTION appropriately: admin_space_left_action = ACTION Set this value to single to cause the system to switch to single-user mode for corrective action. Acceptable values also include suspend and halt. For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined. Details regarding all possible values for ACTION are described in the auditd.conf man page.

identifiers:  CCE-27239-3

references:  AU-1(b), AU-4, AU-5(b), IR-5, 140, 1343, Test attestation on 20121024 by DS

Remediation script:
var_auditd_admin_space_left_action="single"
grep -q ^admin_space_left_action /etc/audit/auditd.conf && \
  sed -i "s/admin_space_left_action.*/admin_space_left_action = $var_auditd_admin_space_left_action/g" /etc/audit/auditd.conf
if ! [ $? -eq 0 ]; then
    echo "admin_space_left_action = $var_auditd_admin_space_left_action" >> /etc/audit/auditd.conf
fi

Configure auditd mail_acct Action on Low Disk Spacerule

The auditd service can be configured to send email to a designated account in certain situations. Add or correct the following line in /etc/audit/auditd.conf to ensure that administrators are notified via email for those situations: action_mail_acct = root

identifiers:  CCE-27241-9, DISA FSO RHEL-06-000313

references:  AU-1(b), AU-4, AU-5(a), IR-5, 139, 144

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: $ sudo service auditd restart

contains 16 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 4 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, DISA FSO RHEL-06-000165

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

Remediation script:

# audit.rules file to operate at
AUDIT_RULES_FILE="/etc/audit/audit.rules"

# General form / skeleton of an audit rule to search for
BASE_SEARCH_RULE='-a always,exit .* -k audit_time_rules'

# System calls group to search for
SYSCALL_GROUP="time"

# Retrieve hardware architecture of the underlying system
[ $(getconf LONG_BIT) = "32" ] && ARCHS=("b32") || ARCHS=("b32" "b64")

# Perform the remediation depending on the system's architecture:
# * on 32 bit system, operate just at '-F arch=b32' audit rules
# * on 64 bit system, operate at both '-F arch=b32' & '-F arch=b64' audit rules
for ARCH in ${ARCHS[@]}
do

  # Create expected audit rule form for particular system call & architecture
  if [ ${ARCH} = "b32" ]
  then
    # stime system call is known at 32-bit arch (see e.g "$ ausyscall i386 stime" 's output)
    # so append it to the list of time group system calls to be audited
    EXPECTED_RULE="-a always,exit -F arch=b32 -S adjtimex -S settimeofday -S stime -k audit_time_rules"
  else
    # stime system call isn't known at 64-bit arch (see "$ ausyscall x86_64 stime" 's output)
    # therefore don't add it to the list of time group system calls to be audited
    EXPECTED_RULE="-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules"
  fi

  # Indicator that we want to append $EXPECTED_RULE for key & arch into
  # audit.rules by default
  APPEND_EXPECTED_RULE=0

  # From all the existing /etc/audit.rule definitions select those, which:
  # * follow the common audit rule form ($BASE_SEARCH_RULE above)
  # * meet the hardware architecture requirement, and
  # * are current $SYSCALL_GROUP specific
  IFS=$'\n' EXISTING_KEY_ARCH_RULES=($(sed -e "/${BASE_SEARCH_RULE}/!d" -e "/${ARCH}/!d" -e "/${SYSCALL_GROUP}/!d"  ${AUDIT_RULES_FILE}))

  # Process found rules case by case
  for RULE in ${EXISTING_KEY_ARCH_RULES[@]}
  do
    # Found rule is for same arch & syscall group, but differs slightly (in count of -S arguments)
    if [ ${RULE} != ${EXPECTED_RULE} ]
    then
      # If so, isolate just '-S syscall' substring of that rule
      RULE_SYSCALLS=$(echo ${RULE} | grep -o -P '(-S \w+ )+')

        # Check if list of '-S syscall' arguments of that rule is a subset
        # '-S syscall' list from the expected form ($EXPECTED_RULE)
        if [ $(echo ${EXPECTED_RULE} | grep -- ${RULE_SYSCALLS}) ]
        then
          # If so, this audit rule is covered when we append expected rule
          # later & therefore the rule can be deleted.
          #
          # Thus delete the rule from both - the audit.rules file and
          # our $EXISTING_KEY_ARCH_RULES array
          sed -i -e "/${RULE}/d" ${AUDIT_RULES_FILE}
          EXISTING_KEY_ARCH_RULES=(${EXISTING_KEY_ARCH_RULES[@]//${RULE}/})
        else
          # Rule isn't covered by $EXPECTED_RULE - in other words it besides
          # adjtimex, settimeofday, or stime -S arguments contains also -S argument
          # for other time group system call (-S clock_adjtime for example).
          # Example: '-S adjtimex -S clock_adjtime'
          #
          # Therefore:
          # * delete the original rule for arch & key from audit.rules
          #   (original '-S adjtimex -S clock_adjtime' rule would be deleted)
          # * delete $SYSCALL_GROUP -S arguments from the rule,
          #   but keep those not from this $SYSCALL_GROUP
          #   (original '-S adjtimex -S clock_adjtime' would become '-S clock_adjtime')
          # * append the modified (filtered) rule again into audit.rules
          #   if the same rule not already present
          #   (new rule for same arch & key with '-S clock_adjtime' would be appended
          #    if not present yet)
          sed -i -e "/${RULE}/d" ${AUDIT_RULES_FILE}

          if [ ${ARCH} = "b32" ]
          then
            # On 32-bit arch drop ' -S (adjtimex|settimeofday|stime)' from the rule's
            # system call list
            NEW_SYSCALLS_FOR_RULE=$(echo ${RULE_SYSCALLS} | sed -r -e "s/[\s]*-S (adjtimex|settimeofday|stime)//g")
          else
            # On 64-bit arch drop ' -S (adjtimex|settimeofday)' from the rule's
            # system call list ('stime' call isn't known, see "$ ausyscall .." examples above)
            NEW_SYSCALLS_FOR_RULE=$(echo ${RULE_SYSCALLS} | sed -r -e "s/[\s]*-S (adjtimex|settimeofday)//g")
          fi
          # Update the list of system calls for new rule to contain those from new syscalls list
          UPDATED_RULE=$(echo ${RULE} | sed "s/${RULE_SYSCALLS}/${NEW_SYSCALLS_FOR_RULE}/g")
          # Squeeze repeated whitespace characters in rule definition (if any) into one
          UPDATED_RULE=$(echo ${UPDATED_RULE} | tr -s '[:space:]')
          # Insert updated rule into /etc/audit/audit.rules only in case it's not
          # present yet to prevent duplicate same rules
          if [ ! $(grep -- ${UPDATED_RULE} ${AUDIT_RULES_FILE}) ]
          then
            echo ${UPDATED_RULE} >> ${AUDIT_RULES_FILE}
          fi
        fi

    else
      # /etc/audit/audit.rules already contains the expected rule form for this
      # architecture & key => don't insert it second time
      APPEND_EXPECTED_RULE=1
    fi
  done

  # We deleted all rules that were subset of the expected one for this arch & key.
  # Also isolated rules containing system calls not from this system calls group.
  # Now append the expected rule if it's not present in audit.rules yet
  if [[ ${APPEND_EXPECTED_RULE} -eq "0" ]]
  then
    echo ${EXPECTED_RULE} >> ${AUDIT_RULES_FILE}
  fi
done

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 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-27203-9, DISA FSO RHEL-06-000167

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

Remediation script:

# audit.rules file to operate at
AUDIT_RULES_FILE="/etc/audit/audit.rules"

# General form / skeleton of an audit rule to search for
BASE_SEARCH_RULE='-a always,exit .* -k audit_time_rules'

# System calls group to search for
SYSCALL_GROUP="time"

# Retrieve hardware architecture of the underlying system
[ $(getconf LONG_BIT) = "32" ] && ARCHS=("b32") || ARCHS=("b32" "b64")

# Perform the remediation depending on the system's architecture:
# * on 32 bit system, operate just at '-F arch=b32' audit rules
# * on 64 bit system, operate at both '-F arch=b32' & '-F arch=b64' audit rules
for ARCH in ${ARCHS[@]}
do

  # Create expected audit rule form for particular system call & architecture
  if [ ${ARCH} = "b32" ]
  then
    # stime system call is known at 32-bit arch (see e.g "$ ausyscall i386 stime" 's output)
    # so append it to the list of time group system calls to be audited
    EXPECTED_RULE="-a always,exit -F arch=b32 -S adjtimex -S settimeofday -S stime -k audit_time_rules"
  else
    # stime system call isn't known at 64-bit arch (see "$ ausyscall x86_64 stime" 's output)
    # therefore don't add it to the list of time group system calls to be audited
    EXPECTED_RULE="-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules"
  fi

  # Indicator that we want to append $EXPECTED_RULE for key & arch into
  # audit.rules by default
  APPEND_EXPECTED_RULE=0

  # From all the existing /etc/audit.rule definitions select those, which:
  # * follow the common audit rule form ($BASE_SEARCH_RULE above)
  # * meet the hardware architecture requirement, and
  # * are current $SYSCALL_GROUP specific
  IFS=$'\n' EXISTING_KEY_ARCH_RULES=($(sed -e "/${BASE_SEARCH_RULE}/!d" -e "/${ARCH}/!d" -e "/${SYSCALL_GROUP}/!d"  ${AUDIT_RULES_FILE}))

  # Process found rules case by case
  for RULE in ${EXISTING_KEY_ARCH_RULES[@]}
  do
    # Found rule is for same arch & syscall group, but differs slightly (in count of -S arguments)
    if [ ${RULE} != ${EXPECTED_RULE} ]
    then
      # If so, isolate just '-S syscall' substring of that rule
      RULE_SYSCALLS=$(echo ${RULE} | grep -o -P '(-S \w+ )+')

        # Check if list of '-S syscall' arguments of that rule is a subset
        # '-S syscall' list from the expected form ($EXPECTED_RULE)
        if [ $(echo ${EXPECTED_RULE} | grep -- ${RULE_SYSCALLS}) ]
        then
          # If so, this audit rule is covered when we append expected rule
          # later & therefore the rule can be deleted.
          #
          # Thus delete the rule from both - the audit.rules file and
          # our $EXISTING_KEY_ARCH_RULES array
          sed -i -e "/${RULE}/d" ${AUDIT_RULES_FILE}
          EXISTING_KEY_ARCH_RULES=(${EXISTING_KEY_ARCH_RULES[@]//${RULE}/})
        else
          # Rule isn't covered by $EXPECTED_RULE - in other words it besides
          # adjtimex, settimeofday, or stime -S arguments contains also -S argument
          # for other time group system call (-S clock_adjtime for example).
          # Example: '-S adjtimex -S clock_adjtime'
          #
          # Therefore:
          # * delete the original rule for arch & key from audit.rules
          #   (original '-S adjtimex -S clock_adjtime' rule would be deleted)
          # * delete $SYSCALL_GROUP -S arguments from the rule,
          #   but keep those not from this $SYSCALL_GROUP
          #   (original '-S adjtimex -S clock_adjtime' would become '-S clock_adjtime')
          # * append the modified (filtered) rule again into audit.rules
          #   if the same rule not already present
          #   (new rule for same arch & key with '-S clock_adjtime' would be appended
          #    if not present yet)
          sed -i -e "/${RULE}/d" ${AUDIT_RULES_FILE}

          if [ ${ARCH} = "b32" ]
          then
            # On 32-bit arch drop ' -S (adjtimex|settimeofday|stime)' from the rule's
            # system call list
            NEW_SYSCALLS_FOR_RULE=$(echo ${RULE_SYSCALLS} | sed -r -e "s/[\s]*-S (adjtimex|settimeofday|stime)//g")
          else
            # On 64-bit arch drop ' -S (adjtimex|settimeofday)' from the rule's
            # system call list ('stime' call isn't known, see "$ ausyscall .." examples above)
            NEW_SYSCALLS_FOR_RULE=$(echo ${RULE_SYSCALLS} | sed -r -e "s/[\s]*-S (adjtimex|settimeofday)//g")
          fi
          # Update the list of system calls for new rule to contain those from new syscalls list
          UPDATED_RULE=$(echo ${RULE} | sed "s/${RULE_SYSCALLS}/${NEW_SYSCALLS_FOR_RULE}/g")
          # Squeeze repeated whitespace characters in rule definition (if any) into one
          UPDATED_RULE=$(echo ${UPDATED_RULE} | tr -s '[:space:]')
          # Insert updated rule into /etc/audit/audit.rules only in case it's not
          # present yet to prevent duplicate same rules
          if [ ! $(grep -- ${UPDATED_RULE} ${AUDIT_RULES_FILE}) ]
          then
            echo ${UPDATED_RULE} >> ${AUDIT_RULES_FILE}
          fi
        fi

    else
      # /etc/audit/audit.rules already contains the expected rule form for this
      # architecture & key => don't insert it second time
      APPEND_EXPECTED_RULE=1
    fi
  done

  # We deleted all rules that were subset of the expected one for this arch & key.
  # Also isolated rules containing system calls not from this system calls group.
  # Now append the expected rule if it's not present in audit.rules yet
  if [[ ${APPEND_EXPECTED_RULE} -eq "0" ]]
  then
    echo ${EXPECTED_RULE} >> ${AUDIT_RULES_FILE}
  fi
done

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, DISA FSO RHEL-06-000169

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

Remediation script:

# audit.rules file to operate at
AUDIT_RULES_FILE="/etc/audit/audit.rules"

# General form / skeleton of an audit rule to search for
BASE_SEARCH_RULE='-a always,exit .* -k audit_time_rules'

# System calls group to search for
SYSCALL_GROUP="time"

# Retrieve hardware architecture of the underlying system
[ $(getconf LONG_BIT) = "32" ] && ARCHS=("b32") || ARCHS=("b32" "b64")

# Perform the remediation depending on the system's architecture:
# * on 32 bit system, operate just at '-F arch=b32' audit rules
# * on 64 bit system, operate at both '-F arch=b32' & '-F arch=b64' audit rules
for ARCH in ${ARCHS[@]}
do

  # Create expected audit rule form for particular system call & architecture
  if [ ${ARCH} = "b32" ]
  then
    # stime system call is known at 32-bit arch (see e.g "$ ausyscall i386 stime" 's output)
    # so append it to the list of time group system calls to be audited
    EXPECTED_RULE="-a always,exit -F arch=b32 -S adjtimex -S settimeofday -S stime -k audit_time_rules"
  else
    # stime system call isn't known at 64-bit arch (see "$ ausyscall x86_64 stime" 's output)
    # therefore don't add it to the list of time group system calls to be audited
    EXPECTED_RULE="-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rules"
  fi

  # Indicator that we want to append $EXPECTED_RULE for key & arch into
  # audit.rules by default
  APPEND_EXPECTED_RULE=0

  # From all the existing /etc/audit.rule definitions select those, which:
  # * follow the common audit rule form ($BASE_SEARCH_RULE above)
  # * meet the hardware architecture requirement, and
  # * are current $SYSCALL_GROUP specific
  IFS=$'\n' EXISTING_KEY_ARCH_RULES=($(sed -e "/${BASE_SEARCH_RULE}/!d" -e "/${ARCH}/!d" -e "/${SYSCALL_GROUP}/!d"  ${AUDIT_RULES_FILE}))

  # Process found rules case by case
  for RULE in ${EXISTING_KEY_ARCH_RULES[@]}
  do
    # Found rule is for same arch & syscall group, but differs slightly (in count of -S arguments)
    if [ ${RULE} != ${EXPECTED_RULE} ]
    then
      # If so, isolate just '-S syscall' substring of that rule
      RULE_SYSCALLS=$(echo ${RULE} | grep -o -P '(-S \w+ )+')

        # Check if list of '-S syscall' arguments of that rule is a subset
        # '-S syscall' list from the expected form ($EXPECTED_RULE)
        if [ $(echo ${EXPECTED_RULE} | grep -- ${RULE_SYSCALLS}) ]
        then
          # If so, this audit rule is covered when we append expected rule
          # later & therefore the rule can be deleted.
          #
          # Thus delete the rule from both - the audit.rules file and
          # our $EXISTING_KEY_ARCH_RULES array
          sed -i -e "/${RULE}/d" ${AUDIT_RULES_FILE}
          EXISTING_KEY_ARCH_RULES=(${EXISTING_KEY_ARCH_RULES[@]//${RULE}/})
        else
          # Rule isn't covered by $EXPECTED_RULE - in other words it besides
          # adjtimex, settimeofday, or stime -S arguments contains also -S argument
          # for other time group system call (-S clock_adjtime for example).
          # Example: '-S adjtimex -S clock_adjtime'
          #
          # Therefore:
          # * delete the original rule for arch & key from audit.rules
          #   (original '-S adjtimex -S clock_adjtime' rule would be deleted)
          # * delete $SYSCALL_GROUP -S arguments from the rule,
          #   but keep those not from this $SYSCALL_GROUP
          #   (original '-S adjtimex -S clock_adjtime' would become '-S clock_adjtime')
          # * append the modified (filtered) rule again into audit.rules
          #   if the same rule not already present
          #   (new rule for same arch & key with '-S clock_adjtime' would be appended
          #    if not present yet)
          sed -i -e "/${RULE}/d" ${AUDIT_RULES_FILE}

          if [ ${ARCH} = "b32" ]
          then
            # On 32-bit arch drop ' -S (adjtimex|settimeofday|stime)' from the rule's
            # system call list
            NEW_SYSCALLS_FOR_RULE=$(echo ${RULE_SYSCALLS} | sed -r -e "s/[\s]*-S (adjtimex|settimeofday|stime)//g")
          else
            # On 64-bit arch drop ' -S (adjtimex|settimeofday)' from the rule's
            # system call list ('stime' call isn't known, see "$ ausyscall .." examples above)
            NEW_SYSCALLS_FOR_RULE=$(echo ${RULE_SYSCALLS} | sed -r -e "s/[\s]*-S (adjtimex|settimeofday)//g")
          fi
          # Update the list of system calls for new rule to contain those from new syscalls list
          UPDATED_RULE=$(echo ${RULE} | sed "s/${RULE_SYSCALLS}/${NEW_SYSCALLS_FOR_RULE}/g")
          # Squeeze repeated whitespace characters in rule definition (if any) into one
          UPDATED_RULE=$(echo ${UPDATED_RULE} | tr -s '[:space:]')
          # Insert updated rule into /etc/audit/audit.rules only in case it's not
          # present yet to prevent duplicate same rules
          if [ ! $(grep -- ${UPDATED_RULE} ${AUDIT_RULES_FILE}) ]
          then
            echo ${UPDATED_RULE} >> ${AUDIT_RULES_FILE}
          fi
        fi

    else
      # /etc/audit/audit.rules already contains the expected rule form for this
      # architecture & key => don't insert it second time
      APPEND_EXPECTED_RULE=1
    fi
  done

  # We deleted all rules that were subset of the expected one for this arch & key.
  # Also isolated rules containing system calls not from this system calls group.
  # Now append the expected rule if it's not present in audit.rules yet
  if [[ ${APPEND_EXPECTED_RULE} -eq "0" ]]
  then
    echo ${EXPECTED_RULE} >> ${AUDIT_RULES_FILE}
  fi
done

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, DISA FSO RHEL-06-000173

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

Remediation script:

# Include source function library.
. /usr/share/scap-security-guide/remediation_functions

# Perform the remediation
fix_audit_watch_rule "auditctl" "/etc/localtime" "wa" "audit_time_rules"

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_rules_usergroup_modification -w /etc/group -p wa -k audit_rules_usergroup_modification -w /etc/passwd -p wa -k audit_rules_usergroup_modification -w /etc/gshadow -p wa -k audit_rules_usergroup_modification -w /etc/shadow -p wa -k audit_rules_usergroup_modification -w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

identifiers:  CCE-26664-3, DISA FSO RHEL-06-000174

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

Remediation script:

# Include source function library.
. /usr/share/scap-security-guide/remediation_functions

# Perform the remediation
fix_audit_watch_rule "auditctl" "/etc/group" "wa" "audit_rules_usergroup_modification"
fix_audit_watch_rule "auditctl" "/etc/passwd" "wa" "audit_rules_usergroup_modification"
fix_audit_watch_rule "auditctl" "/etc/gshadow" "wa" "audit_rules_usergroup_modification"
fix_audit_watch_rule "auditctl" "/etc/shadow" "wa" "audit_rules_usergroup_modification"
fix_audit_watch_rule "auditctl" "/etc/security/opasswd" "wa" "audit_rules_usergroup_modification"

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_rules_networkconfig_modification -a always,exit -F arch=ARCH -S sethostname -S setdomainname -k audit_rules_networkconfig_modification -w /etc/issue -p wa -k audit_rules_networkconfig_modification -w /etc/issue.net -p wa -k audit_rules_networkconfig_modification -w /etc/hosts -p wa -k audit_rules_networkconfig_modification -w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification

identifiers:  CCE-26648-6, DISA FSO RHEL-06-000182

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

Remediation script:

# Include source function library.
. /usr/share/scap-security-guide/remediation_functions

# First perform the remediation of the syscall rule
# Retrieve hardware architecture of the underlying system
[ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64")

for ARCH in "${RULE_ARCHS[@]}"
do
	PATTERN="-a always,exit -F arch=$ARCH -S .* -k *"
	# Use escaped BRE regex to specify rule group
	GROUP="set\(host\|domain\)name"
	FULL_RULE="-a always,exit -F arch=$ARCH -S sethostname -S setdomainname -k audit_rules_networkconfig_modification"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

# Then perform the remediations for the watch rules
fix_audit_watch_rule "auditctl" "/etc/issue" "wa" "audit_rules_networkconfig_modification"
fix_audit_watch_rule "auditctl" "/etc/issue.net" "wa" "audit_rules_networkconfig_modification"
fix_audit_watch_rule "auditctl" "/etc/hosts" "wa" "audit_rules_networkconfig_modification"
fix_audit_watch_rule "auditctl" "/etc/sysconfig/network" "wa" "audit_rules_networkconfig_modification"

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, DISA FSO RHEL-06-000183

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

Remediation script:

# Include source function library.
. /usr/share/scap-security-guide/remediation_functions

# Perform the remediation
fix_audit_watch_rule "auditctl" "/etc/selinux/" "wa" "MAC-policy"

Record Attempts to Alter Login and Logout Eventsrule

The audit system already collects login info for all users and root. To watch for attempted manual edits of files involved in storing login events, add the following to /etc/audit/audit.rules: -w /var/log/faillog -p wa -k logins -w /var/log/lastlog -p wa -k logins

identifiers:  CCE-26691-6

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

Record Attempts to Alter Process and Session Initiation Informationrule

The audit system already collects process information for all users and root. To watch for attempted manual edits of files involved in storing such process information, add the following to /etc/audit/audit.rules: -w /var/run/utmp -p wa -k session -w /var/log/btmp -p wa -k session -w /var/log/wtmp -p wa -k session

identifiers:  CCE-26610-6

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

Remediation script:

# Include source function library.
. /usr/share/scap-security-guide/remediation_functions

# Perform the remediation
fix_audit_watch_rule "auditctl" "/var/run/utmp" "wa" "session"
fix_audit_watch_rule "auditctl" "/var/log/btmp" "wa" "session"
fix_audit_watch_rule "auditctl" "/var/log/wtmp" "wa" "session"

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 If the system is 64 bit then also add the following: -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, DISA FSO RHEL-06-000197

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

Remediation script:

# Include source function library.
. /usr/share/scap-security-guide/remediation_functions

# Perform the remediation of the syscall rule
# Retrieve hardware architecture of the underlying system
[ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64")

for ARCH in "${RULE_ARCHS[@]}"
do

	# First fix the -EACCES requirement
	PATTERN="-a always,exit -F arch=$ARCH -S .* -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k *"
	# Use escaped BRE regex to specify rule group
	GROUP="\(creat\|open\|truncate\)"
	FULL_RULE="-a always,exit -F arch=$ARCH -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"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"

	# Then fix the -EPERM requirement
	PATTERN="-a always,exit -F arch=$ARCH -S .* -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k *"
	# No need to change content of $GROUP variable - it's the same as for -EACCES case above
	FULL_RULE="-a always,exit -F arch=$ARCH -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"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"

done

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, run the following command for each local partition PART: $ sudo find PART -xdev -type f -perm -4000 -o -type f -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, DISA FSO RHEL-06-000198

references:  AC-3(10)), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AC-6(9), AU-12(a), AU-12(c), IR-5, 40, Test attestation on 20140703 by JL

Remediation script:

readonly AUDIT_RULES='/etc/audit/audit.rules'

# Obtain the list of SUID/SGID binaries on the particular system into PRIVILEGED_BINARIES array
PRIVILEGED_BINARIES=($(find / -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/null))

# Keep list of SUID/SGID binaries that have been already handled within some previous iteration
declare -a SBINARIES_TO_SKIP=()

# For each found binary from that list...
for SBINARY in ${PRIVILEGED_BINARIES[@]}
do

    # Replace possible slash '/' character in SBINARY definition so we could use it in sed expressions below
    SBINARY_ESC=${SBINARY//$'/'/$'\/'}

    # Check if this SBINARY wasn't already handled in some of the previous iterations
    if [[ $(sed -ne "/$SBINARY_ESC/p" <<< ${SBINARIES_TO_SKIP[@]}) ]]
    then
        # If so, don't process it second time & go to process next SBINARY
        continue
    fi

    # Search existing audit.rule's content for match. Match criteria:
    # * existing rule is for the same SUID/SGID binary we are currently processing (but
    #   can contain multiple -F path= elements covering multiple SUID/SGID binaries)
    # * existing rule contains all arguments from expected rule form (though can contain
    #   them in arbitrary order)
    BASE_SEARCH=$(sed -e "/-a always,exit/!d" -e "/-F path=${SBINARY_ESC}/!d"	\
                      -e "/-F path=[^[:space:]]\+/!d" -e "/-F perm=.*/!d"	\
                      -e "/-F auid>=500/!d" -e "/-F auid!=4294967295/!d"	\
                      -e "/-k privileged/!d" $AUDIT_RULES)

    # Define expected rule form for this binary
    EXPECTED_RULE="-a always,exit -F path=${SBINARY} -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged"

    # Require execute access type to be set for existing audit rule
    EXEC_ACCESS='x'

    # Search existing audit.rules content for presence of rule pattern for this binary
    if [[ $BASE_SEARCH ]]
    then

        # Current /etc/audit/audit.rules already contains rule for this binary =>
        # Store the exact form of found rule for this binary for further processing
        CONCRETE_RULE=$BASE_SEARCH

        # Select all other SUID/SGID binaries possibly also present in the found rule
        IFS=$'\n' HANDLED_SBINARIES=($(grep -o -e "-F path=[^[:space:]]\+" <<< $CONCRETE_RULE))
        IFS=$' ' HANDLED_SBINARIES=(${HANDLED_SBINARIES[@]//-F path=/})

        # Merge the list of such SUID/SGID binaries found in this iteration with global list ignoring duplicates
        SBINARIES_TO_SKIP=($(for i in "${SBINARIES_TO_SKIP[@]}" "${HANDLED_SBINARIES[@]}"; do echo $i; done | sort -du))

        # Separate CONCRETE_RULE into three sections using hash '#'
        # sign as a delimiter around rule's permission section borders
        CONCRETE_RULE=$(echo $CONCRETE_RULE | sed -n "s/\(.*\)\+\(-F perm=[rwax]\+\)\+/\1#\2#/p")

        # Split CONCRETE_RULE into head, perm, and tail sections using hash '#' delimiter
        IFS=$'#' read RULE_HEAD RULE_PERM RULE_TAIL <<<  "$CONCRETE_RULE"

        # Extract already present exact access type [r|w|x|a] from rule's permission section
        ACCESS_TYPE=${RULE_PERM//-F perm=/}

        # Verify current permission access type(s) for rule contain 'x' (execute) permission
        if ! grep -q "$EXEC_ACCESS" <<< "$ACCESS_TYPE"
        then

            # If not, append the 'x' (execute) permission to the existing access type bits
            ACCESS_TYPE="$ACCESS_TYPE$EXEC_ACCESS"
            # Reconstruct the permissions section for the rule
            NEW_RULE_PERM="-F perm=$ACCESS_TYPE"
            # Update existing rule in /etc/audit/audit.rules with the new permission section
            sed -i "s#${RULE_HEAD}\(.*\)${RULE_TAIL}#${RULE_HEAD}${NEW_RULE_PERM}${RULE_TAIL}#" $AUDIT_RULES

        fi

    else

        # Current /etc/audit/audit.rules content doesn't contain expected rule for this
        # SUID/SGID binary yet => append it
        echo $EXPECTED_RULE >> $AUDIT_RULES
    fi

done

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, DISA FSO RHEL-06-000199

references:  AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Test attestation on 20121024 by DS

Remediation script:

# Include source function library.
. /usr/share/scap-security-guide/remediation_functions

# Perform the remediation of the syscall rule
# Retrieve hardware architecture of the underlying system
[ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64")

for ARCH in "${RULE_ARCHS[@]}"
do
	PATTERN="-a always,exit -F arch=$ARCH -S .* -F auid>=500 -F auid!=4294967295 -k *"
	GROUP="mount"
	FULL_RULE="-a always,exit -F arch=$ARCH -S mount -F auid>=500 -F auid!=4294967295 -k export"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

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, DISA FSO RHEL-06-000200

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

Remediation script:

# Include source function library.
. /usr/share/scap-security-guide/remediation_functions

# Perform the remediation for the syscall rule
# Retrieve hardware architecture of the underlying system
[ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64")

for ARCH in ${RULE_ARCHS[@]}
do
	PATTERN="-a always,exit -F arch=$ARCH -S .* -F auid>=500 -F auid!=4294967295 -k delete"
	# Use escaped BRE regex to specify rule group
	GROUP="\(rmdir\|unlink\|rename\)"
	FULL_RULE="-a always,exit -F arch=$ARCH -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295 -k delete"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

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, DISA FSO RHEL-06-000201

references:  AC-2(7)(b), AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Test attestation on 20121024 by DS

Remediation script:

# Include source function library.
. /usr/share/scap-security-guide/remediation_functions

# Perform the remediation
fix_audit_watch_rule "auditctl" "/etc/sudoers" "wa" "actions"

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, DISA FSO RHEL-06-000202

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

Remediation script:

# Include source function library.
. /usr/share/scap-security-guide/remediation_functions

# First perform the remediation of the syscall rule
# Retrieve hardware architecture of the underlying system
# Note: 32-bit kernel modules can't be loaded / unloaded on 64-bit kernel =>
#       it's not required on a 64-bit system to check also for the presence
#       of 32-bit's equivalent of the corresponding rule. Therefore for
#       each system it's enought to check presence of system's native rule form.
[ $(getconf LONG_BIT) = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b64")

for ARCH in "${RULE_ARCHS[@]}"
do
	PATTERN="-a always,exit -F arch=$ARCH -S .* -k *"
	# Use escaped BRE regex to specify rule group
	GROUP="\(init\|delete\)_module"
	FULL_RULE="-a always,exit -F arch=$ARCH -S init_module -S delete_module -k modules"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

# Then perform the remediations for the watch rules
fix_audit_watch_rule "auditctl" "/sbin/insmod" "x" "modules"
fix_audit_watch_rule "auditctl" "/sbin/rmmod" "x" "modules"
fix_audit_watch_rule "auditctl" "/sbin/modprobe" "x" "modules"

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

Remediation script:

readonly AUDIT_RULES='/etc/audit/audit.rules'

# If '-e .*' setting present in audit.rules already, delete it since the
# auditctl(8) manual page instructs it should be the last rule in configuration
sed -i '/-e[[:space:]]\+.*/d' $AUDIT_RULES

# Append '-e 2' requirement at the end of audit.rules
echo '' >> $AUDIT_RULES
echo '# Set the audit.rules configuration immutable per security requirements' >> $AUDIT_RULES
echo '# Reboot is required to change audit rules once this setting is applied' >> $AUDIT_RULES
echo '-e 2' >> $AUDIT_RULES

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: $ sudo chkconfig --level 2345 auditd on

identifiers:  CCE-27058-7, DISA FSO RHEL-06-000145

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, Test attestation on 20121024 by DS

Remediation script:
#
# Enable auditd for all run levels
#
/sbin/chkconfig --level 0123456 auditd on

#
# Start auditd if not currently running
#
/sbin/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, DISA FSO RHEL-06-000525

references:  AC-17(1), AU-14(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 Red Hat Enterprise Linux 6 system and provides guidance about which ones can be safely disabled. Red Hat Enterprise Linux 6 provides a convenient minimal install option that essentially installs the bare necessities for a functional system. When building Red Hat Enterprise Linux 6 servers, it is highly recommended to select the minimal packages and then build up the system from there.

contains 34 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 Red Hat Enterprise Linux 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 10 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 Red Hat Enterprise Linux 6.

contains 1 rule

Uninstall xinetd Packagerule

The xinetd package can be uninstalled with the following command: $ sudo yum erase xinetd

identifiers:  CCE-27005-8, DISA FSO RHEL-06-000204

references:  CM-7, 305, Test attestation on 20121026 by DS

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

Uninstall telnet-server Packagerule

The telnet-server package can be uninstalled with the following command: $ sudo yum erase telnet-server

identifiers:  CCE-27073-6, DISA FSO RHEL-06-000206

references:  CM-7, 305, 381, Test attestation on 20121026 by DS

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

Remove telnet Clientsrule

The telnet client allows users to start connections to other systems via the telnet protocol.

identifiers:  CCE-

Rlogin, Rsh, and Rexecgroup

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

contains 3 rules

Uninstall rsh-server Packagerule

The rsh-server package can be uninstalled with the following command: $ sudo yum erase rsh-server

identifiers:  CCE-27062-9, DISA FSO RHEL-06-000213

references:  CM-7, 305, 381, Test attestation on 20121026 by DS

Remediation script:
yum -y erase rsh-server

Uninstal rsh Packagerule

The rsh package contains the client commands for the rsh services

identifiers:  CCE-

references:  Test attestation on 20140530 by JL

Remove Rsh Trust Filesrule

The files /etc/hosts.equiv and ~/.rhosts (in each user's home directory) list remote hosts and users that are trusted by the local system when using the rshd daemon. To remove these files, run the following command to delete them from any location: $ sudo rm /etc/hosts.equiv $ rm ~/.rhosts

identifiers:  CCE-27270-8, DISA FSO RHEL-06-000019

references:  CM-7, 1436, Test attestation on 20121026 by DS

Remediation script:
find -type f -name .rhosts -exec rm -f '{}' \;
rm /etc/hosts.equiv

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: $ sudo yum erase ypserv

identifiers:  CCE-27079-3, DISA FSO RHEL-06-000220

references:  CM-7, 305, 381, Test attestation on 20121026 by DS

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

Remove NIS Clientrule

The Network Information Service (NIS), formerly known as Yellow Pages, is a client-server directory service protocol used to distribute system configuration files. The NIS client (ypbind) was used to bind a machine to an NIS server and receive the distributed configuration files.

identifiers:  CCE-

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

Uninstall tftp-server Packagerule

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

identifiers:  CCE-26946-4, DISA FSO RHEL-06-000222

references:  CM-7, 305, Test attestation on 20121026 by DS

Remove tftprule

Trivial File Transfer Protocol (TFTP) is a simple file transfer protocol, typically used to automatically transfer configuration or boot files between machines. TFTP does not support authentication and can be easily hacked. The package tftp is a client program that allows for connections to a tftp server.

identifiers:  CCE-

Base Servicesgroup

This section addresses the base services that are installed on a Red Hat Enterprise Linux 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 1 rule

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: $ sudo chkconfig rhnsd off

identifiers:  CCE-26846-6, DISA FSO RHEL-06-000009

references:  CM-7, 382, Test attestation on 20121024 by DS

Remediation script:
#
# Disable rhnsd for all run levels
#
/sbin/chkconfig --level 0123456 rhnsd off

#
# Stop rhnsd if currently running
#
/sbin/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

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: $ sudo chkconfig --level 2345 crond on

identifiers:  CCE-27070-2, DISA FSO RHEL-06-000224

references:  CM-7, Test attestation on 20121024 by DS

Remediation script:
#
# Enable crond for all run levels
#
/sbin/chkconfig --level 0123456 crond on

#
# Start crond if not currently running
#
/sbin/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: $ sudo chkconfig atd off

identifiers:  CCE-27249-2, DISA FSO RHEL-06-000262

references:  CM-7, 381

Remediation script:
#
# Disable atd for all run levels
#
/sbin/chkconfig --level 0123456 atd off

#
# Stop atd if currently running
#
/sbin/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 9 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 9 rules

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, DISA FSO RHEL-06-000227

references:  AC-3(10), IA-5(1)(c), 776, 774, 1436, Test attestation on 20121024 by DS

Remediation script:
grep -qi ^Protocol /etc/ssh/sshd_config && \
  sed -i "s/Protocol.*/Protocol 2/gI" /etc/ssh/sshd_config
if ! [ $? -eq 0 ]; then
    echo "Protocol 2" >> /etc/ssh/sshd_config
fi

Limit Users' SSH Accessrule

By default, the SSH configuration allows any user with an account to access the system. In order to specify the users that are allowed to login via SSH and deny all other users, add or correct the following line in the /etc/ssh/sshd_config file: DenyUsers USER1 USER2 Where USER1 and USER2 are valid user names.

identifiers:  CCE-27556-0

references:  AC-3, http://iase.disa.mil/stigs/cci/Pages/index.aspx

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 300 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, DISA FSO RHEL-06-000230

references:  AC-2(5), SA-8, 879, 1133, Test attestation on 20121024 by DS

Remediation script:
sshd_idle_timeout_value="300"
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

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, DISA FSO RHEL-06-000234

references:  AC-3, 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, DISA FSO RHEL-06-000236

references:  AC-3, 765, 766, Test attestation on 20121024 by DS

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, DISA FSO RHEL-06-000237

references:  AC-3, AC-6(2), IA-2(1), 770, Test attestation on 20121024 by DS

Remediation script:

SSHD_CONFIG='/etc/ssh/sshd_config'

# Obtain line number of first uncommented case-insensitive occurrence of Match
# block directive (possibly prefixed with whitespace) present in $SSHD_CONFIG
FIRST_MATCH_BLOCK=$(sed -n '/^[[:space:]]*Match[^\n]*/I{=;q}' $SSHD_CONFIG)

# Obtain line number of first uncommented case-insensitive occurence of
# PermitRootLogin directive (possibly prefixed with whitespace) present in
# $SSHD_CONFIG
FIRST_PERMIT_ROOT_LOGIN=$(sed -n '/^[[:space:]]*PermitRootLogin[^\n]*/I{=;q}' $SSHD_CONFIG)

# Case: Match block directive not present in $SSHD_CONFIG
if [ -z "$FIRST_MATCH_BLOCK" ]
then

    # Case: PermitRootLogin directive not present in $SSHD_CONFIG yet
    if [ -z "$FIRST_PERMIT_ROOT_LOGIN" ]
    then
        # Append 'PermitRootLogin no' at the end of $SSHD_CONFIG
        echo -e "\nPermitRootLogin no" >> $SSHD_CONFIG

    # Case: PermitRootLogin directive present in $SSHD_CONFIG already
    else
        # Replace first uncommented case-insensitive occurrence
        # of PermitRootLogin directive
        sed -i "$FIRST_PERMIT_ROOT_LOGIN s/^[[:space:]]*PermitRootLogin.*$/PermitRootLogin no/I" $SSHD_CONFIG
    fi

# Case: Match block directive present in $SSHD_CONFIG
else

    # Case: PermitRootLogin directive not present in $SSHD_CONFIG yet
    if [ -z "$FIRST_PERMIT_ROOT_LOGIN" ]
    then
        # Prepend 'PermitRootLogin no' before first uncommented
        # case-insensitive occurrence of Match block directive
        sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/PermitRootLogin no\n\1/I" $SSHD_CONFIG

    # Case: PermitRootLogin directive present in $SSHD_CONFIG and placed
    #       before first Match block directive
    elif [ "$FIRST_PERMIT_ROOT_LOGIN" -lt "$FIRST_MATCH_BLOCK" ]
    then
        # Replace first uncommented case-insensitive occurrence
        # of PermitRootLogin directive
        sed -i "$FIRST_PERMIT_ROOT_LOGIN s/^[[:space:]]*PermitRootLogin.*$/PermitRootLogin no/I" $SSHD_CONFIG

    # Case: PermitRootLogin directive present in $SSHD_CONFIG and placed
    # after first Match block directive
    else
         # Prepend 'PermitRootLogin no' before first uncommented
         # case-insensitive occurrence of Match block directive
         sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/PermitRootLogin no\n\1/I" $SSHD_CONFIG
    fi
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, DISA FSO RHEL-06-000239

references:  AC-3, 765, 766, Test attestation on 20121024 by DS

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, DISA FSO RHEL-06-000240

references:  AC-8(a), 48, Test attestation on 20121024 by DS

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

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, DISA FSO RHEL-06-000243

references:  AC-3, AC-17(2), SI-7, IA-5(1)(c), IA-7, 803, 1144, 1145, 1146, Test attestation on 20121024 by DS

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.

contains 1 rule

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.

contains 1 rule

Remove the X Windows Package Grouprule

Removing all packages which constitute the X Window System ensures users or malicious software cannot start X. To do so, run the following command: $ sudo yum groupremove "X Window System"

identifiers:  CCE-27198-1, DISA FSO RHEL-06-000291

references:  366, Test attestation on 20121025 by DS

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: $ sudo chkconfig avahi-daemon off

identifiers:  CCE-27087-6, DISA FSO RHEL-06-000246

references:  CM-7, 366

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.

contains 1 rule

Disable the CUPS Servicerule

The cups service can be disabled with the following command: $ sudo chkconfig cups off

identifiers:  CCE-26899-5

references:  CM-7

Remediation script:
#
# Disable cups for all run levels
#
/sbin/chkconfig --level 0123456 cups off

#
# Stop cups if currently running
#
/sbin/service cups stop

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 1 rule

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 1 rule

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: $ sudo yum erase dhcp

identifiers:  CCE-27120-5

references:  CM-7, 366, Test attestation on 20121024 by DS

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 3 rules

Enable the NTP Daemonrule

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

identifiers:  CCE-27093-4, DISA FSO RHEL-06-000247

references:  AU-8(1), 160, Test attestation on 20121024 by DS

Remediation script:
#
# Enable ntpd for all run levels
#
/sbin/chkconfig --level 0123456 ntpd on

#
# Start ntpd if not currently running
#
/sbin/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, DISA FSO RHEL-06-000248

references:  AU-8(1), 160, Test attestation on 20121024 by DS

Specify Additional Remote NTP Serversrule

Additional NTP servers can be specified for time synchronization in the file /etc/ntp.conf. To do so, add additional lines of the following form, substituting the IP address or hostname of a remote NTP server for ntpserver: server ntpserver

identifiers:  CCE-26958-9

references:  AU-8(1)

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 Red Hat Enterprise Linux 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 1 rule

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, DISA FSO RHEL-06-000249

references:  CM-7, 382, Test attestation on 20121024 by DS

LDAPgroup

LDAP is a popular directory service, that is, a standardized way of looking up information from a central database. Red Hat Enterprise Linux 6 includes software that enables a system to act as both an LDAP client and server.

contains 1 rule

Configure OpenLDAP Servergroup

This section details some security-relevant settings for an OpenLDAP server. Installation and configuration of OpenLDAP on Red Hat Enterprise Linux 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

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. $ sudo yum erase openldap-servers The openldap-servers RPM is not installed by default on Red Hat Enterprise Linux 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, DISA FSO RHEL-06-000256

references:  CM-7, 366, Test attestation on 20121024 by DS

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 1 rule

Disable vsftpd if Possiblegroup

contains 1 rule

Uninstall vsftpd Packagerule

The vsftpd package can be removed with the following command: $ sudo yum erase vsftpd

identifiers:  CCE-26687-4

references:  CM-7, 1436

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 sourcesWeb server software is very complex, and includes a long history of vulnerabilitiesThe 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 1 rule

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 1 rule

Uninstall httpd Packagerule

The httpd package can be removed with the following command: $ sudo yum erase httpd

identifiers:  CCE-27133-8

references:  CM-7

Remediation script:
if rpm -qa | grep -q httpd; then
	yum -y remove httpd
fi

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 1 rule

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 1 rule

Uninstall net-snmp Packagerule

The net-snmp package provides the snmpd service. The net-snmp package can be removed with the following command: $ sudo yum erase net-snmp

identifiers:  CCE-26332-7

Remediation script:
if rpm -qa | grep -q net-snmp; then
	yum -y remove net-snmp
fi
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.