Guide to the Secure Configuration of Red Hat Enterprise Linux 6

with profile PCI-DSS v3 Control Baseline for Red Hat Enterprise Linux 6

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

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

Revision History

Current version: 0.9

  • draft (as of 2015-07-30)

Platforms

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

Table of Contents

  1. System Settings
    1. Installing and Maintaining Software
    2. File Permissions and Masks
    3. Account and Access Control
    4. Network Configuration and Firewalls
    5. Configure Syslog
    6. System Accounting with auditd
  2. Services
    1. SSH Server
    2. Network Time Protocol

Checklist

contains 94 rules

System Settingsgroup

contains 90 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 11 rules

Updating Softwaregroup

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

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

contains 4 rules

Ensure Red Hat GPG Key Installedrule

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

$ 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

Rationale:

The Red Hat GPG key is necessary to cryptographically verify packages are from Red Hat.

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

Rationale:

Ensuring the validity of packages' cryptographic signatures prior to installation ensures the authenticity of the software and protects against malicious tampering.

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

Rationale:

Ensuring all packages' cryptographic signatures are valid prior to installation ensures the authenticity of the software and protects against malicious tampering.

identifiers:  CCE-26647-8, DISA FSO RHEL-06-000015

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

Ensure Software Patches Installedrule

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

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

Rationale:

Installing software updates is a fundamental mitigation against the exploitation of publicly-known vulnerabilities.

identifiers:  CCE-27635-2, DISA FSO RHEL-06-000011

references:  SI-2, MA-1(b), 1227, 1233, 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 7 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

Rationale:

The AIDE package must be installed if it is to be available for integrity checking.

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

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.

Rationale:

For AIDE to be effective, an initial database of "known-good" information about files must be captured and it should be able to be verified against the installed files.

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.

Rationale:

By default, AIDE does not install itself for periodic execution. Periodically running AIDE is necessary to reveal unexpected changes in installed files.

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

Rationale:

Permissions on system binaries and configuration files that are too generous could allow an unauthorized user to gain privileges that they should not have. The permissions set by the vendor should be maintained. Any deviations from this baseline should be investigated.

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

Rationale:

The hashes of important files like system executables should match the information given by the RPM database. Executables with erroneous hashes could be a sign of nefarious activity on the system.

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

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

Additional Security Softwaregroup

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

contains 1 rule

Install Intrusion Detection Softwarerule

The base Red Hat platform already includes a sophisticated auditing system that can detect intruder activity, as well as SELinux, which provides host-based intrusion prevention capabilities by confining privileged programs and user sessions which may become compromised.
In DoD environments, supplemental intrusion detection tools, such as, the McAfee Host-based Security System, are available to integrate with existing infrastructure. When these supplemental tools interfere with the proper functioning of SELinux, SELinux takes precedence.

Rationale:

Host-based intrusion detection tools provide a system-level defense when an intruder gains access to a system or network.

identifiers:  CCE-27409-2, DISA FSO RHEL-06-000285

references:  SC-7, 1263

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

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

Verify User Who Owns shadow Filerule

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

$ sudo chown root /etc/shadow

Rationale:

The /etc/shadow file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.

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

Rationale:

The /etc/shadow file stores password hashes. Protection of this file is critical for system security.

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

Rationale:

The /etc/shadow file contains the list of local system accounts and stores password hashes. Protection of this file is critical for system security. Failure to give ownership of this file to root provides the designated owner with access to sensitive information which could weaken the system security posture.

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

Rationale:

The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security.

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

Rationale:

The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security.

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

Rationale:

The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security.

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 passwd Filerule

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

$ sudo chown root /etc/passwd

Rationale:

The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security.

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

Rationale:

The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security.

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

Rationale:

If the /etc/passwd file is writable by a group-owner or the world the risk of its compromise is increased. The file contains the list of accounts on the system and associated information, and protection of this file is critical for system security.

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

Account and Access Controlgroup

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

contains 24 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 6 rules

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.

Rationale:

If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.

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

Verify All Account Password Hashes are Shadowedrule

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

