SRGs from General Purpose Operating System Security Requirements Guide Mapped to DISA STIG for Red Hat Enterprise Linux 8

CCI SRGID STIGID SRG Requirement Requirement Rules Mapped

CCI-000015 SRG-OS-000001-GPOS-00001 TBD - Assigned by DISA after STIG release The operating system must provide automated mechanisms for supporting account management functions. Enterprise environments make account management challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other errors. A comprehensive account management process that includes automation helps to ensure accounts designated as requiring attention are consistently and promptly addressed. Examples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended or terminated, or by disabling accounts located in non-centralized account stores such as multiple servers. This requirement applies to all account types, including individual/user, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service. The automated mechanisms may reside within the operating system itself or may be offered by other infrastructure providing automated account management capabilities. Automated mechanisms may be composed of differing technologies that, when placed together, contain an overall automated mechanism supporting an organization's automated account management requirements. Account management functions include: assigning group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include, for example: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; and using automated telephonic notification to report atypical system account usage.

CCI-000016

SRG-OS-000002-GPOS-00002

TBD - Assigned by DISA after STIG release

The operating system must automatically remove or disable temporary user accounts after 72 hours.

If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary accounts must be set upon account creation. Temporary accounts are established as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. If temporary accounts are used, the operating system must be configured to automatically terminate these types of accounts after a DoD-defined time period of 72 hours. To address access requirements, many operating systems may be integrated with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements.

Assign Expiration Date to Temporary Accounts

Temporary accounts are established as part of normal account activation procedures when there is a need for short-term accounts. In the event temporary accounts are required, configure the system to terminate them after a documented time period. For every temporary account, run the following command to set an expiration date on it, substituting USER and YYYY-MM-DD appropriately:

$ sudo chage -E YYYY-MM-DD USER

YYYY-MM-DD indicates the documented expiration date for the account. For U.S. Government systems, the operating system must be configured to automatically terminate these types of accounts after a period of 72 hours.

CCI-000018

SRG-OS-000004-GPOS-00004

TBD - Assigned by DISA after STIG release

The operating system must audit all account creations.

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to create an account. Auditing account creation actions provides logging that can be used for forensic purposes. To address access requirements, many operating systems may be integrated with enterprise level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.

Ensure auditd Collects System Administrator Actions - /etc/sudoers

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

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Record Events that Modify User/Group Information - /etc/group

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

-w /etc/group -p wa -k audit_rules_usergroup_modification

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

Record Events that Modify User/Group Information - /etc/gshadow

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/security/opasswd

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/shadow

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

CCI-000044

SRG-OS-000021-GPOS-00005

TBD - Assigned by DISA after STIG release

The operating system must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.

By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-force attacks, is reduced. Limits are imposed by locking the account.

Configure the Use of the pam_faillock.so Module in the /etc/pam.d/password-auth File.

The pam_faillock.so module must be loaded in preauth in /etc/pam.d/password-auth.

Configure the Use of the pam_faillock.so Module in the /etc/pam.d/system-auth File.

The pam_faillock.so module must be loaded in preauth in /etc/pam.d/system-auth.

An SELinux Context must be configured for the pam_faillock.so records directory The dir configuration option in PAM pam_faillock.so module defines where the lockout records is stored. The configured directory must have the correct SELinux context.

Account Lockouts Must Be Logged

PAM faillock locks an account due to excessive password failures, this event must be logged.

Lock Accounts After Failed Password Attempts This rule configures the system to lock out accounts after a number of incorrect login attempts using pam_faillock.so. pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. Ensure that the file /etc/security/faillock.conf contains the following entry: deny = <count> Where count should be less than or equal to _{and greater than 0.

In order to avoid errors when manually editing these files, it is
recommended to use the appropriate tools, such as authselect or authconfig,
depending on the OS version.}

Configure the root Account for Failed Password Attempts This rule configures the system to lock out the root account after a number of incorrect login attempts using pam_faillock.so. pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. In order to avoid errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version.

Lock Accounts Must Persist

This rule ensures that the system lock out accounts using pam_faillock.so persist after system reboot. From "pam_faillock" man pages:

Note that the default directory that "pam_faillock" uses is usually cleared on system
boot so the access will be reenabled after system reboot. If that is undesirable, a different
tally directory must be set with the "dir" option.

pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. In order to avoid errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version. The chosen profile expects the directory to be .

Set Interval For Counting Failed Password Attempts Utilizing pam_faillock.so, the fail_interval directive configures the system to lock out an account after a number of incorrect login attempts within a specified time period. Ensure that the file /etc/security/faillock.conf contains the following entry: fail_interval = <interval-in-seconds> where interval-in-seconds is or greater. In order to avoid errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version.

Do Not Show System Messages When Unsuccessful Logon Attempts Occur This rule ensures the system prevents informative messages from being presented to the user pertaining to logon information after a number of incorrect login attempts using pam_faillock.so. pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. In order to avoid errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version.

Set Lockout Time for Failed Password Attempts This rule configures the system to lock out accounts during a specified time period after a number of incorrect login attempts using pam_faillock.so. Ensure that the file /etc/security/faillock.conf contains the following entry: unlock_time=<interval-in-seconds> where interval-in-seconds is or greater. pam_faillock.so module requires multiple entries in pam files. These entries must be carefully defined to work as expected. In order to avoid any errors when manually editing these files, it is recommended to use the appropriate tools, such as authselect or authconfig, depending on the OS version. If unlock_time is set to 0, manual intervention by an administrator is required to unlock a user. This should be done using the faillock tool.

CCI-000048

SRG-OS-000023-GPOS-00006

TBD - Assigned by DISA after STIG release

The operating system must display the Standard Mandatory DoD Notice and Consent Banner before granting local or remote access to the system.

Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for operating systems that can accommodate banners of 1300 characters: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've readconsent to terms in IS user agreem't."

Modify the System Login Banner To configure the system login banner edit /etc/issue. Replace the default text with a message compliant with the local site policy or a legal disclaimer. The DoD required text is either:

You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.

OR:

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

Enable GNOME3 Login Warning Banner

In the default graphical environment, displaying a login warning banner in the GNOME Display Manager's login screen can be enabled on the login screen by setting banner-message-enable to true.

To enable, add or edit banner-message-enable to /etc/dconf/db/gdm.d/00-security-settings. For example:

[org/gnome/login-screen]
banner-message-enable=true

Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example:

/org/gnome/login-screen/banner-message-enable

After the settings have been set, run dconf update. The banner text must also be set.

Set the GNOME3 Login Warning Banner Text

In the default graphical environment, configuring the login warning banner text in the GNOME Display Manager's login screen can be configured on the login screen by setting banner-message-text to 'APPROVED_BANNER' where APPROVED_BANNER is the approved banner for your environment.

To enable, add or edit banner-message-text to /etc/dconf/db/gdm.d/00-security-settings. For example:

[org/gnome/login-screen]
banner-message-text='APPROVED_BANNER'

Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example:

/org/gnome/login-screen/banner-message-text

After the settings have been set, run dconf update. When entering a warning banner that spans several lines, remember to begin and end the string with ' and use \n for new lines.

Enable SSH Warning Banner

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

Banner /etc/issue

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

CCI-000050 SRG-OS-000024-GPOS-00007 TBD - Assigned by DISA after STIG release The operating system must display the Standard Mandatory DoD Notice and Consent Banner until users acknowledge the usage conditions and take explicit actions to log on for further access. The banner must be acknowledged by the user prior to allowing the user access to the operating system. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoD will not be in compliance with system use notifications required by law. To establish acceptance of the application usage policy, a click-through banner at system logon is required. The system must prevent further activity until the user executes a positive action to manifest agreement by clicking on a box indicating "OK".

CCI-000054

SRG-OS-000027-GPOS-00008

TBD - Assigned by DISA after STIG release

The operating system must limit the number of concurrent sessions to ten for all accounts and/or account types.

Operating system management includes the ability to control the number of users and user sessions that utilize an operating system. Limiting the number of allowed users and sessions per user is helpful in reducing the risks related to DoS attacks. This requirement addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions should be defined based upon mission needs and the operational environment for each system.

Limit the Number of Concurrent Login Sessions Allowed Per User

Limiting the number of allowed users and sessions per user can limit risks related to Denial of Service attacks. This addresses concurrent sessions for a single account and does not address concurrent sessions by a single user via multiple accounts. To set the number of concurrent sessions per user add the following line in /etc/security/limits.conf or a file under /etc/security/limits.d/:

* hard maxlogins

CCI-000056

SRG-OS-000028-GPOS-00009

TBD - Assigned by DISA after STIG release

The operating system must retain a users session lock until that user reestablishes access using established identification and authentication procedures.

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 log out because of the temporary nature of the absence. The session lock is implemented at the point where session activity can be determined. Regardless of where the session lock is determined and implemented, once invoked, the session lock shall remain in place until the user re-authenticates. No other activity aside from re-authentication shall unlock the system.

Enable the GNOME3 Screen Locking On Smartcard Removal

In the default graphical environment, screen locking on smartcard removal can be enabled by setting removal-action to 'lock-screen'.

To enable, add or edit removal-action to /etc/dconf/db/local.d/00-security-settings. For example:

[org/gnome/settings-daemon/peripherals/smartcard]
removal-action='lock-screen'

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/settings-daemon/peripherals/smartcard/removal-action

After the settings have been set, run dconf update.

Enable GNOME3 Screensaver Lock After Idle Period

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

[org/gnome/desktop/screensaver]
lock-enabled=true

Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example:

/org/gnome/desktop/screensaver/lock-enabled

After the settings have been set, run dconf update.

Ensure Users Cannot Change GNOME3 Screensaver Lock After Idle Period

If not already configured, ensure that users cannot change GNOME3 screensaver lock settings by adding

/org/gnome/desktop/screensaver/lock-enabled

to /etc/dconf/db/local.d/locks/00-security-settings. For example:

/org/gnome/desktop/screensaver/lock-enabled

After the settings have been set, run dconf update.

CCI-000057

SRG-OS-000029-GPOS-00010

TBD - Assigned by DISA after STIG release

The operating system must initiate a session lock after a 15-minute period of inactivity for all connection types.

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 log out 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, operating systems need to be able to identify when a user's session has idled and take action to initiate the session lock. The session lock is implemented at the point where session activity can be determined and/or controlled.

Set GNOME3 Screensaver Inactivity Timeout

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

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

[org/gnome/desktop/session]
idle-delay=uint32 900

Set GNOME3 Screensaver Lock Delay After Activation Period

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

[org/gnome/desktop/screensaver]
lock-delay=uint32

After the settings have been set, run dconf update.

Ensure Users Cannot Change GNOME3 Screensaver Settings

If not already configured, ensure that users cannot change GNOME3 screensaver lock settings by adding /org/gnome/desktop/screensaver/lock-delay to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example:

/org/gnome/desktop/screensaver/lock-delay

After the settings have been set, run dconf update.

Ensure Users Cannot Change GNOME3 Session Idle Settings

If not already configured, ensure that users cannot change GNOME3 session idle settings by adding /org/gnome/desktop/session/idle-delay to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example:

/org/gnome/desktop/session/idle-delay

After the settings have been set, run dconf update.

CCI-000057

SRG-OS-000030-GPOS-00011

TBD - Assigned by DISA after STIG release

The operating system must provide the capability for users to directly initiate a session lock for all connection types.

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 log out because of the temporary nature of the absence. The session lock is implemented at the point where session activity can be determined. Rather than be forced to wait for a period of time to expire before the user session can be locked, operating systems need to provide users with the ability to manually invoke a session lock so users may secure their session should the need arise for them to temporarily vacate the immediate physical vicinity.

Enable the GNOME3 Screen Locking On Smartcard Removal

[org/gnome/settings-daemon/peripherals/smartcard]
removal-action='lock-screen'

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/settings-daemon/peripherals/smartcard/removal-action

After the settings have been set, run dconf update.

Enable GNOME3 Screensaver Lock After Idle Period

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

[org/gnome/desktop/screensaver]
lock-enabled=true

Once the settings have been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example:

/org/gnome/desktop/screensaver/lock-enabled

After the settings have been set, run dconf update.

Ensure Users Cannot Change GNOME3 Screensaver Lock After Idle Period

If not already configured, ensure that users cannot change GNOME3 screensaver lock settings by adding

/org/gnome/desktop/screensaver/lock-enabled

to /etc/dconf/db/local.d/locks/00-security-settings. For example:

/org/gnome/desktop/screensaver/lock-enabled

After the settings have been set, run dconf update.

CCI-000060

SRG-OS-000031-GPOS-00012

TBD - Assigned by DISA after STIG release

The operating system must conceal, via the session lock, information previously visible on the display with a publicly viewable image.

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 log out because of the temporary nature of the absence. The session lock is implemented at the point where session activity can be determined. The operating system session lock event must include an obfuscation of the display screen so as to prevent other users from reading what was previously displayed. Publicly viewable images can include static or dynamic images, for example, patterns used with screen savers, photographic images, solid colors, a clock, a battery life indicator, or a blank screen, with the additional caveat that none of the images convey sensitive information.

Set GNOME3 Screensaver Inactivity Timeout

[org/gnome/desktop/session]
idle-delay=uint32 900

Set GNOME3 Screensaver Lock Delay After Activation Period

[org/gnome/desktop/screensaver]
lock-delay=uint32

After the settings have been set, run dconf update.

Ensure Users Cannot Change GNOME3 Screensaver Settings

/org/gnome/desktop/screensaver/lock-delay

After the settings have been set, run dconf update.

Ensure Users Cannot Change GNOME3 Session Idle Settings

/org/gnome/desktop/session/idle-delay

After the settings have been set, run dconf update.

CCI-000067

SRG-OS-000032-GPOS-00013

TBD - Assigned by DISA after STIG release

The operating system must monitor remote access methods.

Remote access services, such as those providing remote access to network devices and information systems, which lack automated monitoring capabilities, increase risk and make remote user access management difficult at best. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Automated monitoring of remote access sessions allows organizations to detect cyber attacks and also ensure ongoing compliance with remote access policies by auditing connection activities of remote access capabilities, such as Remote Desktop Protocol (RDP), on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).

