Guide to the Secure Configuration of CentOS Linux 7

with profile PCI-DSS v3 Control Baseline for CentOS Linux 7
This is a *draft* profile for PCI-DSS v3.

This guide presents a catalog of security-relevant configuration settings for CentOS Linux 7. 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 https://www.open-scap.org/security-policies/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 many operational scenarios. 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 CentOS Linux 7, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.

This benchmark is a direct port of a SCAP Security Guide benchmark developed for CentOS Linux. It has been modified through an automated process to remove specific dependencies on CentOS Linux and to function with CentOS. The result is a generally useful SCAP Security Guide benchmark with the following caveats:

  • CentOS is not an exact copy of CentOS Linux. There may be configuration differences that produce false positives and/or false negatives. If this occurs please file a bug report.
  • CentOS has its own build system, compiler options, patchsets, and is a community supported, non-commercial operating system. CentOS does not inherit certifications or evaluations from CentOS Linux. As such, some configuration rules (such as those requiring FIPS 140-2 encryption) will continue to fail on CentOS.

Members of the CentOS community are invited to participate in OpenSCAP and SCAP Security Guide development. Bug reports and patches can be sent to GitHub: https://github.com/OpenSCAP/scap-security-guide. The mailing list is at https://fedorahosted.org/mailman/listinfo/scap-security-guide.

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.

Evaluation Characteristics

Evaluation targetcentos75
Benchmark URL/usr/share/xml/scap/ssg/content/ssg-centos7-xccdf.xml
Profile IDpci-dss
Started at2018-05-19T02:15:46
Finished at2018-05-19T02:19:05
Performed byroot

CPE Platforms

  • cpe:/o:centos:centos:7
  • cpe:/o:redhat:enterprise_linux:7
  • cpe:/o:redhat:enterprise_linux:7::client
  • cpe:/o:redhat:enterprise_linux:7::computenode

Addresses

  • IPv4  127.0.0.1
  • IPv4  10.0.2.15
  • IPv4  192.168.56.201
  • IPv6  0:0:0:0:0:0:0:1
  • IPv6  fe80:0:0:0:3b94:7b6e:a492:d919
  • IPv6  fe80:0:0:0:3bd:2f76:4939:95d8
  • MAC  00:00:00:00:00:00
  • MAC  08:00:27:B4:E9:59
  • MAC  08:00:27:ED:98:8E

Compliance and Scoring

The target system did not satisfy the conditions of 12 rules! Please review rule results and consider applying remediation.

Rule results

23 passed
12 failed
1 other

Severity of failed rules

0 other
0 low
11 medium
1 high

Score

Scoring systemScoreMaximumPercent
urn:xccdf:scoring:default82.986115100.000000
82.99%

Rule Overview

Group rules by:
TitleSeverityResult
Guide to the Secure Configuration of CentOS Linux 7 12x fail 1x notchecked
System Settings 12x fail 1x notchecked
Installing and Maintaining Software 2x fail 1x notchecked
Updating Software 1x notchecked
Ensure Red Hat GPG Key Installedhigh
pass
Ensure gpgcheck Enabled In Main Yum Configurationhigh
pass
Ensure gpgcheck Enabled For All Yum Package Repositorieshigh
pass
Ensure Software Patches Installedhigh
notchecked
System and Software Integrity 2x fail
Software Integrity Checking 2x fail
Verify Integrity with AIDE 2x fail
Install AIDEmedium
fail
Build and Test AIDE Databasemedium
fail
Configure Periodic Execution of AIDEmedium
notapplicable
Verify Integrity with RPM
Verify and Correct File Permissions with RPMhigh
pass
Verify File Hashes with RPMhigh
pass
Endpoint Protection Software
Install Intrusion Detection Softwarehigh
notapplicable
GNOME Desktop Environment
Configure GNOME Screen Locking
Set GNOME3 Screensaver Inactivity Timeoutmedium
notapplicable
Enable GNOME3 Screensaver Idle Activationmedium
notapplicable
Enable GNOME3 Screensaver Lock After Idle Periodmedium
notapplicable
Implement Blank Screensaverlow
notapplicable
File Permissions and Masks
Verify Permissions on Important Files and Directories
Verify User Who Owns shadow Filemedium
pass
Verify Group Who Owns shadow Filemedium
pass
Verify Permissions on shadow Filemedium
pass
Verify User Who Owns group Filemedium
pass
Verify Group Who Owns group Filemedium
pass
Verify Permissions on group Filemedium
pass
Verify User Who Owns passwd Filemedium
pass
Verify Group Who Owns passwd Filemedium
pass
Verify Permissions on passwd Filemedium
pass
Account and Access Control 10x fail
Protect Accounts by Restricting Password-Based Login 3x fail
Verify Proper Storage and Existence of Password Hashes 1x fail
Prevent Log In to Accounts With Empty Passwordhigh
fail
Verify All Account Password Hashes are Shadowedmedium
pass
All GIDs referenced in /etc/passwd must be defined in /etc/grouplow
pass
Set Password Expiration Parameters 1x fail
Set Password Maximum Agemedium
fail
Set Account Expiration Following Inactivitymedium
fail
Protect Accounts by Configuring PAM 7x fail
Set Password Quality Requirements 4x fail
Set Password Quality Requirements with pam_pwquality 4x fail
Set Password Strength Minimum Digit Charactersmedium
fail
Set Password Minimum Lengthmedium
fail
Set Password Strength Minimum Uppercase Charactersmedium
fail
Set Password Strength Minimum Lowercase Charactersmedium
fail
Set Lockouts for Failed Password Attempts 3x fail
Set Deny For Failed Password Attemptsmedium
fail
Set Lockout Time For Failed Password Attemptsmedium
fail
Limit Password Reusemedium
fail
Set Password Hashing Algorithm
Set PAM's Password Hashing Algorithmmedium
pass
Set Password Hashing Algorithm in /etc/login.defsmedium
pass
Set Password Hashing Algorithm in /etc/libuser.confmedium
pass
Protect Physical Console Access
Set Boot Loader Password
Verify /boot/grub2/grub.cfg User Ownershipmedium
notapplicable
Verify /boot/grub2/grub.cfg Group Ownershipmedium
notapplicable
Configure Screen Locking
Enable Smart Card Loginmedium
notapplicable
Network Configuration and Firewalls
IPSec Support
Install libreswan Packagemedium
pass
Configure Syslog
Ensure Proper Configuration of Log Files
Ensure Log Files Are Owned By Appropriate Usermedium
notapplicable
Ensure Log Files Are Owned By Appropriate Groupmedium
notapplicable
Ensure System Log Files Have Correct Permissionsmedium
notapplicable
Ensure All Logs are Rotated by logrotate
Ensure Logrotate Runs Periodicallylow
notapplicable
System Accounting with auditd
Configure auditd Data Retention
Configure auditd Number of Logs Retainedmedium
notapplicable
Configure auditd Max Log File Sizemedium
notapplicable
Configure auditd max_log_file_action Upon Reaching Maximum Log Sizemedium
notapplicable
Configure auditd space_left Action on Low Disk Spacemedium
notapplicable
Configure auditd admin_space_left Action on Low Disk Spacemedium
notapplicable
Configure auditd mail_acct Action on Low Disk Spacemedium
notapplicable
Configure auditd to use audispd's syslog pluginmedium
notapplicable
Configure auditd Rules for Comprehensive Auditing
Records Events that Modify Date and Time Information
Record attempts to alter time through adjtimexlow
notapplicable
Record attempts to alter time through settimeofdaylow
notapplicable
Record Attempts to Alter Time Through stimelow
notapplicable
Record Attempts to Alter Time Through clock_settimelow
notapplicable
Record Attempts to Alter the localtime Filelow
notapplicable
Record Events that Modify the System's Discretionary Access Controls
Record Events that Modify the System's Discretionary Access Controls - chmodlow
notapplicable
Record Events that Modify the System's Discretionary Access Controls - chownlow
notapplicable
Record Events that Modify the System's Discretionary Access Controls - fchmodlow
notapplicable
Record Events that Modify the System's Discretionary Access Controls - fchmodatlow
notapplicable
Record Events that Modify the System's Discretionary Access Controls - fchownlow
notapplicable
Record Events that Modify the System's Discretionary Access Controls - fchownatlow
notapplicable
Record Events that Modify the System's Discretionary Access Controls - fremovexattrmedium
notapplicable
Record Events that Modify the System's Discretionary Access Controls - fsetxattrlow
notapplicable
Record Events that Modify the System's Discretionary Access Controls - lchownlow
notapplicable
Record Events that Modify the System's Discretionary Access Controls - lremovexattrmedium
notapplicable
Record Events that Modify the System's Discretionary Access Controls - lsetxattrlow
notapplicable
Record Events that Modify the System's Discretionary Access Controls - removexattrmedium
notapplicable
Record Events that Modify the System's Discretionary Access Controls - setxattrlow
notapplicable
Record Unauthorized Access Attempts Events to Files (unsuccessful)
Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful)medium
notapplicable
Record Information on the Use of Privileged Commands
Ensure auditd Collects Information on the Use of Privileged Commandsmedium
notapplicable
Record File Deletion Events by User
Ensure auditd Collects File Deletion Events by Usermedium
notapplicable
Record Information on Kernel Modules Loading and Unloading
Ensure auditd Collects Information on Kernel Module Loading and Unloadingmedium
notapplicable
Record Events that Modify User/Group Informationlow
notapplicable
Record Events that Modify the System's Network Environmentlow
notapplicable
System Audit Logs Must Have Mode 0640 or Less Permissivemedium
notapplicable
System Audit Logs Must Be Owned By Rootmedium
notapplicable
Record Events that Modify the System's Mandatory Access Controlslow
notapplicable
Record Attempts to Alter Process and Session Initiation Informationlow
notapplicable
Ensure auditd Collects Information on Exporting to Media (successful)medium
notapplicable
Ensure auditd Collects System Administrator Actionslow
notapplicable
Make the auditd Configuration Immutablemedium
notapplicable
Enable auditd Servicehigh
notapplicable
Enable Auditing for Processes Which Start Prior to the Audit Daemonmedium
notapplicable
Services
SSH Server
Configure OpenSSH Server if Necessary
Set SSH Idle Timeout Intervallow
notapplicable
Network Time Protocol
Enable the NTP Daemonmedium
notapplicable
Specify a Remote NTP Servermedium
notapplicable
Specify Additional Remote NTP Serverslow
notapplicable