Rationale:

The hashes for all user account passwords should be stored in the file /etc/shadow and never in /etc/passwd, which is readable by all users.

identifiers:  CCE-26476-2, DISA FSO RHEL-06-000031

references:  IA-5(h), 201, Test attestation on 20121024 by DS

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.

Rationale:

Inconsistency in GIDs between /etc/passwd and /etc/group could lead to a user having unintended rights.

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

references:  366, Test attestation on 20121024 by DS

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 1 rule
contains 2 rules

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.

warning  Be careful when making changes to PAM's configuration files. The syntax for these files is complex, and modifications can have unexpected consequences. The default configurations shipped with applications should be sufficient for most users.
warning  Running authconfig or system-config-authentication will re-write the PAM configuration files, destroying any manually made changes and replacing them with a series of system defaults. One reference to the configuration file syntax can be found at http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-configuration-file.html.
contains 11 rules

Set Password Quality Requirementsgroup

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

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

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

contains 4 rules

Set Password Quality Requirements, if using pam_cracklibgroup

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

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

password requisite pam_cracklib.so try_first_pass retry=3
and then alter it to read:
password required pam_cracklib.so try_first_pass retry=3 maxrepeat=3 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 difok=4
If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth. The arguments can be modified to ensure compliance with your organization's security policy. Discussion of each parameter follows.

warning  Note that the password quality requirements are not enforced for the root account for some reason.
contains 4 rules

Set Password Strength Minimum Digit Charactersrule

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

Rationale:

Requiring digits makes password guessing attacks more difficult by ensuring a larger search space.

identifiers:  CCE-26374-9, DISA FSO RHEL-06-000056

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

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

Set Password Minimum Lengthrule

The pam_cracklib module's minlen parameter controls requirements for minimum characters required in a password. Add minlen=7 after pam_pwquality to set minimum password length requirements.

Rationale:

Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.

identifiers:  CCE-26615-5

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

Set Password Strength Minimum Uppercase Charactersrule

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

Rationale:

Requiring a minimum number of uppercase characters makes password guessing attacks more difficult by ensuring a larger search space.

identifiers:  CCE-26601-5, DISA FSO RHEL-06-000057

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

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

Set Password Strength Minimum Lowercase Charactersrule

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

Rationale:

Requiring a minimum number of lowercase characters makes password guessing attacks more difficult by ensuring a larger search space.

identifiers:  CCE-26631-2, DISA FSO RHEL-06-000059

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

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

Set Lockouts for Failed Password Attemptsgroup

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

warning  Locking out user accounts presents the risk of a denial-of-service attack. The lockout policy must weigh whether the risk of such a denial-of-service attack outweighs the benefits of thwarting password guessing attacks.
contains 3 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=6 unlock_time=1800 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=6 unlock_time=1800 fail_interval=900
  • Add the following line immediately before the pam_unix.so statement in the ACCOUNT section:
    account required pam_faillock.so

Rationale:

Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks.

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

references:  AC-7(a), 44

Remediation script:
var_accounts_passwords_pam_faillock_deny="6"
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

Set Lockout Time For Failed Password Attemptsrule

To configure the system to lock out accounts after a number of incorrect login attempts and require an administrator to unlock the account 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=6 unlock_time=1800 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=6 unlock_time=1800 fail_interval=900
  • Add the following line immediately before the pam_unix.so statement in the ACCOUNT section:
    account required pam_faillock.so

Rationale:

Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks. Ensuring that an administrator is involved in unlocking locked accounts draws appropriate attention to such situations.

identifiers:  CCE-27110-6, DISA FSO RHEL-06-000356

references:  AC-7(b), 47

