SRGs from General Purpose Operating System SRG Mapped to DISA STIG for Red Hat Enterprise Linux 7


CCI SRGID STIGID SRG Requirement Requirement SRG VulDiscussion VulDiscussion Status SRG Check Check SRG Fix Fix Severity Mitigation Artifact Description Status Justification
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system provides automated mechanisms for supporting account management functions. If it does not, this is a finding. Configure the operating system to provide automated mechanisms for supporting account management functions. This requirement is a permanent not a finding. No fix is required. medium
CCI-000366 SRG-OS-000480-GPOS-00232 TBD - Assigned by DISA after STIG release The operating system must enable an application firewall, if available. CCE-80998-8:Verify firewalld Enabled 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. The firewalld service can be enabled with the following command:
$ sudo systemctl enable firewalld.service
Applicable - Configurable Verify the operating system enabled an application firewall, if available. If it does not, this is a finding. If the operating system does not support an application firewall, this may be downgraded to a CAT III finding. Run the following command to determine the current status of the firewalld service: $ systemctl is-active firewalld If the service is running, it should return the following: active Is it the case that ? Ensure the operating system's application firewall is enabled, if available. The firewalld service can be enabled with the following command: $ sudo systemctl enable firewalld.service medium
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.
CCI-000018 SRG-OS-000004-GPOS-00004 TBD - Assigned by DISA after STIG release The operating system must audit all account creations. CCE-80432-8:Record Events that Modify User/Group Information - /etc/gshadow 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. 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/gshadow -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/gshadow -p wa -k audit_rules_usergroup_modification
Applicable - Configurable Verify the operating system automatically audits account creation. If it does not, this is a finding. To determine if the system is configured to audit account changes, run the following command: auditctl -l | egrep '(/etc/gshadow)' If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each). Is it the case that the system is not configured to audit account changes? Configure the operating system to automatically audit account creation. 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/gshadow -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/gshadow -p wa -k audit_rules_usergroup_modification medium
CCI-000018 SRG-OS-000004-GPOS-00004 TBD - Assigned by DISA after STIG release The operating system must audit all account creations. CCE-80433-6:Record Events that Modify User/Group Information - /etc/group 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. 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
Applicable - Configurable Verify the operating system automatically audits account creation. If it does not, this is a finding. To determine if the system is configured to audit account changes, run the following command: auditctl -l | egrep '(/etc/group)' If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each). Is it the case that the system is not configured to audit account changes? Configure the operating system to automatically audit account creation. 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 medium
CCI-000018 SRG-OS-000004-GPOS-00004 TBD - Assigned by DISA after STIG release The operating system must audit all account creations. CCE-80435-1:Record Events that Modify User/Group Information - /etc/passwd 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. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification
Applicable - Configurable Verify the operating system automatically audits account creation. If it does not, this is a finding. To determine if the system is configured to audit account changes, run the following command: auditctl -l | egrep '(/etc/passwd)' If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each). Is it the case that the system is not configured to audit account changes? Configure the operating system to automatically audit account creation. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification medium
CCI-000018 SRG-OS-000004-GPOS-00004 TBD - Assigned by DISA after STIG release The operating system must audit all account creations. CCE-80430-2:Record Events that Modify User/Group Information - /etc/security/opasswd 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. 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/security/opasswd -p wa -k audit_rules_usergroup_modification


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

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
Applicable - Configurable Verify the operating system automatically audits account creation. If it does not, this is a finding. To determine if the system is configured to audit account changes, run the following command: auditctl -l | egrep '(/etc/security/opasswd)' If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each). Is it the case that the system is not configured to audit account changes? Configure the operating system to automatically audit account creation. 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/security/opasswd -p wa -k audit_rules_usergroup_modification If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following lines to /etc/audit/audit.rules file, in order to capture events that modify account changes: -w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification medium
CCI-000018 SRG-OS-000004-GPOS-00004 TBD - Assigned by DISA after STIG release The operating system must audit all account creations. CCE-80431-0:Record Events that Modify User/Group Information - /etc/shadow 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. 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/shadow -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/shadow -p wa -k audit_rules_usergroup_modification
Applicable - Configurable Verify the operating system automatically audits account creation. If it does not, this is a finding. To determine if the system is configured to audit account changes, run the following command: auditctl -l | egrep '(/etc/shadow)' If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each). Is it the case that the system is not configured to audit account changes? Configure the operating system to automatically audit account creation. 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/shadow -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/shadow -p wa -k audit_rules_usergroup_modification medium
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. CCE-26884-7:Set Lockout Time for Failed Password Attempts 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. To configure the system to lock out accounts after a number of incorrect login attempts and require an administrator to unlock the account using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

  • add the following line immediately before the pam_unix.so statement in the AUTH section:
    auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval=
  • add the following line immediately after the pam_unix.so statement in the AUTH section:
    auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval=
  • add the following line immediately before the pam_unix.so statement in the ACCOUNT section:
    account required pam_faillock.so
If unlock_time is set to 0, manual intervention by an administrator is required to unlock a user.
Applicable - Configurable Verify that the operating system enforces the limit of three consecutive invalid logon attempts by a user during a 15-minute time period. If it does not, this is a finding. To ensure the failed password attempt policy is configured correctly, run the following command: $ grep pam_faillock /etc/pam.d/system-auth The output should show unlock_time=<some-large-number> or 0 for never. Is it the case that unlock_time is less than the expected value? Configure the operating system to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period. To configure the system to lock out accounts after a number of incorrect login attempts and require an administrator to unlock the account using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows: add the following line immediately before the pam_unix.so statement in the AUTH section: auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval= add the following line immediately after the pam_unix.so statement in the AUTH section: auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval= add the following line immediately before the pam_unix.so statement in the ACCOUNT section: account required pam_faillock.so If unlock_time is set to 0, manual intervention by an administrator is required to unlock a user. medium
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. CCE-27297-1:Set Interval For Counting Failed Password Attempts 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. 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. Modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

  • Add the following line immediately before the pam_unix.so statement in the AUTH section:
    auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval=
  • Add the following line immediately after the pam_unix.so statement in the AUTH section:
    auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval=
    
  • Add the following line immediately before the pam_unix.so statement in the ACCOUNT section:
    account required pam_faillock.so
Applicable - Configurable Verify that the operating system enforces the limit of three consecutive invalid logon attempts by a user during a 15-minute time period. If it does not, this is a finding. To ensure the failed password attempt policy is configured correctly, run the following command: $ grep pam_faillock /etc/pam.d/system-auth /etc/pam.d/password-auth For each file, the output should show fail_interval=<interval-in-seconds> where interval-in-seconds is or greater. If the fail_interval parameter is not set, the default setting of 900 seconds is acceptable. Is it the case that fail_interval is less than the required value? Configure the operating system to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period. 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. Modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows: Add the following line immediately before the pam_unix.so statement in the AUTH section: auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval= Add the following line immediately after the pam_unix.so statement in the AUTH section: auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval= Add the following line immediately before the pam_unix.so statement in the ACCOUNT section: account required pam_faillock.so medium
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. CCE-80353-6:Configure the root Account for Failed Password Attempts 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. To configure the system to lock out the root account after a number of incorrect login attempts using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

  • Modify the following line in the AUTH section to add even_deny_root:
    auth required pam_faillock.so preauth silent even_deny_root deny= unlock_time= fail_interval=
  • Modify the following line in the AUTH section to add even_deny_root:
    auth [default=die] pam_faillock.so authfail even_deny_root deny= unlock_time= fail_interval=
Applicable - Configurable Verify that the operating system enforces the limit of three consecutive invalid logon attempts by a user during a 15-minute time period. If it does not, this is a finding. To ensure that even the root account is locked after a defined number of failed password attempts, run the following command: $ grep even_deny_root /etc/pam.d/system-auth The output should show even_deny_root. Is it the case that that is not the case? Configure the operating system to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period. To configure the system to lock out the root account after a number of incorrect login attempts using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows: Modify the following line in the AUTH section to add even_deny_root: auth required pam_faillock.so preauth silent even_deny_root deny= unlock_time= fail_interval=Modify the following line in the AUTH section to add even_deny_root: auth [default=die] pam_faillock.so authfail even_deny_root deny= unlock_time= fail_interval= medium
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. CCE-27350-8:Set Deny For Failed Password Attempts 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. To configure the system to lock out accounts after a number of incorrect login attempts using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

  • add the following line immediately before the pam_unix.so statement in the AUTH section:
    auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval=
  • add the following line immediately after the pam_unix.so statement in the AUTH section:
    auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval=
  • add the following line immediately before the pam_unix.so statement in the ACCOUNT section:
    account required pam_faillock.so
Applicable - Configurable Verify that the operating system enforces the limit of three consecutive invalid logon attempts by a user during a 15-minute time period. If it does not, this is a finding. To ensure the failed password attempt policy is configured correctly, run the following command: $ grep pam_faillock /etc/pam.d/system-auth The output should show deny=. Is it the case that that is not the case? Configure the operating system to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period. To configure the system to lock out accounts after a number of incorrect login attempts using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows: add the following line immediately before the pam_unix.so statement in the AUTH section: auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval= add the following line immediately after the pam_unix.so statement in the AUTH section: auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval= add the following line immediately before the pam_unix.so statement in the ACCOUNT section: account required pam_faillock.so medium
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.
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. CCE-27303-7:Modify the System Login Banner 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 read & consent to terms in IS user agreem't." 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.
Applicable - Configurable Verify the operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. 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 read & consent to terms in IS user agreem't." If it does not, this is a finding. To check if the system login banner is compliant, run the following command: $ cat /etc/issue Is it the case that it does not display the required banner? Configure the operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. 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 read & consent to terms in IS user agreem't." If it does not, this is a finding. 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. medium
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. CCE-26970-4:Enable GNOME3 Login Warning Banner 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 read & consent to terms in IS user agreem't." 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.
Applicable - Configurable Verify the operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. 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 read & consent to terms in IS user agreem't." If it does not, this is a finding. To ensure a login warning banner is enabled, run the following: $ grep banner-message-enable /etc/dconf/db/gdm.d/* If properly configured, the output should be true. To ensure a login warning banner is locked and cannot be changed by a user, run the following: $ grep banner-message-enable /etc/dconf/db/gdm.d/locks/* If properly configured, the output should be /org/gnome/login-screen/banner-message-enable. Is it the case that it is not? Configure the operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. 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 read & consent to terms in IS user agreem't." If it does not, this is a finding. 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. medium
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. CCE-26892-0:Set the GNOME3 Login Warning Banner Text 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 read & consent to terms in IS user agreem't." 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 string '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.
Applicable - Configurable Verify the operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. 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 read & consent to terms in IS user agreem't." If it does not, this is a finding. To ensure the login warning banner text is properly set, run the following: $ grep banner-message-text /etc/dconf/db/gdm.d/* If properly configured, the proper banner text will appear. To ensure the login warning banner text is locked and cannot be changed by a user, run the following: $ grep banner-message-text /etc/dconf/db/gdm.d/locks/* If properly configured, the output should be /org/gnome/login-screen/banner-message-text. Is it the case that it does not? Configure the operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. 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 read & consent to terms in IS user agreem't." If it does not, this is a finding. 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 string '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. medium
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. CCE-27314-4:Enable SSH Warning Banner 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 read & consent to terms in IS user agreem't." 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.
Applicable - Configurable Verify the operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. 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 read & consent to terms in IS user agreem't." If it does not, this is a finding. To determine how the SSH daemon's Banner option is set, run the following command: $ sudo grep -i Banner /etc/ssh/sshd_config If a line indicating /etc/issue is returned, then the required value is set. Is it the case that the required value is not set? Configure the operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. 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 read & consent to terms in IS user agreem't." If it does not, this is a finding. 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. medium
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. CCE-27160-1:Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session Failure to restrict system access to authenticated users negatively impacts operating system security. To configure the number of retry prompts that are permitted per-session: Edit the pam_pwquality.so statement in /etc/pam.d/system-auth to show retry=, or a lower value if site policy is more restrictive. The DoD requirement is a maximum of 3 prompts per session. Applicable - Configurable If the operating system provides a public access service, such as a kiosk, this is not applicable. Verify the operating system does not allow an unattended or automatic logon to the system. If it does, this is a finding. Automatic logon as an authorized user allows access to any user with physical access to the operating system. To check how many retry attempts are permitted on a per-session basis, run the following command: $ grep pam_pwquality /etc/pam.d/system-auth The retry parameter will indicate how many attempts are permitted. The DoD required value is less than or equal to 3. This would appear as retry=3, or a lower value. Is it the case that it is not the required value? If the operating system provides a public access service, such as a kiosk, this is not applicable. Configure the operating system to not allow an unattended or automatic logon to the system. Automatic logon as an authorized user allows access to any user with physical access to the operating system. To configure the number of retry prompts that are permitted per-session: Edit the pam_pwquality.so statement in /etc/pam.d/system-auth to show retry=, or a lower value if site policy is more restrictive. The DoD requirement is a maximum of 3 prompts per session. medium
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. CCE-80104-3:Disable GDM Automatic Login Failure to restrict system access to authenticated users negatively impacts operating system security. 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
Applicable - Configurable If the operating system provides a public access service, such as a kiosk, this is not applicable. Verify the operating system does not allow an unattended or automatic logon to the system. If it does, this is a finding. Automatic logon as an authorized user allows access to any user with physical access to the operating system. To verify that automatic logins are disabled, run the following command: $ grep -Pzoi "^\[daemon]\\nautomaticlogin.*" /etc/gdm/custom.conf The output should show the following: [daemon] AutomaticLoginEnable=false Is it the case that GDM allows users to automatically login? If the operating system provides a public access service, such as a kiosk, this is not applicable. Configure the operating system to not allow an unattended or automatic logon to the system. Automatic logon as an authorized user allows access to any user with physical access to the operating system. 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 high
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. CCE-80105-0:Disable GDM Guest Login Failure to restrict system access to authenticated users negatively impacts operating system security. The GNOME Display Manager (GDM) can allow users to login without credentials which can be useful for public kiosk scenarios. Allowing users to login without credentials or "guest" account access has inherent security risks and should be disabled. To do disable timed logins or guest account access, set the TimedLoginEnable to false in the [daemon] section in /etc/gdm/custom.conf. For example:
[daemon]
TimedLoginEnable=false
Applicable - Configurable If the operating system provides a public access service, such as a kiosk, this is not applicable. Verify the operating system does not allow an unattended or automatic logon to the system. If it does, this is a finding. Automatic logon as an authorized user allows access to any user with physical access to the operating system. To verify that timed logins are disabled, run the following command: $ grep -Pzoi "^\[daemon]\\ntimedlogin.*" /etc/gdm/custom.conf The output should show the following: [daemon] TimedLoginEnable=false Is it the case that GDM allows a guest to login without credentials? If the operating system provides a public access service, such as a kiosk, this is not applicable. Configure the operating system to not allow an unattended or automatic logon to the system. Automatic logon as an authorized user allows access to any user with physical access to the operating system. The GNOME Display Manager (GDM) can allow users to login without credentials which can be useful for public kiosk scenarios. Allowing users to login without credentials or "guest" account access has inherent security risks and should be disabled. To do disable timed logins or guest account access, set the TimedLoginEnable to false in the [daemon] section in /etc/gdm/custom.conf. For example: [daemon] TimedLoginEnable=false high
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. CCE-27471-2:Disable SSH Access via Empty Passwords Failure to restrict system access to authenticated users negatively impacts operating system security. 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.
Applicable - Configurable If the operating system provides a public access service, such as a kiosk, this is not applicable. Verify the operating system does not allow an unattended or automatic logon to the system. If it does, this is a finding. Automatic logon as an authorized user allows access to any user with physical access to the operating system. To determine how the SSH daemon's PermitEmptyPasswords option is set, run the following command: $ sudo grep -i PermitEmptyPasswords /etc/ssh/sshd_config If no line, a commented line, or a line indicating the value no is returned, then the required value is set. Is it the case that the required value is not set? If the operating system provides a public access service, such as a kiosk, this is not applicable. Configure the operating system to not allow an unattended or automatic logon to the system. Automatic logon as an authorized user allows access to any user with physical access to the operating system. 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. high
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. CCE-27413-4:Disable Host-Based Authentication Failure to restrict system access to authenticated users negatively impacts operating system security. SSH's cryptographic host-based authentication is more secure than .rhosts authentication. However, it is not recommended that hosts unilaterally trust one another, even within an organization.