Result Details

Ensure Red Hat GPG Key Installedensure_redhat_gpgkey_installed high

Ensure Red Hat GPG Key Installed

Rule IDensure_redhat_gpgkey_installed
Result
pass
Time2018-05-19T02:15:48
Severityhigh
Identifiers and References

References:  CM-5(3), SI-7, MA-1(b), CCI-001749, 366, Req-6.2, 1.2.3, 5.10.4.1, 3.4.8

Description

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

Changes to software components can have significant effects on the overall security of the operating system. This requirement ensures the software has not been tampered with and that it has been provided by a trusted vendor. The Red Hat GPG key is necessary to cryptographically verify packages are from Red Hat.

Ensure gpgcheck Enabled In Main Yum Configurationensure_gpgcheck_globally_activated high

Ensure gpgcheck Enabled In Main Yum Configuration

Rule IDensure_gpgcheck_globally_activated
Result
pass
Time2018-05-19T02:15:48
Severityhigh
Identifiers and References

References:  SV-86601r1_rule, CM-5(3), SI-7, MA-1(b), CCI-001749, SRG-OS-000366-GPOS-00153, Req-6.2, 1.2.2, 5.10.4.1, 3.4.8

Description

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

Changes to any software components can have significant effects on the overall security of the operating system. This requirement ensures the software has not been tampered with and that it has been provided by a trusted vendor.
Accordingly, patches, service packs, device drivers, or operating system components must be signed with a certificate recognized and approved by the organization.
Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. Certificates used to verify the software must be from an approved Certificate Authority (CA).

Ensure gpgcheck Enabled For All Yum Package Repositoriesensure_gpgcheck_never_disabled high

Ensure gpgcheck Enabled For All Yum Package Repositories

Rule IDensure_gpgcheck_never_disabled
Result
pass
Time2018-05-19T02:15:48
Severityhigh
Identifiers and References

References:  CM-5(3), SI-7, MA-1(b), CCI-001749, 366, Req-6.2, 5.10.4.1, 3.4.8

Description

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

Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. Certificates used to verify the software must be from an approved Certificate Authority (CA).

Ensure Software Patches Installedsecurity_patches_up_to_date high

Ensure Software Patches Installed

Rule IDsecurity_patches_up_to_date
Result
notchecked
Time2018-05-19T02:15:48
Severityhigh
Identifiers and References

References:  SV-86623r3_rule, SI-2, SI-2(c), MA-1(b), CCI-000366, Req-6.2, 1.8, SRG-OS-000480-GPOS-00227, 5.10.4.1

Description

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.

NOTE: U.S. Defense systems are required to be patched within 30 days or sooner as local policy dictates.

Rationale

Installing software updates is a fundamental mitigation against the exploitation of publicly-known vulnerabilities. If the most recent security patches and updates are not installed, unauthorized users may take advantage of weaknesses in the unpatched software. The lack of prompt attention to patching could result in a system compromise.

Evaluation messages
info 
None of the check-content-ref elements was resolvable.
Install AIDEpackage_aide_installed medium

Install AIDE

Rule IDpackage_aide_installed
Result
fail
Time2018-05-19T02:15:48
Severitymedium
Identifiers and References

References:  CM-3(d), CM-3(e), CM-6(d), CM-6(3), SC-28, SI-7, Req-11.5, 1.3.1, 5.10.1.3

Description

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.

Remediation Shell script:   (show)