Remediation script:
var_accounts_passwords_pam_faillock_unlock_time="1800"
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, unlock_time directive present?
		if grep -q "^auth.*[default=die].*pam_faillock.so.*authfail.*unlock_time=" $pamFile; then

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

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

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

	# pam_faillock.so not present yet
	else

		# insert pam_faillock.so preauth & authfail rows with proper value of the 'unlock_time' option
		sed -i --follow-symlink "/^auth.*sufficient.*pam_unix.so.*/i auth        required      pam_faillock.so preauth silent unlock_time=$var_accounts_passwords_pam_faillock_unlock_time" $pamFile
		sed -i --follow-symlink "/^auth.*sufficient.*pam_unix.so.*/a auth        [default=die] pam_faillock.so authfail unlock_time=$var_accounts_passwords_pam_faillock_unlock_time" $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=4 to the line which refers to the pam_unix.so module, as shown:

password sufficient pam_unix.so existing_options remember=4
The DoD STIG requirement is 5 passwords.

Rationale:

Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user.

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="4"
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

Set Password Hashing Algorithmgroup

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

contains 3 rules

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

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

password    sufficient    pam_unix.so sha512 other arguments...
This will help ensure when local users change their passwords, hashes for the new passwords will be generated using the SHA-512 algorithm. This is the default.

Rationale:

Using a stronger hashing algorithm makes password cracking attacks more difficult.

identifiers:  CCE-26303-8, DISA FSO RHEL-06-000062

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

Remediation script:
if ! grep -q "^password.*sufficient.*pam_unix.so.*sha512" /etc/pam.d/system-auth; then   
	sed -i --follow-symlink "/^password.*sufficient.*pam_unix.so/ s/$/ sha512/" /etc/pam.d/system-auth
fi

Set Password Hashing Algorithm in /etc/login.defsrule

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

ENCRYPT_METHOD SHA512

Rationale:

Using a stronger hashing algorithm makes password cracking attacks more difficult.

identifiers:  CCE-27228-6, DISA FSO RHEL-06-000063

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

Remediation script:
if grep --silent ^ENCRYPT_METHOD /etc/login.defs ; then
	sed -i 's/^ENCRYPT_METHOD.*/ENCRYPT_METHOD SHA512/g' /etc/login.defs
else
	echo "" >> /etc/login.defs
	echo "ENCRYPT_METHOD SHA512" >> /etc/login.defs
fi

Set Password Hashing Algorithm in /etc/libuser.confrule

In /etc/libuser.conf, add or correct the following line in its [defaults] section to ensure the system will use the SHA-512 algorithm for password hashing:

crypt_style = sha512

Rationale:

Using a stronger hashing algorithm makes password cracking attacks more difficult.

identifiers:  CCE-27229-4, DISA FSO RHEL-06-000064

references:  IA-5(b), IA-5(c), IA-5(1)(c), IA-7, 803, Test attestation on 20121026 by DS

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

Set Boot Loader Passwordgroup

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

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

Rationale:

Only root should be able to modify important boot parameters.

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

references:  http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 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

Rationale:

The root group is a highly-privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway.

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

references:  http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 225, Test attestation on 20121026 by DS

Remediation script:
chgrp root /etc/grub.conf

Configure Screen Lockinggroup

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

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

contains 5 rules

Configure GUI Screen Lockinggroup

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

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

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

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

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

contains 4 rules

Set GNOME Login Inactivity Timeoutrule

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

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

Rationale:

Setting the idle delay controls when the screensaver will start, and can be combined with screen locking to prevent access from passersby.

identifiers:  CCE-26828-4, DISA FSO RHEL-06-000257

references:  AC-11(a), 57

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

# Set the idle time-out value for inactivity in the GNOME desktop to meet the
# requirement
gconftool-2 --direct \
            --config-source "xml:readwrite:/etc/gconf/gconf.xml.mandatory" \
            --type int \
            --set /desktop/gnome/session/idle_delay ${inactivity_timeout_value}

GNOME Desktop Screensaver Mandatory Userule

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

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

Rationale:

Enabling idle activation of the screensaver ensures the screensaver will be activated after the idle delay. Applications requiring continuous, real-time screen display (such as network management products) require the login session does not have administrator rights and the display station is located in a controlled-access area.

identifiers:  CCE-26600-7, DISA FSO RHEL-06-000258

references:  AC-11(a), 57

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