To disable host-based authentication, add or correct the following line in /etc/ssh/sshd_config:
HostbasedAuthentication no
Applicable - Configurable If the operating system provides a public access service, such as a kiosk, this is not applicable. Verify the operating system does not allow an unattended or automatic logon to the system. If it does, this is a finding. Automatic logon as an authorized user allows access to any user with physical access to the operating system. To determine how the SSH daemon's HostbasedAuthentication option is set, run the following command: $ sudo grep -i HostbasedAuthentication /etc/ssh/sshd_config If no line, a commented line, or a line indicating the value no is returned, then the required value is set. Is it the case that the required value is not set? If the operating system provides a public access service, such as a kiosk, this is not applicable. Configure the operating system to not allow an unattended or automatic logon to the system. Automatic logon as an authorized user allows access to any user with physical access to the operating system. SSH's cryptographic host-based authentication is more secure than .rhosts authentication. However, it is not recommended that hosts unilaterally trust one another, even within an organization. To disable host-based authentication, add or correct the following line in /etc/ssh/sshd_config: HostbasedAuthentication no medium
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. CCE-27363-1:Do Not Allow SSH Environment Options Failure to restrict system access to authenticated users negatively impacts operating system security. To ensure users are not able to override environment variables of the SSH daemon, add or correct the following line in /etc/ssh/sshd_config:
PermitUserEnvironment no
Applicable - Configurable If the operating system provides a public access service, such as a kiosk, this is not applicable. Verify the operating system does not allow an unattended or automatic logon to the system. If it does, this is a finding. Automatic logon as an authorized user allows access to any user with physical access to the operating system. To ensure users are not able to send environment variables, run the following command: $ sudo grep PermitUserEnvironment /etc/ssh/sshd_config If properly configured, output should be: PermitUserEnvironment no Is it the case that PermitUserEnvironment is not disabled? If the operating system provides a public access service, such as a kiosk, this is not applicable. Configure the operating system to not allow an unattended or automatic logon to the system. Automatic logon as an authorized user allows access to any user with physical access to the operating system. To ensure users are not able to override environment variables of the SSH daemon, add or correct the following line in /etc/ssh/sshd_config: PermitUserEnvironment no medium
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. CCE-80205-8:Ensure the Default Umask is Set Correctly in login.defs Setting the most restrictive default permissions ensures that when new accounts are created they do not have unnecessary access. 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 
Applicable - Configurable Verify the operating system defines default permissions for all authenticated users in such a way that the user can only read and modify their own files. If it does not, this is a finding. Verify the UMASK setting is configured correctly in the /etc/login.defs file by running the following command: # grep -i "UMASK" /etc/login.defs All output must show the value of umask set as shown in the below: # grep -i "UMASK" /etc/login.defs umask Is it the case that the above command returns no output, or if the umask is configured incorrectly? Configure the operating system to define default permissions for all authenticated users in such a way that the user can only read and modify their own files. 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 medium
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. CCE-27275-7:Ensure PAM Displays Last Logon/Access Notification 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. 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 read as follows:
session     [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service !~ su* quiet
session     [default=1]   pam_lastlog.so nowtmp showfailed
session     optional      pam_lastlog.so silent noupdate showfailed
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To ensure that last logon/access notification is configured correctly, run the following command: $ grep pam_lastlog.so /etc/pam.d/postlogin The output should show output showfailed. Is it the case that that is not the case? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 read as follows: session [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service !~ su* quiet session [default=1] pam_lastlog.so nowtmp showfailed session optional pam_lastlog.so silent noupdate showfailed low
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. CCE-80524-2:Ensure that Users Path Contains Only Local Directories 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. 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. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify 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, run the following command: $ sudo grep -r PATH /home/ Inspect the output for any PATH is references directories outside the home directory. Is it the case that paths contain more than local home directories? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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. medium
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. CCE-80534-1:All User Files and Directories In The Home Directory Must Be Group-Owned By The Primary User 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify all files and directories in interactive user home directory are group-owned by a group the user is a member of, run the following command: $ sudo ls -lLR /home/USER Is it the case that the group ownership is incorrect? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-80535-8:All User Files and Directories In The Home Directory Must Have Mode 0750 Or Less Permissive 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify all files and directories contained in interactive user home directory, excluding local initialization files, have a mode of 0750, run the following command: $ sudo ls -lLR /home/USER Is it the case that home directory files or folders have incorrect permissions? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-80531-7:All Interactive User Home Directories Must Be Owned By The Primary User 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. Change the owner of interactive users home directories to that correct owner. To change the owner of a interactive users home directory, use the following command:
$ sudo chown USER /home/USER
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify the home directory ownership, run the following command: $ sudo ls -ld $(egrep ':[0-9]{4}' /etc/passwd | cut -d: -f6) Is it the case that the user ownership is incorrect? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Change the owner of interactive users home directories to that correct owner. To change the owner of a interactive users home directory, use the following command: $ sudo chown USER /home/USER medium
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. CCE-80527-5:User Initialization Files Must Be Owned By the Primary User 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. Set the owner of the user initialization files for interactive users to the primary owner with the following command:
$ sudo chown USER /home/USER/.*
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify all local initialization files for interactive users are owned by the primary user, run the following command: $ sudo ls -al /home/USER/.* The user initialization files should be owned by USER. Is it the case that they are not? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Set the owner of the user initialization files for interactive users to the primary owner with the following command: $ sudo chown USER /home/USER/.* medium
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. CCE-80523-4:User Initialization Files Must Not Run World-Writable Programs 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. Set the mode on files being executed by the user initialization files with the following command:
$ sudo chmod 0755 FILE
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify that local initialization files do not execute world-writable programs, execute the following command: $ sudo find /home -perm -002 -type f -exec ls -ld {} -name ".[^.]*"\; There should be no output. Is it the case that files are executing world-writable programs? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Set the mode on files being executed by the user initialization files with the following command: $ sudo chmod 0755 FILE medium
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. CCE-80533-3:All User Files and Directories In The Home Directory Must Be Owned By The Primary User 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. Change the owner of a interactive users files and directories to that owner. To change the of a local interactive users files and directories, use the following command:
$ sudo chown -R USER /home/USER
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify all files and directories in interactive users home directory are owned by the user, run the following command: $ sudo ls -lLR /home/USER Is it the case that the user ownership is incorrect? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Change the owner of a interactive users files and directories to that owner. To change the of a local interactive users files and directories, use the following command: $ sudo chown -R USER /home/USER medium
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. CCE-80530-9:All Interactive User Home Directories Must Have mode 0750 Or Less Permissive 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify the assigned home directory of all interactive user home directories have a mode of 0750 or less permissive, run the following command: $ sudo ls -l /home Inspect the output for any directories with incorrect permissions. Is it the case that they are more permissive? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-80532-5:All Interactive User Home Directories Must Be Group-Owned By The Primary User 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify the assigned home directory of all interactive users is group- owned by that users primary GID, run the following command: $ sudo ls -ld $ (egrep ':[0-9]{4}' /etc/passwd | cut -d: -f6) Is it the case that the group ownership is incorrect? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-80434-4:Ensure Home Directories are Created for New Users 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. Check if the system is configured to create home directories for local interactive users with the following command: $ sudo grep create_home /etc/login.defs Is it the case that the value of CREATE_HOME is not set to yes, is missing, or the line is commented out? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-80529-1:All Interactive Users Home Directories Must Exist 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. Create home directories to all 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify the assigned home directory of all interactive users on the system exist, run the following command: $ sudo pwck -r The output should not return any interactive users. Is it the case that users home directory does not exist? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Create home directories to all 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 medium
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. CCE-80525-9:Ensure All User Initialization Files Have Mode 0740 Or Less Permissive 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. Set the mode of the user initialization files to 0740 with the following command:
$ sudo chmod 0740 /home/USER/.INIT_FILE
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify that all user initialization files have a mode of 0740 or less permissive, run the following command: $ sudo find /home -type f -name '\.*' \( -perm -0002 -o -perm -0020 \) There should be no output. Is it the case that they are not 0740 or more permissive? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Set the mode of the user initialization files to 0740 with the following command: $ sudo chmod 0740 /home/USER/.INIT_FILE medium
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. CCE-80526-7:User Initialization Files Must Be Group-Owned By The Primary User 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. Change the group owner of interactive users files to the group found in
/etc/passwd
for the user. To change the group owner of a local interactive user home directory, use the following command:
$ sudo chgrp USER_GROUP /home/USER/.INIT_FILE
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify the local initialization files of all local interactive users are group- owned by the appropriate user, inspect the primary group of the respective users in /etc/passwd and verify all initialization files under the respective users home directory. Check the group owner of all local interactive users initialization files. Is it the case that they are not? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Change the group owner of interactive users files to the group found in /etc/passwd for the user. To change the group owner of a local interactive user home directory, use the following command: $ sudo chgrp USER_GROUP /home/USER/.INIT_FILE medium
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. CCE-80528-3:All Interactive Users Must Have A Home Directory Defined 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. Assign home directories to all interactive users that currently do not have a home directory assigned. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify interactive users on the system have a home directory assigned, run the following command: $ sudo awk -F":" '{print $1 ":" $6}' /etc/passwd Inspect the output and verify that all interactive users have a home directory defined. Is it the case that users home directory is not defined? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Assign home directories to all interactive users that currently do not have a home directory assigned. medium
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. CCE-80536-6:Ensure the Default Umask is Set Correctly For Interactive Users 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. Remove the UMASK environment variable from all interactive users initialization files. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. Verify the UMASK setting is not configured for interactive users, run the following command: $ sudo grep -ri "UMASK" /home There should be no output. Is it the case that the above command returns no output, or if the umask is configured incorrectly? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Remove the UMASK environment variable from all interactive users initialization files. medium
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. CCE-27286-4:Prevent Login to Accounts With Empty Password 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. If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. Remove any instances of the nullok option in /etc/pam.d/system-auth to prevent logins with empty passwords. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify that null passwords cannot be used, run the following command: $ grep nullok /etc/pam.d/system-auth If this produces any output, it may be possible to log into accounts with empty passwords. Remove any instances of the nullok option to prevent logins with empty passwords. Is it the case that NULL passwords can be used? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. Remove any instances of the nullok option in /etc/pam.d/system-auth to prevent logins with empty passwords. high
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. CCE-82054-8:Verify Only Root Has UID 0 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. 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.
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To list all password file entries for accounts with UID 0, run the following command: $ awk -F: '($3 == \"0\") {print}' /etc/passwd This should print only one line, for the user root. If there is a finding, change the UID of the failing (non-root) user. If the account is associated with the system commands or applications the UID should be changed to one greater than 0 but less than 1000. Otherwise assign a UID of greater than 1000 that has not already been assigned. Is it the case that any account other than root has a UID of 0? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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. high
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. CCE-27511-5:Disable Ctrl-Alt-Del Reboot Activation 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. 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
or
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.
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To ensure the system is configured to mask the Ctrl-Alt-Del sequence, enter the following command: $ sudo ln -sf /dev/null /etc/systemd/system/ctrl-alt-del.target or $ sudo systemctl mask ctrl-alt-del.target Is it the case that the system is configured to reboot when Ctrl-Alt-Del is pressed? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 or 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. high
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. CCE-81004-4:Make sure that the dconf databases are up-to-date with regards to respective keyfiles 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. By default, DConf uses a binary database as a data backend. The system-level database is compiled from keyfiles in the /etc/dconf/db/ directory by the
dconf update
command.
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. In order to be sure that the databases are up-to-date, run the dconf update command as the administrator. Is it the case that The system-wide dconf databases are up-to-date with regards to respective keyfiles? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. By default, DConf uses a binary database as a data backend. The system-level database is compiled from keyfiles in the /etc/dconf/db/ directory by the dconf update command. high
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. CCE-80375-9:Configure AIDE to Verify Access Control Lists (ACLs) 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. 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.
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To determine that AIDE is verifying ACLs, run the following command: $ grep acl /etc/aide.conf Verify that the acl option is added to the correct ruleset. Is it the case that the acl option is missing or not added to the correct ruleset? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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. low
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. CCE-80377-5:Configure AIDE to Use FIPS 140-2 for Validating Hashes 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. By default, the sha512 option is added to the NORMAL ruleset in AIDE. If using a custom ruleset or the sha512 option is missing, add sha512 to the appropriate ruleset. For example, add sha512 to the following line in /etc/aide.conf:
NORMAL = FIPSR+sha512
AIDE rules can be configured in multiple ways; this is merely one example that is already configured by default.
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To determine that AIDE is configured for FIPS 140-2 file hashing, run the following command: $ grep sha512 /etc/aide.conf Verify that the sha512 option is added to the correct ruleset. Is it the case that the sha512 option is missing or not added to the correct ruleset? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. By default, the sha512 option is added to the NORMAL ruleset in AIDE. If using a custom ruleset or the sha512 option is missing, add sha512 to the appropriate ruleset. For example, add sha512 to the following line in /etc/aide.conf: NORMAL = FIPSR+sha512 AIDE rules can be configured in multiple ways; this is merely one example that is already configured by default. medium
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. CCE-80376-7:Configure AIDE to Verify Extended Attributes 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. 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.
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To determine that AIDE is verifying extended file attributes, run the following command: $ grep xattrs /etc/aide.conf Verify that the xattrs option is added to the correct ruleset. Is it the case that the xattrs option is missing or not added to the correct ruleset? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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. medium
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. CCE-27157-7:Verify File Hashes with RPM 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. Without cryptographic integrity protections, system executables and files can be altered by unauthorized users without detection. The RPM package management system can check the hashes of installed software packages, including many that are important to system security. To verify that the cryptographic hash of system files and commands match vendor values, run the following command to list which files on the system have hashes that differ from what is expected by the RPM database:
$ rpm -Va | grep '^..5'
A "c" in the second column indicates that a file is a configuration file, which may appropriately be expected to change. If the file was not expected to change, investigate the cause of the change using audit logs or other means. The package can then be reinstalled to restore the file. Run the following command to determine which package owns the file:
$ rpm -qf FILENAME
The package can be reinstalled from a yum repository using the command:
$ sudo yum reinstall PACKAGENAME
Alternatively, the package can be reinstalled from trusted media using the command:
$ sudo rpm -Uvh PACKAGENAME
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. The following command will list which files on the system have file hashes different from what is expected by the RPM database. $ rpm -Va | awk '$1 ~ /..5/ && $2 != "c"' Is it the case that there is output? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Without cryptographic integrity protections, system executables and files can be altered by unauthorized users without detection. The RPM package management system can check the hashes of installed software packages, including many that are important to system security. To verify that the cryptographic hash of system files and commands match vendor values, run the following command to list which files on the system have hashes that differ from what is expected by the RPM database: $ rpm -Va | grep '^..5' A "c" in the second column indicates that a file is a configuration file, which may appropriately be expected to change. If the file was not expected to change, investigate the cause of the change using audit logs or other means. The package can then be reinstalled to restore the file. Run the following command to determine which package owns the file: $ rpm -qf FILENAME The package can be reinstalled from a yum repository using the command: $ sudo yum reinstall PACKAGENAME Alternatively, the package can be reinstalled from trusted media using the command: $ sudo rpm -Uvh PACKAGENAME high
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. CCE-27140-3:Install Virus Scanning Software 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. Virus scanning software can be used to protect a system from penetration from computer viruses and to limit their spread through intermediate systems. The virus scanning software should be configured to perform scans dynamically on accessed files. If this capability is not available, the system must be configured to scan, at a minimum, all altered files on the system on a daily basis. If the system processes inbound SMTP mail, the virus scanner must be configured to scan all received mail. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. Verify an anti-virus solution is installed on the system. The anti-virus solution may be bundled with an approved host-based security solution. Is it the case that there is no anti-virus solution installed on the system? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Virus scanning software can be used to protect a system from penetration from computer viruses and to limit their spread through intermediate systems. The virus scanning software should be configured to perform scans dynamically on accessed files. If this capability is not available, the system must be configured to scan, at a minimum, all altered files on the system on a daily basis. If the system processes inbound SMTP mail, the virus scanner must be configured to scan all received mail. high
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. CCE-82371-6:The Installed Operating System Is Vendor Supported 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. The installed operating system must be maintained by a vendor. SUSE Linux Enterprise is supported by SUSE. As the SUSE Linux Enterprise vendor, SUSE is responsible for providing security patches. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify that the installed operating system is supported, run the following command: $ grep -i "red hat" /etc/redhat-release The output should contain something similar to: Red Hat Enterprise Linux 7 Is it the case that the installed operating system is not supported? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. The installed operating system must be maintained by a vendor. SUSE Linux Enterprise is supported by SUSE. As the SUSE Linux Enterprise vendor, SUSE is responsible for providing security patches. high
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. CCE-26895-3:Ensure Software Patches Installed 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. 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.
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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. high
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. CCE-82035-7:Ensure /var/log/audit Located On Separate Partition 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. Audit logs are stored in the /var/log/audit directory. Ensure that it has its own partition or logical volume at installation time, or migrate it later using LVM. Make absolutely certain that it is large enough to store all audit logs that will be created by the auditing daemon. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. Run the following command to determine if /var/log/audit is on its own partition or logical volume: $ mount | grep "on /var/log/audit" If /var/log/audit has its own partition or volume group, a line will be returned. Is it the case that no line is returned? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Audit logs are stored in the /var/log/audit directory. Ensure that it has its own partition or logical volume at installation time, or migrate it later using LVM. Make absolutely certain that it is large enough to store all audit logs that will be created by the auditing daemon. low
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. CCE-80144-9:Ensure /home Located On Separate Partition 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. 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. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. Run the following command to determine if /home is on its own partition or logical volume: $ mount | grep "on /home" If /home has its own partition or volume group, a line will be returned. Is it the case that no line is returned? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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. low
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. CCE-82014-2:Ensure /var Located On Separate Partition 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. 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. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. Run the following command to determine if /var is on its own partition or logical volume: $ mount | grep "on /var" If /var has its own partition or volume group, a line will be returned. Is it the case that no line is returned? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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. low
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. CCE-82053-0:Ensure /tmp Located On Separate Partition 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. 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. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. Run the following command to determine if /tmp is on its own partition or logical volume: $ mount | grep "on /tmp" If /tmp has its own partition or volume group, a line will be returned. Is it the case that no line is returned? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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. low
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. CCE-80192-8:Ensure rsyslog Does Not Accept Remote Messages Unless Acting As Log Server 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. The rsyslog daemon should not accept remote messages unless the system acts as a log server. To ensure that it is not listening on the network, ensure the following lines are not found in /etc/rsyslog.conf:
$ModLoad imtcp
$InputTCPServerRun port
$ModLoad imudp
$UDPServerRun port
$ModLoad imrelp
$InputRELPServerRun port
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. The rsyslog daemon should not accept remote messages unless the system acts as a log server. To ensure that it is not listening on the network, ensure the following lines are not found in /etc/rsyslog.conf: $ModLoad imtcp $InputTCPServerRun port $ModLoad imudp $UDPServerRun port $ModLoad imrelp $InputRELPServerRun port medium
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. CCE-80380-9:Ensure cron Is Logging To Rsyslog 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. 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:
cron.*                                                  /var/log/cron
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify that cron is logging to rsyslog, run the following command: grep -rni "cron\.\*" /etc/rsyslog.* The output should return some similar to: cron.* /var/log/cron Is it the case that cron is not logging to rsyslog? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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: cron.* /var/log/cron medium
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. CCE-27343-3:Ensure Logs Sent To Remote Host 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. 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.
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To ensure logs are sent to a remote host, examine the file /etc/rsyslog.conf. If using UDP, a line similar to the following should be present: *.* @ If using TCP, a line similar to the following should be present: *.* @@ If using RELP, a line similar to the following should be present: *.* :omrelp: Is it the case that none of these are present? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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. medium
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. CCE-80438-5:Configure Multiple DNS Servers in /etc/resolv.conf 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify that DNS servers have been configured properly, perform the following: $ sudo grep nameserver /etc/resolv.conf The output should return more than one nameserver entry. Is it the case that it does not exist or is not properly configured or less than 2 'nameserver' entries exist? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 low
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. CCE-80174-6:Ensure System is Not Acting as a Network Sniffer 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. Promiscuous mode of an interface can be disabled with the following command: $ sudo ip link set dev device_name promisc off Is it the case that any network device is in promiscuous mode? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-80998-8:Verify firewalld Enabled 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. The firewalld service can be enabled with the following command:
$ sudo systemctl enable firewalld.service
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. Run the following command to determine the current status of the firewalld service: $ systemctl is-active firewalld If the service is running, it should return the following: active Is it the case that ? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. The firewalld service can be enabled with the following command: $ sudo systemctl enable firewalld.service medium
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. CCE-27349-0:Set Default firewalld Zone for Incoming Packets 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. Inspect the file /etc/firewalld/firewalld.conf to determine the default zone for the firewalld. It should be set to DefaultZone=drop: $ sudo grep DefaultZone /etc/firewalld/firewalld.conf Is it the case that the default zone is not set to DROP? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-80179-5:Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv6 Interfaces 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. The runtime status of the net.ipv6.conf.all.accept_source_route kernel parameter can be queried by running the following command: $ sysctl net.ipv6.conf.all.accept_source_route The output of the command should indicate a value of 0. The preferable way how to assure the runtime compliance is to have correct persistent configuration, and rebooting the system. The persistent kernel parameter configuration is performed by specifying the appropriate assignment in any file located in the /etc/sysctl.d directory. Verify that there is not any existing incorrect configuration by executing the following command: $ grep -r '^\s*net.ipv6.conf.all.accept_source_route\s*=' /etc/sysctl.conf /etc/sysctl.d If any assignments other than net.ipv6.conf.all.accept_source_route = 0 are found, or the correct assignment is duplicated, remove those offending lines from respective files, and make sure that exactly one file in /etc/sysctl.d contains net.ipv6.conf.all.accept_source_route = 0, and that one assignment is returned when $ grep -r net.ipv6.conf.all.accept_source_route /etc/sysctl.conf /etc/sysctl.d is executed. Is it the case that the correct value is not returned? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-80171-2:Verify Any Configured IPSec Tunnel Connections 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. Libreswan provides an implementation of IPsec and IKE, which permits the creation of secure tunnels over untrusted networks. As such, IPsec can be used to circumvent certain network requirements such as filtering. Verify that if any IPsec connection (conn) configured in /etc/ipsec.conf and /etc/ipsec.d exists is an approved organizational connection. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To check for configured IPsec connections (conn), perform the following: grep -rni conn /etc/ipsec.conf /etc/ipsec.d/ Verify any returned results for organizational approval. Is it the case that the IPSec tunnels are not approved? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Libreswan provides an implementation of IPsec and IKE, which permits the creation of secure tunnels over untrusted networks. As such, IPsec can be used to circumvent certain network requirements such as filtering. Verify that if any IPsec connection (conn) configured in /etc/ipsec.conf and /etc/ipsec.d exists is an approved organizational connection. medium
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. CCE-80163-9:Disable Kernel Parameter for Accepting ICMP Redirects by Default on IPv4 Interfaces 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. The runtime status of the net.ipv4.conf.default.accept_redirects kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.default.accept_redirects The output of the command should indicate a value of 0. The preferable way how to assure the runtime compliance is to have correct persistent configuration, and rebooting the system. The persistent kernel parameter configuration is performed by specifying the appropriate assignment in any file located in the /etc/sysctl.d directory. Verify that there is not any existing incorrect configuration by executing the following command: $ grep -r '^\s*net.ipv4.conf.default.accept_redirects\s*=' /etc/sysctl.conf /etc/sysctl.d If any assignments other than net.ipv4.conf.default.accept_redirects = 0 are found, or the correct assignment is duplicated, remove those offending lines from respective files, and make sure that exactly one file in /etc/sysctl.d contains net.ipv4.conf.default.accept_redirects = 0, and that one assignment is returned when $ grep -r net.ipv4.conf.default.accept_redirects /etc/sysctl.conf /etc/sysctl.d is executed. Is it the case that the correct value is not returned? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-80165-4:Enable Kernel Parameter to Ignore ICMP Broadcast Echo Requests on IPv4 Interfaces 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. The runtime status of the net.ipv4.icmp_echo_ignore_broadcasts kernel parameter can be queried by running the following command: $ sysctl net.ipv4.icmp_echo_ignore_broadcasts The output of the command should indicate a value of 1. The preferable way how to assure the runtime compliance is to have correct persistent configuration, and rebooting the system. The persistent kernel parameter configuration is performed by specifying the appropriate assignment in any file located in the /etc/sysctl.d directory. Verify that there is not any existing incorrect configuration by executing the following command: $ grep -r '^\s*net.ipv4.icmp_echo_ignore_broadcasts\s*=' /etc/sysctl.conf /etc/sysctl.d If any assignments other than net.ipv4.icmp_echo_ignore_broadcasts = 1 are found, or the correct assignment is duplicated, remove those offending lines from respective files, and make sure that exactly one file in /etc/sysctl.d contains net.ipv4.icmp_echo_ignore_broadcasts = 1, and that one assignment is returned when $ grep -r net.ipv4.icmp_echo_ignore_broadcasts /etc/sysctl.conf /etc/sysctl.d is executed. Is it the case that the correct value is not returned? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-80162-1:Disable Kernel Parameter for Accepting Source-Routed Packets on IPv4 Interfaces by Default 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. The runtime status of the net.ipv4.conf.default.accept_source_route kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.default.accept_source_route The output of the command should indicate a value of 0. The preferable way how to assure the runtime compliance is to have correct persistent configuration, and rebooting the system. The persistent kernel parameter configuration is performed by specifying the appropriate assignment in any file located in the /etc/sysctl.d directory. Verify that there is not any existing incorrect configuration by executing the following command: $ grep -r '^\s*net.ipv4.conf.default.accept_source_route\s*=' /etc/sysctl.conf /etc/sysctl.d If any assignments other than net.ipv4.conf.default.accept_source_route = 0 are found, or the correct assignment is duplicated, remove those offending lines from respective files, and make sure that exactly one file in /etc/sysctl.d contains net.ipv4.conf.default.accept_source_route = 0, and that one assignment is returned when $ grep -r net.ipv4.conf.default.accept_source_route /etc/sysctl.conf /etc/sysctl.d is executed. Is it the case that the correct value is not returned? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-27434-0:Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv4 Interfaces 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. The runtime status of the net.ipv4.conf.all.accept_source_route kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.all.accept_source_route The output of the command should indicate a value of 0. The preferable way how to assure the runtime compliance is to have correct persistent configuration, and rebooting the system. The persistent kernel parameter configuration is performed by specifying the appropriate assignment in any file located in the /etc/sysctl.d directory. Verify that there is not any existing incorrect configuration by executing the following command: $ grep -r '^\s*net.ipv4.conf.all.accept_source_route\s*=' /etc/sysctl.conf /etc/sysctl.d If any assignments other than net.ipv4.conf.all.accept_source_route = 0 are found, or the correct assignment is duplicated, remove those offending lines from respective files, and make sure that exactly one file in /etc/sysctl.d contains net.ipv4.conf.all.accept_source_route = 0, and that one assignment is returned when $ grep -r net.ipv4.conf.all.accept_source_route /etc/sysctl.conf /etc/sysctl.d is executed. Is it the case that the correct value is not returned? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-80158-9:Disable Accepting ICMP Redirects for All IPv4 Interfaces 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. The runtime status of the net.ipv4.conf.all.accept_redirects kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.all.accept_redirects The output of the command should indicate a value of 0. The preferable way how to assure the runtime compliance is to have correct persistent configuration, and rebooting the system. The persistent kernel parameter configuration is performed by specifying the appropriate assignment in any file located in the /etc/sysctl.d directory. Verify that there is not any existing incorrect configuration by executing the following command: $ grep -r '^\s*net.ipv4.conf.all.accept_redirects\s*=' /etc/sysctl.conf /etc/sysctl.d If any assignments other than net.ipv4.conf.all.accept_redirects = 0 are found, or the correct assignment is duplicated, remove those offending lines from respective files, and make sure that exactly one file in /etc/sysctl.d contains net.ipv4.conf.all.accept_redirects = 0, and that one assignment is returned when $ grep -r net.ipv4.conf.all.accept_redirects /etc/sysctl.conf /etc/sysctl.d is executed. Is it the case that the correct value is not returned? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-80156-3:Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfaces 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. The runtime status of the net.ipv4.conf.all.send_redirects kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.all.send_redirects The output of the command should indicate a value of 0. The preferable way how to assure the runtime compliance is to have correct persistent configuration, and rebooting the system. The persistent kernel parameter configuration is performed by specifying the appropriate assignment in any file located in the /etc/sysctl.d directory. Verify that there is not any existing incorrect configuration by executing the following command: $ grep -r '^\s*net.ipv4.conf.all.send_redirects\s*=' /etc/sysctl.conf /etc/sysctl.d If any assignments other than net.ipv4.conf.all.send_redirects = 0 are found, or the correct assignment is duplicated, remove those offending lines from respective files, and make sure that exactly one file in /etc/sysctl.d contains net.ipv4.conf.all.send_redirects = 0, and that one assignment is returned when $ grep -r net.ipv4.conf.all.send_redirects /etc/sysctl.conf /etc/sysctl.d is executed. Is it the case that the correct value is not returned? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-80999-6:Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfaces by Default 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. The runtime status of the net.ipv4.conf.default.send_redirects kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.default.send_redirects The output of the command should indicate a value of 0. The preferable way how to assure the runtime compliance is to have correct persistent configuration, and rebooting the system. The persistent kernel parameter configuration is performed by specifying the appropriate assignment in any file located in the /etc/sysctl.d directory. Verify that there is not any existing incorrect configuration by executing the following command: $ grep -r '^\s*net.ipv4.conf.default.send_redirects\s*=' /etc/sysctl.conf /etc/sysctl.d If any assignments other than net.ipv4.conf.default.send_redirects = 0 are found, or the correct assignment is duplicated, remove those offending lines from respective files, and make sure that exactly one file in /etc/sysctl.d contains net.ipv4.conf.default.send_redirects = 0, and that one assignment is returned when $ grep -r net.ipv4.conf.default.send_redirects /etc/sysctl.conf /etc/sysctl.d is executed. Is it the case that the correct value is not returned? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-80157-1:Disable Kernel Parameter for IP Forwarding on IPv4 Interfaces 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. To set the runtime status of the net.ipv4.ip_forward kernel parameter, run the following command:
$ sudo sysctl -w net.ipv4.ip_forward=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:
net.ipv4.ip_forward = 0
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. The runtime status of the net.ipv4.ip_forward kernel parameter can be queried by running the following command: $ sysctl net.ipv4.ip_forward The output of the command should indicate a value of 0. The preferable way how to assure the runtime compliance is to have correct persistent configuration, and rebooting the system. The persistent kernel parameter configuration is performed by specifying the appropriate assignment in any file located in the /etc/sysctl.d directory. Verify that there is not any existing incorrect configuration by executing the following command: $ grep -r '^\s*net.ipv4.ip_forward\s*=' /etc/sysctl.conf /etc/sysctl.d If any assignments other than net.ipv4.ip_forward = 0 are found, or the correct assignment is duplicated, remove those offending lines from respective files, and make sure that exactly one file in /etc/sysctl.d contains net.ipv4.ip_forward = 0, and that one assignment is returned when $ grep -r net.ipv4.ip_forward /etc/sysctl.conf /etc/sysctl.d is executed. The ability to forward packets is only appropriate for routers. Is it the case that ? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. To set the runtime status of the net.ipv4.ip_forward kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.ip_forward=0 To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.ip_forward = 0 medium
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. CCE-27326-8:Ensure No Device Files are Unlabeled by SELinux 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. Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device files carry the SELinux type device_t or unlabeled_t, report the bug so that policy can be corrected. Supply information about what the device is and what programs use it.

To check for incorrectly labeled device files, run following commands:
$ sudo find /dev -context *:device_t:* \( -type c -o -type b \) -printf "%p %Z\n"
$ sudo find /dev -context *:unlabeled_t:* \( -type c -o -type b \) -printf "%p %Z\n"
It should produce no output in a well-configured system.
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To check for incorrectly labeled device files, run following commands: $ sudo find /dev -context *:device_t:* \( -type c -o -type b \) -printf "%p %Z\n" $ sudo find /dev -context *:unlabeled_t:* \( -type c -o -type b \) -printf "%p %Z\n" It should produce no output in a well-configured system. Is it the case that there is output? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device files carry the SELinux type device_t or unlabeled_t, report the bug so that policy can be corrected. Supply information about what the device is and what programs use it. To check for incorrectly labeled device files, run following commands: $ sudo find /dev -context *:device_t:* \( -type c -o -type b \) -printf "%p %Z\n" $ sudo find /dev -context *:unlabeled_t:* \( -type c -o -type b \) -printf "%p %Z\n" It should produce no output in a well-configured system. medium
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. CCE-81153-9:Add nosuid Option to /home 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. 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. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify the nosuid option is configured for the /home mount point, run the following command: $ mount | grep '\s/home\s' The output should show the corresponding mount point along with the nosuid setting in parentheses. Is it the case that the is not present in the output line, or there is no output line at all? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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. medium
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. CCE-80148-0:Add nosuid Option to Removable Media Partitions 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. 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. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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. medium
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. CCE-80134-0:Ensure All Files Are Owned by a User 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. 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. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. The following command will discover and print any files on local partitions which do not belong to a valid user. $ sudo find / -xdev -fstype local -nouser Either remove all files and directories from the system that do not have a valid user, or assign a valid user to all unowned files and directories on the system with the chown command: $ sudo chown user file Is it the case that files exist that are not owned by a valid user? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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. medium
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. CCE-80135-7:Ensure All Files Are Owned by a Group 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. If any files are not owned by a group, then the cause of their lack of group-ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate group. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. The following command will discover and print any files on local partitions which do not belong to a valid group. $ sudo find / -xdev -fstype local -nogroup Either remove all files and directories from the system that do not have a valid group, or assign a valid group with the chgrp command: $ sudo chgrp group file Is it the case that there is output? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If any files are not owned by a group, then the cause of their lack of group-ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate group. medium
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. CCE-80136-5:Ensure All World-Writable Directories Are Owned by a System Account 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. All directories in local partitions which are world-writable should be owned by root or another system account. If any world-writable directories are not owned by a system account, this should be investigated. Following this, the files should be deleted or assigned to an appropriate group. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. The following command will discover and print world-writable directories that are not owned by a system account, given the assumption that only system accounts have a uid lower than 500. Run it once for each local partition PART: $ sudo find PART -xdev -type d -perm -0002 -uid +499 -print Is it the case that there is output? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. All directories in local partitions which are world-writable should be owned by root or another system account. If any world-writable directories are not owned by a system account, this should be investigated. Following this, the files should be deleted or assigned to an appropriate group. medium
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. CCE-27498-5:Disable the Automounter 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. 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 disable autofs.service
The autofs service can be masked with the following command:
$ sudo systemctl mask autofs.service
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To check that the autofs service is disabled in system boot configuration, run the following command: $ systemctl is-enabled autofs Output should indicate the autofs service has either not been installed, or has been disabled at all runlevels, as shown in the example below: $ systemctl is-enabled autofs disabled Run the following command to verify autofs is not active (i.e. not running) through current runtime configuration: $ systemctl is-active autofs If the service is not running the command will return the following output: inactive By default the service will also be masked, to check that the autofs is masked, run the following command: $ systemctl show autofs | grep "LoadState\|UnitFileState" If the service is masked the command will return the following outputs: LoadState=masked UnitFileState=masked Is it the case that ? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 disable autofs.service The autofs service can be masked with the following command: $ sudo systemctl mask autofs.service medium
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. CCE-27277-3:Disable Modprobe Loading of USB Storage Driver 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. 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 a file in the directory /etc/modprobe.d:
install usb-storage /bin/true
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.
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. If the system is configured to prevent the loading of the usb-storage kernel module, it will contain lines inside any file in /etc/modprobe.d or the deprecated/etc/modprobe.conf. These lines instruct the module loading system to run another program (such as /bin/true) upon a module install event. Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf: $ grep -r usb-storage /etc/modprobe.conf /etc/modprobe.d Is it the case that no line is returned? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 a file in the directory /etc/modprobe.d: install usb-storage /bin/true 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. medium
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. CCE-27127-0:Enable Randomized Layout of Virtual Address Space 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. The runtime status of the kernel.randomize_va_space kernel parameter can be queried by running the following command: $ sysctl kernel.randomize_va_space The output of the command should indicate a value of 2. The preferable way how to assure the runtime compliance is to have correct persistent configuration, and rebooting the system. The persistent kernel parameter configuration is performed by specifying the appropriate assignment in any file located in the /etc/sysctl.d directory. Verify that there is not any existing incorrect configuration by executing the following command: $ grep -r '^\s*kernel.randomize_va_space\s*=' /etc/sysctl.conf /etc/sysctl.d If any assignments other than kernel.randomize_va_space = 2 are found, or the correct assignment is duplicated, remove those offending lines from respective files, and make sure that exactly one file in /etc/sysctl.d contains kernel.randomize_va_space = 2, and that one assignment is returned when $ grep -r kernel.randomize_va_space /etc/sysctl.conf /etc/sysctl.d is executed. Is it the case that the correct value is not returned? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-27458-9:Mount Remote Filesystems with Kerberos Security 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. Add the sec=krb5:krb5i:krb5p option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify the sec option is configured for all NFS mounts, run the following command: $ mount | grep "sec=" All NFS mounts should show the sec=krb5:krb5i:krb5p setting in parentheses. This is not applicable if NFS is not implemented. Is it the case that the setting is not configured, has the 'sys' option added, or does not have all Kerberos options added? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Add the sec=krb5:krb5i:krb5p option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts. medium
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. CCE-80240-5:Mount Remote Filesystems with nosuid 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. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify the nosuid option is configured for all NFS mounts, run the following command: $ mount | grep nfs All NFS mounts should show the nosuid setting in parentheses. This is not applicable if NFS is not implemented. Is it the case that the setting does not show? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts. medium
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. CCE-80436-9:Mount Remote Filesystems with noexec 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. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts. Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify the noexec option is configured for all NFS mounts, run the following command: $ mount | grep nfs All NFS mounts should show the noexec setting in parentheses. This is not applicable if NFS is not implemented. Is it the case that the setting does not show? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts. medium
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. CCE-27218-7:Remove the X Windows Package Group 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. By removing the xorg-x11-server-common package, the system no longer has X Windows installed. 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 groupremove "X Window System"
$ sudo yum remove xorg-x11-server-common
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To ensure the X Windows package group is removed, run the following command: $ rpm -qi xorg-x11-server-common The output should be: package xorg-x11-server-common is not installed Is it the case that the X Windows package group or xorg-x11-server-common has not be removed? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. By removing the xorg-x11-server-common package, the system no longer has X Windows installed. 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 groupremove "X Window System" $ sudo yum remove xorg-x11-server-common medium
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. CCE-80512-7:Prevent Unrestricted Mail Relaying 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. 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'
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify the system is configured to prevent unrestricted mail relaying, run the following command: $ sudo postconf -n smtpd_client_restrictions The output should return: smtpd_client_restrictions = permit_mynetworks,reject Is it the case that it is not? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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' medium
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. CCE-27311-0:Verify Permissions on SSH Server Public *.pub Key Files 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. To properly set the permissions of /etc/ssh/*.pub, run the command:
$ sudo chmod 0644 /etc/ssh/*.pub
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To check the permissions of /etc/ssh/*.pub, run the command: $ ls -l /etc/ssh/*.pub If properly configured, the output should indicate the following permissions: -rw-r--r-- Is it the case that /etc/ssh/*.pub has unix mode -rw-r--r--? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. To properly set the permissions of /etc/ssh/*.pub, run the command: $ sudo chmod 0644 /etc/ssh/*.pub medium
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. CCE-27485-2:Verify Permissions on SSH Server Private *_key Key Files 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. To properly set the permissions of /etc/ssh/*_key, run the command:
$ sudo chmod 0640 /etc/ssh/*_key
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To check the permissions of /etc/ssh/*_key, run the command: $ ls -l /etc/ssh/*_key If properly configured, the output should indicate the following permissions: -rw-r----- Is it the case that /etc/ssh/*_key has unix mode -rw-r-----? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. To properly set the permissions of /etc/ssh/*_key, run the command: $ sudo chmod 0640 /etc/ssh/*_key medium
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. CCE-80225-6:Enable SSH Print Last Log 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. When enabled, SSH will display the date and time of the last successful account logon. To enable LastLog in SSH, add or correct the following line in the /etc/ssh/sshd_config file:
PrintLastLog yes
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To check if PrintLastLog is enabled or set correctly, run the following command: $ sudo grep PrintLastLog /etc/ssh/sshd_config If configured properly, output should be yes Is it the case that it is commented out or is not enabled? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. When enabled, SSH will display the date and time of the last successful account logon. To enable LastLog in SSH, add or correct the following line in the /etc/ssh/sshd_config file: PrintLastLog yes medium
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. CCE-80222-3:Enable Use of Strict Mode Checking 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. 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. To enable StrictModes in SSH, add or correct the following line in the /etc/ssh/sshd_config file:
StrictModes yes
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To check if StrictModes is enabled or set correctly, run the following command: $ sudo grep StrictModes /etc/ssh/sshd_config If configured properly, output should be yes Is it the case that it is commented out or is not enabled? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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. To enable StrictModes in SSH, add or correct the following line in the /etc/ssh/sshd_config file: StrictModes yes medium
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. CCE-27445-6:Disable SSH Root Login 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To determine how the SSH daemon's PermitRootLogin option is set, run the following command: $ sudo grep -i PermitRootLogin /etc/ssh/sshd_config If a line indicating no is returned, then the required value is set. Is it the case that the required value is not set? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 medium
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. CCE-80223-1:Enable Use of Privilege Separation 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. When enabled, SSH will create an unprivileged child process that has the privilege of the authenticated user. To enable privilege separation in SSH, add or correct the following line in the /etc/ssh/sshd_config file:
UsePrivilegeSeparation 
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To check if UsePrivilegeSeparation is enabled or set correctly, run the following command: $ sudo grep UsePrivilegeSeparation /etc/ssh/sshd_config If configured properly, output should be . Is it the case that it is commented out or is not enabled? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. When enabled, SSH will create an unprivileged child process that has the privilege of the authenticated user. To enable privilege separation in SSH, add or correct the following line in the /etc/ssh/sshd_config file: UsePrivilegeSeparation medium
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. CCE-27320-1:Allow Only SSH Protocol 2 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 SSH protocol version 2 connections should be permitted. The default setting in /etc/ssh/sshd_config is correct, and can be verified by ensuring that the following line appears:
Protocol 2
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To check which SSH protocol version is allowed, check version of openssh-server with following command: $ rpm -qi openssh-server | grep Version Versions equal to or higher than 7.4 only allow Protocol 2. If version is lower than 7.4, run the following command to check configuration: $ sudo grep Protocol /etc/ssh/sshd_config If configured properly, output should be Protocol 2 Is it the case that it is commented out or is not set correctly to Protocol 2? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Only SSH protocol version 2 connections should be permitted. The default setting in /etc/ssh/sshd_config is correct, and can be verified by ensuring that the following line appears: Protocol 2 high
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. CCE-80373-4:Disable SSH Support for Rhosts RSA Authentication 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. SSH can allow authentication through the obsolete rsh command through the use of the authenticating user's SSH keys. This should be disabled.

To ensure this behavior is disabled, add or correct the following line in /etc/ssh/sshd_config:
RhostsRSAAuthentication no
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To check which SSH protocol version is allowed, check version of openssh-server with following command: $ rpm -qi openssh-server | grep Version Versions equal to or higher than 7.4 have deprecated the RhostsRSAAuthentication option. If version is lower than 7.4, run the following command to check configuration: To determine how the SSH daemon's RhostsRSAAuthentication option is set, run the following command: $ sudo grep -i RhostsRSAAuthentication /etc/ssh/sshd_config If no line, a commented line, or a line indicating the value no is returned, then the required value is set. Is it the case that the required value is not set? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. SSH can allow authentication through the obsolete rsh command through the use of the authenticating user's SSH keys. This should be disabled. To ensure this behavior is disabled, add or correct the following line in /etc/ssh/sshd_config: RhostsRSAAuthentication no medium
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. CCE-80224-9:Disable Compression Or Set Compression to delayed 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. Compression is useful for slow network connections over long distances but can cause performance issues on local LANs. If use of compression is required, it should be enabled only after a user has authenticated; otherwise, it should be disabled. To disable compression or delay compression until after a user has successfully authenticated, add or correct the following line in the /etc/ssh/sshd_config file:
Compression 
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To check if compression is enabled or set correctly, run the following command: $ sudo grep Compression /etc/ssh/sshd_config If configured properly, output should be no or delayed. Is it the case that it is commented out, or is not set to no or delayed? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Compression is useful for slow network connections over long distances but can cause performance issues on local LANs. If use of compression is required, it should be enabled only after a user has authenticated; otherwise, it should be disabled. To disable compression or delay compression until after a user has successfully authenticated, add or correct the following line in the /etc/ssh/sshd_config file: Compression medium
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. CCE-80226-4:Enable Encrypted X11 Forwarding 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. By default, remote X11 connections are not encrypted when initiated by users. SSH has the capability to encrypt remote X11 connections when SSH's X11Forwarding option is enabled.

To enable X11 Forwarding, add or correct the following line in /etc/ssh/sshd_config:
X11Forwarding yes
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To determine how the SSH daemon's X11Forwarding option is set, run the following command: $ sudo grep -i X11Forwarding /etc/ssh/sshd_config If a line indicating yes is returned, then the required value is set. Is it the case that the required value is not set? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. By default, remote X11 connections are not encrypted when initiated by users. SSH has the capability to encrypt remote X11 connections when SSH's X11Forwarding option is enabled. To enable X11 Forwarding, add or correct the following line in /etc/ssh/sshd_config: X11Forwarding yes high
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. CCE-80245-4:Uninstall vsftpd Package 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. The vsftpd package can be removed with the following command:
 $ sudo yum erase vsftpd
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. Run the following command to determine if the vsftpd package is installed: $ rpm -q vsftpd Is it the case that the package is installed? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. The vsftpd package can be removed with the following command: $ sudo yum erase vsftpd low
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. CCE-80213-2:Uninstall tftp-server Package 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. The tftp-server package can be removed with the following command:
 $ sudo yum erase tftp-server
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. Run the following command to determine if the tftp-server package is installed: $ rpm -q tftp-server Is it the case that the package is installed? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. The tftp-server package can be removed with the following command: $ sudo yum erase tftp-server high
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. CCE-80214-0:Ensure tftp Daemon Uses Secure Mode 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. If running the 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 (which is also the default):
server_args = -s /var/lib/tftpboot
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. If TFTP is not installed, this is not applicable. To determine if TFTP is installed, run the following command: $ rpm -qa | grep tftp Verify tftp is configured by with the -s option by running the following command: grep "server_args" /etc/xinetd.d/tftp The output should indicate the server_args variable is configured with the -s flag, matching the example below: $ grep "server_args" /etc/xinetd.d/tftp server_args = -s /var/lib/tftpboot Is it the case that this flag is missing? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If running the 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 (which is also the default): server_args = -s /var/lib/tftpboot medium
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. CCE-80513-5:Remove Host-Based Authentication Files 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. The shosts.equiv file 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 rm /[path]/[to]/[file]/shosts.equiv
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify that there are no shosts.equiv files on the system, run the following command: $ find / -name shosts.equiv No output should be returned. Is it the case that these files exist? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. The shosts.equiv file 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 rm /[path]/[to]/[file]/shosts.equiv high
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. CCE-80514-3:Remove User Host-Based Authentication Files 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. 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
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To verify that there are no .shosts files on the system, run the following command: $ sudo find / -name '.shosts' No output should be returned. Is it the case that these files exist? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 high
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. CCE-27386-2:Ensure Default SNMP Password Is Not Used 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. Edit /etc/snmp/snmpd.conf, remove or change the default community strings of public and private. Once the default community strings have been changed, restart the SNMP service:
$ sudo service snmpd restart
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To ensure the default password is not set, run the following command: $ sudo grep -v "^#" /etc/snmp/snmpd.conf| grep -E 'public|private' There should be no output. Is it the case that the default SNMP passwords public and private have not been changed or removed? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Edit /etc/snmp/snmpd.conf, remove or change the default community strings of public and private. Once the default community strings have been changed, restart the SNMP service: $ sudo service snmpd restart high
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. CCE-80378-3:Verify User Who Owns /etc/cron.allow file 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. If /etc/cron.allow exists, it must be owned by root. To properly set the owner of /etc/cron.allow, run the command:
$ sudo chown root /etc/cron.allow 
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To check the ownership of /etc/cron.allow, run the command: $ ls -lL /etc/cron.allow If properly configured, the output should indicate the following owner: root Is it the case that /etc/cron.allow has owner root? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If /etc/cron.allow exists, it must be owned by root. To properly set the owner of /etc/cron.allow, run the command: $ sudo chown root /etc/cron.allow medium
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. CCE-80379-1:Verify Group Who Owns /etc/cron.allow file 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. If /etc/cron.allow exists, it must be group-owned by root. To properly set the group owner of /etc/cron.allow, run the command:
$ sudo chgrp root /etc/cron.allow
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To check the group ownership of /etc/cron.allow, run the command: $ ls -lL /etc/cron.allow If properly configured, the output should indicate the following group-owner: root Is it the case that /etc/cron.allow has group owner root? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If /etc/cron.allow exists, it must be group-owned by root. To properly set the group owner of /etc/cron.allow, run the command: $ sudo chgrp root /etc/cron.allow medium
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. CCE-80258-7:Disable KDump Kernel Crash Analyzer (kdump) 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. 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 disable kdump.service
The kdump service can be masked with the following command:
$ sudo systemctl mask kdump.service
Applicable - Configurable Verify the operating system is configured in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. If it is not, this is a finding. To check that the kdump service is disabled in system boot configuration, run the following command: $ systemctl is-enabled kdump Output should indicate the kdump service has either not been installed, or has been disabled at all runlevels, as shown in the example below: $ systemctl is-enabled kdump disabled Run the following command to verify kdump is not active (i.e. not running) through current runtime configuration: $ systemctl is-active kdump If the service is not running the command will return the following output: inactive By default the service will also be masked, to check that the kdump is masked, run the following command: $ systemctl show kdump | grep "LoadState\|UnitFileState" If the service is masked the command will return the following outputs: LoadState=masked UnitFileState=masked Is it the case that ? Configure the operating system in accordance with the security configuration settings based on DoD security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. 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 disable kdump.service The kdump service can be masked with the following command: $ sudo systemctl mask kdump.service medium
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. CCE-27303-7:Modify the System Login Banner 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". 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.
Applicable - Configurable Verify the operating system displays the Standard Mandatory DoD Notice and Consent Banner until users acknowledge the usage conditions and take explicit actions to log on for further access. If it does not, this is a finding. To check if the system login banner is compliant, run the following command: $ cat /etc/issue Is it the case that it does not display the required banner? Configure the operating system to 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. 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. medium
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. CCE-26970-4:Enable GNOME3 Login Warning Banner 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". 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.
Applicable - Configurable Verify the operating system displays the Standard Mandatory DoD Notice and Consent Banner until users acknowledge the usage conditions and take explicit actions to log on for further access. If it does not, this is a finding. To ensure a login warning banner is enabled, run the following: $ grep banner-message-enable /etc/dconf/db/gdm.d/* If properly configured, the output should be true. To ensure a login warning banner is locked and cannot be changed by a user, run the following: $ grep banner-message-enable /etc/dconf/db/gdm.d/locks/* If properly configured, the output should be /org/gnome/login-screen/banner-message-enable. Is it the case that it is not? Configure the operating system to 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. 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. medium
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. CCE-26892-0:Set the GNOME3 Login Warning Banner Text 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". 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 string '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.
Applicable - Configurable Verify the operating system displays the Standard Mandatory DoD Notice and Consent Banner until users acknowledge the usage conditions and take explicit actions to log on for further access. If it does not, this is a finding. To ensure the login warning banner text is properly set, run the following: $ grep banner-message-text /etc/dconf/db/gdm.d/* If properly configured, the proper banner text will appear. To ensure the login warning banner text is locked and cannot be changed by a user, run the following: $ grep banner-message-text /etc/dconf/db/gdm.d/locks/* If properly configured, the output should be /org/gnome/login-screen/banner-message-text. Is it the case that it does not? Configure the operating system to 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. 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 string '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. medium
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. CCE-27314-4:Enable SSH Warning Banner 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". 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.
Applicable - Configurable Verify the operating system displays the Standard Mandatory DoD Notice and Consent Banner until users acknowledge the usage conditions and take explicit actions to log on for further access. If it does not, this is a finding. To determine how the SSH daemon's Banner option is set, run the following command: $ sudo grep -i Banner /etc/ssh/sshd_config If a line indicating /etc/issue is returned, then the required value is set. Is it the case that the required value is not set? Configure the operating system to 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. 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. medium
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. CCE-80352-8:Ensure the Logon Failure Delay is Set Correctly in login.defs Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account. 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 
Applicable - Configurable Verify the operating system enforces a delay of at least 4 seconds between logon prompts following a failed logon attempt. If it does not, this is a finding. Verify the FAIL_DELAY setting is configured correctly in the /etc/login.defs file by running the following command: $ sudo grep -i "FAIL_DELAY" /etc/login.defs All output must show the value of FAIL_DELAY set as shown in the below: $ sudo grep -i "FAIL_DELAY" /etc/login.defs fail_delay Is it the case that the above command returns no output, or FAIL_DELAY is configured less than the expected value? Configure the operating system to enforce a delay of at least 4 seconds between logon prompts following a failed logon attempt. 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 low
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. CCE-27160-1:Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session 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. To configure the number of retry prompts that are permitted per-session: Edit the pam_pwquality.so statement in /etc/pam.d/system-auth to show retry=, or a lower value if site policy is more restrictive. The DoD requirement is a maximum of 3 prompts per session. Applicable - Configurable Verify the operating system prevents the use of dictionary words for passwords. If it does not, this is a finding. To check how many retry attempts are permitted on a per-session basis, run the following command: $ grep pam_pwquality /etc/pam.d/system-auth The retry parameter will indicate how many attempts are permitted. The DoD required value is less than or equal to 3. This would appear as retry=3, or a lower value. Is it the case that it is not the required value? Configure the operating system to prevent the use of dictionary words for passwords. To configure the number of retry prompts that are permitted per-session: Edit the pam_pwquality.so statement in /etc/pam.d/system-auth to show retry=, or a lower value if site policy is more restrictive. The DoD requirement is a maximum of 3 prompts per session. medium
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. CCE-80541-6:Configure audispd Plugin To Send Logs To Remote Server 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 the audispd plugin to off-load audit records onto a different system or media from the system being audited. Set the remote_server option in
/etc/audisp/audisp-remote.conf
with an IP address or hostname of the system that the audispd plugin should send audit records to. For example
remote_server = 
Applicable - Configurable Verify the operating system, at a minimum, off-loads interconnected systems in real time and off-loads standalone systems weekly. If it does not, this is a finding. To verify the audispd plugin off-loads audit records onto a different system or media from the system being audited, run the following command: $ sudo grep -i remote_server /etc/audisp/audisp-remote.conf The output should return something similar to remote_server = Is it the case that audispd is not sending logs to a remote system? Configure the operating system to, at a minimum, off-load interconnected systems in real time and off-load standalone systems weekly. Configure the audispd plugin to off-load audit records onto a different system or media from the system being audited. Set the remote_server option in /etc/audisp/audisp-remote.conf with an IP address or hostname of the system that the audispd plugin should send audit records to. For example remote_server = medium
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. CCE-80540-8:Encrypt Audit Records Sent With audispd Plugin 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 the operating system to encrypt the transfer of off-loaded audit records onto a different system or media from the system being audited. Uncomment the enable_krb5 option in
/etc/audisp/audisp-remote.conf
, and set it with the following line:
enable_krb5 = yes
Applicable - Configurable Verify the operating system, at a minimum, off-loads interconnected systems in real time and off-loads standalone systems weekly. If it does not, this is a finding. To verify the audispd plugin encrypts audit records off-loaded onto a different system or media from the system being audited, run the following command: $ sudo grep -i enable_krb5 /etc/audisp/audisp-remote.conf The output should return the following: enable_krb5 = yes Is it the case that audispd is not encrypting audit records when sent over the network? Configure the operating system to, at a minimum, off-load interconnected systems in real time and off-load standalone systems weekly. Configure the operating system to encrypt the transfer of off-loaded audit records onto a different system or media from the system being audited. Uncomment the enable_krb5 option in /etc/audisp/audisp-remote.conf, and set it with the following line: enable_krb5 = yes medium
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. CCE-80359-3:Enable FIPS Mode in GRUB2 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. To ensure FIPS mode is enabled, install package dracut-fips, and rebuild initramfs by running the following commands:
$ sudo yum install dracut-fips
dracut -f
After the dracut command has been run, add the argument fips=1 to the default GRUB 2 command line for the Linux operating system in /etc/default/grub, in the manner below:
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 fips=1"
Finally, rebuild the grub.cfg file by using the
grub2-mkconfig -o
command as follows:
  • On BIOS-based machines, issue the following command as root:
    ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
  • On UEFI-based machines, issue the following command as root:
    ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
Applicable - Configurable Verify the operating system implements 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. If it does not, this is a finding. To verify that FIPS is enabled properly in grub, run the following command: $ grep fips /etc/default/grub The output should contain fips=1 Is it the case that FIPS is not configured or enabled in grub? Configure the operating system to 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. To ensure FIPS mode is enabled, install package dracut-fips, and rebuild initramfs by running the following commands: $ sudo yum install dracut-fips dracut -f After the dracut command has been run, add the argument fips=1 to the default GRUB 2 command line for the Linux operating system in /etc/default/grub, in the manner below: GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 fips=1" Finally, rebuild the grub.cfg file by using the grub2-mkconfig -o command as follows: On BIOS-based machines, issue the following command as root: ~]# grub2-mkconfig -o /boot/grub2/grub.cfgOn UEFI-based machines, issue the following command as root: ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg high
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. CCE-80547-3:Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module 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). 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 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 key=modules
Applicable - Configurable Verify the operating system generates audit records for all kernel module load, unload, and restart actions, and also for all program initiations. If it does not, this is a finding. To determine if the system is configured to audit calls to the finit_module system call, run the following command: preserve$ sudo grep "finit_module" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records for all kernel module load, unload, and restart actions, and also for all program initiations. 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 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 key=modules medium
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. CCE-80415-3:Ensure auditd Collects Information on Kernel Module Unloading - delete_module 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). 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 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.
Applicable - Configurable Verify the operating system generates audit records for all kernel module load, unload, and restart actions, and also for all program initiations. If it does not, this is a finding. To determine if the system is configured to audit calls to the delete_module system call, run the following command: preserve$ sudo grep "delete_module" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records for all kernel module load, unload, and restart actions, and also for all program initiations. 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 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. medium
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. CCE-80414-6:Ensure auditd Collects Information on Kernel Module Loading - init_module 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). 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 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.
Applicable - Configurable Verify the operating system generates audit records for all kernel module load, unload, and restart actions, and also for all program initiations. If it does not, this is a finding. To determine if the system is configured to audit calls to the init_module system call, run the following command: preserve$ sudo grep "init_module" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records for all kernel module load, unload, and restart actions, and also for all program initiations. 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 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. medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records for all kernel module load, unload, and restart actions, and also for all program initiations. If it does not, this is a finding. Configure the operating system to generate audit records for all kernel module load, unload, and restart actions, and also for all program initiations. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-80435-1:Record Events that Modify User/Group Information - /etc/passwd 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). 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification
Applicable - Configurable Verify the operating system generates audit records for all account creations, modifications, disabling, and termination events. If it does not, this is a finding. To determine if the system is configured to audit account changes, run the following command: auditctl -l | egrep '(/etc/passwd)' If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each). Is it the case that the system is not configured to audit account changes? Configure the operating system to generate audit records for all account creations, modifications, disabling, and termination events. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records for all account creations, modifications, disabling, and termination events. If it does not, this is a finding. Configure the operating system to generate audit records for all account creations, modifications, disabling, and termination events. This requirement is a permanent not a finding. No fix is required. medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records for all direct access to the information system. If it does not, this is a finding. Configure the operating system to generate audit records for all direct access to the information system. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-27364-9:Record Events that Modify the System's Discretionary Access Controls - chown 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful accesses to objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the chown system call, run the following command: preserve$ sudo grep "chown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful accesses to objects occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=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 medium
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. CCE-27356-5:Record Events that Modify the System's Discretionary Access Controls - fchown 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful accesses to objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the fchown system call, run the following command: preserve$ sudo grep "fchown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful accesses to objects occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=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 medium
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. CCE-27387-0:Record Events that Modify the System's Discretionary Access Controls - fchownat 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful accesses to objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the fchownat system call, run the following command: preserve$ sudo grep "fchownat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful accesses to objects occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=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 medium
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. CCE-27280-7:Record Events that Modify the System's Discretionary Access Controls - lsetxattr 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -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
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
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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful accesses to objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the lsetxattr system call, run the following command: preserve$ sudo grep "lsetxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful accesses to objects occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -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 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 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 medium
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. CCE-27083-5:Record Events that Modify the System's Discretionary Access Controls - lchown 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful accesses to objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the lchown system call, run the following command: preserve$ sudo grep "lchown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful accesses to objects occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=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 medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records when successful/unsuccessful accesses to objects occur. If it does not, this is a finding. Configure the operating system to generate audit records when successful/unsuccessful accesses to objects occur. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-80994-7:Record Attempts to Alter Logon and Logout Events - tallylog 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). 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/tallylog -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/tallylog -p wa -k logins
Applicable - Configurable Verify the operating system generates audit records when concurrent logons to the same account occur from different sources. If it does not, this is a finding. To verify that auditing is configured for system administrator actions, run the following command: $ sudo auditctl -l | grep "watch=/var/log/tallylog\|-w /var/log/tallylog" Is it the case that there is not output? Configure the operating system to generate audit records when concurrent logons to the same account occur from different sources. 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/tallylog -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/tallylog -p wa -k logins medium
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. CCE-80383-3:Record Attempts to Alter Logon and Logout Events - faillock 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). 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/run/faillock -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/run/faillock -p wa -k logins
Applicable - Configurable Verify the operating system generates audit records when concurrent logons to the same account occur from different sources. If it does not, this is a finding. To verify that auditing is configured for system administrator actions, run the following command: $ sudo auditctl -l | grep "watch=/var/run/faillock\|-w /var/run/faillock" Is it the case that there is not output? Configure the operating system to generate audit records when concurrent logons to the same account occur from different sources. 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/run/faillock -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/run/faillock -p wa -k logins medium
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. CCE-80384-1:Record Attempts to Alter Logon and Logout Events - lastlog 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). 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
Applicable - Configurable Verify the operating system generates audit records when concurrent logons to the same account occur from different sources. If it does not, this is a finding. To verify that auditing is configured for system administrator actions, run the following command: $ sudo auditctl -l | grep "watch=/var/log/lastlog\|-w /var/log/lastlog" Is it the case that there is not output? Configure the operating system to generate audit records when concurrent logons to the same account occur from different sources. 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 medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records when concurrent logons to the same account occur from different sources. If it does not, this is a finding. Configure the operating system to generate audit records when concurrent logons to the same account occur from different sources. This requirement is a permanent not a finding. No fix is required. medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records showing starting and ending time for user access to the system. If it does not, this is a finding. Configure the operating system to generate audit records showing starting and ending time for user access to the system. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-80547-3:Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module 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). 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 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 key=modules
Applicable - Configurable Verify the audit system is configured to audit the loading and unloading of dynamic kernel modules. If it does not, this is a finding. To determine if the system is configured to audit calls to the finit_module system call, run the following command: preserve$ sudo grep "finit_module" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the audit system to audit the loading and unloading of dynamic kernel modules. 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 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 key=modules medium
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. CCE-80415-3:Ensure auditd Collects Information on Kernel Module Unloading - delete_module 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). 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 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.
Applicable - Configurable Verify the audit system is configured to audit the loading and unloading of dynamic kernel modules. If it does not, this is a finding. To determine if the system is configured to audit calls to the delete_module system call, run the following command: preserve$ sudo grep "delete_module" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the audit system to audit the loading and unloading of dynamic kernel modules. 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 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. medium
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. CCE-80414-6:Ensure auditd Collects Information on Kernel Module Loading - init_module 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). 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 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.
Applicable - Configurable Verify the audit system is configured to audit the loading and unloading of dynamic kernel modules. If it does not, this is a finding. To determine if the system is configured to audit calls to the init_module system call, run the following command: preserve$ sudo grep "init_module" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the audit system to audit the loading and unloading of dynamic kernel modules. 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 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. medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the audit system is configured to audit the loading and unloading of dynamic kernel modules. If it does not, this is a finding. Configure the audit system to audit the loading and unloading of dynamic kernel modules. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-27461-3:Ensure auditd Collects System Administrator Actions 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). At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing is configured for system administrator actions, run the following command: $ sudo auditctl -l | grep "watch=/etc/sudoers\|watch=/etc/sudoers.d\|-w /etc/sudoers\|-w /etc/sudoers.d" Is it the case that there is not output? Configure the operating system to generate audit records for privileged activities or other system-level access. At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -w /etc/sudoers -p wa -k actions -w /etc/sudoers.d/ -p wa -k actions If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -w /etc/sudoers -p wa -k actions -w /etc/sudoers.d/ -p wa -k actions medium
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. CCE-80405-4:Ensure auditd Collects Information on the Use of Privileged Commands - umount 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). 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/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep umount /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records for privileged activities or other system-level access. 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/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80410-4:Ensure auditd Collects Information on the Use of Privileged Commands - crontab 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). 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/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep crontab /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records for privileged activities or other system-level access. 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/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80401-3:Ensure auditd Collects Information on the Use of Privileged Commands - sudo 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). 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/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep sudo /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records for privileged activities or other system-level access. 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/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80408-8:Ensure auditd Collects Information on the Use of Privileged Commands - ssh-keysign 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). 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/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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/key-sign -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep ssh-keysign /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records for privileged activities or other system-level access. 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/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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/key-sign -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes medium
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. CCE-80406-2:Ensure auditd Collects Information on the Use of Privileged Commands - postdrop 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). 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/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep postdrop /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records for privileged activities or other system-level access. 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/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80407-0:Ensure auditd Collects Information on the Use of Privileged Commands - postqueue 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). 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/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep postqueue /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records for privileged activities or other system-level access. 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/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80399-9:Ensure auditd Collects Information on the Use of Privileged Commands - userhelper 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). 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/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep userhelper /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records for privileged activities or other system-level access. 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/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes medium
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. CCE-80404-7:Ensure auditd Collects Information on the Use of Privileged Commands - chsh 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). 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/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep chsh /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records for privileged activities or other system-level access. 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/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80400-5:Ensure auditd Collects Information on the Use of Privileged Commands - su 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). 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/su -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep su /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records for privileged activities or other system-level access. 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/su -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80398-1:Ensure auditd Collects Information on the Use of Privileged Commands - chage 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). 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=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep chage /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records for privileged activities or other system-level access. 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=special-config-changes 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=special-config-changes medium
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. CCE-80396-5:Ensure auditd Collects Information on the Use of Privileged Commands - unix_chkpwd 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). 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/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep unix_chkpwd /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records for privileged activities or other system-level access. 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/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes medium
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. CCE-80403-9:Ensure auditd Collects Information on the Use of Privileged Commands - newgrp 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). 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/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep newgrp /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records for privileged activities or other system-level access. 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/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80395-7:Ensure auditd Collects Information on the Use of Privileged Commands - passwd 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). 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/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep passwd /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records for privileged activities or other system-level access. 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/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80411-2:Ensure auditd Collects Information on the Use of Privileged Commands - pam_timestamp_check 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). 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/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep pam_timestamp_check /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records for privileged activities or other system-level access. 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/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80397-3:Ensure auditd Collects Information on the Use of Privileged Commands - gpasswd 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). 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/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep gpasswd /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records for privileged activities or other system-level access. 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/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80402-1:Ensure auditd Collects Information on the Use of Privileged Commands - sudoedit 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). 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/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
Applicable - Configurable Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep sudoedit /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records for privileged activities or other system-level access. 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/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records for privileged activities or other system-level access. If it does not, this is a finding. Configure the operating system to generate audit records for privileged activities or other system-level access. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-80994-7:Record Attempts to Alter Logon and Logout Events - tallylog 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). 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/tallylog -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/tallylog -p wa -k logins
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful logon attempts occur. If it does not, this is a finding. To verify that auditing is configured for system administrator actions, run the following command: $ sudo auditctl -l | grep "watch=/var/log/tallylog\|-w /var/log/tallylog" Is it the case that there is not output? Configure the operating system to generate audit records when successful/unsuccessful logon attempts occur. 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/tallylog -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/tallylog -p wa -k logins medium
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. CCE-80383-3:Record Attempts to Alter Logon and Logout Events - faillock 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). 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/run/faillock -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/run/faillock -p wa -k logins
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful logon attempts occur. If it does not, this is a finding. To verify that auditing is configured for system administrator actions, run the following command: $ sudo auditctl -l | grep "watch=/var/run/faillock\|-w /var/run/faillock" Is it the case that there is not output? Configure the operating system to generate audit records when successful/unsuccessful logon attempts occur. 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/run/faillock -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/run/faillock -p wa -k logins medium
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. CCE-80384-1:Record Attempts to Alter Logon and Logout Events - lastlog 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). 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful logon attempts occur. If it does not, this is a finding. To verify that auditing is configured for system administrator actions, run the following command: $ sudo auditctl -l | grep "watch=/var/log/lastlog\|-w /var/log/lastlog" Is it the case that there is not output? Configure the operating system to generate audit records when successful/unsuccessful logon attempts occur. 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 medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records when successful/unsuccessful logon attempts occur. If it does not, this is a finding. Configure the operating system to generate audit records when successful/unsuccessful logon attempts occur. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-80996-2:Ensure auditd Collects File Deletion Events by User - unlink 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). 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 unlink -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 unlink -F auid>=1000 -F auid!=unset -F key=delete
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to delete security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the unlink system call, run the following command: preserve$ sudo grep "unlink" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to delete security objects occur. 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 unlink -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 unlink -F auid>=1000 -F auid!=unset -F key=delete medium
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. CCE-80662-0:Ensure auditd Collects File Deletion Events by User - unlinkat 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). 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 unlinkat -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 unlinkat -F auid>=1000 -F auid!=unset -F key=delete
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to delete security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the unlinkat system call, run the following command: preserve$ sudo grep "unlinkat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to delete security objects occur. 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 unlinkat -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 unlinkat -F auid>=1000 -F auid!=unset -F key=delete medium
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. CCE-80413-8:Ensure auditd Collects File Deletion Events by User - renameat 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). 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 renameat -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 renameat -F auid>=1000 -F auid!=unset -F key=delete
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to delete security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the renameat system call, run the following command: preserve$ sudo grep "renameat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to delete security objects occur. 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 renameat -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 renameat -F auid>=1000 -F auid!=unset -F key=delete medium
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. CCE-80412-0:Ensure auditd Collects File Deletion Events by User - rmdir 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). 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 rmdir -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 rmdir -F auid>=1000 -F auid!=unset -F key=delete
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to delete security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the rmdir system call, run the following command: preserve$ sudo grep "rmdir" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to delete security objects occur. 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 rmdir -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 rmdir -F auid>=1000 -F auid!=unset -F key=delete medium
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. CCE-80995-4:Ensure auditd Collects File Deletion Events by User - rename 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). 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to delete security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the rename system call, run the following command: preserve$ sudo grep "rename" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to delete security objects occur. 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 medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records when successful/unsuccessful attempts to delete security objects occur. If it does not, this is a finding. Configure the operating system to generate audit records when successful/unsuccessful attempts to delete security objects occur. This requirement is a permanent not a finding. No fix is required. medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records when successful/unsuccessful attempts to delete security levels occur. If it does not, this is a finding. Configure the operating system to generate audit records when successful/unsuccessful attempts to delete security levels occur. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-80996-2:Ensure auditd Collects File Deletion Events by User - unlink 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). 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 unlink -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 unlink -F auid>=1000 -F auid!=unset -F key=delete
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to delete privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the unlink system call, run the following command: preserve$ sudo grep "unlink" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to delete privileges occur. 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 unlink -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 unlink -F auid>=1000 -F auid!=unset -F key=delete medium
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. CCE-80662-0:Ensure auditd Collects File Deletion Events by User - unlinkat 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). 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 unlinkat -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 unlinkat -F auid>=1000 -F auid!=unset -F key=delete
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to delete privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the unlinkat system call, run the following command: preserve$ sudo grep "unlinkat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to delete privileges occur. 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 unlinkat -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 unlinkat -F auid>=1000 -F auid!=unset -F key=delete medium
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. CCE-80413-8:Ensure auditd Collects File Deletion Events by User - renameat 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). 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 renameat -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 renameat -F auid>=1000 -F auid!=unset -F key=delete
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to delete privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the renameat system call, run the following command: preserve$ sudo grep "renameat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to delete privileges occur. 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 renameat -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 renameat -F auid>=1000 -F auid!=unset -F key=delete medium
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. CCE-80412-0:Ensure auditd Collects File Deletion Events by User - rmdir 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). 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 rmdir -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 rmdir -F auid>=1000 -F auid!=unset -F key=delete
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to delete privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the rmdir system call, run the following command: preserve$ sudo grep "rmdir" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to delete privileges occur. 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 rmdir -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 rmdir -F auid>=1000 -F auid!=unset -F key=delete medium
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. CCE-80995-4:Ensure auditd Collects File Deletion Events by User - rename 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). 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to delete privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the rename system call, run the following command: preserve$ sudo grep "rename" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to delete privileges occur. 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 medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records when successful/unsuccessful attempts to delete privileges occur. If it does not, this is a finding. Configure the operating system to generate audit records when successful/unsuccessful attempts to delete privileges occur. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-80393-2:Record Any Attempts to Run chcon 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). 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-priv_change
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-priv_change
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur. If it does not, this is a finding. To verify that execution of the command is being audited, run the following command: $ sudo grep "path=/usr/bin/chcon" /etc/audit/audit.rules /etc/audit/rules.d/* The output should return something similar to: -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged-priv_change Is it the case that ? Configure the operating system to generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur. 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-priv_change 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-priv_change medium
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. CCE-80392-4:Record Any Attempts to Run setsebool 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). 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-priv_change
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-priv_change
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur. If it does not, this is a finding. To verify that execution of the command is being audited, run the following command: $ sudo grep "path=/usr/sbin/setsebool" /etc/audit/audit.rules /etc/audit/rules.d/* The output should return something similar to: -a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged-priv_change Is it the case that ? Configure the operating system to generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur. 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-priv_change 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-priv_change medium
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. CCE-80391-6:Record Any Attempts to Run semanage 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). 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-priv_change
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-priv_change
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur. If it does not, this is a finding. To verify that execution of the command is being audited, run the following command: $ sudo grep "path=/usr/sbin/semanage" /etc/audit/audit.rules /etc/audit/rules.d/* The output should return something similar to: -a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged-priv_change Is it the case that ? Configure the operating system to generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur. 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-priv_change 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-priv_change medium
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. CCE-80660-4:Record Any Attempts to Run setfiles 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). 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-priv_change
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-priv_change
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur. If it does not, this is a finding. To verify that execution of the command is being audited, run the following command: $ sudo grep "path=/usr/sbin/setfiles" /etc/audit/audit.rules /etc/audit/rules.d/* The output should return something similar to: -a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged-priv_change Is it the case that ? Configure the operating system to generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur. 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-priv_change 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-priv_change medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur. If it does not, this is a finding. Configure the operating system to generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-82041-5:Limit the Number of Concurrent Login Sessions Allowed Per User 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. 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 
Applicable - Configurable Verify the operating system limits the number of concurrent sessions to ten for all accounts and/or account types. If it does not, this is a finding. Run the following command to ensure the maxlogins value is configured for all users on the system: # grep "maxlogins" /etc/security/limits.conf You should receive output similar to the following: *\t\thard\tmaxlogins\t Is it the case that maxlogins is not equal to or less than the expected value? Configure the operating system to limit the number of concurrent sessions to ten for all accounts and/or account types. 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 low
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. CCE-80112-6:Enable GNOME3 Screensaver Lock After Idle Period 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. 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.
Applicable - Configurable Verify the operating system retains a user's session lock until that user reestablishes access using established identification and authentication procedures. If it does not, this is a finding. To check the status of the idle screen lock activation, run the following command: $ gsettings get org.gnome.desktop.screensaver lock-enabled If properly configured, the output should be true. To ensure that users cannot change how long until the the screensaver locks, run the following: $ grep lock-enabled /etc/dconf/db/local.d/locks/* If properly configured, the output for lock-enabled should be /org/gnome/desktop/screensaver/lock-enabled Is it the case that screensaver locking is not enabled and/or has not been set or configured correctly? Configure the operating system to retain a user's session lock until that user reestablishes access using established identification and authentication procedures. 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. medium
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system retains a user's session lock until that user reestablishes access using established identification and authentication procedures. If it does not, this is a finding. Configure the operating system to retain a user's session lock until that user reestablishes access using established identification and authentication procedures. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-27351-6:Install the screen Package 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. To enable console screen locking, install the screen package. The screen package can be installed with the following command:
$ sudo yum install screen
Instruct users to begin new terminal sessions with the following command:
$ screen
The console can now be locked with the following key combination:
ctrl+a x
Applicable - Configurable Verify the operating system initiates a session lock after a 15-minute period of inactivity for all connection types. If it does not, this is a finding. Run the following command to determine if the screen package is installed: $ rpm -q screen Is it the case that the package is not installed? Configure the operating system to initiate a session lock after a 15-minute period of inactivity for all connection types. To enable console screen locking, install the screen package. The screen package can be installed with the following command: $ sudo yum install screen Instruct users to begin new terminal sessions with the following command: $ screen The console can now be locked with the following key combination: ctrl+a x medium
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. CCE-80370-0:Set GNOME3 Screensaver Lock Delay After Activation Period 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. 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 
Once the setting has been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example:
/org/gnome/desktop/screensaver/lock-delay
After the settings have been set, run dconf update.
Applicable - Configurable Verify the operating system initiates a session lock after a 15-minute period of inactivity for all connection types. If it does not, this is a finding. To check that the screen locks immediately when activated, run the following command: $ gsettings get org.gnome.desktop.screensaver lock-delay If properly configured, the output should be 'uint32 '. To ensure that users cannot change how long until the the screensaver locks, run the following: $ grep lock-delay /etc/dconf/db/local.d/locks/* If properly configured, the output for lock-delay should be /org/gnome/desktop/screensaver/lock-delay Is it the case that the screensaver lock delay is missing, or is set to a value greater than 5? Configure the operating system to initiate a session lock after a 15-minute period of inactivity for all connection types. 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 Once the setting has been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: /org/gnome/desktop/screensaver/lock-delay After the settings have been set, run dconf update. medium
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. CCE-80544-0:Ensure Users Cannot Change GNOME3 Session Idle Settings 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. 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.
Applicable - Configurable Verify the operating system initiates a session lock after a 15-minute period of inactivity for all connection types. If it does not, this is a finding. To ensure that users cannot change session idle and lock settings, run the following: $ grep 'idle-delay' /etc/dconf/db/local.d/locks/* If properly configured, the output should return: /org/gnome/desktop/session/idle-delay Is it the case that GNOME3 session settings are not locked or configured properly? Configure the operating system to initiate a session lock after a 15-minute period of inactivity for all connection types. 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. medium
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. CCE-80110-0:Set GNOME3 Screensaver Inactivity Timeout 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. The idle time-out value for inactivity in the GNOME3 desktop is configured via the idle-delay setting must be set under an appropriate configuration file(s) in the /etc/dconf/db/local.d directory and locked in /etc/dconf/db/local.d/locks directory to prevent user modification.

For example, to configure the system for a 15 minute delay, add the following to /etc/dconf/db/local.d/00-security-settings:
[org/gnome/desktop/session]
idle-delay=uint32 900
Once the setting has been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example:
/org/gnome/desktop/session/idle-delay
After the settings have been set, run dconf update.
Applicable - Configurable Verify the operating system initiates a session lock after a 15-minute period of inactivity for all connection types. If it does not, this is a finding. To check the current idle time-out value, run the following command: $ gsettings get org.gnome.desktop.session idle-delay If properly configured, the output should be 'uint32 '. To ensure that users cannot change the screensaver inactivity timeout setting, run the following: $ grep idle-delay /etc/dconf/db/local.d/locks/* If properly configured, the output should be /org/gnome/desktop/session/idle-delay Is it the case that idle-delay is not equal to or less than the expected value? Configure the operating system to initiate a session lock after a 15-minute period of inactivity for all connection types. The idle time-out value for inactivity in the GNOME3 desktop is configured via the idle-delay setting must be set under an appropriate configuration file(s) in the /etc/dconf/db/local.d directory and locked in /etc/dconf/db/local.d/locks directory to prevent user modification. For example, to configure the system for a 15 minute delay, add the following to /etc/dconf/db/local.d/00-security-settings: [org/gnome/desktop/session] idle-delay=uint32 900 Once the setting has been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: /org/gnome/desktop/session/idle-delay After the settings have been set, run dconf update. medium
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. CCE-80371-8:Ensure Users Cannot Change GNOME3 Screensaver Settings 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. 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.
Applicable - Configurable Verify the operating system initiates a session lock after a 15-minute period of inactivity for all connection types. If it does not, this is a finding. To ensure that users cannot change session idle and lock settings, run the following: $ grep 'lock-delay' /etc/dconf/db/local.d/locks/* If properly configured, the output should return: /org/gnome/desktop/screensaver/lock-delay Is it the case that GNOME3 session settings are not locked or configured properly? Configure the operating system to initiate a session lock after a 15-minute period of inactivity for all connection types. 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. medium
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. CCE-80563-0:Ensure Users Cannot Change GNOME3 Screensaver Lock After Idle Period 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. 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/00-security-settings. For example:
/org/gnome/desktop/screensaver/lock-enabled
After the settings have been set, run dconf update.
Applicable - Configurable Verify the operating system initiates a session lock after a 15-minute period of inactivity for all connection types. If it does not, this is a finding. To ensure that users cannot change how long until the the screensaver locks, run the following: $ grep lock-enabled /etc/dconf/db/local.d/locks/* If properly configured, the output for lock-enabled should be /org/gnome/desktop/screensaver/lock-enabled Is it the case that screensaver locking is not locked? Configure the operating system to initiate a session lock after a 15-minute period of inactivity for all connection types. 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/00-security-settings. For example: /org/gnome/desktop/screensaver/lock-enabled After the settings have been set, run dconf update. medium
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. CCE-80564-8:Ensure Users Cannot Change GNOME3 Screensaver Idle Activation 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. If not already configured, ensure that users cannot change GNOME3 screensaver lock settings by adding
/org/gnome/desktop/screensaver/idle-activation-enabled
to /etc/dconf/db/local.d/00-security-settings. For example:
/org/gnome/desktop/screensaver/idle-activation-enabled
After the settings have been set, run dconf update.
Applicable - Configurable Verify the operating system initiates a session lock after a 15-minute period of inactivity for all connection types. If it does not, this is a finding. To ensure that users cannot disable the screensaver idle inactivity setting, run the following: $ grep idle-activation-enabled /etc/dconf/db/local.d/locks/* If properly configured, the output should be /org/gnome/desktop/screensaver/idle-activation-enabled Is it the case that idle_activation_enabled is not locked? Configure the operating system to initiate a session lock after a 15-minute period of inactivity for all connection types. If not already configured, ensure that users cannot change GNOME3 screensaver lock settings by adding /org/gnome/desktop/screensaver/idle-activation-enabled to /etc/dconf/db/local.d/00-security-settings. For example: /org/gnome/desktop/screensaver/idle-activation-enabled After the settings have been set, run dconf update. medium
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. CCE-80111-8:Enable GNOME3 Screensaver Idle Activation 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. To activate the screensaver in the GNOME3 desktop after a period of inactivity, add or set idle-activation-enabled to true in /etc/dconf/db/local.d/00-security-settings. For example:
[org/gnome/desktop/screensaver]
idle-activation-enabled=true
Once the setting has been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example:
/org/gnome/desktop/screensaver/idle-activation-enabled
After the settings have been set, run dconf update.
Applicable - Configurable Verify the operating system initiates a session lock after a 15-minute period of inactivity for all connection types. If it does not, this is a finding. To check the screensaver mandatory use status, run the following command: $ gsettings get org.gnome.desktop.screensaver idle-activation-enabled If properly configured, the output should be true. To ensure that users cannot disable the screensaver idle inactivity setting, run the following: $ grep idle-activation-enabled /etc/dconf/db/local.d/locks/* If properly configured, the output should be /org/gnome/desktop/screensaver/idle-activation-enabled Is it the case that idle_activation_enabled is not enabled or configured? Configure the operating system to initiate a session lock after a 15-minute period of inactivity for all connection types. To activate the screensaver in the GNOME3 desktop after a period of inactivity, add or set idle-activation-enabled to true in /etc/dconf/db/local.d/00-security-settings. For example: [org/gnome/desktop/screensaver] idle-activation-enabled=true Once the setting has been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification. For example: /org/gnome/desktop/screensaver/idle-activation-enabled After the settings have been set, run dconf update. medium
CCI-000058 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. CCE-80112-6:Enable GNOME3 Screensaver Lock After Idle Period 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. 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.
Applicable - Configurable Verify the operating system provides the capability for users to directly initiate a session lock for all connection types. If it does not, this is a finding. To check the status of the idle screen lock activation, run the following command: $ gsettings get org.gnome.desktop.screensaver lock-enabled If properly configured, the output should be true. To ensure that users cannot change how long until the the screensaver locks, run the following: $ grep lock-enabled /etc/dconf/db/local.d/locks/* If properly configured, the output for lock-enabled should be /org/gnome/desktop/screensaver/lock-enabled Is it the case that screensaver locking is not enabled and/or has not been set or configured correctly? Configure the operating system to provide the capability for users to directly initiate a session lock for all connection types. 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. medium
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.
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).
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. CCE-80359-3:Enable FIPS Mode in GRUB2 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. To ensure FIPS mode is enabled, install package dracut-fips, and rebuild initramfs by running the following commands:
$ sudo yum install dracut-fips
dracut -f
After the dracut command has been run, add the argument fips=1 to the default GRUB 2 command line for the Linux operating system in /etc/default/grub, in the manner below:
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 fips=1"
Finally, rebuild the grub.cfg file by using the
grub2-mkconfig -o
command as follows:
  • On BIOS-based machines, issue the following command as root:
    ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
  • On UEFI-based machines, issue the following command as root:
    ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
Applicable - Configurable Verify the operating system implements DoD-approved encryption to protect the confidentiality of remote access sessions. If it does not, this is a finding. To verify that FIPS is enabled properly in grub, run the following command: $ grep fips /etc/default/grub The output should contain fips=1 Is it the case that FIPS is not configured or enabled in grub? Configure the operating system to implement DoD-approved encryption to protect the confidentiality of remote access sessions. To ensure FIPS mode is enabled, install package dracut-fips, and rebuild initramfs by running the following commands: $ sudo yum install dracut-fips dracut -f After the dracut command has been run, add the argument fips=1 to the default GRUB 2 command line for the Linux operating system in /etc/default/grub, in the manner below: GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 fips=1" Finally, rebuild the grub.cfg file by using the grub2-mkconfig -o command as follows: On BIOS-based machines, issue the following command as root: ~]# grub2-mkconfig -o /boot/grub2/grub.cfgOn UEFI-based machines, issue the following command as root: ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg high
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. CCE-27295-5:Use Only FIPS 140-2 Validated Ciphers 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. Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
The man page sshd_config(5) contains a list of supported ciphers.

Only the following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux 7:
- aes128-ctr
- aes192-ctr
- aes256-ctr
- aes128-cbc
- aes192-cbc
- aes256-cbc
- 3des-cbc
- rijndael-cbc@lysator.liu.se

Any combination of the above ciphers will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following ciphers: .
Applicable - Configurable Verify the operating system implements DoD-approved encryption to protect the confidentiality of remote access sessions. If it does not, this is a finding. Only FIPS ciphers should be used. To verify that only FIPS-approved ciphers are in use, run the following command: $ sudo grep Ciphers /etc/ssh/sshd_config The output should contain only those ciphers which are FIPS-approved. Is it the case that FIPS ciphers are not configured or the enabled ciphers are not FIPS-approved? Configure the operating system to implement DoD-approved encryption to protect the confidentiality of remote access sessions. Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers: Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc The man page sshd_config(5) contains a list of supported ciphers. Only the following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux 7: - aes128-ctr - aes192-ctr - aes256-ctr - aes128-cbc - aes192-cbc - aes256-cbc - 3des-cbc - rijndael-cbc@lysator.liu.se Any combination of the above ciphers will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following ciphers: . medium
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. CCE-80393-2:Record Any Attempts to Run chcon 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). 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-priv_change
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-priv_change
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to modify security objects occur. If it does not, this is a finding. To verify that execution of the command is being audited, run the following command: $ sudo grep "path=/usr/bin/chcon" /etc/audit/audit.rules /etc/audit/rules.d/* The output should return something similar to: -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged-priv_change Is it the case that ? Configure the operating system to generate audit records when successful/unsuccessful attempts to modify security objects occur. 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-priv_change 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-priv_change medium
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. CCE-80392-4:Record Any Attempts to Run setsebool 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). 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-priv_change
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-priv_change
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to modify security objects occur. If it does not, this is a finding. To verify that execution of the command is being audited, run the following command: $ sudo grep "path=/usr/sbin/setsebool" /etc/audit/audit.rules /etc/audit/rules.d/* The output should return something similar to: -a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged-priv_change Is it the case that ? Configure the operating system to generate audit records when successful/unsuccessful attempts to modify security objects occur. 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-priv_change 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-priv_change medium
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. CCE-80391-6:Record Any Attempts to Run semanage 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). 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-priv_change
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-priv_change
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to modify security objects occur. If it does not, this is a finding. To verify that execution of the command is being audited, run the following command: $ sudo grep "path=/usr/sbin/semanage" /etc/audit/audit.rules /etc/audit/rules.d/* The output should return something similar to: -a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged-priv_change Is it the case that ? Configure the operating system to generate audit records when successful/unsuccessful attempts to modify security objects occur. 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-priv_change 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-priv_change medium
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. CCE-80660-4:Record Any Attempts to Run setfiles 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). 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-priv_change
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-priv_change
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to modify security objects occur. If it does not, this is a finding. To verify that execution of the command is being audited, run the following command: $ sudo grep "path=/usr/sbin/setfiles" /etc/audit/audit.rules /etc/audit/rules.d/* The output should return something similar to: -a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged-priv_change Is it the case that ? Configure the operating system to generate audit records when successful/unsuccessful attempts to modify security objects occur. 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-priv_change 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-priv_change medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records when successful/unsuccessful attempts to modify security objects occur. If it does not, this is a finding. Configure the operating system to generate audit records when successful/unsuccessful attempts to modify security objects occur. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-27461-3:Ensure auditd Collects System Administrator Actions 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). At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to modify privileges occur. If it does not, this is a finding. To verify that auditing is configured for system administrator actions, run the following command: $ sudo auditctl -l | grep "watch=/etc/sudoers\|watch=/etc/sudoers.d\|-w /etc/sudoers\|-w /etc/sudoers.d" Is it the case that there is not output? Configure the operating system to generate audit records when successful/unsuccessful attempts to modify privileges occur. At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -w /etc/sudoers -p wa -k actions -w /etc/sudoers.d/ -p wa -k actions If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -w /etc/sudoers -p wa -k actions -w /etc/sudoers.d/ -p wa -k actions medium
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. CCE-80401-3:Ensure auditd Collects Information on the Use of Privileged Commands - sudo 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). 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/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to modify privileges occur. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep sudo /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records when successful/unsuccessful attempts to modify privileges occur. 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/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80404-7:Ensure auditd Collects Information on the Use of Privileged Commands - chsh 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). 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/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to modify privileges occur. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep chsh /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records when successful/unsuccessful attempts to modify privileges occur. 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/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80400-5:Ensure auditd Collects Information on the Use of Privileged Commands - su 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). 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/su -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to modify privileges occur. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep su /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records when successful/unsuccessful attempts to modify privileges occur. 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/su -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80403-9:Ensure auditd Collects Information on the Use of Privileged Commands - newgrp 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). 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/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to modify privileges occur. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep newgrp /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records when successful/unsuccessful attempts to modify privileges occur. 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/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records when successful/unsuccessful attempts to modify privileges occur. If it does not, this is a finding. Configure the operating system to generate audit records when successful/unsuccessful attempts to modify privileges occur. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-27407-6:Enable auditd Service 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. 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
Applicable - Configurable Verify the operating system produces audit records containing information to establish what type of events occurred. If it does not, this is a finding. Run the following command to determine the current status of the auditd service: $ systemctl is-active auditd If the service is running, it should return the following: active Is it the case that ? Configure the operating system to produce audit records containing information to establish what type of events occurred. 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 high
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. CCE-27461-3:Ensure auditd Collects System Administrator Actions 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. At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions
Applicable - Configurable Verify the operating system produces audit records containing information to establish what type of events occurred. If it does not, this is a finding. To verify that auditing is configured for system administrator actions, run the following command: $ sudo auditctl -l | grep "watch=/etc/sudoers\|watch=/etc/sudoers.d\|-w /etc/sudoers\|-w /etc/sudoers.d" Is it the case that there is not output? Configure the operating system to produce audit records containing information to establish what type of events occurred. At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -w /etc/sudoers -p wa -k actions -w /etc/sudoers.d/ -p wa -k actions If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -w /etc/sudoers -p wa -k actions -w /etc/sudoers.d/ -p wa -k actions medium
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. CCE-80401-3:Ensure auditd Collects Information on the Use of Privileged Commands - sudo 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. 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/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system produces audit records containing information to establish what type of events occurred. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep sudo /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to produce audit records containing information to establish what type of events occurred. 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/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80404-7:Ensure auditd Collects Information on the Use of Privileged Commands - chsh 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. 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/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system produces audit records containing information to establish what type of events occurred. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep chsh /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to produce audit records containing information to establish what type of events occurred. 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/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80400-5:Ensure auditd Collects Information on the Use of Privileged Commands - su 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. 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/su -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system produces audit records containing information to establish what type of events occurred. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep su /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to produce audit records containing information to establish what type of events occurred. 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/su -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80403-9:Ensure auditd Collects Information on the Use of Privileged Commands - newgrp 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. 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/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system produces audit records containing information to establish what type of events occurred. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep newgrp /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to produce audit records containing information to establish what type of events occurred. 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/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system produces audit records containing information to establish what type of events occurred. If it does not, this is a finding. Configure the operating system to produce audit records containing information to establish what type of events occurred. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-27407-6:Enable auditd Service 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. 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
Applicable - Configurable Verify the operating system produces audit records containing information to establish when (date and time) the events occurred. If it does not, this is a finding. Run the following command to determine the current status of the auditd service: $ systemctl is-active auditd If the service is running, it should return the following: active Is it the case that ? Configure the operating system to produce audit records containing information to establish when (date and time) the events occurred. 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 high
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system produces audit records containing information to establish when (date and time) the events occurred. If it does not, this is a finding. Configure the operating system to produce audit records containing information to establish when (date and time) the events occurred. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-27407-6:Enable auditd Service 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. 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
Applicable - Configurable Verify the operating system produces audit records containing information to establish where the events occurred. If it does not, this is a finding. Run the following command to determine the current status of the auditd service: $ systemctl is-active auditd If the service is running, it should return the following: active Is it the case that ? Configure the operating system to produce audit records containing information to establish where the events occurred. 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 high
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system produces audit records containing information to establish where the events occurred. If it does not, this is a finding. Configure the operating system to produce audit records containing information to establish where the events occurred. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-27407-6:Enable auditd Service 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. 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
Applicable - Configurable Verify the operating system produces audit records containing information to establish the source of the events. If it does not, this is a finding. Run the following command to determine the current status of the auditd service: $ systemctl is-active auditd If the service is running, it should return the following: active Is it the case that ? Configure the operating system to produce audit records containing information to establish the source of the events. 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 high
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system produces audit records containing information to establish the source of the events. If it does not, this is a finding. Configure the operating system to produce audit records containing information to establish the source of the events. This requirement is a permanent not a finding. No fix is required. medium
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system produces audit records containing information to establish the outcome of the events. If it does not, this is a finding. Configure the operating system to produce audit records containing information to establish the outcome of the events. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-27461-3:Ensure auditd Collects System Administrator Actions 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. At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing is configured for system administrator actions, run the following command: $ sudo auditctl -l | grep "watch=/etc/sudoers\|watch=/etc/sudoers.d\|-w /etc/sudoers\|-w /etc/sudoers.d" Is it the case that there is not output? Configure the operating system to generate audit records containing the full-text recording of privileged commands. At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -w /etc/sudoers -p wa -k actions -w /etc/sudoers.d/ -p wa -k actions If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -w /etc/sudoers -p wa -k actions -w /etc/sudoers.d/ -p wa -k actions medium
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. CCE-27447-2:Ensure auditd Collects Information on Exporting to Media (successful) 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. 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
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system:
-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing is configured for all media exportation events, run the following command: $ sudo auditctl -l | grep syscall | grep mount Is it the case that there is not output? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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 If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system: -a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export medium
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. CCE-80405-4:Ensure auditd Collects Information on the Use of Privileged Commands - umount 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. 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/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep umount /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80410-4:Ensure auditd Collects Information on the Use of Privileged Commands - crontab 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. 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/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep crontab /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80401-3:Ensure auditd Collects Information on the Use of Privileged Commands - sudo 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. 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/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep sudo /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80408-8:Ensure auditd Collects Information on the Use of Privileged Commands - ssh-keysign 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. 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/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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/key-sign -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep ssh-keysign /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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/key-sign -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes medium
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. CCE-80406-2:Ensure auditd Collects Information on the Use of Privileged Commands - postdrop 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. 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/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep postdrop /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80407-0:Ensure auditd Collects Information on the Use of Privileged Commands - postqueue 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. 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/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep postqueue /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80399-9:Ensure auditd Collects Information on the Use of Privileged Commands - userhelper 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. 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/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep userhelper /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes medium
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. CCE-80404-7:Ensure auditd Collects Information on the Use of Privileged Commands - chsh 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. 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/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep chsh /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80400-5:Ensure auditd Collects Information on the Use of Privileged Commands - su 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. 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/su -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep su /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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/su -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80398-1:Ensure auditd Collects Information on the Use of Privileged Commands - chage 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. 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=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep chage /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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=special-config-changes 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=special-config-changes medium
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. CCE-80396-5:Ensure auditd Collects Information on the Use of Privileged Commands - unix_chkpwd 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. 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/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep unix_chkpwd /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes medium
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. CCE-80403-9:Ensure auditd Collects Information on the Use of Privileged Commands - newgrp 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. 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/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep newgrp /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80395-7:Ensure auditd Collects Information on the Use of Privileged Commands - passwd 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. 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/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep passwd /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80411-2:Ensure auditd Collects Information on the Use of Privileged Commands - pam_timestamp_check 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. 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/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep pam_timestamp_check /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80397-3:Ensure auditd Collects Information on the Use of Privileged Commands - gpasswd 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. 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/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep gpasswd /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80402-1:Ensure auditd Collects Information on the Use of Privileged Commands - sudoedit 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. 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/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
Applicable - Configurable Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep sudoedit /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to generate audit records containing the full-text recording of privileged commands. 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/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes medium
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records containing the full-text recording of privileged commands. If it does not, this is a finding. Configure the operating system to generate audit records containing the full-text recording of privileged commands. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-27407-6:Enable auditd Service 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. 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
Applicable - Configurable Verify the operating system produces audit records containing the individual identities of group account users. If it does not, this is a finding. Run the following command to determine the current status of the auditd service: $ systemctl is-active auditd If the service is running, it should return the following: active Is it the case that ? Configure the operating system to produce audit records containing the individual identities of group account users. 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 high
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system produces audit records containing the individual identities of group account users. If it does not, this is a finding. Configure the operating system to produce audit records containing the individual identities of group account users. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-80997-0:Shutdown System When Auditing Failures Occur 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. 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:
-f 2
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to the top of the /etc/audit/audit.rules file:
-f 2
Applicable - Configurable Verify the operating system alerts the ISSO and SA (at a minimum) in the event of an audit processing failure. If it does not, this is a finding. To verify that the system will shutdown when auditd fails, run the following command: $ sudo grep "\-f 2" /etc/audit/audit.rules The output should contain: -f 2 Is it the case that the system is not configured to shutdown on auditd failures? Configure the operating system to alert the ISSO and SA (at a minimum) in the event of an audit processing failure. 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: -f 2 If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to the top of the /etc/audit/audit.rules file: -f 2 medium
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). CCE-80997-0:Shutdown System When Auditing Failures Occur 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. 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:
-f 2
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to the top of the /etc/audit/audit.rules file:
-f 2
Applicable - Configurable Verify the operating system shuts down by default upon audit failure (unless availability is an overriding concern). If it does not, this is a finding. To verify that the system will shutdown when auditd fails, run the following command: $ sudo grep "\-f 2" /etc/audit/audit.rules The output should contain: -f 2 Is it the case that the system is not configured to shutdown on auditd failures? Configure the operating system to shut down by default upon audit failure (unless availability is an overriding concern). 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: -f 2 If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to the top of the /etc/audit/audit.rules file: -f 2 medium
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system provides the capability to centrally review and analyze audit records from multiple components within the system. If it does not, this is a finding. Configure the operating system to provide the capability to centrally review and analyze audit records from multiple components within the system. This requirement is a permanent not a finding. No fix is required. medium
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.
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system uses internal system clocks to generate time stamps for audit records. If it does not, this is a finding. Configure the operating system to use internal system clocks to generate time stamps for audit records. This requirement is a permanent not a finding. No fix is required. medium
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system protects audit information from unauthorized read access. If it does not, this is a finding. Configure the operating system to protect audit information from unauthorized read access. This requirement is a permanent not a finding. No fix is required. medium
CCI-000163 SRG-OS-000058-GPOS-00028 TBD - Assigned by DISA after STIG release The operating system must protect audit information from unauthorized modification. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system protects audit information from unauthorized modification. If it does not, this is a finding. Configure the operating system to protect audit information from unauthorized modification. This requirement is a permanent not a finding. No fix is required. medium
CCI-000164 SRG-OS-000059-GPOS-00029 TBD - Assigned by DISA after STIG release The operating system must protect audit information from unauthorized deletion. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system protects audit information from unauthorized deletion. If it does not, this is a finding. Configure the operating system to protect audit information from unauthorized deletion. This requirement is a permanent not a finding. No fix is required. medium
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.
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system allows only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited. If it does not, this is a finding. Configure the operating system to allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-27364-9:Record Events that Modify the System's Discretionary Access Controls - chown 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the chown system call, run the following command: preserve$ sudo grep "chown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=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 medium
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. CCE-27388-8:Record Events that Modify the System's Discretionary Access Controls - fchmodat 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the fchmodat system call, run the following command: preserve$ sudo grep "fchmodat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=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 medium
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. CCE-27353-2:Record Events that Modify the System's Discretionary Access Controls - fremovexattr 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). 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


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


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


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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the fremovexattr system call, run the following command: preserve$ sudo grep "fremovexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. 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 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 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 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 medium
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. CCE-27410-0:Record Events that Modify the System's Discretionary Access Controls - lremovexattr 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). 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


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


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


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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the lremovexattr system call, run the following command: preserve$ sudo grep "lremovexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. 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 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 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 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 medium
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. CCE-27356-5:Record Events that Modify the System's Discretionary Access Controls - fchown 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the fchown system call, run the following command: preserve$ sudo grep "fchown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=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 medium
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. CCE-27393-8:Record Events that Modify the System's Discretionary Access Controls - fchmod 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the fchmod system call, run the following command: preserve$ sudo grep "fchmod" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=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 medium
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. CCE-27387-0:Record Events that Modify the System's Discretionary Access Controls - fchownat 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the fchownat system call, run the following command: preserve$ sudo grep "fchownat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=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 medium
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. CCE-27213-8:Record Events that Modify the System's Discretionary Access Controls - setxattr 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -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
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
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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the setxattr system call, run the following command: preserve$ sudo grep "setxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -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 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 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 medium
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. CCE-27367-2:Record Events that Modify the System's Discretionary Access Controls - removexattr 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). 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


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


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


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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the removexattr system call, run the following command: preserve$ sudo grep "removexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. 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 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 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 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 medium
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. CCE-27339-1:Record Events that Modify the System's Discretionary Access Controls - chmod 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). 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the chmod system call, run the following command: preserve$ sudo grep "chmod" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. 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 medium
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. CCE-27389-6:Record Events that Modify the System's Discretionary Access Controls - fsetxattr 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -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
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
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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the fsetxattr system call, run the following command: preserve$ sudo grep "fsetxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -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 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 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 medium
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. CCE-27280-7:Record Events that Modify the System's Discretionary Access Controls - lsetxattr 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -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
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
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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the lsetxattr system call, run the following command: preserve$ sudo grep "lsetxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -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 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 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 medium
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. CCE-27083-5:Record Events that Modify the System's Discretionary Access Controls - lchown 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the lchown system call, run the following command: preserve$ sudo grep "lchown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=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 medium
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. CCE-80390-8:Record Unsuccessful Access Attempts to Files - ftruncate 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). 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 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 exiu=-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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the ftruncate system call, run the following command: preserve$ sudo grep "ftruncate" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. 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 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 exiu=-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 medium
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. CCE-80387-4:Record Unsuccessful Access Attempts to Files - openat 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). 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 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the openat system call, run the following command: preserve$ sudo grep "openat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. 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 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 medium
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. CCE-80385-8:Record Unsuccessful Access Attempts to Files - creat 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). 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the creat system call, run the following command: preserve$ sudo grep "creat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. 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 medium
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. CCE-80388-2:Record Unsuccessful Access Attempts to Files - open_by_handle_at 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). 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 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the open_by_handle_at system call, run the following command: preserve$ sudo grep "open_by_handle_at" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. 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 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 medium
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. CCE-80389-0:Record Unsuccessful Access Attempts to Files - truncate 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). 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 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the truncate system call, run the following command: preserve$ sudo grep "truncate" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. 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 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 medium
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. CCE-80386-6:Record Unsuccessful Access Attempts to Files - open 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). 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 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the open system call, run the following command: preserve$ sudo grep "open" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. 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 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 medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records when successful/unsuccessful attempts to access privileges occur. If it does not, this is a finding. Configure the operating system to generate audit records when successful/unsuccessful attempts to access privileges occur. This requirement is a permanent not a finding. No fix is required. medium
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system, for PKI-based authentication, validates certificates by constructing a certification path (which includes status information) to an accepted trust anchor. If it does not, this is a finding. Configure the operating system, for PKI-based authentication, to validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor. This requirement is a permanent not a finding. No fix is required. medium
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system, for PKI-based authentication, enforces authorized access to the corresponding private key. If it does not, this is a finding. Configure the operating system, for PKI-based authentication, to enforce authorized access to the corresponding private key. This requirement is a permanent not a finding. No fix is required. medium
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.
CCI-000192 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 upper-case character be used. CCE-27160-1:Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session 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. To configure the number of retry prompts that are permitted per-session: Edit the pam_pwquality.so statement in /etc/pam.d/system-auth to show retry=, or a lower value if site policy is more restrictive. The DoD requirement is a maximum of 3 prompts per session. Applicable - Configurable Verify the operating system enforces password complexity by requiring that at least one upper-case character be used. If it does not, this is a finding. To check how many retry attempts are permitted on a per-session basis, run the following command: $ grep pam_pwquality /etc/pam.d/system-auth The retry parameter will indicate how many attempts are permitted. The DoD required value is less than or equal to 3. This would appear as retry=3, or a lower value. Is it the case that it is not the required value? Configure the operating system to enforce password complexity by requiring that at least one upper-case character be used. To configure the number of retry prompts that are permitted per-session: Edit the pam_pwquality.so statement in /etc/pam.d/system-auth to show retry=, or a lower value if site policy is more restrictive. The DoD requirement is a maximum of 3 prompts per session. medium
CCI-000192 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 upper-case character be used. CCE-27200-5:Ensure PAM Enforces Password Requirements - Minimum Uppercase Characters 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. 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. Applicable - Configurable Verify the operating system enforces password complexity by requiring that at least one upper-case character be used. If it does not, this is a finding. To check how many uppercase characters are required in a password, run the following command: $ grep ucredit /etc/security/pwquality.conf The ucredit parameter (as a negative number) will indicate how many uppercase characters are required. The DoD and FISMA require at least one uppercase character in a password. This would appear as ucredit = -1. Is it the case that ucredit is not found or not set less than or equal to the required value? Configure the operating system to enforce password complexity by requiring that at least one upper-case character be used. 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. medium
CCI-000193 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 lower-case character be used. CCE-27345-8:Ensure PAM Enforces Password Requirements - Minimum Lowercase Characters 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. 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. Applicable - Configurable Verify the operating system enforces password complexity by requiring that at least one lower-case character be used. If it does not, this is a finding. To check how many lowercase characters are required in a password, run the following command: $ grep lcredit /etc/security/pwquality.conf The lcredit parameter (as a negative number) will indicate how many special characters are required. The DoD and FISMA require at least one lowercase character in a password. This would appear as lcredit = -1. Is it the case that lcredit is not found or not less than or equal to the required value? Configure the operating system to enforce password complexity by requiring that at least one lower-case character be used. 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. medium
CCI-000194 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. CCE-27214-6:Ensure PAM Enforces Password Requirements - Minimum Digit Characters 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. 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. Applicable - Configurable Verify the operating system enforces password complexity by requiring that at least one numeric character be used. If it does not, this is a finding. To check how many digits are required in a password, run the following command: $ grep dcredit /etc/security/pwquality.conf The dcredit parameter (as a negative number) will indicate how many digits are required. The DoD requires at least one digit in a password. This would appear as dcredit = -1. Is it the case that dcredit is not found or not equal to or less than the required value? Configure the operating system to enforce password complexity by requiring that at least one numeric character be used. 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. medium
CCI-000195 SRG-OS-000072-GPOS-00040 TBD - Assigned by DISA after STIG release The operating system must require the change of at least 50% of the total number of characters when passwords are changed. CCE-82020-9:Ensure PAM Enforces Password Requirements - Minimum Different Characters 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 8 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.
Applicable - Configurable Verify the operating system requires the change of at least eight of the total number of characters when passwords are changed. If it does not, this is a finding. To check how many characters must differ during a password change, run the following command: $ grep difok /etc/security/pwquality.conf The difok parameter will indicate how many characters must differ. Is it the case that difok is not found or not equal to or greater than the required value? Configure the operating system to require the change of at least eight of the total number of characters when passwords are changed. 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. medium
CCI-000195 SRG-OS-000072-GPOS-00040 TBD - Assigned by DISA after STIG release The operating system must require the change of at least 50% of the total number of characters when passwords are changed. CCE-27512-3:Ensure PAM Enforces Password Requirements - Maximum Consecutive Repeating Characters from Same Character Class 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 8 characters. 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. Applicable - Configurable Verify the operating system requires the change of at least eight of the total number of characters when passwords are changed. If it does not, this is a finding. To check the value for maximum consecutive repeating characters, run the following command: $ grep maxclassrepeat /etc/security/pwquality.conf For DoD systems, the output should show maxclassrepeat=4. Is it the case that that is not the case? Configure the operating system to require the change of at least eight of the total number of characters when passwords are changed. 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. medium
CCI-000195 SRG-OS-000072-GPOS-00040 TBD - Assigned by DISA after STIG release The operating system must require the change of at least 50% of the total number of characters when passwords are changed. CCE-82055-5:Set Password Maximum Consecutive Repeating Characters 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 8 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. Applicable - Configurable Verify the operating system requires the change of at least eight of the total number of characters when passwords are changed. If it does not, this is a finding. To check the maximum value for consecutive repeating characters, run the following command: $ grep maxrepeat /etc/security/pwquality.conf Look for the value of the maxrepeat parameter. The DoD requirement is 3, which would appear as maxrepeat=3. Is it the case that maxrepeat is not found or not greater than or equal to the required value? Configure the operating system to require the change of at least eight of the total number of characters when passwords are changed. 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. medium
CCI-000195 SRG-OS-000072-GPOS-00040 TBD - Assigned by DISA after STIG release The operating system must require the change of at least 50% of the total number of characters when passwords are changed. CCE-82045-6:Ensure PAM Enforces Password Requirements - Minimum Different Categories 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 8 characters. 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.
Applicable - Configurable Verify the operating system requires the change of at least eight of the total number of characters when passwords are changed. If it does not, this is a finding. To check how many categories of characters must be used in password during a password change, run the following command: $ grep minclass /etc/security/pwquality.conf The minclass parameter will indicate how many character classes must be used. If the requirement was for the password to contain characters from three different categories, then this would appear as minclass = 3. Is it the case that minclass is not found or not set equal to or greater than the required value? Configure the operating system to require the change of at least eight of the total number of characters when passwords are changed. 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. medium
CCI-000196 SRG-OS-000073-GPOS-00041 TBD - Assigned by DISA after STIG release The operating system must store only encrypted representations of passwords. CCE-82050-6:Set Password Hashing Algorithm in /etc/login.defs 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. In /etc/login.defs, add or correct the following line to ensure the system will use SHA-512 as the hashing algorithm:
ENCRYPT_METHOD SHA512
Applicable - Configurable Verify the operating system stores only encrypted representations of passwords. If it does not, this is a finding. Inspect /etc/login.defs and ensure the following line appears: ENCRYPT_METHOD SHA512 Is it the case that it does not? Configure the operating system to store only encrypted representations of passwords. In /etc/login.defs, add or correct the following line to ensure the system will use SHA-512 as the hashing algorithm: ENCRYPT_METHOD SHA512 medium
CCI-000196 SRG-OS-000073-GPOS-00041 TBD - Assigned by DISA after STIG release The operating system must store only encrypted representations of passwords. CCE-82038-1:Set Password Hashing Algorithm in /etc/libuser.conf 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. In /etc/libuser.conf, add or correct the following line in its [defaults] section to ensure the system will use the SHA-512 algorithm for password hashing:
crypt_style = sha512
Applicable - Configurable Verify the operating system stores only encrypted representations of passwords. If it does not, this is a finding. Inspect /etc/libuser.conf and ensure the following line appears in the [default] section: crypt_style = sha512 Is it the case that it does not? Configure the operating system to store only encrypted representations of passwords. In /etc/libuser.conf, add or correct the following line in its [defaults] section to ensure the system will use the SHA-512 algorithm for password hashing: crypt_style = sha512 medium
CCI-000196 SRG-OS-000073-GPOS-00041 TBD - Assigned by DISA after STIG release The operating system must store only encrypted representations of passwords. CCE-82043-1:Set PAM's Password Hashing Algorithm 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. The PAM system service can be configured to only store encrypted representations of passwords. In /etc/pam.d/system-auth, the password section of the file controls which PAM modules execute during a password change. Set the pam_unix.so module in the password section to include the argument sha512, as shown below:
password    sufficient    pam_unix.so sha512 other arguments...

This will help ensure when local users change their passwords, hashes for the new passwords will be generated using the SHA-512 algorithm. This is the default.
Applicable - Configurable Verify the operating system stores only encrypted representations of passwords. If it does not, this is a finding. Inspect the password section of /etc/pam.d/system-auth and ensure that the pam_unix.so module includes the argument sha512: $ grep sha512 /etc/pam.d/system-auth Is it the case that it does not? Configure the operating system to store only encrypted representations of passwords. The PAM system service can be configured to only store encrypted representations of passwords. In /etc/pam.d/system-auth, the password section of the file controls which PAM modules execute during a password change. Set the pam_unix.so module in the password section to include the argument sha512, as shown below: password sufficient pam_unix.so sha512 other arguments... This will help ensure when local users change their passwords, hashes for the new passwords will be generated using the SHA-512 algorithm. This is the default. medium
CCI-000197 SRG-OS-000074-GPOS-00042 TBD - Assigned by DISA after STIG release The operating system must transmit only encrypted representations of passwords. CCE-27320-1:Allow Only SSH Protocol 2 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. Only SSH protocol version 2 connections should be permitted. The default setting in /etc/ssh/sshd_config is correct, and can be verified by ensuring that the following line appears:
Protocol 2
Applicable - Configurable Verify the operating system transmits only encrypted representations of passwords. If it does not, this is a finding. To check which SSH protocol version is allowed, check version of openssh-server with following command: $ rpm -qi openssh-server | grep Version Versions equal to or higher than 7.4 only allow Protocol 2. If version is lower than 7.4, run the following command to check configuration: $ sudo grep Protocol /etc/ssh/sshd_config If configured properly, output should be Protocol 2 Is it the case that it is commented out or is not set correctly to Protocol 2? Configure the operating system to transmit only encrypted representations of passwords. Only SSH protocol version 2 connections should be permitted. The default setting in /etc/ssh/sshd_config is correct, and can be verified by ensuring that the following line appears: Protocol 2 high
CCI-000198 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. CCE-82036-5:Set Password Minimum Age 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. 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 .
Applicable - Configurable Verify operating system enforces 24 hours/1 day as the minimum password lifetime. If it does not, this is a finding. To check the minimum password age, run the command: $ grep PASS_MIN_DAYS /etc/login.defs Is it the case that it is not equal to or greater than the required value? Configure operating system to enforce 24 hours/1 day as the minimum password lifetime. 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 . medium
CCI-000198 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. CCE-80521-8:Set Existing Passwords Minimum Age 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. Configure non-compliant accounts to enforce a 24 hours/1 day minimum password lifetime by running the following command:
$ sudo chage -m 1 USER
Applicable - Configurable Verify operating system enforces 24 hours/1 day as the minimum password lifetime. If it does not, this is a finding. Check whether the minimum time period between password changes for each user account is one day or greater by running the following command for each user: $ sudo chage -l USER | grep Minimum The output for each user should return something similary to the following: Minimum number of days between password change\t\t: 1 Is it the case that existing passwords are not configured correctly? Configure operating system to enforce 24 hours/1 day as the minimum password lifetime. Configure non-compliant accounts to enforce a 24 hours/1 day minimum password lifetime by running the following command: $ sudo chage -m 1 USER medium
CCI-000199 SRG-OS-000076-GPOS-00044 TBD - Assigned by DISA after STIG release Operating systems must enforce a 60-day maximum password lifetime restriction. CCE-27051-2:Set Password Maximum Age 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. 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 .
Applicable - Configurable Verify operating system enforces a 60-day maximum password lifetime restriction. If it does not, this is a finding. To check the maximum password age, run the command: $ grep PASS_MAX_DAYS /etc/login.defs The DoD and FISMA requirement is 60. A value of 180 days is sufficient for many environments. Is it the case that PASS_MAX_DAYS is not set equal to or greater than the required value? Configure operating system to enforce a 60-day maximum password lifetime restriction. 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 . medium
CCI-000199 SRG-OS-000076-GPOS-00044 TBD - Assigned by DISA after STIG release Operating systems must enforce a 60-day maximum password lifetime restriction. CCE-80522-6:Set Existing Passwords Maximum Age 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. Configure non-compliant accounts to enforce a 60-day maximum password lifetime restriction by running the following command:
$ sudo chage -M 60 USER
Applicable - Configurable Verify operating system enforces a 60-day maximum password lifetime restriction. If it does not, this is a finding. Check whether the maximum time period for existing passwords is restricted to 60 days by running the following command for each user: $ sudo chage -l USER | grep Maximum The output for each user should return something similary to the following: Maximum number of days between password change\t\t: 60 Is it the case that existing passwords are not configured correctly? Configure operating system to enforce a 60-day maximum password lifetime restriction. Configure non-compliant accounts to enforce a 60-day maximum password lifetime restriction by running the following command: $ sudo chage -M 60 USER medium
CCI-000200 SRG-OS-000077-GPOS-00045 TBD - Assigned by DISA after STIG release The operating system must prohibit password reuse for a minimum of five generations. CCE-82030-8:Limit Password Reuse Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. Do not allow users to reuse recent passwords. This can be accomplished by using the remember option for the pam_unix or pam_pwhistory PAM modules.

In the file /etc/pam.d/system-auth, append remember= to the line which refers to the pam_unix.so or pam_pwhistory.somodule, as shown below:
  • for the pam_unix.so case:
    password sufficient pam_unix.so ...existing_options... remember=
  • for the pam_pwhistory.so case:
    password requisite pam_pwhistory.so ...existing_options... remember=
The DoD STIG requirement is 5 passwords.
Applicable - Configurable Verify the operating system prohibits password reuse for a minimum of five generations. If it does not, this is a finding. To verify the password reuse setting is compliant, run the following command: $ grep remember /etc/pam.d/system-auth The output should show the following at the end of the line: remember= Is it the case that the value of remember is not set equal to or greater than the expected setting? Configure the operating system to prohibit password reuse for a minimum of five generations. Do not allow users to reuse recent passwords. This can be accomplished by using the remember option for the pam_unix or pam_pwhistory PAM modules. In the file /etc/pam.d/system-auth, append remember= to the line which refers to the pam_unix.so or pam_pwhistory.somodule, as shown below: for the pam_unix.so case: password sufficient pam_unix.so ...existing_options... remember= for the pam_pwhistory.so case: password requisite pam_pwhistory.so ...existing_options... remember= The DoD STIG requirement is 5 passwords. medium
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. CCE-80390-8:Record Unsuccessful Access Attempts to Files - ftruncate 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). 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 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 exiu=-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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the ftruncate system call, run the following command: preserve$ sudo grep "ftruncate" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. 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 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 exiu=-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 medium
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. CCE-80387-4:Record Unsuccessful Access Attempts to Files - openat 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). 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 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the openat system call, run the following command: preserve$ sudo grep "openat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. 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 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 medium
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. CCE-80385-8:Record Unsuccessful Access Attempts to Files - creat 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). 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the creat system call, run the following command: preserve$ sudo grep "creat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. 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 medium
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. CCE-80388-2:Record Unsuccessful Access Attempts to Files - open_by_handle_at 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). 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 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the open_by_handle_at system call, run the following command: preserve$ sudo grep "open_by_handle_at" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. 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 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 medium
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. CCE-80389-0:Record Unsuccessful Access Attempts to Files - truncate 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). 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 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the truncate system call, run the following command: preserve$ sudo grep "truncate" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. 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 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 medium
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. CCE-80386-6:Record Unsuccessful Access Attempts to Files - open 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). 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 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the open system call, run the following command: preserve$ sudo grep "open" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. 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 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 medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. If it does not, this is a finding. Configure the operating system to generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-27364-9:Record Events that Modify the System's Discretionary Access Controls - chown 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the chown system call, run the following command: preserve$ sudo grep "chown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=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 medium
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. CCE-27388-8:Record Events that Modify the System's Discretionary Access Controls - fchmodat 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the fchmodat system call, run the following command: preserve$ sudo grep "fchmodat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=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 medium
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. CCE-27353-2:Record Events that Modify the System's Discretionary Access Controls - fremovexattr 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). 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


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


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


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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the fremovexattr system call, run the following command: preserve$ sudo grep "fremovexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. 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 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 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 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 medium
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. CCE-27410-0:Record Events that Modify the System's Discretionary Access Controls - lremovexattr 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). 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


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


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


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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the lremovexattr system call, run the following command: preserve$ sudo grep "lremovexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. 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 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 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 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 medium
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. CCE-27356-5:Record Events that Modify the System's Discretionary Access Controls - fchown 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the fchown system call, run the following command: preserve$ sudo grep "fchown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=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 medium
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. CCE-27393-8:Record Events that Modify the System's Discretionary Access Controls - fchmod 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the fchmod system call, run the following command: preserve$ sudo grep "fchmod" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=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 medium
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. CCE-27387-0:Record Events that Modify the System's Discretionary Access Controls - fchownat 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the fchownat system call, run the following command: preserve$ sudo grep "fchownat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=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 medium
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. CCE-27213-8:Record Events that Modify the System's Discretionary Access Controls - setxattr 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -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
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
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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the setxattr system call, run the following command: preserve$ sudo grep "setxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -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 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 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 medium
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. CCE-27367-2:Record Events that Modify the System's Discretionary Access Controls - removexattr 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). 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


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


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


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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the removexattr system call, run the following command: preserve$ sudo grep "removexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. 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 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 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 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 medium
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. CCE-27339-1:Record Events that Modify the System's Discretionary Access Controls - chmod 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). 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the chmod system call, run the following command: preserve$ sudo grep "chmod" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. 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 medium
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. CCE-27389-6:Record Events that Modify the System's Discretionary Access Controls - fsetxattr 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -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
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
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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the fsetxattr system call, run the following command: preserve$ sudo grep "fsetxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -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 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 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 medium
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. CCE-27280-7:Record Events that Modify the System's Discretionary Access Controls - lsetxattr 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -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
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
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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the lsetxattr system call, run the following command: preserve$ sudo grep "lsetxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -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 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 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 medium
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. CCE-27083-5:Record Events that Modify the System's Discretionary Access Controls - lchown 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). At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the lchown system call, run the following command: preserve$ sudo grep "lchown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=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 medium
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. CCE-80390-8:Record Unsuccessful Access Attempts to Files - ftruncate 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). 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 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 exiu=-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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the ftruncate system call, run the following command: preserve$ sudo grep "ftruncate" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. 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 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 exiu=-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 medium
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. CCE-80387-4:Record Unsuccessful Access Attempts to Files - openat 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). 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 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the openat system call, run the following command: preserve$ sudo grep "openat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. 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 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 medium
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. CCE-80385-8:Record Unsuccessful Access Attempts to Files - creat 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). 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the creat system call, run the following command: preserve$ sudo grep "creat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. 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 medium
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. CCE-80388-2:Record Unsuccessful Access Attempts to Files - open_by_handle_at 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). 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 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the open_by_handle_at system call, run the following command: preserve$ sudo grep "open_by_handle_at" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. 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 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 medium
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. CCE-80389-0:Record Unsuccessful Access Attempts to Files - truncate 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). 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 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the truncate system call, run the following command: preserve$ sudo grep "truncate" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. 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 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 medium
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. CCE-80386-6:Record Unsuccessful Access Attempts to Files - open 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). 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 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
Applicable - Configurable Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. To determine if the system is configured to audit calls to the open system call, run the following command: preserve$ sudo grep "open" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. 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 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 medium
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. Product Meets this Requirement 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). This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system generates audit records when successful/unsuccessful attempts to access security objects occur. If it does not, this is a finding. Configure the operating system to generate audit records when successful/unsuccessful attempts to access security objects occur. This requirement is a permanent not a finding. No fix is required. medium
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.
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. CCE-26952-2:Configure Periodic Execution of AIDE 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. At a minimum, AIDE should be configured to run a weekly scan. To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab:
05 4 * * * root /usr/sbin/aide --check
To implement a weekly execution of AIDE at 4:05am using cron, add the following line to /etc/crontab:
05 4 * * 0 root /usr/sbin/aide --check
AIDE can be executed periodically through other means; this is merely one example. The usage of cron's special time codes, such as @daily and @weekly is acceptable.
Applicable - Configurable Verify the operating system performs 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. If it does not, this is a finding. To determine that periodic AIDE execution has been scheduled, run the following command: $ grep aide /etc/crontab The output should return something similar to the following: 05 4 * * * root /usr/sbin/aide --check NOTE: The usage of special cron times, such as @daily or @weekly, is acceptable. Is it the case that there is no output? Configure the operating system to 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. At a minimum, AIDE should be configured to run a weekly scan. To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab: 05 4 * * * root /usr/sbin/aide --check To implement a weekly execution of AIDE at 4:05am using cron, add the following line to /etc/crontab: 05 4 * * 0 root /usr/sbin/aide --check AIDE can be executed periodically through other means; this is merely one example. The usage of cron's special time codes, such as @daily and @weekly is acceptable. medium
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. CCE-27334-2:Ensure SELinux State is Enforcing 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. 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=
Applicable - Configurable Verify the operating system verifies correct operation of all security functions. If it does not, this is a finding. Check the file /etc/selinux/config and ensure the following line appears: SELINUX= Is it the case that SELINUX is not set to enforcing? Configure the operating system to verify correct operation of all security functions. 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= high
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. CCE-27279-9:Configure SELinux Policy 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. 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.
Applicable - Configurable Verify the operating system verifies correct operation of all security functions. If it does not, this is a finding. Check the file /etc/selinux/config and ensure the following line appears: SELINUXTYPE= Is it the case that it does not? Configure the operating system to verify correct operation of all security functions. 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. high
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. CCE-80346-0:Ensure yum Removes Previous Package Versions 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. 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. Applicable - Configurable Verify the operating system removes all software components after updated versions have been installed. If it does not, this is a finding. To verify that clean_requirements_on_remove is configured properly, run the following command: $ grep clean_requirements_on_remove /etc/yum.conf The output should return something similar to: clean_requirements_on_remove=1 Is it the case that clean_requirements_on_remove is not enabled or configured correctly? Configure the operating system to remove all software components after updated versions have been installed. 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. low
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. CCE-27127-0:Enable Randomized Layout of Virtual Address Space 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. 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
Applicable - Configurable Verify the operating system implements address space layout randomization to protect its memory from unauthorized code execution. If it does not, this is a finding. The runtime status of the kernel.randomize_va_space kernel parameter can be queried by running the following command: $ sysctl kernel.randomize_va_space The output of the command should indicate a value of 2. The preferable way how to assure the runtime compliance is to have correct persistent configuration, and rebooting the system. The persistent kernel parameter configuration is performed by specifying the appropriate assignment in any file located in the /etc/sysctl.d directory. Verify that there is not any existing incorrect configuration by executing the following command: $ grep -r '^\s*kernel.randomize_va_space\s*=' /etc/sysctl.conf /etc/sysctl.d If any assignments other than kernel.randomize_va_space = 2 are found, or the correct assignment is duplicated, remove those offending lines from respective files, and make sure that exactly one file in /etc/sysctl.d contains kernel.randomize_va_space = 2, and that one assignment is returned when $ grep -r kernel.randomize_va_space /etc/sysctl.conf /etc/sysctl.d is executed. Is it the case that the correct value is not returned? Configure the operating system to implement address space layout randomization to protect its memory from unauthorized code execution. 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 medium
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.
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-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. CCE-80215-7:Install the OpenSSH Server Package 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. The openssh-server package should be installed. The openssh-server package can be installed with the following command:
$ sudo yum install openssh-server
Applicable - Configurable Verify the operating system maintains the confidentiality and integrity of information during reception. If it does not, this is a finding. Run the following command to determine if the openssh-server package is installed: $ rpm -q openssh-server Is it the case that the package is not installed? Configure the operating system to maintain the confidentiality and integrity of information during reception. The openssh-server package should be installed. The openssh-server package can be installed with the following command: $ sudo yum install openssh-server medium
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. CCE-80215-7:Install the OpenSSH Server Package 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. The openssh-server package should be installed. The openssh-server package can be installed with the following command:
$ sudo yum install openssh-server
Applicable - Configurable Verify the operating system maintains the confidentiality and integrity of information during preparation for transmission. If it does not, this is a finding. Run the following command to determine if the openssh-server package is installed: $ rpm -q openssh-server Is it the case that the package is not installed? Configure the operating system to maintain the confidentiality and integrity of information during preparation for transmission. The openssh-server package should be installed. The openssh-server package can be installed with the following command: $ sudo yum install openssh-server medium
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). CCE-27358-1:Deactivate Wireless Network Interfaces 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. 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 wifi off
Applicable - Configurable Verify the operating system implements 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). If it does not, this is a finding. Verify that there are no wireless interfaces configured on the system with the following command: $ sudo nmcli device The output should contain the following: wifi disconnected Is it the case that it is not? Configure the operating system to 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). 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 wifi off medium
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). CCE-80215-7:Install the OpenSSH Server Package 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. The openssh-server package should be installed. The openssh-server package can be installed with the following command:
$ sudo yum install openssh-server
Applicable - Configurable Verify the operating system implements 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). If it does not, this is a finding. Run the following command to determine if the openssh-server package is installed: $ rpm -q openssh-server Is it the case that the package is not installed? Configure the operating system to 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). The openssh-server package should be installed. The openssh-server package can be installed with the following command: $ sudo yum install openssh-server medium
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. CCE-80215-7:Install the OpenSSH Server Package 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. The openssh-server package should be installed. The openssh-server package can be installed with the following command:
$ sudo yum install openssh-server
Applicable - Configurable Verify the operating system protects the confidentiality and integrity of transmitted information. If it does not, this is a finding. Run the following command to determine if the openssh-server package is installed: $ rpm -q openssh-server Is it the case that the package is not installed? Configure the operating system to protect the confidentiality and integrity of transmitted information. The openssh-server package should be installed. The openssh-server package can be installed with the following command: $ sudo yum install openssh-server medium
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. CCE-80216-5:Enable the OpenSSH Service 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. The SSH server service, sshd, is commonly needed. The sshd service can be enabled with the following command:
$ sudo systemctl enable sshd.service
Applicable - Configurable Verify the operating system protects the confidentiality and integrity of transmitted information. If it does not, this is a finding. Run the following command to determine the current status of the sshd service: $ systemctl is-active sshd If the service is running, it should return the following: active Is it the case that ? Configure the operating system to protect the confidentiality and integrity of transmitted information. The SSH server service, sshd, is commonly needed. The sshd service can be enabled with the following command: $ sudo systemctl enable sshd.service medium
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. CCE-80542-4:Configure firewalld To Rate Limit Connections 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. Create a direct firewall rule to protect against DoS attacks with the following command:
$ sudo firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT_direct 0 -p tcp -m limit --limit 25/minute --limit-burst 100  -j INPUT_ZONES
Applicable - Configurable Verify the operating system protects against or limits the effects of Denial of Service (DoS) attacks by ensuring the operating system is implementing rate-limiting measures on impacted network interfaces. If it does not, this is a finding. To verify the operating system protects against or limits the effects of DoS attacks by ensuring the operating system is implementing rate-limiting measures on impacted network interfaces, run the following command: $ sudo firewall-cmd --permanent --direct --get-rules ipv4 filter INPUT_direct The output should return: 0 -p tcp -m limit --limit 25/minute --limit-burst 100 -j INPUT_ZONES Is it the case that firewalld is not rate limiting connections? Configure the operating system to 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. Create a direct firewall rule to protect against DoS attacks with the following command: $ sudo firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT_direct 0 -p tcp -m limit --limit 25/minute --limit-burst 100 -j INPUT_ZONES medium
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. CCE-80359-3:Enable FIPS Mode in GRUB2 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). To ensure FIPS mode is enabled, install package dracut-fips, and rebuild initramfs by running the following commands:
$ sudo yum install dracut-fips
dracut -f
After the dracut command has been run, add the argument fips=1 to the default GRUB 2 command line for the Linux operating system in /etc/default/grub, in the manner below:
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 fips=1"
Finally, rebuild the grub.cfg file by using the
grub2-mkconfig -o
command as follows:
  • On BIOS-based machines, issue the following command as root:
    ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
  • On UEFI-based machines, issue the following command as root:
    ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
Applicable - Configurable Verify the operating system implements cryptographic mechanisms to prevent unauthorized disclosure of all information at rest on all operating system components. If it does not, this is a finding. To verify that FIPS is enabled properly in grub, run the following command: $ grep fips /etc/default/grub The output should contain fips=1 Is it the case that FIPS is not configured or enabled in grub? Configure the operating system to implement cryptographic mechanisms to prevent unauthorized disclosure of all information at rest on all operating system components. To ensure FIPS mode is enabled, install package dracut-fips, and rebuild initramfs by running the following commands: $ sudo yum install dracut-fips dracut -f After the dracut command has been run, add the argument fips=1 to the default GRUB 2 command line for the Linux operating system in /etc/default/grub, in the manner below: GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 fips=1" Finally, rebuild the grub.cfg file by using the grub2-mkconfig -o command as follows: On BIOS-based machines, issue the following command as root: ~]# grub2-mkconfig -o /boot/grub2/grub.cfgOn UEFI-based machines, issue the following command as root: ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg high
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).
CCI-000205 SRG-OS-000078-GPOS-00046 TBD - Assigned by DISA after STIG release The operating system must enforce a minimum 15-character password length. CCE-27293-0:Ensure PAM Enforces Password Requirements - Minimum 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. 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. Applicable - Configurable Verify the operating system enforces a minimum 15-character password length. If it does not, this is a finding. To check how many characters are required in a password, run the following command: $ grep minlen /etc/security/pwquality.conf Your output should contain minlen = Is it the case that minlen is not found, or not equal to or greater than the required value? Configure the operating system to enforce a minimum 15-character password 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. medium
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system obscures feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. If it does not, this is a finding. Configure the operating system to obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-27287-2:Require Authentication for Single User Mode 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. Single-user mode is intended as a system recovery method, providing a single user root access to the system by providing a boot option at startup. By default, no authentication is performed if single-user mode is selected.

By default, single-user mode is protected by requiring a password and is set in /usr/lib/systemd/system/rescue.service.
Applicable - Configurable Verify the operating system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. If it does not, this is a finding. To check if authentication is required for single-user mode, run the following command: $ grep sulogin /usr/lib/systemd/system/rescue.service The output should be similar to the following, and the line must begin with ExecStart and /sbin/sulogin. ExecStart=-/bin/sh -c "/sbin/sulogin; /usr/bin/systemctl --fail --no-block default" Is it the case that the output is different? Configure the operating system to enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. Single-user mode is intended as a system recovery method, providing a single user root access to the system by providing a boot option at startup. By default, no authentication is performed if single-user mode is selected. By default, single-user mode is protected by requiring a password and is set in /usr/lib/systemd/system/rescue.service. medium
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. CCE-27309-4:Set Boot Loader Password in grub2 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. 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 pasword by running the following command:
$ grub2-setpassword
When prompted, enter the password that was selected.

Once the superuser password has been added, update the grub.cfg file by running:
grub2-mkconfig -o /boot/grub2/grub.cfg
Applicable - Configurable Verify the operating system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. If it does not, this is a finding. To verify the boot loader superuser password has been set, run the following command: sudo grep "superusers" /etc/grub2.cfg The output should show the following: password_pbkdf2 superusers-account ${GRUB2_PASSWORD} To verify the boot loader superuser account password has been set, and the password encrypted, run the following command: sudo cat /boot/grub2/user.cfg The output should be similar to: GRUB2_PASSWORD=grub.pbkdf2.sha512.10000.C4E08AC72FBFF7E837FD267BFAD7AEB3D42DDC 2C99F2A94DD5E2E75C2DC331B719FE55D9411745F82D1B6CFD9E927D61925F9BBDD1CFAA0080E0 916F7AB46E0D.1302284FCCC52CD73BA3671C6C12C26FF50BA873293B24EE2A96EE3B57963E6D7 0C83964B473EC8F93B07FE749AA6710269E904A9B08A6BBACB00A2D242AD828 Is it the case that it does not? Configure the operating system to enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. 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 pasword by running the following command: $ grub2-setpassword When prompted, enter the password that was selected. Once the superuser password has been added, update the grub.cfg file by running: grub2-mkconfig -o /boot/grub2/grub.cfg high
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. CCE-80354-4:Set the UEFI Boot Loader Password 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. 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 pasword by running the following command:
$ grub2-setpassword
When prompted, enter the password that was selected.

Once the superuser password has been added, update the grub.cfg file by running:
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
Applicable - Configurable Verify the operating system enforces approved authorizations for logical access to information and system resources in accordance with applicable access control policies. If it does not, this is a finding. To verify the boot loader superuser password has been set, run the following command: sudo grep "password" /etc/grub2-efi.cfg The output should show the following: password_pbkdf2 superusers-account ${GRUB2_PASSWORD} To verify the boot loader superuser account password has been set, and the password encrypted, run the following command: sudo cat /boot/efi/EFI/redhat/user.cfg The output should be similar to: GRUB2_PASSWORD=grub.pbkdf2.sha512.10000.C4E08AC72FBFF7E837FD267BFAD7AEB3D42DDC 2C99F2A94DD5E2E75C2DC331B719FE55D9411745F82D1B6CFD9E927D61925F9BBDD1CFAA0080E0 916F7AB46E0D.1302284FCCC52CD73BA3671C6C12C26FF50BA873293B24EE2A96EE3B57963E6D7 0C83964B473EC8F93B07FE749AA6710269E904A9B08A6BBACB00A2D242AD828 Is it the case that it does not? Configure the operating system to enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies. 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 pasword by running the following command: $ grub2-setpassword When prompted, enter the password that was selected. Once the superuser password has been added, update the grub.cfg file by running: grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg medium
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. CCE-27165-0:Uninstall telnet-server Package 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. The telnet-server package can be removed with the following command:
$ sudo yum erase telnet-server
Applicable - Configurable Verify the operating system is configured to disable non-essential capabilities. If it does not, this is a finding. Run the following command to determine if the telnet-server package is installed: $ rpm -q telnet-server Is it the case that the package is installed? Configure the operating system to disable non-essential capabilities. The telnet-server package can be removed with the following command: $ sudo yum erase telnet-server high
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. CCE-27342-5:Uninstall rsh-server Package 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. The rsh-server package can be removed with the following command:
$ sudo yum erase rsh-server
Applicable - Configurable Verify the operating system is configured to disable non-essential capabilities. If it does not, this is a finding. Run the following command to determine if the rsh-server package is installed: $ rpm -q rsh-server Is it the case that the package is installed? Configure the operating system to disable non-essential capabilities. The rsh-server package can be removed with the following command: $ sudo yum erase rsh-server high
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. CCE-27399-5:Uninstall ypserv Package 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. The ypserv package can be removed with the following command:
$ sudo yum erase ypserv
Applicable - Configurable Verify the operating system is configured to disable non-essential capabilities. If it does not, this is a finding. Run the following command to determine if the ypserv package is installed: $ rpm -q ypserv Is it the case that the package is installed? Configure the operating system to disable non-essential capabilities. The ypserv package can be removed with the following command: $ sudo yum erase ypserv high
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. CCE-80447-6:Configure the Firewalld Ports 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 to allow approved services to have access to the system. To configure firewalld to open ports, run the following command:
$ sudo firewall-cmd --permanent --add-port=port_number/tcp
or
$ sudo firewall-cmd --permanent --add-port=service_name
Run the command list above for each of the ports listed below: To configure firewalld to allow access, run the following command(s): firewall-cmd --permanent --add-service=ssh
Applicable - Configurable Verify the operating system is configured to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments. If it does not, this is a finding. Inspect the list of enabled firewall ports and verify they are configured correctly by running the following command: $ sudo firewall-cmd --list-all Is it the case that the default rules are not configured? Configure the operating system to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments. Configure the firewalld ports to allow approved services to have access to the system. To configure firewalld to open ports, run the following command: $ sudo firewall-cmd --permanent --add-port=port_number/tcp or $ sudo firewall-cmd --permanent --add-port=service_name Run the command list above for each of the ports listed below: To configure firewalld to allow access, run the following command(s): firewall-cmd --permanent --add-service=ssh medium
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. CCE-82024-1:Disable DCCP Support 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. The Datagram Congestion Control Protocol (DCCP) is a relatively new transport layer protocol, designed to support streaming media and telephony. To configure the system to prevent the dccp kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d:
install dccp /bin/true
Applicable - Configurable Verify the operating system is configured to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments. If it does not, this is a finding. If the system is configured to prevent the loading of the dccp kernel module, it will contain lines inside any file in /etc/modprobe.d or the deprecated/etc/modprobe.conf. These lines instruct the module loading system to run another program (such as /bin/true) upon a module install event. Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf: $ grep -r dccp /etc/modprobe.conf /etc/modprobe.d Is it the case that no line is returned? Configure the operating system to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments. The Datagram Congestion Control Protocol (DCCP) is a relatively new transport layer protocol, designed to support streaming media and telephony. To configure the system to prevent the dccp kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d: install dccp /bin/true medium
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). CCE-27503-2:All GIDs referenced in /etc/passwd must be defined in /etc/group 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. Add a group to the system for each GID referenced without a corresponding group. Applicable - Configurable Verify the operating system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users). If it does not, this is a finding. To ensure all GIDs referenced in /etc/passwd are defined in /etc/group, run the following command: $ sudo pwck -qr There should be no output. Is it the case that GIFs referenced in /etc/passwd are returned as not defined in /etc/group? Configure the operating system to uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users). Add a group to the system for each GID referenced without a corresponding group. low
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). CCE-80207-4:Enable Smart Card Login 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. To enable smart card authentication, consult the documentation at: For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at: Applicable - Configurable Verify the operating system uniquely identifies and authenticates organizational users (or processes acting on behalf of organizational users). If it does not, this is a finding. Interview the SA to determine if all accounts not exempted by policy are using CAC authentication. For DoD systems, the following systems and accounts are exempt from using smart card (CAC) authentication: SIPRNET systemsStandalone systemsApplication accountsTemporary employee accounts, such as students or interns, who cannot easily receive a CAC or PIVOperational tactical locations that are not collocated with RAPIDS workstations to issue CAC or ALTTest systems, such as those with an Interim Approval to Test (IATT) and use a separate VPN, firewall, or security measure preventing access to network and system components from outside the protection boundary documented in the IATT. Is it the case that non-exempt accounts are not using CAC authentication? Configure the operating system to uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users). To enable smart card authentication, consult the documentation at: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/smartcards.html#authconfig-smartcards For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at: https://access.redhat.com/solutions/82273 medium
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. CCE-80519-2:Install Smart Card Packages For Multifactor Authentication 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. Configure the operating system to implement multifactor authentication by installing the required packages with the following command: The esc pam_pkcs11 package can be installed with the following command:
$ sudo yum install esc pam_pkcs11
Applicable - Configurable Verify the operating system uses multifactor authentication for network access to privileged accounts. If it does not, this is a finding. To verify the operating system has the packages required for multifactor authentication installed, run the following command: $ sudo yum list installed esc pam_pkcs11 Is it the case that smartcard software is not installed? Configure the operating system to use multifactor authentication for network access to privileged accounts. Configure the operating system to implement multifactor authentication by installing the required packages with the following command: The esc pam_pkcs11 package can be installed with the following command: $ sudo yum install esc pam_pkcs11 medium
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. CCE-80207-4:Enable Smart Card Login 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. To enable smart card authentication, consult the documentation at: For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at: Applicable - Configurable Verify the operating system uses multifactor authentication for network access to non-privileged accounts. If it does not, this is a finding. Interview the SA to determine if all accounts not exempted by policy are using CAC authentication. For DoD systems, the following systems and accounts are exempt from using smart card (CAC) authentication: SIPRNET systemsStandalone systemsApplication accountsTemporary employee accounts, such as students or interns, who cannot easily receive a CAC or PIVOperational tactical locations that are not collocated with RAPIDS workstations to issue CAC or ALTTest systems, such as those with an Interim Approval to Test (IATT) and use a separate VPN, firewall, or security measure preventing access to network and system components from outside the protection boundary documented in the IATT. Is it the case that non-exempt accounts are not using CAC authentication? Configure the operating system to use multifactor authentication for network access to non-privileged accounts. To enable smart card authentication, consult the documentation at: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/smartcards.html#authconfig-smartcards For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at: https://access.redhat.com/solutions/82273 medium
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. CCE-27471-2:Disable SSH Access via Empty Passwords 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. 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.
Applicable - Configurable Verify the operating system uses multifactor authentication for network access to non-privileged accounts. If it does not, this is a finding. To determine how the SSH daemon's PermitEmptyPasswords option is set, run the following command: $ sudo grep -i PermitEmptyPasswords /etc/ssh/sshd_config If no line, a commented line, or a line indicating the value no is returned, then the required value is set. Is it the case that the required value is not set? Configure the operating system to use multifactor authentication for network access to non-privileged accounts. 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. high
CCI-000767 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. CCE-80207-4:Enable Smart Card Login To assure 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. To enable smart card authentication, consult the documentation at: For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at: Applicable - Configurable Verify the operating system uses multifactor authentication for local access to privileged accounts. If it does not, this is a finding. Interview the SA to determine if all accounts not exempted by policy are using CAC authentication. For DoD systems, the following systems and accounts are exempt from using smart card (CAC) authentication: SIPRNET systemsStandalone systemsApplication accountsTemporary employee accounts, such as students or interns, who cannot easily receive a CAC or PIVOperational tactical locations that are not collocated with RAPIDS workstations to issue CAC or ALTTest systems, such as those with an Interim Approval to Test (IATT) and use a separate VPN, firewall, or security measure preventing access to network and system components from outside the protection boundary documented in the IATT. Is it the case that non-exempt accounts are not using CAC authentication? Configure the operating system to use multifactor authentication for local access to privileged accounts. To enable smart card authentication, consult the documentation at: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/smartcards.html#authconfig-smartcards For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at: https://access.redhat.com/solutions/82273 medium
CCI-000768 SRG-OS-000108-GPOS-00055 TBD - Assigned by DISA after STIG release The operating system must use multifactor authentication for local access to non-privileged accounts. CCE-80207-4:Enable Smart Card Login To assure accountability, prevent unauthenticated access, and prevent misuse of the system, non-privileged 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 non-privileged account is defined as an operating system account with authorizations of a regular or non-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. To enable smart card authentication, consult the documentation at: For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at: Applicable - Configurable Verify the operating system uses multifactor authentication for local access to non-privileged accounts. If it does not, this is a finding. Interview the SA to determine if all accounts not exempted by policy are using CAC authentication. For DoD systems, the following systems and accounts are exempt from using smart card (CAC) authentication: SIPRNET systemsStandalone systemsApplication accountsTemporary employee accounts, such as students or interns, who cannot easily receive a CAC or PIVOperational tactical locations that are not collocated with RAPIDS workstations to issue CAC or ALTTest systems, such as those with an Interim Approval to Test (IATT) and use a separate VPN, firewall, or security measure preventing access to network and system components from outside the protection boundary documented in the IATT. Is it the case that non-exempt accounts are not using CAC authentication? Configure the operating system to use multifactor authentication for local access to non-privileged accounts. To enable smart card authentication, consult the documentation at: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/smartcards.html#authconfig-smartcards For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at: https://access.redhat.com/solutions/82273 medium
CCI-000770 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. CCE-80207-4:Enable Smart Card Login To assure 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. To enable smart card authentication, consult the documentation at: For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at: Applicable - Configurable Verify the operating system requires individuals to be authenticated with an individual authenticator prior to using a group authenticator. If it does not, this is a finding. Interview the SA to determine if all accounts not exempted by policy are using CAC authentication. For DoD systems, the following systems and accounts are exempt from using smart card (CAC) authentication: SIPRNET systemsStandalone systemsApplication accountsTemporary employee accounts, such as students or interns, who cannot easily receive a CAC or PIVOperational tactical locations that are not collocated with RAPIDS workstations to issue CAC or ALTTest systems, such as those with an Interim Approval to Test (IATT) and use a separate VPN, firewall, or security measure preventing access to network and system components from outside the protection boundary documented in the IATT. Is it the case that non-exempt accounts are not using CAC authentication? Configure the operating system to require individuals to be authenticated with an individual authenticator prior to using a group authenticator. To enable smart card authentication, consult the documentation at: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/smartcards.html#authconfig-smartcards For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at: https://access.redhat.com/solutions/82273 medium
CCI-000770 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. CCE-27445-6:Disable SSH Root Login To assure 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. 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
Applicable - Configurable Verify the operating system requires individuals to be authenticated with an individual authenticator prior to using a group authenticator. If it does not, this is a finding. To determine how the SSH daemon's PermitRootLogin option is set, run the following command: $ sudo grep -i PermitRootLogin /etc/ssh/sshd_config If a line indicating no is returned, then the required value is set. Is it the case that the required value is not set? Configure the operating system to require individuals to be authenticated with an individual authenticator prior to using a group authenticator. 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 medium
CCI-000770 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. Product Meets this Requirement To assure 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system requires individuals to be authenticated with an individual authenticator prior to using a group authenticator. If it does not, this is a finding. Configure the operating system to require individuals to be authenticated with an individual authenticator prior to using a group authenticator. This requirement is a permanent not a finding. No fix is required. medium
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-001942 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 non-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 non-privileged account is any operating system account with authorizations of a non-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-000778 SRG-OS-000114-GPOS-00059 TBD - Assigned by DISA after STIG release The operating system must uniquely identify peripherals before establishing a connection. CCE-27498-5:Disable the Automounter 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. 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 disable autofs.service
The autofs service can be masked with the following command:
$ sudo systemctl mask autofs.service
Applicable - Configurable Verify the operating system uniquely identifies peripherals before establishing a connection. If it does not, this is a finding. To check that the autofs service is disabled in system boot configuration, run the following command: $ systemctl is-enabled autofs Output should indicate the autofs service has either not been installed, or has been disabled at all runlevels, as shown in the example below: $ systemctl is-enabled autofs disabled Run the following command to verify autofs is not active (i.e. not running) through current runtime configuration: $ systemctl is-active autofs If the service is not running the command will return the following output: inactive By default the service will also be masked, to check that the autofs is masked, run the following command: $ systemctl show autofs | grep "LoadState\|UnitFileState" If the service is masked the command will return the following outputs: LoadState=masked UnitFileState=masked Is it the case that ? Configure the operating system to uniquely identify peripherals before establishing a connection. 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 disable autofs.service The autofs service can be masked with the following command: $ sudo systemctl mask autofs.service medium
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. CCE-27277-3:Disable Modprobe Loading of USB Storage Driver 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. 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 a file in the directory /etc/modprobe.d:
install usb-storage /bin/true
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.
Applicable - Configurable Verify the operating system uniquely identifies peripherals before establishing a connection. If it does not, this is a finding. If the system is configured to prevent the loading of the usb-storage kernel module, it will contain lines inside any file in /etc/modprobe.d or the deprecated/etc/modprobe.conf. These lines instruct the module loading system to run another program (such as /bin/true) upon a module install event. Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf: $ grep -r usb-storage /etc/modprobe.conf /etc/modprobe.d Is it the case that no line is returned? Configure the operating system to uniquely identify peripherals before establishing a connection. 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 a file in the directory /etc/modprobe.d: install usb-storage /bin/true 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. medium
CCI-000795 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. CCE-27355-7:Set Account Expiration Following 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. To specify the number of days after a password expires (which signifies inactivity) until an account is permanently disabled, add or correct the following lines in /etc/default/useradd, substituting NUM_DAYS appropriately:
INACTIVE=
A value of 35 is recommended; however, this profile expects that the value is set to . If a password is currently on the verge of expiration, then 35 days remain until the account is automatically disabled. However, if the password will not expire for another 60 days, then 95 days could elapse until the account would be automatically disabled. See the useradd man page for more information. Determining the inactivity timeout must be done with careful consideration of the length of a "normal" period of inactivity for users in the particular environment. Setting the timeout too low incurs support costs and also has the potential to impact availability of the system to legitimate users.
Applicable - Configurable Verify the operating system disables account identifiers (individuals, groups, roles, and devices) after 35 days of inactivity. If it does not, this is a finding. To verify the INACTIVE setting, run the following command: $ grep "INACTIVE" /etc/default/useradd The output should indicate the INACTIVE configuration option is set to an appropriate integer as shown in the example below: $ grep "INACTIVE" /etc/default/useradd INACTIVE= Is it the case that the value of INACTIVE is greater than the expected value? Configure the operating system to disable account identifiers (individuals, groups, roles, and devices) after 35 days of 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 lines in /etc/default/useradd, substituting NUM_DAYS appropriately: INACTIVE= A value of 35 is recommended; however, this profile expects that the value is set to . If a password is currently on the verge of expiration, then 35 days remain until the account is automatically disabled. However, if the password will not expire for another 60 days, then 95 days could elapse until the account would be automatically disabled. See the useradd man page for more information. Determining the inactivity timeout must be done with careful consideration of the length of a "normal" period of inactivity for users in the particular environment. Setting the timeout too low incurs support costs and also has the potential to impact availability of the system to legitimate users. medium
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-002468 SRG-OS-000402-GPOS-00181 TBD - Assigned by DISA after STIG release The operating system must perform data origin verification authentication on the name/address resolution responses the system receives from authoritative sources. If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed which would result in query failure or denial of service. Data origin authentication verification must be performed to thwart these types of attacks. Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching Domain Name System (DNS) servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations. This is not applicable if DNSSEC is not implemented on the local network.
CCI-002467 SRG-OS-000401-GPOS-00180 TBD - Assigned by DISA after STIG release The operating system must perform data integrity verification on the name/address resolution responses the system receives from authoritative sources. If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed which would result in query failure or denial of service. Data integrity verification must be performed to thwart these types of attacks. Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching Domain Name System (DNS) servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations. This is not applicable if DNSSEC is not implemented on the local network.
CCI-002466 SRG-OS-000400-GPOS-00179 TBD - Assigned by DISA after STIG release The operating system must request data integrity verification on the name/address resolution responses the system receives from authoritative sources. If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed which would result in query failure or denial of service. Data integrity verification must be performed to thwart these types of attacks. Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching Domain Name System (DNS) servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations. This is not applicable if DNSSEC is not implemented on the local network.
CCI-002465 SRG-OS-000399-GPOS-00178 TBD - Assigned by DISA after STIG release The operating system must request data origin authentication verification on the name/address resolution responses the system receives from authoritative sources. If data origin authentication and data integrity verification are not performed, the resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed, which would result in query failure or DoS. Data origin authentication must be performed to thwart these types of attacks. Each client of name resolution services either performs this validation on its own or has authenticated channels to trusted validation providers. Information systems that provide name and address resolution services for local clients include, for example, recursive resolving or caching Domain Name System (DNS) servers. DNS client resolvers either perform validation of DNSSEC signatures, or clients use authenticated channels to recursive resolvers that perform such validations. Information systems that use technologies other than the DNS to map between host/service names and network addresses provide other means to enable clients to verify the authenticity of response data. This is not applicable if DNSSEC is not implemented on the local network.
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. CCE-80359-3:Enable FIPS Mode in GRUB2 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. To ensure FIPS mode is enabled, install package dracut-fips, and rebuild initramfs by running the following commands:
$ sudo yum install dracut-fips
dracut -f
After the dracut command has been run, add the argument fips=1 to the default GRUB 2 command line for the Linux operating system in /etc/default/grub, in the manner below:
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 fips=1"
Finally, rebuild the grub.cfg file by using the
grub2-mkconfig -o
command as follows:
  • On BIOS-based machines, issue the following command as root:
    ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
  • On UEFI-based machines, issue the following command as root:
    ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
Applicable - Configurable Verify the operating system implements NSA-approved cryptography to protect classified information in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. If it does not, this is a finding. To verify that FIPS is enabled properly in grub, run the following command: $ grep fips /etc/default/grub The output should contain fips=1 Is it the case that FIPS is not configured or enabled in grub? Configure the operating system to implement NSA-approved cryptography to protect classified information in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards. To ensure FIPS mode is enabled, install package dracut-fips, and rebuild initramfs by running the following commands: $ sudo yum install dracut-fips dracut -f After the dracut command has been run, add the argument fips=1 to the default GRUB 2 command line for the Linux operating system in /etc/default/grub, in the manner below: GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 fips=1" Finally, rebuild the grub.cfg file by using the grub2-mkconfig -o command as follows: On BIOS-based machines, issue the following command as root: ~]# grub2-mkconfig -o /boot/grub2/grub.cfgOn UEFI-based machines, issue the following command as root: ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg high
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. CCE-27295-5:Use Only FIPS 140-2 Validated Ciphers 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 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. Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
The man page sshd_config(5) contains a list of supported ciphers.

Only the following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux 7:
- aes128-ctr
- aes192-ctr
- aes256-ctr
- aes128-cbc
- aes192-cbc
- aes256-cbc
- 3des-cbc
- rijndael-cbc@lysator.liu.se

Any combination of the above ciphers will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following ciphers: .
Applicable - Configurable Verify the operating system uses mechanisms meeting the requirements of applicable federal laws, Executive orders, directives, policies, regulations, standards, and guidance for authentication to a cryptographic module. If it does not, this is a finding. Only FIPS ciphers should be used. To verify that only FIPS-approved ciphers are in use, run the following command: $ sudo grep Ciphers /etc/ssh/sshd_config The output should contain only those ciphers which are FIPS-approved. Is it the case that FIPS ciphers are not configured or the enabled ciphers are not FIPS-approved? Configure the operating system to use mechanisms meeting the requirements of applicable federal laws, Executive orders, directives, policies, regulations, standards, and guidance for authentication to a cryptographic module. Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers: Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc The man page sshd_config(5) contains a list of supported ciphers. Only the following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux 7: - aes128-ctr - aes192-ctr - aes256-ctr - aes128-cbc - aes192-cbc - aes256-cbc - 3des-cbc - rijndael-cbc@lysator.liu.se Any combination of the above ciphers will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following ciphers: . medium
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. CCE-27433-2:Set SSH Idle Timeout Interval 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. SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out.

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


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.
Applicable - Configurable Verify the operating system verifies remote disconnection at the termination of nonlocal maintenance and diagnostic sessions, when used for nonlocal maintenance sessions. If it does not, this is a finding. Run the following command to see what the timeout interval is: $ sudo grep ClientAliveInterval /etc/ssh/sshd_config If properly configured, the output should be: ClientAliveInterval Is it the case that it is commented out or not configured properly? Configure the operating system to verify remote disconnection at the termination of nonlocal maintenance and diagnostic sessions, when used for nonlocal maintenance sessions. SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out. To set an idle timeout interval, edit the following line in /etc/ssh/sshd_config as follows: ClientAliveInterval 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. medium
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. CCE-27295-5:Use Only FIPS 140-2 Validated Ciphers 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. Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
The man page sshd_config(5) contains a list of supported ciphers.

Only the following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux 7:
- aes128-ctr
- aes192-ctr
- aes256-ctr
- aes128-cbc
- aes192-cbc
- aes256-cbc
- 3des-cbc
- rijndael-cbc@lysator.liu.se

Any combination of the above ciphers will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following ciphers: .
Applicable - Configurable Verify the operating system implements cryptographic mechanisms to protect the confidentiality of nonlocal maintenance and diagnostic communications, when used for nonlocal maintenance sessions. If it does not, this is a finding. Only FIPS ciphers should be used. To verify that only FIPS-approved ciphers are in use, run the following command: $ sudo grep Ciphers /etc/ssh/sshd_config The output should contain only those ciphers which are FIPS-approved. Is it the case that FIPS ciphers are not configured or the enabled ciphers are not FIPS-approved? Configure the operating system to implement cryptographic mechanisms to protect the confidentiality of nonlocal maintenance and diagnostic communications, when used for nonlocal maintenance sessions. Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers: Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc The man page sshd_config(5) contains a list of supported ciphers. Only the following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux 7: - aes128-ctr - aes192-ctr - aes256-ctr - aes128-cbc - aes192-cbc - aes256-cbc - 3des-cbc - rijndael-cbc@lysator.liu.se Any combination of the above ciphers will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following ciphers: . medium
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. CCE-27455-5:Use Only FIPS 140-2 Validated MACs 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. Limit the MACs to those hash algorithms which are FIPS-approved. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved MACs:
MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1
The man page sshd_config(5) contains a list of supported MACs.

Only the following message authentication codes are FIPS 140-2 certified on Red Hat Enterprise Linux 7:
- hmac-sha1
- hmac-sha2-256
- hmac-sha2-512
- hmac-sha1-etm@openssh.com
- hmac-sha2-256-etm@openssh.com
- hmac-sha2-512-etm@openssh.com

Any combination of the above MACs will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following MACs: .
Applicable - Configurable Verify the operating system implements cryptographic mechanisms to protect the confidentiality of nonlocal maintenance and diagnostic communications, when used for nonlocal maintenance sessions. If it does not, this is a finding. Only FIPS-approved MACs should be used. To verify that only FIPS-approved MACs are in use, run the following command: $ sudo grep -i macs /etc/ssh/sshd_config The output should contain only those MACs which are FIPS-approved. Any use of other ciphers or algorithms will result in the module entering the non-FIPS mode of operation. Is it the case that MACs option is commented out or not using FIPS-approved hash algorithms? Configure the operating system to implement cryptographic mechanisms to protect the confidentiality of nonlocal maintenance and diagnostic communications, when used for nonlocal maintenance sessions. Limit the MACs to those hash algorithms which are FIPS-approved. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved MACs: MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1 The man page sshd_config(5) contains a list of supported MACs. Only the following message authentication codes are FIPS 140-2 certified on Red Hat Enterprise Linux 7: - hmac-sha1 - hmac-sha2-256 - hmac-sha2-512 - hmac-sha1-etm@openssh.com - hmac-sha2-256-etm@openssh.com - hmac-sha2-512-etm@openssh.com Any combination of the above MACs will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following MACs: . medium
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). Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system uniquely identifies and authenticates non-organizational users (or processes acting on behalf of non-organizational users). If it does not, this is a finding. Configure the operating system to uniquely identify and authenticate non-organizational users (or processes acting on behalf of non-organizational users). This requirement is a permanent not a finding. No fix is required. medium
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. CCE-27295-5:Use Only FIPS 140-2 Validated Ciphers 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). Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
The man page sshd_config(5) contains a list of supported ciphers.

Only the following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux 7:
- aes128-ctr
- aes192-ctr
- aes256-ctr
- aes128-cbc
- aes192-cbc
- aes256-cbc
- 3des-cbc
- rijndael-cbc@lysator.liu.se

Any combination of the above ciphers will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following ciphers: .
Applicable - Configurable Verify the operating system implements cryptographic mechanisms to protect the integrity of nonlocal maintenance and diagnostic communications, when used for nonlocal maintenance sessions. If it does not, this is a finding. Only FIPS ciphers should be used. To verify that only FIPS-approved ciphers are in use, run the following command: $ sudo grep Ciphers /etc/ssh/sshd_config The output should contain only those ciphers which are FIPS-approved. Is it the case that FIPS ciphers are not configured or the enabled ciphers are not FIPS-approved? Configure the operating system to implement cryptographic mechanisms to protect the integrity of nonlocal maintenance and diagnostic communications, when used for nonlocal maintenance sessions. Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers: Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc The man page sshd_config(5) contains a list of supported ciphers. Only the following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux 7: - aes128-ctr - aes192-ctr - aes256-ctr - aes128-cbc - aes192-cbc - aes256-cbc - 3des-cbc - rijndael-cbc@lysator.liu.se Any combination of the above ciphers will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following ciphers: . medium
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. CCE-27461-3:Ensure auditd Collects System Administrator Actions 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. At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file:
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing is configured for system administrator actions, run the following command: $ sudo auditctl -l | grep "watch=/etc/sudoers\|watch=/etc/sudoers.d\|-w /etc/sudoers\|-w /etc/sudoers.d" Is it the case that there is not output? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. At a minimum, the audit system should collect administrator actions for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -w /etc/sudoers -p wa -k actions -w /etc/sudoers.d/ -p wa -k actions If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file: -w /etc/sudoers -p wa -k actions -w /etc/sudoers.d/ -p wa -k actions medium
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. CCE-27447-2:Ensure auditd Collects Information on Exporting to Media (successful) 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. 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
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system:
-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing is configured for all media exportation events, run the following command: $ sudo auditctl -l | grep syscall | grep mount Is it the case that there is not output? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add the following line to /etc/audit/audit.rules file, setting ARCH to either b32 or b64 as appropriate for your system: -a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export medium
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. CCE-80994-7:Record Attempts to Alter Logon and Logout Events - tallylog 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. 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/tallylog -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/tallylog -p wa -k logins
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing is configured for system administrator actions, run the following command: $ sudo auditctl -l | grep "watch=/var/log/tallylog\|-w /var/log/tallylog" Is it the case that there is not output? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/tallylog -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/tallylog -p wa -k logins medium
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. CCE-80383-3:Record Attempts to Alter Logon and Logout Events - faillock 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. 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/run/faillock -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/run/faillock -p wa -k logins
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing is configured for system administrator actions, run the following command: $ sudo auditctl -l | grep "watch=/var/run/faillock\|-w /var/run/faillock" Is it the case that there is not output? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/run/faillock -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/run/faillock -p wa -k logins medium
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. CCE-80384-1:Record Attempts to Alter Logon and Logout Events - lastlog 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. 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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing is configured for system administrator actions, run the following command: $ sudo auditctl -l | grep "watch=/var/log/lastlog\|-w /var/log/lastlog" Is it the case that there is not output? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 medium
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. CCE-27364-9:Record Events that Modify the System's Discretionary Access Controls - chown 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. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the chown system call, run the following command: preserve$ sudo grep "chown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=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 medium
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. CCE-27388-8:Record Events that Modify the System's Discretionary Access Controls - fchmodat 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. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the fchmodat system call, run the following command: preserve$ sudo grep "fchmodat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=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 medium
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. CCE-27353-2:Record Events that Modify the System's Discretionary Access Controls - fremovexattr 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. 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


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


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


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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the fremovexattr system call, run the following command: preserve$ sudo grep "fremovexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 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 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 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 medium
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. CCE-27410-0:Record Events that Modify the System's Discretionary Access Controls - lremovexattr 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. 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


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


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


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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the lremovexattr system call, run the following command: preserve$ sudo grep "lremovexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 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 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 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 medium
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. CCE-27356-5:Record Events that Modify the System's Discretionary Access Controls - fchown 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. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the fchown system call, run the following command: preserve$ sudo grep "fchown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=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 medium
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. CCE-27393-8:Record Events that Modify the System's Discretionary Access Controls - fchmod 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. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the fchmod system call, run the following command: preserve$ sudo grep "fchmod" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=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 medium
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. CCE-27387-0:Record Events that Modify the System's Discretionary Access Controls - fchownat 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. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the fchownat system call, run the following command: preserve$ sudo grep "fchownat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=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 medium
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. CCE-27213-8:Record Events that Modify the System's Discretionary Access Controls - setxattr 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. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -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
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
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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the setxattr system call, run the following command: preserve$ sudo grep "setxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -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 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 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 medium
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. CCE-27367-2:Record Events that Modify the System's Discretionary Access Controls - removexattr 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. 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


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


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


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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the removexattr system call, run the following command: preserve$ sudo grep "removexattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 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 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 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 medium
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. CCE-27339-1:Record Events that Modify the System's Discretionary Access Controls - chmod 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. 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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the chmod system call, run the following command: preserve$ sudo grep "chmod" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 medium
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. CCE-27389-6:Record Events that Modify the System's Discretionary Access Controls - fsetxattr 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. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -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
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
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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the fsetxattr system call, run the following command: preserve$ sudo grep "fsetxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -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 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 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 medium
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. CCE-27280-7:Record Events that Modify the System's Discretionary Access Controls - lsetxattr 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. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -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
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
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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the lsetxattr system call, run the following command: preserve$ sudo grep "lsetxattr" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -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 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 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 medium
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. CCE-27083-5:Record Events that Modify the System's Discretionary Access Controls - lchown 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. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the lchown system call, run the following command: preserve$ sudo grep "lchown" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. At a minimum, the audit system should collect file permission changes for all users and root. If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add the following line to a file with suffix .rules in the directory /etc/audit/rules.d: -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=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 medium
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. CCE-80405-4:Ensure auditd Collects Information on the Use of Privileged Commands - umount 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. 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/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep umount /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80410-4:Ensure auditd Collects Information on the Use of Privileged Commands - crontab 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. 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/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep crontab /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80401-3:Ensure auditd Collects Information on the Use of Privileged Commands - sudo 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. 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/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep sudo /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/sudo -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80408-8:Ensure auditd Collects Information on the Use of Privileged Commands - ssh-keysign 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. 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/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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/key-sign -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep ssh-keysign /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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/key-sign -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes medium
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. CCE-80406-2:Ensure auditd Collects Information on the Use of Privileged Commands - postdrop 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. 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/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep postdrop /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80407-0:Ensure auditd Collects Information on the Use of Privileged Commands - postqueue 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. 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/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep postqueue /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80399-9:Ensure auditd Collects Information on the Use of Privileged Commands - userhelper 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. 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/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep userhelper /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes medium
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. CCE-80404-7:Ensure auditd Collects Information on the Use of Privileged Commands - chsh 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. 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/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep chsh /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/chsh -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80400-5:Ensure auditd Collects Information on the Use of Privileged Commands - su 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. 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/su -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep su /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/su -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80398-1:Ensure auditd Collects Information on the Use of Privileged Commands - chage 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. 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=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep chage /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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=special-config-changes 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=special-config-changes medium
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. CCE-80396-5:Ensure auditd Collects Information on the Use of Privileged Commands - unix_chkpwd 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. 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/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep unix_chkpwd /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes medium
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. CCE-80403-9:Ensure auditd Collects Information on the Use of Privileged Commands - newgrp 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. 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/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep newgrp /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80395-7:Ensure auditd Collects Information on the Use of Privileged Commands - passwd 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. 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/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep passwd /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80411-2:Ensure auditd Collects Information on the Use of Privileged Commands - pam_timestamp_check 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. 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/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep pam_timestamp_check /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80397-3:Ensure auditd Collects Information on the Use of Privileged Commands - gpasswd 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. 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/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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=special-config-changes
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep gpasswd /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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=special-config-changes medium
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. CCE-80402-1:Ensure auditd Collects Information on the Use of Privileged Commands - sudoedit 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. 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/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
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/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command: $ sudo grep sudoedit /etc/audit/audit.rules /etc/audit/rules.d/* It should return a relevant line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes 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/sudoedit -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes medium
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. CCE-80996-2:Ensure auditd Collects File Deletion Events by User - unlink 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. 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 unlink -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 unlink -F auid>=1000 -F auid!=unset -F key=delete
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the unlink system call, run the following command: preserve$ sudo grep "unlink" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 unlink -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 unlink -F auid>=1000 -F auid!=unset -F key=delete medium
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. CCE-80662-0:Ensure auditd Collects File Deletion Events by User - unlinkat 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. 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 unlinkat -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 unlinkat -F auid>=1000 -F auid!=unset -F key=delete
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the unlinkat system call, run the following command: preserve$ sudo grep "unlinkat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 unlinkat -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 unlinkat -F auid>=1000 -F auid!=unset -F key=delete medium
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. CCE-80413-8:Ensure auditd Collects File Deletion Events by User - renameat 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. 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 renameat -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 renameat -F auid>=1000 -F auid!=unset -F key=delete
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the renameat system call, run the following command: preserve$ sudo grep "renameat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 renameat -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 renameat -F auid>=1000 -F auid!=unset -F key=delete medium
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. CCE-80412-0:Ensure auditd Collects File Deletion Events by User - rmdir 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. 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 rmdir -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 rmdir -F auid>=1000 -F auid!=unset -F key=delete
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the rmdir system call, run the following command: preserve$ sudo grep "rmdir" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 rmdir -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 rmdir -F auid>=1000 -F auid!=unset -F key=delete medium
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. CCE-80995-4:Ensure auditd Collects File Deletion Events by User - rename 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. 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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the rename system call, run the following command: preserve$ sudo grep "rename" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 medium
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. CCE-80393-2:Record Any Attempts to Run chcon 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. 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-priv_change
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-priv_change
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that execution of the command is being audited, run the following command: $ sudo grep "path=/usr/bin/chcon" /etc/audit/audit.rules /etc/audit/rules.d/* The output should return something similar to: -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged-priv_change Is it the case that ? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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-priv_change 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-priv_change medium
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. CCE-80392-4:Record Any Attempts to Run setsebool 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. 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-priv_change
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-priv_change
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that execution of the command is being audited, run the following command: $ sudo grep "path=/usr/sbin/setsebool" /etc/audit/audit.rules /etc/audit/rules.d/* The output should return something similar to: -a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged-priv_change Is it the case that ? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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-priv_change 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-priv_change medium
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. CCE-80391-6:Record Any Attempts to Run semanage 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. 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-priv_change
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-priv_change
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that execution of the command is being audited, run the following command: $ sudo grep "path=/usr/sbin/semanage" /etc/audit/audit.rules /etc/audit/rules.d/* The output should return something similar to: -a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged-priv_change Is it the case that ? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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-priv_change 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-priv_change medium
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. CCE-80660-4:Record Any Attempts to Run setfiles 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. 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-priv_change
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-priv_change
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To verify that execution of the command is being audited, run the following command: $ sudo grep "path=/usr/sbin/setfiles" /etc/audit/audit.rules /etc/audit/rules.d/* The output should return something similar to: -a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged-priv_change Is it the case that ? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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-priv_change 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-priv_change medium
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. CCE-80390-8:Record Unsuccessful Access Attempts to Files - ftruncate 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. 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 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 exiu=-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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the ftruncate system call, run the following command: preserve$ sudo grep "ftruncate" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 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 exiu=-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 medium
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. CCE-80387-4:Record Unsuccessful Access Attempts to Files - openat 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. 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 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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the openat system call, run the following command: preserve$ sudo grep "openat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 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 medium
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. CCE-80385-8:Record Unsuccessful Access Attempts to Files - creat 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. 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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the creat system call, run the following command: preserve$ sudo grep "creat" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 medium
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. CCE-80388-2:Record Unsuccessful Access Attempts to Files - open_by_handle_at 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. 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 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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the open_by_handle_at system call, run the following command: preserve$ sudo grep "open_by_handle_at" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 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 medium
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. CCE-80389-0:Record Unsuccessful Access Attempts to Files - truncate 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. 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 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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the truncate system call, run the following command: preserve$ sudo grep "truncate" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 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 medium
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. CCE-80386-6:Record Unsuccessful Access Attempts to Files - open 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. 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 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
Applicable - Configurable Verify the operating system audits all activities performed during nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. To determine if the system is configured to audit calls to the open system call, run the following command: preserve$ sudo grep "open" /etc/audit/audit.* If the system is configured to audit this activity, it will return a line. Is it the case that no line is returned? Configure the operating system to audit all activities performed during nonlocal maintenance and diagnostic sessions. 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 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 medium
CCI-001991 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. CCE-80520-0:Configure Smart Card Certificate Status Checking 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). Configure the operating system to do certificate status checking for PKI authentication. Modify all of the cert_policy lines in /etc/pam_pkcs11/pam_pkcs11.conf to include ocsp_on like so:
cert_policy = ca, ocsp_on, signature;
Applicable - Configurable Verify the operating system, for PKI-based authentication, implements a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network. If it does not, this is a finding. To verify the operating system implements certificate status checking for PKI authentication, run the following command: $ sudo grep -i cert_policy /etc/pam_pkcs11/pam_pkcs11.conf The output should return multiple lines similiar to the following: cert_policy = ca, ocsp_on, signature; cert_policy = ca, ocsp_on, signature; cert_policy = ca, ocsp_on, signature; Is it the case that ocsp_on is not configured? Configure the operating system, for PKI-based authentication, to 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. Configure the operating system to do certificate status checking for PKI authentication. Modify all of the cert_policy lines in /etc/pam_pkcs11/pam_pkcs11.conf to include ocsp_on like so: cert_policy = ca, ocsp_on, signature; medium
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.
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.
CCI-002041 SRG-OS-000380-GPOS-00165 TBD - Assigned by DISA after STIG release The operating system must allow the use of a temporary password for system logons with an immediate change to a permanent password. Without providing this capability, an account may be created without a password. Non-repudiation cannot be guaranteed once an account is created if a user is not forced to change the temporary password upon initial logon. Temporary passwords are typically used to allow access when new accounts are created or passwords are changed. It is common practice for administrators to create temporary passwords for user accounts which allow the users to log on, yet force them to change the password once they have successfully authenticated.
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. Guidance Does Not Meet this Requirement Due to Impracticality or Scope 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. This requirement is NA. No fix is required. N/A Verify the operating system is configured such that emergency administrator accounts are automatically removed or disabled within 72 hours. If it is not, this is a finding. Configure the operating system such that emergency administrator accounts are automatically removed or disabled within 72 hours. This requirement is NA. No fix is required. medium
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-001958 SRG-OS-000378-GPOS-00163 TBD - Assigned by DISA after STIG release The operating system must authenticate peripherals before establishing a connection. CCE-27498-5:Disable the Automounter 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. 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 disable autofs.service
The autofs service can be masked with the following command:
$ sudo systemctl mask autofs.service
Applicable - Configurable Verify the operating system authenticates peripherals before establishing a connection. If it does not, this is a finding. To check that the autofs service is disabled in system boot configuration, run the following command: $ systemctl is-enabled autofs Output should indicate the autofs service has either not been installed, or has been disabled at all runlevels, as shown in the example below: $ systemctl is-enabled autofs disabled Run the following command to verify autofs is not active (i.e. not running) through current runtime configuration: $ systemctl is-active autofs If the service is not running the command will return the following output: inactive By default the service will also be masked, to check that the autofs is masked, run the following command: $ systemctl show autofs | grep "LoadState\|UnitFileState" If the service is masked the command will return the following outputs: LoadState=masked UnitFileState=masked Is it the case that ? Configure the operating system to authenticate peripherals before establishing a connection. 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 disable autofs.service The autofs service can be masked with the following command: $ sudo systemctl mask autofs.service medium
CCI-001958 SRG-OS-000378-GPOS-00163 TBD - Assigned by DISA after STIG release The operating system must authenticate peripherals before establishing a connection. CCE-27277-3:Disable Modprobe Loading of USB Storage Driver 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. 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 a file in the directory /etc/modprobe.d:
install usb-storage /bin/true
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.
Applicable - Configurable Verify the operating system authenticates peripherals before establishing a connection. If it does not, this is a finding. If the system is configured to prevent the loading of the usb-storage kernel module, it will contain lines inside any file in /etc/modprobe.d or the deprecated/etc/modprobe.conf. These lines instruct the module loading system to run another program (such as /bin/true) upon a module install event. Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf: $ grep -r usb-storage /etc/modprobe.conf /etc/modprobe.d Is it the case that no line is returned? Configure the operating system to authenticate peripherals before establishing a connection. 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 a file in the directory /etc/modprobe.d: install usb-storage /bin/true 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. medium
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. CCE-27295-5:Use Only FIPS 140-2 Validated Ciphers 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. Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
The man page sshd_config(5) contains a list of supported ciphers.

Only the following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux 7:
- aes128-ctr
- aes192-ctr
- aes256-ctr
- aes128-cbc
- aes192-cbc
- aes256-cbc
- 3des-cbc
- rijndael-cbc@lysator.liu.se

Any combination of the above ciphers will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following ciphers: .
Applicable - Configurable Verify the operating system employs strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. Only FIPS ciphers should be used. To verify that only FIPS-approved ciphers are in use, run the following command: $ sudo grep Ciphers /etc/ssh/sshd_config The output should contain only those ciphers which are FIPS-approved. Is it the case that FIPS ciphers are not configured or the enabled ciphers are not FIPS-approved? Configure the operating system to employ strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions. Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers: Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc The man page sshd_config(5) contains a list of supported ciphers. Only the following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux 7: - aes128-ctr - aes192-ctr - aes256-ctr - aes128-cbc - aes192-cbc - aes256-cbc - 3des-cbc - rijndael-cbc@lysator.liu.se Any combination of the above ciphers will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following ciphers: . medium
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. CCE-27455-5:Use Only FIPS 140-2 Validated MACs 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. Limit the MACs to those hash algorithms which are FIPS-approved. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved MACs:
MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1
The man page sshd_config(5) contains a list of supported MACs.

Only the following message authentication codes are FIPS 140-2 certified on Red Hat Enterprise Linux 7:
- hmac-sha1
- hmac-sha2-256
- hmac-sha2-512
- hmac-sha1-etm@openssh.com
- hmac-sha2-256-etm@openssh.com
- hmac-sha2-512-etm@openssh.com

Any combination of the above MACs will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following MACs: .
Applicable - Configurable Verify the operating system employs strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions. If it does not, this is a finding. Only FIPS-approved MACs should be used. To verify that only FIPS-approved MACs are in use, run the following command: $ sudo grep -i macs /etc/ssh/sshd_config The output should contain only those MACs which are FIPS-approved. Any use of other ciphers or algorithms will result in the module entering the non-FIPS mode of operation. Is it the case that MACs option is commented out or not using FIPS-approved hash algorithms? Configure the operating system to employ strong authenticators in the establishment of nonlocal maintenance and diagnostic sessions. Limit the MACs to those hash algorithms which are FIPS-approved. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved MACs: MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1 The man page sshd_config(5) contains a list of supported MACs. Only the following message authentication codes are FIPS 140-2 certified on Red Hat Enterprise Linux 7: - hmac-sha1 - hmac-sha2-256 - hmac-sha2-512 - hmac-sha1-etm@openssh.com - hmac-sha2-256-etm@openssh.com - hmac-sha2-512-etm@openssh.com Any combination of the above MACs will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following MACs: . medium
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. CCE-80207-4:Enable Smart Card Login 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. To enable smart card authentication, consult the documentation at: For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at: Applicable - Configurable Verify the operating system electronically verifies Personal Identity Verification (PIV) credentials. If it does not, this is a finding. Interview the SA to determine if all accounts not exempted by policy are using CAC authentication. For DoD systems, the following systems and accounts are exempt from using smart card (CAC) authentication: SIPRNET systemsStandalone systemsApplication accountsTemporary employee accounts, such as students or interns, who cannot easily receive a CAC or PIVOperational tactical locations that are not collocated with RAPIDS workstations to issue CAC or ALTTest systems, such as those with an Interim Approval to Test (IATT) and use a separate VPN, firewall, or security measure preventing access to network and system components from outside the protection boundary documented in the IATT. Is it the case that non-exempt accounts are not using CAC authentication? Configure the operating system to electronically verify Personal Identity Verification (PIV) credentials. To enable smart card authentication, consult the documentation at: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/smartcards.html#authconfig-smartcards For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at: https://access.redhat.com/solutions/82273 medium
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. CCE-80520-0:Configure Smart Card Certificate Status Checking 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. Configure the operating system to do certificate status checking for PKI authentication. Modify all of the cert_policy lines in /etc/pam_pkcs11/pam_pkcs11.conf to include ocsp_on like so:
cert_policy = ca, ocsp_on, signature;
Applicable - Configurable Verify the operating system electronically verifies Personal Identity Verification (PIV) credentials. If it does not, this is a finding. To verify the operating system implements certificate status checking for PKI authentication, run the following command: $ sudo grep -i cert_policy /etc/pam_pkcs11/pam_pkcs11.conf The output should return multiple lines similiar to the following: cert_policy = ca, ocsp_on, signature; cert_policy = ca, ocsp_on, signature; cert_policy = ca, ocsp_on, signature; Is it the case that ocsp_on is not configured? Configure the operating system to electronically verify Personal Identity Verification (PIV) credentials. Configure the operating system to do certificate status checking for PKI authentication. Modify all of the cert_policy lines in /etc/pam_pkcs11/pam_pkcs11.conf to include ocsp_on like so: cert_policy = ca, ocsp_on, signature; medium
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. CCE-80519-2:Install Smart Card Packages For Multifactor Authentication 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. Configure the operating system to implement multifactor authentication by installing the required packages with the following command: The esc pam_pkcs11 package can be installed with the following command:
$ sudo yum install esc pam_pkcs11
Applicable - Configurable Verify the operating system electronically verifies Personal Identity Verification (PIV) credentials. If it does not, this is a finding. To verify the operating system has the packages required for multifactor authentication installed, run the following command: $ sudo yum list installed esc pam_pkcs11 Is it the case that smartcard software is not installed? Configure the operating system to electronically verify Personal Identity Verification (PIV) credentials. Configure the operating system to implement multifactor authentication by installing the required packages with the following command: The esc pam_pkcs11 package can be installed with the following command: $ sudo yum install esc pam_pkcs11 medium
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. CCE-80108-4:Enable the GNOME3 Login Smartcard Authentication 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. In the default graphical environment, smart card authentication can be enabled on the login screen by setting enable-smartcard-authentication to true.

To enable, add or edit enable-smartcard-authentication to /etc/dconf/db/gdm.d/00-security-settings. For example:
[org/gnome/login-screen]
enable-smartcard-authentication=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/enable-smartcard-authentication
After the settings have been set, run dconf update.
Applicable - Configurable Verify the operating system electronically verifies Personal Identity Verification (PIV) credentials. If it does not, this is a finding. To ensure smart card authentication on the login screen is enabled, run the following command: $ grep enable-smartcard-authentication /etc/dconf/db/gdm.d/* The output should be true. To ensure that users cannot disable smart card authentication on the login screen, run the following: $ grep enable-smartcard-authentication /etc/dconf/db/gdm.d/locks/* If properly configured, the output should be /org/gnome/login-screen/enable-smartcard-authentication Is it the case that enable-smartcard-authentication has not been configured or is disabled? Configure the operating system to electronically verify Personal Identity Verification (PIV) credentials. In the default graphical environment, smart card authentication can be enabled on the login screen by setting enable-smartcard-authentication to true. To enable, add or edit enable-smartcard-authentication to /etc/dconf/db/gdm.d/00-security-settings. For example: [org/gnome/login-screen] enable-smartcard-authentication=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/enable-smartcard-authentication After the settings have been set, run dconf update. medium
CCI-001953 SRG-OS-000376-GPOS-00161 TBD - Assigned by DISA after STIG release The operating system must accept Personal Identity Verification (PIV) credentials. CCE-80207-4:Enable Smart Card Login 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. To enable smart card authentication, consult the documentation at: For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at: Applicable - Configurable Verify the operating system accepts Personal Identity Verification (PIV) credentials. If it does not, this is a finding. Interview the SA to determine if all accounts not exempted by policy are using CAC authentication. For DoD systems, the following systems and accounts are exempt from using smart card (CAC) authentication: SIPRNET systemsStandalone systemsApplication accountsTemporary employee accounts, such as students or interns, who cannot easily receive a CAC or PIVOperational tactical locations that are not collocated with RAPIDS workstations to issue CAC or ALTTest systems, such as those with an Interim Approval to Test (IATT) and use a separate VPN, firewall, or security measure preventing access to network and system components from outside the protection boundary documented in the IATT. Is it the case that non-exempt accounts are not using CAC authentication? Configure the operating system to accept Personal Identity Verification (PIV) credentials. To enable smart card authentication, consult the documentation at: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System-Level_Authentication_Guide/smartcards.html#authconfig-smartcards For guidance on enabling SSH to authenticate against a Common Access Card (CAC), consult documentation at: https://access.redhat.com/solutions/82273 medium
CCI-001948 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. CCE-80520-0:Configure Smart Card Certificate Status Checking Using an authentication device, such as a 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 card and the DoD Common Access Card. 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, non-organization-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). Requires further clarification from NIST. Configure the operating system to do certificate status checking for PKI authentication. Modify all of the cert_policy lines in /etc/pam_pkcs11/pam_pkcs11.conf to include ocsp_on like so:
cert_policy = ca, ocsp_on, signature;
Applicable - Configurable Verify the operating system implements 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. If it does not, this is a finding. To verify the operating system implements certificate status checking for PKI authentication, run the following command: $ sudo grep -i cert_policy /etc/pam_pkcs11/pam_pkcs11.conf The output should return multiple lines similiar to the following: cert_policy = ca, ocsp_on, signature; cert_policy = ca, ocsp_on, signature; cert_policy = ca, ocsp_on, signature; Is it the case that ocsp_on is not configured? Configure the operating system to 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. Configure the operating system to do certificate status checking for PKI authentication. Modify all of the cert_policy lines in /etc/pam_pkcs11/pam_pkcs11.conf to include ocsp_on like so: cert_policy = ca, ocsp_on, signature; medium
CCI-001948 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. CCE-80519-2:Install Smart Card Packages For Multifactor Authentication Using an authentication device, such as a 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 card and the DoD Common Access Card. 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, non-organization-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). Requires further clarification from NIST. Configure the operating system to implement multifactor authentication by installing the required packages with the following command: The esc pam_pkcs11 package can be installed with the following command:
$ sudo yum install esc pam_pkcs11
Applicable - Configurable Verify the operating system implements 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. If it does not, this is a finding. To verify the operating system has the packages required for multifactor authentication installed, run the following command: $ sudo yum list installed esc pam_pkcs11 Is it the case that smartcard software is not installed? Configure the operating system to 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. Configure the operating system to implement multifactor authentication by installing the required packages with the following command: The esc pam_pkcs11 package can be installed with the following command: $ sudo yum install esc pam_pkcs11 medium
CCI-001948 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. CCE-80108-4:Enable the GNOME3 Login Smartcard Authentication Using an authentication device, such as a 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 card and the DoD Common Access Card. 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, non-organization-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). Requires further clarification from NIST. In the default graphical environment, smart card authentication can be enabled on the login screen by setting enable-smartcard-authentication to true.

To enable, add or edit enable-smartcard-authentication to /etc/dconf/db/gdm.d/00-security-settings. For example:
[org/gnome/login-screen]
enable-smartcard-authentication=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/enable-smartcard-authentication
After the settings have been set, run dconf update.
Applicable - Configurable Verify the operating system implements 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. If it does not, this is a finding. To ensure smart card authentication on the login screen is enabled, run the following command: $ grep enable-smartcard-authentication /etc/dconf/db/gdm.d/* The output should be true. To ensure that users cannot disable smart card authentication on the login screen, run the following: $ grep enable-smartcard-authentication /etc/dconf/db/gdm.d/locks/* If properly configured, the output should be /org/gnome/login-screen/enable-smartcard-authentication Is it the case that enable-smartcard-authentication has not been configured or is disabled? Configure the operating system to 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. In the default graphical environment, smart card authentication can be enabled on the login screen by setting enable-smartcard-authentication to true. To enable, add or edit enable-smartcard-authentication to /etc/dconf/db/gdm.d/00-security-settings. For example: [org/gnome/login-screen] enable-smartcard-authentication=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/enable-smartcard-authentication After the settings have been set, run dconf update. medium
CCI-001948 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. CCE-80437-7:Configure PAM in SSSD Services Using an authentication device, such as a 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 card and the DoD Common Access Card. 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, non-organization-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). Requires further clarification from NIST. SSSD should be configured to run SSSD pam services. To configure SSSD to known SSH hosts, add pam to services under the [sssd] section in /etc/sssd/sssd.conf. For example:
[sssd]
services = sudo, autofs, pam
Applicable - Configurable Verify the operating system implements 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. If it does not, this is a finding. To verify that SSSD is configured for PAM services, run the following command: $ sudo grep services /etc/sssd/sssd.conf If configured properly, output should be similar to services = pam Is it the case that it does not exist or 'pam' is not added to the 'services' option under the 'sssd' section? Configure the operating system to 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. SSSD should be configured to run SSSD pam services. To configure SSSD to known SSH hosts, add pam to services under the [sssd] section in /etc/sssd/sssd.conf. For example: [sssd] services = sudo, autofs, pam medium
CCI-002039 SRG-OS-000374-GPOS-00159 TBD - Assigned by DISA after STIG release The operating system must require devices to re-authenticate when changing authenticators. Without re-authentication, devices may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to change device authenticators, it is critical the device re-authenticate.
CCI-002038 SRG-OS-000373-GPOS-00158 TBD - Assigned by DISA after STIG release The operating system must require users to re-authenticate when changing authenticators. CCE-80351-0:Ensure Users Re-Authenticate for Privilege Escalation - sudo NOPASSWD Without re-authentication, users may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to change user authenticators, it is critical the user re-authenticate. The sudo NOPASSWD tag, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the NOPASSWD tag does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. Applicable - Configurable Verify the operating system requires users to re-authenticate when changing authenticators. If it does not, this is a finding. To determine if NOPASSWD has been configured for sudo, run the following command: $ sudo grep -ri nopasswd /etc/sudoers /etc/sudoers.d/ The command should return no output. Is it the case that nopasswd is enabled in sudo? Configure the operating system to require users to re-authenticate when changing authenticators. The sudo NOPASSWD tag, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the NOPASSWD tag does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. medium
CCI-002038 SRG-OS-000373-GPOS-00158 TBD - Assigned by DISA after STIG release The operating system must require users to re-authenticate when changing authenticators. CCE-80350-2:Ensure Users Re-Authenticate for Privilege Escalation - sudo !authenticate Without re-authentication, users may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to change user authenticators, it is critical the user re-authenticate. The sudo !authenticate option, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the !authenticate option does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. Applicable - Configurable Verify the operating system requires users to re-authenticate when changing authenticators. If it does not, this is a finding. To determine if !authenticate has not been configured for sudo, run the following command: $ sudo grep -r \!authenticate /etc/sudoers /etc/sudoers.d/ The command should return no output. Is it the case that !authenticate is enabled in sudo? Configure the operating system to require users to re-authenticate when changing authenticators. The sudo !authenticate option, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the !authenticate option does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. medium
CCI-000879 SRG-OS-000126-GPOS-00066 TBD - Assigned by DISA after STIG release The operating system must terminate all sessions and network connections related to nonlocal maintenance when nonlocal maintenance is completed. CCE-27433-2:Set SSH Idle Timeout Interval If a maintenance session or connection remains open after maintenance is completed, it may be hijacked by an attacker and used to compromise or damage the system. 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. SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out.

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


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.
Applicable - Configurable Verify the operating system terminates all sessions and network connections related to nonlocal maintenance when nonlocal maintenance is completed. If it does not, this is a finding. Run the following command to see what the timeout interval is: $ sudo grep ClientAliveInterval /etc/ssh/sshd_config If properly configured, the output should be: ClientAliveInterval Is it the case that it is commented out or not configured properly? Configure the operating system to terminate all sessions and network connections related to nonlocal maintenance when nonlocal maintenance is completed. SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out. To set an idle timeout interval, edit the following line in /etc/ssh/sshd_config as follows: ClientAliveInterval 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. medium
CCI-002038 SRG-OS-000373-GPOS-00157 TBD - Assigned by DISA after STIG release The operating system must require users to re-authenticate when changing roles. CCE-80351-0:Ensure Users Re-Authenticate for Privilege Escalation - sudo NOPASSWD Without re-authentication, users may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to change security roles, it is critical the user re-authenticate. The sudo NOPASSWD tag, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the NOPASSWD tag does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. Applicable - Configurable Verify the operating system requires users to re-authenticate when changing roles. If it does not, this is a finding. To determine if NOPASSWD has been configured for sudo, run the following command: $ sudo grep -ri nopasswd /etc/sudoers /etc/sudoers.d/ The command should return no output. Is it the case that nopasswd is enabled in sudo? Configure the operating system to require users to re-authenticate when changing roles. The sudo NOPASSWD tag, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the NOPASSWD tag does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. medium
CCI-002038 SRG-OS-000373-GPOS-00157 TBD - Assigned by DISA after STIG release The operating system must require users to re-authenticate when changing roles. CCE-80350-2:Ensure Users Re-Authenticate for Privilege Escalation - sudo !authenticate Without re-authentication, users may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to change security roles, it is critical the user re-authenticate. The sudo !authenticate option, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the !authenticate option does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. Applicable - Configurable Verify the operating system requires users to re-authenticate when changing roles. If it does not, this is a finding. To determine if !authenticate has not been configured for sudo, run the following command: $ sudo grep -r \!authenticate /etc/sudoers /etc/sudoers.d/ The command should return no output. Is it the case that !authenticate is enabled in sudo? Configure the operating system to require users to re-authenticate when changing roles. The sudo !authenticate option, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the !authenticate option does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. medium
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system separates user functionality (including user interface services) from operating system management functionality. If it does not, this is a finding. Configure the operating system to separate user functionality (including user interface services) from operating system management functionality. This requirement is a permanent not a finding. No fix is required. medium
CCI-002038 SRG-OS-000373-GPOS-00156 TBD - Assigned by DISA after STIG release The operating system must require users to re-authenticate for privilege escalation. CCE-80351-0:Ensure Users Re-Authenticate for Privilege Escalation - sudo NOPASSWD Without re-authentication, users may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to escalate a functional capability, it is critical the user re-authenticate. The sudo NOPASSWD tag, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the NOPASSWD tag does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. Applicable - Configurable Verify the operating system requires users to re-authenticate for privilege escalation. If it does not, this is a finding. To determine if NOPASSWD has been configured for sudo, run the following command: $ sudo grep -ri nopasswd /etc/sudoers /etc/sudoers.d/ The command should return no output. Is it the case that nopasswd is enabled in sudo? Configure the operating system to require users to re-authenticate for privilege escalation. The sudo NOPASSWD tag, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the NOPASSWD tag does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. medium
CCI-002038 SRG-OS-000373-GPOS-00156 TBD - Assigned by DISA after STIG release The operating system must require users to re-authenticate for privilege escalation. CCE-80350-2:Ensure Users Re-Authenticate for Privilege Escalation - sudo !authenticate Without re-authentication, users may access resources or perform tasks for which they do not have authorization. When operating systems provide the capability to escalate a functional capability, it is critical the user re-authenticate. The sudo !authenticate option, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the !authenticate option does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. Applicable - Configurable Verify the operating system requires users to re-authenticate for privilege escalation. If it does not, this is a finding. To determine if !authenticate has not been configured for sudo, run the following command: $ sudo grep -r \!authenticate /etc/sudoers /etc/sudoers.d/ The command should return no output. Is it the case that !authenticate is enabled in sudo? Configure the operating system to require users to re-authenticate for privilege escalation. The sudo !authenticate option, when specified, allows a user to execute commands using sudo without having to authenticate. This should be disabled by making sure that the !authenticate option does not exist in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/. medium
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).
CCI-001084 SRG-OS-000134-GPOS-00068 TBD - Assigned by DISA after STIG release The operating system must isolate security functions from nonsecurity functions. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system isolates security functions from nonsecurity functions. If it does not, this is a finding. Configure the operating system to isolate security functions from nonsecurity functions. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-81153-9:Add nosuid Option to /home 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). 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. Applicable - Configurable Verify the operating system prevents 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. If it does not, this is a finding. To verify the nosuid option is configured for the /home mount point, run the following command: $ mount | grep '\s/home\s' The output should show the corresponding mount point along with the nosuid setting in parentheses. Is it the case that the is not present in the output line, or there is no output line at all? Configure the operating system to 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. 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. medium
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. CCE-80153-0:Add noexec Option to /dev/shm 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). 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. Applicable - Configurable Verify the operating system prevents 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. If it does not, this is a finding. To verify the noexec option is configured for the /dev/shm mount point, run the following command: $ mount | grep '\s/dev/shm\s' The output should show the corresponding mount point along with the noexec setting in parentheses. Is it the case that the is not present in the output line, or there is no output line at all? Configure the operating system to 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. 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. medium
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. CCE-80154-8:Add nosuid Option to /dev/shm 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). 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. Applicable - Configurable Verify the operating system prevents 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. If it does not, this is a finding. To verify the nosuid option is configured for the /dev/shm mount point, run the following command: $ mount | grep '\s/dev/shm\s' The output should show the corresponding mount point along with the nosuid setting in parentheses. Is it the case that the is not present in the output line, or there is no output line at all? Configure the operating system to 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. 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. medium
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. CCE-80152-2:Add nodev Option to /dev/shm 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). 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. Applicable - Configurable Verify the operating system prevents 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. If it does not, this is a finding. To verify the nodev option is configured for the /dev/shm mount point, run the following command: $ mount | grep '\s/dev/shm\s' The output should show the corresponding mount point along with the nodev setting in parentheses. Is it the case that the is not present in the output line, or there is no output line at all? Configure the operating system to 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. 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. medium
CCI-001749 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. CCE-26989-4:Ensure gpgcheck Enabled In Main yum Configuration 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. 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
Applicable - Configurable Verify the operating system prevents 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. If it does not, this is a finding. To determine whether yum is configured to use gpgcheck, inspect /etc/yum.conf and ensure the following appears in the [main] section: gpgcheck=1 A value of 1 indicates that gpgcheck is enabled. Absence of a gpgcheck line or a setting of 0 indicates that it is disabled. Is it the case that GPG checking is not enabled? Configure the operating system to 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. 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 high
CCI-001749 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. CCE-80347-8:Ensure gpgcheck Enabled for Local Packages 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. 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. Applicable - Configurable Verify the operating system prevents 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. If it does not, this is a finding. To verify that localpkg_gpgcheck is configured properly, run the following command: $ grep localpkg_gpgcheck /etc/yum.conf The output should return something similar to: localpkg_gpgcheck=1 Is it the case that gpgcheck is not enabled or configured correctly to verify local packages? Configure the operating system to 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. 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. high
CCI-001814 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. CCE-27407-6:Enable auditd Service 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. 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
Applicable - Configurable Verify the operating system audits the enforcement actions used to restrict access associated with changes to the system. If it does not, this is a finding. Run the following command to determine the current status of the auditd service: $ systemctl is-active auditd If the service is running, it should return the following: active Is it the case that ? Configure the operating system to audit the enforcement actions used to restrict access associated with changes to the system. 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 high
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify operating systems prevents unauthorized and unintended information transfer via shared system resources. If it does not, this is a finding. Configure operating systems to prevent unauthorized and unintended information transfer via shared system resources. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-27557-8:Set Interactive Session Timeout 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. Setting the TMOUT option in /etc/profile ensures that all user sessions will terminate based on inactivity. The TMOUT setting in /etc/profile should read as follows:
TMOUT=
Applicable - Configurable Verify the operating system terminates 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. If it does not, this is a finding. Run the following command to ensure the TMOUT value is configured for all users on the system: $ sudo grep TMOUT /etc/profile The output should return the following: TMOUT= Is it the case that value of TMOUT is not less than or equal to expected setting? Configure the operating system to 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. Setting the TMOUT option in /etc/profile ensures that all user sessions will terminate based on inactivity. The TMOUT setting in /etc/profile should read as follows: TMOUT= medium
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. CCE-27082-7:Set SSH Client Alive Max Count 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. To ensure the SSH idle timeout occurs precisely when the ClientAliveInterval is set, edit /etc/ssh/sshd_config as follows:
ClientAliveCountMax 
Applicable - Configurable Verify the operating system terminates 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. If it does not, this is a finding. To ensure the SSH idle timeout will occur when the ClientAliveInterval is set, run the following command: $ sudo grep ClientAliveCountMax /etc/ssh/sshd_config If properly configured, output should be: ClientAliveCountMax Is it the case that it is commented out or not configured properly? Configure the operating system to 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. To ensure the SSH idle timeout occurs precisely when the ClientAliveInterval is set, edit /etc/ssh/sshd_config as follows: ClientAliveCountMax medium
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. CCE-27433-2:Set SSH Idle Timeout Interval 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. SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out.

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


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.
Applicable - Configurable Verify the operating system terminates 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. If it does not, this is a finding. Run the following command to see what the timeout interval is: $ sudo grep ClientAliveInterval /etc/ssh/sshd_config If properly configured, the output should be: ClientAliveInterval Is it the case that it is commented out or not configured properly? Configure the operating system to 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. SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out. To set an idle timeout interval, edit the following line in /etc/ssh/sshd_config as follows: ClientAliveInterval 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. medium
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. CCE-80359-3:Enable FIPS Mode in GRUB2 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. To ensure FIPS mode is enabled, install package dracut-fips, and rebuild initramfs by running the following commands:
$ sudo yum install dracut-fips
dracut -f
After the dracut command has been run, add the argument fips=1 to the default GRUB 2 command line for the Linux operating system in /etc/default/grub, in the manner below:
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 fips=1"
Finally, rebuild the grub.cfg file by using the
grub2-mkconfig -o
command as follows:
  • On BIOS-based machines, issue the following command as root:
    ~]# grub2-mkconfig -o /boot/grub2/grub.cfg
  • On UEFI-based machines, issue the following command as root:
    ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
Applicable - Configurable Verify the operating system protects the confidentiality and integrity of all information at rest. If it does not, this is a finding. To verify that FIPS is enabled properly in grub, run the following command: $ grep fips /etc/default/grub The output should contain fips=1 Is it the case that FIPS is not configured or enabled in grub? Configure the operating system to protect the confidentiality and integrity of all information at rest. To ensure FIPS mode is enabled, install package dracut-fips, and rebuild initramfs by running the following commands: $ sudo yum install dracut-fips dracut -f After the dracut command has been run, add the argument fips=1 to the default GRUB 2 command line for the Linux operating system in /etc/default/grub, in the manner below: GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 fips=1" Finally, rebuild the grub.cfg file by using the grub2-mkconfig -o command as follows: On BIOS-based machines, issue the following command as root: ~]# grub2-mkconfig -o /boot/grub2/grub.cfgOn UEFI-based machines, issue the following command as root: ~]# grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg high
CCI-001233 SRG-OS-000191-GPOS-00080 TBD - Assigned by DISA after STIG release The operating system must employ automated mechanisms to determine the state of system components with regard to flaw remediation using the following frequency: continuously, where HBSS is used; 30 days, for any additional internal network scans not covered by HBSS; and annually, for external scans by Computer Network Defense Service Provider (CNDSP). Without the use of automated mechanisms to scan for security flaws on a continuous and/or periodic basis, the operating system or other system components may remain vulnerable to the exploits presented by undetected software flaws. To support this requirement, the operating system may have an integrated solution incorporating continuous scanning using HBSS and periodic scanning using other tools, as specified in the requirement.
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system reveals error messages only to authorized users. If it does not, this is a finding. Configure the operating system to reveal error messages only to authorized users. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-26970-4:Enable GNOME3 Login Warning Banner 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 read & consent to terms in IS user agreem't." 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.
Applicable - Configurable Verify any publically accessible connection to the operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. 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 read & consent to terms in IS user agreem't." If it does not, this is a finding. To ensure a login warning banner is enabled, run the following: $ grep banner-message-enable /etc/dconf/db/gdm.d/* If properly configured, the output should be true. To ensure a login warning banner is locked and cannot be changed by a user, run the following: $ grep banner-message-enable /etc/dconf/db/gdm.d/locks/* If properly configured, the output should be /org/gnome/login-screen/banner-message-enable. Is it the case that it is not? Configure any publically accessible connection to the operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. 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 read & consent to terms in IS user agreem't." 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. medium
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. CCE-26892-0:Set the GNOME3 Login Warning Banner Text 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 read & consent to terms in IS user agreem't." 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 string '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.
Applicable - Configurable Verify any publically accessible connection to the operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. 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 read & consent to terms in IS user agreem't." If it does not, this is a finding. To ensure the login warning banner text is properly set, run the following: $ grep banner-message-text /etc/dconf/db/gdm.d/* If properly configured, the proper banner text will appear. To ensure the login warning banner text is locked and cannot be changed by a user, run the following: $ grep banner-message-text /etc/dconf/db/gdm.d/locks/* If properly configured, the output should be /org/gnome/login-screen/banner-message-text. Is it the case that it does not? Configure any publically accessible connection to the operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. 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 read & consent to terms in IS user agreem't." 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 string '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. medium
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. CCE-27314-4:Enable SSH Warning Banner 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 read & consent to terms in IS user agreem't." 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.
Applicable - Configurable Verify any publically accessible connection to the operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. 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 read & consent to terms in IS user agreem't." If it does not, this is a finding. To determine how the SSH daemon's Banner option is set, run the following command: $ sudo grep -i Banner /etc/ssh/sshd_config If a line indicating /etc/issue is returned, then the required value is set. Is it the case that the required value is not set? Configure any publically accessible connection to the operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system. 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 read & consent to terms in IS user agreem't." 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. medium
CCI-001403 SRG-OS-000239-GPOS-00089 TBD - Assigned by DISA after STIG release The operating system must audit all account modifications. CCE-80435-1:Record Events that Modify User/Group Information - /etc/passwd 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. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification
Applicable - Configurable Verify the operating system automatically audits account modification. If it does not, this is a finding. To determine if the system is configured to audit account changes, run the following command: auditctl -l | egrep '(/etc/passwd)' If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each). Is it the case that the system is not configured to audit account changes? Configure the operating system to automatically audit account modification. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification medium
CCI-001404 SRG-OS-000240-GPOS-00090 TBD - Assigned by DISA after STIG release The operating system must audit all account disabling actions. CCE-80435-1:Record Events that Modify User/Group Information - /etc/passwd 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. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification
Applicable - Configurable Verify the operating system automatically audits account disabling actions. If it does not, this is a finding. To determine if the system is configured to audit account changes, run the following command: auditctl -l | egrep '(/etc/passwd)' If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each). Is it the case that the system is not configured to audit account changes? Configure the operating system to automatically audit account disabling actions. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification medium
CCI-001404 SRG-OS-000240-GPOS-00090 TBD - Assigned by DISA after STIG release The operating system must audit all account disabling actions. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system automatically audits account disabling actions. If it does not, this is a finding. Configure the operating system to automatically audit account disabling actions. This requirement is a permanent not a finding. No fix is required. medium
CCI-001405 SRG-OS-000241-GPOS-00091 TBD - Assigned by DISA after STIG release The operating system must audit all account removal actions. CCE-80435-1:Record Events that Modify User/Group Information - /etc/passwd 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. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification
Applicable - Configurable Verify the operating system automatically audits account removal actions. If it does not, this is a finding. To determine if the system is configured to audit account changes, run the following command: auditctl -l | egrep '(/etc/passwd)' If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each). Is it the case that the system is not configured to audit account changes? Configure the operating system to automatically audit account removal actions. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification medium
CCI-001405 SRG-OS-000241-GPOS-00091 TBD - Assigned by DISA after STIG release The operating system must audit all account removal actions. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system automatically audits account removal actions. If it does not, this is a finding. Configure the operating system to automatically audit account removal actions. This requirement is a permanent not a finding. No fix is required. medium
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. CCE-27295-5:Use Only FIPS 140-2 Validated Ciphers 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. Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
The man page sshd_config(5) contains a list of supported ciphers.

Only the following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux 7:
- aes128-ctr
- aes192-ctr
- aes256-ctr
- aes128-cbc
- aes192-cbc
- aes256-cbc
- 3des-cbc
- rijndael-cbc@lysator.liu.se

Any combination of the above ciphers will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following ciphers: .
Applicable - Configurable Verify the operating system implements cryptography to protect the integrity of remote access sessions. If it does not, this is a finding. Only FIPS ciphers should be used. To verify that only FIPS-approved ciphers are in use, run the following command: $ sudo grep Ciphers /etc/ssh/sshd_config The output should contain only those ciphers which are FIPS-approved. Is it the case that FIPS ciphers are not configured or the enabled ciphers are not FIPS-approved? Configure the operating system to implement cryptography to protect the integrity of remote access sessions. Limit the ciphers to those algorithms which are FIPS-approved. Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved ciphers: Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc The man page sshd_config(5) contains a list of supported ciphers. Only the following ciphers are FIPS 140-2 certified on Red Hat Enterprise Linux 7: - aes128-ctr - aes192-ctr - aes256-ctr - aes128-cbc - aes192-cbc - aes256-cbc - 3des-cbc - rijndael-cbc@lysator.liu.se Any combination of the above ciphers will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following ciphers: . medium
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. CCE-27455-5:Use Only FIPS 140-2 Validated MACs 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. Limit the MACs to those hash algorithms which are FIPS-approved. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved MACs:
MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1
The man page sshd_config(5) contains a list of supported MACs.

Only the following message authentication codes are FIPS 140-2 certified on Red Hat Enterprise Linux 7:
- hmac-sha1
- hmac-sha2-256
- hmac-sha2-512
- hmac-sha1-etm@openssh.com
- hmac-sha2-256-etm@openssh.com
- hmac-sha2-512-etm@openssh.com

Any combination of the above MACs will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following MACs: .
Applicable - Configurable Verify the operating system implements cryptography to protect the integrity of remote access sessions. If it does not, this is a finding. Only FIPS-approved MACs should be used. To verify that only FIPS-approved MACs are in use, run the following command: $ sudo grep -i macs /etc/ssh/sshd_config The output should contain only those MACs which are FIPS-approved. Any use of other ciphers or algorithms will result in the module entering the non-FIPS mode of operation. Is it the case that MACs option is commented out or not using FIPS-approved hash algorithms? Configure the operating system to implement cryptography to protect the integrity of remote access sessions. Limit the MACs to those hash algorithms which are FIPS-approved. The following line in /etc/ssh/sshd_config demonstrates use of FIPS-approved MACs: MACs hmac-sha2-512,hmac-sha2-256,hmac-sha1 The man page sshd_config(5) contains a list of supported MACs. Only the following message authentication codes are FIPS 140-2 certified on Red Hat Enterprise Linux 7: - hmac-sha1 - hmac-sha2-256 - hmac-sha2-512 - hmac-sha1-etm@openssh.com - hmac-sha2-256-etm@openssh.com - hmac-sha2-512-etm@openssh.com Any combination of the above MACs will pass this check. Official FIPS 140-2 paperwork for Red Hat Enterprise Linux 7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf The rule is parametrized to use the following MACs: . medium
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. CCE-80515-0:Configure SSSD LDAP Backend Client CA Certificate Location 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 SSSD to implement cryptography to protect the integrity of LDAP remote access sessions. By setting the
ldap_tls_cacertdir
option in
/etc/sssd/sssd.conf
to point to the path for the X.509 certificates used for peer authentication.
ldap_tls_cacertdir /path/to/tls/cacert
Applicable - Configurable Verify the operating system implements cryptography to protect the integrity of remote access sessions. If it does not, this is a finding. To verify the operating system implements cryptography to protect the integrity of remote ldap access sessions, run the following command: $ sudo grep ldap_tls_cacertdir /etc/sssd/sssd.conf The output should return the following with a correctly configured CA cert path: ldap_tls_cacertdir /path/to/tls/cacert Is it the case that the TLS CA cert is not configured? Configure the operating system to implement cryptography to protect the integrity of remote access sessions. Configure SSSD to implement cryptography to protect the integrity of LDAP remote access sessions. By setting the ldap_tls_cacertdir option in /etc/sssd/sssd.conf to point to the path for the X.509 certificates used for peer authentication. ldap_tls_cacertdir /path/to/tls/cacert medium
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. CCE-80516-8:Configure SSSD LDAP Backend Client CA Certificate 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 SSSD to implement cryptography to protect the integrity of LDAP remote access sessions. By setting the
ldap_tls_cacert
option in
/etc/sssd/sssd.conf
to point to the path for the X.509 certificates used for peer authentication.
ldap_tls_cacert /path/to/tls/ca.cert
Applicable - Configurable Verify the operating system implements cryptography to protect the integrity of remote access sessions. If it does not, this is a finding. To verify the operating system implements cryptography to protect the integrity of remote ldap access sessions, run the following command: $ sudo grep ldap_tls_cacert /etc/sssd/sssd.conf The output should return the following with a correctly configured CA cert path: ldap_tls_cacert /path/to/tls/ca.cert Is it the case that the TLS CA cert is not configured? Configure the operating system to implement cryptography to protect the integrity of remote access sessions. Configure SSSD to implement cryptography to protect the integrity of LDAP remote access sessions. By setting the ldap_tls_cacert option in /etc/sssd/sssd.conf to point to the path for the X.509 certificates used for peer authentication. ldap_tls_cacert /path/to/tls/ca.cert medium
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. CCE-80546-5:Configure SSSD LDAP Backend to Use TLS For All Transactions 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. This check verifies that Red Hat Enterprise Linux 7 implements cryptography to protect the integrity of remote LDAP authentication sessions.

To determine if LDAP is being used for authentication, use the following command:
$ sudo grep -i useldapauth /etc/sysconfig/authconfig


If USELDAPAUTH=yes, then LDAP is being used. To check if LDAP is configured to use TLS, use the following command:
$ sudo grep -i ldap_id_use_start_tls /etc/sssd/sssd.conf
Applicable - Configurable Verify the operating system implements cryptography to protect the integrity of remote access sessions. If it does not, this is a finding. If the system is not using TLS, set the ldap_id_use_start_tls option in /etc/sssd/sssd.conf to True. Is it the case that the 'ldap_id_use_start_tls' option is not set to 'True'? Configure the operating system to implement cryptography to protect the integrity of remote access sessions. This check verifies that Red Hat Enterprise Linux 7 implements cryptography to protect the integrity of remote LDAP authentication sessions. To determine if LDAP is being used for authentication, use the following command: $ sudo grep -i useldapauth /etc/sysconfig/authconfig If USELDAPAUTH=yes, then LDAP is being used. To check if LDAP is configured to use TLS, use the following command: $ sudo grep -i ldap_id_use_start_tls /etc/sssd/sssd.conf high
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. CCE-27407-6:Enable auditd Service 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. 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
Applicable - Configurable Verify the operating system initiates session audits at system start-up. If it does not, this is a finding. Run the following command to determine the current status of the auditd service: $ systemctl is-active auditd If the service is running, it should return the following: active Is it the case that ? Configure the operating system to initiate session audits at system start-up. 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 high
CCI-001813 SRG-OS-000364-GPOS-00151 TBD - Assigned by DISA after STIG release The operating system must enforce access restrictions. CCE-80517-6:Boot Loader Is Not Installed On Removeable Media 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). The system must not allow removable media to be used as the boot loader. Remove alternate methods of booting the system from removable media. usb0, cd, fd0, etc. are some examples of removeable media which should not exist in the line:
set root='hd0,msdos1'
Applicable - Configurable Verify the operating system enforces access restrictions. If it does not, this is a finding. To verify the system is not configured to use a boot loader on removable media, run the following command: $ sudo grep "set root='hd0" /boot/grub2/grub.cfg The output should return something similar to: set root='hd0,msdos1' usb0, cd, fd0, etc. are some examples of removeable media which should not exist in the line: set root='hd0,msdos1' Is it the case that it is not? Configure the operating system to enforce access restrictions. The system must not allow removable media to be used as the boot loader. Remove alternate methods of booting the system from removable media. usb0, cd, fd0, etc. are some examples of removeable media which should not exist in the line: set root='hd0,msdos1' medium
CCI-001813 SRG-OS-000364-GPOS-00151 TBD - Assigned by DISA after STIG release The operating system must enforce access restrictions. CCE-80221-5:Disable Kerberos Authentication 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). Unless needed, SSH should not permit extraneous or unnecessary authentication mechanisms like Kerberos. To disable Kerberos authentication, add or correct the following line in the /etc/ssh/sshd_config file:
KerberosAuthentication no
Applicable - Configurable Verify the operating system enforces access restrictions. If it does not, this is a finding. To check if KerberosAuthentication is disabled or set correctly, run the following command: $ sudo grep KerberosAuthentication /etc/ssh/sshd_config If configured properly, output should be no Is it the case that it is commented out or is not disabled? Configure the operating system to enforce access restrictions. Unless needed, SSH should not permit extraneous or unnecessary authentication mechanisms like Kerberos. To disable Kerberos authentication, add or correct the following line in the /etc/ssh/sshd_config file: KerberosAuthentication no medium
CCI-001813 SRG-OS-000364-GPOS-00151 TBD - Assigned by DISA after STIG release The operating system must enforce access restrictions. CCE-80220-7:Disable GSSAPI Authentication 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). Unless needed, SSH should not permit extraneous or unnecessary authentication mechanisms like GSSAPI. To disable GSSAPI authentication, add or correct the following line in the /etc/ssh/sshd_config file:
GSSAPIAuthentication no
Applicable - Configurable Verify the operating system enforces access restrictions. If it does not, this is a finding. To check if GSSAPIAuthentication is disabled or set correctly, run the following command: $ sudo grep GSSAPIAuthentication /etc/ssh/sshd_config If configured properly, output should be no Is it the case that it is commented out or is not disabled? Configure the operating system to enforce access restrictions. Unless needed, SSH should not permit extraneous or unnecessary authentication mechanisms like GSSAPI. To disable GSSAPI authentication, add or correct the following line in the /etc/ssh/sshd_config file: GSSAPIAuthentication no medium
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. CCE-27407-6:Enable auditd Service 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. 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
Applicable - Configurable Verify the operating system produces audit records containing information to establish the identity of any individual or process associated with the event. If it does not, this is a finding. Run the following command to determine the current status of the auditd service: $ systemctl is-active auditd If the service is running, it should return the following: active Is it the case that ? Configure the operating system to produce audit records containing information to establish the identity of any individual or process associated with the event. 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 high
CCI-001493 SRG-OS-000256-GPOS-00097 TBD - Assigned by DISA after STIG release The operating system must protect audit tools from unauthorized access. CCE-27209-6:Verify and Correct File Permissions with RPM 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. The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. Verify that the file permissions of system files and commands match vendor values. Check the file permissions with the following command:
$ sudo rpm -Va | awk '{ if (substr($0,2,1)=="M") print $NF }'
Output indicates files that do not match vendor defaults. After locating a file with incorrect permissions, run the following command to determine which package owns it:
$ rpm -qf FILENAME

Next, run the following command to reset its permissions to the correct values:
$ sudo rpm --setperms PACKAGENAME
Applicable - Configurable Verify the operating system protects audit tools from unauthorized access. If it does not, this is a finding. The following command will list which files on the system have permissions different from what is expected by the RPM database: $ rpm -Va | awk '{ if (substr($0,2,1)=="M") print $NF }' Is it the case that there is output? Configure the operating system to protect audit tools from unauthorized access. The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. Verify that the file permissions of system files and commands match vendor values. Check the file permissions with the following command: $ sudo rpm -Va | awk '{ if (substr($0,2,1)=="M") print $NF }' Output indicates files that do not match vendor defaults. After locating a file with incorrect permissions, run the following command to determine which package owns it: $ rpm -qf FILENAME Next, run the following command to reset its permissions to the correct values: $ sudo rpm --setperms PACKAGENAME high
CCI-001494 SRG-OS-000257-GPOS-00098 TBD - Assigned by DISA after STIG release The operating system must protect audit tools from unauthorized modification. CCE-27209-6:Verify and Correct File Permissions with RPM 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. The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. Verify that the file permissions of system files and commands match vendor values. Check the file permissions with the following command:
$ sudo rpm -Va | awk '{ if (substr($0,2,1)=="M") print $NF }'
Output indicates files that do not match vendor defaults. After locating a file with incorrect permissions, run the following command to determine which package owns it:
$ rpm -qf FILENAME

Next, run the following command to reset its permissions to the correct values:
$ sudo rpm --setperms PACKAGENAME
Applicable - Configurable Verify the operating system protects audit tools from unauthorized modification. If it does not, this is a finding. The following command will list which files on the system have permissions different from what is expected by the RPM database: $ rpm -Va | awk '{ if (substr($0,2,1)=="M") print $NF }' Is it the case that there is output? Configure the operating system to protect audit tools from unauthorized modification. The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. Verify that the file permissions of system files and commands match vendor values. Check the file permissions with the following command: $ sudo rpm -Va | awk '{ if (substr($0,2,1)=="M") print $NF }' Output indicates files that do not match vendor defaults. After locating a file with incorrect permissions, run the following command to determine which package owns it: $ rpm -qf FILENAME Next, run the following command to reset its permissions to the correct values: $ sudo rpm --setperms PACKAGENAME high
CCI-001494 SRG-OS-000257-GPOS-00098 TBD - Assigned by DISA after STIG release The operating system must protect audit tools from unauthorized modification. CCE-80545-7:Verify and Correct Ownership with RPM 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. The RPM package management system can check file ownership permissions of installed software packages, including many that are important to system security. After locating a file with incorrect permissions, which can be found with
rpm -Va | awk '{ if (substr($0,6,1)=="U" || substr($0,7,1)=="G") print $NF }'
run the following command to determine which package owns it:
$ rpm -qf FILENAME
Next, run the following command to reset its permissions to the correct values:
$ sudo rpm --setugids PACKAGENAME
Applicable - Configurable Verify the operating system protects audit tools from unauthorized modification. If it does not, this is a finding. The following command will list which files on the system have ownership different from what is expected by the RPM database: $ rpm -Va | rpm -Va --nofiledigest | awk '{ if (substr($0,6,1)=="U" || substr($0,7,1)=="G") print $NF }' Is it the case that there is output? Configure the operating system to protect audit tools from unauthorized modification. The RPM package management system can check file ownership permissions of installed software packages, including many that are important to system security. After locating a file with incorrect permissions, which can be found with rpm -Va | awk '{ if (substr($0,6,1)=="U" || substr($0,7,1)=="G") print $NF }' run the following command to determine which package owns it: $ rpm -qf FILENAME Next, run the following command to reset its permissions to the correct values: $ sudo rpm --setugids PACKAGENAME high
CCI-001495 SRG-OS-000258-GPOS-00099 TBD - Assigned by DISA after STIG release The operating system must protect audit tools from unauthorized deletion. CCE-27209-6:Verify and Correct File Permissions with RPM 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. The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. Verify that the file permissions of system files and commands match vendor values. Check the file permissions with the following command:
$ sudo rpm -Va | awk '{ if (substr($0,2,1)=="M") print $NF }'
Output indicates files that do not match vendor defaults. After locating a file with incorrect permissions, run the following command to determine which package owns it:
$ rpm -qf FILENAME

Next, run the following command to reset its permissions to the correct values:
$ sudo rpm --setperms PACKAGENAME
Applicable - Configurable Verify the operating system protects audit tools from unauthorized deletion. If it does not, this is a finding. The following command will list which files on the system have permissions different from what is expected by the RPM database: $ rpm -Va | awk '{ if (substr($0,2,1)=="M") print $NF }' Is it the case that there is output? Configure the operating system to protect audit tools from unauthorized deletion. The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. Verify that the file permissions of system files and commands match vendor values. Check the file permissions with the following command: $ sudo rpm -Va | awk '{ if (substr($0,2,1)=="M") print $NF }' Output indicates files that do not match vendor defaults. After locating a file with incorrect permissions, run the following command to determine which package owns it: $ rpm -qf FILENAME Next, run the following command to reset its permissions to the correct values: $ sudo rpm --setperms PACKAGENAME high
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. CCE-27096-7:Install AIDE 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. The aide package can be installed with the following command:
$ sudo yum install aide
Applicable - Configurable Verify the operating system notifies designated personnel if baseline configurations are changed in an unauthorized manner. If it does not, this is a finding. Run the following command to determine if the aide package is installed: $ rpm -q aide Is it the case that the package is not installed? Configure the operating system to notify designated personnel if baseline configurations are changed in an unauthorized manner. The aide package can be installed with the following command: $ sudo yum install aide medium
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. CCE-26952-2:Configure Periodic Execution of AIDE 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. At a minimum, AIDE should be configured to run a weekly scan. To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab:
05 4 * * * root /usr/sbin/aide --check
To implement a weekly execution of AIDE at 4:05am using cron, add the following line to /etc/crontab:
05 4 * * 0 root /usr/sbin/aide --check
AIDE can be executed periodically through other means; this is merely one example. The usage of cron's special time codes, such as @daily and @weekly is acceptable.
Applicable - Configurable Verify the operating system notifies designated personnel if baseline configurations are changed in an unauthorized manner. If it does not, this is a finding. To determine that periodic AIDE execution has been scheduled, run the following command: $ grep aide /etc/crontab The output should return something similar to the following: 05 4 * * * root /usr/sbin/aide --check NOTE: The usage of special cron times, such as @daily or @weekly, is acceptable. Is it the case that there is no output? Configure the operating system to notify designated personnel if baseline configurations are changed in an unauthorized manner. At a minimum, AIDE should be configured to run a weekly scan. To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab: 05 4 * * * root /usr/sbin/aide --check To implement a weekly execution of AIDE at 4:05am using cron, add the following line to /etc/crontab: 05 4 * * 0 root /usr/sbin/aide --check AIDE can be executed periodically through other means; this is merely one example. The usage of cron's special time codes, such as @daily and @weekly is acceptable. medium
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. CCE-80374-2:Configure Notification of Post-AIDE Scan Details 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. 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.
Applicable - Configurable Verify the operating system notifies designated personnel if baseline configurations are changed in an unauthorized manner. If it does not, this is a finding. To determine that periodic AIDE execution has been scheduled, run the following command: $ grep aide /etc/crontab The output should return something similar to the following: 05 4 * * * root /usr/sbin/aide --check | /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost Is it the case that AIDE has not been configured or has not been configured to notify personnel of scan details? Configure the operating system to notify designated personnel if baseline configurations are changed in an unauthorized manner. 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. medium
CCI-001812 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-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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify the operating system limits privileges to change software resident within software libraries. If it does not, this is a finding. Configure the operating system to limit privileges to change software resident within software libraries. This requirement is a permanent not a finding. No fix is required. medium
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-001619 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. CCE-27360-7:Ensure PAM Enforces Password Requirements - Minimum Special Characters 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: ~ ! @ # $ % ^ *. 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. Applicable - Configurable Verify the operating system enforces password complexity by requiring that at least one special character be used. If it does not, this is a finding. To check how many special characters are required in a password, run the following command: $ grep ocredit /etc/security/pwquality.conf The ocredit parameter (as a negative number) will indicate how many special characters are required. The DoD and FISMA require at least one special character in a password. This would appear as ocredit = -1. Is it the case that ocredit is not found or not equal to or less than the required value? Configure the operating system to enforce password complexity by requiring that at least one special character be used. 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. medium
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.
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. Product Meets this Requirement 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. This requirement is a permanent not a finding. No fix is required. Applicable - Inherently Meets Verify, in the event of a system failure, the operating system preserves any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to mission processes. If it does not, this is a finding. Configure the operating system to preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to mission processes, in the event of a system failure. This requirement is a permanent not a finding. No fix is required. medium
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.
CCI-001683 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. CCE-80435-1:Record Events that Modify User/Group Information - /etc/passwd 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. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification
Applicable - Configurable Verify the operating system notifies System Administrators and Information System Security Officers when accounts are created. If it does not, this is a finding. To determine if the system is configured to audit account changes, run the following command: auditctl -l | egrep '(/etc/passwd)' If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each). Is it the case that the system is not configured to audit account changes? Configure the operating system to notify System Administrators and Information System Security Officers when accounts are created. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification medium
CCI-001684 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. CCE-80435-1:Record Events that Modify User/Group Information - /etc/passwd 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. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification
Applicable - Configurable Verify the operating system notifies System Administrators and Information System Security Officers when accounts are modified. If it does not, this is a finding. To determine if the system is configured to audit account changes, run the following command: auditctl -l | egrep '(/etc/passwd)' If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each). Is it the case that the system is not configured to audit account changes? Configure the operating system to notify System Administrators and Information System Security Officers when accounts are modified. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification medium
CCI-001685 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. CCE-80435-1:Record Events that Modify User/Group Information - /etc/passwd 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. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification
Applicable - Configurable Verify the operating system notifies System Administrators and Information System Security Officers when accounts are disabled. If it does not, this is a finding. To determine if the system is configured to audit account changes, run the following command: auditctl -l | egrep '(/etc/passwd)' If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each). Is it the case that the system is not configured to audit account changes? Configure the operating system to notify System Administrators and Information System Security Officers when accounts are disabled. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification medium
CCI-001686 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. CCE-80435-1:Record Events that Modify User/Group Information - /etc/passwd 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. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification
Applicable - Configurable Verify the operating system notifies System Administrators and Information System Security Officers for account removal actions. If it does not, this is a finding. To determine if the system is configured to audit account changes, run the following command: auditctl -l | egrep '(/etc/passwd)' If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each). Is it the case that the system is not configured to audit account changes? Configure the operating system to notify System Administrators and Information System Security Officers for account removal actions. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification medium
CCI-002046 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. CCE-80439-3:Configure Time Service Maxpoll Interval 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. The maxpoll should be configured to in /etc/ntp.conf or /etc/chrony.conf to continuously poll time servers. To configure maxpoll in /etc/ntp.conf or /etc/chrony.conf add the following:
maxpoll 
Applicable - Configurable Verify the operating system synchronizes internal information system clocks to the authoritative time source when the time difference is greater than one second. If it does not, this is a finding. To verify that maxpoll has been set properly, perform the following: $ sudo grep maxpoll /etc/ntp.conf /etc/chrony.conf The output should return maxpoll . Is it the case that it does not exist or maxpoll has not been set to the expected value? Configure the operating system to synchronize internal information system clocks to the authoritative time source when the time difference is greater than the organization-defined time period. The maxpoll should be configured to in /etc/ntp.conf or /etc/chrony.conf to continuously poll time servers. To configure maxpoll in /etc/ntp.conf or /etc/chrony.conf add the following: maxpoll medium
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. CCE-27209-6:Verify and Correct File Permissions with RPM 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. The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. Verify that the file permissions of system files and commands match vendor values. Check the file permissions with the following command:
$ sudo rpm -Va | awk '{ if (substr($0,2,1)=="M") print $NF }'
Output indicates files that do not match vendor defaults. After locating a file with incorrect permissions, run the following command to determine which package owns it:
$ rpm -qf FILENAME

Next, run the following command to reset its permissions to the correct values:
$ sudo rpm --setperms PACKAGENAME
Applicable - Configurable Verify the operating system uses cryptographic mechanisms to protect the integrity of audit tools. If it does not, this is a finding. The following command will list which files on the system have permissions different from what is expected by the RPM database: $ rpm -Va | awk '{ if (substr($0,2,1)=="M") print $NF }' Is it the case that there is output? Configure the operating system to use cryptographic mechanisms to protect the integrity of audit tools. The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. Verify that the file permissions of system files and commands match vendor values. Check the file permissions with the following command: $ sudo rpm -Va | awk '{ if (substr($0,2,1)=="M") print $NF }' Output indicates files that do not match vendor defaults. After locating a file with incorrect permissions, run the following command to determine which package owns it: $ rpm -qf FILENAME Next, run the following command to reset its permissions to the correct values: $ sudo rpm --setperms PACKAGENAME high
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. CCE-80545-7:Verify and Correct Ownership with RPM 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. The RPM package management system can check file ownership permissions of installed software packages, including many that are important to system security. After locating a file with incorrect permissions, which can be found with
rpm -Va | awk '{ if (substr($0,6,1)=="U" || substr($0,7,1)=="G") print $NF }'
run the following command to determine which package owns it:
$ rpm -qf FILENAME
Next, run the following command to reset its permissions to the correct values:
$ sudo rpm --setugids PACKAGENAME
Applicable - Configurable Verify the operating system uses cryptographic mechanisms to protect the integrity of audit tools. If it does not, this is a finding. The following command will list which files on the system have ownership different from what is expected by the RPM database: $ rpm -Va | rpm -Va --nofiledigest | awk '{ if (substr($0,6,1)=="U" || substr($0,7,1)=="G") print $NF }' Is it the case that there is output? Configure the operating system to use cryptographic mechanisms to protect the integrity of audit tools. The RPM package management system can check file ownership permissions of installed software packages, including many that are important to system security. After locating a file with incorrect permissions, which can be found with rpm -Va | awk '{ if (substr($0,6,1)=="U" || substr($0,7,1)=="G") print $NF }' run the following command to determine which package owns it: $ rpm -qf FILENAME Next, run the following command to reset its permissions to the correct values: $ sudo rpm --setugids PACKAGENAME high
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. CCE-27082-7:Set SSH Client Alive Max Count 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. To ensure the SSH idle timeout occurs precisely when the ClientAliveInterval is set, edit /etc/ssh/sshd_config as follows:
ClientAliveCountMax 
Applicable - Configurable Verify the operating system automatically terminates a user session after inactivity time-outs have expired or at shutdown. If it does not, this is a finding. To ensure the SSH idle timeout will occur when the ClientAliveInterval is set, run the following command: $ sudo grep ClientAliveCountMax /etc/ssh/sshd_config If properly configured, output should be: ClientAliveCountMax Is it the case that it is commented out or not configured properly? Configure the operating system to automatically terminate a user session after inactivity time-outs have expired or at shutdown. To ensure the SSH idle timeout occurs precisely when the ClientAliveInterval is set, edit /etc/ssh/sshd_config as follows: ClientAliveCountMax medium
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. CCE-27433-2:Set SSH Idle Timeout Interval 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. SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out.

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


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.
Applicable - Configurable Verify the operating system automatically terminates a user session after inactivity time-outs have expired or at shutdown. If it does not, this is a finding. Run the following command to see what the timeout interval is: $ sudo grep ClientAliveInterval /etc/ssh/sshd_config If properly configured, the output should be: ClientAliveInterval Is it the case that it is commented out or not configured properly? Configure the operating system to automatically terminate a user session after inactivity time-outs have expired or at shutdown. SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out. To set an idle timeout interval, edit the following line in /etc/ssh/sshd_config as follows: ClientAliveInterval 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. medium
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. CCE-80447-6:Configure the Firewalld Ports 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 to allow approved services to have access to the system. To configure firewalld to open ports, run the following command:
$ sudo firewall-cmd --permanent --add-port=port_number/tcp
or
$ sudo firewall-cmd --permanent --add-port=service_name
Run the command list above for each of the ports listed below: To configure firewalld to allow access, run the following command(s): firewall-cmd --permanent --add-service=ssh
Applicable - Configurable Verify the operating system controls remote access methods. If it does not, this is a finding. Inspect the list of enabled firewall ports and verify they are configured correctly by running the following command: $ sudo firewall-cmd --list-all Is it the case that the default rules are not configured? Configure the operating system to control remote access methods. Configure the firewalld ports to allow approved services to have access to the system. To configure firewalld to open ports, run the following command: $ sudo firewall-cmd --permanent --add-port=port_number/tcp or $ sudo firewall-cmd --permanent --add-port=service_name Run the command list above for each of the ports listed below: To configure firewalld to allow access, run the following command(s): firewall-cmd --permanent --add-service=ssh medium
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.
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.
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.
CCI-002130 SRG-OS-000303-GPOS-00120 TBD - Assigned by DISA after STIG release The operating system must audit all account enabling actions. CCE-80435-1:Record Events that Modify User/Group Information - /etc/passwd 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. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification
Applicable - Configurable Verify the operating system automatically audits account enabling actions. If it does not, this is a finding. To determine if the system is configured to audit account changes, run the following command: auditctl -l | egrep '(/etc/passwd)' If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each). Is it the case that the system is not configured to audit account changes? Configure the operating system to automatically audit account enabling actions. 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/passwd -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/passwd -p wa -k audit_rules_usergroup_modification medium
CCI-002132 SRG-OS-000304-GPOS-00121 TBD - Assigned by DISA after STIG release The operating system must notify system administrators and 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 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. In order 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.
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.
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. 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-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 non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. CCE-27511-5:Disable Ctrl-Alt-Del Reboot Activation 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. 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
or
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.
Applicable - Configurable Verify that the operating system prevents non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. If it does not, this is a finding. To ensure the system is configured to mask the Ctrl-Alt-Del sequence, enter the following command: $ sudo ln -sf /dev/null /etc/systemd/system/ctrl-alt-del.target or $ sudo systemctl mask ctrl-alt-del.target Is it the case that the system is configured to reboot when Ctrl-Alt-Del is pressed? Configure the operating system to prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. 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 or 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. high
CCI-002235 SRG-OS-000324-GPOS-00125 TBD - Assigned by DISA after STIG release The operating system must prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. CCE-80543-2:Map System Users To The Appropriate SELinux Role 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. 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
or
$ 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
Applicable - Configurable Verify that the operating system prevents non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. If it does not, this is a finding. To verify the operating system prevents non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures, run the following command: $ sudo semanage login -l All administrators must be mapped to the sysadm_u or staff_u users with the appropriate domains (sysadm_t and staff_t). All authorized non-administrative users must be mapped to the user_u role or the appropriate domain (user_t). Is it the case that non-admin users are not confined correctly? Configure the operating system to prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures. 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 or $ 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 medium
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.
CCI-002234 SRG-OS-000327-GPOS-00127 TBD - Assigned by DISA after STIG release The operating system must audit the execution of privileged functions. CCE-27437-3:Ensure auditd Collects Information on the Use of Privileged Commands 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. At a minimum, the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid / setgid programs, run the following command for each local partition PART:
$ sudo find PART -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/null
If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d for each setuid / setgid program on the system, replacing the SETUID_PROG_PATH part with the full path of that setuid / setgid program in the list:
-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules for each setuid / setgid program on the system, replacing the SETUID_PROG_PATH part with the full path of that setuid / setgid program in the list:
-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
Applicable - Configurable Verify that the operating system audits the execution of privileged functions. If it does not, this is a finding. To verify that auditing of privileged command use is configured, run the following command for each local partition PART to find relevant setuid / setgid programs: $ sudo find PART -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/null Run the following command to verify entries in the audit rules for all programs found with the previous command: $ sudo grep path /etc/audit/audit.rules It should be the case that all relevant setuid / setgid programs have a line in the audit rules. Is it the case that it is not the case? Configure the operating system to audit the execution of privileged functions. At a minimum, the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid / setgid programs, run the following command for each local partition PART: $ sudo find PART -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/null If the auditd daemon is configured to use the augenrules program to read audit rules during daemon startup (the default), add a line of the following form to a file with suffix .rules in the directory /etc/audit/rules.d for each setuid / setgid program on the system, replacing the SETUID_PROG_PATH part with the full path of that setuid / setgid program in the list: -a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes If the auditd daemon is configured to use the auditctl utility to read audit rules during daemon startup, add a line of the following form to /etc/audit/audit.rules for each setuid / setgid program on the system, replacing the SETUID_PROG_PATH part with the full path of that setuid / setgid program in the list: -a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes medium
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. CCE-26884-7:Set Lockout Time for Failed Password Attempts 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. To configure the system to lock out accounts after a number of incorrect login attempts and require an administrator to unlock the account using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

  • add the following line immediately before the pam_unix.so statement in the AUTH section:
    auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval=
  • add the following line immediately after the pam_unix.so statement in the AUTH section:
    auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval=
  • add the following line immediately before the pam_unix.so statement in the ACCOUNT section:
    account required pam_faillock.so
If unlock_time is set to 0, manual intervention by an administrator is required to unlock a user.
Applicable - Configurable Verify the operating system automatically locks an account until the locked account is released by an administrator when three unsuccessful logon attempts in 15 minutes are made. If it does not, this is a finding. To ensure the failed password attempt policy is configured correctly, run the following command: $ grep pam_faillock /etc/pam.d/system-auth The output should show unlock_time=<some-large-number> or 0 for never. Is it the case that unlock_time is less than the expected value? Configure the operating system to automatically lock an account until the locked account is released by an administrator when three unsuccessful logon attempts in 15 minutes are made. To configure the system to lock out accounts after a number of incorrect login attempts and require an administrator to unlock the account using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows: add the following line immediately before the pam_unix.so statement in the AUTH section: auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval= add the following line immediately after the pam_unix.so statement in the AUTH section: auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval= add the following line immediately before the pam_unix.so statement in the ACCOUNT section: account required pam_faillock.so If unlock_time is set to 0, manual intervention by an administrator is required to unlock a user. medium
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. CCE-27297-1:Set Interval For Counting Failed Password Attempts 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. 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. Modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

  • Add the following line immediately before the pam_unix.so statement in the AUTH section:
    auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval=
  • Add the following line immediately after the pam_unix.so statement in the AUTH section:
    auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval=
    
  • Add the following line immediately before the pam_unix.so statement in the ACCOUNT section:
    account required pam_faillock.so
Applicable - Configurable Verify the operating system automatically locks an account until the locked account is released by an administrator when three unsuccessful logon attempts in 15 minutes are made. If it does not, this is a finding. To ensure the failed password attempt policy is configured correctly, run the following command: $ grep pam_faillock /etc/pam.d/system-auth /etc/pam.d/password-auth For each file, the output should show fail_interval=<interval-in-seconds> where interval-in-seconds is or greater. If the fail_interval parameter is not set, the default setting of 900 seconds is acceptable. Is it the case that fail_interval is less than the required value? Configure the operating system to automatically lock an account until the locked account is released by an administrator when three unsuccessful logon attempts in 15 minutes are made. 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. Modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows: Add the following line immediately before the pam_unix.so statement in the AUTH section: auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval= Add the following line immediately after the pam_unix.so statement in the AUTH section: auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval= Add the following line immediately before the pam_unix.so statement in the ACCOUNT section: account required pam_faillock.so medium
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. CCE-80353-6:Configure the root Account for Failed Password Attempts 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. To configure the system to lock out the root account after a number of incorrect login attempts using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

  • Modify the following line in the AUTH section to add even_deny_root:
    auth required pam_faillock.so preauth silent even_deny_root deny= unlock_time= fail_interval=
  • Modify the following line in the AUTH section to add even_deny_root:
    auth [default=die] pam_faillock.so authfail even_deny_root deny= unlock_time= fail_interval=
Applicable - Configurable Verify the operating system automatically locks an account until the locked account is released by an administrator when three unsuccessful logon attempts in 15 minutes are made. If it does not, this is a finding. To ensure that even the root account is locked after a defined number of failed password attempts, run the following command: $ grep even_deny_root /etc/pam.d/system-auth The output should show even_deny_root. Is it the case that that is not the case? Configure the operating system to automatically lock an account until the locked account is released by an administrator when three unsuccessful logon attempts in 15 minutes are made. To configure the system to lock out the root account after a number of incorrect login attempts using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows: Modify the following line in the AUTH section to add even_deny_root: auth required pam_faillock.so preauth silent even_deny_root deny= unlock_time= fail_interval=Modify the following line in the AUTH section to add even_deny_root: auth [default=die] pam_faillock.so authfail even_deny_root deny= unlock_time= fail_interval= medium
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. CCE-27350-8:Set Deny For Failed Password Attempts 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. To configure the system to lock out accounts after a number of incorrect login attempts using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:

  • add the following line immediately before the pam_unix.so statement in the AUTH section:
    auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval=
  • add the following line immediately after the pam_unix.so statement in the AUTH section:
    auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval=
  • add the following line immediately before the pam_unix.so statement in the ACCOUNT section:
    account required pam_faillock.so
Applicable - Configurable Verify the operating system automatically locks an account until the locked account is released by an administrator when three unsuccessful logon attempts in 15 minutes are made. If it does not, this is a finding. To ensure the failed password attempt policy is configured correctly, run the following command: $ grep pam_faillock /etc/pam.d/system-auth The output should show deny=. Is it the case that that is not the case? Configure the operating system to automatically lock an account until the locked account is released by an administrator when three unsuccessful logon attempts in 15 minutes are made. To configure the system to lock out accounts after a number of incorrect login attempts using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows: add the following line immediately before the pam_unix.so statement in the AUTH section: auth required pam_faillock.so preauth silent deny= unlock_time= fail_interval= add the following line immediately after the pam_unix.so statement in the AUTH section: auth [default=die] pam_faillock.so authfail deny= unlock_time= fail_interval= add the following line immediately before the pam_unix.so statement in the ACCOUNT section: account required pam_faillock.so medium
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.
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 weeks worth of audit records, when audit records are not immediately sent to a central audit record storage facility. CCE-82035-7:Ensure /var/log/audit Located On Separate Partition 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. Audit logs are stored in the /var/log/audit directory. Ensure that it has its own partition or logical volume at installation time, or migrate it later using LVM. Make absolutely certain that it is large enough to store all audit logs that will be created by the auditing daemon. Applicable - Configurable Verify the operating system allocates 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. If it does not, this is a finding. Run the following command to determine if /var/log/audit is on its own partition or logical volume: $ mount | grep "on /var/log/audit" If /var/log/audit has its own partition or volume group, a line will be returned. Is it the case that no line is returned? Configure the operating system to 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. Audit logs are stored in the /var/log/audit directory. Ensure that it has its own partition or logical volume at installation time, or migrate it later using LVM. Make absolutely certain that it is large enough to store all audit logs that will be created by the auditing daemon. low
CCI-001851 SRG-OS-000342-GPOS-00133 TBD - Assigned by DISA after STIG release The operating system must off-load audit records onto a different system or media from the system being audited. CCE-80541-6:Configure audispd Plugin To Send Logs To Remote Server 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 the audispd plugin to off-load audit records onto a different system or media from the system being audited. Set the remote_server option in
/etc/audisp/audisp-remote.conf
with an IP address or hostname of the system that the audispd plugin should send audit records to. For example
remote_server = 
Applicable - Configurable Verify the operating system off-loads audit records onto a different system or media from the system being audited. If it does not, this is a finding. To verify the audispd plugin off-loads audit records onto a different system or media from the system being audited, run the following command: $ sudo grep -i remote_server /etc/audisp/audisp-remote.conf The output should return something similar to remote_server = Is it the case that audispd is not sending logs to a remote system? Configure the operating system to off-load audit records onto a different system or media from the system being audited. Configure the audispd plugin to off-load audit records onto a different system or media from the system being audited. Set the remote_server option in /etc/audisp/audisp-remote.conf with an IP address or hostname of the system that the audispd plugin should send audit records to. For example remote_server = medium
CCI-001851 SRG-OS-000342-GPOS-00133 TBD - Assigned by DISA after STIG release The operating system must off-load audit records onto a different system or media from the system being audited. CCE-80539-0:Configure audispd's Plugin disk_full_action When Disk Is Full 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 the action the operating system takes if the disk the audit records are written to becomes full. Edit the file /etc/audisp/audisp-remote.conf. Add or modify the following line, substituting ACTION appropriately:
disk_full_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 and halt. For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined.
Applicable - Configurable Verify the operating system off-loads audit records onto a different system or media from the system being audited. If it does not, this is a finding. Inspect /etc/audisp/audisp-remote.conf and locate the following line to determine if the system is configured to either send to syslog, switch to single user mode, or halt when the disk is full: grep -i disk_full_action /etc/audisp/audisp-remote.conf The output should return something similar to: disk_full_action = single Acceptable values also include syslog and halt. Is it the case that the system is not configured to switch to single user mode for corrective action? Configure the operating system to off-load audit records onto a different system or media from the system being audited. Configure the action the operating system takes if the disk the audit records are written to becomes full. Edit the file /etc/audisp/audisp-remote.conf. Add or modify the following line, substituting ACTION appropriately: disk_full_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 and halt. For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined. medium
CCI-001851 SRG-OS-000342-GPOS-00133 TBD - Assigned by DISA after STIG release The operating system must off-load audit records onto a different system or media from the system being audited. CCE-80540-8:Encrypt Audit Records Sent With audispd Plugin 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 the operating system to encrypt the transfer of off-loaded audit records onto a different system or media from the system being audited. Uncomment the enable_krb5 option in
/etc/audisp/audisp-remote.conf
, and set it with the following line:
enable_krb5 = yes
Applicable - Configurable Verify the operating system off-loads audit records onto a different system or media from the system being audited. If it does not, this is a finding. To verify the audispd plugin encrypts audit records off-loaded onto a different system or media from the system being audited, run the following command: $ sudo grep -i enable_krb5 /etc/audisp/audisp-remote.conf The output should return the following: enable_krb5 = yes Is it the case that audispd is not encrypting audit records when sent over the network? Configure the operating system to off-load audit records onto a different system or media from the system being audited. Configure the operating system to encrypt the transfer of off-loaded audit records onto a different system or media from the system being audited. Uncomment the enable_krb5 option in /etc/audisp/audisp-remote.conf, and set it with the following line: enable_krb5 = yes medium
CCI-001851 SRG-OS-000342-GPOS-00133 TBD - Assigned by DISA after STIG release The operating system must off-load audit records onto a different system or media from the system being audited. CCE-80538-2:Configure audispd's Plugin network_failure_action On Network Failure 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 the action the operating system takes if there is an error sending audit records to a remote system. Edit the file /etc/audisp/audisp-remote.conf. Add or modify the following line, substituting ACTION appropriately:
network_failure_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 and halt. For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined.
Applicable - Configurable Verify the operating system off-loads audit records onto a different system or media from the system being audited. If it does not, this is a finding. Inspect /etc/audisp/audisp-remote.conf and locate the following line to determine if the system is configured to either send to syslog, switch to single user mode, or halt when there is a network failure with audispd: grep -i network_failure_action /etc/audisp/audisp-remote.conf The output should return something similar to: network_failure_action = single Acceptable values also include syslog and halt. Is it the case that the system is not configured to switch to single user mode for corrective action? Configure the operating system to off-load audit records onto a different system or media from the system being audited. Configure the action the operating system takes if there is an error sending audit records to a remote system. Edit the file /etc/audisp/audisp-remote.conf. Add or modify the following line, substituting ACTION appropriately: network_failure_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 and halt. For certain systems, the need for availability outweighs the need to log all actions, and a different setting should be determined. medium
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% of the repository maximum audit record storage capacity. CCE-27394-6:Configure auditd mail_acct Action on Low Disk Space If security personnel are not notified immediately when storage volume reaches 75% utilization, they are unable to plan for audit record storage capacity expansion. 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 = 
Applicable - Configurable Verify the operating system immediately notifies the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75% of the repository maximum audit record storage capacity. If it does not, this is a finding. Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured to send email to an account when it needs to notify an administrator: action_mail_acct = root Is it the case that auditd is not configured to send emails per identified actions? Configure the operating system to immediately notify the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75% of the repository maximum audit record storage capacity. 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 = medium
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% of the repository maximum audit record storage capacity. CCE-80537-4:Configure auditd space_left on Low Disk Space If security personnel are not notified immediately when storage volume reaches 75% utilization, they are unable to plan for audit record storage capacity expansion. 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 SIZE_in_MB appropriately:
space_left = SIZE_in_MB
Set this value to the appropriate size in Megabytes cause the system to notify the user of an issue.
Applicable - Configurable Verify the operating system immediately notifies the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75% of the repository maximum audit record storage capacity. If it does not, this is a finding. Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured correctly: space_left SIZE_in_MB Is it the case that the system is not configured a specfic size in MB to notify administrators of an issue? Configure the operating system to immediately notify the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75% of the repository maximum audit record storage capacity. 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 SIZE_in_MB appropriately: space_left = SIZE_in_MB Set this value to the appropriate size in Megabytes cause the system to notify the user of an issue. medium
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% of the repository maximum audit record storage capacity. CCE-27375-5:Configure auditd space_left Action on Low Disk Space If security personnel are not notified immediately when storage volume reaches 75% utilization, they are unable to plan for audit record storage capacity expansion. 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.
Applicable - Configurable Verify the operating system immediately notifies the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75% of the repository maximum audit record storage capacity. If it does not, this is a finding. Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured to email the administrator when disk space is starting to run low: $ sudo grep space_left_action /etc/audit/auditd.conf space_left_action Acceptable values are email, suspend, single, and halt. Is it the case that the system is not configured to send an email to the system administrator when disk space is starting to run low? Configure the operating system to immediately notify the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75% of the repository maximum audit record storage capacity. 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: syslogemailexecsuspendsinglehalt 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. medium
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.
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.
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.
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.
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.
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.
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.
CCI-001891 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). CCE-80439-3:Configure Time Service Maxpoll Interval 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). The maxpoll should be configured to in /etc/ntp.conf or /etc/chrony.conf to continuously poll time servers. To configure maxpoll in /etc/ntp.conf or /etc/chrony.conf add the following:
maxpoll 
Applicable - Configurable Verify the operating system, for networked systems, compares 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). If it does not, this is a finding. To verify that maxpoll has been set properly, perform the following: $ sudo grep maxpoll /etc/ntp.conf /etc/chrony.conf The output should return maxpoll . Is it the case that it does not exist or maxpoll has not been set to the expected value? Configure the operating system to, 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). The maxpoll should be configured to in /etc/ntp.conf or /etc/chrony.conf to continuously poll time servers. To configure maxpoll in /etc/ntp.conf or /etc/chrony.conf add the following: maxpoll medium
CCI-002418 SRG-OS-000481-GPOS-000481 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.