Complexity:low
Disruption:low
Strategy:enable
# Function to install or uninstall packages on RHEL and Fedora systems.
#
# Example Call(s):
#
#     package_command install aide
#     package_command remove telnet-server
#
function package_command {

# Load function arguments into local variables
local package_operation=$1
local package=$2

# Check sanity of the input
if [ $# -ne "2" ]
then
  echo "Usage: package_command 'install/uninstall' 'rpm_package_name"
  echo "Aborting."
  exit 1
fi

# If dnf is installed, use dnf; otherwise, use yum
if [ -f "/usr/bin/dnf" ] ; then
  install_util="/usr/bin/dnf"
else
  install_util="/usr/bin/yum"
fi

if [ "$package_operation" != 'remove' ] ; then
  # If the rpm is not installed, install the rpm
  if ! /bin/rpm -q --quiet $package; then
    $install_util -y $package_operation $package
  fi
else
  # If the rpm is installed, uninstall the rpm
  if /bin/rpm -q --quiet $package; then
    $install_util -y $package_operation $package
  fi
fi

}

package_command install aide
Remediation Ansible snippet:   (show)

Complexity:low
Disruption:low
Strategy:enable
- name: Ensure aide is installed
  package:
    name="{{item}}"
    state=present
  with_items:
    - aide
  tags:
    - package_aide_installed
    - medium_severity
    - enable_strategy
    - low_complexity
    - low_disruption
    - CCE-27096-7
    - NIST-800-53-CM-3(d)
    - NIST-800-53-CM-3(e)
    - NIST-800-53-CM-6(d)
    - NIST-800-53-CM-6(3)
    - NIST-800-53-SC-28
    - NIST-800-53-SI-7
    - PCI-DSS-Req-11.5
    - CJIS-5.10.1.3

Remediation Puppet snippet:   (show)

Complexity:low
Disruption:low
Strategy:enable
include install_aide

class install_aide {
  package { 'aide':
    ensure => 'installed',
  }
}
Remediation Anaconda snippet:   (show)

Complexity:low
Disruption:low
Strategy:enable

package --add=aide
Build and Test AIDE Databaseaide_build_database medium

Build and Test AIDE Database

Rule IDaide_build_database
Result
fail
Time2018-05-19T02:15:48
Severitymedium
Identifiers and References

References:  CM-3(d), CM-3(e), CM-6(d), CM-6(3), SC-28, SI-7, Req-11.5, 5.10.1.3

Description

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.

Remediation Shell script:   (show)

# Function to install or uninstall packages on RHEL and Fedora systems.
#
# Example Call(s):
#
#     package_command install aide
#     package_command remove telnet-server
#
function package_command {

# Load function arguments into local variables
local package_operation=$1
local package=$2

# Check sanity of the input
if [ $# -ne "2" ]
then
  echo "Usage: package_command 'install/uninstall' 'rpm_package_name"
  echo "Aborting."
  exit 1
fi

# If dnf is installed, use dnf; otherwise, use yum
if [ -f "/usr/bin/dnf" ] ; then
  install_util="/usr/bin/dnf"
else
  install_util="/usr/bin/yum"
fi

if [ "$package_operation" != 'remove' ] ; then
  # If the rpm is not installed, install the rpm
  if ! /bin/rpm -q --quiet $package; then
    $install_util -y $package_operation $package
  fi
else
  # If the rpm is installed, uninstall the rpm
  if /bin/rpm -q --quiet $package; then
    $install_util -y $package_operation $package
  fi
fi

}

package_command install aide

/usr/sbin/aide --init
/bin/cp -p /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
Remediation Ansible snippet:   (show)

Complexity:low
Disruption:low
Strategy:restrict
- name: "Ensure AIDE is installed"
  package:
    name="{{item}}"
    state=present
  with_items:
    - aide
  tags:
    - aide_build_database
    - medium_severity
    - restrict_strategy
    - low_complexity
    - low_disruption
    - CCE-27220-3
    - NIST-800-53-CM-3(d)
    - NIST-800-53-CM-3(e)
    - NIST-800-53-CM-6(d)
    - NIST-800-53-CM-6(3)
    - NIST-800-53-SC-28
    - NIST-800-53-SI-7
    - PCI-DSS-Req-11.5
    - CJIS-5.10.1.3

- name: "Build and Test AIDE Database"
  shell: /usr/sbin/aide --init
  tags:
    - aide_build_database
    - medium_severity
    - restrict_strategy
    - low_complexity
    - low_disruption
    - CCE-27220-3
    - NIST-800-53-CM-3(d)
    - NIST-800-53-CM-3(e)
    - NIST-800-53-CM-6(d)
    - NIST-800-53-CM-6(3)
    - NIST-800-53-SC-28
    - NIST-800-53-SI-7
    - PCI-DSS-Req-11.5
    - CJIS-5.10.1.3

- name: Stage AIDE Database"
  copy:
    src: /var/lib/aide/aide.db.new.gz
    dest: /var/lib/aide/aide.db.gz
    backup: yes
    remote_src: yes
  tags:
    - aide_build_database
    - medium_severity
    - restrict_strategy
    - low_complexity
    - low_disruption
    - CCE-27220-3
    - NIST-800-53-CM-3(d)
    - NIST-800-53-CM-3(e)
    - NIST-800-53-CM-6(d)
    - NIST-800-53-CM-6(3)
    - NIST-800-53-SC-28
    - NIST-800-53-SI-7
    - PCI-DSS-Req-11.5
    - CJIS-5.10.1.3
Configure Periodic Execution of AIDEaide_periodic_cron_checking medium

Configure Periodic Execution of AIDE

Rule IDaide_periodic_cron_checking
Result
notapplicable
Time2018-05-19T02:15:48
Severitymedium
Identifiers and References

References:  SV-86597r1_rule, CM-3(d), CM-3(e), CM-3(5), CM-6(d), CM-6(3), SC-28, SI-7, CCI-001744, Req-11.5, 1.3.2, SRG-OS-000363-GPOS-00150, 5.10.1.3

Description

At a minimum, AIDE should be configured to run a weekly scan. At most, AIDE should be run daily. 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
To implement a weekly execution of AIDE at 4:05am using cron, add the following line to /etc/crontab:
05 4 * * 0 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.

Unauthorized changes to the baseline configuration could make the system vulnerable to various attacks or allow unauthorized access to the operating system. Changes to operating system configurations can have unintended side effects, some of which may be relevant to security.

Detecting such changes and providing an automated response can help avoid unintended, negative consequences that could ultimately affect the security state of the operating system. The operating system's Information Management Officer (IMO)/Information System Security Officer (ISSO) and System Administrators (SAs) must be notified via email and/or monitoring system trap when there is an unauthorized modification of a configuration item.

Verify and Correct File Permissions with RPMrpm_verify_permissions high

Verify and Correct File Permissions with RPM

Rule IDrpm_verify_permissions
Result
pass
Time2018-05-19T02:16:06
Severityhigh
Identifiers and References

References:  SV-86473r2_rule, AC-6, AU-9(1), AU-9(3), CM-6(d), CM-6(3), CCI-001494, CCI-001496, Req-11.5, 1.2.6, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, 6.2.3, SRG-OS-000257-GPOS-00098, SRG-OS-000278-GPOS-00108, 5.10.4.1, 3.3.8, 3.4.1

Description

The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. Verify that the file permissions of system files and commands match vendor values. Check the file permissions with the following command:

$ sudo rpm -Va | grep '^.M'
Output indicates files that do not match vendor defaults. 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.

Warnings
warning  Note: Due to a bug in the gdm package, the RPM verify command may continue to fail even after file permissions have been correctly set on /var/log/gdm. This is being tracked in Red Hat Bugzilla #1275532.
Verify File Hashes with RPMrpm_verify_hashes high

Verify File Hashes with RPM

Rule IDrpm_verify_hashes
Result
pass
Time2018-05-19T02:19:04
Severityhigh
Identifiers and References

References:  SV-86479r2_rule, CM-6(d), CM-6(3), SI-7(1), CCI-000663, Req-11.5, 1.2.6, SRG-OS-000480-GPOS-00227, 5.10.4.1, 3.3.8, 3.4.1

Description

Without cryptographic integrity protections, system executables and files can be altered by unauthorized users without detection. The RPM package management system can check the hashes of installed software packages, including many that are important to system security. To verify that the cryptographic hash of system files and commands match vendor values, 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.

Install Intrusion Detection Softwareinstall_hids high

Install Intrusion Detection Software

Rule IDinstall_hids
Result
notapplicable
Time2018-05-19T02:19:04
Severityhigh
Identifiers and References

References:  SC-7, CCI-001263, Req-11.4

Description

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.

Rationale

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

Warnings
warning  Note 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 proper functioning of SELinux, SELinux takes precedence.
Set GNOME3 Screensaver Inactivity Timeoutdconf_gnome_screensaver_idle_delay medium

Set GNOME3 Screensaver Inactivity Timeout

Rule IDdconf_gnome_screensaver_idle_delay
Result
notapplicable
Time2018-05-19T02:19:04
Severitymedium
Identifiers and References

References:  SV-86517r2_rule, AC-11(a), CCI-000057, Req-8.1.8, SRG-OS-000029-GPOS-00010, 5.5.5, 3.1.10

Description

The idle time-out value for inactivity in the GNOME3 desktop is configured via the idle-delay setting must be set under an appropriate configuration file(s) in the /etc/dconf/db/local.d directory and locked in /etc/dconf/db/local.d/locks directory to prevent user modification.

For example, to configure the system for a 15 minute delay, add the following to /etc/dconf/db/local.d/00-security-settings:

[org/gnome/desktop/session]
idle-delay='uint32 900'
Once the setting has been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example:
/org/gnome/desktop/session/idle-delay
After the settings have been set, run dconf update.

Rationale

A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, GNOME3 can be configured to identify when a user's session has idled and take action to initiate a session lock.

Enable GNOME3 Screensaver Idle Activationdconf_gnome_screensaver_idle_activation_enabled medium

Enable GNOME3 Screensaver Idle Activation

Rule IDdconf_gnome_screensaver_idle_activation_enabled
Result
notapplicable
Time2018-05-19T02:19:04
Severitymedium
Identifiers and References

References:  SV-86523r1_rule, AC-11(a), CCI-000057, SRG-OS-000029-GPOS-00010, Req-8.1.8, 5.5.5, 3.1.10

Description

To activate the screensaver in the GNOME3 desktop after a period of inactivity, add or set idle-activation-enabled to true in /etc/dconf/db/local.d/00-security-settings. For example:

[org/gnome/desktop/screensaver]
idle_activation_enabled=true
Once the setting has been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example:
/org/gnome/desktop/screensaver/idle-activation-enabled
After the settings have been set, run dconf update.

Rationale

A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, GNOME desktops can be configured to identify when a user's session has idled and take action to initiate the session lock.

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.

Enable GNOME3 Screensaver Lock After Idle Perioddconf_gnome_screensaver_lock_enabled medium

Enable GNOME3 Screensaver Lock After Idle Period

Rule IDdconf_gnome_screensaver_lock_enabled
Result
notapplicable
Time2018-05-19T02:19:04
Severitymedium
Identifiers and References

References:  SV-86515r2_rule, AC-11(b), CCI-000056, Req-8.1.8, SRG-OS-000028-GPOS-00009, OS-SRG-000030-GPOS-00011, 5.5.5, 3.1.10

Description

To activate locking of the screensaver in the GNOME3 desktop when it is activated, add or set lock-enabled to true in /etc/dconf/db/local.d/00-security-settings. For example:

[org/gnome/desktop/screensaver]
lock-enabled=true
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example:
/org/gnome/desktop/screensaver/lock-enabled
After the settings have been set, run dconf update.

Rationale

A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to logout because of the temporary nature of the absense.

Implement Blank Screensaverdconf_gnome_screensaver_mode_blank low

Implement Blank Screensaver

Rule IDdconf_gnome_screensaver_mode_blank
Result
notapplicable
Time2018-05-19T02:19:04
Severitylow
Identifiers and References

References:  AC-11(b), CCI-000060, Req-8.1.8, 5.5.5, 3.1.10

Description

To set the screensaver mode in the GNOME3 desktop to a blank screen, add or set picture-uri to string '' in /etc/dconf/db/local.d/00-security-settings. For example:

[org/gnome/desktop/screensaver]
picture-uri=string ''
Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example:
/org/gnome/desktop/screensaver/picture-uri
After the settings have been set, run dconf update.

Rationale

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

Verify User Who Owns shadow Fileuserowner_shadow_file medium

Verify User Who Owns shadow File

Rule IDuserowner_shadow_file
Result
pass
Time2018-05-19T02:19:04
Severitymedium
Identifiers and References

References:  AC-6, Req-8.7.c, 5.5.2.2, 6.1.3

Description

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.

Verify Group Who Owns shadow Filegroupowner_shadow_file medium

Verify Group Who Owns shadow File

Rule IDgroupowner_shadow_file
Result
pass
Time2018-05-19T02:19:04
Severitymedium
Identifiers and References

References:  AC-6, Req-8.7.c, 5.5.2.2, 6.1.3

Description

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.

Verify Permissions on shadow Filefile_permissions_etc_shadow medium

Verify Permissions on shadow File

Rule IDfile_permissions_etc_shadow
Result
pass
Time2018-05-19T02:19:04
Severitymedium
Identifiers and References

References:  AC-6, Req-8.7.c, 5.5.2.2, 6.1.3

Description

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.

Verify User Who Owns group Filefile_owner_etc_group medium

Verify User Who Owns group File

Rule IDfile_owner_etc_group
Result
pass
Time2018-05-19T02:19:04
Severitymedium
Identifiers and References

References:  AC-6, Req-8.7.c, 5.5.2.2, 6.1.4

Description

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.

Verify Group Who Owns group Filefile_groupowner_etc_group medium

Verify Group Who Owns group File

Rule IDfile_groupowner_etc_group
Result
pass
Time2018-05-19T02:19:04
Severitymedium
Identifiers and References

References:  AC-6, Req-8.7.c, 5.5.2.2, 6.1.4

Description

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.

Verify Permissions on group Filefile_permissions_etc_group medium

Verify Permissions on group File

Rule IDfile_permissions_etc_group
Result
pass
Time2018-05-19T02:19:04
Severitymedium
Identifiers and References

References:  AC-6, Req-8.7.c, 5.5.2.2, 6.1.4

Description

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.

Verify User Who Owns passwd Filefile_owner_etc_passwd medium

Verify User Who Owns passwd File

Rule IDfile_owner_etc_passwd
Result
pass
Time2018-05-19T02:19:04
Severitymedium
Identifiers and References

References:  AC-6, Req-8.7.c, 5.5.2.2, 6.1.2

Description

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.

Verify Group Who Owns passwd Filefile_groupowner_etc_passwd medium

Verify Group Who Owns passwd File

Rule IDfile_groupowner_etc_passwd
Result
pass
Time2018-05-19T02:19:04
Severitymedium
Identifiers and References

References:  AC-6, Req-8.7.c, 5.5.2.2, 6.1.2

Description

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.

Verify Permissions on passwd Filefile_permissions_etc_passwd medium

Verify Permissions on passwd File

Rule IDfile_permissions_etc_passwd
Result
pass
Time2018-05-19T02:19:04
Severitymedium
Identifiers and References

References:  AC-6, Req-8.7.c, 5.5.2.2, 6.1.2

Description

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.

Prevent Log In to Accounts With Empty Passwordno_empty_passwords high

Prevent Log In to Accounts With Empty Password

Rule IDno_empty_passwords
Result
fail
Time2018-05-19T02:19:04
Severityhigh
Identifiers and References

References:  SV-86561r1_rule, AC-6, IA-5(b), IA-5(c), IA-5(1)(a), CCI-000366, SRG-OS-000480-GPOS-00227, Req-8.2.3, 5.5.2, 3.1.1, 3.1.5

Description

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

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.

Remediation Shell script:   (show)

sed --follow-symlinks -i 's/\<nullok\>//g' /etc/pam.d/system-auth
sed --follow-symlinks -i 's/\<nullok\>//g' /etc/pam.d/password-auth
Remediation Ansible snippet:   (show)

Complexity:low
Disruption:medium
Strategy:configure
- name: "Prevent Log In to Accounts With Empty Password - system-auth"
  replace:
    dest: /etc/pam.d/system-auth
    follow: yes
    regexp: 'nullok'
  tags:
    - no_empty_passwords
    - high_severity
    - configure_strategy
    - low_complexity
    - medium_disruption
    - CCE-27286-4
    - NIST-800-53-AC-6
    - NIST-800-53-IA-5(b)
    - NIST-800-53-IA-5(c)
    - NIST-800-53-IA-5(1)(a)
    - NIST-800-171-3.1.1
    - NIST-800-171-3.1.5
    - PCI-DSS-Req-8.2.3
    - CJIS-5.5.2
    - DISA-STIG-RHEL-07-010290

- name: "Prevent Log In to Accounts With Empty Password - password-auth"
  replace:
    dest: /etc/pam.d/password-auth
    follow: yes
    regexp: 'nullok'
  tags:
    - no_empty_passwords
    - high_severity
    - configure_strategy
    - low_complexity
    - medium_disruption
    - CCE-27286-4
    - NIST-800-53-AC-6
    - NIST-800-53-IA-5(b)
    - NIST-800-53-IA-5(c)
    - NIST-800-53-IA-5(1)(a)
    - NIST-800-171-3.1.1
    - NIST-800-171-3.1.5
    - PCI-DSS-Req-8.2.3
    - CJIS-5.5.2
    - DISA-STIG-RHEL-07-010290

Verify All Account Password Hashes are Shadowedaccounts_password_all_shadowed medium

Verify All Account Password Hashes are Shadowed

Rule IDaccounts_password_all_shadowed
Result
pass
Time2018-05-19T02:19:04
Severitymedium
Identifiers and References

References:  IA-5(h), Req-8.2.1, 5.5.2, 3.5.10

Description

If any password hashes are stored in /etc/passwd (in the second field, instead of an x or *), 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.

All GIDs referenced in /etc/passwd must be defined in /etc/groupgid_passwd_group_same low

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

Rule IDgid_passwd_group_same
Result
pass
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  SV-86627r1_rule, IA-2, CCI-000764, SRG-OS-000104-GPOS-00051, Req-8.5.a, 5.5.2

Description

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

Rationale

If a user is assigned the Group Identifier (GID) of a group not existing on the system, and a group with the Gruop Identifier (GID) is subsequently created, the user may have unintended rights to any files associated with the group.

Set Password Strength Minimum Digit Charactersaccounts_password_pam_dcredit medium

Set Password Strength Minimum Digit Characters

Rule IDaccounts_password_pam_dcredit
Result
fail
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86531r2_rule, IA-5(1)(a), IA-5(b), IA-5(c), 194, CCI-000194, SRG-OS-000071-GPOS-00039, Req-8.2.3, 6.3.2

Description

The pam_pwquality 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_pwquality will grant +1 additional length credit for each digit. Modify the dcredit setting in /etc/security/pwquality.conf to require the use of a digit in passwords.

Rationale

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possble combinations that need to be tested before the password is compromised. Requiring digits makes password guessing attacks more difficult by ensuring a larger search space.

Remediation Shell script:   (show)


var_password_pam_dcredit="-1"
# Function to replace configuration setting in config file or add the configuration setting if
# it does not exist.
#
# Expects four arguments:
#
# config_file:		Configuration file that will be modified
# key:			Configuration option to change
# value:		Value of the configuration option to change
# cce:			The CCE identifier or '@CCENUM@' if no CCE identifier exists
#
# Optional arugments:
#
# format:		Optional argument to specify the format of how key/value should be
# 			modified/appended in the configuration file. The default is key = value.
#
# Example Call(s):
#
#     With default format of 'key = value':
#     replace_or_append '/etc/sysctl.conf' '^kernel.randomize_va_space' '2' '@CCENUM@'
#
#     With custom key/value format:
#     replace_or_append '/etc/sysconfig/selinux' '^SELINUX=' 'disabled' '@CCENUM@' '%s=%s'
#
#     With a variable:
#     replace_or_append '/etc/sysconfig/selinux' '^SELINUX=' $var_selinux_state '@CCENUM@' '%s=%s'
#
function replace_or_append {
  local config_file=$1
  local key=$2
  local value=$3
  local cce=$4
  local format=$5

  # Check sanity of the input
  if [ $# -lt "3" ]
  then
        echo "Usage: replace_or_append 'config_file_location' 'key_to_search' 'new_value'"
        echo
        echo "If symlinks need to be taken into account, add yes/no to the last argument"
        echo "to allow to 'follow_symlinks'."
        echo "Aborting."
        exit 1
  fi

  # Test if the config_file is a symbolic link. If so, use --follow-symlinks with sed.
  # Otherwise, regular sed command will do.
  if test -L $config_file; then
    sed_command="sed -i --follow-symlinks"
  else
    sed_command="sed -i"
  fi

  # Test that the cce arg is not empty or does not equal @CCENUM@.
  # If @CCENUM@ exists, it means that there is no CCE assigned.
  if ! [ "x$cce" = x ] && [ "$cce" != '@CCENUM@' ]; then
    cce="CCE-${cce}"
  else
    cce="CCE"
  fi

  # Strip any search characters in the key arg so that the key can be replaced without
  # adding any search characters to the config file.
  stripped_key=$(sed "s/[\^=\$,;+]*//g" <<< $key)

  # If there is no print format specified in the last arg, use the default format.
  if ! [ "x$format" = x ] ; then
    printf -v formatted_output "$format" "$stripped_key" "$value"
  else
    formatted_output="$stripped_key = $value"
  fi

  # If the key exists, change it. Otherwise, add it to the config_file.
  if `grep -qi "$key" $config_file` ; then
    eval '$sed_command "s/$key.*/$formatted_output/g" $config_file'
  else
    # \n is precaution for case where file ends without trailing newline
    echo -e "\n# Per $cce: Set $formatted_output in $config_file" >> $config_file
    echo -e "$formatted_output" >> $config_file
  fi

}

replace_or_append '/etc/security/pwquality.conf' '^dcredit' $var_password_pam_dcredit 'CCE-27214-6' '%s = %s'
Remediation Ansible snippet:   (show)

- name: XCCDF Value var_password_pam_dcredit # promote to variable
  set_fact:
    var_password_pam_dcredit: -1
  tags:
    - always

- name: Ensure PAM variable dcredit is set accordingly
  lineinfile:
    create=yes
    dest="/etc/security/pwquality.conf"
    regexp="^dcredit"
    line="dcredit = {{ var_password_pam_dcredit }}"
  tags:
    - accounts_password_pam_dcredit
    - medium_severity
    - CCE-27214-6
    - NIST-800-53-IA-5(1)(a)
    - NIST-800-53-IA-5(b)
    - NIST-800-53-IA-5(c)
    - NIST-800-53-194
    - PCI-DSS-Req-8.2.3
    - DISA-STIG-RHEL-07-010140

Set Password Minimum Lengthaccounts_password_pam_minlen medium

Set Password Minimum Length

Rule IDaccounts_password_pam_minlen
Result
fail
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86559r1_rule, IA-5(1)(a), CCI-000205, SRG-OS-000078-GPOS-00046, Req-8.2.3, 6.3.2, 5.6.2.1.1

Description

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

The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. 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 compromose the password.

Remediation Shell script:   (show)


var_password_pam_minlen="7"
# Function to replace configuration setting in config file or add the configuration setting if
# it does not exist.
#
# Expects four arguments:
#
# config_file:		Configuration file that will be modified
# key:			Configuration option to change
# value:		Value of the configuration option to change
# cce:			The CCE identifier or '@CCENUM@' if no CCE identifier exists
#
# Optional arugments:
#
# format:		Optional argument to specify the format of how key/value should be
# 			modified/appended in the configuration file. The default is key = value.
#
# Example Call(s):
#
#     With default format of 'key = value':
#     replace_or_append '/etc/sysctl.conf' '^kernel.randomize_va_space' '2' '@CCENUM@'
#
#     With custom key/value format:
#     replace_or_append '/etc/sysconfig/selinux' '^SELINUX=' 'disabled' '@CCENUM@' '%s=%s'
#
#     With a variable:
#     replace_or_append '/etc/sysconfig/selinux' '^SELINUX=' $var_selinux_state '@CCENUM@' '%s=%s'
#
function replace_or_append {
  local config_file=$1
  local key=$2
  local value=$3
  local cce=$4
  local format=$5

  # Check sanity of the input
  if [ $# -lt "3" ]
  then
        echo "Usage: replace_or_append 'config_file_location' 'key_to_search' 'new_value'"
        echo
        echo "If symlinks need to be taken into account, add yes/no to the last argument"
        echo "to allow to 'follow_symlinks'."
        echo "Aborting."
        exit 1
  fi

  # Test if the config_file is a symbolic link. If so, use --follow-symlinks with sed.
  # Otherwise, regular sed command will do.
  if test -L $config_file; then
    sed_command="sed -i --follow-symlinks"
  else
    sed_command="sed -i"
  fi

  # Test that the cce arg is not empty or does not equal @CCENUM@.
  # If @CCENUM@ exists, it means that there is no CCE assigned.
  if ! [ "x$cce" = x ] && [ "$cce" != '@CCENUM@' ]; then
    cce="CCE-${cce}"
  else
    cce="CCE"
  fi

  # Strip any search characters in the key arg so that the key can be replaced without
  # adding any search characters to the config file.
  stripped_key=$(sed "s/[\^=\$,;+]*//g" <<< $key)

  # If there is no print format specified in the last arg, use the default format.
  if ! [ "x$format" = x ] ; then
    printf -v formatted_output "$format" "$stripped_key" "$value"
  else
    formatted_output="$stripped_key = $value"
  fi

  # If the key exists, change it. Otherwise, add it to the config_file.
  if `grep -qi "$key" $config_file` ; then
    eval '$sed_command "s/$key.*/$formatted_output/g" $config_file'
  else
    # \n is precaution for case where file ends without trailing newline
    echo -e "\n# Per $cce: Set $formatted_output in $config_file" >> $config_file
    echo -e "$formatted_output" >> $config_file
  fi

}

replace_or_append '/etc/security/pwquality.conf' '^minlen' $var_password_pam_minlen 'CCE-27293-0' '%s = %s'
Remediation Ansible snippet:   (show)

Complexity:low
Disruption:low
Strategy:restrict
- name: XCCDF Value var_password_pam_minlen # promote to variable
  set_fact:
    var_password_pam_minlen: 7
  tags:
    - always

- name: Ensure PAM variable minlen is set accordingly
  lineinfile:
    create=yes
    dest="/etc/security/pwquality.conf"
    regexp="^minlen"
    line="minlen = {{ var_password_pam_minlen }}"
  tags:
    - accounts_password_pam_minlen
    - medium_severity
    - restrict_strategy
    - low_complexity
    - low_disruption
    - CCE-27293-0
    - NIST-800-53-IA-5(1)(a)
    - PCI-DSS-Req-8.2.3
    - CJIS-5.6.2.1.1
    - DISA-STIG-RHEL-07-010280

Set Password Strength Minimum Uppercase Charactersaccounts_password_pam_ucredit medium

Set Password Strength Minimum Uppercase Characters

Rule IDaccounts_password_pam_ucredit
Result
fail
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86527r2_rule, IA-5(b), IA-5(c), IA-5(1)(a), CCI-000192, SRG-OS-000069-GPOS-00037, Req-8.2.3, 6.3.2

Description

The pam_pwquality 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_pwquality will grant +1 additional length credit for each uppercase character. Modify the ucredit setting in /etc/security/pwquality.conf to require the use of an uppercase character in passwords.

Rationale

Use of a complex password helps to increase the time and resources reuiqred to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Remediation Shell script:   (show)


var_password_pam_ucredit="-1"
# Function to replace configuration setting in config file or add the configuration setting if
# it does not exist.
#
# Expects four arguments:
#
# config_file:		Configuration file that will be modified
# key:			Configuration option to change
# value:		Value of the configuration option to change
# cce:			The CCE identifier or '@CCENUM@' if no CCE identifier exists
#
# Optional arugments:
#
# format:		Optional argument to specify the format of how key/value should be
# 			modified/appended in the configuration file. The default is key = value.
#
# Example Call(s):
#
#     With default format of 'key = value':
#     replace_or_append '/etc/sysctl.conf' '^kernel.randomize_va_space' '2' '@CCENUM@'
#
#     With custom key/value format:
#     replace_or_append '/etc/sysconfig/selinux' '^SELINUX=' 'disabled' '@CCENUM@' '%s=%s'
#
#     With a variable:
#     replace_or_append '/etc/sysconfig/selinux' '^SELINUX=' $var_selinux_state '@CCENUM@' '%s=%s'
#
function replace_or_append {
  local config_file=$1
  local key=$2
  local value=$3
  local cce=$4
  local format=$5

  # Check sanity of the input
  if [ $# -lt "3" ]
  then
        echo "Usage: replace_or_append 'config_file_location' 'key_to_search' 'new_value'"
        echo
        echo "If symlinks need to be taken into account, add yes/no to the last argument"
        echo "to allow to 'follow_symlinks'."
        echo "Aborting."
        exit 1
  fi

  # Test if the config_file is a symbolic link. If so, use --follow-symlinks with sed.
  # Otherwise, regular sed command will do.
  if test -L $config_file; then
    sed_command="sed -i --follow-symlinks"
  else
    sed_command="sed -i"
  fi

  # Test that the cce arg is not empty or does not equal @CCENUM@.
  # If @CCENUM@ exists, it means that there is no CCE assigned.
  if ! [ "x$cce" = x ] && [ "$cce" != '@CCENUM@' ]; then
    cce="CCE-${cce}"
  else
    cce="CCE"
  fi

  # Strip any search characters in the key arg so that the key can be replaced without
  # adding any search characters to the config file.
  stripped_key=$(sed "s/[\^=\$,;+]*//g" <<< $key)

  # If there is no print format specified in the last arg, use the default format.
  if ! [ "x$format" = x ] ; then
    printf -v formatted_output "$format" "$stripped_key" "$value"
  else
    formatted_output="$stripped_key = $value"
  fi

  # If the key exists, change it. Otherwise, add it to the config_file.
  if `grep -qi "$key" $config_file` ; then
    eval '$sed_command "s/$key.*/$formatted_output/g" $config_file'
  else
    # \n is precaution for case where file ends without trailing newline
    echo -e "\n# Per $cce: Set $formatted_output in $config_file" >> $config_file
    echo -e "$formatted_output" >> $config_file
  fi

}

replace_or_append '/etc/security/pwquality.conf' '^ucredit' $var_password_pam_ucredit 'CCE-27200-5' '%s = %s'
Remediation Ansible snippet:   (show)

- name: XCCDF Value var_password_pam_ucredit # promote to variable
  set_fact:
    var_password_pam_ucredit: -1
  tags:
    - always

- name: Ensure PAM variable ucredit is set accordingly
  lineinfile:
    create=yes
    dest="/etc/security/pwquality.conf"
    regexp="^ucredit"
    line="ucredit = {{ var_password_pam_ucredit }}"
  tags:
    - accounts_password_pam_ucredit
    - medium_severity
    - CCE-27200-5
    - NIST-800-53-IA-5(b)
    - NIST-800-53-IA-5(c)
    - NIST-800-53-IA-5(1)(a)
    - PCI-DSS-Req-8.2.3
    - DISA-STIG-RHEL-07-010120

Set Password Strength Minimum Lowercase Charactersaccounts_password_pam_lcredit medium

Set Password Strength Minimum Lowercase Characters

Rule IDaccounts_password_pam_lcredit
Result
fail
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86529r2_rule, IA-5(b), IA-5(c), IA-5(1)(a), CCI-000193, SRG-OS-000070-GPOS-00038, Req-8.2.3

Description

The pam_pwquality 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_pwquality will grant +1 additional length credit for each lowercase character. Modify the lcredit setting in /etc/security/pwquality.conf to require the use of a lowercase character in passwords.

Rationale

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possble combinations that need to be tested before the password is compromised. Requiring a minimum number of lowercase characters makes password guessing attacks more difficult by ensuring a larger search space.

Remediation Shell script:   (show)


var_password_pam_lcredit="-1"
# Function to replace configuration setting in config file or add the configuration setting if
# it does not exist.
#
# Expects four arguments:
#
# config_file:		Configuration file that will be modified
# key:			Configuration option to change
# value:		Value of the configuration option to change
# cce:			The CCE identifier or '@CCENUM@' if no CCE identifier exists
#
# Optional arugments:
#
# format:		Optional argument to specify the format of how key/value should be
# 			modified/appended in the configuration file. The default is key = value.
#
# Example Call(s):
#
#     With default format of 'key = value':
#     replace_or_append '/etc/sysctl.conf' '^kernel.randomize_va_space' '2' '@CCENUM@'
#
#     With custom key/value format:
#     replace_or_append '/etc/sysconfig/selinux' '^SELINUX=' 'disabled' '@CCENUM@' '%s=%s'
#
#     With a variable:
#     replace_or_append '/etc/sysconfig/selinux' '^SELINUX=' $var_selinux_state '@CCENUM@' '%s=%s'
#
function replace_or_append {
  local config_file=$1
  local key=$2
  local value=$3
  local cce=$4
  local format=$5

  # Check sanity of the input
  if [ $# -lt "3" ]
  then
        echo "Usage: replace_or_append 'config_file_location' 'key_to_search' 'new_value'"
        echo
        echo "If symlinks need to be taken into account, add yes/no to the last argument"
        echo "to allow to 'follow_symlinks'."
        echo "Aborting."
        exit 1
  fi

  # Test if the config_file is a symbolic link. If so, use --follow-symlinks with sed.
  # Otherwise, regular sed command will do.
  if test -L $config_file; then
    sed_command="sed -i --follow-symlinks"
  else
    sed_command="sed -i"
  fi

  # Test that the cce arg is not empty or does not equal @CCENUM@.
  # If @CCENUM@ exists, it means that there is no CCE assigned.
  if ! [ "x$cce" = x ] && [ "$cce" != '@CCENUM@' ]; then
    cce="CCE-${cce}"
  else
    cce="CCE"
  fi

  # Strip any search characters in the key arg so that the key can be replaced without
  # adding any search characters to the config file.
  stripped_key=$(sed "s/[\^=\$,;+]*//g" <<< $key)

  # If there is no print format specified in the last arg, use the default format.
  if ! [ "x$format" = x ] ; then
    printf -v formatted_output "$format" "$stripped_key" "$value"
  else
    formatted_output="$stripped_key = $value"
  fi

  # If the key exists, change it. Otherwise, add it to the config_file.
  if `grep -qi "$key" $config_file` ; then
    eval '$sed_command "s/$key.*/$formatted_output/g" $config_file'
  else
    # \n is precaution for case where file ends without trailing newline
    echo -e "\n# Per $cce: Set $formatted_output in $config_file" >> $config_file
    echo -e "$formatted_output" >> $config_file
  fi

}

replace_or_append '/etc/security/pwquality.conf' '^lcredit' $var_password_pam_lcredit 'CCE-27345-8' '%s = %s'
Remediation Ansible snippet:   (show)

- name: XCCDF Value var_password_pam_lcredit # promote to variable
  set_fact:
    var_password_pam_lcredit: -1
  tags:
    - always

- name: Ensure PAM variable lcredit is set accordingly
  lineinfile:
    create=yes
    dest="/etc/security/pwquality.conf"
    regexp="^lcredit"
    line="lcredit = {{ var_password_pam_lcredit }}"
  tags:
    - accounts_password_pam_lcredit
    - medium_severity
    - CCE-27345-8
    - NIST-800-53-IA-5(b)
    - NIST-800-53-IA-5(c)
    - NIST-800-53-IA-5(1)(a)
    - PCI-DSS-Req-8.2.3
    - DISA-STIG-RHEL-07-010130

Set Deny For Failed Password Attemptsaccounts_passwords_pam_faillock_deny medium

Set Deny For Failed Password Attempts

Rule IDaccounts_passwords_pam_faillock_deny
Result
fail
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86567r2_rule, AC-7(b), CCI-002238, SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005, Req-8.1.6, 5.3.2, 5.5.3, 3.1.8

Description

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.

Remediation Shell script:   (show)


var_accounts_passwords_pam_faillock_deny="6"

AUTH_FILES[0]="/etc/pam.d/system-auth"
AUTH_FILES[1]="/etc/pam.d/password-auth"

# This script fixes absence of pam_faillock.so in PAM stack or the
# absense of deny=[0-9]+ in pam_faillock.so arguments
# When inserting auth pam_faillock.so entries,
# the entry with preauth argument will be added before pam_unix.so module
# and entry with authfail argument will be added before pam_deny.so module.

# The placement of pam_faillock.so entries will not be changed
# if they are already present

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-symlinks "s/\(^auth.*required.*pam_faillock.so.*preauth.*silent.*\)\(deny *= *\).*/\1\2$var_accounts_passwords_pam_faillock_deny/" $pamFile
			sed -i --follow-symlinks "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-symlinks "/^auth.*required.*pam_faillock.so.*preauth.*silent.*/ s/$/ deny=$var_accounts_passwords_pam_faillock_deny/" $pamFile
			sed -i --follow-symlinks "/^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 row with proper value of the 'deny' option before pam_unix.so
		sed -i --follow-symlinks "/^auth.*pam_unix.so.*/i auth        required      pam_faillock.so preauth silent deny=$var_accounts_passwords_pam_faillock_deny" $pamFile
		# insert pam_faillock.so authfail row with proper value of the 'deny' option before pam_deny.so, after all modules which determine authentication outcome.
		sed -i --follow-symlinks "/^auth.*pam_deny.so.*/i auth        [default=die] pam_faillock.so authfail deny=$var_accounts_passwords_pam_faillock_deny" $pamFile
	fi

	# add pam_faillock.so into account phase
	if ! grep -q "^account.*required.*pam_faillock.so" $pamFile; then
		sed -i --follow-symlinks "/^account.*required.*pam_unix.so/i account     required      pam_faillock.so" $pamFile
	fi
done
Set Lockout Time For Failed Password Attemptsaccounts_passwords_pam_faillock_unlock_time medium

Set Lockout Time For Failed Password Attempts

Rule IDaccounts_passwords_pam_faillock_unlock_time
Result
fail
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86567r2_rule, AC-7(b), CCI-002238, SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005, Req-8.1.7, 5.3.2, 5.5.3, 3.1.8

Description

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.

Remediation Shell script:   (show)


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-symlinks "s/\(^auth.*required.*pam_faillock.so.*preauth.*silent.*\)\(unlock_time *= *\).*/\1\2$var_accounts_passwords_pam_faillock_unlock_time/" $pamFile
			sed -i --follow-symlinks "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-symlinks "/^auth.*required.*pam_faillock.so.*preauth.*silent.*/ s/$/ unlock_time=$var_accounts_passwords_pam_faillock_unlock_time/" $pamFile
			sed -i --follow-symlinks "/^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-symlinks "/^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-symlinks "/^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-symlinks "/^account.*required.*pam_unix.so/i account     required      pam_faillock.so" $pamFile
	fi
done
Limit Password Reuseaccounts_password_pam_unix_remember medium

Limit Password Reuse

Rule IDaccounts_password_pam_unix_remember
Result
fail
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86557r1_rule, IA-5(f), IA-5(1)(e), CCI-000200, SRG-OS-000077-GPOS-00045, Req-8.2.5, 5.3.3, 5.6.2.1.1, 3.5.8

Description

Do not allow users to reuse recent passwords. This can be accomplished by using the remember option for the pam_unix or pam_pwhistory PAM modules.

In the file /etc/pam.d/system-auth, append remember=4 to the line which refers to the pam_unix.so or pam_pwhistory.somodule, as shown below:

  • for the pam_unix.so case:
    password sufficient pam_unix.so ...existing_options... remember=4
  • for the pam_pwhistory.so case:
    password requisite pam_pwhistory.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.

Remediation Shell script:   (show)


var_password_pam_unix_remember="4"

if grep -q "remember=" /etc/pam.d/system-auth; then   
	sed -i --follow-symlinks "s/\(^password.*sufficient.*pam_unix.so.*\)\(\(remember *= *\)[^ $]*\)/\1remember=$var_password_pam_unix_remember/" /etc/pam.d/system-auth
else
	sed -i --follow-symlinks "/^password[[:space:]]\+sufficient[[:space:]]\+pam_unix.so/ s/$/ remember=$var_password_pam_unix_remember/" /etc/pam.d/system-auth
fi
Set PAM's Password Hashing Algorithmset_password_hashing_algorithm_systemauth medium

Set PAM's Password Hashing Algorithm

Rule IDset_password_hashing_algorithm_systemauth
Result
pass
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86543r1_rule, IA-5(b), IA-5(c), IA-5(1)(c), IA-7, CCI-000196, SRG-OS-000073-GPOS-00041, Req-8.2.1, 6.3.1, 5.6.2.2, 3.13.11

Description

The PAM system service can be configured to only store encrypted representations of passwords. 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

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kepy in plain text.

This setting ensures user and group account administration utilities are configured to store only encrypted representations of passwords. Additionally, the crypt_style configuration option ensures the use of a strong hashing algorithm that makes password cracking attacks more difficult.

Set Password Hashing Algorithm in /etc/login.defsset_password_hashing_algorithm_logindefs medium

Set Password Hashing Algorithm in /etc/login.defs

Rule IDset_password_hashing_algorithm_logindefs
Result
pass
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86545r1_rule, IA-5(b), IA-5(c), IA-5(1)(c), IA-7, CCI-000196, SRG-OS-000073-GPOS-00041, Req-8.2.1, 6.3.1, 5.6.2.2, 3.13.11

Description

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

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kept in plain text.

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

Set Password Hashing Algorithm in /etc/libuser.confset_password_hashing_algorithm_libuserconf medium

Set Password Hashing Algorithm in /etc/libuser.conf

Rule IDset_password_hashing_algorithm_libuserconf
Result
pass
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86547r2_rule, IA-5(b), IA-5(c), IA-5(1)(c), IA-7, CCI-000196, SRG-OS-000073-GPOS-00041, Req-8.2.1, 5.6.2.2, 3.13.11

Description

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

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kepy in plain text.

This setting ensures user and group account administration utilities are configured to store only encrypted representations of passwords. Additionally, the crypt_style configuration option ensures the use of a strong hashing algorithm that makes password cracking attacks more difficult.

Verify /boot/grub2/grub.cfg User Ownershipfile_user_owner_grub2_cfg medium

Verify /boot/grub2/grub.cfg User Ownership

Rule IDfile_user_owner_grub2_cfg
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AC-6(7), CCI-000225, Req-7.1, 1.4.1, 5.5.2.2, 3.4.5

Description

The file /boot/grub2/grub.cfg should be owned by the root user to prevent destruction or modification of the file. To properly set the owner of /boot/grub2/grub.cfg, run the command:

$ sudo chown root /boot/grub2/grub.cfg

Rationale

Only root should be able to modify important boot parameters.

Verify /boot/grub2/grub.cfg Group Ownershipfile_group_owner_grub2_cfg medium

Verify /boot/grub2/grub.cfg Group Ownership

Rule IDfile_group_owner_grub2_cfg
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AC-6(7), CCI-000225, Req-7.1, 1.4.1, 5.5.2.2, 3.4.5

Description

The file /boot/grub2/grub.cfg should be group-owned by the root group to prevent destruction or modification of the file. To properly set the group owner of /boot/grub2/grub.cfg, run the command:

$ sudo chgrp root /boot/grub2/grub.cfg

Rationale

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

Enable Smart Card Loginsmartcard_auth medium

Enable Smart Card Login

Rule IDsmartcard_auth
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86589r1_rule, IA-2(2), CCI-000765, CCI-000766, CCI-000767, CCI-000768, CCI-000771, CCI-000772, CCI-000884, Req-8.3, SRG-OS-000104-GPOS-00051, SRG-OS-000106-GPOS-00053, SRG-OS-000107-GPOS-00054, SRG-OS-000109-GPOS-00056, SRG-OS-000108-GPOS-00055, SRG-OS-000108-GPOS-00057, SRG-OS-000108-GPOS-00058

Description

To enable smart card authentication, consult the documentation at:

For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at:

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.

Install libreswan Packagepackage_libreswan_installed medium

Install libreswan Package

Rule IDpackage_libreswan_installed
Result
pass
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AC-17, MA-4, SC-9, CCI-001130, CCI-001131, Req-4.1

Description

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

$ sudo yum install libreswan

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.

Ensure Log Files Are Owned By Appropriate Userrsyslog_files_ownership medium

Ensure Log Files Are Owned By Appropriate User

Rule IDrsyslog_files_ownership
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AC-6, SI-11, CCI-001314, Req-10.5.1, Req-10.5.2

Description

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.

Ensure Log Files Are Owned By Appropriate Grouprsyslog_files_groupownership medium

Ensure Log Files Are Owned By Appropriate Group

Rule IDrsyslog_files_groupownership
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AC-6, SI-11, CCI-001314, Req-10.5.1, Req-10.5.2

Description

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.

Ensure System Log Files Have Correct Permissionsrsyslog_files_permissions medium

Ensure System Log Files Have Correct Permissions

Rule IDrsyslog_files_permissions
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SI-11, CCI-001314, Req-10.5.1, Req-10.5.2, 4.2.1.3

Description

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.

Ensure Logrotate Runs Periodicallyensure_logrotate_activated low

Ensure Logrotate Runs Periodically

Rule IDensure_logrotate_activated
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  AU-9, CCI-000366, Req-10.7

Description

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.

Configure auditd Number of Logs Retainedauditd_data_retention_num_logs medium

Configure auditd Number of Logs Retained

Rule IDauditd_data_retention_num_logs
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AU-1(b), AU-11, IR-5, Req-10.7, 5.4.1.1, 3.3.1

Description

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.

Configure auditd Max Log File Sizeauditd_data_retention_max_log_file medium

Configure auditd Max Log File Size

Rule IDauditd_data_retention_max_log_file
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AU-1(b), AU-11, IR-5, Req-10.7, 5.2.1.1, 5.4.1.1

Description

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.

Configure auditd max_log_file_action Upon Reaching Maximum Log Sizeauditd_data_retention_max_log_file_action medium

Configure auditd max_log_file_action Upon Reaching Maximum Log Size

Rule IDauditd_data_retention_max_log_file_action
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AU-1(b), AU-4, AU-11, IR-5, Req-10.7, 5.2.1.3, 5.4.1.1

Description

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.

Configure auditd space_left Action on Low Disk Spaceauditd_data_retention_space_left_action medium

Configure auditd space_left Action on Low Disk Space

Rule IDauditd_data_retention_space_left_action
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AU-1(b), AU-4, AU-5(1), AU-5(b), IR-5, CCI-001855, Req-10.7, 5.2.1.2, SRG-OS-000343-GPOS-00134, 030340, 5.4.1.1, 3.3.1

Description

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.

Configure auditd admin_space_left Action on Low Disk Spaceauditd_data_retention_admin_space_left_action medium

Configure auditd admin_space_left Action on Low Disk Space

Rule IDauditd_data_retention_admin_space_left_action
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AU-1(b), AU-4, AU-5(b), IR-5, CCI-000140, CCI-001343, Req-10.7, 5.2.1.2, 5.4.1.1, 3.3.1

Description

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.

Configure auditd mail_acct Action on Low Disk Spaceauditd_data_retention_action_mail_acct medium

Configure auditd mail_acct Action on Low Disk Space

Rule IDauditd_data_retention_action_mail_acct
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86717r2_rule, AU-1(b), AU-4, AU-5(1), AU-5(a), IR-5, CCI-001855, Req-10.7.a, 5.2.1.2, SRG-OS-000343-GPOS-00134, 5.4.1.1, 3.3.1

Description

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.

Configure auditd to use audispd's syslog pluginauditd_audispd_syslog_plugin_activated medium

Configure auditd to use audispd's syslog plugin

Rule IDauditd_audispd_syslog_plugin_activated
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AU-1(b), AU-3(2), IR-5, CCI-000136, Req-10.5.3, 5.4.1.1, 3.3.1

Description

To configure the auditd service to use the syslog plug-in of the audispd audit event multiplexor, set the active line in /etc/audisp/plugins.d/syslog.conf to yes. Restart the auditd service:

$ 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 a plug-in for audit event multiplexor (audispd) to pass audit records to the local syslog server

Record attempts to alter time through adjtimexaudit_rules_time_adjtimex low

Record attempts to alter time through adjtimex

Rule IDaudit_rules_time_adjtimex
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 5.2.4, Req-10.4.2.b, CCI-001487, CCI-000169, 5.4.1.1, 3.1.7

Description

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S adjtimex -F key=audit_time_rules
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S adjtimex -F key=audit_time_rules
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S adjtimex -F key=audit_time_rules
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S adjtimex -F key=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,settimeofday -F key=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.

Record attempts to alter time through settimeofdayaudit_rules_time_settimeofday low

Record attempts to alter time through settimeofday

Rule IDaudit_rules_time_settimeofday
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 5.2.4, Req-10.4.2.b, CCI-001487, CCI-000169, 5.4.1.1, 3.1.7

Description

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S settimeofday -F key=audit_time_rules
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S settimeofday -F key=audit_time_rules
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S settimeofday -F key=audit_time_rules
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S settimeofday -F key=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,settimeofday -F key=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.

Record Attempts to Alter Time Through stimeaudit_rules_time_stime low

Record Attempts to Alter Time Through stime

Rule IDaudit_rules_time_stime
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, Req-10.4.2.b, CCI-001487, CCI-000169, 5.4.1.1, 3.1.7

Description

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d for both 32 bit and 64 bit systems:

-a always,exit -F arch=b32 -S stime -F key=audit_time_rules
Since the 64 bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32 bit and 64 bit systems). If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file for both 32 bit and 64 bit systems:
-a always,exit -F arch=b32 -S stime -F key=audit_time_rules
Since the 64 bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32 bit and 64 bit systems). 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 system calls:
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=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.

Record Attempts to Alter Time Through clock_settimeaudit_rules_time_clock_settime low

Record Attempts to Alter Time Through clock_settime

Rule IDaudit_rules_time_clock_settime
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 5.2.4, Req-10.4.2.b, CCI-001487, CCI-000169, 5.4.1.1, 3.1.7

Description

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
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,settimeofday -F key=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.

Record Attempts to Alter the localtime Fileaudit_rules_time_watch_localtime low

Record Attempts to Alter the localtime File

Rule IDaudit_rules_time_watch_localtime
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(b), IR-5, 5.2.4, Req-10.4.2.b, CCI-001487, CCI-000169, 5.4.1.1, 3.1.7

Description

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-w /etc/localtime -p wa -k audit_time_rules
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-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.

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

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

Rule IDaudit_rules_dac_modification_chmod
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  SV-86729r2_rule, AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, CCI-000126, CCI-000172, Req-10.5.5, 5.2.10, SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, 5.4.1.1, 3.1.7

Description

At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=4294967295 -F key=perm_mod

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.

Warnings
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.
Record Events that Modify the System's Discretionary Access Controls - chownaudit_rules_dac_modification_chown low

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

Rule IDaudit_rules_dac_modification_chown
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  SV-86721r2_rule, AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, CCI-000126, CCI-000172, Req-10.5.5, 5.2.10, SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, 5.4.1.1, 3.1.7

Description

At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -F key=perm_mod

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.

Warnings
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.
Record Events that Modify the System's Discretionary Access Controls - fchmodaudit_rules_dac_modification_fchmod low

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

Rule IDaudit_rules_dac_modification_fchmod
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  SV-86731r2_rule, AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, CCI-000126, CCI-000172, Req-10.5.5, 5.2.10, SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, 5.4.1.1, 3.1.7

Description

At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -F key=perm_mod

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.

Warnings
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.
Record Events that Modify the System's Discretionary Access Controls - fchmodataudit_rules_dac_modification_fchmodat low

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

Rule IDaudit_rules_dac_modification_fchmodat
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  SV-86733r2_rule, AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, CCI-000126, CCI-000172, Req-10.5.5, 5.2.10, SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, 5.4.1.1, 3.1.7

Description

At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -F key=perm_mod

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.

Warnings
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.
Record Events that Modify the System's Discretionary Access Controls - fchownaudit_rules_dac_modification_fchown low

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

Rule IDaudit_rules_dac_modification_fchown
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  SV-86723r2_rule, AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, CCI-000126, CCI-000172, Req-10.5.5, 5.2.10, SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, 5.4.1.1, 3.1.7

Description

At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -F key=perm_mod

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.

Warnings
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.
Record Events that Modify the System's Discretionary Access Controls - fchownataudit_rules_dac_modification_fchownat low

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

Rule IDaudit_rules_dac_modification_fchownat
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  SV-86727r2_rule, AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, CCI-000126, CCI-000172, Req-10.5.5, 5.2.10, SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, 5.4.1.1, 3.1.7

Description

At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -F key=perm_mod

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.

Warnings
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.
Record Events that Modify the System's Discretionary Access Controls - fremovexattraudit_rules_dac_modification_fremovexattr medium

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

Rule IDaudit_rules_dac_modification_fremovexattr
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86743r2_rule, AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, CCI-000172, Req-10.5.5, 5.2.10, SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, 5.4.1.1, 3.1.7

Description

At a minimum, the audit system should collect file permission changes for all users and root.

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

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


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


If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod


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

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.

Warnings
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.
Record Events that Modify the System's Discretionary Access Controls - fsetxattraudit_rules_dac_modification_fsetxattr low

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

Rule IDaudit_rules_dac_modification_fsetxattr
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  SV-86737r2_rule, AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, CCI-000126, CCI-000172, Req-10.5.5, 5.2.10, SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, 5.4.1.1, 3.1.7

Description

At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod

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.

Warnings
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.
Record Events that Modify the System's Discretionary Access Controls - lchownaudit_rules_dac_modification_lchown low

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

Rule IDaudit_rules_dac_modification_lchown
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  SV-86725r2_rule, AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, CCI-000126, CCI-000172, Req-10.5.5, 5.2.10, SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, 5.4.1.1, 3.1.7

Description

At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -F key=perm_mod

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.

Warnings
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.
Record Events that Modify the System's Discretionary Access Controls - lremovexattraudit_rules_dac_modification_lremovexattr medium

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

Rule IDaudit_rules_dac_modification_lremovexattr
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86745r2_rule, AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, CCI-000172, Req-10.5.5, 5.2.10, SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, 5.4.1.1, 3.1.7

Description

At a minimum, the audit system should collect file permission changes for all users and root.

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

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


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


If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod


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

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.

Warnings
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.
Record Events that Modify the System's Discretionary Access Controls - lsetxattraudit_rules_dac_modification_lsetxattr low

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

Rule IDaudit_rules_dac_modification_lsetxattr
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  SV-86739r2_rule, AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, CCI-000126, CCI-000172, Req-10.5.5, 5.2.10, SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, 5.4.1.1, 3.1.7

Description

At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod

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.

Warnings
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.
Record Events that Modify the System's Discretionary Access Controls - removexattraudit_rules_dac_modification_removexattr medium

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

Rule IDaudit_rules_dac_modification_removexattr
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86741r2_rule, AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, CCI-000172, Req-10.5.5, 5.2.10, SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, 5.4.1.1, 3.1.7

Description

At a minimum, the audit system should collect file permission changes for all users and root.

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

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


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


If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod


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

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.

Warnings
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.
Record Events that Modify the System's Discretionary Access Controls - setxattraudit_rules_dac_modification_setxattr low

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

Rule IDaudit_rules_dac_modification_setxattr
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  SV-86735r2_rule, AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, CCI-000126, CCI-000172, Req-10.5.5, 5.2.10, SRG-OS-000064-GPOS-00033, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, 5.4.1.1, 3.1.7

Description

At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod

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.

Warnings
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.
Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful)audit_rules_unsuccessful_file_modification medium

Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful)

Rule IDaudit_rules_unsuccessful_file_modification
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, CCI-000172, CCI-002884, Req-10.2.4, Req-10.2.1, 5.2.10, 5.4.1.1, 3.1.7

Description

At a minimum the audit system should collect unauthorized file accesses for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -F key=access
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -F key=access
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -F key=access
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -F key=access
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -F key=access
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -F key=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.

Ensure auditd Collects Information on the Use of Privileged Commandsaudit_rules_privileged_commands medium

Ensure auditd Collects Information on the Use of Privileged Commands

Rule IDaudit_rules_privileged_commands
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86719r2_rule, AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-2(4), AU-6(9), AU-12(a), AU-12(c), IR-5, CCI-002234, SRG-OS-000327-GPOS-00127, Req-10.2.2, 5.2.10, 5.4.1.1, 3.1.7

Description

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
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d for each setuid / setgid program on the system, replacing the SETUID_PROG_PATH part with the full path of that setuid / setgid program in the list:
-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=4294967295 -F key=privileged
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules for each setuid / setgid program on the system, replacing the SETUID_PROG_PATH part with the full path of that setuid / setgid program in the list:
-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=4294967295 -F key=privileged

Rationale

Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider and advanced persistent threast.

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.

Ensure auditd Collects File Deletion Events by Useraudit_rules_file_deletion_events medium

Ensure auditd Collects File Deletion Events by User

Rule IDaudit_rules_file_deletion_events
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, Req-10.2.7, 5.2.14, CCI-000366, CCI-000172, CCI-002884, 5.4.1.1, 3.1.7

Description

At a minimum the audit system should collect file deletion events for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as appropriate for your system:

-a always,exit -F arch=ARCH -S rmdiri,unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=4294967295 -F key=delete
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system:
-a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename -S renameat -F auid>=1000 -F auid!=4294967295 -F key=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.

Ensure auditd Collects Information on Kernel Module Loading and Unloadingaudit_rules_kernel_module_loading medium

Ensure auditd Collects Information on Kernel Module Loading and Unloading

Rule IDaudit_rules_kernel_module_loading
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, Req-10.2.7, 5.2.17, CCI-000172, 5.4.1.1, 3.1.7

Description

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system:

-w /usr/sbin/insmod -p x -k modules
-w /usr/sbin/rmmod -p x -k modules
-w /usr/sbin/modprobe -p x -k modules
-a always,exit -F arch=ARCH -S init_module -S delete_module -k modules
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system:
-w /usr/sbin/insmod -p x -k modules
-w /usr/sbin/rmmod -p x -k modules
-w /usr/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.

Record Events that Modify User/Group Informationaudit_rules_usergroup_modification low

Record Events that Modify User/Group Information

Rule IDaudit_rules_usergroup_modification
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  SV-86789r3_rule, AC-2(4), AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, CCI-000018, CCI-000172, CCI-001403, CCI-002130, Req-10.2.5, 5.2.5, SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000241-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000476-GPOS-00221, 5.4.1.1, 3.1.7

Description

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d, in order to capture events that modify account changes:

-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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file, in order to capture events that modify account changes:
-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.

Record Events that Modify the System's Network Environmentaudit_rules_networkconfig_modification low

Record Events that Modify the System's Network Environment

Rule IDaudit_rules_networkconfig_modification
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, Req-10.5.5, 5.4.1.1, 5.2.6, 3.1.7

Description

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as appropriate for your system:

-a always,exit -F arch=ARCH -S sethostname,setdomainname -F key=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
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system:
-a always,exit -F arch=ARCH -S sethostname,setdomainname -F key=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.

System Audit Logs Must Have Mode 0640 or Less Permissivefile_permissions_var_log_audit medium

System Audit Logs Must Have Mode 0640 or Less Permissive

Rule IDfile_permissions_var_log_audit
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AC-6, AU-1(b), AU-9, IR-5, Req-10.5, 5.4.1.1, 3.3.1

Description

If log_group in /etc/audit/auditd.conf is set to a group other than the root group account, change the mode of the audit log files with the following command:

$ sudo chmod 0640 audit_file

Otherwise, change the mode of the audit log files with the following command:
$ sudo chmod 0600 audit_file

Rationale

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

System Audit Logs Must Be Owned By Rootfile_ownership_var_log_audit medium

System Audit Logs Must Be Owned By Root

Rule IDfile_ownership_var_log_audit
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AC-6, AU-1(b), AU-9, IR-5, CCI-000163, SRG-OS-000058-GPOS-00028, Req-10.5.1, 5.4.1.1, 3.3.1

Description

All audit logs must be owned by root user and group. By default, the path for audit log is

/var/log/audit/
. To properly set the owner of /var/log/audit, run the command:
$ sudo chown root /var/log/audit
To properly set the owner of /var/log/audit/*, run the command:
$ sudo chown root /var/log/audit/*

Rationale

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality.

Record Events that Modify the System's Mandatory Access Controlsaudit_rules_mac_modification low

Record Events that Modify the System's Mandatory Access Controls

Rule IDaudit_rules_mac_modification
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, Req-10.5.5, 5.2.7, 5.4.1.1, 3.1.8

Description

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-w /etc/selinux/ -p wa -k MAC-policy
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-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.

Record Attempts to Alter Process and Session Initiation Informationaudit_rules_session_events low

Record Attempts to Alter Process and Session Initiation Information

Rule IDaudit_rules_session_events
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, Req-10.2.3, 5.2.9, 5.4.1.1, 3.1.7

Description

The audit system already collects process information for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d in order to watch for attempted manual edits of files involved in storing such process information:

-w /var/run/utmp -p wa -k session
-w /var/log/btmp -p wa -k session
-w /var/log/wtmp -p wa -k session
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for attempted manual edits of files involved in storing such process information:
-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.

Ensure auditd Collects Information on Exporting to Media (successful)audit_rules_media_export medium

Ensure auditd Collects Information on Exporting to Media (successful)

Rule IDaudit_rules_media_export
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  SV-86795r3_rule, AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-3(1), AU-12(a), AU-12(c), IR-5, CCI-000135, CCI-002884, SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, Req-10.2.7, 5.2.13, 5.4.1.1, 3.1.7

Description

At a minimum, the audit system should collect media exportation events for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as appropriate for your system:

-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=4294967295 -F key=export
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system:
-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=4294967295 -F key=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.

Ensure auditd Collects System Administrator Actionsaudit_rules_sysadmin_actions low

Ensure auditd Collects System Administrator Actions

Rule IDaudit_rules_sysadmin_actions
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  SV-86787r3_rule, AC-2(7)(b), AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), iAU-3(1), AU-12(a), AU-12(c), IR-5, CCI-000126, CCI-000130, CCI-000135, CCI-000172, CCI-002884, Req-10.2.2, Req-10.2.5.b, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, 5.4.1.1, 3.1.7

Description

At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -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.

Make the auditd Configuration Immutableaudit_rules_immutable medium

Make the auditd Configuration Immutable

Rule IDaudit_rules_immutable
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AC-6, AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, Req-10.5.2, 4.1.18, 5.4.1.1, 3.3.1, 3.4.3

Description

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d in order to make the auditd configuration immutable:

-e 2
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file in order to make the auditd 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

Enable auditd Serviceservice_auditd_enabled high

Enable auditd Service

Rule IDservice_auditd_enabled
Result
notapplicable
Time2018-05-19T02:19:05
Severityhigh
Identifiers and References

References:  SV-86703r1_rule, AU-3, AC-17(1), AU-1(b), AU-10, AU-12(a), AU-12(c), AU-14(1), IR-5, CCI-000126, CCI-000131, SRG-OS-000038-GPOS-00016, SRG-OS-000039-GPOS-00017, SRG-OS-000042-GPOS-00021, SRG-OS-000254-GPOS-00095, SRG-OS-000255-GPOS-00096, Req-10, 4.1.2, 5.4.1.1, 3.3.1, 3.3.2, 3.3.6

Description

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 systemctl enable auditd.service

Rationale

Without establishing what type of events occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. Ensuring the auditd service is active ensures audit records generated by the kernel are appropriately recorded.

Additionally, a properly configured audit subsystem ensures that actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions.

Enable Auditing for Processes Which Start Prior to the Audit Daemonbootloader_audit_argument medium

Enable Auditing for Processes Which Start Prior to the Audit Daemon

Rule IDbootloader_audit_argument
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AC-17(1), AU-14(1), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-10, IR-5, CCI-001464, CCI-000130, Req-10.3, 4.1.3, 5.4.1.1, 3.3.1

Description

To ensure all processes can be audited, even those which start prior to the audit daemon, add the argument audit=1 to the default GRUB 2 command line for the Linux operating system in /etc/default/grub, in the manner below:

GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 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.

Warnings
warning  The GRUB 2 configuration file, grub.cfg, is automatically updated each time a new kernel is installed. Note that any changes to /etc/default/grub require rebuilding the grub.cfg file. To update the GRUB 2 configuration file manually, use the
grub2-mkconfig -o
command as follows:
  • On BIOS-based machines, issue the following command as root:
    ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
  • On UEFI-based machines, issue the following command as root:
    ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
Set SSH Idle Timeout Intervalsshd_set_idle_timeout low

Set SSH Idle Timeout Interval

Rule IDsshd_set_idle_timeout
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  SV-86861r2_rule, AC-2(5), SA-8(i), AC-12, CCI-001133, CCI-002361, SRG-OS-000163-GPOS-00072, SRG-OS-000279-GPOS-00109, Req-8.1.8, 5.2.12, 5.5.6, 3.1.11

Description

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

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

ClientAliveInterval interval
The timeout interval is given in seconds. To have a timeout of 10 minutes, set interval to 600.

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

Terminating an idle ssh session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been let unattended.

Enable the NTP Daemonservice_chronyd_or_ntpd_enabled medium

Enable the NTP Daemon

Rule IDservice_chronyd_or_ntpd_enabled
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AU-8(1), CCI-000160, Req-10.4, 2.2.1.1, 3.3.7

Description

The chronyd service can be enabled with the following command:

$ sudo systemctl enable chronyd.service
Note: The chronyd daemon is enabled by default.

The ntpd service can be enabled with the following command:
$ sudo systemctl enable ntpd.service
Note: The ntpd daemon is not enabled by default. Though as mentioned in the previous sections in certain environments the ntpd daemon might be preferred to be used rather than the chronyd one. Refer to: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Configuring_NTP_Using_the_chrony_Suite.html for guidance which NTP daemon to choose depending on the environment used.

Rationale

Enabling some of chronyd or ntpd services ensures that the NTP daemon 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 chronyd and ntpd NTP daemons offer 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

Specify a Remote NTP Serverchronyd_or_ntpd_specify_remote_server medium

Specify a Remote NTP Server

Rule IDchronyd_or_ntpd_specify_remote_server
Result
notapplicable
Time2018-05-19T02:19:05
Severitymedium
Identifiers and References

References:  AU-8(1), CCI-000160, Req-10.4.1, Req-10.4.3, 3.6, 3.3.7

Description

Depending on specific functional requirements of a concrete production environment, the CentOS Linux 7 Server system can be configured to utilize the services of the chronyd NTP daemon (the default), or services of the ntpd NTP daemon. Refer to https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Configuring_NTP_Using_the_chrony_Suite.html for more detailed comparison of the features of both of the choices, and for further guidance how to choose between the two NTP daemons.
To specify a remote NTP server for time synchronization, perform the following:

  • if the system is configured to use the chronyd as the NTP daemon (the default), edit the file /etc/chrony.conf as follows,
  • if the system is configured to use the ntpd as the NTP daemon, edit the file /etc/ntp.conf as documented below.
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.

Specify Additional Remote NTP Serverschronyd_or_ntpd_specify_multiple_servers low

Specify Additional Remote NTP Servers

Rule IDchronyd_or_ntpd_specify_multiple_servers
Result
notapplicable
Time2018-05-19T02:19:05
Severitylow
Identifiers and References

References:  AU-8(1), Req-10.4.3

Description

Depending on specific functional requirements of a concrete production environment, the CentOS Linux 7 Server system can be configured to utilize the services of the chronyd NTP daemon (the default), or services of the ntpd NTP daemon. Refer to https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Configuring_NTP_Using_the_chrony_Suite.html for more detailed comparison of the features of both of the choices, and for further guidance how to choose between the two NTP daemons.
Additional NTP servers can be specified for time synchronization. To do so, perform the following:

  • if the system is configured to use the chronyd as the NTP daemon (the default), edit the file /etc/chrony.conf as follows,
  • if the system is configured to use the ntpd as the NTP daemon, edit the file /etc/ntp.conf as documented below.
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.

Red Hat and CentOS 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.