# Set the screensaver activation in the GNOME desktop after a period of inactivity
gconftool-2 --direct \
            --config-source "xml:readwrite:/etc/gconf/gconf.xml.mandatory" \
            --type bool \
            --set /apps/gnome-screensaver/idle_activation_enabled true

Enable Screen Lock Activation After Idle Periodrule

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

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

Rationale:

Enabling the activation of the screen lock after an idle period ensures password entry will be required in order to access the system, preventing access by passersby.

identifiers:  CCE-26235-2, DISA FSO RHEL-06-000259

references:  AC-11(a), 57

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

# Set the screensaver locking activation in the GNOME desktop when the
# screensaver is activated
gconftool-2 --direct \
            --config-source "xml:readwrite:/etc/gconf/gconf.xml.mandatory" \
            --type bool \
            --set /apps/gnome-screensaver/lock_enabled true

Implement Blank Screensaverrule

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

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

Rationale:

Setting the screensaver mode to blank-only conceals the contents of the display from passersby.

identifiers:  CCE-26638-7, DISA FSO RHEL-06-000260

references:  AC-11(b), 60

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

# Set the screensaver mode in the GNOME desktop to a blank screen
gconftool-2 --direct \
            --config-source "xml:readwrite:/etc/gconf/gconf.xml.mandatory" \
            --type string \
            --set /apps/gnome-screensaver/mode blank-only
contains 1 rule

Enable Smart Card Loginrule

To enable smart card authentication, consult the documentation at:

  • https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html
For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at:
  • https://access.redhat.com/solutions/82273

Rationale:

Smart card login provides two-factor authentication stronger than that provided by a username and password combination. Smart cards leverage PKI (public key infrastructure) in order to provide and verify credentials.

identifiers:  CCE-27440-7, DISA FSO RHEL-06-000349

references:  765, 766, 767, 768, 771, 772, 884

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

IPSec Supportgroup

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

contains 1 rule

Install openswan Packagerule

The Openswan package provides an implementation of IPsec and IKE, which permits the creation of secure tunnels over untrusted networks. The openswan package can be installed with the following command:

$ sudo yum install openswan

Rationale:

Providing the ability for remote users or systems to initiate a secure VPN connection protects information when it is transmitted over a wide area network.

identifiers:  CCE-27626-1, DISA FSO RHEL-06-000321

references:  AC-17, MA-4, SC-8, 1130, 1131

Remediation script:
yum -y install openswan

Configure Sysloggroup

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

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

contains 4 rules

Ensure Proper Configuration of Log Filesgroup

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

*.info;mail.none;authpriv.none;cron.none                /var/log/messages
authpriv.*                                              /var/log/secure
mail.*                                                  -/var/log/maillog
cron.*                                                  /var/log/cron
*.emerg                                                 *
uucp,news.crit                                          /var/log/spooler
local7.*                                                /var/log/boot.log
See the man page rsyslog.conf(5) for more information. Note that the rsyslog daemon can be configured to use a timestamp format that some log processing programs may not understand. If this occurs, edit the file /etc/rsyslog.conf and add or edit the following line:
$ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

contains 3 rules

Ensure Log Files Are Owned By Appropriate Userrule

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

$ ls -l LOGFILE
If the owner is not root, run the following command to correct this:
$ sudo chown root LOGFILE

Rationale:

The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access.

identifiers:  CCE-26812-8, DISA FSO RHEL-06-000133

references:  AC-6, 1314, Test attestation on 20121024 by DS

Ensure Log Files Are Owned By Appropriate Grouprule

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

$ ls -l LOGFILE
If the owner is not root, run the following command to correct this:
$ sudo chgrp root LOGFILE

Rationale:

The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access.

identifiers:  CCE-26821-9, DISA FSO RHEL-06-000134

references:  AC-6, 1314, Test attestation on 20121024 by DS

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

Rationale:

Log files can contain valuable information regarding system configuration. If the system log files are not protected unauthorized users could change the logged data, eliminating their forensic value.

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

references:  http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 1314, Test attestation on 20121024 by DS

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

Rationale:

Log files that are not properly rotated run the risk of growing so large that they fill up the /var/log partition. Valuable logging information could be lost if the /var/log partition becomes full.

identifiers:  CCE-27014-0, DISA FSO RHEL-06-000138

references:  AU-9, 366

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

Configure auditd Number of Logs Retainedrule

Determine how many log files auditd should retain when it rotates logs. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting NUMLOGS with the correct value of 5:

num_logs = NUMLOGS
Set the value to 5 for general-purpose systems. Note that values less than 2 result in no log rotation.

Rationale:

The total storage for audit log files must be large enough to retain log information over the period required. This is a function of the maximum log file size and the number of logs retained.

identifiers:  CCE-27522-2, DISA FSO RHEL-06-000159

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

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.

Rationale:

The total storage for audit log files must be large enough to retain log information over the period required. This is a function of the maximum log file size and the number of logs retained.

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:
  • ignore
  • syslog
  • suspend
  • rotate
  • keep_logs
Set the ACTION to rotate to ensure log rotation occurs. This is the default. The setting is case-insensitive.

Rationale:

Automatically rotating logs (by setting this to rotate) minimizes the chances of the system unexpectedly running out of disk space by being overwhelmed with log data. However, for systems that must never discard log data, or which use external processes to transfer it and reclaim space, keep_logs can be employed.

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:
  • ignore
  • syslog
  • email
  • exec
  • suspend
  • single
  • halt
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.

Rationale:

Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption.

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.

Rationale:

Administrators should be made aware of an inability to record audit records. If a separate partition or logical volume of adequate size is used, running low on space for audit records should never occur.

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

Rationale:

Email sent to the root account is typically aliased to the administrators of the system, who can take appropriate action.

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

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

Configure auditd to use audispd pluginrule

To configure the auditd service to use the audispd plugin, set the active line in /etc/audisp/plugins.d/syslog.conf to yes. Restart the auditdservice:

$ sudo service auditd restart

Rationale:

The auditd service does not include the ability to send audit records to a centralized server for management directly. It does, however, include an audit event multiplexor plugin (audispd) to pass audit records to the local syslog server

identifiers:  CCE-26933-2, DISA FSO RHEL-06-000509

references:  AU-1(b), AU-3(2), IR-5, 136

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

Records Events that Modify Date and Time Informationgroup

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

contains 5 rules

Record attempts to alter time through adjtimexrule

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

# audit_time_rules
-a always,exit -F arch=b32 -S adjtimex -k audit_time_rules
On a 64-bit system, add the following to /etc/audit/audit.rules:
# audit_time_rules
-a always,exit -F arch=b64 -S adjtimex -k audit_time_rules
The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls:
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime 
-k audit_time_rules

Rationale:

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 (such as sshd). All changes to the system time should be audited.

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

Rationale:

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 (such as sshd). All changes to the system time should be audited.

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

Rationale:

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 (such as sshd). All changes to the system time should be audited.

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 Time Through clock_settimerule

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

# audit_time_rules
-a always,exit -F arch=b32 -S clock_settime -k audit_time_rules
On a 64-bit system, add the following to /etc/audit/audit.rules:
# audit_time_rules
-a always,exit -F arch=b64 -S clock_settime -k audit_time_rules
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

Rationale:

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 (such as sshd). All changes to the system time should be audited.

identifiers:  CCE-27170-0, DISA FSO RHEL-06-000171

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

# 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 audit_time_rules"
	GROUP="clock_settime"
	FULL_RULE="-a always,exit -F arch=$ARCH -S clock_settime -k audit_time_rules"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
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.

Rationale:

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 (such as sshd). All changes to the system time should be audited.

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 the System's Discretionary Access Controlsgroup

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

-a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod
    -a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod
    -a always,exit -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod
If your system is 64 bit then these lines should be duplicated and the arch=b32 replaced with arch=b64 as follows:
-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod
    -a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod
    -a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

contains 13 rules

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

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

-a always,exit -F arch=b32 -S chmod -F auid>=500 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S chmod  -F auid>=500 -F auid!=4294967295 -k perm_mod