Ensure remote access methods are monitored in Rsyslog Logging of remote access methods must be implemented to help identify cyber attacks and ensure ongoing compliance with remote access policies are being audited and upheld. An examples of a remote access method is the use of the Remote Desktop Protocol (RDP) from an external, non-organization controlled network. The /etc/rsyslog.conf or /etc/rsyslog.d/*.conf file should contain a match for the following selectors: auth.*, authpriv.*, and daemon.*. If not, use the following as an example configuration: auth.*;authpriv.* /var/log/secure daemon.* /var/log/messages

CCI-000068

SRG-OS-000033-GPOS-00014

TBD - Assigned by DISA after STIG release

The operating system must implement DoD-approved encryption to protect the confidentiality of remote access sessions.

Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Encryption provides a means to secure the remote connection to prevent unauthorized access to the data traversing the remote access connection (e.g., RDP), thereby providing a degree of confidentiality. The encryption strength of a mechanism is selected based on the security categorization of the information.

Configure Libreswan to use System Crypto Policy Crypto Policies provide a centralized control over crypto algorithms usage of many packages. Libreswan is supported by system crypto policy, but the Libreswan configuration may be set up to ignore it. To check that Crypto Policies settings are configured correctly, ensure that the /etc/ipsec.conf includes the appropriate configuration file. In /etc/ipsec.conf, make sure that the following line is not commented out or superseded by later includes: include /etc/crypto-policies/back-ends/libreswan.config

Configure SSH Client to Use FIPS 140-2 Validated Ciphers: openssh.config

Crypto Policies provide a centralized control over crypto algorithms usage of many packages. OpenSSH is supported by system crypto policy, but the OpenSSH configuration may be set up incorrectly. To check that Crypto Policies settings for ciphers are configured correctly, ensure that /etc/crypto-policies/back-ends/openssh.config contains the following line and is not commented out:

Ciphers

Force frequent session key renegotiation

The RekeyLimit parameter specifies how often the session key of the is renegotiated, both in terms of amount of data that may be transmitted and the time elapsed.
To decrease the default limits, add or correct the following line in /etc/ssh/sshd_config:

RekeyLimit

Set kernel parameter 'crypto.fips_enabled' to 1

System running in FIPS mode is indicated by kernel parameter 'crypto.fips_enabled'. This parameter should be set to 1 in FIPS mode. To enable FIPS mode, run the following command:

fips-mode-setup --enable

To enable strict FIPS compliance, the fips=1 kernel option needs to be added to the kernel boot parameters during system installation so key generation is done with FIPS-approved algorithms and continuous monitoring tests in place.

CCI-000130

SRG-OS-000037-GPOS-00015

TBD - Assigned by DISA after STIG release

The operating system must produce audit records containing information to establish what type of events occurred.

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. Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Associating event types with detected events in the operating system audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured operating system.

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

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

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

Record Any Attempts to Run chacl

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

-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run chcon

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

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run semanage

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

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setfacl

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

-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setfiles

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

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setsebool

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

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects File Deletion Events by User - rename

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

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system:

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - renameat

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - rmdir

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlink

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlinkat

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects Information on Kernel Module Unloading - delete_module

To capture kernel module unloading events, use following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S delete_module -F auid>=1000 -F auid!=unset -F key=modules

Place to add the line depends on a way auditd daemon is configured. If it is configured to use the augenrules program (the default), add the line to a file with suffix .rules in the directory /etc/audit/rules.d. If the auditd daemon is configured to use the auditctl utility, add the line to file /etc/audit/audit.rules.

Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module

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

-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system:

-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on Kernel Module Loading - init_module

To capture kernel module loading events, use following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S init_module -F auid>=1000 -F auid!=unset -F key=modules

Record Attempts to Alter Logon and Logout Events - lastlog

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

-w /var/log/lastlog -p wa -k logins

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:

-w /var/log/lastlog -p wa -k logins

Ensure auditd Collects Information on Exporting to Media (successful)

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

-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export

-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export

Ensure auditd Collects Information on the Use of Privileged Commands - chage

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

-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - chsh

-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - crontab

-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - gpasswd

-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - kmod

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - mount

-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - newgrp

-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - pam_timestamp_check

-a always,exit -F path=/usr/sbin/pam_timestamp_check
-F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/pam_timestamp_check
-F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - passwd

-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - postdrop

-a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - postqueue

-a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run ssh-agent

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

-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-agent

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-agent

Ensure auditd Collects Information on the Use of Privileged Commands - ssh-keysign

-a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - su

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - sudo

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - umount

-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - unix_chkpwd

-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - unix_update

-a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - userhelper

-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - usermod

-a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects System Administrator Actions - /etc/sudoers

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Record Unsuccessful Access Attempts to Files - creat

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

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - ftruncate

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open_by_handle_at

-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - openat

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - truncate

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Events that Modify User/Group Information - /etc/group

-w /etc/group -p wa -k audit_rules_usergroup_modification

-w /etc/group -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/gshadow

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/security/opasswd

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/shadow

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

Enable Auditing for Processes Which Start Prior to the Audit Daemon

To ensure all processes can be audited, even those which start prior to the audit daemon, add the argument audit=1 to the default GRUB 2 command line for the Linux operating system. To ensure that audit=1 is added as a kernel command line argument to newly installed kernels, add audit=1 to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:

GRUB_CMDLINE_LINUX="... audit=1 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="audit=1"

Extend Audit Backlog Limit for the Audit Daemon

To improve the kernel capacity to queue all log events, even those which occurred prior to the audit daemon, add the argument audit_backlog_limit=8192 to the default GRUB 2 command line for the Linux operating system. To ensure that audit_backlog_limit=8192 is added as a kernel command line argument to newly installed kernels, add audit_backlog_limit=8192 to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:

GRUB_CMDLINE_LINUX="... audit_backlog_limit=8192 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="audit_backlog_limit=8192"

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

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

$ sudo systemctl enable auditd.service

CCI-000131

SRG-OS-000038-GPOS-00016

TBD - Assigned by DISA after STIG release

The operating system must produce audit records containing information to establish when (date and time) the events occurred.

Without establishing when events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. In order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know when events occurred (date and time). Associating event types with detected events in the operating system audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured operating system.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-000132

SRG-OS-000039-GPOS-00017

TBD - Assigned by DISA after STIG release

The operating system must produce audit records containing information to establish where the events occurred.

Without establishing where events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. In order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know where events occurred, such as operating system components, modules, device identifiers, node names, file names, and functionality. Associating information about where the event occurred within the operating system provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured operating system.

Set type of computer node name logging in audit logs To configure Audit daemon to use a unique identifier as computer node name in the audit events, set name_format to in /etc/audit/auditd.conf.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-000133

SRG-OS-000040-GPOS-00018

TBD - Assigned by DISA after STIG release

The operating system must produce audit records containing information to establish the source of the events.

Without establishing the source of the event, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. In addition to logging where events occur within the operating system, the operating system must also generate audit records that identify sources of events. Sources of operating system events include, but are not limited to, processes and services. In order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know the source of the event.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-000134

SRG-OS-000041-GPOS-00019

TBD - Assigned by DISA after STIG release

The operating system must produce audit records containing information to establish the outcome of the events.

Without information about the outcome of events, security personnel cannot make an accurate assessment as to whether an attack was successful or if changes were made to the security state of the system. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-000135

SRG-OS-000042-GPOS-00020

TBD - Assigned by DISA after STIG release

The operating system must generate audit records containing the full-text recording of privileged commands.

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information. At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

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

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

Record Any Attempts to Run chacl

-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run chcon

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run semanage

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setfacl

-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setfiles

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setsebool

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects File Deletion Events by User - rename

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - renameat

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - rmdir

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlink

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlinkat

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects Information on Kernel Module Unloading - delete_module

To capture kernel module unloading events, use following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S delete_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module

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

-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules

-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on Kernel Module Loading - init_module

To capture kernel module loading events, use following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S init_module -F auid>=1000 -F auid!=unset -F key=modules

Record Attempts to Alter Logon and Logout Events - lastlog

-w /var/log/lastlog -p wa -k logins

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:

-w /var/log/lastlog -p wa -k logins

Ensure auditd Collects Information on Exporting to Media (successful)

-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export

-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export

Ensure auditd Collects Information on the Use of Privileged Commands - chage

-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - chsh

-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - crontab

-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - gpasswd

-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - kmod

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - mount

-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - newgrp

-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - pam_timestamp_check

-a always,exit -F path=/usr/sbin/pam_timestamp_check
-F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/pam_timestamp_check
-F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - passwd

-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - postdrop

-a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - postqueue

-a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run ssh-agent

-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-agent

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-agent

Ensure auditd Collects Information on the Use of Privileged Commands - ssh-keysign

-a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - su

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - sudo

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - umount

-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - unix_chkpwd

-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - unix_update

-a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - userhelper

-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - usermod

-a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects System Administrator Actions - /etc/sudoers

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Record Unsuccessful Access Attempts to Files - creat

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - ftruncate

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open_by_handle_at

-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - openat

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - truncate

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Events that Modify User/Group Information - /etc/group

-w /etc/group -p wa -k audit_rules_usergroup_modification

-w /etc/group -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/gshadow

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/security/opasswd

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/shadow

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

Enable Auditing for Processes Which Start Prior to the Audit Daemon

GRUB_CMDLINE_LINUX="... audit=1 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="audit=1"

Extend Audit Backlog Limit for the Audit Daemon

GRUB_CMDLINE_LINUX="... audit_backlog_limit=8192 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="audit_backlog_limit=8192"

CCI-000135

SRG-OS-000042-GPOS-00021

TBD - Assigned by DISA after STIG release

The operating system must produce audit records containing the individual identities of group account users.

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information. At a minimum, the organization must audit the individual identities of group users. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the actual account involved in the activity.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-000139

SRG-OS-000046-GPOS-00022

TBD - Assigned by DISA after STIG release

The operating system must alert the ISSO and SA (at a minimum) in the event of an audit processing failure.

It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.

Configure auditd mail_acct Action on Low Disk Space

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

action_mail_acct =

The Postfix package is installed

A mail server is required for sending emails. The postfix package can be installed with the following command:

$ sudo yum install postfix

Configure System to Forward All Mail From Postmaster to The Root Account

Verify the administrators are notified in the event of an audit processing failure. Check that the "/etc/aliases" file has a defined value for "root".

$ sudo grep "postmaster:\s*root$" /etc/aliases

postmaster: root

CCI-000140

SRG-OS-000047-GPOS-00023

TBD - Assigned by DISA after STIG release

The operating system must shut down by default upon audit failure (unless availability is an overriding concern).

It is critical that when the operating system is at risk of failing to process audit logs as required, it takes action to mitigate the failure. Audit processing failures include: software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode. When availability is an overriding concern, other approved actions in response to an audit failure are as follows: 1) If the failure was caused by the lack of audit record storage capacity, the operating system must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner. 2) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the operating system must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.

Configure auditd Disk Error Action on Disk Error

The auditd service can be configured to take an action when there is a disk error. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting ACTION appropriately:

disk_error_action = ACTION

Set this value to single to cause the system to switch to single-user mode for corrective action. Acceptable values also include syslog, exec, single, 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.

Configure auditd Disk Full Action when Disk Space Is Full

The auditd service can be configured to take an action when disk space is running low but prior to running out of space completely. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting ACTION appropriately:

disk_full_action = ACTION

CCI-000154

SRG-OS-000051-GPOS-00024

TBD - Assigned by DISA after STIG release

The operating system must provide the capability to centrally review and analyze audit records from multiple components within the system.

Successful incident response and auditing relies on timely, accurate system information and analysis in order to allow the organization to identify and respond to potential incidents in a proficient manner. If the operating system does not provide the ability to centrally review the operating system logs, forensic analysis is negatively impacted. Segregation of logging data to multiple disparate computer systems is counterproductive and makes log analysis and log event alarming difficult to implement and manage, particularly when the system has multiple logging components writing to different locations or systems. To support the centralized capability, the operating system must be able to provide the information in a format that can be extracted and used, allowing the application performing the centralization of the log records to meet this requirement.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Ensure rsyslog is Installed

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

 $ sudo yum install rsyslog

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-000158

SRG-OS-000054-GPOS-00025

TBD - Assigned by DISA after STIG release

The operating system must provide the capability to filter audit records for events of interest based upon all audit fields within audit records.

The ability to specify the event criteria that are of interest provides the individuals reviewing the logs with the ability to quickly isolate and identify these events without having to review entries that are of little or no consequence to the investigation. Without this capability, forensic investigations are impeded. Events of interest can be identified by the content of specific audit record fields, including, for example, identities of individuals, event types, event locations, event times, event dates, system resources involved, IP addresses involved, or information objects accessed. Organizations may define audit event criteria to any degree of granularity required, for example, locations selectable by general networking location (e.g., by network or subnetwork) or selectable by specific information system component. This requires operating systems to provide the capability to customize audit record reports based on all available criteria.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-000159 SRG-OS-000055-GPOS-00026 TBD - Assigned by DISA after STIG release The operating system must use internal system clocks to generate time stamps for audit records. Without an internal clock used as the reference for the time stored on each event to provide a trusted common reference for the time, forensic analysis would be impeded. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. If the internal clock is not used, the system may not be able to provide time stamps for log messages. Additionally, externally generated time stamps may not be accurate.

CCI-000162

SRG-OS-000057-GPOS-00027

TBD - Assigned by DISA after STIG release

The operating system must protect audit information from unauthorized read access.

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity.

Make the auditd Configuration Immutable

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

-e 2

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file in order to make the auditd configuration immutable:

-e 2

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

Configure immutable Audit login UIDs

Configure kernel to prevent modification of login UIDs once they are set. Changing login UIDs while this configuration is enforced requires special capabilities which are not available to unprivileged users. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d in order to make login UIDs immutable:

--loginuid-immutable

--loginuid-immutable

System Audit Directories Must Be Group Owned By Root

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

/var/log/audit/

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

$ sudo chgrp root /var/log/audit

If log_group in /etc/audit/auditd.conf is set to a group other than the root group account, change the group ownership of the audit directories to this specific group.

System Audit Directories Must Be Owned By Root

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

/var/log/audit/

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

$ sudo chown root /var/log/audit

System Audit Logs Must Have Mode 0750 or Less Permissive

Verify the audit log directories have a mode of "0700" or less permissive by first determining where the audit logs are stored with the following command:

$ sudo grep -iw log_file /etc/audit/auditd.conf

log_file = /var/log/audit/audit.log

Configure the audit log directory to be protected from unauthorized read access by setting the correct permissive mode with the following command:

$ sudo chmod 0700 audit_log_directory

By default, audit_log_directory is "/var/log/audit".

System Audit Logs Must Be Group Owned By Root

All audit logs must be group owned by root user. The path for audit log can be configured via log_file parameter in

/etc/audit/auditd.conf

or, by default, the path for audit log is

/var/log/audit/

. To properly set the group owner of /var/log/audit/*, run the command:

$ sudo chgrp root /var/log/audit/*

If log_group in /etc/audit/auditd.conf is set to a group other than the root group account, change the group ownership of the audit logs to this specific group.

System Audit Logs Must Be Owned By Root

All audit logs must be owned by root user. The path for audit log can be configured via log_file parameter in

/etc/audit/auditd.conf

or by default, the path for audit log is

/var/log/audit/

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

$ sudo chown root /var/log/audit/*

System Audit Logs Must Have Mode 0640 or Less Permissive

Determine where the audit logs are stored with the following command:

$ sudo grep -iw log_file /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log

Configure the audit log to be protected from unauthorized read access by setting the correct permissive mode with the following command:

$ sudo chmod 0600 audit_log_file

By default, audit_log_file is "/var/log/audit/audit.log".

CCI-000163

SRG-OS-000058-GPOS-00028

TBD - Assigned by DISA after STIG release

The operating system must protect audit information from unauthorized modification.

If audit information were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit information, the operating system must protect audit information from unauthorized modification. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit information system activity.

Make the auditd Configuration Immutable

-e 2

-e 2

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

Configure immutable Audit login UIDs

--loginuid-immutable

--loginuid-immutable

System Audit Directories Must Be Group Owned By Root

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

/var/log/audit/

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

$ sudo chgrp root /var/log/audit

If log_group in /etc/audit/auditd.conf is set to a group other than the root group account, change the group ownership of the audit directories to this specific group.

System Audit Directories Must Be Owned By Root

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

/var/log/audit/

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

$ sudo chown root /var/log/audit

System Audit Logs Must Have Mode 0750 or Less Permissive

Verify the audit log directories have a mode of "0700" or less permissive by first determining where the audit logs are stored with the following command:

$ sudo grep -iw log_file /etc/audit/auditd.conf

log_file = /var/log/audit/audit.log

Configure the audit log directory to be protected from unauthorized read access by setting the correct permissive mode with the following command:

$ sudo chmod 0700 audit_log_directory

By default, audit_log_directory is "/var/log/audit".

System Audit Logs Must Be Group Owned By Root

All audit logs must be group owned by root user. The path for audit log can be configured via log_file parameter in

/etc/audit/auditd.conf

or, by default, the path for audit log is

/var/log/audit/

. To properly set the group owner of /var/log/audit/*, run the command:

$ sudo chgrp root /var/log/audit/*

If log_group in /etc/audit/auditd.conf is set to a group other than the root group account, change the group ownership of the audit logs to this specific group.

System Audit Logs Must Be Owned By Root

All audit logs must be owned by root user. The path for audit log can be configured via log_file parameter in

/etc/audit/auditd.conf

or by default, the path for audit log is

/var/log/audit/

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

$ sudo chown root /var/log/audit/*

System Audit Logs Must Have Mode 0640 or Less Permissive

Determine where the audit logs are stored with the following command:

$ sudo grep -iw log_file /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log

Configure the audit log to be protected from unauthorized read access by setting the correct permissive mode with the following command:

$ sudo chmod 0600 audit_log_file

By default, audit_log_file is "/var/log/audit/audit.log".

CCI-000164

SRG-OS-000059-GPOS-00029

TBD - Assigned by DISA after STIG release

The operating system must protect audit information from unauthorized deletion.

If audit information were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit information, the operating system must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit information system activity.

Make the auditd Configuration Immutable

-e 2

-e 2

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

Configure immutable Audit login UIDs

--loginuid-immutable

--loginuid-immutable

System Audit Directories Must Be Group Owned By Root

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

/var/log/audit/

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

$ sudo chgrp root /var/log/audit

If log_group in /etc/audit/auditd.conf is set to a group other than the root group account, change the group ownership of the audit directories to this specific group.

System Audit Directories Must Be Owned By Root

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

/var/log/audit/

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

$ sudo chown root /var/log/audit

System Audit Logs Must Have Mode 0750 or Less Permissive

Verify the audit log directories have a mode of "0700" or less permissive by first determining where the audit logs are stored with the following command:

$ sudo grep -iw log_file /etc/audit/auditd.conf

log_file = /var/log/audit/audit.log

Configure the audit log directory to be protected from unauthorized read access by setting the correct permissive mode with the following command:

$ sudo chmod 0700 audit_log_directory

By default, audit_log_directory is "/var/log/audit".

System Audit Logs Must Be Group Owned By Root

All audit logs must be group owned by root user. The path for audit log can be configured via log_file parameter in

/etc/audit/auditd.conf

or, by default, the path for audit log is

/var/log/audit/

. To properly set the group owner of /var/log/audit/*, run the command:

$ sudo chgrp root /var/log/audit/*

If log_group in /etc/audit/auditd.conf is set to a group other than the root group account, change the group ownership of the audit logs to this specific group.

System Audit Logs Must Be Owned By Root

All audit logs must be owned by root user. The path for audit log can be configured via log_file parameter in

/etc/audit/auditd.conf

or by default, the path for audit log is

/var/log/audit/

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

$ sudo chown root /var/log/audit/*

System Audit Logs Must Have Mode 0640 or Less Permissive

Determine where the audit logs are stored with the following command:

$ sudo grep -iw log_file /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log

Configure the audit log to be protected from unauthorized read access by setting the correct permissive mode with the following command:

$ sudo chmod 0600 audit_log_file

By default, audit_log_file is "/var/log/audit/audit.log".

CCI-000169

SRG-OS-000062-GPOS-00031

TBD - Assigned by DISA after STIG release

The operating system must provide audit record generation capability for DoD-defined auditable events for all operating system components.

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DoD has defined the list of events for which the operating system will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions.

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

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

Record Any Attempts to Run chacl

-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run chcon

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run semanage

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setfacl

-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setfiles

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setsebool

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects File Deletion Events by User - rename

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - renameat

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - rmdir

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlink

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlinkat

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects Information on Kernel Module Unloading - delete_module

To capture kernel module unloading events, use following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S delete_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module

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

-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules

-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on Kernel Module Loading - init_module

To capture kernel module loading events, use following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S init_module -F auid>=1000 -F auid!=unset -F key=modules

Record Attempts to Alter Logon and Logout Events - lastlog

-w /var/log/lastlog -p wa -k logins

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:

-w /var/log/lastlog -p wa -k logins

Ensure auditd Collects Information on Exporting to Media (successful)

-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export

-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export

Ensure auditd Collects Information on the Use of Privileged Commands - chage

-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - chsh

-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - crontab

-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - gpasswd

-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - kmod

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - mount

-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - newgrp

-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - pam_timestamp_check

-a always,exit -F path=/usr/sbin/pam_timestamp_check
-F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/pam_timestamp_check
-F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - passwd

-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - postdrop

-a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - postqueue

-a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run ssh-agent

-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-agent

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-agent

Ensure auditd Collects Information on the Use of Privileged Commands - ssh-keysign

-a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - su

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - sudo

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - umount

-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - unix_chkpwd

-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - unix_update

-a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - userhelper

-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - usermod

-a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects System Administrator Actions - /etc/sudoers

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Record Unsuccessful Access Attempts to Files - creat

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - ftruncate

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open_by_handle_at

-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - openat

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - truncate

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Events that Modify User/Group Information - /etc/group

-w /etc/group -p wa -k audit_rules_usergroup_modification

-w /etc/group -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/gshadow

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/security/opasswd

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/shadow

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

Include Local Events in Audit Logs To configure Audit daemon to include local events in Audit logs, set local_events to yes in /etc/audit/auditd.conf. This is the default setting.

Log USBGuard daemon audit events using Linux Audit To configure USBGuard daemon to log via Linux Audit (as opposed directly to a file), AuditBackend option in /etc/usbguard/usbguard-daemon.conf needs to be set to LinuxAudit.

Enable Auditing for Processes Which Start Prior to the Audit Daemon

GRUB_CMDLINE_LINUX="... audit=1 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="audit=1"

Extend Audit Backlog Limit for the Audit Daemon

GRUB_CMDLINE_LINUX="... audit_backlog_limit=8192 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="audit_backlog_limit=8192"

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-000171

SRG-OS-000063-GPOS-00032

TBD - Assigned by DISA after STIG release

The operating system must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.

Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Verify Permissions on /etc/audit/auditd.conf

To properly set the permissions of /etc/audit/auditd.conf, run the command:

$ sudo chmod 0640 /etc/audit/auditd.conf

Verify Permissions on /etc/audit/rules.d/*.rules

To properly set the permissions of /etc/audit/rules.d/*.rules, run the command:

$ sudo chmod 0640 /etc/audit/rules.d/*.rules

CCI-000172

SRG-OS-000064-GPOS-00033

TBD - Assigned by DISA after STIG release

The operating system must generate audit records when successful/unsuccessful attempts to access privileges occur.

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).

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

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

Ensure auditd Collects Information on the Use of Privileged Commands - unix_update

-a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Unsuccessful Access Attempts to Files - creat

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - ftruncate

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open_by_handle_at

-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - openat

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - truncate

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

CCI-000185

SRG-OS-000066-GPOS-00034

TBD - Assigned by DISA after STIG release

The operating system, for PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.

Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted. A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement.

SSSD Has a Correct Trust Anchor

SSSD must have acceptable trust anchor present.

CCI-000186

SRG-OS-000067-GPOS-00035

TBD - Assigned by DISA after STIG release

The operating system, for PKI-based authentication, must enforce authorized access to the corresponding private key.

If the private key is discovered, an attacker can use the key to authenticate as an authorized user and gain access to the network infrastructure. The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and non-repudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys.

Verify the SSH Private Key Files Have a Passcode

When creating SSH key pairs, always use a passcode.
You can create such keys with the following command:

$ sudo ssh-keygen -n [passphrase]

Red Hat Enterprise Linux 8, for certificate-based authentication, must enforce authorized access to the corresponding private key.

CCI-000187

SRG-OS-000068-GPOS-00036

TBD - Assigned by DISA after STIG release

The operating system must map the authenticated identity to the user or group account for PKI-based authentication.

Without mapping the certificate used to authenticate to the user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis.

Enable Certmap in SSSD

SSSD should be configured to verify the certificate of the user or group. To set this up ensure that section like certmap/testing.test/rule_name is setup in /etc/sssd/sssd.conf. For example

[certmap/testing.test/rule_name]
matchrule =<SAN>.*EDIPI@mil
maprule = (userCertificate;binary={cert!bin})
domains = testing.test

CCI-004066

SRG-OS-000069-GPOS-00037

TBD - Assigned by DISA after STIG release

The operating system must enforce password complexity by requiring that at least one uppercase character be used.

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Ensure PAM password complexity module is enabled in password-auth To enable PAM password complexity in password-auth file: Edit the password section in /etc/pam.d/password-auth to show password requisite pam_pwquality.so.

Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session To configure the number of retry prompts that are permitted per-session: Edit the /etc/security/pwquality.conf to include retry=, or a lower value if site policy is more restrictive. The DoD requirement is a maximum of 3 prompts per session.

Ensure PAM Enforces Password Requirements - Minimum Uppercase Characters The pam_pwquality module's ucredit= parameter controls requirements for usage of uppercase letters in a password. When set to a negative number, any password will be required to contain that many uppercase characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each uppercase character. Modify the ucredit setting in /etc/security/pwquality.conf to require the use of an uppercase character in passwords.

CCI-004066

SRG-OS-000070-GPOS-00038

TBD - Assigned by DISA after STIG release

The operating system must enforce password complexity by requiring that at least one lowercase character be used.

Ensure PAM Enforces Password Requirements - Minimum Lowercase Characters The pam_pwquality module's lcredit parameter controls requirements for usage of lowercase letters in a password. When set to a negative number, any password will be required to contain that many lowercase characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each lowercase character. Modify the lcredit setting in /etc/security/pwquality.conf to require the use of a lowercase character in passwords.

CCI-004066

SRG-OS-000071-GPOS-00039

TBD - Assigned by DISA after STIG release

The operating system must enforce password complexity by requiring that at least one numeric character be used.

Ensure PAM Enforces Password Requirements - Minimum Digit Characters The pam_pwquality module's dcredit parameter controls requirements for usage of digits in a password. When set to a negative number, any password will be required to contain that many digits. When set to a positive number, pam_pwquality will grant +1 additional length credit for each digit. Modify the dcredit setting in /etc/security/pwquality.conf to require the use of a digit in passwords.

CCI-004066

SRG-OS-000072-GPOS-00040

TBD - Assigned by DISA after STIG release

The operating system must require the change of at least 50 percent of the total number of characters when passwords are changed.

If the operating system allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks. The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different. If the password length is an odd number then number of changed characters must be rounded up. For example, a password length of 15 characters must require the change of at least eight characters.

Ensure PAM Enforces Password Requirements - Prevent the Use of Dictionary Words The pam_pwquality module's dictcheck check if passwords contains dictionary words. When dictcheck is set to 1 passwords will be checked for dictionary words.

Ensure PAM Enforces Password Requirements - Minimum Different Characters The pam_pwquality module's difok parameter sets the number of characters in a password that must not be present in and old password during a password change.

Modify the difok setting in /etc/security/pwquality.conf to equal _{to require differing characters
when changing passwords.}

Ensure PAM Enforces Password Requirements - Maximum Consecutive Repeating Characters from Same Character Class The pam_pwquality module's maxclassrepeat parameter controls requirements for consecutive repeating characters from the same character class. When set to a positive number, it will reject passwords which contain more than that number of consecutive characters from the same character class. Modify the maxclassrepeat setting in /etc/security/pwquality.conf to equal _{to prevent a run of (_{+ 1) or more identical characters.}}

Set Password Maximum Consecutive Repeating Characters The pam_pwquality module's maxrepeat parameter controls requirements for consecutive repeating characters. When set to a positive number, it will reject passwords which contain more than that number of consecutive characters. Modify the maxrepeat setting in /etc/security/pwquality.conf to equal _{to prevent a
run of (_{+ 1) or more identical characters.}}

Ensure PAM Enforces Password Requirements - Minimum Different Categories

The pam_pwquality module's minclass parameter controls requirements for usage of different character classes, or types, of character that must exist in a password before it is considered valid. For example, setting this value to three (3) requires that any password must have characters from at least three different categories in order to be approved. The default value is zero (0), meaning there are no required classes. There are four categories available:

* Upper-case characters
* Lower-case characters
* Digits
* Special characters (for example, punctuation)

Modify the minclass setting in /etc/security/pwquality.conf entry to require _{differing categories of characters when changing passwords.}

CCI-004062

SRG-OS-000073-GPOS-00041

TBD - Assigned by DISA after STIG release

The operating system must store only encrypted representations of passwords.

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.

Verify All Account Password Hashes are Shadowed with SHA512

Verify the operating system requires the shadow password suite configuration be set to encrypt interactive user passwords using a strong cryptographic hash. Check that the interactive user account passwords are using a strong password hash with the following command:

$ sudo cut -d: -f2 /etc/shadow
$6$kcOnRq/5$NUEYPuyL.wghQwWssXRcLRFiiru7f5JPV6GaJhNC2aK5F3PZpE/BCCtwrxRc/AInKMNX3CdMw11m9STiql12f/

Password hashes ! or * indicate inactive accounts not available for logon and are not evaluated. If any interactive user password hash does not begin with $6, this is a finding.

Set Password Hashing Algorithm in /etc/login.defs

In /etc/login.defs, add or update the following line to ensure the system will use _{as the hashing algorithm:
ENCRYPT_METHOD}

Set PAM''s Password Hashing Algorithm - password-auth

The PAM system service can be configured to only store encrypted representations of passwords. In /etc/pam.d/password-auth, the password section of the file controls which PAM modules to execute during a password change. Set the pam_unix.so module in the password section to include the option and no other hashing algorithms as shown below:

password    sufficient    pam_unix.so _{other arguments...}

This will help ensure that new passwords for local users will be stored using the _algorithm.

Set PAM''s Password Hashing Algorithm

The PAM system service can be configured to only store encrypted representations of passwords. In "/etc/pam.d/system-auth", the password section of the file controls which PAM modules to execute during a password change. Set the pam_unix.so module in the password section to include the option and no other hashing algorithms as shown below:

password    sufficient    pam_unix.so _{other arguments...}

This will help ensure that new passwords for local users will be stored using the _algorithm.

Set Password Hashing Rounds in /etc/login.defs

In /etc/login.defs, ensure SHA_CRYPT_MIN_ROUNDS and SHA_CRYPT_MAX_ROUNDS has the minimum value of 5000. For example:

SHA_CRYPT_MIN_ROUNDS 5000
SHA_CRYPT_MAX_ROUNDS 5000

Notice that if neither are set, they already have the default value of 5000. If either is set, they must have the minimum value of 5000.

CCI-000197

SRG-OS-000074-GPOS-00042

TBD - Assigned by DISA after STIG release

The operating system must transmit only encrypted representations of passwords.

Uninstall vsftpd Package

The vsftpd package can be removed with the following command:

 $ sudo yum erase vsftpd

CCI-004066

SRG-OS-000075-GPOS-00043

TBD - Assigned by DISA after STIG release

Operating systems must enforce 24 hours/1 day as the minimum password lifetime.

Enforcing a minimum password lifetime helps to prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.

Set Password Minimum Age

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

PASS_MIN_DAYS

A value of 1 day is considered sufficient for many environments. The DoD requirement is 1. The profile requirement is .

Set Existing Passwords Minimum Age

Configure non-compliant accounts to enforce a 24 hours/1 day minimum password lifetime by running the following command:

$ sudo chage -m 1 USER

CCI-004066

SRG-OS-000076-GPOS-00044

TBD - Assigned by DISA after STIG release

Operating systems must enforce a 60-day maximum password lifetime restriction.

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.

Set Password Maximum Age

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

PASS_MAX_DAYS

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

Set Existing Passwords Maximum Age

Configure non-compliant accounts to enforce a _{-day maximum password lifetime
restriction by running the following command:
$ sudo chage -M _USER}

CCI-004066

SRG-OS-000078-GPOS-00046

TBD - Assigned by DISA after STIG release

The operating system must enforce a minimum 15-character password length.

The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.

Set Password Minimum Length in login.defs

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

PASS_MIN_LEN

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

Ensure PAM Enforces Password Requirements - Minimum Length The pam_pwquality module's minlen parameter controls requirements for minimum characters required in a password. Add minlen= after pam_pwquality to set minimum password length requirements.

CCI-000206 SRG-OS-000079-GPOS-00047 TBD - Assigned by DISA after STIG release The operating system must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. To prevent the compromise of authentication information, such as passwords during the authentication process, the feedback from the operating system shall not provide any information allowing an unauthorized user to compromise the authentication mechanism. Obfuscation of user-provided information that is typed into the system is a method used when addressing this risk. For example, displaying asterisks when a user types in a password is an example of obscuring feedback of authentication information.

CCI-000213

SRG-OS-000080-GPOS-00048

TBD - Assigned by DISA after STIG release

The operating system must enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.

To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems (e.g., web servers and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include: identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include: access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system.

Set the Boot Loader Admin Username to a Non-Default Value

The grub2 boot loader should have a superuser account and password protection enabled to protect boot-time settings.

To maximize the protection, select a password-protected superuser account with unique name, and modify the /etc/grub.d/01_users configuration file to reflect the account name change.

Do not to use common administrator account names like root, admin, or administrator for the grub2 superuser account.

Change the superuser to a different username (The default is 'root').

$ sed -i 's/\(set superusers=\).*/\1"<unique user ID>"/g' /etc/grub.d/01_users

Once the superuser account has been added, update the grub.cfg file by running:

grubby --update-kernel=ALL --env=/boot/grub2/grubenv

Set Boot Loader Password in grub2

The grub2 boot loader should have a superuser account and password protection enabled to protect boot-time settings.

Since plaintext passwords are a security risk, generate a hash for the password by running the following command:

# grub2-setpassword

When prompted, enter the password that was selected.

Set the UEFI Boot Loader Admin Username to a Non-Default Value

The grub2 boot loader should have a superuser account and password protection enabled to protect boot-time settings.

To maximize the protection, select a password-protected superuser account with unique name, and modify the /etc/grub.d/01_users configuration file to reflect the account name change.

It is highly suggested not to use common administrator account names like root, admin, or administrator for the grub2 superuser account.

Change the superuser to a different username (The default is 'root').

$ sed -i 's/\(set superusers=\).*/\1"<unique user ID>"/g' /etc/grub.d/01_users

Once the superuser account has been added, update the grub.cfg file by running:

grubby --update-kernel=ALL --env=/boot/grub2/grubenv

Set the UEFI Boot Loader Password

# grub2-setpassword

When prompted, enter the password that was selected.

Require Authentication for Emergency Systemd Target Emergency mode is intended as a system recovery method, providing a single user root access to the system during a failed boot sequence.

By default, Emergency mode is protected by requiring a password and is set in /usr/lib/systemd/system/emergency.service.

Require Authentication for Single User Mode Single-user mode is intended as a system recovery method, providing a single user root access to the system by providing a boot option at startup.

By default, single-user mode is protected by requiring a password and is set in /usr/lib/systemd/system/rescue.service.

CCI-000381

SRG-OS-000095-GPOS-00049

TBD - Assigned by DISA after STIG release

The operating system must be configured to disable non-essential capabilities.

It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Examples of non-essential capabilities include, but are not limited to, games, software packages, tools, and demonstration software, not related to requirements or providing a wide array of functionality not required for every mission, but which cannot be disabled.

Disable chrony daemon from acting as server The port option in /etc/chrony.conf can be set to 0 to make chrony daemon to never open any listening port for server operation and to operate strictly in a client-only mode.

Disable network management of chrony daemon The cmdport option in /etc/chrony.conf can be set to 0 to stop chrony daemon from listening on the UDP port 323 for management connections made by chronyc.

Enable Kernel Page-Table Isolation (KPTI)

To enable Kernel page-table isolation, add the argument pti=on to the default GRUB 2 command line for the Linux operating system. To ensure that pti=on is added as a kernel command line argument to newly installed kernels, add pti=on to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:

GRUB_CMDLINE_LINUX="... pti=on ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="pti=on"

Disable ATM Support

The Asynchronous Transfer Mode (ATM) is a protocol operating on network, data link, and physical layers, based on virtual circuits and virtual paths. To configure the system to prevent the atm kernel module from being loaded, add the following line to the file /etc/modprobe.d/atm.conf:

install atm /bin/false

To configure the system to prevent the atm from being used, add the following line to file /etc/modprobe.d/atm.conf:

blacklist atm

Disable Bluetooth Kernel Module

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

install bluetooth /bin/true

Disable CAN Support

The Controller Area Network (CAN) is a serial communications protocol which was initially developed for automotive and is now also used in marine, industrial, and medical applications. To configure the system to prevent the can kernel module from being loaded, add the following line to the file /etc/modprobe.d/can.conf:

install can /bin/false

To configure the system to prevent the can from being used, add the following line to file /etc/modprobe.d/can.conf:

blacklist can

Disable Mounting of cramfs

To configure the system to prevent the cramfs kernel module from being loaded, add the following line to the file /etc/modprobe.d/cramfs.conf:

install cramfs /bin/false

To configure the system to prevent the cramfs from being used, add the following line to file /etc/modprobe.d/cramfs.conf:

blacklist cramfs

This effectively prevents usage of this uncommon filesystem. The cramfs filesystem type is a compressed read-only Linux filesystem embedded in small footprint systems. A cramfs image can be used without having to first decompress the image.

Disable IEEE 1394 (FireWire) Support

The IEEE 1394 (FireWire) is a serial bus standard for high-speed real-time communication. To configure the system to prevent the firewire-core kernel module from being loaded, add the following line to the file /etc/modprobe.d/firewire-core.conf:

install firewire-core /bin/false

To configure the system to prevent the firewire-core from being used, add the following line to file /etc/modprobe.d/firewire-core.conf:

blacklist firewire-core

Disable SCTP Support

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

install sctp /bin/false

To configure the system to prevent the sctp from being used, add the following line to file /etc/modprobe.d/sctp.conf:

blacklist sctp

Disable TIPC Support

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

install tipc /bin/false

To configure the system to prevent the tipc from being used, add the following line to file /etc/modprobe.d/tipc.conf:

blacklist tipc

Disable the uvcvideo module

If the device contains a camera it should be covered or disabled when not in use.

Uninstall abrt-addon-ccpp Package

The abrt-addon-ccpp package can be removed with the following command:

$ sudo yum erase abrt-addon-ccpp

Uninstall abrt-addon-kerneloops Package

The abrt-addon-kerneloops package can be removed with the following command:

$ sudo yum erase abrt-addon-kerneloops

Uninstall abrt-cli Package

The abrt-cli package can be removed with the following command:

$ sudo yum erase abrt-cli

Uninstall abrt-plugin-sosreport Package

The abrt-plugin-sosreport package can be removed with the following command:

$ sudo yum erase abrt-plugin-sosreport

Uninstall Automatic Bug Reporting Tool (abrt)

The Automatic Bug Reporting Tool (abrt) collects and reports crash data when an application crash is detected. Using a variety of plugins, abrt can email crash reports to system administrators, log crash reports to files, or forward crash reports to a centralized issue tracking system such as RHTSupport. The abrt package can be removed with the following command:

$ sudo yum erase abrt

Uninstall gssproxy Package

The gssproxy package can be removed with the following command:

$ sudo yum erase gssproxy

Uninstall iprutils Package

The iprutils package can be removed with the following command:

$ sudo yum erase iprutils

Uninstall krb5-workstation Package

The krb5-workstation package can be removed with the following command:

$ sudo yum erase krb5-workstation

Uninstall libreport-plugin-logger Package

The libreport-plugin-logger package can be removed with the following command:

$ sudo yum erase libreport-plugin-logger

Uninstall libreport-plugin-rhtsupport Package

The libreport-plugin-rhtsupport package can be removed with the following command:

$ sudo yum erase libreport-plugin-rhtsupport

Uninstall python3-abrt-addon Package

The python3-abrt-addon package can be removed with the following command:

$ sudo yum erase python3-abrt-addon

Uninstall rsh-server Package

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

$ sudo yum erase rsh-server

Uninstall Sendmail Package

Sendmail is not the default mail transfer agent and is not installed by default. The sendmail package can be removed with the following command:

$ sudo yum erase sendmail

Uninstall telnet-server Package

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

$ sudo yum erase telnet-server

Uninstall tuned Package

The tuned package can be removed with the following command:

$ sudo yum erase tuned

Uninstall vsftpd Package

The vsftpd package can be removed with the following command:

 $ sudo yum erase vsftpd

CCI-000382

SRG-OS-000096-GPOS-00050

TBD - Assigned by DISA after STIG release

The operating system must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments.

In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., VPN and IPS); however, doing so increases risk over limiting the services provided by any one component. To support the requirements and principles of least functionality, the operating system must support the organizational requirements, providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues.

Configure the Firewalld Ports

Configure the firewalld ports to allow approved services to have access to the system. To configure firewalld to open ports, run the following command:

firewall-cmd --permanent --add-port=port_number/tcp

To configure firewalld to allow access for pre-defined services, run the following command:

firewall-cmd --permanent --add-service=service_name

Install firewalld Package

The firewalld package can be installed with the following command:

$ sudo yum install firewalld

Verify firewalld Enabled

The firewalld service can be enabled with the following command:

$ sudo systemctl enable firewalld.service

CCI-000764

SRG-OS-000104-GPOS-00051

TBD - Assigned by DISA after STIG release

The operating system must uniquely identify and must authenticate organizational users (or processes acting on behalf of organizational users).

To assure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system. Organizational users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Organizational users (and processes acting on behalf of users) must be uniquely identified and authenticated to all accesses, except for the following: 1) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication; and 2) Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity.

Ensure All Accounts on the System Have Unique User IDs

Change user IDs (UIDs), or delete accounts, so each has a unique name.

CCI-000765

SRG-OS-000105-GPOS-00052

TBD - Assigned by DISA after STIG release

The operating system must use multifactor authentication for network access to privileged accounts.

Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. Factors include: 1) something a user knows (e.g., password/PIN); 2) something a user has (e.g., cryptographic identification device, token); and 3) something a user is (e.g., biometric). A privileged account is defined as an information system account with authorizations of a privileged user. Network access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, or the Internet). The DoD CAC with DoD-approved PKI is an example of multifactor authentication.

Install Smart Card Packages For Multifactor Authentication

Configure the operating system to implement multifactor authentication by installing the required package with the following command: The openssl-pkcs11 package can be installed with the following command:

$ sudo yum install openssl-pkcs11

Enable Smartcards in SSSD

SSSD should be configured to authenticate access to the system using smart cards. To enable smart cards in SSSD, set pam_cert_auth to True under the [pam] section in /etc/sssd/sssd.conf. For example:

[pam]
pam_cert_auth = True

Add or update "pam_sss.so" line in auth section of "/etc/pam.d/system-auth" file to include "try_cert_auth" or "require_cert_auth" option, like in the following example:

/etc/pam.d/system-auth:auth [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_sss.so try_cert_auth

Also add or update "pam_sss.so" line in auth section of "/etc/pam.d/smartcard-auth" file to include the "allow_missing_name" option, like in the following example:

/etc/pam.d/smartcard-auth:auth sufficient pam_sss.so allow_missing_name

CCI-000766

SRG-OS-000106-GPOS-00053

TBD - Assigned by DISA after STIG release

The operating system must use multifactor authentication for network access to non-privileged accounts.

To assure accountability and prevent unauthenticated access, non-privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system. Multifactor authentication uses two or more factors to achieve authentication. Factors include: 1) Something you know (e.g., password/PIN); 2) Something you have (e.g., cryptographic identification device, token); and 3) Something you are (e.g., biometric). A non-privileged account is any information system account with authorizations of a non-privileged user. Network access is any access to an application by a user (or process acting on behalf of a user) where said access is obtained through a network connection. The DoD CAC with DoD-approved PKI is an example of multifactor authentication.

Disable SSH Access via Empty Passwords

Disallow SSH login with empty passwords. The default SSH configuration disables logins with empty passwords. The appropriate configuration is used if no value is set for PermitEmptyPasswords.
To explicitly disallow SSH login from accounts with empty passwords, add or correct the following line in /etc/ssh/sshd_config:

PermitEmptyPasswords no

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

Enable Smartcards in SSSD

[pam]
pam_cert_auth = True

Add or update "pam_sss.so" line in auth section of "/etc/pam.d/system-auth" file to include "try_cert_auth" or "require_cert_auth" option, like in the following example:

/etc/pam.d/system-auth:auth [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_sss.so try_cert_auth

Also add or update "pam_sss.so" line in auth section of "/etc/pam.d/smartcard-auth" file to include the "allow_missing_name" option, like in the following example:

/etc/pam.d/smartcard-auth:auth sufficient pam_sss.so allow_missing_name

CCI-000765

SRG-OS-000107-GPOS-00054

TBD - Assigned by DISA after STIG release

The operating system must use multifactor authentication for local access to privileged accounts.

To ensure accountability and prevent unauthenticated access, privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system. Multifactor authentication is defined as using two or more factors to achieve authentication. Factors include: 1) Something you know (e.g., password/PIN); 2) Something you have (e.g., cryptographic identification device, token); and 3) Something you are (e.g., biometric). A privileged account is defined as an operating system account with authorizations of a privileged user. Local access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network. The DOD CAC with DOD-approved PKI is an example of multifactor authentication.

Enable Smartcards in SSSD

[pam]
pam_cert_auth = True

Add or update "pam_sss.so" line in auth section of "/etc/pam.d/system-auth" file to include "try_cert_auth" or "require_cert_auth" option, like in the following example:

/etc/pam.d/system-auth:auth [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_sss.so try_cert_auth

Also add or update "pam_sss.so" line in auth section of "/etc/pam.d/smartcard-auth" file to include the "allow_missing_name" option, like in the following example:

/etc/pam.d/smartcard-auth:auth sufficient pam_sss.so allow_missing_name

CCI-000766

SRG-OS-000108-GPOS-00055

TBD - Assigned by DISA after STIG release

The operating system must use multifactor authentication for local access to nonprivileged accounts.

To ensure accountability, prevent unauthenticated access, and prevent misuse of the system, nonprivileged users must utilize multifactor authentication for local access. Multifactor authentication is defined as using two or more factors to achieve authentication. Factors include: 1) Something you know (e.g., password/PIN); 2) Something you have (e.g., cryptographic identification device or token); and 3) Something you are (e.g., biometric). A nonprivileged account is defined as an operating system account with authorizations of a regular or nonprivileged user. Local access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network. The DOD CAC with DOD-approved PKI is an example of multifactor authentication.

Enable Smartcards in SSSD

[pam]
pam_cert_auth = True

Add or update "pam_sss.so" line in auth section of "/etc/pam.d/system-auth" file to include "try_cert_auth" or "require_cert_auth" option, like in the following example:

/etc/pam.d/system-auth:auth [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_sss.so try_cert_auth

Also add or update "pam_sss.so" line in auth section of "/etc/pam.d/smartcard-auth" file to include the "allow_missing_name" option, like in the following example:

/etc/pam.d/smartcard-auth:auth sufficient pam_sss.so allow_missing_name

CCI-004045

SRG-OS-000109-GPOS-00056

TBD - Assigned by DISA after STIG release

The operating system must require individuals to be authenticated with an individual authenticator prior to using a group authenticator.

To ensure individual accountability and prevent unauthorized access, organizational users must be individually identified and authenticated. A group authenticator is a generic account used by multiple individuals. Use of a group authenticator alone does not uniquely identify individual users. Examples of the group authenticator is the Unix OS "root" user account, the Windows "Administrator" account, the "sa" account, or a "helpdesk" account. For example, the Unix and Windows operating systems offer a "switch user" capability allowing users to authenticate with their individual credentials and, when needed, "switch" to the administrator role. This method provides for unique individual authentication prior to using a group authenticator. Users (and any processes acting on behalf of users) need to be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization, which outlines specific user actions that can be performed on the operating system without identification or authentication. Requiring individuals to be authenticated with an individual authenticator prior to using a group authenticator allows for traceability of actions, as well as adding an additional level of protection of the actions that can be taken with group account knowledge.

Disable SSH Root Login

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

PermitRootLogin no

CCI-001941 SRG-OS-000112-GPOS-00057 TBD - Assigned by DISA after STIG release The operating system must implement replay-resistant authentication mechanisms for network access to privileged accounts. A replay attack may enable an unauthorized user to gain access to the operating system. Authentication sessions between the authenticator and the operating system validating the user credentials must not be vulnerable to a replay attack. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. A privileged account is any information system account with authorizations of a privileged user. Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators.

CCI-001941 SRG-OS-000113-GPOS-00058 TBD - Assigned by DISA after STIG release The operating system must implement replay-resistant authentication mechanisms for network access to nonprivileged accounts. A replay attack may enable an unauthorized user to gain access to the operating system. Authentication sessions between the authenticator and the operating system validating the user credentials must not be vulnerable to a replay attack. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. A nonprivileged account is any operating system account with authorizations of a nonprivileged user. Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators.

CCI-000778

SRG-OS-000114-GPOS-00059

TBD - Assigned by DISA after STIG release

The operating system must uniquely identify peripherals before establishing a connection.

Without identifying devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Peripherals include, but are not limited to, such devices as flash drives, external storage, and printers.

Disable Modprobe Loading of USB Storage Driver

To prevent USB storage devices from being used, configure the kernel module loading system to prevent automatic loading of the USB storage driver. To configure the system to prevent the usb-storage kernel module from being loaded, add the following line to the file /etc/modprobe.d/usb-storage.conf:

install usb-storage /bin/false

To configure the system to prevent the usb-storage from being used, add the following line to file /etc/modprobe.d/usb-storage.conf:

blacklist usb-storage

This will prevent the modprobe program from loading the usb-storage module, but will not prevent an administrator (or another program) from using the insmod program to load the module manually.

Disable the Automounter

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

The autofs service can be disabled with the following command:

$ sudo systemctl mask --now autofs.service

CCI-003627

SRG-OS-000118-GPOS-00060

TBD - Assigned by DISA after STIG release

The operating system must disable account identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.

Inactive identifiers pose a risk to systems and applications because attackers may exploit an inactive identifier and potentially obtain undetected access to the system. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Operating systems need to track periods of inactivity and disable application identifiers after 35 days of inactivity.

Set Account Expiration Following Inactivity

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

INACTIVE=

If a password is currently on the verge of expiration, then day(s) remain(s) until the account is automatically disabled. However, if the password will not expire for another 60 days, then 60 days plus day(s) could elapse until the account would be automatically disabled. See the useradd man page for more information.

CCI-000803

SRG-OS-000120-GPOS-00061

TBD - Assigned by DISA after STIG release

The operating system must use mechanisms meeting the requirements of applicable federal laws, Executive orders, directives, policies, regulations, standards, and guidance for authentication to a cryptographic module.

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised. Operating systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. FIPS 140-2/140-3 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoD requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general purpose computing system.

Verify All Account Password Hashes are Shadowed with SHA512

$ sudo cut -d: -f2 /etc/shadow
$6$kcOnRq/5$NUEYPuyL.wghQwWssXRcLRFiiru7f5JPV6GaJhNC2aK5F3PZpE/BCCtwrxRc/AInKMNX3CdMw11m9STiql12f/

Password hashes ! or * indicate inactive accounts not available for logon and are not evaluated. If any interactive user password hash does not begin with $6, this is a finding.

Configure Kerberos to use System Crypto Policy

Crypto Policies provide a centralized control over crypto algorithms usage of many packages. Kerberos is supported by crypto policy, but it's configuration may be set up to ignore it. To check that Crypto Policies settings for Kerberos are configured correctly, examine that there is a symlink at /etc/krb5.conf.d/crypto-policies targeting /etc/cypto-policies/back-ends/krb5.config. If the symlink exists, Kerberos is configured to use the system-wide crypto policy settings.

Disable Kerberos by removing host keytab Kerberos is not an approved key distribution method for Common Criteria. To prevent using Kerberos by system daemons, remove the Kerberos keytab files, especially /etc/krb5.keytab.

Remove the Kerberos Server Package

The krb5-server package should be removed if not in use. Is this system the Kerberos server? If not, remove the package. The krb5-server package can be removed with the following command:

$ sudo yum erase krb5-server

The krb5-server RPM is not installed by default on a Red Hat Enterprise Linux 8 system. It is needed only by the Kerberos servers, not by the clients which use Kerberos for authentication. If the system is not intended for use as a Kerberos Server it should be removed.

Uninstall krb5-workstation Package

The krb5-workstation package can be removed with the following command:

$ sudo yum erase krb5-workstation

Ensure rsyslog-gnutls is installed

TLS protocol support for rsyslog is installed. The rsyslog-gnutls package can be installed with the following command:

$ sudo yum install rsyslog-gnutls

Set PAM''s Password Hashing Algorithm - password-auth

password    sufficient    pam_unix.so _{other arguments...}

This will help ensure that new passwords for local users will be stored using the _algorithm.

Set PAM''s Password Hashing Algorithm

password    sufficient    pam_unix.so _{other arguments...}

This will help ensure that new passwords for local users will be stored using the _algorithm.

Set Password Hashing Rounds in /etc/login.defs

In /etc/login.defs, ensure SHA_CRYPT_MIN_ROUNDS and SHA_CRYPT_MAX_ROUNDS has the minimum value of 5000. For example:

SHA_CRYPT_MIN_ROUNDS 5000
SHA_CRYPT_MAX_ROUNDS 5000

Notice that if neither are set, they already have the default value of 5000. If either is set, they must have the minimum value of 5000.

CCI-000804

SRG-OS-000121-GPOS-00062

TBD - Assigned by DISA after STIG release

The operating system must uniquely identify and must authenticate non-organizational users (or processes acting on behalf of non-organizational users).

Lack of authentication and identification enables non-organizational users to gain access to the application or possibly other information systems and provides an opportunity for intruders to compromise resources within the application or information system. Non-organizational users include all information system users other than organizational users, which include organizational employees or individuals the organization deems to have equivalent status of an employee (e.g., contractors and guest researchers). Non-organizational users shall be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization when related to the use of anonymous access.

Ensure All Accounts on the System Have Unique User IDs

Change user IDs (UIDs), or delete accounts, so each has a unique name.

CCI-001876

SRG-OS-000122-GPOS-00063

TBD - Assigned by DISA after STIG release

The operating system must provide an audit reduction capability that supports on-demand reporting requirements.

The ability to generate on-demand reports, including after the audit data has been subjected to audit reduction, greatly facilitates the organization's ability to generate incident reports as needed to better handle larger-scale or more complex security incidents. Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. The report generation capability provided by the application must support on-demand (i.e., customizable, ad hoc, and as-needed) reports.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-001682

SRG-OS-000123-GPOS-00064

TBD - Assigned by DISA after STIG release

The information system must automatically remove or disable emergency accounts after the crisis is resolved or 72 hours.

Emergency accounts are privileged accounts that are established in response to crisis situations where the need for rapid account activation is required. Therefore, emergency account activation may bypass normal account authorization processes. If these accounts are automatically disabled, system maintenance during emergencies may not be possible, thus adversely affecting system availability. Emergency accounts are different from infrequently used accounts (i.e., local logon accounts used by the organization's system administrators when network or normal logon/access is not available). Infrequently used accounts are not subject to automatic termination dates. Emergency accounts are accounts created in response to crisis situations, usually for use by maintenance personnel. The automatic expiration or disabling time period may be extended as needed until the crisis is resolved; however, it must not be extended indefinitely. A permanent account should be established for privileged users who need long-term maintenance accounts. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements.

Assign Expiration Date to Temporary Accounts

$ sudo chage -E YYYY-MM-DD USER

CCI-000877

SRG-OS-000125-GPOS-00065

TBD - Assigned by DISA after STIG release

The operating system must employ strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions.

If maintenance tools are used by unauthorized personnel, they may accidentally or intentionally damage or compromise the system. The act of managing systems and applications includes the ability to access sensitive application information, such as system configuration details, diagnostic information, user information, and potentially sensitive application data. Some maintenance and test tools are either standalone devices with their own operating systems or are applications bundled with an operating system. Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, PKI where certificates are stored on a token protected by a password, passphrase, or biometric.

Configure OpenSSL library to use TLS Encryption

Crypto Policies are means of enforcing certain cryptographic settings for selected applications including OpenSSL. OpenSSL is by default configured to modify its configuration based on currently configured Crypto Policy. Editing the Crypto Policy back-end is not recommended. Check the crypto-policies(7) man page and choose a policy that configures TLS protocol to version 1.2 or higher, for example DEFAULT, FUTURE or FIPS policy. Or create and apply a custom policy that restricts minimum TLS version to 1.2. For example for versions prior to crypto-policies-20210617-1.gitc776d3e.el8.noarch this is expected:

$ sudo grep -i MinProtocol /etc/crypto-policies/back-ends/opensslcnf.config

MinProtocol = TLSv1.2

Or for version crypto-policies-20210617-1.gitc776d3e.el8.noarch and newer this is expected:

$ sudo grep -i MinProtocol /etc/crypto-policies/back-ends/opensslcnf.config

TLS.MinProtocol = TLSv1.2
DTLS.MinProtocol = DTLSv1.2

Configure SSH Client to Use FIPS 140-2 Validated Ciphers: openssh.config

Ciphers

Configure SSH Server to Use FIPS 140-2 Validated Ciphers: opensshserver.config

Crypto Policies provide a centralized control over crypto algorithms usage of many packages. OpenSSH is supported by system crypto policy, but the OpenSSH configuration may be set up incorrectly. To check that Crypto Policies settings for ciphers are configured correctly, ensure that /etc/crypto-policies/back-ends/opensshserver.config contains the following text and is not commented out:

-oCiphers=

Configure SSH Client to Use FIPS 140-2 Validated MACs: openssh.config Crypto Policies provide a centralized control over crypto algorithms usage of many packages. OpenSSH is supported by system crypto policy, but the OpenSSH configuration may be set up incorrectly. To check that Crypto Policies settings are configured correctly, ensure that /etc/crypto-policies/back-ends/openssh.config contains the following line and is not commented out: MACs

Configure SSH Server to Use FIPS 140-2 Validated MACs: opensshserver.config Crypto Policies provide a centralized control over crypto algorithms usage of many packages. OpenSSH is supported by system crypto policy, but the OpenSSH configuration may be set up incorrectly. To check that Crypto Policies settings are configured correctly, ensure that /etc/crypto-policies/back-ends/opensshserver.config contains the following text and is not commented out: -oMACS=

Set kernel parameter 'crypto.fips_enabled' to 1

System running in FIPS mode is indicated by kernel parameter 'crypto.fips_enabled'. This parameter should be set to 1 in FIPS mode. To enable FIPS mode, run the following command:

fips-mode-setup --enable

CCI-001082

SRG-OS-000132-GPOS-00067

TBD - Assigned by DISA after STIG release

The operating system must separate user functionality (including user interface services) from operating system management functionality.

Operating system management functionality includes functions necessary for administration and requires privileged user access. Allowing non-privileged users to access operating system management functionality capabilities increases the risk that non-privileged users may obtain elevated privileges. Operating system management functionality includes functions necessary to administer console, network components, workstations, or servers and typically requires privileged user access. The separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, different TCP/UDP ports, virtualization techniques, combinations of these methods, or other methods, as appropriate. An example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. This may include isolating the administrative interface on a different security domain and with additional access controls.

Restrict Access to Kernel Message Buffer

To set the runtime status of the kernel.dmesg_restrict kernel parameter, run the following command:

$ sudo sysctl -w kernel.dmesg_restrict=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

kernel.dmesg_restrict = 1

Restrict Exposed Kernel Pointer Addresses Access

To set the runtime status of the kernel.kptr_restrict kernel parameter, run the following command:

$ sudo sysctl -w kernel.kptr_restrict=

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

kernel.kptr_restrict =

Disallow kernel profiling by unprivileged users

To set the runtime status of the kernel.perf_event_paranoid kernel parameter, run the following command:

$ sudo sysctl -w kernel.perf_event_paranoid=2

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

kernel.perf_event_paranoid = 2

Disable Access to Network bpf() Syscall From Unprivileged Processes

To set the runtime status of the kernel.unprivileged_bpf_disabled kernel parameter, run the following command:

$ sudo sysctl -w kernel.unprivileged_bpf_disabled=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

kernel.unprivileged_bpf_disabled = 1

Restrict usage of ptrace to descendant processes

To set the runtime status of the kernel.yama.ptrace_scope kernel parameter, run the following command:

$ sudo sysctl -w kernel.yama.ptrace_scope=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

kernel.yama.ptrace_scope = 1

CCI-001084

SRG-OS-000134-GPOS-00068

TBD - Assigned by DISA after STIG release

The operating system must isolate security functions from nonsecurity functions.

An isolation boundary provides access control and protects the integrity of the hardware, software, and firmware that perform security functions. Security functions are the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Operating systems implement code separation (i.e., separation of security functions from nonsecurity functions) in a number of ways, including through the provision of security kernels via processor rings or processor modes. For non-kernel code, security function isolation is often achieved through file system protections that serve to protect the code on disk and address space protections that protect executing code. Developers and implementers can increase the assurance in security functions by employing well-defined security policy models; structured, disciplined, and rigorous hardware and software development techniques; and sound system/security engineering principles. Implementation may include isolation of memory space and libraries. Operating systems restrict access to security functions through the use of access control mechanisms and by implementing least privilege capabilities.

Enable page allocator poisoning

To enable poisoning of free pages, add the argument page_poison=1 to the default GRUB 2 command line for the Linux operating system. To ensure that page_poison=1 is added as a kernel command line argument to newly installed kernels, add page_poison=1 to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:

GRUB_CMDLINE_LINUX="... page_poison=1 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="page_poison=1"

Enable SLUB/SLAB allocator poisoning

To enable poisoning of SLUB/SLAB objects, add the argument slub_debug= to the default GRUB 2 command line for the Linux operating system. To ensure that slub_debug= is added as a kernel command line argument to newly installed kernels, add slub_debug= to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:

GRUB_CMDLINE_LINUX="... slub_debug=_..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="slub_debug=_"

Disable vsyscalls

To disable use of virtual syscalls, add the argument vsyscall=none to the default GRUB 2 command line for the Linux operating system. To ensure that vsyscall=none is added as a kernel command line argument to newly installed kernels, add vsyscall=none to the default Grub2 command line for Linux operating systems. Modify the line within /etc/default/grub as shown below:

GRUB_CMDLINE_LINUX="... vsyscall=none ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="vsyscall=none"

Install policycoreutils Package

The policycoreutils package can be installed with the following command:

$ sudo yum install policycoreutils

Ensure SELinux State is Enforcing

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

SELINUX=

CCI-001090

SRG-OS-000138-GPOS-00069

TBD - Assigned by DISA after STIG release

Operating systems must prevent unauthorized and unintended information transfer via shared system resources.

Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DoD or other government agencies. There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components.

Ensure All World-Writable Directories Are Owned by root User

All directories in local partitions which are world-writable should be owned by root. If any world-writable directories are not owned by root, this should be investigated. Following this, the files should be deleted or assigned to root user.

Verify that All World-Writable Directories Have Sticky Bits Set

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

$ sudo chmod +t DIR

Restrict Access to Kernel Message Buffer

To set the runtime status of the kernel.dmesg_restrict kernel parameter, run the following command:

$ sudo sysctl -w kernel.dmesg_restrict=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

kernel.dmesg_restrict = 1

Disallow kernel profiling by unprivileged users

To set the runtime status of the kernel.perf_event_paranoid kernel parameter, run the following command:

$ sudo sysctl -w kernel.perf_event_paranoid=2

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

kernel.perf_event_paranoid = 2

CCI-001095 SRG-OS-000142-GPOS-00071 TBD - Assigned by DISA after STIG release The operating system must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of Denial of Service (DoS) attacks. DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. Managing excess capacity ensures that sufficient capacity is available to counter flooding attacks. Employing increased capacity and service redundancy may reduce the susceptibility to some DoS attacks. Managing excess capacity may include, for example, establishing selected usage priorities, quotas, or partitioning.

CCI-001133

SRG-OS-000163-GPOS-00072

TBD - Assigned by DISA after STIG release

The operating system must terminate all network connections associated with a communications session at the end of the session, or as follows: for in-band management sessions (privileged sessions), the session must be terminated after 10 minutes of inactivity; and for user sessions (non-privileged session), the session must be terminated after 15 minutes of inactivity, except to fulfill documented and validated mission requirements.

Terminating an idle 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 left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, and de-allocating networking assignments at the application level if multiple application sessions are using a single operating system-level network connection. This does not mean that the operating system terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.

Configure Logind to terminate idle sessions after certain time of inactivity

To configure logind service to terminate inactive user sessions after _{seconds, edit the file
/etc/systemd/logind.conf. Ensure that there is a section
[Login] which contains the configuration
StopIdleSessionSec=
.}

Set SSH Client Alive Interval

SSH allows administrators to set a network responsiveness timeout interval. After this interval has passed, the unresponsive client will be automatically logged out.

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

ClientAliveInterval

The timeout interval is given in seconds. For example, 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 in /etc/ssh/sshd_config. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle.

Set SSH Client Alive Count Max The SSH server sends at most ClientAliveCountMax messages during a SSH session and waits for a response from the SSH client. The option ClientAliveInterval configures timeout after each ClientAliveCountMax message. If the SSH server does not receive a response from the client, then the connection is considered unresponsive and terminated. For SSH earlier than v8.2, a ClientAliveCountMax value of 0 causes a timeout precisely when the ClientAliveInterval is set. Starting with v8.2, a value of 0 disables the timeout functionality completely. If the option is set to a number greater than 0, then the session will be disconnected after ClientAliveInterval * ClientAliveCountMax seconds without receiving a keep alive message.

CCI-001190 SRG-OS-000184-GPOS-00078 TBD - Assigned by DISA after STIG release The operating system must fail to a secure state if system initialization fails, shutdown fails, or aborts fail. Failure to a known safe state helps prevent systems from failing to a state that may cause loss of data or unauthorized access to system resources. Operating systems that fail suddenly and with no incorporated failure state planning may leave the system available but with a reduced security protection capability. Preserving operating system state information also facilitates system restart and return to the operational mode of the organization with less disruption to mission-essential processes. Abort refers to stopping a program or function before it has finished naturally. The term abort refers to both requested and unexpected terminations.

CCI-001199

SRG-OS-000185-GPOS-00079

TBD - Assigned by DISA after STIG release

The operating system must protect the confidentiality and integrity of all information at rest.

Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive and tape drive, when used for backups) within an operating system. This requirement addresses protection of user-generated data, as well as operating system-specific configuration data. Organizations may choose to employ different mechanisms to achieve confidentiality and integrity protections, as appropriate, in accordance with the security category and/or classification of the information.

Encrypt Partitions

Red Hat Enterprise Linux 8 natively supports partition encryption through the Linux Unified Key Setup-on-disk-format (LUKS) technology. The easiest way to encrypt a partition is during installation time.

For manual installations, select the Encrypt checkbox during partition creation to encrypt the partition. When this option is selected the system will prompt for a passphrase to use in decrypting the partition. The passphrase will subsequently need to be entered manually every time the system boots.

For automated/unattended installations, it is possible to use Kickstart by adding the --encrypted and --passphrase= options to the definition of each partition to be encrypted. For example, the following line would encrypt the root partition:

part / --fstype=ext4 --size=100 --onpart=hda1 --encrypted --passphrase=PASSPHRASE

Any PASSPHRASE is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the --passphrase= option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation.

By default, the Anaconda installer uses aes-xts-plain64 cipher with a minimum 512 bit key size which should be compatible with FIPS enabled.

Detailed information on encrypting partitions using LUKS or LUKS ciphers can be found on the Red Hat Enterprise Linux 8 Documentation web site:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/encrypting-block-devices-using-luks_security-hardening .

CCI-001312 SRG-OS-000205-GPOS-00083 TBD - Assigned by DISA after STIG release The operating system must generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries. Any operating system providing too much information in error messages risks compromising the data and security of the structure, and content of error messages needs to be carefully considered by the organization. Organizations carefully consider the structure/content of error messages. The extent to which information systems are able to identify and handle error conditions is guided by organizational policy and operational requirements. Information that could be exploited by adversaries includes, for example, erroneous logon attempts with passwords entered by mistake as the username, mission/business information that can be derived from (if not stated explicitly by) information recorded, and personal information, such as account numbers, social security numbers, and credit card numbers.

CCI-001314

SRG-OS-000206-GPOS-00084

TBD - Assigned by DISA after STIG release

The operating system must reveal error messages only to authorized users.

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

System Audit Directories Must Be Group Owned By Root

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

/var/log/audit/

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

$ sudo chgrp root /var/log/audit

If log_group in /etc/audit/auditd.conf is set to a group other than the root group account, change the group ownership of the audit directories to this specific group.

System Audit Directories Must Be Owned By Root

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

/var/log/audit/

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

$ sudo chown root /var/log/audit

System Audit Logs Must Be Group Owned By Root

All audit logs must be group owned by root user. The path for audit log can be configured via log_file parameter in

/etc/audit/auditd.conf

or, by default, the path for audit log is

/var/log/audit/

. To properly set the group owner of /var/log/audit/*, run the command:

$ sudo chgrp root /var/log/audit/*

If log_group in /etc/audit/auditd.conf is set to a group other than the root group account, change the group ownership of the audit logs to this specific group.

Verify Group Who Owns /var/log Directory

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

$ sudo chgrp root /var/log

Verify Group Who Owns /var/log/messages File

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

$ sudo chgrp root /var/log/messages

Verify User Who Owns /var/log Directory

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

$ sudo chown root /var/log

Verify User Who Owns /var/log/messages File

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

$ sudo chown root /var/log/messages

System Audit Logs Must Be Owned By Root

All audit logs must be owned by root user. The path for audit log can be configured via log_file parameter in

/etc/audit/auditd.conf

or by default, the path for audit log is

/var/log/audit/

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

$ sudo chown root /var/log/audit/*

Verify Permissions on /var/log Directory

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

$ sudo chmod 0755 /var/log

System Audit Logs Must Have Mode 0640 or Less Permissive

Determine where the audit logs are stored with the following command:

$ sudo grep -iw log_file /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log

Configure the audit log to be protected from unauthorized read access by setting the correct permissive mode with the following command:

$ sudo chmod 0600 audit_log_file

By default, audit_log_file is "/var/log/audit/audit.log".

Verify Permissions on /var/log/messages File

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

$ sudo chmod 0640 /var/log/messages

CCI-001384

SRG-OS-000228-GPOS-00088

TBD - Assigned by DISA after STIG release

Any publically accessible connection to the operating system must display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.

Display of a standardized and approved use notification before granting access to the publicly accessible operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for operating systems that can accommodate banners of 1300 characters: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've readconsent to terms in IS user agreem't."

Enable GNOME3 Login Warning Banner

[org/gnome/login-screen]
banner-message-enable=true

Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example:

/org/gnome/login-screen/banner-message-enable

After the settings have been set, run dconf update. The banner text must also be set.

Set the GNOME3 Login Warning Banner Text

[org/gnome/login-screen]
banner-message-text='APPROVED_BANNER'

Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example:

/org/gnome/login-screen/banner-message-text

After the settings have been set, run dconf update. When entering a warning banner that spans several lines, remember to begin and end the string with ' and use \n for new lines.

Enable SSH Warning Banner

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

Banner /etc/issue

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

CCI-001403

SRG-OS-000239-GPOS-00089

TBD - Assigned by DISA after STIG release

The operating system must audit all account modifications.

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to modify an existing account. Auditing account modification actions provides logging that can be used for forensic purposes. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.

Ensure auditd Collects System Administrator Actions - /etc/sudoers

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Record Events that Modify User/Group Information - /etc/group

-w /etc/group -p wa -k audit_rules_usergroup_modification

-w /etc/group -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/gshadow

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/security/opasswd

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/shadow

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

CCI-001404

SRG-OS-000240-GPOS-00090

TBD - Assigned by DISA after STIG release

The operating system must audit all account disabling actions.

When operating system accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual users or for identifying the operating system processes themselves. In order to detect and respond to events affecting user accessibility and system processing, operating systems must audit account disabling actions and, as required, notify the appropriate individuals so they can investigate the event. Such a capability greatly reduces the risk that operating system accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.

Ensure auditd Collects System Administrator Actions - /etc/sudoers

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Record Events that Modify User/Group Information - /etc/group

-w /etc/group -p wa -k audit_rules_usergroup_modification

-w /etc/group -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/gshadow

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/security/opasswd

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/shadow

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

CCI-001405

SRG-OS-000241-GPOS-00091

TBD - Assigned by DISA after STIG release

The operating system must audit all account removal actions.

When operating system accounts are removed, user accessibility is affected. Accounts are utilized for identifying individual users or for identifying the operating system processes themselves. In order to detect and respond to events affecting user accessibility and system processing, operating systems must audit account removal actions and, as required, notify the appropriate individuals so they can investigate the event. Such a capability greatly reduces the risk that operating system accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.

Ensure auditd Collects System Administrator Actions - /etc/sudoers

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Record Events that Modify User/Group Information - /etc/group

-w /etc/group -p wa -k audit_rules_usergroup_modification

-w /etc/group -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/gshadow

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/security/opasswd

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/shadow

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

CCI-001453

SRG-OS-000250-GPOS-00093

TBD - Assigned by DISA after STIG release

The operating system must implement cryptography to protect the integrity of remote access sessions.

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash.

Configure GnuTLS library to use DoD-approved TLS Encryption Crypto Policies provide a centralized control over crypto algorithms usage of many packages. GnuTLS is supported by system crypto policy, but the GnuTLS configuration may be set up to ignore it. To check that Crypto Policies settings are configured correctly, ensure that /etc/crypto-policies/back-ends/gnutls.config contains the following line and is not commented out: +VERS-ALL:-VERS-DTLS0.9:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1:-VERS-DTLS1.0

Configure OpenSSL library to use System Crypto Policy Crypto Policies provide a centralized control over crypto algorithms usage of many packages. OpenSSL is supported by crypto policy, but the OpenSSL configuration may be set up to ignore it. To check that Crypto Policies settings are configured correctly, you have to examine the OpenSSL config file available under /etc/pki/tls/openssl.cnf. This file has the ini format, and it enables crypto policy support if there is a [ crypto_policy ] section that contains the .include /etc/crypto-policies/back-ends/opensslcnf.config directive.

Configure OpenSSL library to use TLS Encryption

$ sudo grep -i MinProtocol /etc/crypto-policies/back-ends/opensslcnf.config

MinProtocol = TLSv1.2

Or for version crypto-policies-20210617-1.gitc776d3e.el8.noarch and newer this is expected:

$ sudo grep -i MinProtocol /etc/crypto-policies/back-ends/opensslcnf.config

TLS.MinProtocol = TLSv1.2
DTLS.MinProtocol = DTLSv1.2

Configure SSH to use System Crypto Policy Crypto Policies provide a centralized control over crypto algorithms usage of many packages. SSH is supported by crypto policy, but the SSH configuration may be set up to ignore it. To check that Crypto Policies settings are configured correctly, ensure that the CRYPTO_POLICY variable is either commented or not set at all in the /etc/sysconfig/sshd.

Configure SSH Client to Use FIPS 140-2 Validated Ciphers: openssh.config

Ciphers

Configure SSH Server to Use FIPS 140-2 Validated Ciphers: opensshserver.config

Crypto Policies provide a centralized control over crypto algorithms usage of many packages. OpenSSH is supported by system crypto policy, but the OpenSSH configuration may be set up incorrectly. To check that Crypto Policies settings for ciphers are configured correctly, ensure that /etc/crypto-policies/back-ends/opensshserver.config contains the following text and is not commented out:

-oCiphers=

Use Only FIPS 140-2 Validated Key Exchange Algorithms

Limit the key exchange algorithms to those which are FIPS-approved. Add or modify the following line in /etc/crypto-policies/back-ends/opensshserver.config

CRYPTO_POLICY='-oKexAlgorithms=ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512'

This rule ensures that only the key exchange algorithms mentioned above (or their subset) are configured for use, keeping the given order of algorithms.

Set kernel parameter 'crypto.fips_enabled' to 1

System running in FIPS mode is indicated by kernel parameter 'crypto.fips_enabled'. This parameter should be set to 1 in FIPS mode. To enable FIPS mode, run the following command:

fips-mode-setup --enable

CCI-001464

SRG-OS-000254-GPOS-00095

TBD - Assigned by DISA after STIG release

The operating system must initiate session audits at system start-up.

If auditing is enabled late in the start-up process, the actions of some start-up processes may not be audited. Some audit systems also maintain state information only available if auditing is enabled before a given process is created.

Enable Auditing for Processes Which Start Prior to the Audit Daemon

GRUB_CMDLINE_LINUX="... audit=1 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="audit=1"

Extend Audit Backlog Limit for the Audit Daemon

GRUB_CMDLINE_LINUX="... audit_backlog_limit=8192 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="audit_backlog_limit=8192"

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-001487

SRG-OS-000255-GPOS-00096

TBD - Assigned by DISA after STIG release

The operating system must produce audit records containing information to establish the identity of any individual or process associated with the event.

Without information that establishes the identity of the subjects (i.e., users or processes acting on behalf of users) associated with the events, security personnel cannot determine responsibility for the potentially harmful event.

Resolve information before writing to audit logs To configure Audit daemon to resolve all uid, gid, syscall, architecture, and socket address information before writing the events to disk, set log_format to ENRICHED in /etc/audit/auditd.conf.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-001493

SRG-OS-000256-GPOS-00097

TBD - Assigned by DISA after STIG release

The operating system must protect audit tools from unauthorized access.

Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Audit Tools Must Be Group-owned by Root

Red Hat Enterprise Linux 8 systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools, and the corresponding rights the user enjoys, to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. Audit tools must have the correct group owner.

Audit Tools Must Be Owned by Root

Audit Tools Must Have a Mode of 0755 or Less Permissive

CCI-001494

SRG-OS-000257-GPOS-00098

TBD - Assigned by DISA after STIG release

The operating system must protect audit tools from unauthorized modification.

Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user has in order to make access decisions regarding the modification of audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Audit Tools Must Be Group-owned by Root

Audit Tools Must Be Owned by Root

Audit Tools Must Have a Mode of 0755 or Less Permissive

CCI-001495

SRG-OS-000258-GPOS-00099

TBD - Assigned by DISA after STIG release

The operating system must protect audit tools from unauthorized deletion.

Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user has in order to make access decisions regarding the deletion of audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Audit Tools Must Be Group-owned by Root

Audit Tools Must Be Owned by Root

Audit Tools Must Have a Mode of 0755 or Less Permissive

CCI-001499

SRG-OS-000259-GPOS-00100

TBD - Assigned by DISA after STIG release

The operating system must limit privileges to change software resident within software libraries.

If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Verify that Shared Library Directories Have Root Group Ownership

System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:

/lib
/lib64
/usr/lib
/usr/lib64

Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be group-owned by the root user. If the directories, is found to be owned by a user other than root correct its ownership with the following command:

$ sudo chgrp root DIR

Verify that Shared Library Directories Have Root Ownership

System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:

/lib
/lib64
/usr/lib
/usr/lib64

Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be owned by the root user. If the directories, is found to be owned by a user other than root correct its ownership with the following command:

$ sudo chown root DIR

Verify that Shared Library Directories Have Restrictive Permissions

System-wide shared library directories, which contain are linked to executables during process load time or run time, are stored in the following directories by default:

/lib
/lib64
/usr/lib
/usr/lib64

Kernel modules, which can be added to the kernel during runtime, are stored in /lib/modules. All sub-directories in these directories should not be group-writable or world-writable. If any file in these directories is found to be group-writable or world-writable, correct its permission with the following command:

$ sudo chmod go-w DIR

Verify that system commands files are group owned by root or a system account

System commands files are stored in the following directories by default:

/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin

All files in these directories should be owned by the root group, or a system account. If the directory, or any file in these directories, is found to be owned by a group other than root or a a system account correct its ownership with the following command:

$ sudo chgrp root FILE

Verify that System Executables Have Root Ownership

System executables are stored in the following directories by default:

/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin

All files in these directories should be owned by the root user. If any file FILE in these directories is found to be owned by a user other than root, correct its ownership with the following command:

$ sudo chown root FILE

Verify that Shared Library Files Have Root Ownership

System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:

/lib
/lib64
/usr/lib
/usr/lib64

Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be owned by the root user. If the directory, or any file in these directories, is found to be owned by a user other than root correct its ownership with the following command:

$ sudo chown root FILE

Verify that System Executables Have Restrictive Permissions

System executables are stored in the following directories by default:

/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin

All files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command:

$ sudo chmod go-w FILE

Verify that Shared Library Files Have Restrictive Permissions

System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default:

/lib
/lib64
/usr/lib
/usr/lib64

Kernel modules, which can be added to the kernel during runtime, are stored in /lib/modules. All files in these directories should not be group-writable or world-writable. If any file in these directories is found to be group-writable or world-writable, correct its permission with the following command:

$ sudo chmod go-w FILE

Verify the system-wide library files in directories "/lib", "/lib64", "/usr/lib/" and "/usr/lib64" are group-owned by root.

System-wide library files are stored in the following directories by default:

/lib
/lib64
/usr/lib
/usr/lib64

All system-wide shared library files should be protected from unauthorised access. If any of these files is not group-owned by root, correct its group-owner with the following command:

$ sudo chgrp root FILE

CCI-004066

SRG-OS-000266-GPOS-00101

TBD - Assigned by DISA after STIG release

The operating system must enforce password complexity by requiring that at least one special character be used.

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor in determining how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Special characters are those characters that are not alphanumeric. Examples include: ~ ! @ # $ % ^ *.

Ensure PAM Enforces Password Requirements - Minimum Special Characters The pam_pwquality module's ocredit= parameter controls requirements for usage of special (or "other") characters in a password. When set to a negative number, any password will be required to contain that many special characters. When set to a positive number, pam_pwquality will grant +1 additional length credit for each special character. Modify the ocredit setting in /etc/security/pwquality.conf to equal _{to require use of a special character in passwords.}

CCI-001665

SRG-OS-000269-GPOS-00103

TBD - Assigned by DISA after STIG release

In the event of a system failure, the operating system must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to mission processes.

Failure to a known state can address safety or security in accordance with the mission/business needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving operating system state information helps to facilitate operating system restart and return to the operational mode of the organization with least disruption to mission/business processes.

Disable KDump Kernel Crash Analyzer (kdump)

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

$ sudo systemctl mask --now kdump.service

CCI-000015

SRG-OS-000274-GPOS-00104

TBD - Assigned by DISA after STIG release

The operating system must notify system administrators and ISSOs when accounts are created.

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to create a new account. Notification of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the creation of operating system user accounts and notifies administrators and ISSOs that it exists. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

CCI-000015

SRG-OS-000275-GPOS-00105

TBD - Assigned by DISA after STIG release

The operating system must notify system administrators and ISSOs when accounts are modified.

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to modify an existing account. Notification of account modification is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail which documents the modification of operating system user accounts and notifies the system administrator and ISSO of changes. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

CCI-000015

SRG-OS-000276-GPOS-00106

TBD - Assigned by DISA after STIG release

The operating system must notify system administrators and ISSOs when accounts are disabled.

When operating system accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual operating system users or for identifying the operating system processes themselves. Sending notification of account disabling events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that operating system accessibility will be negatively affected for extended periods of time and also provides logging that can be used for forensic purposes. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

CCI-000015

SRG-OS-000277-GPOS-00107

TBD - Assigned by DISA after STIG release

The operating system must notify system administrators and ISSOs when accounts are removed.

When operating system accounts are removed, user accessibility is affected. Accounts are utilized for identifying individual operating system users or for identifying the operating system processes themselves. Sending notification of account removal events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that operating system accessibility will be negatively affected for extended periods of time and also provides logging that can be used for forensic purposes. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

CCI-001496

SRG-OS-000278-GPOS-00108

TBD - Assigned by DISA after STIG release

The operating system must use cryptographic mechanisms to protect the integrity of audit tools.

Protecting the integrity of the tools used for auditing purposes is a critical step toward ensuring the integrity of audit information. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. It is not uncommon for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs. To address this risk, audit tools must be cryptographically signed in order to provide the capability to identify when the audit tools have been modified, manipulated, or replaced. An example is a checksum hash of the file or files.

Configure AIDE to Verify the Audit Tools

The operating system file integrity tool must be configured to protect the integrity of the audit tools.

CCI-002361

SRG-OS-000279-GPOS-00109

TBD - Assigned by DISA after STIG release

The operating system must automatically terminate a user session after inactivity time-outs have expired or at shutdown.

Automatic session termination addresses the termination of user-initiated logical sessions in contrast to the termination of network connections that are associated with communications sessions (i.e., network disconnect). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational information system. Such user sessions can be terminated (and thus terminate user access) without terminating network sessions. Session termination terminates all processes associated with a user's logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use. This capability is typically reserved for specific operating system functionality where the system owner, data owner, or organization requires additional assurance.

Set SSH Client Alive Interval

ClientAliveInterval

CCI-002363 SRG-OS-000280-GPOS-00110 TBD - Assigned by DISA after STIG release The operating system must provide a logoff capability for user-initiated communications sessions when requiring user access authentication. If a user cannot explicitly end an operating system session, the session may remain open and be exploited by an attacker; this is referred to as a zombie session. Information resources to which users gain access via authentication include, for example, local workstations and remote services. For some types of interactive sessions, including, for example, remote logon, information systems typically send logoff messages as final messages prior to terminating sessions.

CCI-002364 SRG-OS-000281-GPOS-00111 TBD - Assigned by DISA after STIG release The operating system must display an explicit logoff message to users indicating the reliable termination of authenticated communications sessions. If a user cannot explicitly end an operating system session, the session may remain open and be exploited by an attacker; this is referred to as a zombie session. Users need to be aware of whether or not the session has been terminated. Information resources to which users gain access via authentication include, for example, local workstations and remote services. Logoff messages can be displayed after authenticated sessions have been terminated. However, for some types of interactive sessions, including, for example, remote logon, information systems typically send logoff messages as final messages prior to terminating sessions.

CCI-002314

SRG-OS-000297-GPOS-00115

TBD - Assigned by DISA after STIG release

The operating system must control remote access methods.

Remote access services, such as those providing remote access to network devices and information systems, which lack automated control capabilities, increase risk and make remote user access management difficult at best. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Operating system functionality (e.g., RDP) must be capable of taking enforcement action if the audit reveals unauthorized activity. Automated control of remote access sessions allows organizations to ensure ongoing compliance with remote access policies by enforcing connection rules of remote access applications on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).

Configure the Firewalld Ports

Configure the firewalld ports to allow approved services to have access to the system. To configure firewalld to open ports, run the following command:

firewall-cmd --permanent --add-port=port_number/tcp

To configure firewalld to allow access for pre-defined services, run the following command:

firewall-cmd --permanent --add-service=service_name

Firewalld Must Employ a Deny-all, Allow-by-exception Policy for Allowing Connections to Other Systems

Red Hat Enterprise Linux 8 incorporates the "firewalld" daemon, which allows for many different configurations. One of these configurations is zones. Zones can be utilized to a deny-all, allow-by-exception approach. The default "drop" zone will drop all incoming network packets unless it is explicitly allowed by the configuration file or is related to an outgoing network connection.

Install firewalld Package

The firewalld package can be installed with the following command:

$ sudo yum install firewalld

Verify firewalld Enabled

The firewalld service can be enabled with the following command:

$ sudo systemctl enable firewalld.service

CCI-002322

SRG-OS-000298-GPOS-00116

TBD - Assigned by DISA after STIG release

The operating system must provide the capability to immediately disconnect or disable remote access to the operating system.

Without the ability to immediately disconnect or disable remote access, an attack or other compromise taking place would not be immediately stopped. Operating system remote access functionality must have the capability to immediately disconnect current users remotely accessing the information system and/or disable further remote access. The speed of disconnect or disablement varies based on the criticality of missions functions and the need to eliminate immediate or future remote access to organizational information systems. The remote access functionality (e.g., RDP) may implement features such as automatic disconnect (or user-initiated disconnect) in case of adverse information based on an indicator of compromise or attack.

Install firewalld Package

The firewalld package can be installed with the following command:

$ sudo yum install firewalld

CCI-001444

SRG-OS-000299-GPOS-00117

TBD - Assigned by DISA after STIG release

The operating system must protect wireless access to and from the system using encryption.

Allowing devices and users to connect to or from the system without first authenticating them allows untrusted access and can lead to a compromise or attack. Since wireless communications can be intercepted, it is necessary to use encryption to protect the confidentiality of information in transit. Wireless technologies include, for example, microwave, packet radio (UHF/VHF), 802.11x, and Bluetooth. Wireless networks use authentication protocols (e.g., EAP/TLS, PEAP), which provide credential protection and mutual authentication. This requirement applies to those operating systems that control wireless devices.

Deactivate Wireless Network Interfaces

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

Configure the system to disable all wireless network interfaces with the following command:

$ sudo nmcli radio all off

CCI-001443

SRG-OS-000300-GPOS-00118

TBD - Assigned by DISA after STIG release

The operating system must protect wireless access to the system using authentication of users and/or devices.

Allowing devices and users to connect to the system without first authenticating them allows untrusted access and can lead to a compromise or attack. Wireless technologies include, for example, microwave, packet radio (UHF/VHF), 802.11x, and Bluetooth. Wireless networks use authentication protocols (e.g., EAP/TLS, PEAP), which provide credential protection and mutual authentication. This requirement applies to those operating systems that control wireless devices.

Disable Bluetooth Kernel Module

install bluetooth /bin/true

Deactivate Wireless Network Interfaces

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

Configure the system to disable all wireless network interfaces with the following command:

$ sudo nmcli radio all off

CCI-002130

SRG-OS-000303-GPOS-00120

TBD - Assigned by DISA after STIG release

The operating system must audit all account enabling actions.

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to enable a new or disabled account. Auditing account modification actions provides logging that can be used for forensic purposes. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.

Ensure auditd Collects System Administrator Actions - /etc/sudoers

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Record Events that Modify User/Group Information - /etc/group

-w /etc/group -p wa -k audit_rules_usergroup_modification

-w /etc/group -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/gshadow

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/security/opasswd

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/shadow

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

CCI-000015

SRG-OS-000304-GPOS-00121

TBD - Assigned by DISA after STIG release

The operating system must notify system administrators (SAs) and information system security officers (ISSOs) of account enabling actions.

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to enable an existing disabled account. Sending notification of account enabling actions to the SA and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that operating system accessibility will be negatively affected for extended periods of time and also provides logging that can be used for forensic purposes. To detect and respond to events that affect user accessibility and application processing, operating systems must audit account enabling actions and, as required, notify the appropriate individuals so they can investigate the event. To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.

Ensure auditd Collects System Administrator Actions - /etc/sudoers

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Record Events that Modify User/Group Information - /etc/group

-w /etc/group -p wa -k audit_rules_usergroup_modification

-w /etc/group -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/gshadow

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/security/opasswd

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/shadow

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

CCI-002165

SRG-OS-000312-GPOS-00122

TBD - Assigned by DISA after STIG release

The operating system must allow operating system admins to pass information to any other operating system admin or user.

Discretionary Access Control (DAC) is based on the notion that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled file permissions. When discretionary access control policies are implemented, subjects are not constrained with regard to what actions they can take with information for which they have already been granted access. Thus, subjects that have been granted access to information are not prevented from passing (i.e., the subjects have the discretion to pass) the information to other subjects or objects. A subject that is constrained in its operation by Mandatory Access Control policies is still able to operate under the less rigorous constraints of this requirement. Thus, while Mandatory Access Control imposes constraints preventing a subject from passing information to another subject operating at a different sensitivity level, this requirement permits the subject to pass the information to any subject at the same sensitivity level. The policy is bounded by the information system boundary. Once the information is passed outside the control of the information system, additional means may be required to ensure the constraints remain in effect. While the older, more traditional definitions of discretionary access control require identity-based access control, that limitation is not required for this use of discretionary access control.

Enable Kernel Parameter to Enforce DAC on Hardlinks

To set the runtime status of the fs.protected_hardlinks kernel parameter, run the following command:

$ sudo sysctl -w fs.protected_hardlinks=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

fs.protected_hardlinks = 1

Enable Kernel Parameter to Enforce DAC on Symlinks

To set the runtime status of the fs.protected_symlinks kernel parameter, run the following command:

$ sudo sysctl -w fs.protected_symlinks=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

fs.protected_symlinks = 1

CCI-002165

SRG-OS-000312-GPOS-00123

TBD - Assigned by DISA after STIG release

The operating system must allow operating system admins to grant their privileges to other operating system admins.

Enable Kernel Parameter to Enforce DAC on Hardlinks

To set the runtime status of the fs.protected_hardlinks kernel parameter, run the following command:

$ sudo sysctl -w fs.protected_hardlinks=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

fs.protected_hardlinks = 1

Enable Kernel Parameter to Enforce DAC on Symlinks

To set the runtime status of the fs.protected_symlinks kernel parameter, run the following command:

$ sudo sysctl -w fs.protected_symlinks=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

fs.protected_symlinks = 1

CCI-002165 SRG-OS-000312-GPOS-00124 TBD - Assigned by DISA after STIG release The operating system must allow operating system admins to change security attributes on users, the operating system, or the operating systems components. Discretionary Access Control (DAC) is based on the notion that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled file permissions. When discretionary access control policies are implemented, subjects are not constrained with regard to what actions they can take with information for which they have already been granted access. Thus, subjects that have been granted access to information are not prevented from passing (i.e., the subjects have the discretion to pass) the information to other subjects or objects. A subject that is constrained in its operation by Mandatory Access Control policies is still able to operate under the less rigorous constraints of this requirement. Thus, while Mandatory Access Control imposes constraints preventing a subject from passing information to another subject operating at a different sensitivity level, this requirement permits the subject to pass the information to any subject at the same sensitivity level. The policy is bounded by the information system boundary. Once the information is passed outside the control of the information system, additional means may be required to ensure the constraints remain in effect. While the older, more traditional definitions of discretionary access control require identity-based access control, that limitation is not required for this use of discretionary access control.

CCI-002235

SRG-OS-000324-GPOS-00125

TBD - Assigned by DISA after STIG release

The operating system must prevent nonprivileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures.

Preventing non-privileged users from executing privileged functions mitigates the risk that unauthorized individuals or processes may gain unnecessary access to information or privileges. Privileged functions include, for example, establishing accounts, performing system integrity checks, or administering cryptographic key management activities. Non-privileged users are individuals that do not possess appropriate authorizations. Circumventing intrusion detection and prevention mechanisms or malicious code protection mechanisms are examples of privileged functions that require protection from non-privileged users.

Disable Ctrl-Alt-Del Burst Action

By default, SystemD will reboot the system if the Ctrl-Alt-Del key sequence is pressed Ctrl-Alt-Delete more than 7 times in 2 seconds.

To configure the system to ignore the CtrlAltDelBurstAction setting, add or modify the following to /etc/systemd/system.conf:

CtrlAltDelBurstAction=none

Disable Ctrl-Alt-Del Reboot Activation

By default, SystemD will reboot the system if the Ctrl-Alt-Del key sequence is pressed.

To configure the system to ignore the Ctrl-Alt-Del key sequence from the command line instead of rebooting the system, do either of the following:

ln -sf /dev/null /etc/systemd/system/ctrl-alt-del.target

systemctl mask ctrl-alt-del.target

Do not simply delete the /usr/lib/systemd/system/ctrl-alt-del.service file, as this file may be restored during future system updates.

Map System Users To The Appropriate SELinux Role

Configure the operating system to prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. All administrators must be mapped to the sysadm_u or staff_u users with the appropriate domains (sysadm_t and staff_t).

$ sudo semanage login -m -s sysadm_u USER

$ sudo semanage login -m -s staff_u USER

All authorized non-administrative users must be mapped to the user_u role or the appropriate domain (user_t).

$ sudo semanage login -m -s user_u USER

Disable debug-shell SystemD Service

SystemD's debug-shell service is intended to diagnose SystemD related boot issues with various systemctl commands. Once enabled and following a system reboot, the root shell will be available on tty9 which is access by pressing CTRL-ALT-F9. The debug-shell service should only be used for SystemD related issues and should otherwise be disabled.

By default, the debug-shell SystemD service is already disabled. The debug-shell service can be disabled with the following command:

$ sudo systemctl mask --now debug-shell.service

Enable Kernel Parameter to Enforce DAC on Hardlinks

To set the runtime status of the fs.protected_hardlinks kernel parameter, run the following command:

$ sudo sysctl -w fs.protected_hardlinks=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

fs.protected_hardlinks = 1

Enable Kernel Parameter to Enforce DAC on Symlinks

To set the runtime status of the fs.protected_symlinks kernel parameter, run the following command:

$ sudo sysctl -w fs.protected_symlinks=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

fs.protected_symlinks = 1

CCI-002233

SRG-OS-000326-GPOS-00126

TBD - Assigned by DISA after STIG release

The operating system must prevent all software from executing at higher privilege levels than users executing the software.

In certain situations, software applications/programs need to execute with elevated privileges to perform required functions. However, if the privileges required for execution are at a higher level than the privileges assigned to organizational users invoking such applications/programs, those users are indirectly provided with greater privileges than assigned by the organizations. Some programs and processes are required to operate at a higher privilege level and therefore should be excluded from the organization-defined software list after review.

Record Events When Privileged Executables Are Run

Verify the system generates an audit record when privileged functions are executed. If audit is using the "auditctl" tool to load the rules, run the following command:

$ sudo grep execve /etc/audit/audit.rules

If audit is using the "augenrules" tool to load the rules, run the following command:

$ sudo grep -r execve /etc/audit/rules.d

-a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k setuid

-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k setuid

-a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k setgid

-a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k setgid

If both the "b32" and "b64" audit rules for "SUID" files are not defined, this is a finding. If both the "b32" and "b64" audit rules for "SGID" files are not defined, this is a finding.

CCI-002234

SRG-OS-000327-GPOS-00127

TBD - Assigned by DISA after STIG release

The operating system must audit the execution of privileged functions.

Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information 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 threats and the advanced persistent threat.

Record Events When Privileged Executables Are Run

Verify the system generates an audit record when privileged functions are executed. If audit is using the "auditctl" tool to load the rules, run the following command:

$ sudo grep execve /etc/audit/audit.rules

If audit is using the "augenrules" tool to load the rules, run the following command:

$ sudo grep -r execve /etc/audit/rules.d

-a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k setuid

-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k setuid

-a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k setgid

-a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k setgid

If both the "b32" and "b64" audit rules for "SUID" files are not defined, this is a finding. If both the "b32" and "b64" audit rules for "SGID" files are not defined, this is a finding.

CCI-002238

SRG-OS-000329-GPOS-00128

TBD - Assigned by DISA after STIG release

The operating system must automatically lock an account until the locked account is released by an administrator when three unsuccessful logon attempts in 15 minutes occur.

By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account.

Lock Accounts Must Persist

This rule ensures that the system lock out accounts using pam_faillock.so persist after system reboot. From "pam_faillock" man pages:

Note that the default directory that "pam_faillock" uses is usually cleared on system
boot so the access will be reenabled after system reboot. If that is undesirable, a different
tally directory must be set with the "dir" option.

CCI-001914

SRG-OS-000337-GPOS-00129

TBD - Assigned by DISA after STIG release

The operating system must provide the capability for assigned IMOs/ISSOs or designated SAs to change the auditing to be performed on all operating system components, based on all selectable event criteria in near real time.

If authorized individuals do not have the ability to modify auditing parameters in response to a changing threat environment, the organization may not be able to effectively respond, and important forensic information may be lost. This requirement enables organizations to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve information system resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-001849

SRG-OS-000341-GPOS-00132

TBD - Assigned by DISA after STIG release

The operating system must allocate audit record storage capacity to store at least one week's worth of audit records, when audit records are not immediately sent to a central audit record storage facility.

In order to ensure operating systems have a sufficient storage capacity in which to write the audit logs, operating systems need to be able to allocate audit record storage capacity. The task of allocating audit record storage capacity is usually performed during initial installation of the operating system.

Configure a Sufficiently Large Partition for Audit Logs

The Red Hat Enterprise Linux 8 operating system must allocate audit record storage capacity to store at least one weeks worth of audit records when audit records are not immediately sent to a central audit record storage facility. The partition size needed to capture a week's worth of audit records is based on the activity level of the system and the total storage capacity available. In normal circumstances, 10.0 GB of storage space for audit records will be sufficient. Determine which partition the audit records are being written to with the following command:

$ sudo grep log_file /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log

Check the size of the partition that audit records are written to with the following command:

$ sudo df -h /var/log/audit/
/dev/sda2 24G 10.4G 13.6G 43% /var/log/audit

Extend Audit Backlog Limit for the Audit Daemon

GRUB_CMDLINE_LINUX="... audit_backlog_limit=8192 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="audit_backlog_limit=8192"

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

CCI-001851

SRG-OS-000342-GPOS-00133

TBD - Assigned by DISA after STIG release

The operating system must offload audit records onto a different system or media from the system being audited.

Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading is a common process in information systems with limited audit storage capacity.

Configure a Sufficiently Large Partition for Audit Logs

$ sudo grep log_file /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log

Check the size of the partition that audit records are written to with the following command:

$ sudo df -h /var/log/audit/
/dev/sda2 24G 10.4G 13.6G 43% /var/log/audit

Set type of computer node name logging in audit logs To configure Audit daemon to use a unique identifier as computer node name in the audit events, set name_format to in /etc/audit/auditd.conf.

Appropriate Action Must be Setup When the Internal Audit Event Queue is Full The audit system should have an action setup in the event the internal event queue becomes full. To setup an overflow action edit /etc/audit/auditd.conf. Set overflow_action to one of the following values: syslog, single, halt.

Ensure Rsyslog Authenticates Off-Loaded Audit Records

Rsyslogd is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with gnutls (which is a secure communications library implementing the SSL, TLS and DTLS protocols), and you have a method to securely encrypt and off-load auditing. When using rsyslogd to off-load logs the remote system must be authenticated. Set the following configuration option in /etc/rsyslog.conf or in a file in /etc/rsyslog.d (using legacy syntax):

$ActionSendStreamDriverAuthMode x509/name

Alternatively, use the RainerScript syntax:

action(type="omfwd" Target="some.example.com" StreamDriverAuthMode="x509/name")

Ensure Rsyslog Encrypts Off-Loaded Audit Records

Rsyslogd is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with gnutls (which is a secure communications library implementing the SSL, TLS and DTLS protocols), and you have a method to securely encrypt and off-load auditing. When using rsyslogd to off-load logs off a encrpytion system must be used. Set the following configuration option in /etc/rsyslog.conf or in a file in /etc/rsyslog.d (using legacy syntax):

$ActionSendStreamDriverMode 1

Alternatively, use the RainerScript syntax:

action(type="omfwd" ... StreamDriverMode="1")

Ensure Rsyslog Encrypts Off-Loaded Audit Records

Rsyslogd is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with gnutls (which is a secure communications library implementing the SSL, TLS and DTLS protocols), and you have a method to securely encrypt and off-load auditing. When using rsyslogd to off-load logs off an encryption system must be used. Set the following configuration option in /etc/rsyslog.conf or in a file in /etc/rsyslog.d (using legacy syntax):

$DefaultNetstreamDriver gtls

Alternatively, use the RainerScript syntax:

global(DefaultNetstreamDriver="gtls")

Ensure Logs Sent To Remote Host

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

*.* @

To use TCP for log message delivery:

*.* @@

To use RELP for log message delivery:

*.* :omrelp:

There must be a resolvable DNS CNAME or Alias record set to "_{" for logs to be sent correctly to the centralized logging utility.}

CCI-001855

SRG-OS-000343-GPOS-00134

TBD - Assigned by DISA after STIG release

The operating system must immediately notify the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of the repository maximum audit record storage capacity.

If security personnel are not notified immediately when storage volume reaches 75% utilization, they are unable to plan for audit record storage capacity expansion.

Configure auditd mail_acct Action on Low Disk Space

action_mail_acct =

Configure auditd space_left Action on Low Disk Space

The auditd service can be configured to take an action when disk space starts to run low. Edit the file /etc/audit/auditd.conf. Modify the following line, substituting ACTION appropriately:

space_left_action = ACTION

Possible values for ACTION are described in the auditd.conf man page. These include:

syslog
email
exec
suspend
single
halt

Set this to email (instead of the default, which is suspend) as it is more likely to get prompt attention. Acceptable values also include suspend, single, and halt.

Configure auditd space_left on Low Disk Space

space_left = PERCENTAGE%

Set this value to at least 25 to cause the system to notify the user of an issue.

CCI-001858 SRG-OS-000344-GPOS-00135 TBD - Assigned by DISA after STIG release The operating system must provide an immediate real-time alert to the SA and ISSO, at a minimum, of all audit failure events requiring real-time alerts. It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected. Alerts provide organizations with urgent messages. Real-time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less).

CCI-001875

SRG-OS-000348-GPOS-00136

TBD - Assigned by DISA after STIG release

The operating system must provide an audit reduction capability that supports on-demand audit review and analysis.

The ability to perform on-demand audit review and analysis, including after the audit data has been subjected to audit reduction, greatly facilitates the organization's ability to generate incident reports, as needed, to better handle larger-scale or more complex security incidents. Audit reduction is a technique used to reduce the volume of audit records in order to facilitate a manual review. Audit reduction does not alter original audit records. The report generation capability provided by the application must support on-demand (i.e., customizable, ad hoc, and as-needed) reports.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-001877

SRG-OS-000349-GPOS-00137

TBD - Assigned by DISA after STIG release

The operating system must provide an audit reduction capability that supports after-the-fact investigations of security incidents.

If the audit reduction capability does not support after-the-fact investigations, it is difficult to establish, correlate, and investigate the events leading up to an outage or attack or identify those responses for one. This capability is also required to comply with applicable Federal laws and DoD policies. Audit reduction capability must support after-the-fact investigations of security incidents either natively or through the use of third-party tools. This requirement is specific to operating systems with audit reduction capabilities.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-001878

SRG-OS-000350-GPOS-00138

TBD - Assigned by DISA after STIG release

The operating system must provide a report generation capability that supports on-demand audit review and analysis.

The report generation capability must support on-demand review and analysis in order to facilitate the organization's ability to generate incident reports, as needed, to better handle larger-scale or more complex security incidents. Report generation must be capable of generating on-demand (i.e., customizable, ad hoc, and as-needed) reports. On-demand reporting allows personnel to report issues more rapidly to more effectively meet reporting requirements. Collecting log data and aggregating it to present the data in a single, consolidated report achieves this objective.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-001879

SRG-OS-000351-GPOS-00139

TBD - Assigned by DISA after STIG release

The operating system must provide a report generation capability that supports on-demand reporting requirements.

The report generation capability must support on-demand reporting in order to facilitate the organization's ability to generate incident reports, as needed, to better handle larger-scale or more complex security incidents. Report generation must be capable of generating on-demand (i.e., customizable, ad hoc, and as-needed) reports. On-demand reporting allows personnel to report issues more rapidly to more effectively meet reporting requirements. Collecting log data and aggregating it to present the data in a single, consolidated report achieves this objective.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-001880

SRG-OS-000352-GPOS-00140

TBD - Assigned by DISA after STIG release

The operating system must provide a report generation capability that supports after-the-fact investigations of security incidents.

If the report generation capability does not support after-the-fact investigations, it is difficult to establish, correlate, and investigate the events leading up to an outage or attack or identify those responses for one. This capability is also required to comply with applicable Federal laws and DoD policies. The report generation capability must support after-the-fact investigations of security incidents either natively or through the use of third-party tools.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-001881

SRG-OS-000353-GPOS-00141

TBD - Assigned by DISA after STIG release

The operating system must not alter original content or time ordering of audit records when it provides an audit reduction capability.

If the audit reduction capability alters the content or time ordering of audit records, the integrity of the audit records is compromised, and the records are no longer usable for forensic analysis. Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. Time ordering refers to the chronological organization of records based on time stamps. The degree of time stamp precision can affect this. This requirement is specific to operating systems providing audit reduction capabilities. The audit reduction capability can be met either natively or through the use of third-party tools.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-001882

SRG-OS-000354-GPOS-00142

TBD - Assigned by DISA after STIG release

The operating system must not alter original content or time ordering of audit records when it provides a report generation capability.

If the report generation capability alters the content or time ordering of audit records, the integrity of the audit records is compromised, and the records are no longer usable for forensic analysis. Time ordering refers to the chronological organization of records based on time stamps. The degree of time stamp precision can affect this. This requirement is specific to operating systems providing report generation capabilities. The report generation capability can be met either natively or through the use of third-party tools.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-004923

SRG-OS-000355-GPOS-00143

TBD - Assigned by DISA after STIG release

The operating system must, for networked systems, compare internal information system clocks at least every 24 hours with a server which is synchronized to one of the redundant United States Naval Observatory (USNO) time servers, or a time server designated for the appropriate DOD network (NIPRNet/SIPRNet), and/or the Global Positioning System (GPS).

Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network. Organizations should consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints).

Configure Time Service Maxpoll Interval

The maxpoll should be configured to _{in /etc/ntp.conf or
/etc/chrony.conf (or /etc/chrony.d/) to continuously poll time servers. To configure
maxpoll in /etc/ntp.conf or /etc/chrony.conf (or /etc/chrony.d/)
add the following after each server, pool or peer entry:
maxpoll
to server directives. If using chrony, any pool directives
should be configured too.}

Ensure Chrony is only configured with the server directive Check that Chrony only has time sources configured with the server directive.

A remote time server for Chrony is configured

Chrony is a daemon which implements the Network Time Protocol (NTP). It is designed to synchronize system clocks across a variety of systems and use a source that is highly accurate. More information on chrony can be found at https://chrony-project.org/. Chrony can be configured to be a client and/or a server. Add or edit server or pool lines to /etc/chrony.conf as appropriate:

server <remote-server>

Multiple servers may be configured.

CCI-004926

SRG-OS-000356-GPOS-00144

TBD - Assigned by DISA after STIG release

The operating system must synchronize internal information system clocks to the authoritative time source when the time difference is greater than one second.

Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network. Organizations should consider setting time periods for different types of systems (e.g., financial, legal, or mission-critical systems). Organizations should also consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints). This requirement is related to the comparison done every 24 hours in SRG-OS-000355 because a comparison must be done in order to determine the time difference.

Configure Time Service Maxpoll Interval

Ensure Chrony is only configured with the server directive Check that Chrony only has time sources configured with the server directive.

CCI-001889

SRG-OS-000358-GPOS-00145

TBD - Assigned by DISA after STIG release

The operating system must record time stamps for audit records that meet a minimum granularity of one second for a minimum degree of precision.

Without sufficient granularity of time stamps, it is not possible to adequately determine the chronological order of records. Time stamps generated by the operating system include date and time. Granularity of time measurements refers to the degree of synchronization between information system clocks and reference clocks.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-001890

SRG-OS-000359-GPOS-00146

TBD - Assigned by DISA after STIG release

The operating system must record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT).

If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis. Time stamps generated by the operating system include date and time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC.

Configure Time Service Maxpoll Interval

Ensure Chrony is only configured with the server directive Check that Chrony only has time sources configured with the server directive.

CCI-000366 SRG-OS-000360-GPOS-00147 TBD - Assigned by DISA after STIG release The operating system must enforce dual authorization for movement and/or deletion of all audit information, when such movement or deletion is not part of an authorized automatic process. An authorized user may intentionally or accidentally move or delete audit records without those specific actions being authorized. All bulk manipulation of audit information must be authorized via automatic processes. Any manual manipulation of audit information must require dual authorization. Dual authorization mechanisms require the approval of two authorized individuals to execute.

CCI-003980 SRG-OS-000362-GPOS-00149 TBD - Assigned by DISA after STIG release The operating system must prohibit user installation of system software without explicit privileged status. Allowing regular users to install software, without explicit privileges, creates the risk that untested or potentially malicious software will be installed on the system. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceeds the rights of a regular user. Operating system functionality will vary, and while users are not permitted to install unapproved software, there may be instances where the organization allows the user to install approved software packages, such as from an approved software repository. The operating system or software configuration management utility must enforce control of software installation by users based upon what types of software installations are permitted (e.g., updates and security patches to existing software) and what types of installations are prohibited (e.g., software whose pedigree with regard to being potentially malicious is unknown or suspect) by the organization.

CCI-001744

SRG-OS-000363-GPOS-00150

TBD - Assigned by DISA after STIG release

The operating system must notify designated personnel if baseline configurations are changed in an unauthorized manner.

Unauthorized changes to the baseline configuration could make the system vulnerable to various attacks or allow unauthorized access to the operating system. Changes to operating system configurations can have unintended side effects, some of which may be relevant to security. Detecting such changes and providing an automated response can help avoid unintended, negative consequences that could ultimately affect the security state of the operating system. The operating system's IMO/ISSO and SAs must be notified via email and/or monitoring system trap when there is an unauthorized modification of a configuration item.

Configure Notification of Post-AIDE Scan Details

AIDE should notify appropriate personnel of the details of a scan after the scan has been run. If AIDE has already been configured for periodic execution in /etc/crontab, append the following line to the existing AIDE line:

 | /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost

Otherwise, add the following line to /etc/crontab:

05 4 * * * root /usr/sbin/aide --check | /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost

AIDE can be executed periodically through other means; this is merely one example.

The mailx Package Is Installed

A mail server is required for sending emails. The mailx package can be installed with the following command:

$ sudo yum install mailx

CCI-001813

SRG-OS-000364-GPOS-00151

TBD - Assigned by DISA after STIG release

The operating system must enforce access restrictions.

Failure to provide logical access restrictions associated with changes to system configuration may have significant effects on the overall security of the system. When dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the operating system can have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals should be allowed to obtain access to operating system components for the purposes of initiating changes, including upgrades and modifications. Logical access restrictions include, for example, controls that restrict access to workflow automation, media libraries, abstract layers (e.g., changes implemented into third-party interfaces rather than directly into information systems), and change windows (e.g., changes occur only during specified times, making unauthorized changes easy to discover).

Disable GSSAPI Authentication

Unless needed, SSH should not permit extraneous or unnecessary authentication mechanisms like GSSAPI.
The default SSH configuration disallows authentications based on GSSAPI. The appropriate configuration is used if no value is set for GSSAPIAuthentication.
To explicitly disable GSSAPI authentication, add or correct the following line in /etc/ssh/sshd_config:

GSSAPIAuthentication no

Disable Kerberos Authentication

Unless needed, SSH should not permit extraneous or unnecessary authentication mechanisms like Kerberos.
The default SSH configuration disallows authentication validation through Kerberos. The appropriate configuration is used if no value is set for KerberosAuthentication.
To explicitly disable Kerberos authentication, add or correct the following line in /etc/ssh/sshd_config:

KerberosAuthentication no

CCI-003938

SRG-OS-000365-GPOS-00152

TBD - Assigned by DISA after STIG release

The operating system must audit the enforcement actions used to restrict access associated with changes to the system.

Without auditing the enforcement of access restrictions against changes to the application configuration, it will be difficult to identify attempted attacks and an audit trail will not be available for forensic investigation for after-the-fact actions. Enforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after the fact.

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-003992

SRG-OS-000366-GPOS-00153

TBD - Assigned by DISA after STIG release

The operating system must prevent the installation of patches, service packs, device drivers, or operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization.

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

Ensure gpgcheck Enabled In Main yum Configuration

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

gpgcheck=1

Ensure gpgcheck Enabled for Local Packages yum should be configured to verify the signature(s) of local packages prior to installation. To configure yum to verify signatures of local packages, set the localpkg_gpgcheck to 1 in /etc/yum.conf.

Ensure gpgcheck Enabled for All yum Package Repositories

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

gpgcheck=0

Ensure Red Hat GPG Key Installed

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

$ sudo subscription-manager register

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

$ sudo rpm --import /media/cdrom/RPM-GPG-KEY

Alternatively, the key may be pre-loaded during the RHEL installation. In such cases, the key can be installed by running the following command:

sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

Disable Kernel Image Loading

To set the runtime status of the kernel.kexec_load_disabled kernel parameter, run the following command:

$ sudo sysctl -w kernel.kexec_load_disabled=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

kernel.kexec_load_disabled = 1

CCI-001764

SRG-OS-000368-GPOS-00154

TBD - Assigned by DISA after STIG release

The operating system must prevent program execution in accordance with local policies regarding software program usage and restrictions and/or rules authorizing the terms and conditions of software program usage.

Control of program execution is a mechanism used to prevent execution of unauthorized programs. Some operating systems may provide a capability that runs counter to the mission or provides users with functionality that exceeds mission requirements. This includes functions and services installed at the operating system-level. Some of the programs, installed by default, may be harmful or may not be necessary to support essential organizational operations (e.g., key missions, functions). Removal of executable programs is not always possible; therefore, establishing a method of preventing program execution is critical to maintaining a secure system baseline. Methods for complying with this requirement include restricting execution of programs in certain environments, while preventing execution in other environments; or limiting execution of certain program functionality based on organization-defined criteria (e.g., privileges, subnets, sandboxed environments, or roles).

Configure Fapolicy Module to Employ a Deny-all, Permit-by-exception Policy to Allow the Execution of Authorized Software Programs.

The Fapolicy module must be configured to employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs and to prevent unauthorized software from running.

Add nosuid Option to /boot The nosuid mount option can be used to prevent execution of setuid programs in /boot. The SUID and SGID permissions should not be required on the boot partition. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of /boot.

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

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

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

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

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

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

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

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

Add nodev Option to /var/log/audit The nodev mount option can be used to prevent device files from being created in /var/log/audit. Legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of /var/log/audit.

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

Add nosuid Option to /var/log/audit The nosuid mount option can be used to prevent execution of setuid programs in /var/log/audit. The SUID and SGID permissions should not be required in directories containing audit log files. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of /var/log/audit.

Add nodev Option to /var/log The nodev mount option can be used to prevent device files from being created in /var/log. Legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of /var/log.

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

Add nosuid Option to /var/log The nosuid mount option can be used to prevent execution of setuid programs in /var/log. The SUID and SGID permissions should not be required in directories containing log files. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of /var/log.

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

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

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

Install fapolicyd Package

The fapolicyd package can be installed with the following command:

$ sudo yum install fapolicyd

Enable the File Access Policy Service

The File Access Policy service should be enabled. The fapolicyd service can be enabled with the following command:

$ sudo systemctl enable fapolicyd.service

CCI-001774

SRG-OS-000370-GPOS-00155

TBD - Assigned by DISA after STIG release

The operating system must employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs.

Utilizing a whitelist provides a configuration management method for allowing the execution of only authorized software. Using only authorized software decreases risk by limiting the number of potential vulnerabilities. The organization must identify authorized software programs and permit execution of authorized software. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as whitelisting. Verification of white-listed software occurs prior to execution or at system startup. This requirement applies to operating system programs, functions, and services designed to manage system processes and configurations (e.g., group policies).

Configure Fapolicy Module to Employ a Deny-all, Permit-by-exception Policy to Allow the Execution of Authorized Software Programs.

The Fapolicy module must be configured to employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs and to prevent unauthorized software from running.

Disable the uvcvideo module

If the device contains a camera it should be covered or disabled when not in use.

Install fapolicyd Package

The fapolicyd package can be installed with the following command:

$ sudo yum install fapolicyd

Enable the File Access Policy Service

The File Access Policy service should be enabled. The fapolicyd service can be enabled with the following command:

$ sudo systemctl enable fapolicyd.service

CCI-004046

SRG-OS-000375-GPOS-00160

TBD - Assigned by DISA after STIG release

The operating system must implement multifactor authentication for remote access to privileged accounts in such a way that one of the factors is provided by a device separate from the system gaining access.

Using an authentication device, such as a common access card (CAC) or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification (PIV) card and the DOD CAC. A privileged account is defined as an information system account with authorizations of a privileged user. Remote access is access to DOD nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management).

Install Smart Card Packages For Multifactor Authentication

$ sudo yum install openssl-pkcs11

Install the opensc Package For Multifactor Authentication

The opensc package can be installed with the following command:

$ sudo yum install opensc

Certificate status checking in SSSD Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards. Configuring certificate_verification to ocsp_dgst= ensures that certificates for multifactor solutions are checked via Online Certificate Status Protocol (OCSP).

Enable Smartcards in SSSD

[pam]
pam_cert_auth = True

Add or update "pam_sss.so" line in auth section of "/etc/pam.d/system-auth" file to include "try_cert_auth" or "require_cert_auth" option, like in the following example:

/etc/pam.d/system-auth:auth [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_sss.so try_cert_auth

Also add or update "pam_sss.so" line in auth section of "/etc/pam.d/smartcard-auth" file to include the "allow_missing_name" option, like in the following example:

/etc/pam.d/smartcard-auth:auth sufficient pam_sss.so allow_missing_name

CCI-001953

SRG-OS-000376-GPOS-00161

TBD - Assigned by DISA after STIG release

The operating system must accept Personal Identity Verification (PIV) credentials.

The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access. DoD has mandated the use of the CAC to support identity management and personal authentication for systems covered under Homeland Security Presidential Directive (HSPD) 12, as well as making the CAC a primary component of layered protection for national security systems.

Install the opensc Package For Multifactor Authentication

The opensc package can be installed with the following command:

$ sudo yum install opensc

CCI-001954

SRG-OS-000377-GPOS-00162

TBD - Assigned by DISA after STIG release

The operating system must electronically verify Personal Identity Verification (PIV) credentials.

Install Smart Card Packages For Multifactor Authentication

$ sudo yum install openssl-pkcs11

CCI-001958

SRG-OS-000378-GPOS-00163

TBD - Assigned by DISA after STIG release

The operating system must authenticate peripherals before establishing a connection.

Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Peripherals include, but are not limited to, such devices as flash drives, external storage, and printers.

Disable Modprobe Loading of USB Storage Driver

install usb-storage /bin/false

To configure the system to prevent the usb-storage from being used, add the following line to file /etc/modprobe.d/usb-storage.conf:

blacklist usb-storage

This will prevent the modprobe program from loading the usb-storage module, but will not prevent an administrator (or another program) from using the insmod program to load the module manually.

Install usbguard Package

The usbguard package can be installed with the following command:

$ sudo yum install usbguard

Disable the Automounter

$ sudo systemctl mask --now autofs.service

Enable the USBGuard Service

The USBGuard service should be enabled. The usbguard service can be enabled with the following command:

$ sudo systemctl enable usbguard.service

Generate USBGuard Policy

By default USBGuard when enabled prevents access to all USB devices and this lead to inaccessible system if they use USB mouse/keyboard. To prevent this scenario, the initial policy configuration must be generated based on current connected USB devices.

CCI-001967 SRG-OS-000379-GPOS-00164 TBD - Assigned by DISA after STIG release The operating system must authenticate all endpoint devices before establishing a local, remote, and/or network connection using bidirectional authentication that is cryptographically based. Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Bidirectional authentication provides stronger safeguards to validate the identity of other devices for connections that are of greater risk. Bidirectional authentication solutions include, but are not limited to, IEEE 802.1x and Extensible Authentication Protocol [EAP], RADIUS server with EAP-Transport Layer Security [TLS] authentication, Kerberos, and SSL mutual authentication. A local connection is any connection with a device communicating without the use of a network. A network connection is any connection with a device that communicates through a network (e.g., local area network, wide area network, or the Internet). A remote connection is any connection with a device communicating through an external network (e.g., the Internet). Because of the challenges of applying this requirement on a large scale, organizations are encouraged to only apply this requirement to those limited number (and type) of devices that truly need to support this capability.

CCI-002007

SRG-OS-000383-GPOS-00166

TBD - Assigned by DISA after STIG release

The operating system must prohibit the use of cached authenticators after one day.

If cached authentication information is out-of-date, the validity of the authentication information may be questionable.

Configure SSSD to Expire Offline Credentials

SSSD should be configured to expire offline credentials after 1 day. Check if SSSD allows cached authentications with the following command:

$ sudo grep cache_credentials /etc/sssd/sssd.conf
cache_credentials = true

If "cache_credentials" is set to "false" or is missing no further checks are required.
To configure SSSD to expire offline credentials, set offline_credentials_expiration to 1 under the [pam] section in /etc/sssd/sssd.conf. For example:

[pam]
offline_credentials_expiration = 1

CCI-004068

SRG-OS-000384-GPOS-00167

TBD - Assigned by DISA after STIG release

The operating system, for PKI-based authentication, must implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network.

Without configuring a local cache of revocation data, there is the potential to allow access to users who are no longer authorized (users with revoked certificates).

SSSD Has a Correct Trust Anchor

SSSD must have acceptable trust anchor present.

CCI-002884

SRG-OS-000392-GPOS-00172

TBD - Assigned by DISA after STIG release

The operating system must audit all activities performed during nonlocal maintenance and diagnostic sessions.

If events associated with nonlocal administrative access or diagnostic sessions are not logged, a major tool for assessing and investigating attacks would not be available. This requirement addresses auditing-related issues associated with maintenance tools used specifically for diagnostic and repair actions on organizational information systems. Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. This requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system, for example, the software implementing "ping," "ls," "ipconfig," or the hardware and software implementing the monitoring port of an Ethernet switch.

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

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

Record Any Attempts to Run chacl

-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run chcon

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run semanage

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setfacl

-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setfiles

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setsebool

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects File Deletion Events by User - rename

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - renameat

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - rmdir

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlink

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlinkat

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects Information on Kernel Module Unloading - delete_module

To capture kernel module unloading events, use following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S delete_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module

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

-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules

-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on Kernel Module Loading - init_module

To capture kernel module loading events, use following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S init_module -F auid>=1000 -F auid!=unset -F key=modules

Record Attempts to Alter Logon and Logout Events - faillock

-w _{-p wa -k logins}

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:

-w _{-p wa -k logins}

Record Attempts to Alter Logon and Logout Events - lastlog

-w /var/log/lastlog -p wa -k logins

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:

-w /var/log/lastlog -p wa -k logins

Ensure auditd Collects Information on Exporting to Media (successful)

-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export

-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export

Ensure auditd Collects Information on the Use of Privileged Commands - chage

-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - chsh

-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - crontab

-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - gpasswd

-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - kmod

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - mount

-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - newgrp

-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - pam_timestamp_check

-a always,exit -F path=/usr/sbin/pam_timestamp_check
-F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/pam_timestamp_check
-F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - passwd

-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - postdrop

-a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - postqueue

-a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run ssh-agent

-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-agent

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-agent

Ensure auditd Collects Information on the Use of Privileged Commands - ssh-keysign

-a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - su

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - sudo

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - umount

-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - unix_chkpwd

-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - unix_update

-a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - userhelper

-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - usermod

-a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects System Administrator Actions - /etc/sudoers

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Record Unsuccessful Access Attempts to Files - creat

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - ftruncate

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open_by_handle_at

-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - openat

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - truncate

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Events that Modify User/Group Information - /etc/group

-w /etc/group -p wa -k audit_rules_usergroup_modification

-w /etc/group -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/gshadow

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/security/opasswd

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/shadow

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

Enable Auditing for Processes Which Start Prior to the Audit Daemon

GRUB_CMDLINE_LINUX="... audit=1 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="audit=1"

Extend Audit Backlog Limit for the Audit Daemon

GRUB_CMDLINE_LINUX="... audit_backlog_limit=8192 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="audit_backlog_limit=8192"

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-002890

SRG-OS-000393-GPOS-00173

TBD - Assigned by DISA after STIG release

The operating system must implement cryptographic mechanisms to protect the integrity of nonlocal maintenance and diagnostic communications, when used for nonlocal maintenance sessions.

Privileged access contains control and configuration information and is particularly sensitive, so additional protections are necessary. This is maintained by using cryptographic mechanisms, such as a hash function or digital signature, to protect integrity. Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. The operating system can meet this requirement through leveraging a cryptographic module. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system (e.g., the software implementing "ping," "ls," "ipconfig," or the hardware and software implementing the monitoring port of an Ethernet switch).

Configure System Cryptography Policy

To configure the system cryptography policy to use ciphers only from the policy, run the following command:

$ sudo update-crypto-policies --set

The rule checks if settings for selected crypto policy are configured as expected. Configuration files in the /etc/crypto-policies/back-ends are either symlinks to correct files provided by Crypto-policies package or they are regular files in case crypto policy customizations are applied. Crypto policies may be customized by crypto policy modules, in which case it is delimited from the base policy using a colon.

Configure OpenSSL library to use TLS Encryption

$ sudo grep -i MinProtocol /etc/crypto-policies/back-ends/opensslcnf.config

MinProtocol = TLSv1.2

Or for version crypto-policies-20210617-1.gitc776d3e.el8.noarch and newer this is expected:

$ sudo grep -i MinProtocol /etc/crypto-policies/back-ends/opensslcnf.config

TLS.MinProtocol = TLSv1.2
DTLS.MinProtocol = DTLSv1.2

Configure SSH Client to Use FIPS 140-2 Validated Ciphers: openssh.config

Ciphers

Set kernel parameter 'crypto.fips_enabled' to 1

System running in FIPS mode is indicated by kernel parameter 'crypto.fips_enabled'. This parameter should be set to 1 in FIPS mode. To enable FIPS mode, run the following command:

fips-mode-setup --enable

CCI-003123

SRG-OS-000394-GPOS-00174

TBD - Assigned by DISA after STIG release

The operating system must implement cryptographic mechanisms to protect the confidentiality of nonlocal maintenance and diagnostic communications, when used for nonlocal maintenance sessions.

Privileged access contains control and configuration information and is particularly sensitive, so additional protections are necessary. This is maintained by using cryptographic mechanisms such as encryption to protect confidentiality. Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the Internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. This requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system (e.g., the software implementing "ping," "ls," "ipconfig," or the hardware and software implementing the monitoring port of an Ethernet switch). The operating system can meet this requirement through leveraging a cryptographic module.

Configure System Cryptography Policy

To configure the system cryptography policy to use ciphers only from the policy, run the following command:

$ sudo update-crypto-policies --set

Configure OpenSSL library to use TLS Encryption

$ sudo grep -i MinProtocol /etc/crypto-policies/back-ends/opensslcnf.config

MinProtocol = TLSv1.2

Or for version crypto-policies-20210617-1.gitc776d3e.el8.noarch and newer this is expected:

$ sudo grep -i MinProtocol /etc/crypto-policies/back-ends/opensslcnf.config

TLS.MinProtocol = TLSv1.2
DTLS.MinProtocol = DTLSv1.2

Configure SSH Client to Use FIPS 140-2 Validated Ciphers: openssh.config

Ciphers

Set kernel parameter 'crypto.fips_enabled' to 1

System running in FIPS mode is indicated by kernel parameter 'crypto.fips_enabled'. This parameter should be set to 1 in FIPS mode. To enable FIPS mode, run the following command:

fips-mode-setup --enable

CCI-002891

SRG-OS-000395-GPOS-00175

TBD - Assigned by DISA after STIG release

The operating system must verify remote disconnection at the termination of nonlocal maintenance and diagnostic sessions, when used for nonlocal maintenance sessions.

If the remote connection is not closed and verified as closed, the session may remain open and be exploited by an attacker; this is referred to as a zombie session. Remote connections must be disconnected and verified as disconnected when nonlocal maintenance sessions have been terminated and are no longer available for use.

Set SSH Client Alive Interval

ClientAliveInterval

CCI-002450

SRG-OS-000396-GPOS-00176

TBD - Assigned by DISA after STIG release

The operating system must implement NSA-approved cryptography to protect classified information in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.

Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.

Configure System Cryptography Policy

To configure the system cryptography policy to use ciphers only from the policy, run the following command:

$ sudo update-crypto-policies --set

Enable FIPS Mode

To enable FIPS mode, run the following command:

fips-mode-setup --enable

The fips-mode-setup command will configure the system in FIPS mode by automatically configuring the following:

Setting the kernel FIPS mode flag (/proc/sys/crypto/fips_enabled) to 1
Creating /etc/system-fips
Setting the system crypto policy in /etc/crypto-policies/config to
Loading the Dracut fips module

Set kernel parameter 'crypto.fips_enabled' to 1

System running in FIPS mode is indicated by kernel parameter 'crypto.fips_enabled'. This parameter should be set to 1 in FIPS mode. To enable FIPS mode, run the following command:

fips-mode-setup --enable

CCI-002470 SRG-OS-000403-GPOS-00182 TBD - Assigned by DISA after STIG release The operating system must only allow the use of DoD PKI-established certificate authorities for authentication in the establishment of protected sessions to the operating system. Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoD-approved CA, trust of this CA has not been established. The DoD will only accept PKI-certificates obtained from a DoD-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of SSL/TLS certificates.

CCI-002475

SRG-OS-000404-GPOS-00183

TBD - Assigned by DISA after STIG release

The operating system must implement cryptographic mechanisms to prevent unauthorized modification of all information at rest on all operating system components.

Operating systems handling data requiring "data at rest" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest. Selection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields).

Encrypt Partitions

part / --fstype=ext4 --size=100 --onpart=hda1 --encrypted --passphrase=PASSPHRASE

CCI-002476

SRG-OS-000405-GPOS-00184

TBD - Assigned by DISA after STIG release

The operating system must implement cryptographic mechanisms to prevent unauthorized disclosure of all information at rest on all operating system components.

Encrypt Partitions

part / --fstype=ext4 --size=100 --onpart=hda1 --encrypted --passphrase=PASSPHRASE

CCI-002385

SRG-OS-000420-GPOS-00186

TBD - Assigned by DISA after STIG release

The operating system must protect against or limit the effects of Denial of Service (DoS) attacks by ensuring the operating system is implementing rate-limiting measures on impacted network interfaces.

DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. This requirement addresses the configuration of the operating system to mitigate the impact of DoS attacks that have occurred or are ongoing on system availability. For each system, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or establishing memory partitions). Employing increased capacity and bandwidth, combined with service redundancy, may reduce the susceptibility to some DoS attacks.

Configure Firewalld to Use the Nftables Backend

Firewalld can be configured with many backends, such as nftables.

CCI-002418

SRG-OS-000423-GPOS-00187

TBD - Assigned by DISA after STIG release

The operating system must protect the confidentiality and integrity of transmitted information.

Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered. This requirement applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa.

Configure BIND to use System Crypto Policy Crypto Policies provide a centralized control over crypto algorithms usage of many packages. BIND is supported by crypto policy, but the BIND configuration may be set up to ignore it. To check that Crypto Policies settings are configured correctly, ensure that the /etc/named.conf includes the appropriate configuration: In the options section of /etc/named.conf, make sure that the following line is not commented out or superseded by later includes: include "/etc/crypto-policies/back-ends/bind.config";

Configure SSH Client to Use FIPS 140-2 Validated Ciphers: openssh.config

Ciphers

Install the OpenSSH Server Package

The openssh-server package should be installed. The openssh-server package can be installed with the following command:

$ sudo yum install openssh-server

Enable the OpenSSH Service

The SSH server service, sshd, is commonly needed. The sshd service can be enabled with the following command:

$ sudo systemctl enable sshd.service

Set kernel parameter 'crypto.fips_enabled' to 1

System running in FIPS mode is indicated by kernel parameter 'crypto.fips_enabled'. This parameter should be set to 1 in FIPS mode. To enable FIPS mode, run the following command:

fips-mode-setup --enable

CCI-002421

SRG-OS-000424-GPOS-00188

TBD - Assigned by DISA after STIG release

The operating system must implement cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission unless otherwise protected by alternative physical safeguards, such as, at a minimum, a Protected Distribution System (PDS).

Encrypting information for transmission protects information from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic hash functions which have common application in digital signatures, checksums, and message authentication codes. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, operating systems need to leverage transmission protection mechanisms such as TLS, SSL VPNs, or IPSec. Alternative physical protection measures include PDS. PDSs are used to transmit unencrypted classified National Security Information (NSI) through an area of lesser classification or control. Since the classified NSI is unencrypted, the PDS must provide adequate electrical, electromagnetic, and physical safeguards to deter exploitation.

Install the OpenSSH Server Package

The openssh-server package should be installed. The openssh-server package can be installed with the following command:

$ sudo yum install openssh-server

Enable the OpenSSH Service

The SSH server service, sshd, is commonly needed. The sshd service can be enabled with the following command:

$ sudo systemctl enable sshd.service

Deactivate Wireless Network Interfaces

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

Configure the system to disable all wireless network interfaces with the following command:

$ sudo nmcli radio all off

CCI-002420

SRG-OS-000425-GPOS-00189

TBD - Assigned by DISA after STIG release

The operating system must maintain the confidentiality and integrity of information during preparation for transmission.

Information can be either unintentionally or maliciously disclosed or modified during preparation for transmission, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information. Ensuring the confidentiality of transmitted information requires the operating system to take measures in preparing information for transmission. This can be accomplished via access control and encryption. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, operating systems need to support transmission protection mechanisms such as TLS, SSL VPNs, or IPSec.

Install the OpenSSH Server Package

The openssh-server package should be installed. The openssh-server package can be installed with the following command:

$ sudo yum install openssh-server

Enable the OpenSSH Service

The SSH server service, sshd, is commonly needed. The sshd service can be enabled with the following command:

$ sudo systemctl enable sshd.service

CCI-002422

SRG-OS-000426-GPOS-00190

TBD - Assigned by DISA after STIG release

The operating system must maintain the confidentiality and integrity of information during reception.

Information can be either unintentionally or maliciously disclosed or modified during reception, including, for example, during aggregation, at protocol transformation points, and during packing/unpacking. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information. Ensuring the confidentiality of transmitted information requires the operating system to take measures in preparing information for transmission. This can be accomplished via access control and encryption. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When receiving data, operating systems need to leverage protection mechanisms such as TLS, SSL VPNs, or IPSec.

Install the OpenSSH Server Package

The openssh-server package should be installed. The openssh-server package can be installed with the following command:

$ sudo yum install openssh-server

Enable the OpenSSH Service

The SSH server service, sshd, is commonly needed. The sshd service can be enabled with the following command:

$ sudo systemctl enable sshd.service

CCI-002754 SRG-OS-000432-GPOS-00191 TBD - Assigned by DISA after STIG release The operating system must behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received. A common vulnerability of operating system is unpredictable behavior when invalid inputs are received. This requirement guards against adverse or unintended system behavior caused by invalid inputs, where information system responses to the invalid input may be disruptive or cause the system to fail into an unsafe state. The behavior will be derived from the organizational and system requirements and includes, but is not limited to, notification of the appropriate personnel, creating an audit record, and rejecting invalid input.

CCI-002824

SRG-OS-000433-GPOS-00192

TBD - Assigned by DISA after STIG release

The operating system must implement non-executable data to protect its memory from unauthorized code execution.

Some adversaries launch attacks with the intent of executing code in non-executable regions of memory or in memory locations that are prohibited. Security safeguards employed to protect memory include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can either be hardware-enforced or software-enforced with hardware providing the greater strength of mechanism. Examples of attacks are buffer overflow attacks.

Enable NX or XD Support in the BIOS

Reboot the system and enter the BIOS or Setup configuration menu. Navigate the BIOS configuration menu and make sure that the option is enabled. The setting may be located under a Security section. Look for Execute Disable (XD) on Intel-based systems and No Execute (NX) on AMD-based systems.

Enable SLUB/SLAB allocator poisoning

GRUB_CMDLINE_LINUX="... slub_debug=_..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="slub_debug=_"

Restrict Exposed Kernel Pointer Addresses Access

To set the runtime status of the kernel.kptr_restrict kernel parameter, run the following command:

$ sudo sysctl -w kernel.kptr_restrict=

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

kernel.kptr_restrict =

CCI-002824

SRG-OS-000433-GPOS-00193

TBD - Assigned by DISA after STIG release

The operating system must implement address space layout randomization to protect its memory from unauthorized code execution.

Enable Kernel Page-Table Isolation (KPTI)

GRUB_CMDLINE_LINUX="... pti=on ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="pti=on"

Enable Randomized Layout of Virtual Address Space

To set the runtime status of the kernel.randomize_va_space kernel parameter, run the following command:

$ sudo sysctl -w kernel.randomize_va_space=2

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

kernel.randomize_va_space = 2

CCI-002617

SRG-OS-000437-GPOS-00194

TBD - Assigned by DISA after STIG release

The operating system must remove all software components after updated versions have been installed.

Previous versions of software components that are not removed from the information system after updates have been installed may be exploited by adversaries. Some information technology products may remove older versions of software automatically from the information system.

Ensure yum Removes Previous Package Versions yum should be configured to remove previous software components after new versions have been installed. To configure yum to remove the previous software components after updating, set the clean_requirements_on_remove to 1 in /etc/yum.conf.

CCI-002696

SRG-OS-000445-GPOS-00199

TBD - Assigned by DISA after STIG release

The operating system must verify correct operation of all security functions.

Without verification of the security functions, security functions may not operate correctly and the failure may go unnoticed. Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. This requirement applies to operating systems performing security function verification/testing and/or systems and environments that require this functionality.

Build and Test AIDE Database

Run the following command to generate a new database:

$ sudo /usr/sbin/aide --init

By default, the database will be written to the file /var/lib/aide/aide.db.new.gz. Storing the database, the configuration file /etc/aide.conf, and the binary /usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity. The newly-generated database can be installed as follows:

$ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

To initiate a manual check, run the following command:

$ sudo /usr/sbin/aide --check

If this check produces any unexpected output, investigate.

Install AIDE

The aide package can be installed with the following command:

$ sudo yum install aide

Configure SELinux Policy

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

SELINUXTYPE=

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

Ensure SELinux State is Enforcing

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

SELINUX=

CCI-002699

SRG-OS-000446-GPOS-00200

TBD - Assigned by DISA after STIG release

The operating system must perform verification of the correct operation of security functions: upon system start-up and/or restart; upon command by a user with privileged access; and/or every 30 days.

Without verification of the security functions, security functions may not operate correctly and the failure may go unnoticed. Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Notifications provided by information systems include, for example, electronic alerts to system administrators, messages to local computer consoles, and/or hardware indications, such as lights. This requirement applies to operating systems performing security function verification/testing and/or systems and environments that require this functionality.

Configure Notification of Post-AIDE Scan Details

 | /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost

Otherwise, add the following line to /etc/crontab:

05 4 * * * root /usr/sbin/aide --check | /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost

AIDE can be executed periodically through other means; this is merely one example.

CCI-002702

SRG-OS-000447-GPOS-00201

TBD - Assigned by DISA after STIG release

The operating system must shut down the information system, restart the information system, and/or notify the system administrator when anomalies in the operation of any security functions are discovered.

If anomalies are not acted upon, security functions may fail to secure the system. Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Notifications provided by information systems include messages to local computer consoles, and/or hardware indications, such as lights. This capability must take into account operational requirements for availability for selecting an appropriate response. The organization may choose to shut down or restart the information system upon security function anomaly detection.

Configure Notification of Post-AIDE Scan Details

 | /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost

Otherwise, add the following line to /etc/crontab:

05 4 * * * root /usr/sbin/aide --check | /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost

AIDE can be executed periodically through other means; this is merely one example.

CCI-000172

SRG-OS-000458-GPOS-00203

TBD - Assigned by DISA after STIG release

The operating system must generate audit records when successful/unsuccessful attempts to access security objects occur.

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

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

Record Unsuccessful Access Attempts to Files - creat

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - ftruncate

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open_by_handle_at

-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - openat

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - truncate

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

CCI-000172

SRG-OS-000461-GPOS-00205

TBD - Assigned by DISA after STIG release

The operating system must generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur.

Record Unsuccessful Access Attempts to Files - creat

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - ftruncate

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open_by_handle_at

-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - openat

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - truncate

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

CCI-000172

SRG-OS-000462-GPOS-00206

TBD - Assigned by DISA after STIG release

The operating system must generate audit records when successful/unsuccessful attempts to modify privileges occur.

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

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

Record Any Attempts to Run chacl

-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run chcon

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run semanage

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setfacl

-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setfiles

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setsebool

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects File Deletion Events by User - rename

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - renameat

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - rmdir

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlink

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlinkat

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

Configure immutable Audit login UIDs

--loginuid-immutable

--loginuid-immutable

Ensure auditd Collects Information on Kernel Module Unloading - delete_module

To capture kernel module unloading events, use following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S delete_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module

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

-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules

-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on Kernel Module Loading - init_module

To capture kernel module loading events, use following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S init_module -F auid>=1000 -F auid!=unset -F key=modules

Record Attempts to Alter Logon and Logout Events - lastlog

-w /var/log/lastlog -p wa -k logins

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:

-w /var/log/lastlog -p wa -k logins

Ensure auditd Collects Information on Exporting to Media (successful)

-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export

-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export

Ensure auditd Collects Information on the Use of Privileged Commands - chage

-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - chsh

-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - crontab

-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - gpasswd

-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - kmod

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - mount

-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - newgrp

-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - pam_timestamp_check

-a always,exit -F path=/usr/sbin/pam_timestamp_check
-F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/pam_timestamp_check
-F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - passwd

-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - postdrop

-a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - postqueue

-a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run ssh-agent

-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-agent

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-agent

Ensure auditd Collects Information on the Use of Privileged Commands - ssh-keysign

-a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - su

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - sudo

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - umount

-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - unix_chkpwd

-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - unix_update

-a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - userhelper

-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - usermod

-a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects System Administrator Actions - /etc/sudoers

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Record Unsuccessful Access Attempts to Files - creat

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - ftruncate

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open_by_handle_at

-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - openat

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - truncate

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

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

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Events that Modify User/Group Information - /etc/group

-w /etc/group -p wa -k audit_rules_usergroup_modification

-w /etc/group -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/gshadow

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/security/opasswd

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/shadow

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

Enable Auditing for Processes Which Start Prior to the Audit Daemon

GRUB_CMDLINE_LINUX="... audit=1 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="audit=1"

Extend Audit Backlog Limit for the Audit Daemon

GRUB_CMDLINE_LINUX="... audit_backlog_limit=8192 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="audit_backlog_limit=8192"

CCI-000172

SRG-OS-000463-GPOS-00207

TBD - Assigned by DISA after STIG release

The operating system must generate audit records when successful/unsuccessful attempts to modify security objects occur.

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

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

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

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

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -F key=perm_mod

Record Any Attempts to Run chcon

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run semanage

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setfiles

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setsebool

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

CCI-000172

SRG-OS-000465-GPOS-00209

TBD - Assigned by DISA after STIG release

The operating system must generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur.

Record Any Attempts to Run chcon

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run semanage

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setfiles

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setsebool

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

CCI-000172

SRG-OS-000466-GPOS-00210

TBD - Assigned by DISA after STIG release

The operating system must generate audit records when successful/unsuccessful attempts to delete privileges occur.

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

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

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

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

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

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

Record Any Attempts to Run chacl

-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects File Deletion Events by User - rename

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - renameat

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - rmdir

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlink

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlinkat

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects Information on the Use of Privileged Commands - su

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - sudo

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - usermod

-a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects System Administrator Actions - /etc/sudoers

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Record Events that Modify User/Group Information - /etc/group

-w /etc/group -p wa -k audit_rules_usergroup_modification

-w /etc/group -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/gshadow

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/security/opasswd

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/shadow

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

CCI-000172

SRG-OS-000467-GPOS-00211

TBD - Assigned by DISA after STIG release

The operating system must generate audit records when successful/unsuccessful attempts to delete security levels occur.

Ensure auditd Collects File Deletion Events by User - rename

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - renameat

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - rmdir

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlink

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlinkat

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

CCI-000172

SRG-OS-000468-GPOS-00212

TBD - Assigned by DISA after STIG release

The operating system must generate audit records when successful/unsuccessful attempts to delete security objects occur.

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

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

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

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

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -F key=perm_mod

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

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

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

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

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

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

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

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

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -F key=perm_mod

Record Any Attempts to Run chcon

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects File Deletion Events by User - rename

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - renameat

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - rmdir

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlink

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlinkat

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects Information on the Use of Privileged Commands - chage

-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

CCI-000172

SRG-OS-000470-GPOS-00214

TBD - Assigned by DISA after STIG release

The operating system must generate audit records when successful/unsuccessful logon attempts occur.

Record Attempts to Alter Logon and Logout Events - faillock

-w _{-p wa -k logins}

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:

-w _{-p wa -k logins}

Record Attempts to Alter Logon and Logout Events - lastlog

-w /var/log/lastlog -p wa -k logins

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:

-w /var/log/lastlog -p wa -k logins

Ensure auditd Collects System Administrator Actions - /etc/sudoers

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/

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

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

Record Events that Modify User/Group Information - /etc/group

-w /etc/group -p wa -k audit_rules_usergroup_modification

-w /etc/group -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/gshadow

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/security/opasswd

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/shadow

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

CCI-000172

SRG-OS-000471-GPOS-00215

TBD - Assigned by DISA after STIG release

The operating system must generate audit records for privileged activities or other system-level access.

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

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

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

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

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - chown

-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - fchmod

-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - fchmodat

-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - fchown

-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - fchownat

-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - fremovexattr

At a minimum, the audit system should collect file permission changes for all users and root.

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - fsetxattr

-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - lchown

-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - lremovexattr

At a minimum, the audit system should collect file permission changes for all users and root.

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - lsetxattr

-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - removexattr

At a minimum, the audit system should collect file permission changes for all users and root.

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - setxattr

-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S setxattr -F auid=0 -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S setxattr -F auid=0 -F key=perm_mod

Record Any Attempts to Run chacl

-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run chcon

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run semanage

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setfacl

-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setfiles

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run setsebool

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects File Deletion Events by User - rename

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - renameat

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - rmdir

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlink

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects File Deletion Events by User - unlinkat

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete

Ensure auditd Collects Information on Kernel Module Unloading - delete_module

To capture kernel module unloading events, use following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S delete_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system:

-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules

-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on Kernel Module Loading - init_module

To capture kernel module loading events, use following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S init_module -F auid>=1000 -F auid!=unset -F key=modules

Record Attempts to Alter Logon and Logout Events - lastlog

-w /var/log/lastlog -p wa -k logins

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:

-w /var/log/lastlog -p wa -k logins

Ensure auditd Collects Information on Exporting to Media (successful)

-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export

-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export

Ensure auditd Collects Information on the Use of Privileged Commands - chage

-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - chsh

-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - crontab

-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - gpasswd

-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - kmod

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - mount

-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - newgrp

-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - pam_timestamp_check

-a always,exit -F path=/usr/sbin/pam_timestamp_check
-F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/pam_timestamp_check
-F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - passwd

-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - postdrop

-a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - postqueue

-a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Any Attempts to Run ssh-agent

-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-agent

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh-agent

Ensure auditd Collects Information on the Use of Privileged Commands - ssh-keysign

-a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - su

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - sudo

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - umount

-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - unix_chkpwd

-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - unix_update

-a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - userhelper

-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - usermod

-a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects System Administrator Actions - /etc/sudoers

-w /etc/sudoers -p wa -k actions

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-w /etc/sudoers -p wa -k actions

Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/

-w /etc/sudoers.d/ -p wa -k actions

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-w /etc/sudoers.d/ -p wa -k actions

Record Unsuccessful Access Attempts to Files - creat

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the system is 64 bit then also add the following lines:

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the system is 64 bit then also add the following lines:

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - ftruncate

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the system is 64 bit then also add the following lines:

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the system is 64 bit then also add the following lines:

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the system is 64 bit then also add the following lines:

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the system is 64 bit then also add the following lines:

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - open_by_handle_at

-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the system is 64 bit then also add the following lines:

-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the system is 64 bit then also add the following lines:

-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - openat

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the system is 64 bit then also add the following lines:

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the system is 64 bit then also add the following lines:

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Unsuccessful Access Attempts to Files - truncate

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the system is 64 bit then also add the following lines:

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

If the system is 64 bit then also add the following lines:

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access

Record Events that Modify User/Group Information - /etc/group

-w /etc/group -p wa -k audit_rules_usergroup_modification

-w /etc/group -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/gshadow

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/security/opasswd

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/shadow

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

Enable Auditing for Processes Which Start Prior to the Audit Daemon

GRUB_CMDLINE_LINUX="... audit=1 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="audit=1"

Extend Audit Backlog Limit for the Audit Daemon

GRUB_CMDLINE_LINUX="... audit_backlog_limit=8192 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="audit_backlog_limit=8192"

CCI-000172

SRG-OS-000471-GPOS-00216

TBD - Assigned by DISA after STIG release

The audit system must be configured to audit the loading and unloading of dynamic kernel modules.

Ensure auditd Collects Information on Kernel Module Unloading - delete_module

To capture kernel module unloading events, use following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S delete_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system:

-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules

-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on Kernel Module Loading - init_module

To capture kernel module loading events, use following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S init_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on the Use of Privileged Commands - kmod

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

CCI-000172 SRG-OS-000472-GPOS-00217 TBD - Assigned by DISA after STIG release The operating system must generate audit records showing starting and ending time for user access to the system. Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter).

CCI-000172

SRG-OS-000473-GPOS-00218

TBD - Assigned by DISA after STIG release

The operating system must generate audit records when concurrent logons to the same account occur from different sources.

Record Attempts to Alter Logon and Logout Events - faillock

-w _{-p wa -k logins}

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:

-w _{-p wa -k logins}

Record Attempts to Alter Logon and Logout Events - lastlog

-w /var/log/lastlog -p wa -k logins

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file in order to watch for unattempted manual edits of files involved in storing logon events:

-w /var/log/lastlog -p wa -k logins

Enable Auditing for Processes Which Start Prior to the Audit Daemon

GRUB_CMDLINE_LINUX="... audit=1 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="audit=1"

CCI-000172

SRG-OS-000474-GPOS-00219

TBD - Assigned by DISA after STIG release

The operating system must generate audit records when successful/unsuccessful accesses to objects occur.

Record Events that Modify the System's Discretionary Access Controls - chown

-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - fchown

-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - fchownat

-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - fremovexattr

At a minimum, the audit system should collect file permission changes for all users and root.

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - fsetxattr

-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - lchown

-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - lremovexattr

At a minimum, the audit system should collect file permission changes for all users and root.

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - lsetxattr

-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -F key=perm_mod

If the system is 64 bit then also add the following line:

-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -F key=perm_mod

Record Events that Modify the System's Discretionary Access Controls - removexattr

At a minimum, the audit system should collect file permission changes for all users and root.

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:

-a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b32 -S removexattr -F auid=0 -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!=unset -F key=perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -F key=perm_mod

CCI-000172

SRG-OS-000475-GPOS-00220

TBD - Assigned by DISA after STIG release

The operating system must generate audit records for all direct access to the information system.

Configure immutable Audit login UIDs

--loginuid-immutable

--loginuid-immutable

Ensure the audit Subsystem is Installed

The audit package should be installed.

Enable auditd Service

$ sudo systemctl enable auditd.service

CCI-000172

SRG-OS-000476-GPOS-00221

TBD - Assigned by DISA after STIG release

The operating system must generate audit records for all account creations, modifications, disabling, and termination events.

Ensure auditd Collects System Administrator Actions - /etc/sudoers

-w /etc/sudoers -p wa -k actions

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-w /etc/sudoers -p wa -k actions

Ensure auditd Collects System Administrator Actions - /etc/sudoers.d/

-w /etc/sudoers.d/ -p wa -k actions

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:

-w /etc/sudoers.d/ -p wa -k actions

Record Events that Modify User/Group Information - /etc/group

-w /etc/group -p wa -k audit_rules_usergroup_modification

-w /etc/group -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/gshadow

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/security/opasswd

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/passwd

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

Record Events that Modify User/Group Information - /etc/shadow

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

CCI-000172

SRG-OS-000477-GPOS-00222

TBD - Assigned by DISA after STIG release

The operating system must generate audit records for all kernel module load, unload, and restart actions, and also for all program initiations.

Ensure auditd Collects Information on Kernel Module Unloading - delete_module

To capture kernel module unloading events, use following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S delete_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module

If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following lines to a file with suffix .rules in the directory /etc/audit/rules.d to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system:

-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules

-a always,exit -F arch=ARCH -S finit_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on Kernel Module Loading - init_module

To capture kernel module loading events, use following line, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:

-a always,exit -F arch=ARCH -S init_module -F auid>=1000 -F auid!=unset -F key=modules

Ensure auditd Collects Information on the Use of Privileged Commands - kmod

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

CCI-002450

SRG-OS-000478-GPOS-00223

TBD - Assigned by DISA after STIG release

The operating system must implement NIST FIPS-validated cryptography for the following: to provision digital signatures, to generate cryptographic hashes, and to protect unclassified information requiring confidentiality and cryptographic protection in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.

Enable Dracut FIPS Module

To enable FIPS mode, run the following command:

fips-mode-setup --enable

To enable FIPS, the system requires that the fips module is added in dracut configuration. Check if /etc/dracut.conf.d/40-fips.conf contain add_dracutmodules+=" fips "

Enable FIPS Mode

To enable FIPS mode, run the following command:

fips-mode-setup --enable

The fips-mode-setup command will configure the system in FIPS mode by automatically configuring the following:

Setting the kernel FIPS mode flag (/proc/sys/crypto/fips_enabled) to 1
Creating /etc/system-fips
Setting the system crypto policy in /etc/crypto-policies/config to
Loading the Dracut fips module

Set kernel parameter 'crypto.fips_enabled' to 1

System running in FIPS mode is indicated by kernel parameter 'crypto.fips_enabled'. This parameter should be set to 1 in FIPS mode. To enable FIPS mode, run the following command:

fips-mode-setup --enable

CCI-001851

SRG-OS-000479-GPOS-00224

TBD - Assigned by DISA after STIG release

The operating system must, at a minimum, off-load audit data from interconnected systems in real time and off-load audit data from standalone systems weekly.

Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading is a common process in information systems with limited audit storage capacity.

Set type of computer node name logging in audit logs To configure Audit daemon to use a unique identifier as computer node name in the audit events, set name_format to in /etc/audit/auditd.conf.

Ensure rsyslog is Installed

Rsyslog is installed by default. The rsyslog package can be installed with the following command:

 $ sudo yum install rsyslog

Ensure Rsyslog Authenticates Off-Loaded Audit Records

$ActionSendStreamDriverAuthMode x509/name

Alternatively, use the RainerScript syntax:

action(type="omfwd" Target="some.example.com" StreamDriverAuthMode="x509/name")

Ensure Rsyslog Encrypts Off-Loaded Audit Records

Rsyslogd is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with gnutls (which is a secure communications library implementing the SSL, TLS and DTLS protocols), and you have a method to securely encrypt and off-load auditing. When using rsyslogd to off-load logs off a encrpytion system must be used. Set the following configuration option in /etc/rsyslog.conf or in a file in /etc/rsyslog.d (using legacy syntax):

$ActionSendStreamDriverMode 1

Alternatively, use the RainerScript syntax:

action(type="omfwd" ... StreamDriverMode="1")

Ensure Rsyslog Encrypts Off-Loaded Audit Records

Rsyslogd is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with gnutls (which is a secure communications library implementing the SSL, TLS and DTLS protocols), and you have a method to securely encrypt and off-load auditing. When using rsyslogd to off-load logs off an encryption system must be used. Set the following configuration option in /etc/rsyslog.conf or in a file in /etc/rsyslog.d (using legacy syntax):

$DefaultNetstreamDriver gtls

Alternatively, use the RainerScript syntax:

global(DefaultNetstreamDriver="gtls")

Ensure Logs Sent To Remote Host

*.* @

To use TCP for log message delivery:

*.* @@

To use RELP for log message delivery:

*.* :omrelp:

There must be a resolvable DNS CNAME or Alias record set to "_{" for logs to be sent correctly to the centralized logging utility.}

CCI-000366

SRG-OS-000480-GPOS-00225

TBD - Assigned by DISA after STIG release

The operating system must prevent the use of dictionary words for passwords.

If the operating system allows the user to select passwords based on dictionary words, then this increases the chances of password compromise by increasing the opportunity for successful guesses and brute-force attacks.

CCI-000366

SRG-OS-000480-GPOS-00226

TBD - Assigned by DISA after STIG release

The operating system must enforce a delay of at least 4 seconds between logon prompts following a failed logon attempt.

Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account.

Ensure the Logon Failure Delay is Set Correctly in login.defs

To ensure the logon failure delay controlled by /etc/login.defs is set properly, add or correct the FAIL_DELAY setting in /etc/login.defs to read as follows:

FAIL_DELAY

CCI-000366

SRG-OS-000480-GPOS-00227

TBD - Assigned by DISA after STIG release

The operating system must be configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs.

Configuring the operating system to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DoD that reflects the most restrictive security posture consistent with operational requirements. Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture and/or functionality of the system. Security-related parameters are those parameters impacting the security state of the system, including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: registry settings; account, file, directory permission settings; and settings for functions, ports, protocols, services, and remote connections.

Only Authorized Local User Accounts Exist on Operating System

Enterprise Application tends to use the server or virtual machine exclusively. Besides the default operating system user, there should be only authorized local users required by the installed software groups and applications that exist on the operating system. The authorized user list can be customized in the refine value variable var_accounts_authorized_local_users_regex. OVAL regular expression is used for the user list. Configure the system so all accounts on the system are assigned to an active system, application, or user account. Remove accounts that do not support approved system activities or that allow for a normal user to perform administrative-level actions. To remove unauthorized system accounts, use the following command:

$ sudo userdel unauthorized_user

Ensure Home Directories are Created for New Users

All local interactive user accounts, upon creation, should be assigned a home directory.

Configure the operating system to assign home directories to all new local interactive users by setting the CREATE_HOME parameter in /etc/login.defs to yes as follows:

CREATE_HOME yes

Verify Only Root Has UID 0

If any account other than root has a UID of 0, this misconfiguration should be investigated and the accounts other than root should be removed or have their UID changed.
If the account is associated with system commands or applications the UID should be changed to one greater than "0" but less than "1000." Otherwise assign a UID greater than "1000" that has not already been assigned.

Ensure PAM password complexity module is enabled in system-auth To enable PAM password complexity in system-auth file: Edit the password section in /etc/pam.d/system-auth to show password requisite pam_pwquality.so.

Ensure the Default Bash Umask is Set Correctly

To ensure the default umask for users of the Bash shell is set properly, add or correct the umask setting in /etc/bashrc to read as follows:

umask

Ensure the Default C Shell Umask is Set Correctly

To ensure the default umask for users of the C shell is set properly, add or correct the umask setting in /etc/csh.cshrc to read as follows:

umask

Ensure the Default Umask is Set Correctly in /etc/profile

To ensure the default umask controlled by /etc/profile is set properly, add or correct the umask setting in /etc/profile to read as follows:

umask

Note that /etc/profile also reads scrips within /etc/profile.d directory. These scripts are also valid files to set umask value. Therefore, they should also be considered during the check and properly remediated, if necessary.

Ensure the Default Umask is Set Correctly For Interactive Users Remove the UMASK environment variable from all interactive users initialization files.

User Initialization Files Must Not Run World-Writable Programs

Set the mode on files being executed by the user initialization files with the following command:

$ sudo chmod o-w FILE

Ensure that Users Path Contains Only Local Directories

Ensure that all interactive user initialization files executable search path statements do not contain statements that will reference a working directory other than the users home directory.

All Interactive Users Must Have A Home Directory Defined Assign home directories to all interactive users that currently do not have a home directory assigned. This rule checks if the home directory is properly defined in a folder which has at least one parent folder, like "user" in "/home/user" or "/remote/users/user". Therefore, this rule will report a finding for home directories like /users, /tmp or /.

All Interactive Users Home Directories Must Exist

Create home directories to all local interactive users that currently do not have a home directory assigned. Use the following commands to create the user home directory assigned in /etc/passwd:

$ sudo mkdir /home/USER

All User Files and Directories In The Home Directory Must Be Group-Owned By The Primary Group

Change the group of a local interactive users files and directories to a group that the interactive user is a member of. To change the group owner of a local interactive users files and directories, use the following command:

$ sudo chgrp USER_GROUP /home/USER/FILE_DIR

This rule ensures every file or directory under the home directory related to an interactive user is group-owned by an interactive user.

All User Files and Directories In The Home Directory Must Have Mode 0750 Or Less Permissive

Set the mode on files and directories in the local interactive user home directory with the following command:

$ sudo chmod 0750 /home/USER/FILE_DIR

Files that begin with a "." are excluded from this requirement.

Configure AIDE to Verify Access Control Lists (ACLs)

By default, the acl option is added to the FIPSR ruleset in AIDE. If using a custom ruleset or the acl option is missing, add acl to the appropriate ruleset. For example, add acl to the following line in /etc/aide.conf:

FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256

AIDE rules can be configured in multiple ways; this is merely one example that is already configured by default. The remediation provided with this rule adds acl to all rule sets available in /etc/aide.conf

Configure AIDE to Verify Extended Attributes

By default, the xattrs option is added to the FIPSR ruleset in AIDE. If using a custom ruleset or the xattrs option is missing, add xattrs to the appropriate ruleset. For example, add xattrs to the following line in /etc/aide.conf:

FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256

AIDE rules can be configured in multiple ways; this is merely one example that is already configured by default. The remediation provided with this rule adds xattrs to all rule sets available in /etc/aide.conf

Include Local Events in Audit Logs To configure Audit daemon to include local events in Audit logs, set local_events to yes in /etc/audit/auditd.conf. This is the default setting.

Disable core dump backtraces The ProcessSizeMax option in [Coredump] section of /etc/systemd/coredump.conf specifies the maximum size in bytes of a core which will be processed. Core dumps exceeding this size may be stored, but the backtrace will not be generated.

Disable storing core dump The Storage option in [Coredump] sectionof /etc/systemd/coredump.conf can be set to none to disable storing core dumps permanently.

Disable Ctrl-Alt-Del Reboot Key Sequence in GNOME3

By default, GNOME will reboot the system if the Ctrl-Alt-Del key sequence is pressed.

To configure the system to ignore the Ctrl-Alt-Del key sequence from the Graphical User Interface (GUI) instead of rebooting the system, add or set logout to [''] in /etc/dconf/db/local.d/00-security-settings. For example:

[org/gnome/settings-daemon/plugins/media-keys]
logout=['']

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/settings-daemon/plugins/media-keys/logout

After the settings have been set, run dconf update.

Disable the GNOME3 Login User List

In the default graphical environment, users logging directly into the system are greeted with a login screen that displays all known users. This functionality should be disabled by setting disable-user-list to true.

To disable, add or edit disable-user-list to /etc/dconf/db/gdm.d/00-security-settings. For example:

[org/gnome/login-screen]
disable-user-list=true

Once the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification. For example:

/org/gnome/login-screen/disable-user-list

After the settings have been set, run dconf update.

Ensure All World-Writable Directories Are Owned by root User

Ensure All World-Writable Directories Are Group Owned by a System Account

All directories in local partitions which are world-writable should be group owned by root or another system account. If any world-writable directories are not group owned by a system account, this should be investigated. Following this, the files should be deleted or assigned to an appropriate group.

Disable Ctrl-Alt-Del Burst Action

CtrlAltDelBurstAction=none

Disable Ctrl-Alt-Del Reboot Activation

ln -sf /dev/null /etc/systemd/system/ctrl-alt-del.target

systemctl mask ctrl-alt-del.target

Do not simply delete the /usr/lib/systemd/system/ctrl-alt-del.service file, as this file may be restored during future system updates.

Disable Core Dumps for All Users

To disable core dumps for all users, add the following line to /etc/security/limits.conf, or to a file within the /etc/security/limits.d/ directory:

*     hard   core    0

Ensure PAM Displays Last Logon/Access Notification

To configure the system to notify users of last logon/access using pam_lastlog, add or correct the pam_lastlog settings in /etc/pam.d/postlogin to include showfailed option, such as:

session     [default=1]    pam_lastlog.so showfailed

And make sure that the silent option is not set for this specific line.

Enable authselect Configure user authentication setup to use the authselect tool. If authselect profile is selected, the rule will enable the _profile.

All Interactive User Home Directories Must Be Group-Owned By The Primary Group

Change the group owner of interactive users home directory to the group found in /etc/passwd. To change the group owner of interactive users home directory, use the following command:

$ sudo chgrp USER_GROUP /home/USER

This rule ensures every home directory related to an interactive user is group-owned by an interactive user. It also ensures that interactive users are group-owners of one and only one home directory.

Ensure All User Initialization Files Have Mode 0740 Or Less Permissive

Set the mode of the user initialization files, including the root user, to 0740 with the following commands:

$ sudo chmod 0740 /root/.INIT_FILE
$ sudo chmod 0740 /home/USER/.INIT_FILE

All Interactive User Home Directories Must Have mode 0750 Or Less Permissive

Change the mode of interactive users home directories to 0750. To change the mode of interactive users home directory, use the following command:

$ sudo chmod 0750 /home/USER

Verify Permissions on SSH Server Private *_key Key Files SSH server private keys - files that match the /etc/ssh/*_key glob, have to have restricted permissions. If those files are owned by the root user and the root group, they have to have the 0600 permission or stricter. If they are owned by the root user, but by a dedicated group ssh_keys, they can have the 0640 permission or stricter.

Verify Permissions on SSH Server Public *.pub Key Files

To properly set the permissions of /etc/ssh/*.pub, run the command:

$ sudo chmod 0644 /etc/ssh/*.pub

Ensure All Files Are Owned by a Group

If any file is not group-owned by a group present in /etc/group, the cause of the lack of group-ownership must be investigated. Following this, those files should be deleted or assigned to an appropriate group. Locate the mount points related to local devices by the following command:

$ findmnt -n -l -k -it $(awk '/nodev/ { print $2 }' /proc/filesystems | paste -sd,)

For all mount points listed by the previous command, it is necessary to search for files which do not belong to a valid group using the following command:

$ sudo find MOUNTPOINT -xdev -nogroup 2>/dev/null

Enable page allocator poisoning

GRUB_CMDLINE_LINUX="... page_poison=1 ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="page_poison=1"

Disable vsyscalls

GRUB_CMDLINE_LINUX="... vsyscall=none ..."

Run the following command to update command line for already installed kernels:

# grubby --update-kernel=ALL --args="vsyscall=none"

The Installed Operating System Is Vendor Supported

The installed operating system must be maintained by a vendor. Red Hat Enterprise Linux is supported by Red Hat, Inc. As the Red Hat Enterprise Linux vendor, Red Hat, Inc. is responsible for providing security patches.

Disable ATM Support

install atm /bin/false

To configure the system to prevent the atm from being used, add the following line to file /etc/modprobe.d/atm.conf:

blacklist atm

Disable CAN Support

install can /bin/false

To configure the system to prevent the can from being used, add the following line to file /etc/modprobe.d/can.conf:

blacklist can

Disable SCTP Support

install sctp /bin/false

To configure the system to prevent the sctp from being used, add the following line to file /etc/modprobe.d/sctp.conf:

blacklist sctp

Disable Modprobe Loading of USB Storage Driver

install usb-storage /bin/false

To configure the system to prevent the usb-storage from being used, add the following line to file /etc/modprobe.d/usb-storage.conf:

blacklist usb-storage

This will prevent the modprobe program from loading the usb-storage module, but will not prevent an administrator (or another program) from using the insmod program to load the module manually.

Add nosuid Option to /boot/efi The nosuid mount option can be used to prevent execution of setuid programs in /boot/efi. The SUID and SGID permissions should not be required on the boot partition. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of /boot/efi.

Add noexec Option to /home The noexec mount option can be used to prevent binaries from being executed out of /home. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of /home.

Mount Remote Filesystems with nodev Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts.

Add nodev Option to Removable Media Partitions The nodev mount option prevents files from being interpreted as character or block devices. Legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of any removable media partitions.

Mount Remote Filesystems with noexec Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts.

Add noexec Option to Removable Media Partitions The noexec mount option prevents the direct execution of binaries on the mounted filesystem. Preventing the direct execution of binaries from removable media (such as a USB key) provides a defense against malicious software that may be present on such untrusted media. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of any removable media partitions.

Mount Remote Filesystems with nosuid Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts.

Add nosuid Option to Removable Media Partitions The nosuid mount option prevents set-user-identifier (SUID) and set-group-identifier (SGID) permissions from taking effect. These permissions allow users to execute binaries with the same permissions as the owner and group of the file respectively. Users should not be allowed to introduce SUID and SGID files into the system via partitions mounted from removeable media. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of any removable media partitions.

Configure Multiple DNS Servers in /etc/resolv.conf

Determine whether the system is using local or DNS name resolution with the following command:

$ sudo grep hosts /etc/nsswitch.conf
hosts: files dns

If the DNS entry is missing from the host's line in the "/etc/nsswitch.conf" file, the "/etc/resolv.conf" file must be empty. Verify the "/etc/resolv.conf" file is empty with the following command:

$ sudo ls -al /etc/resolv.conf
-rw-r--r-- 1 root root 0 Aug 19 08:31 resolv.conf

If the DNS entry is found on the host's line of the "/etc/nsswitch.conf" file, then verify the following:
Multiple Domain Name System (DNS) Servers should be configured in /etc/resolv.conf. This provides redundant name resolution services in the event that a domain server crashes. To configure the system to contain as least 2 DNS servers, add a corresponding nameserver ip_address entry in /etc/resolv.conf for each DNS server where ip_address is the IP address of a valid DNS server. For example:

search example.com
nameserver 192.168.0.1
nameserver 192.168.0.2

Ensure System is Not Acting as a Network Sniffer

The system should not be acting as a network sniffer, which can capture all traffic on the network to which it is connected. Run the following to determine if any interface is running in promiscuous mode:

$ ip link | grep PROMISC

Promiscuous mode of an interface can be disabled with the following command:

$ sudo ip link set dev device_name multicast off promisc off

Prevent Login to Accounts With Empty Password If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. Remove any instances of the nullok in /etc/pam.d/system-auth and /etc/pam.d/password-auth to prevent logins with empty passwords.

Ensure There Are No Accounts With Blank or Null Passwords

Check the "/etc/shadow" file for blank passwords with the following command:

$ sudo awk -F: '!$2 {print $1}' /etc/shadow

If the command returns any results, this is a finding. Configure all accounts on the system to have a password or lock the account with the following commands: Perform a password reset:

$ sudo passwd [username]

Lock an account:

$ sudo passwd -l [username]

Ensure All Files Are Owned by a User

If any files are not owned by a user, then the cause of their lack of ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate user. Locate the mount points related to local devices by the following command:

$ findmnt -n -l -k -it $(awk '/nodev/ { print $2 }' /proc/filesystems | paste -sd,)

For all mount points listed by the previous command, it is necessary to search for files which do not belong to a valid user using the following command:

$ sudo find MOUNTPOINT -xdev -nouser 2>/dev/null

Remove Host-Based Authentication Files

The shosts.equiv file lists remote hosts and users that are trusted by the local system. To remove these files, run the following command to delete them from any location:

$ sudo rm /[path]/[to]/[file]/shosts.equiv

Remove User Host-Based Authentication Files

The ~/.shosts (in each user's home directory) files list remote hosts and users that are trusted by the local system. To remove these files, run the following command to delete them from any location:

$ sudo find / -name '.shosts' -type f -delete

Install firewalld Package

The firewalld package can be installed with the following command:

$ sudo yum install firewalld

Uninstall gssproxy Package

The gssproxy package can be removed with the following command:

$ sudo yum erase gssproxy

Uninstall iprutils Package

The iprutils package can be removed with the following command:

$ sudo yum erase iprutils

Install policycoreutils Package

The policycoreutils package can be installed with the following command:

$ sudo yum install policycoreutils

Install rng-tools Package

The rng-tools package can be installed with the following command:

$ sudo yum install rng-tools

Ensure rsyslog-gnutls is installed

TLS protocol support for rsyslog is installed. The rsyslog-gnutls package can be installed with the following command:

$ sudo yum install rsyslog-gnutls

Ensure rsyslog is Installed

Rsyslog is installed by default. The rsyslog package can be installed with the following command:

 $ sudo yum install rsyslog

Uninstall Sendmail Package

Sendmail is not the default mail transfer agent and is not installed by default. The sendmail package can be removed with the following command:

$ sudo yum erase sendmail

Uninstall tftp-server Package

The tftp-server package can be removed with the following command:

 $ sudo yum erase tftp-server

Uninstall tuned Package

The tuned package can be removed with the following command:

$ sudo yum erase tuned

Uninstall vsftpd Package

The vsftpd package can be removed with the following command:

 $ sudo yum erase vsftpd

Ensure /home Located On Separate Partition If user home directories will be stored locally, create a separate partition for /home at installation time (or migrate it later using LVM). If /home will be mounted from another system such as an NFS server, then creating a separate partition is not necessary at installation time, and the mountpoint can instead be configured later.

Ensure /tmp Located On Separate Partition The /tmp directory is a world-writable directory used for temporary file storage. Ensure it has its own partition or logical volume at installation time, or migrate it using LVM.

Ensure /var Located On Separate Partition The /var directory is used by daemons and other system services to store frequently-changing data. Ensure that /var has its own partition or logical volume at installation time, or migrate it using LVM.

Ensure /var/log Located On Separate Partition System logs are stored in the /var/log directory. Ensure that /var/log has its own partition or logical volume at installation time, or migrate it using LVM.

Ensure /var/tmp Located On Separate Partition The /var/tmp directory is a world-writable directory used for temporary file storage. Ensure it has its own partition or logical volume at installation time, or migrate it using LVM.

Prevent Unrestricted Mail Relaying

Modify the

/etc/postfix/main.cf

file to restrict client connections to the local network with the following command:

$ sudo postconf -e 'smtpd_client_restrictions = permit_mynetworks,reject'

Ensure cron Is Logging To Rsyslog

Cron logging must be implemented to spot intrusions or trace cron job status. If cron is not logging to rsyslog, it can be implemented by adding the following to the RULES section of /etc/rsyslog.conf: If the legacy syntax is used:

cron.*                                                  /var/log/cron

If the modern syntax (RainerScript) is used:

cron.* action(type="omfile" file="/var/log/cron")

Ensure Logs Sent To Remote Host

*.* @

To use TCP for log message delivery:

*.* @@

To use RELP for log message delivery:

*.* :omrelp:

There must be a resolvable DNS CNAME or Alias record set to "_{" for logs to be sent correctly to the centralized logging utility.}

Ensure Software Patches Installed

If the system is joined to the Red Hat Network, a Red Hat Satellite Server, or a yum server, run the following command to install updates:

$ sudo yum update

If the system is not configured to use one of these sources, updates (in the form of RPM packages) can be manually downloaded from the Red Hat Network and installed using rpm.

NOTE: U.S. Defense systems are required to be patched within 30 days or sooner as local policy dictates.

Disable the Automounter

$ sudo systemctl mask --now autofs.service

Disable debug-shell SystemD Service

$ sudo systemctl mask --now debug-shell.service

Verify firewalld Enabled

The firewalld service can be enabled with the following command:

$ sudo systemctl enable firewalld.service

Disable KDump Kernel Crash Analyzer (kdump)

$ sudo systemctl mask --now kdump.service

Enable the Hardware RNG Entropy Gatherer Service

The Hardware RNG Entropy Gatherer service should be enabled. The rngd service can be enabled with the following command:

$ sudo systemctl enable rngd.service

Enable rsyslog Service

The rsyslog service provides syslog-style logging by default on Red Hat Enterprise Linux 8. The rsyslog service can be enabled with the following command:

$ sudo systemctl enable rsyslog.service

Disable acquiring, saving, and processing core dumps The systemd-coredump.socket unit is a socket activation of the systemd-coredump@.service which processes core dumps. By masking the unit, core dump processing is disabled.

Set Default firewalld Zone for Incoming Packets

To set the default zone to drop for the built-in default zone which processes incoming IPv4 and IPv6 packets, modify the following line in /etc/firewalld/firewalld.conf to be:

DefaultZone=drop

Disable SSH Access via Empty Passwords

PermitEmptyPasswords no

Any accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords.

Disable GSSAPI Authentication

GSSAPIAuthentication no

Disable Kerberos Authentication

KerberosAuthentication no

Disable SSH Root Login

The root user should never be allowed to login to a system directly over a network. To disable root login via SSH, add or correct the following line in /etc/ssh/sshd_config:

PermitRootLogin no

Disable SSH Support for User Known Hosts

SSH can allow system users to connect to systems if a cache of the remote systems public keys is available. This should be disabled.

To ensure this behavior is disabled, add or correct the following line in /etc/ssh/sshd_config:

IgnoreUserKnownHosts yes

Disable X11 Forwarding

The X11Forwarding parameter provides the ability to tunnel X11 traffic through the connection to enable remote graphic connections. SSH has the capability to encrypt remote X11 connections when SSH's X11Forwarding option is enabled.
The default SSH configuration disables X11Forwarding. The appropriate configuration is used if no value is set for X11Forwarding.
To explicitly disable X11 Forwarding, add or correct the following line in /etc/ssh/sshd_config:

X11Forwarding no

Enable Use of Strict Mode Checking

SSHs StrictModes option checks file and ownership permissions in the user's home directory .ssh folder before accepting login. If world- writable permissions are found, logon is rejected.
The default SSH configuration has StrictModes enabled. The appropriate configuration is used if no value is set for StrictModes.
To explicitly enable StrictModes in SSH, add or correct the following line in /etc/ssh/sshd_config:

StrictModes yes

Enable SSH Print Last Log

Ensure that SSH will display the date and time of the last successful account logon.
The default SSH configuration enables print of the date and time of the last login. The appropriate configuration is used if no value is set for PrintLastLog.
To explicitly enable LastLog in SSH, add or correct the following line in /etc/ssh/sshd_config:

PrintLastLog yes

Force frequent session key renegotiation

RekeyLimit

SSH server uses strong entropy to seed

To set up SSH server to use entropy from a high-quality source, edit the /etc/sysconfig/sshd file. The SSH_USE_STRONG_RNG configuration value determines how many bytes of entropy to use, so make sure that the file contains line

SSH_USE_STRONG_RNG=32

Prevent remote hosts from connecting to the proxy display The SSH daemon should prevent remote hosts from connecting to the proxy display.
The default SSH configuration for X11UseLocalhost is yes, which prevents remote hosts from connecting to the proxy display.
To explicitly prevent remote connections to the proxy display, add or correct the following line in /etc/ssh/sshd_config: X11UseLocalhost yes

The operating system must restrict privilege elevation to authorized personnel The sudo command allows a user to execute programs with elevated (administrator) privileges. It prompts the user for their password and confirms your request to execute a command by checking a file, called sudoers. Restrict privileged actions by removing the following entries from the sudoers file: ALL ALL=(ALL) ALL ALL ALL=(ALL:ALL) ALL

Ensure sudo only includes the default configuration directory Administrators can configure authorized sudo users via drop-in files, and it is possible to include other directories and configuration files from the file currently being parsed. Make sure that /etc/sudoers only includes drop-in configuration files from /etc/sudoers.d, or that no drop-in file is included. Either the /etc/sudoers should contain only one #includedir directive pointing to /etc/sudoers.d, and no file in /etc/sudoers.d/ should include other files or directories; Or the /etc/sudoers should not contain any #include, @include, #includedir or @includedir directives. Note that the '#' character doesn't denote a comment in the configuration file.

Ensure invoking users password for privilege escalation when using sudo

The sudoers security policy requires that users authenticate themselves before they can use sudo. When sudoers requires authentication, it validates the invoking user's credentials. The expected output for:

 sudo cvtsudoers -f sudoers /etc/sudoers | grep -E '^Defaults !?(rootpw|targetpw|runaspw)$'

 Defaults !targetpw
      Defaults !rootpw
      Defaults !runaspw

or if cvtsudoers not supported:

 sudo find /etc/sudoers /etc/sudoers.d \( \! -name '*~' -a \! -name '*.*' \) -exec grep -E --with-filename '^[[:blank:]]*Defaults[[:blank:]](.*[[:blank:]])?!?\b(rootpw|targetpw|runaspw)' -- {} \;

 /etc/sudoers:Defaults !targetpw
      /etc/sudoers:Defaults !rootpw
      /etc/sudoers:Defaults !runaspw

Disable storing core dumps

To set the runtime status of the kernel.core_pattern kernel parameter, run the following command:

$ sudo sysctl -w kernel.core_pattern=|/bin/false

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

kernel.core_pattern = |/bin/false

Disable Kernel Image Loading

To set the runtime status of the kernel.kexec_load_disabled kernel parameter, run the following command:

$ sudo sysctl -w kernel.kexec_load_disabled=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

kernel.kexec_load_disabled = 1

Restrict Exposed Kernel Pointer Addresses Access

To set the runtime status of the kernel.kptr_restrict kernel parameter, run the following command:

$ sudo sysctl -w kernel.kptr_restrict=

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

kernel.kptr_restrict =

Enable Randomized Layout of Virtual Address Space

To set the runtime status of the kernel.randomize_va_space kernel parameter, run the following command:

$ sudo sysctl -w kernel.randomize_va_space=2

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

kernel.randomize_va_space = 2

Disable Access to Network bpf() Syscall From Unprivileged Processes

To set the runtime status of the kernel.unprivileged_bpf_disabled kernel parameter, run the following command:

$ sudo sysctl -w kernel.unprivileged_bpf_disabled=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

kernel.unprivileged_bpf_disabled = 1

Restrict usage of ptrace to descendant processes

To set the runtime status of the kernel.yama.ptrace_scope kernel parameter, run the following command:

$ sudo sysctl -w kernel.yama.ptrace_scope=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

kernel.yama.ptrace_scope = 1

Harden the operation of the BPF just-in-time compiler

To set the runtime status of the net.core.bpf_jit_harden kernel parameter, run the following command:

$ sudo sysctl -w net.core.bpf_jit_harden=2

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.core.bpf_jit_harden = 2

Disable Accepting ICMP Redirects for All IPv4 Interfaces

To set the runtime status of the net.ipv4.conf.all.accept_redirects kernel parameter, run the following command:

$ sudo sysctl -w net.ipv4.conf.all.accept_redirects=0

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.ipv4.conf.all.accept_redirects = 0

Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv4 Interfaces

To set the runtime status of the net.ipv4.conf.all.accept_source_route kernel parameter, run the following command:

$ sudo sysctl -w net.ipv4.conf.all.accept_source_route=0

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.ipv4.conf.all.accept_source_route = 0

Disable Kernel Parameter for IPv4 Forwarding on all IPv4 Interfaces

To set the runtime status of the net.ipv4.conf.all.forwarding kernel parameter, run the following command:

$ sudo sysctl -w net.ipv4.conf.all.forwarding=0

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.ipv4.conf.all.forwarding = 0

Enable Kernel Parameter to Use Reverse Path Filtering on all IPv4 Interfaces

To set the runtime status of the net.ipv4.conf.all.rp_filter kernel parameter, run the following command:

$ sudo sysctl -w net.ipv4.conf.all.rp_filter=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.ipv4.conf.all.rp_filter = 1

Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfaces

To set the runtime status of the net.ipv4.conf.all.send_redirects kernel parameter, run the following command:

$ sudo sysctl -w net.ipv4.conf.all.send_redirects=0

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.ipv4.conf.all.send_redirects = 0

Disable Kernel Parameter for Accepting ICMP Redirects by Default on IPv4 Interfaces

To set the runtime status of the net.ipv4.conf.default.accept_redirects kernel parameter, run the following command:

$ sudo sysctl -w net.ipv4.conf.default.accept_redirects=0

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.ipv4.conf.default.accept_redirects = 0

Disable Kernel Parameter for Accepting Source-Routed Packets on IPv4 Interfaces by Default

To set the runtime status of the net.ipv4.conf.default.accept_source_route kernel parameter, run the following command:

$ sudo sysctl -w net.ipv4.conf.default.accept_source_route=0

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.ipv4.conf.default.accept_source_route = 0

Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfaces by Default

To set the runtime status of the net.ipv4.conf.default.send_redirects kernel parameter, run the following command:

$ sudo sysctl -w net.ipv4.conf.default.send_redirects=0

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.ipv4.conf.default.send_redirects = 0

Enable Kernel Parameter to Ignore ICMP Broadcast Echo Requests on IPv4 Interfaces

To set the runtime status of the net.ipv4.icmp_echo_ignore_broadcasts kernel parameter, run the following command:

$ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.ipv4.icmp_echo_ignore_broadcasts = 1

Configure Accepting Router Advertisements on All IPv6 Interfaces

To set the runtime status of the net.ipv6.conf.all.accept_ra kernel parameter, run the following command:

$ sudo sysctl -w net.ipv6.conf.all.accept_ra=0

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.ipv6.conf.all.accept_ra = 0

Disable Accepting ICMP Redirects for All IPv6 Interfaces

To set the runtime status of the net.ipv6.conf.all.accept_redirects kernel parameter, run the following command:

$ sudo sysctl -w net.ipv6.conf.all.accept_redirects=0

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.ipv6.conf.all.accept_redirects = 0

Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv6 Interfaces

To set the runtime status of the net.ipv6.conf.all.accept_source_route kernel parameter, run the following command:

$ sudo sysctl -w net.ipv6.conf.all.accept_source_route=0

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.ipv6.conf.all.accept_source_route = 0

Disable Kernel Parameter for IPv6 Forwarding

To set the runtime status of the net.ipv6.conf.all.forwarding kernel parameter, run the following command:

$ sudo sysctl -w net.ipv6.conf.all.forwarding=0

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.ipv6.conf.all.forwarding = 0

Disable Accepting Router Advertisements on all IPv6 Interfaces by Default

To set the runtime status of the net.ipv6.conf.default.accept_ra kernel parameter, run the following command:

$ sudo sysctl -w net.ipv6.conf.default.accept_ra=0

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.ipv6.conf.default.accept_ra = 0

Disable Kernel Parameter for Accepting ICMP Redirects by Default on IPv6 Interfaces

To set the runtime status of the net.ipv6.conf.default.accept_redirects kernel parameter, run the following command:

$ sudo sysctl -w net.ipv6.conf.default.accept_redirects=0

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.ipv6.conf.default.accept_redirects = 0

Disable Kernel Parameter for Accepting Source-Routed Packets on IPv6 Interfaces by Default

To set the runtime status of the net.ipv6.conf.default.accept_source_route kernel parameter, run the following command:

$ sudo sysctl -w net.ipv6.conf.default.accept_source_route=0

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

net.ipv6.conf.default.accept_source_route = 0

Disable the use of user namespaces

To set the runtime status of the user.max_user_namespaces kernel parameter, run the following command:

$ sudo sysctl -w user.max_user_namespaces=0

To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:

user.max_user_namespaces = 0

When containers are deployed on the machine, the value should be set to large non-zero value.

Ensure tftp Daemon Uses Secure Mode

If running the Trivial File Transfer Protocol (TFTP) service is necessary, it should be configured to change its root directory at startup. To do so, ensure /etc/xinetd.d/tftp includes -s as a command line argument, as shown in the following example:

server_args = -s

Disable graphical user interface

By removing the following packages, the system no longer has X Windows installed. xorg-x11-server-Xorg xorg-x11-server-common xorg-x11-server-utils xorg-x11-server-Xwayland If X Windows is not installed then the system cannot boot into graphical user mode. This prevents the system from being accidentally or maliciously booted into a graphical.target mode. To do so, run the following command:

sudo yum remove xorg-x11-server-Xorg xorg-x11-server-common xorg-x11-server-utils xorg-x11-server-Xwayland

Disable X Windows Startup By Setting Default Target

Systems that do not require a graphical user interface should only boot by default into multi-user.target mode. This prevents accidental booting of the system into a graphical.target mode. Setting the system's default target to multi-user.target will prevent automatic startup of the X server. To do so, run:

$ systemctl set-default multi-user.target

You should see the following output:

Removed symlink /etc/systemd/system/default.target.
Created symlink from /etc/systemd/system/default.target to /usr/lib/systemd/system/multi-user.target.

CCI-000366

SRG-OS-000480-GPOS-00228

TBD - Assigned by DISA after STIG release

The operating system must define default permissions for all authenticated users in such a way that the user can only read and modify their own files.

Setting the most restrictive default permissions ensures that when new accounts are created they do not have unnecessary access.

Ensure the Default Bash Umask is Set Correctly

To ensure the default umask for users of the Bash shell is set properly, add or correct the umask setting in /etc/bashrc to read as follows:

umask

Ensure the Default C Shell Umask is Set Correctly

To ensure the default umask for users of the C shell is set properly, add or correct the umask setting in /etc/csh.cshrc to read as follows:

umask

Ensure the Default Umask is Set Correctly in login.defs

To ensure the default umask controlled by /etc/login.defs is set properly, add or correct the UMASK setting in /etc/login.defs to read as follows:

UMASK

Ensure the Default Umask is Set Correctly in /etc/profile

To ensure the default umask controlled by /etc/profile is set properly, add or correct the umask setting in /etc/profile to read as follows:

umask

Ensure the Default Umask is Set Correctly For Interactive Users Remove the UMASK environment variable from all interactive users initialization files.

CCI-000366

SRG-OS-000480-GPOS-00229

TBD - Assigned by DISA after STIG release

The operating system must not allow an unattended or automatic logon to the system.

Failure to restrict system access to authenticated users negatively impacts operating system security.

Disable GDM Automatic Login

The GNOME Display Manager (GDM) can allow users to automatically login without user interaction or credentials. User should always be required to authenticate themselves to the system that they are authorized to use. To disable user ability to automatically login to the system, set the AutomaticLoginEnable to false in the [daemon] section in /etc/gdm/custom.conf. For example:

[daemon]
AutomaticLoginEnable=false

Disable SSH Access via Empty Passwords

PermitEmptyPasswords no

Any accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords.

Do Not Allow SSH Environment Options

Ensure that users are not able to override environment variables of the SSH daemon.
The default SSH configuration disables environment processing. The appropriate configuration is used if no value is set for PermitUserEnvironment.
To explicitly disable Environment options, add or correct the following /etc/ssh/sshd_config:

PermitUserEnvironment no

CCI-000366

SRG-OS-000480-GPOS-00230

TBD - Assigned by DISA after STIG release

The operating system must limit the ability of non-privileged users to grant other users direct access to the contents of their home directories/folders.

Users' home directories/folders may contain information of a sensitive nature. Non-privileged users should coordinate any sharing of information with an SA through shared resources.

Install fapolicyd Package

The fapolicyd package can be installed with the following command:

$ sudo yum install fapolicyd

Enable the File Access Policy Service

The File Access Policy service should be enabled. The fapolicyd service can be enabled with the following command:

$ sudo systemctl enable fapolicyd.service

CCI-000366

SRG-OS-000480-GPOS-00232

TBD - Assigned by DISA after STIG release

The operating system must enable an application firewall, if available.

Firewalls protect computers from network attacks by blocking or limiting access to open network ports. Application firewalls limit which applications are allowed to communicate over the network.

Configure Fapolicy Module to Employ a Deny-all, Permit-by-exception Policy to Allow the Execution of Authorized Software Programs.

The Fapolicy module must be configured to employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs and to prevent unauthorized software from running.

Install firewalld Package

The firewalld package can be installed with the following command:

$ sudo yum install firewalld

Verify firewalld Enabled

The firewalld service can be enabled with the following command:

$ sudo systemctl enable firewalld.service

SSH server uses strong entropy to seed

SSH_USE_STRONG_RNG=32

CCI-002418 SRG-OS-000481-GPOS-00481 TBD - Assigned by DISA after STIG release The operating system must protect the confidentiality and integrity of communications with wireless peripherals. Without protection of communications with wireless peripherals, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read, altered, or used to compromise the operating system. This requirement applies to wireless peripheral technologies (e.g., wireless mice, keyboards, displays, etc.) used with an operating system. Wireless peripherals (e.g., Wi-Fi/Bluetooth/IR Keyboards, Mice, and Pointing Devices and Near Field Communications [NFC]) present a unique challenge by creating an open, unsecured port on a computer. Wireless peripherals must meet DoD requirements for wireless data transmission and be approved for use by the AO. Even though some wireless peripherals, such as mice and pointing devices, do not ordinarily carry information that need to be protected, modification of communications with these wireless peripherals may be used to compromise the operating system. Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of communications with wireless peripherals can be accomplished by physical means (e.g., employing physical barriers to wireless radio frequencies) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. If the wireless peripheral is only passing telemetry data, encryption of the data may not be required.

CCI-002605 SRG-OS-000439-GPOS-00195 TBD - Assigned by DISA after STIG release The operating system must install security-relevant software updates within the time period directed by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs). Security flaws with operating systems are discovered daily. Vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously.

CCI-003628 SRG-OS-000590-GPOS-00110 TBD - Assigned by DISA after STIG release The operating system must disable accounts when the accounts are no longer associated to a user. Disabling expired, inactive, or otherwise anomalous accounts supports the concepts of least privilege and least functionality which reduce the attack surface of the system.

CCI-003959 SRG-OS-000690-GPOS-00140 TBD - Assigned by DISA after STIG release The operating system must prohibit the use or connection of unauthorized hardware components. Hardware components provide the foundation for organizational systems and the platform for the execution of authorized software programs. Managing the inventory of hardware components and controlling which hardware components are permitted to be installed or connected to organizational systems is essential to provide adequate security.

CCI-004047 SRG-OS-000705-GPOS-00150 TBD - Assigned by DISA after STIG release The operating system must implement multifactor authentication for local, network, and/or remote access to privileged accounts and/or nonprivileged accounts such that the device meets organization-defined strength of mechanism requirements. The purpose of requiring a device separate from the system to which the user is attempting to gain access for one of the factors during multifactor authentication is to reduce the likelihood of compromising authenticators or credentials stored on the system. Adversaries may be able to compromise such authenticators or credentials and subsequently impersonate authorized users. Implementing one of the factors on a separate device (e.g., a hardware token), provides a greater strength of mechanism and an increased level of assurance in the authentication process.

CCI-004061 SRG-OS-000710-GPOS-00160 TBD - Assigned by DISA after STIG release The operating system must, for password-based authentication, verify when users create or update passwords the passwords are not found on the list of commonly-used, expected, or compromised passwords in IA-5 (1) (a). Password-based authentication applies to passwords regardless of whether they are used in single-factor or multifactor authentication. Long passwords or passphrases are preferable over shorter passwords. Enforced composition rules provide marginal security benefits while decreasing usability. However, organizations may choose to establish certain rules for password generation (e.g., minimum character length for long passwords) under certain circumstances and can enforce this requirement in IA-5(1)(h). Account recovery can occur, for example, in situations when a password is forgotten. Cryptographically protected passwords include salted one-way cryptographic hashes of passwords. The list of commonly used, compromised, or expected passwords includes passwords obtained from previous breach corpuses, dictionary words, and repetitive or sequential characters. The list includes context-specific words, such as the name of the service, username, and derivatives thereof.

CCI-004063 SRG-OS-000720-GPOS-00170 TBD - Assigned by DISA after STIG release The operating system must for password-based authentication, require immediate selection of a new password upon account recovery. Password-based authentication applies to passwords regardless of whether they are used in single-factor or multifactor authentication. Long passwords or passphrases are preferable over shorter passwords. Enforced composition rules provide marginal security benefits while decreasing usability. However, organizations may choose to establish certain rules for password generation (e.g., minimum character length for long passwords) under certain circumstances and can enforce this requirement in IA-5(1)(h). Account recovery can occur, for example, in situations when a password is forgotten. Cryptographically protected passwords include salted one-way cryptographic hashes of passwords. The list of commonly used, compromised, or expected passwords includes passwords obtained from previous breach corpuses, dictionary words, and repetitive or sequential characters. The list includes context-specific words, such as the name of the service, username, and derivatives thereof.

CCI-004064 SRG-OS-000725-GPOS-00180 TBD - Assigned by DISA after STIG release The operating system must for password-based authentication, allow user selection of long passwords and passphrases, including spaces and all printable characters. Password-based authentication applies to passwords regardless of whether they are used in single-factor or multifactor authentication. Long passwords or passphrases are preferable over shorter passwords. Enforced composition rules provide marginal security benefits while decreasing usability. However, organizations may choose to establish certain rules for password generation (e.g., minimum character length for long passwords) under certain circumstances and can enforce this requirement in IA-5(1)(h). Account recovery can occur, for example, in situations when a password is forgotten. Cryptographically protected passwords include salted one-way cryptographic hashes of passwords. The list of commonly used, compromised, or expected passwords includes passwords obtained from previous breach corpuses, dictionary words, and repetitive or sequential characters. The list includes context-specific words, such as the name of the service, username, and derivatives thereof.

CCI-004065

SRG-OS-000730-GPOS-00190

TBD - Assigned by DISA after STIG release

The operating system must, for password-based authentication, employ automated tools to assist the user in selecting strong password authenticators.

Password-based authentication applies to passwords regardless of whether they are used in single-factor or multifactor authentication. Long passwords or passphrases are preferable over shorter passwords. Enforced composition rules provide marginal security benefits while decreasing usability. However, organizations may choose to establish certain rules for password generation (e.g., minimum character length for long passwords) under certain circumstances and can enforce this requirement in IA-5(1)(h). Account recovery can occur, for example, in situations when a password is forgotten. Cryptographically protected passwords include salted one-way cryptographic hashes of passwords. The list of commonly used, compromised, or expected passwords includes passwords obtained from previous breach corpuses, dictionary words, and repetitive or sequential characters. The list includes context-specific words, such as the name of the service, username, and derivatives thereof.

CCI-004083 SRG-OS-000745-GPOS-00210 TBD - Assigned by DISA after STIG release The operating system must accept only external credentials that are NIST-compliant. Acceptance of only NIST-compliant external authenticators applies to organizational systems that are accessible to the public (e.g., public-facing websites). External authenticators are issued by nonfederal government entities and are compliant with [SP 800-63B]. Approved external authenticators meet or exceed the minimum federal government-wide technical, security, privacy, and organizational maturity requirements. Meeting or exceeding federal requirements allows federal government relying parties to trust external authenticators in connection with an authentication transaction at a specified authenticator assurance level.

CCI-004188

SRG-OS-000755-GPOS-00220

TBD - Assigned by DISA after STIG release

The operating system must monitor the use of maintenance tools that execute with increased privilege.

Maintenance tools that execute with increased system privilege can result in unauthorized access to organizational information and assets that would otherwise be inaccessible.

Ensure auditd Collects Information on the Use of Privileged Commands - su

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Ensure auditd Collects Information on the Use of Privileged Commands - sudo

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules:

-a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged

Record Events When Privileged Executables Are Run

Verify the system generates an audit record when privileged functions are executed. If audit is using the "auditctl" tool to load the rules, run the following command:

$ sudo grep execve /etc/audit/audit.rules

If audit is using the "augenrules" tool to load the rules, run the following command:

$ sudo grep -r execve /etc/audit/rules.d

-a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k setuid

-a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k setuid

-a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k setgid

-a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k setgid

If both the "b32" and "b64" audit rules for "SUID" files are not defined, this is a finding. If both the "b32" and "b64" audit rules for "SGID" files are not defined, this is a finding.

CCI-004909 SRG-OS-000775-GPOS-00230 TBD - Assigned by DISA after STIG release The operating system must include only approved trust anchors in trust stores or certificate stores managed by the organization. Public key infrastructure (PKI) certificates are certificates with visibility external to organizational systems and certificates related to the internal operations of systems, such as application-specific time services. In cryptographic systems with a hierarchical structure, a trust anchor is an authoritative source (i.e., a certificate authority) for which trust is assumed and not derived. A root certificate for a PKI system is an example of a trust anchor. A trust store or certificate store maintains a list of trusted root certificates.

CCI-004910 SRG-OS-000780-GPOS-00240 TBD - Assigned by DISA after STIG release The operating system must provide protected storage for cryptographic keys with organization-defined safeguards and/or hardware protected key store. A Trusted Platform Module (TPM) is an example of a hardware-protected data store that can be used to protect cryptographic keys.

CCI-004922 SRG-OS-000785-GPOS-00250 TBD - Assigned by DISA after STIG release The operating system must synchronize system clocks within and between systems or system components. Time synchronization of system clocks is essential for the correct execution of many system services, including identification and authentication processes that involve certificates and time-of-day restrictions as part of access control. Denial of service or failure to deny expired credentials may result without properly synchronized clocks within and between systems and system components. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. The granularity of time measurements refers to the degree of synchronization between system clocks and reference clocks, such as clocks synchronizing within hundreds of milliseconds or tens of milliseconds. Organizations may define different time granularities for system components. Time service can be critical to other security capabilities—such as access control and identification and authentication—depending on the nature of the mechanisms used to support the capabilities.

CCI-004961 SRG-OS-000805-GPOS-00260 TBD - Assigned by DISA after STIG release The operating system must employ automated patch management tools to facilitate flaw remediation to the organization-defined system components. Using automated tools to support patch management helps to ensure the timeliness and completeness of system patching operations.