Guide to the Secure Configuration of CentOS Linux 7
with profile PCI-DSS v3 Control Baseline for CentOS Linux 7This is a *draft* profile for PCI-DSS v3.
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.
Evaluation Characteristics
Evaluation target | centos75 |
---|---|
Benchmark URL | /usr/share/xml/scap/ssg/content/ssg-centos7-xccdf.xml |
Profile ID | pci-dss |
Started at | 2018-05-19T02:15:46 |
Finished at | 2018-05-19T02:19:05 |
Performed by | root |
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
Rule results
Severity of failed rules
Score
Scoring system | Score | Maximum | Percent |
---|---|---|---|
urn:xccdf:scoring:default | 82.986115 | 100.000000 |
Rule Overview
Result Details
Ensure Red Hat GPG Key Installed
Rule ID | ensure_redhat_gpgkey_installed |
Result | pass |
Time | 2018-05-19T02:15:48 |
Severity | high |
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 registerIf 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 Configuration
Rule ID | ensure_gpgcheck_globally_activated |
Result | pass |
Time | 2018-05-19T02:15:48 |
Severity | high |
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=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.
|
Ensure gpgcheck Enabled For All Yum Package Repositories
Rule ID | ensure_gpgcheck_never_disabled |
Result | pass |
Time | 2018-05-19T02:15:48 |
Severity | high |
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 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 Installed
Rule ID | security_patches_up_to_date |
Result | notchecked |
Time | 2018-05-19T02:15:48 |
Severity | high |
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 updateIf 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. |
Install AIDE
Rule ID | package_aide_installed | ||||||
Result | fail | ||||||
Time | 2018-05-19T02:15:48 | ||||||
Severity | medium | ||||||
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)
| |||||||
Remediation Ansible snippet: (show)
| |||||||
Remediation Puppet snippet: (show)
| |||||||
Build and Test AIDE Database
Rule ID | aide_build_database | ||||||
Result | fail | ||||||
Time | 2018-05-19T02:15:48 | ||||||
Severity | medium | ||||||
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 --initBy 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.gzTo initiate a manual check, run the following command: $ sudo /usr/sbin/aide --checkIf 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)
| |||||||
Remediation Ansible snippet: (show)
|
Configure Periodic Execution of AIDE
Rule ID | aide_periodic_cron_checking |
Result | notapplicable |
Time | 2018-05-19T02:15:48 |
Severity | medium |
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 05 4 * * * root /usr/sbin/aide --checkTo 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 --checkAIDE 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.
|
Verify File Hashes with RPM
Rule ID | rpm_verify_hashes |
Result | pass |
Time | 2018-05-19T02:19:04 |
Severity | high |
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 FILENAMEThe package can be reinstalled from a yum repository using the command: $ sudo yum reinstall PACKAGENAMEAlternatively, 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 Software
Rule ID | install_hids |
Result | notapplicable |
Time | 2018-05-19T02:19:04 |
Severity | high |
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. |
Disable Prelinking
Rule ID | disable_prelink |
Result | pass |
Time | 2018-05-19T02:15:48 |
Severity | low |
Identifiers and References | References: CM-6(d), CM-6(3), SC-28, SI-7, Req-11.5, 5.10.1.3, 1.5.4, 3.13.11 |
Description |
The prelinking feature changes binaries in an attempt to decrease their startup
time. In order to disable it, change or add the following line inside the file
PRELINKING=noNext, run the following command to return binaries to a normal, non-prelinked state: $ sudo /usr/sbin/prelink -ua |
Rationale | Because the prelinking feature changes binaries, it can interfere with the operation of certain software and/or modes such as AIDE, FIPS, etc. |
Set GNOME3 Screensaver Inactivity Timeout
Rule ID | dconf_gnome_screensaver_idle_delay |
Result | notapplicable |
Time | 2018-05-19T02:19:04 |
Severity | medium |
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 [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-delayAfter 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 Activation
Rule ID | dconf_gnome_screensaver_idle_activation_enabled |
Result | notapplicable |
Time | 2018-05-19T02:19:04 |
Severity | medium |
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 [org/gnome/desktop/screensaver] idle_activation_enabled=trueOnce 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-enabledAfter 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.
|
Enable GNOME3 Screensaver Lock After Idle Period
Rule ID | dconf_gnome_screensaver_lock_enabled |
Result | notapplicable |
Time | 2018-05-19T02:19:04 |
Severity | medium |
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 [org/gnome/desktop/screensaver] lock-enabled=trueOnce 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-enabledAfter 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 Screensaver
Rule ID | dconf_gnome_screensaver_mode_blank |
Result | notapplicable |
Time | 2018-05-19T02:19:04 |
Severity | low |
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 [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-uriAfter 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 File
Rule ID | userowner_shadow_file |
Result | pass |
Time | 2018-05-19T02:19:04 |
Severity | medium |
Identifiers and References | |
Description |
To properly set the owner of $ sudo chown root /etc/shadow |
Rationale | The |
Verify Group Who Owns shadow File
Rule ID | groupowner_shadow_file |
Result | pass |
Time | 2018-05-19T02:19:04 |
Severity | medium |
Identifiers and References | |
Description |
To properly set the group owner of $ sudo chgrp root /etc/shadow |
Rationale | The |
Verify User Who Owns group File
Rule ID | file_owner_etc_group |
Result | pass |
Time | 2018-05-19T02:19:04 |
Severity | medium |
Identifiers and References | |
Description |
To properly set the owner of $ sudo chown root /etc/group |
Rationale | The |
Verify Group Who Owns group File
Rule ID | file_groupowner_etc_group |
Result | pass |
Time | 2018-05-19T02:19:04 |
Severity | medium |
Identifiers and References | |
Description |
To properly set the group owner of $ sudo chgrp root /etc/group |
Rationale | The |
Verify User Who Owns passwd File
Rule ID | file_owner_etc_passwd |
Result | pass |
Time | 2018-05-19T02:19:04 |
Severity | medium |
Identifiers and References | |
Description |
To properly set the owner of $ sudo chown root /etc/passwd |
Rationale | The |
Verify Group Who Owns passwd File
Rule ID | file_groupowner_etc_passwd |
Result | pass |
Time | 2018-05-19T02:19:04 |
Severity | medium |
Identifiers and References | |
Description |
To properly set the group owner of $ sudo chgrp root /etc/passwd |
Rationale | The |
Prevent Log In to Accounts With Empty Password
Rule ID | no_empty_passwords | ||||||
Result | fail | ||||||
Time | 2018-05-19T02:19:04 | ||||||
Severity | high | ||||||
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 | ||||||
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)
| |||||||
Remediation Ansible snippet: (show)
|
Verify All Account Password Hashes are Shadowed
Rule ID | accounts_password_all_shadowed |
Result | pass |
Time | 2018-05-19T02:19:04 |
Severity | medium |
Identifiers and References | |
Description |
If any password hashes are stored in |
Rationale |
The hashes for all user account passwords should be stored in
the file |
All GIDs referenced in /etc/passwd must be defined in /etc/group
Rule ID | gid_passwd_group_same |
Result | pass |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 Maximum Age
Rule ID | accounts_maximum_age_login_defs | ||||||
Result | fail | ||||||
Time | 2018-05-19T02:19:05 | ||||||
Severity | medium | ||||||
Identifiers and References | References: SV-86553r1_rule, IA-5(f), IA-5(g), IA-5(1)(d), CCI-000199, SRG-OS-000076-GPOS-00044, Req-8.2.4, 5.4.1.1, 5.6.2.1, 3.5.6 | ||||||
Description | To specify password maximum age for new accounts,
edit the file PASS_MAX_DAYS 90A value of 180 days is sufficient for many environments. The DoD requirement is 60. The profile requirement is 90 .
| ||||||
Rationale |
Any password, no matter how complex, can eventually be cracked. Therefore, passwords
need to be changed periodically. If the operating system does not limit the lifetime
of passwords and force users to change their passwords, there is the risk that the
operating system passwords could be compromised.
| ||||||
Remediation Shell script: (show)
| |||||||
Remediation Ansible snippet: (show)
|
Set Account Expiration Following Inactivity
Rule ID | account_disable_post_pw_expiration | ||||||
Result | fail | ||||||
Time | 2018-05-19T02:19:05 | ||||||
Severity | medium | ||||||
Identifiers and References | References: SV-86565r1_rule, AC-2(2), AC-2(3), IA-4(e), CCI-000795, SRG-OS-000118-GPOS-00060, Req-8.1.4, 3.5.6, 5.6.2.1.1 | ||||||
Description | To specify the number of days after a password expires (which
signifies inactivity) until an account is permanently disabled, add or correct
the following lines in INACTIVE=90A value of 35 is recommended. If a password is currently on the verge of expiration, then 35 days remain until the account is automatically disabled. However, if the password will not expire for another 60 days, then 95 days could elapse until the account would be automatically disabled. See the useradd man page for more information. Determining the inactivity
timeout must be done with careful consideration of the length of a "normal"
period of inactivity for users in the particular environment. Setting
the timeout too low incurs support costs and also has the potential to impact
availability of the system to legitimate users.
| ||||||
Rationale | Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials. | ||||||
Remediation Shell script: (show)
| |||||||
Remediation Ansible snippet: (show)
|
Ensure All Accounts on the System Have Unique Names
Rule ID | account_unique_name |
Result | pass |
Time | 2018-05-19T02:19:05 |
Severity | low |
Identifiers and References | References: CCI-000770, CCI-000804, Req-8.1.1, 5.5.2 |
Description | Change usernames, or delete accounts, so each has a unique name. |
Rationale | Unique usernames allow for accountability on the system. |
Set Password Strength Minimum Digit Characters
Rule ID | accounts_password_pam_dcredit |
Result | fail |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 |
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.
|
Remediation Shell script: (show)
| |
Remediation Ansible snippet: (show)
|
Set Password Minimum Length
Rule ID | accounts_password_pam_minlen | ||||||
Result | fail | ||||||
Time | 2018-05-19T02:19:05 | ||||||
Severity | medium | ||||||
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 | ||||||
Rationale |
The shorter the password, the lower the number of possible combinations
that need to be tested before the password is compromised.
| ||||||
Remediation Shell script: (show)
| |||||||
Remediation Ansible snippet: (show)
|
Set Password Strength Minimum Uppercase Characters
Rule ID | accounts_password_pam_ucredit |
Result | fail |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 |
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.
|
Remediation Shell script: (show)
| |
Remediation Ansible snippet: (show)
|
Set Password Strength Minimum Lowercase Characters
Rule ID | accounts_password_pam_lcredit |
Result | fail |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 |
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.
|
Remediation Shell script: (show)
| |
Remediation Ansible snippet: (show)
|
Set Deny For Failed Password Attempts
Rule ID | accounts_passwords_pam_faillock_deny |
Result | fail |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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
|
Rationale | Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks. |
Remediation Shell script: (show)
|
Set Lockout Time For Failed Password Attempts
Rule ID | accounts_passwords_pam_faillock_unlock_time |
Result | fail |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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
|
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)
|
Limit Password Reuse
Rule ID | accounts_password_pam_unix_remember |
Result | fail |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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
|
Rationale | Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user. |
Remediation Shell script: (show)
|
Set PAM's Password Hashing Algorithm
Rule ID | set_password_hashing_algorithm_systemauth |
Result | pass |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 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.
|
Set Password Hashing Algorithm in /etc/login.defs
Rule ID | set_password_hashing_algorithm_logindefs |
Result | pass |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 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.
|
Set Password Hashing Algorithm in /etc/libuser.conf
Rule ID | set_password_hashing_algorithm_libuserconf |
Result | pass |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 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.
|
Set Last Logon/Access Notification
Rule ID | display_login_attempts |
Result | pass |
Time | 2018-05-19T02:19:05 |
Severity | low |
Identifiers and References | References: SV-86899r1_rule, AC-9, CCI-000366, Req-10.2.4, SRG-OS-000480-GPOS-00227, 5.5.2 |
Description | To configure the system to notify users of last logon/access
using session [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service !~ su* quiet session [default=1] pam_lastlog.so nowtmp showfailed session optional pam_lastlog.so silent noupdate showfailed |
Rationale | Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of unsuccessful attempts that were made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. |
Verify /boot/grub2/grub.cfg User Ownership
Rule ID | file_user_owner_grub2_cfg |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 $ sudo chown root /boot/grub2/grub.cfg |
Rationale | Only root should be able to modify important boot parameters. |
Verify /boot/grub2/grub.cfg Group Ownership
Rule ID | file_group_owner_grub2_cfg |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 $ sudo chgrp root /boot/grub2/grub.cfg |
Rationale |
The |
Enable Smart Card Login
Rule ID | smartcard_auth |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 Package
Rule ID | package_libreswan_installed |
Result | pass |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 $ 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 User
Rule ID | rsyslog_files_ownership |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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
$ ls -l LOGFILEIf 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 Group
Rule ID | rsyslog_files_groupownership |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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
$ ls -l LOGFILEIf 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 Logrotate Runs Periodically
Rule ID | ensure_logrotate_activated |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
Identifiers and References | References: AU-9, CCI-000366, Req-10.7 |
Description | The # 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 Retained
Rule ID | auditd_data_retention_num_logs |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
Identifiers and References | |
Description | Determine how many log files
num_logs = NUMLOGSSet 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 Size
Rule ID | auditd_data_retention_max_log_file |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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
max_log_file = STOREMBSet 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 Size
Rule ID | auditd_data_retention_max_log_file_action |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 max_log_file_action = ACTIONPossible values for ACTION are described in the auditd.conf man
page. These include:
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 |
Configure auditd space_left Action on Low Disk Space
Rule ID | auditd_data_retention_space_left_action |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 space_left_action = ACTIONPossible values for ACTION are described in the auditd.conf man page.
These include:
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 Space
Rule ID | auditd_data_retention_admin_space_left_action |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 admin_space_left_action = ACTIONSet 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 Space
Rule ID | auditd_data_retention_action_mail_acct |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 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 plugin
Rule ID | auditd_audispd_syslog_plugin_activated |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 $ 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 adjtimex
Rule ID | audit_rules_time_adjtimex |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -a always,exit -F arch=b32 -S adjtimex -F key=audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S adjtimex -F key=audit_time_rulesIf 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_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S adjtimex -F key=audit_time_rulesThe -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 settimeofday
Rule ID | audit_rules_time_settimeofday |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -a always,exit -F arch=b32 -S settimeofday -F key=audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S settimeofday -F key=audit_time_rulesIf 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_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S settimeofday -F key=audit_time_rulesThe -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 stime
Rule ID | audit_rules_time_stime |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -a always,exit -F arch=b32 -S stime -F key=audit_time_rulesSince 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_rulesSince 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_settime
Rule ID | audit_rules_time_clock_settime |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-changeIf 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-changeIf 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-changeIf 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-changeThe -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 File
Rule ID | audit_rules_time_watch_localtime |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -w /etc/localtime -p wa -k audit_time_rulesIf 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_rulesThe -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 - chmod
Rule ID | audit_rules_dac_modification_chmod |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -F key=perm_modIf 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_modIf 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_modIf 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 - chown
Rule ID | audit_rules_dac_modification_chown |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -F key=perm_modIf 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_modIf 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_modIf 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 - fchmod
Rule ID | audit_rules_dac_modification_fchmod |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -F key=perm_modIf 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_modIf 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_modIf 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 - fchmodat
Rule ID | audit_rules_dac_modification_fchmodat |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -F key=perm_modIf 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_modIf 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_modIf 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 - fchown
Rule ID | audit_rules_dac_modification_fchown |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -F key=perm_modIf 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_modIf 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_modIf 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 - fchownat
Rule ID | audit_rules_dac_modification_fchownat |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -F key=perm_modIf 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_modIf 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_modIf 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 - fremovexattr
Rule ID | audit_rules_dac_modification_fremovexattr |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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.
-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 - fsetxattr
Rule ID | audit_rules_dac_modification_fsetxattr |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -F key=perm_modIf 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_modIf 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_modIf 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 - lchown
Rule ID | audit_rules_dac_modification_lchown |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -F key=perm_modIf 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_modIf 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_modIf 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 - lremovexattr
Rule ID | audit_rules_dac_modification_lremovexattr |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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.
-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 - lsetxattr
Rule ID | audit_rules_dac_modification_lsetxattr |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -F key=perm_modIf 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_modIf 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_modIf 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 - removexattr
Rule ID | audit_rules_dac_modification_removexattr |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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.
-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 - setxattr
Rule ID | audit_rules_dac_modification_setxattr |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -F key=perm_modIf 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_modIf 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_modIf 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.
|
Record Attempts to Alter Logon and Logout Events
Rule ID | audit_rules_login_events |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
Identifiers and References | References: AC-17(7), AU-1(b), AU-12(a), AU-12(c), IR-5, CCI-000172, CCI-002884, Req-10.2.3, 5.2.8, 5.4.1.1, 3.1.7 |
Description | The audit system already collects login information for all users
and root. If the -w /var/log/tallylog -p wa -k logins -w /var/run/faillock/ -p wa -k logins -w /var/log/lastlog -p wa -k loginsIf 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 unattempted manual
edits of files involved in storing logon events:
-w /var/log/tallylog -p wa -k logins -w /var/run/faillock/ -p wa -k logins -w /var/log/lastlog -p wa -k logins |
Rationale | Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. |
Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful)
Rule ID | audit_rules_unsuccessful_file_modification |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 -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=accessIf 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=accessIf 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=accessIf 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 Commands
Rule ID | audit_rules_privileged_commands |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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/nullIf 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=privilegedIf 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.
|
Ensure auditd Collects File Deletion Events by User
Rule ID | audit_rules_file_deletion_events |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 -a always,exit -F arch=ARCH -S rmdiri,unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=4294967295 -F key=deleteIf 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 Unloading
Rule ID | audit_rules_kernel_module_loading |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 -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 modulesIf 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 Information
Rule ID | audit_rules_usergroup_modification |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -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 Environment
Rule ID | audit_rules_networkconfig_modification |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -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_modificationIf 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 Be Owned By Root
Rule ID | file_ownership_var_log_audit |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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/auditTo 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 Controls
Rule ID | audit_rules_mac_modification |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -w /etc/selinux/ -p wa -k MAC-policyIf 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 Information
Rule ID | audit_rules_session_events |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -w /var/run/utmp -p wa -k session -w /var/log/btmp -p wa -k session -w /var/log/wtmp -p wa -k sessionIf 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)
Rule ID | audit_rules_media_export |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 -a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=4294967295 -F key=exportIf 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 Actions
Rule ID | audit_rules_sysadmin_actions |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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 -w /etc/sudoers -p wa -k actions -w /etc/sudoers.d/ -p wa -k actionsIf 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 Immutable
Rule ID | audit_rules_immutable |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 -e 2If 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 2With 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 Service
Rule ID | service_auditd_enabled |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | high |
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 $ 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 |
Enable Auditing for Processes Which Start Prior to the Audit Daemon
Rule ID | bootloader_audit_argument |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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 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 |
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 -ocommand as follows:
|
Set SSH Idle Timeout Interval
Rule ID | sshd_set_idle_timeout |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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.
ClientAliveInterval intervalThe 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 Daemon
Rule ID | service_chronyd_or_ntpd_enabled |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
Identifiers and References | References: AU-8(1), CCI-000160, Req-10.4, 2.2.1.1, 3.3.7 |
Description |
The $ sudo systemctl enable chronyd.serviceNote: The chronyd daemon is enabled by default.
The ntpd service can be enabled with the following command:
$ sudo systemctl enable ntpd.serviceNote: 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 |
Specify a Remote NTP Server
Rule ID | chronyd_or_ntpd_specify_remote_server |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | medium |
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
server ntpserverThis 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 Servers
Rule ID | chronyd_or_ntpd_specify_multiple_servers |
Result | notapplicable |
Time | 2018-05-19T02:19:05 |
Severity | low |
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
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. |