warning  Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

identifiers:  CCE-26280-8, DISA FSO RHEL-06-000184

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 *"
	GROUP="chmod"
	FULL_RULE="-a always,exit -F arch=$ARCH -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

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

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

-a always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 -k perm_mod

warning  Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

identifiers:  CCE-27173-4, DISA FSO RHEL-06-000185

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 *"
	GROUP="chown"
	FULL_RULE="-a always,exit -F arch=$ARCH -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

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

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

-a always,exit -F arch=b32 -S fchmod -F auid>=500 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S fchmod -F auid>=500 -F auid!=4294967295 -k perm_mod

warning  Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

identifiers:  CCE-27174-2, DISA FSO RHEL-06-000186

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 *"
	GROUP="chmod"
	FULL_RULE="-a always,exit -F arch=$ARCH -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

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

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

-a always,exit -F arch=b32 -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod

warning  Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

identifiers:  CCE-27175-9, DISA FSO RHEL-06-000187

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 *"
	GROUP="chmod"
	FULL_RULE="-a always,exit -F arch=$ARCH -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

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

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

-a always,exit -F arch=b32 -S fchown -F auid>=500 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S fchown -F auid>=500 -F auid!=4294967295 -k perm_mod

warning  Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

identifiers:  CCE-27177-5, DISA FSO RHEL-06-000188

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 *"
	GROUP="chown"
	FULL_RULE="-a always,exit -F arch=$ARCH -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

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

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

-a always,exit -F arch=b32 -S fchownat -F auid>=500 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S fchownat -F auid>=500 -F auid!=4294967295 -k perm_mod

warning  Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

identifiers:  CCE-27178-3, DISA FSO RHEL-06-000189

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 *"
	GROUP="chown"
	FULL_RULE="-a always,exit -F arch=$ARCH -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

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

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

-a always,exit -F arch=b32 -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

warning  Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

identifiers:  CCE-27179-1, DISA FSO RHEL-06-000190

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 auid>=500 -F auid!=4294967295 -k *"
	GROUP="xattr"
	FULL_RULE="-a always,exit -F arch=${ARCH} -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

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

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

-a always,exit -F arch=b32 -S fsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S fsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

warning  Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

identifiers:  CCE-27180-9, DISA FSO RHEL-06-000191

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 auid>=500 -F auid!=4294967295 -k *"
	GROUP="xattr"
	FULL_RULE="-a always,exit -F arch=${ARCH} -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

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

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

-a always,exit -F arch=b32 -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod

warning  Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

identifiers:  CCE-27181-7, DISA FSO RHEL-06-000192

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 *"
	GROUP="chown"
	FULL_RULE="-a always,exit -F arch=$ARCH -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

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

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

-a always,exit -F arch=b32 -S lremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S lremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

warning  Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

identifiers:  CCE-27182-5, DISA FSO RHEL-06-000193

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 auid>=500 -F auid!=4294967295 -k *"
	GROUP="xattr"
	FULL_RULE="-a always,exit -F arch=${ARCH} -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

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

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

-a always,exit -F arch=b32 -S lsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S lsetxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

warning  Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

identifiers:  CCE-27183-3, DISA FSO RHEL-06-000194

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 auid>=500 -F auid!=4294967295 -k *"
	GROUP="xattr"
	FULL_RULE="-a always,exit -F arch=${ARCH} -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

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

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

-a always,exit -F arch=b32 -S removexattr -F auid>=500 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S removexattr -F auid>=500 -F auid!=4294967295 -k perm_mod

warning  Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

identifiers:  CCE-27184-1, DISA FSO RHEL-06-000195

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 auid>=500 -F auid!=4294967295 -k *"
	GROUP="xattr"
	FULL_RULE="-a always,exit -F arch=${ARCH} -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

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

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

-a always,exit -F arch=b32 -S setxattr -F auid>=500 -F auid!=4294967295 -k perm_mod
If the system is 64 bit then also add the following:
-a always,exit -F arch=b64 -S setxattr -F auid>=500 -F auid!=4294967295 -k perm_mod

warning  Note that these rules can be configured in a number of ways while still achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
Rationale:

The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.

identifiers:  CCE-27185-8, DISA FSO RHEL-06-000196

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 auid>=500 -F auid!=4294967295 -k *"
	GROUP="xattr"
	FULL_RULE="-a always,exit -F arch=${ARCH} -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod"
	fix_audit_syscall_rule "auditctl" "$PATTERN" "$GROUP" "$ARCH" "$FULL_RULE"
done

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

Rationale:

In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy.

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

Rationale:

The network environment should not be modified by anything other than administrator action. Any change to network parameters should be audited.

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"

System Audit Logs Must Have Mode 0640 or Less Permissiverule

Change the mode of the audit log files with the following command:

$ sudo chmod 0640 audit_file

Rationale:

If users can write to audit logs, audit trails can be modified or destroyed.

identifiers:  CCE-27243-5, DISA FSO RHEL-06-000383

references:  AC-6, AU-1(b), AU-9, IR-5, 166, Test attestation on 20121024 by DS

Remediation script:
chmod -R 640 /var/log/audit/*
chmod 640 /etc/audit/audit.rules

System Audit Logs Must Be Owned By Rootrule

To properly set the owner of /var/log, run the command:

$ sudo chown root /var/log

Rationale:

Failure to give ownership of the audit log files to root allows the designated owner, and unauthorized users, potential access to sensitive information.

identifiers:  CCE-27244-3, DISA FSO RHEL-06-000384

references:  AC-6, AU-1(b), AU-9, IR-5, 166, Test attestation on 20121024 by DS

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

Rationale:

The system's mandatory access policy (SELinux) should not be arbitrarily changed by anything other than administrator action. All changes to MAC policy should be audited.

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

Rationale:

Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion.

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

Rationale:

Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise.

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

Rationale:

Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity.

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

Rationale:

The unauthorized exportation of data to external media could result in an information leak where classified information, Privacy Act information, and intellectual property could be lost. An audit trail should be created each time a filesystem is mounted to help identify and guard against information loss.

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

Rationale:

Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence.

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

Rationale:

The actions taken by system administrators should be audited to keep a record of what was executed on the system, as well as, for accountability purposes.

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

Rationale:

The addition/removal of kernel modules can be used to alter the behavior of the kernel and potentially introduce malicious code into kernel space. It is important to have an audit trail of modules that have been introduced into the kernel.

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.

Rationale:

Making the audit configuration immutable prevents accidental as well as malicious modification of the audit rules, although it may be problematic if legitimate changes are needed during system operation

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

Rationale:

Ensuring the auditd service is active ensures audit records generated by the kernel can be written to disk, or that appropriate actions will be taken if other obstacles exist.

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

Rationale:

Each process on the system carries an "auditable" flag which indicates whether its activities can be audited. Although auditd takes care of enabling this for all processes which launch after it does, adding the kernel argument ensures it is set for every process during boot.

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 RHEL 6 system and provides guidance about which ones can be safely disabled.

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

contains 4 rules

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

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

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

Rationale:

Causing idle users to be automatically logged out guards against compromises one system leading trivially to compromises on another.

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="15"
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

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

Rationale:

Enabling the ntpd service ensures that the ntpd service will be running and that the system will synchronize its time to any servers specified. This is important whether the system is configured to be a client (and synchronize only its own clock) or it is also acting as an NTP server to other systems. Synchronizing time is essential for authentication services such as Kerberos, but it is also important for maintaining accurate logs and auditing possible security breaches.

The NTP daemon offers all of the functionality of ntpdate, which is now deprecated. Additional information on this is available at http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate

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.

Rationale:

Synchronizing with an NTP server makes it possible to collate system logs from multiple sources or correlate computer events with real time events.

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

Rationale:

Specifying additional NTP servers increases the availability of accurate time data, in the event that one of the specified servers becomes unavailable. This is typical for a system acting as an NTP server for other systems.

identifiers:  CCE-26958-9

references:  AU-8(1)

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.