Cyber · Trackr The Free Compliance Library
⌘K
DoD Compliance · STIG

Tri-Lab Operating System Stack (TOSS) 4 Security Technical Implementation Guide

V2R1 · · · Released 24 Jul 2024 · 226 rules
Compare

Pick two releases to diff their requirements.

View

Open a previous version of this STIG.

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DOD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.
Digest of Updates vs. V1R3 · 24 Jan 2024 −1 ✎ 15

Comparison against the immediately-prior release (V1R3). Rule matching uses the Group Vuln ID. Content-change detection compares the rule’s description, check, and fix text after stripping inline markup — cosmetic-only edits aren’t flagged.

Removed rules 1

  • V-253068 Medium TOSS must prohibit password reuse for a minimum of five generations.

Content changes 15

  • V-252912 Medium checkfix TOSS, for PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.
  • V-252915 Medium check TOSS must not permit direct logons to the root account using remote access from outside of the system via SSH.
  • V-252928 Medium descriptioncheckfix TOSS 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).
  • V-252930 High description TOSS 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.
  • V-252931 Medium descriptioncheckfix TOSS must require reauthentication when using the "sudo" command.
  • V-252932 Medium description TOSS must have the packages required for multifactor authentication installed.
  • V-252952 Medium description TOSS must use multifactor authentication for network and local access to privileged and nonprivileged accounts.
  • V-252953 Medium fix TOSS must disable account identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.
  • V-252958 Medium description TOSS must require users to reauthenticate for privilege escalation.
  • V-252959 Medium check TOSS must require users to provide a password for privilege escalation.
  • V-253061 Medium descriptionfix TOSS must enforce password complexity by requiring that at least one lowercase character be used.
  • V-253064 Medium description TOSS must store only encrypted representations of passwords.
  • V-253066 Medium checkfix TOSS must enforce 24 hours/one day as the minimum password lifetime.
  • V-253082 Medium check TOSS must be configured to disable USB mass storage.
  • V-253083 Medium descriptioncheckfix TOSS must be configured so that all network connections associated with SSH traffic are terminated at the end of the session or after 10 minutes of inactivity, except to fulfill documented and validated mission requirements.
Sort by
b
TOSS must display the Standard Mandatory DoD Notice and Consent Banner or equivalent US Government Agency Notice and Consent Banner before granting local or remote access to the system.
AC-8 - Medium - CCI-000048 - V-252911 - SV-252911r958390_rule
RMF Control
AC-8
Severity
M
CCI
CCI-000048
Version
TOSS-04-010000
Vuln IDs
  • V-252911
Rule IDs
  • SV-252911r958390_rule
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 or other US Government Agency 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."
Checks: C-56364r824055_chk

Verify TOSS displays the Standard Mandatory DoD Notice and Consent Banner or equivalent US Government Agency Notice and Consent Banner before granting access to the system. Check that TOSS displays a banner at the command line login screen with the following command: $ sudo cat /etc/issue "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." If the system has a graphical logon capability and does not display a graphical logon banner, this is a finding. If the text in the file does not match the Standard Mandatory DoD Notice and Consent Banner or equivalent US Government Agency Notice and Consent Banner, this is a finding.

Fix: F-56314r824056_fix

Configure TOSS to display the Standard Mandatory DoD Notice and Consent Banner or equivalent US Government Agency Notice and Consent Banner before granting access to the system. The banner must be formatted in accordance with applicable DoD or other US Government Agency policy. Edit the "/etc/issue" file to replace the default text with the Standard Mandatory DoD Notice and Consent Banner or equivalent US Government Agency Notice and Consent Banner. The DoD-required text is: "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.

b
TOSS, for PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.
IA-5 - Medium - CCI-000185 - V-252912 - SV-252912r986571_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000185
Version
TOSS-04-010010
Vuln IDs
  • V-252912
Rule IDs
  • SV-252912r986571_rule
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. Satisfies: SRG-OS-000066-GPOS-00034, SRG-OS-000384-GPOS-00167
Checks: C-56365r986569_chk

Verify TOSS for PKI-based authentication has valid certificates by constructing a certification path (which includes status information) to an accepted trust anchor. Check that the system has a valid DOD root CA installed with the following command: Note: If the system does not support PKI authentication, this requirement is Not Applicable. $ sudo openssl x509 -text -in /etc/sssd/pki/sssd_auth_ca_db.pem Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: sha256WithRSAEncryption Issuer: C = US, O = U.S. Government, OU = DOD, OU = PKI, CN = DOD Root CA 3 Validity Not Before: Mar 20 18:46:41 2012 GMT Not After : Dec 30 18:46:41 2029 GMT Subject: C = US, O = U.S. Government, OU = DOD, OU = PKI, CN = DOD Root CA 3 Subject Public Key Info: Public Key Algorithm: rsaEncryption If the root ca file is not a DOD-issued certificate with a valid date and installed in the /etc/sssd/pki/sssd_auth_ca_db.pem location, this is a finding.

Fix: F-56315r986570_fix

If PKI-based authentication is used, configure TOSS to validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor. Obtain a valid copy of the DOD root CA file from the PKI CA certificate bundle from cyber.mil and copy it into the following file: /etc/sssd/pki/sssd_auth_ca_db.pem

b
TOSS, for PKI-based authentication, must enforce authorized access to the corresponding private key.
IA-5 - Medium - CCI-000186 - V-252913 - SV-252913r958450_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000186
Version
TOSS-04-010020
Vuln IDs
  • V-252913
Rule IDs
  • SV-252913r958450_rule
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.
Checks: C-56366r824061_chk

Verify the operating system, for PKI-based authentication, enforces authorized access to the corresponding private key. If the system does not allow PKI authentication, this requirement is Not Applicable. Verify the SSH private key files have a passphrase. For each private key stored on the system, use the following command: $ sudo ssh-keygen -y -f /path/to/file If the contents of the key are displayed, and use of un-passphrased SSH keys is not documented with the Information System Security Officer (ISSO), this is a finding.

Fix: F-56316r824062_fix

Create a new private and public key pair that utilizes a passcode with the following command: $ sudo ssh-keygen -n [passphrase]

b
TOSS must require authentication upon booting into emergency or rescue modes.
AC-3 - Medium - CCI-000213 - V-252914 - SV-252914r958472_rule
RMF Control
AC-3
Severity
M
CCI
CCI-000213
Version
TOSS-04-010030
Vuln IDs
  • V-252914
Rule IDs
  • SV-252914r958472_rule
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.
Checks: C-56367r824064_chk

Check to see if the system requires authentication for rescue or emergency mode with the following command: $ sudo grep sulogin-shell /usr/lib/systemd/system/rescue.service ExecStart=-/usr/lib/systemd/systemd-sulogin-shell rescue If the "ExecStart" line is configured for anything other than "/usr/lib/systemd/systemd-sulogin-shell rescue", commented out, or missing, this is a finding.

Fix: F-56317r824065_fix

Configure the system to require authentication upon booting into emergency or rescue mode by adding the following line to the "/usr/lib/systemd/system/rescue.service" file. ExecStart=-/usr/lib/systemd/systemd-sulogin-shell rescue

b
TOSS must not permit direct logons to the root account using remote access from outside of the system via SSH.
Medium - CCI-004045 - V-252915 - SV-252915r986573_rule
RMF Control
Severity
M
CCI
CCI-004045
Version
TOSS-04-010040
Vuln IDs
  • V-252915
Rule IDs
  • SV-252915r986573_rule
Even though the communications channel may be encrypted, an additional layer of security is gained by extending the policy of not logging on directly as root. In addition, logging on with a user-specific account provides individual accountability of actions performed on the system.
Checks: C-56368r986572_chk

Verify remote access from outside the system using SSH prevents users from logging on directly as "root." Check that SSH prevents users from logging on directly as "root" with the following command: $ sudo grep -i PermitRootLogin /etc/ssh/sshd_config PermitRootLogin no If the "PermitRootLogin" keyword is set to "yes", is missing, or is commented out, and is not documented with the information system security officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56318r824068_fix

Configure TOSS to stop users from logging on remotely from outside of the cluster as the "root" user via SSH. Edit the appropriate "/etc/ssh/sshd_config" file to uncomment or add the line for the "PermitRootLogin" keyword and set its value to "no": PermitRootLogin no The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

b
The TOSS file system automounter must be disabled unless required.
IA-3 - Medium - CCI-000778 - V-252916 - SV-252916r958498_rule
RMF Control
IA-3
Severity
M
CCI
CCI-000778
Version
TOSS-04-010050
Vuln IDs
  • V-252916
Rule IDs
  • SV-252916r958498_rule
Automatically mounting file systems permits easy introduction of unknown devices, thereby facilitating malicious activity.
Checks: C-56369r824070_chk

Verify the operating system disables the ability to automount devices. Check to see if automounter service is active with the following command: Note: If the autofs service is not installed, this requirement is Not Applicable. $ sudo systemctl status autofs autofs.service - Automounts filesystems on demand Loaded: loaded (/usr/lib/systemd/system/autofs.service; disabled) Active: inactive (dead) If the "autofs" status is set to "active" and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56319r824071_fix

Configure the operating system to disable the ability to automount devices. Turn off the automount service with the following commands: $ sudo systemctl stop autofs $ sudo systemctl disable autofs If "autofs" is required for Network File System (NFS), it must be documented with the ISSO.

b
The TOSS pam_unix.so module must be configured in the password-auth file to use a FIPS 140-2-approved cryptographic hashing algorithm for system authentication.
IA-7 - Medium - CCI-000803 - V-252917 - SV-252917r971535_rule
RMF Control
IA-7
Severity
M
CCI
CCI-000803
Version
TOSS-04-010060
Vuln IDs
  • V-252917
Rule IDs
  • SV-252917r971535_rule
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. TOSS 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.
Checks: C-56370r824073_chk

Verify that the pam_unix.so module is configured to use sha512. Check that the pam_unix.so module is configured to use sha512 in /etc/pam.d/password-auth with the following command: $ sudo grep password /etc/pam.d/password-auth | grep pam_unix password sufficient pam_unix.so sha512 If "sha512" is missing, or is commented out, this is a finding.

Fix: F-56320r824074_fix

Configure TOSS to use a FIPS 140-2-approved cryptographic hashing algorithm for system authentication. Edit and/or modify the following line in the "/etc/pam.d/password-auth" file to include the sha512 option for pam_unix.so: password sufficient pam_unix.so sha512

b
The TOSS pam_unix.so module must be configured in the system-auth file to use a FIPS 140-2-approved cryptographic hashing algorithm for system authentication.
IA-7 - Medium - CCI-000803 - V-252918 - SV-252918r971535_rule
RMF Control
IA-7
Severity
M
CCI
CCI-000803
Version
TOSS-04-010070
Vuln IDs
  • V-252918
Rule IDs
  • SV-252918r971535_rule
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. TOSS 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.
Checks: C-56371r824076_chk

Verify that the pam_unix.so module is configured to use sha512. Check that the pam_unix.so module is configured to use sha512 in /etc/pam.d/system-auth with the following command: $ sudo grep password /etc/pam.d/system-auth | grep pam_unix password sufficient pam_unix.so sha512 If "sha512" is missing, or is commented out, this is a finding.

Fix: F-56321r824077_fix

Configure TOSS to use a FIPS 140-2-approved cryptographic hashing algorithm for system authentication. Edit and/or modify the following line in the "/etc/pam.d/system-auth" file to include the sha512 option for pam_unix.so: password sufficient pam_unix.so sha512

b
The TOSS operating system must implement DoD-approved encryption in the OpenSSL package.
MA-4 - Medium - CCI-000877 - V-252919 - SV-252919r958510_rule
RMF Control
MA-4
Severity
M
CCI
CCI-000877
Version
TOSS-04-010080
Vuln IDs
  • V-252919
Rule IDs
  • SV-252919r958510_rule
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. TOSS incorporates system-wide crypto policies by default. The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/openssl.config file. Satisfies: SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093
Checks: C-56372r824079_chk

Verify the OpenSSL library is configured to use only DoD-approved TLS encryption: $ sudo grep -i MinProtocol /etc/crypto-policies/back-ends/opensslcnf.config TLS.MinProtocol = TLSv1.2 DTLS.MinProtocol = DTLSv1.2 If the "TLS.MinProtocol" is set to anything older than "TLSv1.2" or the "DTLS.MinProtocol" is set to anything older than DTLSv1.2, this is a finding.

Fix: F-56322r824080_fix

Configure the TOSS OpenSSL library to use only DoD-approved TLS encryption by editing the following lines in the "/etc/crypto-policies/back-ends/opensslcnf.config" file: MinProtocol = TLSv1.2 DTLS.MinProtocol = DTLSv1.2 A reboot is required for the changes to take effect.

b
TOSS must use a Linux Security Module configured to enforce limits on system services.
SC-3 - Medium - CCI-001084 - V-252920 - SV-252920r958518_rule
RMF Control
SC-3
Severity
M
CCI
CCI-001084
Version
TOSS-04-010090
Vuln IDs
  • V-252920
Rule IDs
  • SV-252920r958518_rule
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 non-security 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.
Checks: C-56373r824082_chk

Verify that TOSS verifies the correct operation of all security functions. Check if "SELinux" is active and in "Enforcing" mode with the following command: $ sudo getenforce Enforcing If "SELinux" is not active or not in "Enforcing" mode, this is a finding.

Fix: F-56323r824083_fix

Configure the operating system to verify correct operation of all security functions. Set the "SELinux" status and the "Enforcing" mode by modifying the "/etc/selinux/config" file to have the following line: SELINUX=enforcing A reboot is required for the changes to take effect.

b
TOSS must prevent unauthorized and unintended information transfer via shared system resources.
SC-4 - Medium - CCI-001090 - V-252921 - SV-252921r958524_rule
RMF Control
SC-4
Severity
M
CCI
CCI-001090
Version
TOSS-04-010100
Vuln IDs
  • V-252921
Rule IDs
  • SV-252921r958524_rule
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.
Checks: C-56374r824085_chk

Check to see that all public directories are owned by root or a system account with the following command: $ sudo find / -type d -perm -0002 -exec ls -lLd {} \; drwxrwxrwxt 7 root root 4096 Jul 26 11:19 /tmp If any of the returned directories are not owned by root or a system account, this is a finding.

Fix: F-56324r824086_fix

Configure all public directories to be owned by root or a system account to prevent unauthorized and unintended information transferred via shared system resources. Set the owner of all public directories as root or a system account using the command, replace "[Public Directory]" with any directory path not owned by root or a system account: $ sudo chown root [Public Directory]

b
The TOSS operating system must be configured to use TCP syncookies.
SC-5 - Medium - CCI-001095 - V-252922 - SV-252922r958528_rule
RMF Control
SC-5
Severity
M
CCI
CCI-001095
Version
TOSS-04-010110
Vuln IDs
  • V-252922
Rule IDs
  • SV-252922r958528_rule
Denial of Service (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.
Checks: C-56375r824088_chk

Verify The TOSS operating system is configured to use TCP syncookies. Check the value of TCP syncookies with the following command: $ sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_syncookies = 1 If the value is not "1", this is a finding. Check the saved value of TCP syncookies with the following command: $ sudo grep -i net.ipv4.tcp_syncookies /etc/sysctl.conf /etc/sysctl.d/* | grep -v '#' If no output is returned, this is a finding.

Fix: F-56325r824089_fix

Configure The TOSS operating system to use TCP syncookies by running the following command: $ sudo sysctl -w net.ipv4.tcp_syncookies=1 If "1" is not the system's default value, add or update the following line in "/etc/sysctl.conf": net.ipv4.tcp_syncookies = 1

a
TOSS must display the Standard Mandatory DoD Notice and Consent Banner or equivalent US Government Agency Notice and Consent Banner before granting local or remote access to the system via a ssh logon.
AC-8 - Low - CCI-001384 - V-252923 - SV-252923r958586_rule
RMF Control
AC-8
Severity
L
CCI
CCI-001384
Version
TOSS-04-010120
Vuln IDs
  • V-252923
Rule IDs
  • SV-252923r958586_rule
Display of a standardized and approved use notification before granting access to TOSS 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 or other US Government Agency 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."
Checks: C-56376r824091_chk

Verify that TOSS displays the Standard Mandatory DoD Notice and Consent Banner or equivalent US Government Agency Notice and Consent Banner before granting access to the system when connecting from outside of the cluster. Check for the location of the banner file being used with the following command: $ sudo grep -i banner /etc/ssh/sshd_config banner /etc/issue This command will return the banner keyword and the name of the file that contains the ssh banner (in this case "/etc/issue"). If the line is commented out, this is a finding. For nodes of the cluster that are only privately (within the cluster) accessible, this requirement is Not Applicable. View the file specified by the banner keyword to check that it matches the text of the Standard Mandatory DoD Notice and Consent Banner: "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." If the system has a graphical logon capability and does not display a graphical logon banner, this is a finding. If the text in the file does not match the Standard Mandatory DoD Notice and Consent Banner or equivalent US Government Agency Notice and Consent Banner, this is a finding.

Fix: F-56326r824092_fix

Configure TOSS to display the Standard Mandatory DoD Notice and Consent Banner or equivalent US Government Agency Notice and Consent Banner before granting access to the system. Edit the "/etc/ssh/sshd_config" file to uncomment the banner keyword and configure it to point to a file that will contain the logon banner (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor). An example configuration line is: banner /etc/issue The banner must be formatted in accordance with applicable DoD or other US Government Agency policy. Edit the "/etc/issue" file to replace the default text with the Standard Mandatory DoD Notice and Consent Banner or equivalent US Government Agency Notice and Consent Banner. The DoD-required text is: "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.

b
The TOSS operating system must implement DoD-approved encryption to protect the confidentiality of SSH connections.
AC-17 - Medium - CCI-001453 - V-252924 - SV-252924r991554_rule
RMF Control
AC-17
Severity
M
CCI
CCI-001453
Version
TOSS-04-010140
Vuln IDs
  • V-252924
Rule IDs
  • SV-252924r991554_rule
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. TOSS incorporates system-wide crypto policies by default. The SSH configuration file has no effect on the ciphers, MACs, or algorithms unless specifically defined in the /etc/sysconfig/sshd file. The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/openssh.config file. By specifying a cipher list with the order of ciphers being in a "strongest to weakest" orientation, the system will automatically attempt to use the strongest cipher for securing SSH connections. Satisfies: SRG-OS-000250-GPOS-00093, SRG-OS-000394-GPOS-00174
Checks: C-56377r824094_chk

Verify the SSH daemon is configured to use only ciphers employing FIPS 140-2-approved algorithms: Verify that system-wide crypto policies are in effect: $ sudo grep CRYPTO_POLICY /etc/sysconfig/sshd # CRYPTO_POLICY= If the "CRYPTO_POLICY" is uncommented, this is a finding. Verify which system-wide crypto policy is in use: $ sudo update-crypto-policies --show FIPS Check that the ciphers in the back-end configurations are FIPS 140-2-approved algorithms with the following command: $ sudo grep -i ciphers /etc/crypto-policies/back-ends/openssh.config /etc/crypto-policies/back-ends/opensshserver.config /etc/crypto-policies/back-ends/openssh.config:Ciphers aes256-ctr,aes192-ctr,aes128-ctr /etc/crypto-policies/back-ends/opensshserver.config:CRYPTO_POLICY='-oCiphers=aes256-ctr,aes192-ctr,aes128-ctr' /etc/crypto-policies/back-ends/opensshserver.config:CRYPTO_POLICY='-oCiphers=aes256-ctr,aes192-ctr,aes128-ctr' If the cipher entries in the "openssh.config" and "opensshserver.config" files have any ciphers other than "aes256-ctr,aes192-ctr,aes128-ctr", the order differs from the example above, if they are missing, or commented out, this is a finding.

Fix: F-56327r824095_fix

Configure the TOSS SSH daemon to use only ciphers employing FIPS 140-2-approved algorithms with the following command: $ sudo fips-mode-setup --enable Next, update the "/etc/crypto-policies/back-ends/openssh.config" and "/etc/crypto-policies/back-ends/opensshserver.config" files to include these ciphers employing FIPS 140-2-approved algorithms: /etc/crypto-policies/back-ends/openssh.config:Ciphers aes256-ctr,aes192-ctr,aes128-ctr /etc/crypto-policies/back-ends/opensshserver.config:CRYPTO_POLICY='-oCiphers=aes256-ctr,aes192-ctr,aes128-ctr' /etc/crypto-policies/back-ends/opensshserver.config:CRYPTO_POLICY='-oCiphers=aes256-ctr,aes192-ctr,aes128-ctr' A reboot is required for the changes to take effect.

b
The TOSS operating system must implement DoD-approved TLS encryption in the GnuTLS package.
AC-17 - Medium - CCI-001453 - V-252925 - SV-252925r991554_rule
RMF Control
AC-17
Severity
M
CCI
CCI-001453
Version
TOSS-04-010150
Vuln IDs
  • V-252925
Rule IDs
  • SV-252925r991554_rule
Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Transport Layer Security (TLS) encryption is a required security setting as a number of known vulnerabilities have been reported against Secure Sockets Layer (SSL) and earlier versions of TLS. Encryption of private information is essential to ensuring data confidentiality. If private information is not encrypted, it can be intercepted and easily read by an unauthorized party. SQL Server must use a minimum of FIPS 140-2-approved TLS version 1.2, and all non-FIPS-approved SSL and TLS versions must be disabled. NIST SP 800-52 specifies the preferred configurations for government systems. 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. The GnuTLS library offers an API to access secure communications protocols. SSLv2 is not available in the GnuTLS library. The TOSS system-wide crypto policy defines employed algorithms in the /etc/crypto-policies/back-ends/gnutls.config file.5
Checks: C-56378r824097_chk

Verify the GnuTLS library is configured to only allow DoD-approved SSL/TLS Versions: $ sudo grep -io +vers.* /etc/crypto-policies/back-ends/gnutls.config +VERS-ALL:-VERS-DTLS0.9:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1:-VERS-DTLS1.0:+COMP-NULL:%PROFILE_MEDIUM If the "gnutls.config" does not list "-VERS-DTLS0.9:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1:-VERS-DTLS1.0" to disable unapproved SSL/TLS versions, this is a finding.

Fix: F-56328r824098_fix

Configure the TOSS GnuTLS library to use only DoD-approved encryption by adding the following line to "/etc/crypto-policies/back-ends/gnutls.config": +VERS-ALL:-VERS-DTLS0.9:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1:-VERS-DTLS1.0 A reboot is required for the changes to take effect.

b
The TOSS SSH daemon must be configured to use only Message Authentication Codes (MACs) employing FIPS 140-2 validated cryptographic hash algorithms.
AC-17 - Medium - CCI-001453 - V-252926 - SV-252926r991554_rule
RMF Control
AC-17
Severity
M
CCI
CCI-001453
Version
TOSS-04-010160
Vuln IDs
  • V-252926
Rule IDs
  • SV-252926r991554_rule
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. TOSS incorporates system-wide crypto policies by default. The SSH configuration file has no effect on the ciphers, MACs, or algorithms unless specifically defined in the /etc/sysconfig/sshd file. The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/openssh.config file. By specifying a hash algorithm list with the order of hashes being in a "strongest to weakest" orientation, the system will automatically attempt to use the strongest hash for securing SSH connections.
Checks: C-56379r824100_chk

Verify the SSH daemon is configured to use only MACs employing FIPS 140-2-approved algorithms: Check that the MACs in the back-end configurations are FIPS 140-2-approved algorithms with the following command: $ sudo grep -i macs /etc/crypto-policies/back-ends/openssh.config /etc/crypto-policies/back-ends/opensshserver.config /etc/crypto-policies/back-ends/openssh.config:MACs hmac-sha2-512,hmac-sha2-256 /etc/crypto-policies/back-ends/opensshserver.config:-oMACs=hmac-sha2-512,hmac-sha2-256' /etc/crypto-policies/back-ends/opensshserver.config:-oMACs=hmac-sha2-512,hmac-sha2-256' If the MAC entries in the "openssh.config" and "opensshserver.config" files have any hashes other than "hmac-sha2-512" and "hmac-sha2-256", the order differs from the example above, if they are missing, or commented out, this is a finding.

Fix: F-56329r824101_fix

Configure the TOSS SSH daemon to use only MACs employing FIPS 140-2-approved algorithms. Update the "/etc/crypto-policies/back-ends/openssh.config" and "/etc/crypto-policies/back-ends/opensshserver.config" files to include these MACs employing FIPS 140-2-approved algorithms: /etc/crypto-policies/back-ends/openssh.config:MACs hmac-sha2-512,hmac-sha2-256 /etc/crypto-policies/back-ends/opensshserver.config:-oMACs=hmac-sha2-512,hmac-sha2-256' /etc/crypto-policies/back-ends/opensshserver.config:-oMACs=hmac-sha2-512,hmac-sha2-256' A reboot is required for the changes to take effect.

b
The TOSS operating system must be configured to preserve log records from failure events.
SC-24 - Medium - CCI-001665 - V-252927 - SV-252927r991562_rule
RMF Control
SC-24
Severity
M
CCI
CCI-001665
Version
TOSS-04-010170
Vuln IDs
  • V-252927
Rule IDs
  • SV-252927r991562_rule
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.
Checks: C-56380r824103_chk

Verify the rsyslog service is enabled and active with the following commands: $ sudo systemctl is-enabled rsyslog enabled $ sudo systemctl is-active rsyslog active If the service is not "enabled" and "active", this is a finding. If "rsyslog" is not enabled, ask the System Administrator how system error logging is performed on the system. If there is no evidence of system logging being performed on the system, this is a finding.

Fix: F-56330r824104_fix

Start and enable the rsyslog service with the following commands: $ sudo systemctl start rsyslog.service $ sudo systemctl enable rsyslog.service

b
TOSS 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).
AU-8 - Medium - CCI-001890 - V-252928 - SV-252928r986576_rule
RMF Control
AU-8
Severity
M
CCI
CCI-001890
Version
TOSS-04-010180
Vuln IDs
  • V-252928
Rule IDs
  • SV-252928r986576_rule
Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time that 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). 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. TOSS utilizes the "timedatectl" command to view the status of the "systemd-timesyncd.service." The "timedatectl" status will display the local time, UTC, and the offset from UTC. Note that USNO offers authenticated NTP service to DOD and U.S. Government agencies operating on the NIPR and SIPR networks. Visit https://www.usno.navy.mil/USNO/time/ntp/dod-customers for more information. Satisfies: SRG-OS-000355-GPOS-00143, SRG-OS-000356-GPOS-00144, SRG-OS-000359-GPOS-00146
Checks: C-56381r986574_chk

If the system is not networked, this requirement is Not Applicable. The system clock must be configured to compare the system clock at least every 24 hours to the authoritative time source. Check the value of "maxpoll" in the "/etc/chrony/chrony.conf" file with the following command: $ sudo grep maxpoll /etc/chrony/chrony.conf server tick.usno.navy.mil iburst maxpoll 16 If "maxpoll" is not set to "16" or does not exist, this is a finding. Verify that the "chrony.conf" file is configured to an authoritative DOD time source by running the following command: $ grep -i server /etc/chrony.conf server tick.usno.navy.mil iburst maxpoll 16 server tock.usno.navy.mil iburst maxpoll 16 server ntp2.usno.navy.mil iburst maxpoll 16 If the parameter "server" is not set, is not set to an authoritative DOD time source, or is commented out, this is a finding.

Fix: F-56331r986575_fix

For networked systems, configure TOSS to compare internal information system clocks at least every 24 hours with a server which is synchronized to one of the redundant USNO time servers, or a time server designated for the appropriate DOD network (NIPRNet/SIPRNet), and/or the GPS. Add and/or modify the following line in the /etc/chrony.conf file: server [ntp.server.name] iburst maxpoll 16

b
The TOSS file integrity tool must notify the system administrator when changes to the baseline configuration or anomalies in the operation of any security functions are discovered within an organizationally defined frequency.
CM-3 - Medium - CCI-001744 - V-252929 - SV-252929r958794_rule
RMF Control
CM-3
Severity
M
CCI
CCI-001744
Version
TOSS-04-010210
Vuln IDs
  • V-252929
Rule IDs
  • SV-252929r958794_rule
Unauthorized changes to the baseline configuration could make the system vulnerable to various attacks or allow unauthorized access to the operating system. Changes to operating system configurations can have unintended side effects, some of which may be relevant to security. Detecting such changes and providing an automated response can help avoid unintended, negative consequences that could ultimately affect the security state of the operating system. The operating system's Information Management Officer (IMO)/Information System Security Officer (ISSO) and System Administrators (SAs) must be notified via email and/or monitoring system trap when there is an unauthorized modification of a configuration item. 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. TOSS 4 comes with many optional software packages. A file integrity tool called Advanced Intrusion Detection Environment (AIDE) is one of those optional packages. This requirement assumes the use of AIDE; however, a different tool may be used if the requirements are met. Note that AIDE does not have a configuration that will send a notification, so a cron job is recommended that uses the mail application on the system to email the results of the file integrity check. Satisfies: SRG-OS-000363-GPOS-00150, SRG-OS-000446-GPOS-00200, SRG-OS-000447-GPOS-00201
Checks: C-56382r824109_chk

Verify the operating system routinely checks the baseline configuration for unauthorized changes and notifies the system administrator when anomalies in the operation of any security functions are discovered. Check to see if AIDE is installed on the system with the following command: $ sudo yum list installed aide If AIDE is not installed, ask the System Administrator how file integrity checks are performed on the system. Check that TOSS routinely executes a file integrity scan for changes to the system baseline. The command used in the example will use a daily occurrence. Check the cron directories for scripts controlling the execution and notification of results of the file integrity application. For example, if AIDE is installed on the system, use the following commands: $ sudo ls -al /etc/cron.* | grep aide -rwxr-xr-x 1 root root 29 Nov 22 2015 aide $ sudo grep aide /etc/crontab /var/spool/cron/root /etc/crontab: 30 04 * * * root usr/sbin/aide /var/spool/cron/root: 30 04 * * * root usr/sbin/aide $ sudo more /etc/cron.daily/aide #!/bin/bash /usr/sbin/aide --check | /bin/mail -s "$HOSTNAME - Daily aide integrity check run" root@sysname.mil Here the use of /bin/mail is one example of how to notify designated personnel. There may be other methods available to a system, such as notifications from an external log aggregation service (e.g., SIEM). If the file integrity application does not exist, or a script file controlling the execution of the file integrity application does not exist, or the file integrity application does not notify designated personnel of changes, this is a finding.

Fix: F-56332r824110_fix

Configure the file integrity tool to run automatically on the system at least weekly and to notify designated personnel if baseline configurations are changed in an unauthorized manner. The AIDE tool can be configured to email designated personnel with the use of the cron system. The following example output is generic. It will set cron to run AIDE daily and to send email at the completion of the analysis. $ sudo more /etc/cron.daily/aide #!/bin/bash /usr/sbin/aide --check | /bin/mail -s "$HOSTNAME - Daily aide integrity check run" root@sysname.mil

c
TOSS 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.
High - CCI-003992 - V-252930 - SV-252930r986577_rule
RMF Control
Severity
H
CCI
CCI-003992
Version
TOSS-04-010220
Vuln IDs
  • V-252930
Rule IDs
  • SV-252930r986577_rule
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 Certification Authority (CA).
Checks: C-56383r824112_chk

Verify TOSS 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. Check that YUM verifies the signature of packages from a repository prior to install with the following command: $ sudo egrep '^\[.*\]|gpgcheck' /etc/yum.repos.d/*.repo /etc/yum.repos.d/appstream.repo:[appstream] /etc/yum.repos.d/appstream.repo:gpgcheck=1 /etc/yum.repos.d/baseos.repo:[baseos] /etc/yum.repos.d/baseos.repo:gpgcheck=1 If "gpgcheck" is not set to "1", or if options are missing or commented out, ask the System Administrator how the certificates for patches and other operating system components are verified. If there is no process to validate certificates that is approved by the organization, this is a finding.

Fix: F-56333r824113_fix

Configure TOSS 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 by setting the following option in the "/etc/yum.repos.d/[your_repo_name].repo" file(s): gpgcheck=1

b
TOSS must require reauthentication when using the "sudo" command.
Medium - CCI-004895 - V-252931 - SV-252931r987879_rule
RMF Control
Severity
M
CCI
CCI-004895
Version
TOSS-04-010230
Vuln IDs
  • V-252931
Rule IDs
  • SV-252931r987879_rule
Without reauthentication, 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 organization requires the user to reauthenticate when using the "sudo" command. If the value is set to an integer less than 0, the user's time stamp will not expire and the user will not have to reauthenticate for privileged actions until the user's session is terminated.
Checks: C-56384r986578_chk

Verify the operating system requires reauthentication when using the "sudo" command to elevate privileges. $ sudo egrep -ir 'timestamp_timeout' /etc/sudoers /etc/sudoers.d /etc/sudoers:Defaults timestamp_timeout=0 If "timestamp_timeout" is set to a negative number, is commented out, or no results are returned, this is a finding.

Fix: F-56334r986579_fix

Configure the "sudo" command to require reauthentication. Edit the /etc/sudoers file: $ sudo visudo Add or modify the following line: Defaults timestamp_timeout=0

b
TOSS must have the packages required for multifactor authentication installed.
Medium - CCI-004046 - V-252932 - SV-252932r986581_rule
RMF Control
Severity
M
CCI
CCI-004046
Version
TOSS-04-010240
Vuln IDs
  • V-252932
Rule IDs
  • SV-252932r986581_rule
Using an authentication device, such as a DOD Common Access Card (CAC) or token that is separate from the information system, ensures that even if the information system is compromised, credentials stored on the authentication device will not be affected. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification (PIV) card and the DOD CAC. A privileged account is defined as an information system account with authorizations of a privileged user. Remote access is access to DOD nonpublic information systems by an authorized user (or an information system) communicating through an external, 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).
Checks: C-56385r824118_chk

Verify TOSS has the packages required for multifactor authentication installed with the following commands: $ sudo yum list installed openssl-pkcs11 openssl-pkcs11.x86_64 0.4.10-2.el8 @anaconda If the "openssl-pkcs11" package is not installed, ask the administrator to indicate what type of multifactor authentication is being utilized and what packages are installed to support it. If there is no evidence of multifactor authentication being used, this is a finding.

Fix: F-56335r824119_fix

Configure TOSS to implement multifactor authentication by installing the required package with the following command: $ sudo yum install openssl-pkcs11

b
TOSS must prohibit the use of cached authentications after one day.
IA-5 - Medium - CCI-002007 - V-252933 - SV-252933r958828_rule
RMF Control
IA-5
Severity
M
CCI
CCI-002007
Version
TOSS-04-010250
Vuln IDs
  • V-252933
Rule IDs
  • SV-252933r958828_rule
If cached authentication information is out of date, the validity of the authentication information may be questionable. TOSS includes multiple options for configuring authentication, but this requirement will be focus on the System Security Services Daemon (SSSD). By default, sssd does not cache credentials.
Checks: C-56386r824121_chk

Verify that SSSD prohibits the use of cached authentications after one day. Note: If smart card authentication is not being used on the system, this item is Not Applicable. Check that SSSD allows cached authentications with the following command: $ sudo grep cache_credentials /etc/sssd/sssd.conf cache_credentials = true If "cache_credentials" is set to "false" or missing from the configuration file, this is not a finding and no further checks are required. If "cache_credentials" is set to "true", check that SSSD prohibits the use of cached authentications after one day with the following command: $ sudo grep offline_credentials_expiration /etc/sssd/sssd.conf offline_credentials_expiration = 1 If "offline_credentials_expiration" is not set to a value of "1", this is a finding.

Fix: F-56336r824122_fix

Configure the SSSD to prohibit the use of cached authentications after one day. Add or change the following line in "/etc/sssd/sssd.conf" just below the line "[pam]." offline_credentials_expiration = 1

b
All TOSS networked systems must have and implement SSH to protect the confidentiality and integrity of transmitted and received information, as well as information during preparation for transmission.
SC-8 - Medium - CCI-002418 - V-252934 - SV-252934r958908_rule
RMF Control
SC-8
Severity
M
CCI
CCI-002418
Version
TOSS-04-010280
Vuln IDs
  • V-252934
Rule IDs
  • SV-252934r958908_rule
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. Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188, SRG-OS-000425-GPOS-00189, SRG-OS-000426-GPOS-00190
Checks: C-56387r824124_chk

Verify that the SSH package is installed: $ rpm -q openssh-server openssh-server-8.0p1-10.el8_4.2.x86_64 If the "SSH server" package is not installed, this is a finding. Verify SSH is loaded and active with the following commands: $ sudo systemctl is-active sshd active $ sudo systemctl is-enabled sshd enabled If "sshd" does not show a status of "active" and "enabled", this is a finding.

Fix: F-56337r824125_fix

Install the SSH server package onto the host with the following command: $ sudo yum install openssh-server Configure the SSH service to automatically start now and after each reboot with the following command: $ sudo systemctl enable --now sshd.service

b
For TOSS systems using Domain Name Servers (DNS) resolution, at least two name servers must be configured.
CM-6 - Medium - CCI-000366 - V-252935 - SV-252935r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-010330
Vuln IDs
  • V-252935
Rule IDs
  • SV-252935r991589_rule
To provide availability for name resolution services, multiple redundant name servers are mandated. A failure in name resolution could lead to the failure of security functions requiring name resolution, which may include time synchronization, centralized authentication, and remote system logging.
Checks: C-56388r824127_chk

Determine whether the system is using local or DNS name resolution with the following command: $ sudo grep hosts /etc/nsswitch.conf hosts: files dns If the DNS entry is missing from the host's line in the "/etc/nsswitch.conf" file, the "/etc/resolv.conf" file must be empty. Verify the "/etc/resolv.conf" file is empty with the following command: $ sudo ls -al /etc/resolv.conf -rw-r--r-- 1 root root 0 Aug 19 08:31 resolv.conf If local host authentication is being used and the "/etc/resolv.conf" file is not empty, this is a finding. If the DNS entry is found on the host's line of the "/etc/nsswitch.conf" file, verify the operating system is configured to use two or more name servers for DNS resolution. Determine the name servers used by the system with the following command: $ sudo grep nameserver /etc/resolv.conf nameserver 192.168.1.2 nameserver 192.168.1.3 If less than two lines are returned that are not commented out, this is a finding.

Fix: F-56338r824128_fix

Configure the operating system to use two or more name servers for DNS resolution. By default, "NetworkManager" on TOSS dynamically updates the /etc/resolv.conf file with the DNS settings from active "NetworkManager" connection profiles. However, this feature can be disabled to allow manual configurations. If manually configuring DNS, edit the "/etc/resolv.conf" file to uncomment or add the two or more "nameserver" option lines with the IP address of local authoritative name servers. If local host resolution is being performed, the "/etc/resolv.conf" file must be empty. An empty "/etc/resolv.conf" file can be created as follows: $ sudo echo -n > /etc/resolv.conf

b
The debug-shell systemd service must be disabled on TOSS.
CM-6 - Medium - CCI-000366 - V-252936 - SV-252936r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-010340
Vuln IDs
  • V-252936
Rule IDs
  • SV-252936r991589_rule
The debug-shell requires no authentication and provides root privileges to anyone who has physical access to the machine. While this feature is disabled by default, masking it adds an additional layer of assurance that it will not be enabled via a dependency in systemd. This also prevents attackers with physical access from trivially bypassing security on the machine through valid troubleshooting configurations and gaining root access when the system is rebooted.
Checks: C-56389r824130_chk

Verify TOSS is configured to mask the debug-shell systemd service with the following command: $ sudo systemctl status debug-shell.service debug-shell.service Loaded: masked (Reason: Unit debug-shell.service is masked.) Active: inactive (dead) If the "debug-shell.service" is loaded and not masked, this is a finding.

Fix: F-56339r824131_fix

Configure the system to mask the debug-shell systemd service with the following command: $ sudo systemctl mask debug-shell.service Created symlink /etc/systemd/system/debug-shell.service -> /dev/null Reload the daemon to take effect. $ sudo systemctl daemon-reload

c
The root account must be the only account having unrestricted access to the TOSS system.
CM-6 - High - CCI-000366 - V-252937 - SV-252937r991589_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
TOSS-04-010350
Vuln IDs
  • V-252937
Rule IDs
  • SV-252937r991589_rule
If an account other than root also has a User Identifier (UID) of "0", it has root authority, giving that account unrestricted access to the entire operating system. Multiple accounts with a UID of "0" afford an opportunity for potential intruders to guess a password for a privileged account.
Checks: C-56390r824133_chk

Check the system for duplicate UID "0" assignments with the following command: $ sudo awk -F: '$3 == 0 {print $1}' /etc/passwd If any accounts other than root have a UID of "0", this is a finding.

Fix: F-56340r824134_fix

Change the UID of any account on the system, other than root, that has a UID of "0." 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 of greater than "1000" that has not already been assigned.

c
The systemd Ctrl-Alt-Delete burst key sequence in TOSS must be disabled.
CM-6 - High - CCI-000366 - V-252938 - SV-252938r991589_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
TOSS-04-010360
Vuln IDs
  • V-252938
Rule IDs
  • SV-252938r991589_rule
A locally logged-on user who presses Ctrl-Alt-Delete when at the console can reboot the system. If accidentally pressed, as could happen in the case of a mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. In a graphical user environment, risk of unintentional reboot from the Ctrl-Alt-Delete sequence is reduced because the user will be prompted before any action is taken.
Checks: C-56391r824136_chk

Verify TOSS is not configured to reboot the system when Ctrl-Alt-Delete is pressed seven times within two seconds with the following command: $ sudo grep -i ctrl /etc/systemd/system.conf CtrlAltDelBurstAction=none If the "CtrlAltDelBurstAction" is not set to "none", commented out, or is missing, this is a finding.

Fix: F-56341r824137_fix

Configure the system to disable the CtrlAltDelBurstAction by added or modifying the following line in the "/etc/systemd/system.conf" configuration file: CtrlAltDelBurstAction=none Reload the daemon for this change to take effect. $ sudo systemctl daemon-reload

b
There must be no ".shosts" files on The TOSS operating system.
CM-6 - Medium - CCI-000366 - V-252939 - SV-252939r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-010370
Vuln IDs
  • V-252939
Rule IDs
  • SV-252939r991589_rule
The ."shosts" files are used to configure host-based authentication for individual users or the system via SSH. Host-based authentication is not sufficient for preventing unauthorized access to the system, as it does not require interactive identification and authentication of a connection request, or for the use of two-factor authentication.
Checks: C-56392r824139_chk

Verify there are no ."shosts" files on TOSS with the following command: $ sudo find / -name '*.shosts' If any ."shosts" files are found, this is a finding.

Fix: F-56342r824140_fix

Remove any found ."shosts" files from the system. $ sudo rm /[path]/[to]/[file]/.shosts

c
TOSS must not allow blank or null passwords in the system-auth file.
CM-6 - High - CCI-000366 - V-252940 - SV-252940r991589_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
TOSS-04-010380
Vuln IDs
  • V-252940
Rule IDs
  • SV-252940r991589_rule
If an account has an empty password, anyone could log on and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.
Checks: C-56393r824142_chk

To verify that null passwords cannot be used, run the following command: $ sudo grep -i nullok /etc/pam.d/system-auth If output is produced, this is a finding.

Fix: F-56343r824143_fix

Remove any instances of the "nullok" option in the "/etc/pam.d/system-auth" file to prevent logons with empty passwords. Note: Manual changes to the listed file may be overwritten by the "authselect" program.

b
TOSS must not be performing packet forwarding unless the system is a router.
CM-6 - Medium - CCI-000366 - V-252941 - SV-252941r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-010390
Vuln IDs
  • V-252941
Rule IDs
  • SV-252941r991589_rule
Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this software is used when not required, system network information may be unnecessarily transmitted across the network.
Checks: C-56394r824145_chk

Verify TOSS is not performing packet forwarding unless the system is a router. If the system is a router (sometimes called a gateway) this requirement is Not Applicable. Note: If either IPv4 or IPv6 is disabled on the system, this requirement only applies to the active internet protocol version. Check to see if IP forwarding is enabled using the following commands: $ sudo sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 0 $ sudo sysctl net.ipv6.conf.all.forwarding net.ipv6.conf.all.forwarding = 0 If IP forwarding value is not "0" and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56344r824146_fix

Configure TOSS to not allow packet forwarding, unless the system is a router with the following commands: $ sudo sysctl -w net.ipv4.ip_forward=0 $ sudo sysctl -w net.ipv6.conf.all.forwarding=0 If "0" is not the system's default value then add or update the following lines in the appropriate file under "/etc/sysctl.d": net.ipv4.ip_forward=0 net.ipv6.conf.all.forwarding=0

b
The TOSS SSH daemon must not allow authentication using known host's authentication.
CM-6 - Medium - CCI-000366 - V-252942 - SV-252942r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-010400
Vuln IDs
  • V-252942
Rule IDs
  • SV-252942r991589_rule
Configuring this setting for the SSH daemon provides additional assurance that remote logon via SSH will require a password, even in the event of misconfiguration elsewhere.
Checks: C-56395r824148_chk

Verify the SSH daemon does not allow authentication using known host's authentication with the following command: $ sudo grep -i IgnoreUserKnownHosts /etc/ssh/sshd_config IgnoreUserKnownHosts yes If the value is returned as "no", the returned line is commented out, or no output is returned, this is a finding.

Fix: F-56345r824149_fix

Configure the SSH daemon to not allow authentication using known host's authentication. Add the following line in "/etc/ssh/sshd_config" or uncomment the line and set the value to "yes": IgnoreUserKnownHosts yes The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

b
The TOSS SSH daemon must not allow compression or must only allow compression after successful authentication.
CM-6 - Medium - CCI-000366 - V-252943 - SV-252943r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-010410
Vuln IDs
  • V-252943
Rule IDs
  • SV-252943r991589_rule
If compression is allowed in an SSH connection prior to authentication, vulnerabilities in the compression software could result in compromise of the system from an unauthenticated connection, potentially with root privileges.
Checks: C-56396r824151_chk

Verify the SSH daemon performs compression after a user successfully authenticates with the following command: $ sudo grep -i compression /etc/ssh/sshd_config Compression delayed If the "Compression" keyword is set to "yes", is missing, or the returned line is commented out, this is a finding.

Fix: F-56346r824152_fix

Uncomment the "Compression" keyword in "/etc/ssh/sshd_config" (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor) on the system and set the value to "delayed" or "no": Compression no The SSH service must be restarted for changes to take effect.

b
The TOSS SSH daemon must not allow Kerberos authentication, except to fulfill documented and validated mission requirements.
CM-6 - Medium - CCI-000366 - V-252944 - SV-252944r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-010420
Vuln IDs
  • V-252944
Rule IDs
  • SV-252944r991589_rule
Configuring these settings for the SSH daemon provides additional assurance that remote logon via SSH will not use unused methods of authentication, even in the event of misconfiguration elsewhere.
Checks: C-56397r824154_chk

Verify the SSH daemon does not allow Kerberos authentication with the following command: $ sudo grep -i KerberosAuthentication /etc/ssh/sshd_config KerberosAuthentication no If the value is returned as "yes", the returned line is commented out, no output is returned, or has not been documented with the ISSO, this is a finding.

Fix: F-56347r824155_fix

Configure the SSH daemon to not allow Kerberos authentication. Add the following line in "/etc/ssh/sshd_config" or uncomment the line and set the value to "no": KerberosAuthentication no The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

c
TOSS must not allow an unattended or automatic logon to the system.
CM-6 - High - CCI-000366 - V-252945 - SV-252945r991591_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
TOSS-04-010430
Vuln IDs
  • V-252945
Rule IDs
  • SV-252945r991591_rule
Failure to restrict system access to authenticated users negatively impacts operating system security.
Checks: C-56398r824157_chk

Verify TOSS does not allow an unattended or automatic logon to the system via a graphical user interface. Note: This requirement assumes the use of the TOSS default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Check for the value of the "AutomaticLoginEnable" in the "/etc/gdm/custom.conf" file with the following command: $ sudo grep -i automaticloginenable /etc/gdm/custom.conf AutomaticLoginEnable=false If the value of "AutomaticLoginEnable" is missing or is not set to "false", this is a finding. 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.

Fix: F-56348r824158_fix

Configure TOSS to not allow an unattended or automatic logon to the system via a graphical user interface. Add or edit the line for the "AutomaticLoginEnable" parameter in the [daemon] section of the "/etc/gdm/custom.conf" file to "false": [daemon] AutomaticLoginEnable=false

b
TOSS must enforce the limit of five consecutive invalid logon attempts by a user during a 15-minute time period.
AC-7 - Medium - CCI-000044 - V-252946 - SV-252946r958388_rule
RMF Control
AC-7
Severity
M
CCI
CCI-000044
Version
TOSS-04-020000
Vuln IDs
  • V-252946
Rule IDs
  • SV-252946r958388_rule
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.
Checks: C-56399r824160_chk

Verify the "/etc/security/faillock.conf" file is configured to lock an account after three unsuccessful logon attempts within 15 minutes: $ sudo grep -e "deny =" -e "fail_interval =" /etc/security/faillock.conf deny = 3 fail_interval = 900 If the "deny" option is set to "0", more than "3", is missing, or is commented out, this is a finding. If the "fail_interval" option is set to less than "900", is missing, or is commented out, this is a finding. Note: If the System Administrator demonstrates the use of an approved centralized account management method that locks an account after three unsuccessful logon attempts within a period of 15 minutes, this requirement is Not Applicable.

Fix: F-56349r824161_fix

Configure the operating system to lock an account when three unsuccessful logon attempts occur in 15 minutes. Add/Modify the "/etc/security/faillock.conf" file to match the following lines: deny = 3 fail_interval = 900

a
TOSS must limit the number of concurrent sessions to 256 for all accounts and/or account types.
AC-10 - Low - CCI-000054 - V-252947 - SV-252947r958398_rule
RMF Control
AC-10
Severity
L
CCI
CCI-000054
Version
TOSS-04-020010
Vuln IDs
  • V-252947
Rule IDs
  • SV-252947r958398_rule
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 Denial of Service (DoS) attacks. TOSS as an HPC operating system, is capable of supporting a large number of sessions, as well as tools which presume a larger number of concurrent sessions will be allowed. 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.
Checks: C-56400r824163_chk

Verify TOSS limits the number of concurrent sessions to less than or equal to 256 for all accounts and/or account types by issuing the following command: $ sudo grep -r -s '^[^#].*maxlogins' /etc/security/limits.conf /etc/security/limits.d/*.conf * hard maxlogins 256 This can be set as a global domain (with the * wildcard) but may be set differently for multiple domains. If the "maxlogins" item is missing, commented out, or the value is set greater than "256" and is not documented with the Information System Security Officer (ISSO) as an operational requirement for all domains that have the "maxlogins" item assigned, this is a finding.

Fix: F-56350r824164_fix

Configure TOSS to limit the number of concurrent sessions to at most 256 for all accounts and/or account types. Add the following line to the top of the /etc/security/limits.conf or in a ."conf" file defined in /etc/security/limits.d/: * hard maxlogins 256

b
TOSS must retain a user's session lock until that user reestablishes access using established identification and authentication procedures.
AC-11 - Medium - CCI-000056 - V-252948 - SV-252948r986582_rule
RMF Control
AC-11
Severity
M
CCI
CCI-000056
Version
TOSS-04-020020
Vuln IDs
  • V-252948
Rule IDs
  • SV-252948r986582_rule
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. Satisfies: SRG-OS-000028-GPOS-00009, SRG-OS-000030-GPOS-00011, SRG-OS-000031-GPOS-00012
Checks: C-56401r824166_chk

Verify TOSS retains a user's session lock until that user reestablishes access using established identification and authentication procedures with the following command: Note: This requirement assumes the use of the TOSS default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. $ sudo gsettings get org.gnome.desktop.screensaver lock-enabled true If the setting is "false", this is a finding.

Fix: F-56351r824167_fix

Configure TOSS to retain a user's session lock until that user reestablishes access using established identification and authentication procedures. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following example: $ sudo vi /etc/dconf/db/local.d/00-screensaver Edit the "[org/gnome/desktop/screensaver]" section of the database file and add or update the following lines: # Set this to true to lock the screen when the screensaver activates lock-enabled=true Update the system databases: $ sudo dconf update

b
TOSS must automatically lock graphical user sessions after 15 minutes of inactivity.
AC-11 - Medium - CCI-000057 - V-252949 - SV-252949r958402_rule
RMF Control
AC-11
Severity
M
CCI
CCI-000057
Version
TOSS-04-020030
Vuln IDs
  • V-252949
Rule IDs
  • SV-252949r958402_rule
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.
Checks: C-56402r824169_chk

Verify TOSS initiates a session lock after at most a 15-minute period of inactivity for graphical user interfaces with the following commands: Note: This requirement assumes the use of the TOSS default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. $ sudo gsettings get org.gnome.desktop.session idle-delay uint32 900 If "idle-delay" is set to "0" or a value greater than "900", this is a finding.

Fix: F-56352r824170_fix

Configure the operating system to initiate a screensaver after a 15-minute period of inactivity for graphical user interfaces. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command: $ sudo touch /etc/dconf/db/local.d/00-screensaver Edit /etc/dconf/db/local.d/00-screensaver and add or update the following lines: [org/gnome/desktop/session] # Set the lock time out to 900 seconds before the session is considered idle idle-delay=uint32 900 Update the system databases: $ sudo dconf update

b
TOSS must map the authenticated identity to the user or group account for PKI-based authentication.
IA-5 - Medium - CCI-000187 - V-252950 - SV-252950r958452_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000187
Version
TOSS-04-020050
Vuln IDs
  • V-252950
Rule IDs
  • SV-252950r958452_rule
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. There are various methods of mapping certificates to user/group accounts for TOSS. For the purposes of this requirement, the check and fix will account for Active Directory mapping. Some of the other possible methods include joining the system to a domain and utilizing a TOSS idM server, or a local system mapping, where the system is not part of a domain.
Checks: C-56403r824172_chk

Verify the certificate of the user or group is mapped to the corresponding user or group in the "sssd.conf" file with the following command: Note: If the system does not support PKI authentication, this requirement is Not Applicable. $ sudo cat /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = pam, sudo, ssh domains = testing.test [pam] pam_cert_auth = True [domain/testing.test] id_provider = ldap [certmap/testing.test/rule_name] matchrule =<SAN>.*EDIPI@mil maprule = (userCertificate;binary={cert!bin}) domains = testing.test If the certmap section does not exist, ask the System Administrator to indicate how certificates are mapped to accounts. If there is no evidence of certificate mapping, this is a finding.

Fix: F-56353r824173_fix

Configure TOSS to map the authenticated identity to the user or group account by adding or modifying the certmap section of the "/etc/sssd/sssd.conf" file based on the following example: [certmap/testing.test/rule_name] matchrule =<SAN>.*EDIPI@mil maprule = (userCertificate;binary={cert!bin}) dmains = testing.test The "sssd" service must be restarted for the changes to take effect. To restart the "sssd" service, run the following command: $ sudo systemctl restart sssd.service

b
TOSS duplicate User IDs (UIDs) must not exist for interactive users.
IA-2 - Medium - CCI-000764 - V-252951 - SV-252951r958482_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000764
Version
TOSS-04-020060
Vuln IDs
  • V-252951
Rule IDs
  • SV-252951r958482_rule
To ensure accountability and prevent unauthenticated access, interactive users must be identified and authenticated to prevent potential misuse and compromise of the system. Interactive users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Interactive 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. Satisfies: SRG-OS-000104-GPOS-00051, SRG-OS-000121-GPOS-00062
Checks: C-56404r824175_chk

Verify that TOSS contains no duplicate User IDs (UIDs) for interactive users. Check that the operating system contains no duplicate UIDs for interactive users with the following command: $ sudo awk -F ":" 'list[$3]++{print $1, $3}' /etc/passwd If output is produced, and the accounts listed are interactive user accounts, this is a finding.

Fix: F-56354r824176_fix

Edit the file "/etc/passwd" and provide each interactive user account that has a duplicate User ID (UID) with a unique UID.

b
TOSS must use multifactor authentication for network and local access to privileged and nonprivileged accounts.
IA-2 - Medium - CCI-000765 - V-252952 - SV-252952r986568_rule
RMF Control
IA-2
Severity
M
CCI
CCI-000765
Version
TOSS-04-020070
Vuln IDs
  • V-252952
Rule IDs
  • SV-252952r986568_rule
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 common access card (CAC) with DOD-approved PKI is an example of multifactor authentication. Satisfies: SRG-OS-000105-GPOS-00052, SRG-OS-000106-GPOS-00053, SRG-OS-000107-GPOS-00054, SRG-OS-000108-GPOS-00055
Checks: C-56405r824178_chk

Verify the operating system uses multifactor authentication for network access to privileged accounts. If it does not, this is a finding. Note: This requirement is applicable to any externally accessible nodes of the TOSS system. For compute or other intra-cluster only accessible nodes, this requirement is Not Applicable. One possible method for meeting this requirement is to require smart card logon for access to interactive accounts. Check that the "pam_cert_auth" setting is set to "true" in the "/etc/sssd/sssd.conf" file. Check that the "try_cert_auth" or "require_cert_auth" options are configured in both "/etc/pam.d/system-auth" and "/etc/pam.d/smartcard-auth" files with the following command: $ sudo grep cert_auth /etc/sssd/sssd.conf /etc/pam.d/* /etc/sssd/sssd.conf:pam_cert_auth = True /etc/pam.d/smartcard-auth:auth sufficient pam_sss.so try_cert_auth /etc/pam.d/system-auth:auth [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_sss.so try_cert_auth If "pam_cert_auth" is not set to "true" in "/etc/sssd/sssd.conf", this is a finding. If "pam_sss.so" is not set to "try_cert_auth" or "require_cert_auth" in both the "/etc/pam.d/smartcard-auth" and "/etc/pam.d/system-auth" files, this is a finding.

Fix: F-56355r824179_fix

Configure the operating system to use multifactor authentication for network access to privileged accounts. One possible method for meeting this requirement is to require smart card logon for access to interactive accounts; in which case, configure TOSS to use multifactor authentication for local access to accounts. Add or update the "pam_cert_auth" setting in the "/etc/sssd/sssd.conf" file to match the following line: [pam] pam_cert_auth = True Add or update "pam_sss.so" with "try_cert_auth" or "require_cert_auth" in the "/etc/pam.d/system-auth" and "/etc/pam.d/smartcard-auth" files based on the following examples: /etc/pam.d/smartcard-auth:auth sufficient pam_sss.so try_cert_auth /etc/pam.d/system-auth:auth [success=done authinfo_unavail=ignore ignore=ignore default=die] pam_sss.so try_cert_auth The "sssd" service must be restarted for the changes to take effect. To restart the "sssd" service, run the following command: $ sudo systemctl restart sssd.service

b
TOSS must disable account identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.
Medium - CCI-003627 - V-252953 - SV-252953r986584_rule
RMF Control
Severity
M
CCI
CCI-003627
Version
TOSS-04-020120
Vuln IDs
  • V-252953
Rule IDs
  • SV-252953r986584_rule
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.
Checks: C-56406r824181_chk

Verify the account identifiers (individuals, groups, roles, and devices) are disabled after 35 days of inactivity with the following command: Check the account inactivity value by performing the following command: $ sudo grep -i inactive /etc/default/useradd INACTIVE=35 If "INACTIVE" is set to "-1", a value greater than "35", or is commented out, this is a finding.

Fix: F-56356r986583_fix

Configure TOSS to disable account identifiers after 35 days of inactivity after the password expiration. Run the following command to change the configuration for useradd: $ sudo useradd -D -f 35 DOD recommendation is 35 days, but a lower value is acceptable. The value "-1" will disable this feature, and "0" will disable the account immediately after the password expires.

b
TOSS must automatically remove or disable emergency accounts after the crisis is resolved or 72 hours.
AC-2 - Medium - CCI-001682 - V-252954 - SV-252954r958508_rule
RMF Control
AC-2
Severity
M
CCI
CCI-001682
Version
TOSS-04-020140
Vuln IDs
  • V-252954
Rule IDs
  • SV-252954r958508_rule
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, TOSS can be integrated with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements.
Checks: C-56407r824184_chk

Verify emergency accounts have been provisioned with an expiration date of 72 hours. For every existing emergency account, run the following command to obtain its account expiration information. $ sudo chage -l system_account_name Verify each of these accounts has an expiration date set within 72 hours. If any emergency accounts have no expiration date set or do not expire within 72 hours, this is a finding. If there are no emergency accounts configured, this requirement is Not Applicable.

Fix: F-56357r824185_fix

If an emergency account must be created, configure the system to terminate the account after 72 hours with the following command to set an expiration date for the account. Substitute "system_account_name" with the account to be created. $ sudo chage -E `date -d "+3 days" +%Y-%m-%d` system_account_name The automatic expiration or disabling time period may be extended as needed until the crisis is resolved.

b
TOSS must reveal error messages only to authorized users.
SI-11 - Medium - CCI-001314 - V-252955 - SV-252955r958566_rule
RMF Control
SI-11
Severity
M
CCI
CCI-001314
Version
TOSS-04-020150
Vuln IDs
  • V-252955
Rule IDs
  • SV-252955r958566_rule
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.
Checks: C-56408r824187_chk

Verify the "/var/log/messages" file has a mode of "0640" or less permissive and is owned by the root user with the following command: $ sudo ls -l /var/log/messages -rw-r----- 1 root root 59782947 Jul 20 01:36 /var/log/messages If the "/var/log/messages" file has a mode more permissive than "0640", this is a finding. If the "/var/log/messages" file is not owned by "root", this is a finding. Verify the "/var/log" directory has a mode of "0755" or less permissive and is owned by the root user with the following command: $ sudo ls -ld /var/log/ drwxr-xr-x 1 root root 1200 Jul 19 03:39 /var/log If the "/var/log/" directory has a mode more permissive than "0755", this is a finding. If the "/var/log/" directory is not owned by "root", this is a finding.

Fix: F-56358r824188_fix

Change the permissions of the file "/var/log/messages" to "0640" and the ownership of the file to "root" by running the following commands: $ sudo chmod 0640 /var/log/messages $ sudo chown root /var/log/messages Change the permissions of the directory "/var/log/" to "0755" and the ownership of the directory to "root" by running the following commands: $ sudo chmod 0755 /var/log/ $ sudo chown root /var/log/

b
TOSS must protect wireless access to the system using authentication of users and/or devices.
AC-18 - Medium - CCI-001443 - V-252956 - SV-252956r991568_rule
RMF Control
AC-18
Severity
M
CCI
CCI-001443
Version
TOSS-04-020160
Vuln IDs
  • V-252956
Rule IDs
  • SV-252956r991568_rule
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. Satisfies: SRG-OS-000299-GPOS-00117, SRG-OS-000300-GPOS-00118, SRG-OS-000481-GPOS-00481
Checks: C-56409r824190_chk

Verify there are no wireless interfaces configured on the system with the following command: Note: This requirement is Not Applicable for systems that do not have physical wireless network radios. $ sudo nmcli device status DEVICE TYPE STATE CONNECTION virbr0 bridge connected virbr0 wlp7s0 wifi connected wifiSSID enp6s0 ethernet disconnected -- p2p-dev-wlp7s0 wifi-p2p disconnected -- lo loopback unmanaged -- virbr0-nic tun unmanaged -- If a wireless interface is configured and has not been documented and approved by the Information System Security Officer (ISSO), this is a finding.

Fix: F-56359r824191_fix

Configure the system to disable all wireless network interfaces with the following command: $ sudo nmcli radio all off

b
TOSS must automatically lock an account until the locked account is released by an administrator when three unsuccessful logon attempts in 15 minutes occur.
AC-7 - Medium - CCI-002238 - V-252957 - SV-252957r958736_rule
RMF Control
AC-7
Severity
M
CCI
CCI-002238
Version
TOSS-04-020170
Vuln IDs
  • V-252957
Rule IDs
  • SV-252957r958736_rule
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. Due to the scale of HPC systems and the number of users in question, it is impractical to require an administrator to unlock the user's account manually. Strong controls around automatic lock out, and typical (though not universal) use of strong MFA to enter an HPC system mitigate the concerns of a brute force attack being successful.
Checks: C-56410r824193_chk

Check that the system locks an account after three unsuccessful logon attempts within a period of 15 minutes until released by an administrator with the following commands. Note: If a centralized authentication platform (AD, IdM, LDAP, etc) is utilized for authentication, then this requirement is not applicable, to allow the centralized platform to solely manage user lockout. Verify the pam_faillock.so module is present in the "/etc/pam.d/system-auth" and " /etc/pam.d/password-auth" files: $ sudo grep pam_faillock.so /etc/pam.d/system-auth /etc/pam.d/password-auth /etc/pam.d/system-auth:auth required pam_faillock.so preauth /etc/pam.d/system-auth:auth required pam_faillock.so authfail /etc/pam.d/system-auth:account required pam_faillock.so /etc/pam.d/password-auth:auth required pam_faillock.so preauth /etc/pam.d/password-auth:auth required pam_faillock.so authfail /etc/pam.d/password-auth:account required pam_faillock.so preauth If the pam_failllock.so module is not present in the "/etc/pam.d/system-auth" and " /etc/pam.d/password-auth" files, this is a finding. Verify the "/etc/security/faillock.conf" file is configured to lock an account until released by an administrator after three unsuccessful logon attempts: $ sudo grep 'unlock_time =' /etc/security/faillock.conf unlock_time = 0 If the "unlock_time" option is not set to "0", is missing or commented out, this is a finding.

Fix: F-56360r824194_fix

Configure the operating system to lock an account until released by an administrator when three unsuccessful logon attempts occur in 15 minutes. Add and/or modify the appropriate sections of the "/etc/pam.d/system-auth" and "/etc/pam.d/password-auth" files to match the following lines: auth required pam_faillock.so preauth auth required pam_faillock.so authfail account required pam_faillock.so Add and/or modify the "/etc/security/faillock.conf" file to match the following line: unlock_time = 0

b
TOSS must require users to reauthenticate for privilege escalation.
Medium - CCI-004895 - V-252958 - SV-252958r987879_rule
RMF Control
Severity
M
CCI
CCI-004895
Version
TOSS-04-020180
Vuln IDs
  • V-252958
Rule IDs
  • SV-252958r987879_rule
Without reauthentication, 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 reauthenticate.
Checks: C-56411r824196_chk

Verify that "/etc/sudoers" has no occurrences of "!authenticate." Check that the "/etc/sudoers" file has no occurrences of "!authenticate" by running the following command: $ sudo grep -i authenticate /etc/sudoers /etc/sudoers.d/* If any occurrences of "!authenticate" return from the command, this is a finding.

Fix: F-56361r824197_fix

Remove any occurrence of "!authenticate" found in "/etc/sudoers" file or files in the "/etc/sudoers.d" directory.

b
TOSS must require users to provide a password for privilege escalation.
Medium - CCI-004895 - V-252959 - SV-252959r987879_rule
RMF Control
Severity
M
CCI
CCI-004895
Version
TOSS-04-020190
Vuln IDs
  • V-252959
Rule IDs
  • SV-252959r987879_rule
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 reauthenticate.
Checks: C-56412r986586_chk

Verify that "/etc/sudoers" has no occurrences of "NOPASSWD." Check that the "/etc/sudoers" file has no occurrences of "NOPASSWD" by running the following command: $ sudo grep -i nopasswd /etc/sudoers /etc/sudoers.d/* %admin ALL=(ALL) NOPASSWD: ALL If any occurrences of "NOPASSWD" are returned from the command and have not been documented with the information system security officer (ISSO) as an organizationally defined administrative group utilizing multifactor authentication (MFA), this is a finding.

Fix: F-56362r824200_fix

Remove any occurrence of "NOPASSWD" found in "/etc/sudoers" file or files in the "/etc/sudoers.d" directory.

b
All TOSS local interactive user accounts must be assigned a home directory upon creation.
CM-6 - Medium - CCI-000366 - V-252960 - SV-252960r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-020200
Vuln IDs
  • V-252960
Rule IDs
  • SV-252960r991589_rule
If local interactive users are not assigned a valid home directory, there is no place for the storage and control of files they should own.
Checks: C-56413r824202_chk

Verify all local interactive users on TOSS are assigned a home directory upon creation with the following command: $ sudo grep -i create_home /etc/login.defs CREATE_HOME yes If the value for "CREATE_HOME" parameter is not set to "yes", the line is missing, or the line is commented out, this is a finding.

Fix: F-56363r824203_fix

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

b
All TOSS local interactive user home directories must be group-owned by the home directory owner's primary group.
CM-6 - Medium - CCI-000366 - V-252961 - SV-252961r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-020210
Vuln IDs
  • V-252961
Rule IDs
  • SV-252961r991589_rule
If the Group Identifier (GID) of a local interactive user's home directory is not the same as the primary GID of the user, this would allow unauthorized access to the user's files, and users that share the same group may not be able to access files that they legitimately should.
Checks: C-56414r824205_chk

Verify the assigned home directory of all local interactive users is group-owned by that user's primary GID with the following command: Note: This may miss local interactive users that have been assigned a privileged UID. Evidence of interactive use may be obtained from a number of log files containing system logon information. The returned directory "/home/smithj" is used as an example. $ sudo ls -ld $(awk -F: '($3&gt;=1000)&amp;&amp;($7 !~ /nologin/){print $6}' /etc/passwd) drwxr-x--- 2 smithj admin 4096 Jun 5 12:41 smithj Check the user's primary group with the following command: $ sudo grep $(grep smithj /etc/passwd | awk -F: '{print $4}') /etc/group admin:x:250:smithj,jonesj,jacksons If the user home directory referenced in "/etc/passwd" is not group-owned by that user's primary GID, this is a finding.

Fix: F-56364r824206_fix

Change the group owner of a local interactive user's home directory to the group found in "/etc/passwd." To change the group owner of a local interactive user's home directory, use the following command: Note: The example will be for the user "smithj", who has a home directory of "/home/smithj", and has a primary group of users. $ sudo chgrp users /home/smithj

b
All TOSS local interactive users must have a home directory assigned in the /etc/passwd file.
CM-6 - Medium - CCI-000366 - V-252962 - SV-252962r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-020230
Vuln IDs
  • V-252962
Rule IDs
  • SV-252962r991589_rule
If local interactive users are not assigned a valid home directory, there is no place for the storage and control of files they should own.
Checks: C-56415r824208_chk

Verify local interactive users on TOSS have a home directory assigned with the following command: $ sudo pwck -r user 'lp': directory '/var/spool/lpd' does not exist user 'news': directory '/var/spool/news' does not exist user 'uucp': directory '/var/spool/uucp' does not exist user 'www-data': directory '/var/www' does not exist Ask the System Administrator (SA) if any users found without home directories are local interactive users. If the SA is unable to provide a response, check for users with a User Identifier (UID) of 1000 or greater with the following command: $ sudo awk -F: '($3&gt;=1000)&amp;&amp;($7 !~ /nologin/){print $1, $3, $6}' /etc/passwd If any interactive users do not have a home directory assigned, this is a finding.

Fix: F-56365r824209_fix

Assign home directories to all local interactive users on TOSS that currently do not have a home directory assigned.

c
The x86 Ctrl-Alt-Delete key sequence in TOSS must be disabled if a graphical user interface is installed.
CM-6 - High - CCI-000366 - V-252963 - SV-252963r991589_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
TOSS-04-020240
Vuln IDs
  • V-252963
Rule IDs
  • SV-252963r991589_rule
A locally logged-on user, who presses Ctrl-Alt-Delete when at the console, can reboot the system. If accidentally pressed, as could happen in the case of a mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. In a graphical user environment, risk of unintentional reboot from the Ctrl-Alt-Delete sequence is reduced because the user will be prompted before any action is taken.
Checks: C-56416r824211_chk

Verify TOSS is not configured to reboot the system when Ctrl-Alt-Delete is pressed when using a graphical user interface with the following command: Note: This requirement assumes the use of the TOSS default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. $ sudo grep logout /etc/dconf/db/local.d/* logout='' If the "logout" key is bound to an action, is commented out, or is missing, this is a finding.

Fix: F-56366r824212_fix

Configure the system to disable the Ctrl-Alt-Delete sequence when using a graphical user interface by creating or editing the /etc/dconf/db/local.d/00-disable-CAD file. Add the setting to disable the Ctrl-Alt-Delete sequence for a graphical user interface: [org/gnome/settings-daemon/plugins/media-keys] logout='' Note: The value above is set to two single quotations. Then update the dconf settings: $ sudo dconf update

b
TOSS must disable the user list at logon for graphical user interfaces.
CM-6 - Medium - CCI-000366 - V-252964 - SV-252964r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-020250
Vuln IDs
  • V-252964
Rule IDs
  • SV-252964r991589_rule
Leaving the user list enabled is a security risk since it allows anyone with physical access to the system to enumerate known user accounts without authenticated access to the system.
Checks: C-56417r824214_chk

Verify the operating system disables the user logon list for graphical user interfaces with the following command: Note: This requirement assumes the use of the TOSS default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. $ sudo gsettings get org.gnome.login-screen disable-user-list true If the setting is "false", this is a finding.

Fix: F-56367r824215_fix

Configure the operating system to disable the user list at logon for graphical user interfaces. Create a database to contain the system-wide screensaver settings (if it does not already exist) with the following command: Note: The example below is using the database "local" for the system, so if the system is using another database in "/etc/dconf/profile/user", the file should be created under the appropriate subdirectory. $ sudo touch /etc/dconf/db/local.d/02-login-screen [org/gnome/login-screen] disable-user-list=true Update the system databases: $ sudo dconf update

b
TOSS must display the date and time of the last successful account logon upon an SSH logon.
CM-6 - Medium - CCI-000366 - V-252965 - SV-252965r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-020260
Vuln IDs
  • V-252965
Rule IDs
  • SV-252965r991589_rule
Providing users with feedback on when account accesses via SSH last occurred facilitates user recognition and reporting of unauthorized account use.
Checks: C-56418r824217_chk

Verify SSH provides users with feedback on when account accesses last occurred with the following command: $ sudo grep -i printlastlog /etc/ssh/sshd_config PrintLastLog yes If the "PrintLastLog" keyword is set to "no", is missing, or is commented out, this is a finding.

Fix: F-56368r824218_fix

Configure SSH to provide users with feedback on when account accesses last occurred by setting the required configuration options in "/etc/pam.d/sshd" or in the "sshd_config" file used by the system ("/etc/ssh/sshd_config" will be used in the example) (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor). Modify the "PrintLastLog" line in "/etc/ssh/sshd_config" to match the following: PrintLastLog yes The SSH service must be restarted for changes to "sshd_config" to take effect.

c
TOSS must not allow accounts configured with blank or null passwords.
CM-6 - High - CCI-000366 - V-252966 - SV-252966r991589_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
TOSS-04-020270
Vuln IDs
  • V-252966
Rule IDs
  • SV-252966r991589_rule
If an account has an empty password, anyone could log on and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.
Checks: C-56419r824220_chk

To verify that null passwords cannot be used, run the following command: $ sudo grep -i permitemptypasswords /etc/ssh/sshd_config PermitEmptyPasswords no If "PermitEmptyPasswords" is set to "yes", this is a finding.

Fix: F-56369r824221_fix

Edit the following line in "etc/ssh/sshd_config" to prevent logons with empty passwords. PermitEmptyPasswords no The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

b
TOSS must not have unnecessary accounts.
CM-6 - Medium - CCI-000366 - V-252967 - SV-252967r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-020280
Vuln IDs
  • V-252967
Rule IDs
  • SV-252967r991589_rule
Accounts providing no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system.
Checks: C-56420r824223_chk

Verify all accounts on the system are assigned to an active system, application, or user account. Obtain the list of authorized system accounts from the Information System Security Officer (ISSO). Check the system accounts on the system with the following command: $ sudo more /etc/passwd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin sync:x:5:0:sync:/sbin:/bin/sync shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown halt:x:7:0:halt:/sbin:/sbin/halt games:x:12:100:games:/usr/games:/sbin/nologin gopher:x:13:30:gopher:/var/gopher:/sbin/nologin Accounts such as "games" and "gopher" are not authorized accounts as they do not support authorized system functions. If the accounts on the system do not match the provided documentation, or accounts that do not support an authorized system function are present, this is a finding.

Fix: F-56370r824224_fix

Configure the system so all accounts on the system are assigned to an active system, application, or user account. Remove accounts that do not support approved system activities or that allow for a normal user to perform administrative-level actions. Document all authorized accounts on the system.

b
TOSS must define default permissions for all authenticated users in such a way that the user can only read and modify their own files.
CM-6 - Medium - CCI-000366 - V-252968 - SV-252968r991590_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-020290
Vuln IDs
  • V-252968
Rule IDs
  • SV-252968r991590_rule
Setting the most restrictive default permissions ensures that when new accounts are created, they do not have unnecessary access.
Checks: C-56421r824226_chk

Verify TOSS defines default permissions for all authenticated users in such a way that the user can only read and modify their own files. Check for the value of the "UMASK" parameter in "/etc/login.defs" file with the following command: Note: If the value of the "UMASK" parameter is set to "000" in "/etc/login.defs" file, the Severity is raised to a CAT I. $ grep -i umask /etc/login.defs UMASK 077 If the value for the "UMASK" parameter is not "077", or the "UMASK" parameter is missing or is commented out, this is a finding.

Fix: F-56371r824227_fix

Configure TOSS to define default permissions for all authenticated users in such a way that the user can only read and modify their own files. Add or edit the line for the "UMASK" parameter in "/etc/login.defs" file to "077": UMASK 077

b
All TOSS local interactive user home directories must have mode 0770 or less permissive.
CM-6 - Medium - CCI-000366 - V-252969 - SV-252969r991592_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-020300
Vuln IDs
  • V-252969
Rule IDs
  • SV-252969r991592_rule
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.
Checks: C-56422r824229_chk

Verify the operating system limits the ability of non-privileged users to grant other users direct access to the contents of their home directories/folders. Ensure that the user permissions on all user home directories is set to 770 permissions with the following command: $ find $(awk -F: '($3&gt;=1000)&amp;&amp;($7 !~ /nologin/){print $6}' /etc/passwd) -maxdepth 0 -not -perm 770 -ls If there is any output, this is a finding.

Fix: F-56372r824230_fix

Change the mode of interactive user's home directories to "0770." To change the mode of a local interactive user's home directory, use the following command: Note: The example will be for the user "smithj." $ sudo chmod 0770 /home/smithj

b
All TOSS local interactive user home directories must be owned by root.
CM-6 - Medium - CCI-000366 - V-252970 - SV-252970r991592_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-020310
Vuln IDs
  • V-252970
Rule IDs
  • SV-252970r991592_rule
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.
Checks: C-56423r824232_chk

Check that all user home directories are owned by the root user with the following command: $ find $(awk -F: '($3&gt;=1000)&amp;&amp;($7 !~ /nologin/){print $6}' /etc/passwd) -maxdepth 0 -not -user root -ls If there is any output, this is a finding.

Fix: F-56373r824233_fix

Change the owner of interactive user's home directories to root. To change the owner of a local interactive user's home directory, use the following command: Note: The example will be for the user "smithj." $ sudo chown root /home/smithj

b
All TOSS local interactive user home directories must be owned by the user's primary group.
CM-6 - Medium - CCI-000366 - V-252971 - SV-252971r991592_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-020320
Vuln IDs
  • V-252971
Rule IDs
  • SV-252971r991592_rule
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.
Checks: C-56424r824235_chk

Check that all user home directories are owned by the user's primary group with the following command: $ awk -F: '($3&gt;=1000)&amp;&amp;($7 !~ /nologin/)&amp;&amp;("stat -c '%g' " $6 | getline dir_group)&amp;&amp;(dir_group!=$4){print $1,$6}' /etc/passwd admin /home/admin Check each user's primary group with the following command (example command is for the "admin" user): $ sudo grep "^admin" /etc/group admin:x:250:smithj,jonesj,jacksons If the user home directory referenced in "/etc/passwd" is not group-owned by that user's primary GID, this is a finding.

Fix: F-56374r824236_fix

Change the group owner of interactive user's home directories to that users primary group. To change the group owner of a local interactive user's home directory, use the following command: Note: The example will be for the user "smithj." $ sudo chgrp smithj /home/smithj

b
TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/shadow.
AC-2 - Medium - CCI-000018 - V-252972 - SV-252972r958368_rule
RMF Control
AC-2
Severity
M
CCI
CCI-000018
Version
TOSS-04-030000
Vuln IDs
  • V-252972
Rule IDs
  • SV-252972r958368_rule
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. Satisfies: SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221
Checks: C-56425r824238_chk

Verify TOSS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/shadow." Check the auditing rules in "/etc/audit/audit.rules" with the following command: $ sudo grep /etc/shadow /etc/audit/audit.rules -w /etc/shadow -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier. The string following "-k" does not need to match the example output above.

Fix: F-56375r824239_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/shadow." Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/shadow -p wa -k identity The audit daemon must be restarted for the changes to take effect. Note: The "-k" allows for specifying an arbitrary identifier. The string following "-k" does not need to match the example output above.

b
TOSS audit records must contain information to establish what type of events occurred, when the events occurred, the source of events, where events occurred, and the outcome of events.
AU-3 - Medium - CCI-000130 - V-252973 - SV-252973r986588_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030010
Vuln IDs
  • V-252973
Rule IDs
  • SV-252973r986588_rule
Without establishing what type of events occurred, when events occurred, the source of events, where events occurred, and the outcome of events, 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 TOSS audit logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured TOSS system. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000038-GPOS-00016, SRG-OS-000039-GPOS-00017, SRG-OS-000040-GPOS-00018, SRG-OS-000041-GPOS-00019, SRG-OS-000042-GPOS-00021, SRG-OS-000047-GPOS-00023, SRG-OS-000051-GPOS-00024, SRG-OS-000064-GPOS-00033, SRG-OS-000241-GPOS-00091, SRG-OS-000254-GPOS-00095, SRG-OS-000327-GPOS-00127, SRG-OS-000342-GPOS-00133, SRG-OS-000348-GPOS-00136, SRG-OS-000349-GPOS-00137, SRG-OS-000350-GPOS-00138, SRG-OS-000351-GPOS-00139, SRG-OS-000353-GPOS-00141, SRG-OS-000354-GPOS-00142, SRG-OS-000365-GPOS-00152, SRG-OS-000474-GPOS-00219, SRG-OS-000479-GPOS-00224
Checks: C-56426r824241_chk

Verify the audit service is configured to produce audit records. Check that the audit service is installed properly with the following command: $ sudo yum list installed audit If the "audit" package is not installed, this is a finding. Check that the audit service is properly running and active on the system with the following command: $ sudo systemctl is-active auditd.service active If the command above returns "inactive", this is a finding.

Fix: F-56376r824242_fix

Configure the audit service to produce audit records containing the information needed to establish when (date and time) an event occurred. Install the audit service (if the audit service is not already installed) with the following command: $ sudo yum install audit Enable the audit service with the following command: $ sudo systemctl enable auditd.service Start the audit service with the following command: $ sudo systemctl start auditd.service

b
TOSS must generate audit records containing the full-text recording of privileged commands.
AU-3 - Medium - CCI-000135 - V-252974 - SV-252974r958422_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000135
Version
TOSS-04-030060
Vuln IDs
  • V-252974
Rule IDs
  • SV-252974r958422_rule
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.
Checks: C-56427r824244_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "sudo" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w sudo /etc/audit/audit.rules -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid&gt;=1000 -F auid!=unset -k priv_cmd If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56377r824245_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "sudo" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd The audit daemon must be restarted for the changes to take effect.

b
TOSS must alert the ISSO and SA (at a minimum) in the event of an audit processing failure.
AU-5 - Medium - CCI-000139 - V-252975 - SV-252975r958424_rule
RMF Control
AU-5
Severity
M
CCI
CCI-000139
Version
TOSS-04-030080
Vuln IDs
  • V-252975
Rule IDs
  • SV-252975r958424_rule
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.
Checks: C-56428r824247_chk

Verify that the SA and ISSO (at a minimum) are notified in the event of an audit processing failure. Check that TOSS notifies the SA and ISSO (at a minimum) in the event of an audit processing failure with the following command: $ sudo grep action_mail_acct /etc/audit/auditd.conf action_mail_acct = root If the value of the "action_mail_acct" keyword is not set to "root" and/or other accounts for security personnel, the "action_mail_acct" keyword is missing, or the retuned line is commented out, ask the system administrator to indicate how they and the ISSO are notified of an audit process failure. If there is no evidence of the proper personnel being notified of an audit processing failure, this is a finding.

Fix: F-56378r824248_fix

Configure "auditd" service to notify the SA and ISSO in the event of an audit processing failure. Edit the following line in "/etc/audit/auditd.conf" to ensure that administrators are notified via email for those situations: action_mail_acct = root

b
TOSS must take appropriate action when an audit processing failure occurs.
AU-5 - Medium - CCI-000140 - V-252976 - SV-252976r958426_rule
RMF Control
AU-5
Severity
M
CCI
CCI-000140
Version
TOSS-04-030090
Vuln IDs
  • V-252976
Rule IDs
  • SV-252976r958426_rule
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.
Checks: C-56429r824250_chk

Verify TOSS takes the appropriate action when an audit processing failure occurs. Check that TOSS takes the appropriate action when an audit processing failure occurs with the following command: $ sudo grep disk_error_action /etc/audit/auditd.conf disk_error_action = HALT If the value of the "disk_error_action" option is not "SYSLOG", "SINGLE", or "HALT", or the line is commented out, ask the system administrator to indicate how the system takes appropriate action when an audit process failure occurs. If there is no evidence of appropriate action, this is a finding.

Fix: F-56379r824251_fix

Configure TOSS to shut down by default upon audit failure (unless availability is an overriding concern). Add or update the following line (depending on configuration "disk_error_action" can be set to "SYSLOG" or "SINGLE" depending on configuration) in "/etc/audit/auditd.conf" file: disk_error_action = HALT If availability has been determined to be more important, and this decision is documented with the ISSO, configure the operating system to notify system administration staff and ISSO staff in the event of an audit processing failure by setting the "disk_error_action" to "SYSLOG."

b
TOSS audit logs must have a mode of 0600 or less permissive to prevent unauthorized read access.
AU-9 - Medium - CCI-000162 - V-252977 - SV-252977r958434_rule
RMF Control
AU-9
Severity
M
CCI
CCI-000162
Version
TOSS-04-030120
Vuln IDs
  • V-252977
Rule IDs
  • SV-252977r958434_rule
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. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
Checks: C-56430r824253_chk

Verify the audit logs have a mode of "0600" or less permissive. First, determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the location of the audit log file, check if the audit log has a mode of "0600" or less permissive with the following command: $ sudo ls -l /var/log/audit/audit.log -rw------- 1 root root 908084 Jul 19 23:10 /var/log/audit/audit.log If the audit log has a mode more permissive than "0600", this is a finding.

Fix: F-56380r824254_fix

Configure the audit log to be protected from unauthorized read access by setting the correct permissive mode with the following command: $ sudo chmod 0600 [audit_log_file] Replace "[audit_log_file]" to the correct audit log path, by default this location is "/var/log/audit/audit.log."

b
TOSS audit log directory must have a mode of 0700 or less permissive to prevent unauthorized read access.
AU-9 - Medium - CCI-000162 - V-252978 - SV-252978r958434_rule
RMF Control
AU-9
Severity
M
CCI
CCI-000162
Version
TOSS-04-030130
Vuln IDs
  • V-252978
Rule IDs
  • SV-252978r958434_rule
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. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
Checks: C-56431r824256_chk

Verify the audit log directory has a mode of "0700" or less permissive. First, determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the directory where the audit log file is located, check if the audit log directory has a mode of "0700" or less permissive with the following command: $ sudo ls -ld /var/log/audit/ drwx------. 2 root root 99 Jul 19 07:32 /var/log/audit/ If the audit log directory has a mode more permissive than "0700", this is a finding.

Fix: F-56381r824257_fix

Configure the audit log directory to be protected from unauthorized read access by setting the correct permissive mode with the following command: $ sudo chmod 0700 [audit_log_directory] Replace "[audit_log_directory]" to the correct audit log directory path, by default this location is "/var/log/audit."

b
TOSS audit logs must be owned by user root to prevent unauthorized read access.
AU-9 - Medium - CCI-000162 - V-252979 - SV-252979r958434_rule
RMF Control
AU-9
Severity
M
CCI
CCI-000162
Version
TOSS-04-030140
Vuln IDs
  • V-252979
Rule IDs
  • SV-252979r958434_rule
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. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
Checks: C-56432r824259_chk

Verify the audit logs are owned by user root. First, determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the location of the audit log file, check if the audit log is owned by user "root" with the following command: $ sudo ls -l /var/log/audit/audit.log -rw------- 1 root root 908084 Jul 19 23:10 /var/log/audit/audit.log If the audit log is not owned by user "root", this is a finding.

Fix: F-56382r824260_fix

Configure the audit log and audit log directory to be protected from unauthorized read access, by setting the correct owner as "root" with the following command: $ sudo chown root [audit_log_file] Replace "[audit_log_file]" to the correct audit log path, by default this location is "/var/log/audit/audit.log." Configure the audit log to be owned by root by configuring the log group in the /etc/audit/auditd.conf file: log_group = root

b
TOSS audit logs must be owned by group root to prevent unauthorized read access.
AU-9 - Medium - CCI-000162 - V-252980 - SV-252980r958434_rule
RMF Control
AU-9
Severity
M
CCI
CCI-000162
Version
TOSS-04-030150
Vuln IDs
  • V-252980
Rule IDs
  • SV-252980r958434_rule
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. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
Checks: C-56433r824262_chk

Verify the audit logs are owned by group root. First, determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the location of the audit log file, check if the audit log is owned by group "root" with the following command: $ sudo ls -l /var/log/audit/audit.log -rw------- 1 root root 908084 Jul 19 23:10 /var/log/audit/audit.log If the audit log is not owned by group "root", this is a finding.

Fix: F-56383r824263_fix

Configure the audit log and audit log directory to be protected from unauthorized read access, by setting the correct owner as "root" with the following command: $ sudo chgrp root [audit_log_file] Replace "[audit_log_file]" to the correct audit log path, by default this location is "/var/log/audit/audit.log." Configure the audit log to be owned by root by configuring the log group in the /etc/audit/auditd.conf file: log_group = root

b
TOSS audit log directory must be owned by user root to prevent unauthorized read access.
AU-9 - Medium - CCI-000162 - V-252981 - SV-252981r958434_rule
RMF Control
AU-9
Severity
M
CCI
CCI-000162
Version
TOSS-04-030160
Vuln IDs
  • V-252981
Rule IDs
  • SV-252981r958434_rule
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. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
Checks: C-56434r824265_chk

Verify the audit log directory is owned by user root. First, determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the directory where the audit log file is located, check if the directory is owned by user "root" with the following command: $ sudo ls -ld /var/log/audit/ drwx------. 2 root root 99 Jul 19 07:32 /var/log/audit/ If the audit log directory is not owned by user "root", this is a finding.

Fix: F-56384r824266_fix

Configure the audit log directory to be protected from unauthorized read access, by setting the correct owner as "root" with the following command: $ sudo chown root [audit_log_directory] Replace "[audit_log_directory]" to the correct audit log directory path, by default this location is "/var/log/audit/."

b
TOSS audit log directory must be owned by group root to prevent unauthorized read access.
AU-9 - Medium - CCI-000162 - V-252982 - SV-252982r958434_rule
RMF Control
AU-9
Severity
M
CCI
CCI-000162
Version
TOSS-04-030170
Vuln IDs
  • V-252982
Rule IDs
  • SV-252982r958434_rule
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. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
Checks: C-56435r824268_chk

Verify the audit log directory is owned by group root. First, determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the directory where the audit log file is located, check if the directory is owned by group "root" with the following command: $ sudo ls -ld /var/log/audit/ drwx------. 2 root root 99 Jul 19 07:32 /var/log/audit/ If the audit log directory is not owned by group "root", this is a finding.

Fix: F-56385r824269_fix

Configure the audit log directory to be protected from unauthorized read access, by setting the correct group as "root" with the following command: $ sudo chgrp root [audit_log_directory] Replace "[audit_log_directory]" to the correct audit log directory path, by default this location is "/var/log/audit/."

b
The TOSS audit system must protect auditing rules from unauthorized change.
AU-9 - Medium - CCI-000162 - V-252983 - SV-252983r958434_rule
RMF Control
AU-9
Severity
M
CCI
CCI-000162
Version
TOSS-04-030180
Vuln IDs
  • V-252983
Rule IDs
  • SV-252983r958434_rule
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 TOSS system activity. In immutable mode, unauthorized users cannot execute changes to the audit system to potentially hide malicious activity and then put the audit rules back. A system reboot would be noticeable and a system administrator could then investigate the unauthorized changes. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
Checks: C-56436r824271_chk

Verify the audit system prevents unauthorized changes with the following command: $ sudo grep "^\s*[^#]" /etc/audit/audit.rules | tail -1 -e 2 If the audit system is not set to be immutable by adding the "-e 2" option to the "/etc/audit/audit.rules", this is a finding.

Fix: F-56386r824272_fix

Configure the audit system to set the audit rules to be immutable by adding the following line to the end of "/etc/audit/rules.d/audit.rules": -e 2 Note: Once set, the system must be rebooted for auditing to be changed. It is recommended to add this option as the last step in securing the system.

b
The TOSS audit system must protect logon UIDs from unauthorized change.
AU-9 - Medium - CCI-000162 - V-252984 - SV-252984r958434_rule
RMF Control
AU-9
Severity
M
CCI
CCI-000162
Version
TOSS-04-030190
Vuln IDs
  • V-252984
Rule IDs
  • SV-252984r958434_rule
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 TOSS system activity. In immutable mode, unauthorized users cannot execute changes to the audit system to potentially hide malicious activity and then put the audit rules back. A system reboot would be noticeable and a system administrator could then investigate the unauthorized changes. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029
Checks: C-56437r824274_chk

Verify the audit system prevents unauthorized changes to logon UIDs with the following command: $ sudo grep -i immutable /etc/audit/audit.rules --loginuid-immutable If the login UIDs are not set to be immutable by adding the "--loginuid-immutable" option to the "/etc/audit/audit.rules", this is a finding.

Fix: F-56387r824275_fix

Configure the audit system to set the logon UIDs to be immutable by adding the following line to "/etc/audit/rules.d/audit.rules": --loginuid-immutable

b
Successful/unsuccessful uses of the "chage" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252985 - SV-252985r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030310
Vuln IDs
  • V-252985
Rule IDs
  • SV-252985r958412_rule
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 "chage" command is used to change or view user password expiry information. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56438r824277_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "chage" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w chage /etc/audit/audit.rules -a always,exit -F path=/usr/bin/chage -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-chage If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56388r824278_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chage" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=unset -k privileged-chage The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "chcon" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252986 - SV-252986r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030320
Vuln IDs
  • V-252986
Rule IDs
  • SV-252986r958412_rule
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 "chcon" command is used to change file SELinux security context. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56439r824280_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "chcon" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w chcon /etc/audit/audit.rules -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56389r824281_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chcon" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the ssh-agent in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252987 - SV-252987r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030330
Vuln IDs
  • V-252987
Rule IDs
  • SV-252987r958412_rule
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 "ssh-agent" is a program to hold private keys used for public key authentication. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56440r824283_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "ssh-agent" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep ssh-agent /etc/audit/audit.rules -a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-ssh If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56390r824284_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ssh-agent" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "passwd" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252988 - SV-252988r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030340
Vuln IDs
  • V-252988
Rule IDs
  • SV-252988r958412_rule
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 "passwd" command is used to change passwords for user accounts. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56441r824286_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "passwd" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w passwd /etc/audit/audit.rules -a always,exit -F path=/usr/bin/passwd -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-passwd If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56391r824287_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "passwd" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -k privileged-passwd The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of postdrop in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252989 - SV-252989r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030350
Vuln IDs
  • V-252989
Rule IDs
  • SV-252989r958412_rule
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 "postdrop" command creates a file in the maildrop directory and copies its standard input to the file. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56442r824289_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "postdrop" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "postdrop" /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-unix-update If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56392r824290_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "postdrop" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/postdrop -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of postqueue in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252990 - SV-252990r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030360
Vuln IDs
  • V-252990
Rule IDs
  • SV-252990r958412_rule
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 "postqueue" command implements the Postfix user interface for queue management. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56443r824292_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "postqueue" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "postqueue" /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-unix-update If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56393r824293_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "postqueue" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/postqueue -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of setsebool in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252991 - SV-252991r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030370
Vuln IDs
  • V-252991
Rule IDs
  • SV-252991r958412_rule
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 "setsebool" command sets the current state of a particular SELinux boolean or a list of booleans to a given value. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56444r824295_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "setsebool" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "setsebool" /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-unix-update If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56394r824296_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "setsebool" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/setsebool -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the ssh-keysign in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252992 - SV-252992r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030380
Vuln IDs
  • V-252992
Rule IDs
  • SV-252992r958412_rule
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 "ssh-keysign" program is an SSH helper program for host-based authentication. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56445r824298_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "ssh-keysign" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep ssh-keysign /etc/audit/audit.rules -a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-ssh If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56395r824299_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ssh-keysign" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/libexec/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=unset -k privileged-ssh The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "setfacl" command in RTOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252993 - SV-252993r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030390
Vuln IDs
  • V-252993
Rule IDs
  • SV-252993r958412_rule
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 "setfacl" command is used to set file access control lists. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56446r824301_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "setfacl" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w setfacl /etc/audit/audit.rules -a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56396r824302_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "setfacl" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "pam_timestamp_check" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252994 - SV-252994r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030400
Vuln IDs
  • V-252994
Rule IDs
  • SV-252994r958412_rule
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 "pam_timestamp_check" command is used to check if the default timestamp is valid. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56447r824304_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "pam_timestamp_check" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w pam_timestamp_check /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-pam_timestamp_check If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56397r824305_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "pam_timestamp_check" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=unset -k privileged-pam_timestamp_check The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "newgrp" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252995 - SV-252995r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030410
Vuln IDs
  • V-252995
Rule IDs
  • SV-252995r958412_rule
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 "newgrp" command is used to change the current group ID during a login session. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56448r824307_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "newgrp" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w newgrp /etc/audit/audit.rules -a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid&gt;=1000 -F auid!=unset -k priv_cmd If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56398r824308_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "newgrp" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "init_module" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252996 - SV-252996r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030420
Vuln IDs
  • V-252996
Rule IDs
  • SV-252996r958412_rule
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 "init_module" command is used to load a kernel module. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56449r824310_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "init_module" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "init_module" /etc/audit/audit.rules -a always,exit -F arch=b32 -S init_module -F auid&gt;=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S init_module -F auid&gt;=1000 -F auid!=unset -k module_chng If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56399r824311_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "init_module" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S init_module -F auid>=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S init_module -F auid>=1000 -F auid!=unset -k module_chng The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "rename" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252997 - SV-252997r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030430
Vuln IDs
  • V-252997
Rule IDs
  • SV-252997r958412_rule
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 "rename" command will rename the specified files by replacing the first occurrence of expression in their name by replacement. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56450r824313_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "rename" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "rename" /etc/audit/audit.rules -a always,exit -F arch=b32 -S rename -F auid&gt;=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S rename -F auid&gt;=1000 -F auid!=unset -k delete If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56400r824314_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "rename" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S rename -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S rename -F auid>=1000 -F auid!=unset -k delete The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "renameat" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252998 - SV-252998r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030440
Vuln IDs
  • V-252998
Rule IDs
  • SV-252998r958412_rule
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 "renameat" command renames a file, moving it between directories if required. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56451r824316_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "renameat" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "renameat" /etc/audit/audit.rules -a always,exit -F arch=b32 -S renameat -F auid&gt;=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S renameat -F auid&gt;=1000 -F auid!=unset -k delete If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56401r824317_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "renameat" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S renameat -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S renameat -F auid>=1000 -F auid!=unset -k delete The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "rmdir" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-252999 - SV-252999r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030450
Vuln IDs
  • V-252999
Rule IDs
  • SV-252999r958412_rule
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 "rmdir" command removes empty directories. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56452r824319_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "rmdir" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "rmdir" /etc/audit/audit.rules -a always,exit -F arch=b32 -S rmdir -F auid&gt;=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S rmdir -F auid&gt;=1000 -F auid!=unset -k delete If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56402r824320_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "rmdir" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S rmdir -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S rmdir -F auid>=1000 -F auid!=unset -k delete The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "unlink" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-253000 - SV-253000r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030460
Vuln IDs
  • V-253000
Rule IDs
  • SV-253000r958412_rule
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 "unlink" command deletes a name from the filesystem. If that name was the last link to a file and no processes have the file open, the file is deleted and the space it was using is made available for reuse. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56453r824322_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "unlink" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "unlink" /etc/audit/audit.rules -a always,exit -F arch=b32 -S unlink -F auid&gt;=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S unlink -F auid&gt;=1000 -F auid!=unset -k delete If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56403r824323_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "unlink" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S unlink -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S unlink -F auid>=1000 -F auid!=unset -k delete The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "unlinkat" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-253001 - SV-253001r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030470
Vuln IDs
  • V-253001
Rule IDs
  • SV-253001r958412_rule
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 "unlinkat" system call operates in exactly the same way as either "unlink" or "rmdir" except for the differences described in the manual page. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56454r824325_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "unlinkat" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "unlinkat" /etc/audit/audit.rules -a always,exit -F arch=b32 -S unlinkat -F auid&gt;=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S unlinkat -F auid&gt;=1000 -F auid!=unset -k delete If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56404r824326_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "unlinkat" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S unlinkat -F auid>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S unlinkat -F auid>=1000 -F auid!=unset -k delete The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "finit_module" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-253002 - SV-253002r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030480
Vuln IDs
  • V-253002
Rule IDs
  • SV-253002r958412_rule
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 "finit_module" command is used to load a kernel module. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56455r824328_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "finit_module" syscall by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "finit_module" /etc/audit/audit.rules -a always,exit -F arch=b32 -S finit_module -F auid&gt;=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S finit_module -F auid&gt;=1000 -F auid!=unset -k module_chng If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56405r824329_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "finit_module" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S finit_module -F auid>=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S finit_module -F auid>=1000 -F auid!=unset -k module_chng The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "delete_module" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-253003 - SV-253003r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030490
Vuln IDs
  • V-253003
Rule IDs
  • SV-253003r958412_rule
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 "delete_module" command is used to unload a kernel module. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56456r824331_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "delete_module" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "delete_module" /etc/audit/audit.rules -a always,exit -F arch=b32 -S delete_module -F auid&gt;=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S delete_module -F auid&gt;=1000 -F auid!=unset -k module_chng If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56406r824332_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "delete_module" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S delete_module -F auid>=1000 -F auid!=unset -k module_chng -a always,exit -F arch=b64 -S delete_module -F auid>=1000 -F auid!=unset -k module_chng The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "crontab" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-253004 - SV-253004r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030500
Vuln IDs
  • V-253004
Rule IDs
  • SV-253004r958412_rule
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 "crontab" command is used to maintain crontab files for individual users. Crontab is the program used to install, remove, or list the tables used to drive the cron daemon. This is similar to the task scheduler used in other operating systems. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56457r824334_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "crontab" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w crontab /etc/audit/audit.rules -a always,exit -F path=/usr/bin/crontab -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-crontab If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56407r824335_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "crontab" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -k privileged-crontab The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "chsh" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-253005 - SV-253005r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030510
Vuln IDs
  • V-253005
Rule IDs
  • SV-253005r958412_rule
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 "chsh" command is used to change the login shell. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56458r824337_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "chsh" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w chsh /etc/audit/audit.rules -a always,exit -F path=/usr/bin/chsh -F perm=x -F auid&gt;=1000 -F auid!=unset -k priv_cmd If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56408r824338_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chsh" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=unset -k priv_cmd The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of setfiles in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-253006 - SV-253006r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030520
Vuln IDs
  • V-253006
Rule IDs
  • SV-253006r958412_rule
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 "setfiles" command is primarily used to initialize the security context fields (extended attributes) on one or more filesystems (or parts of them). Usually, it is initially run as part of the SELinux installation process (a step commonly known as labeling). When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56459r824340_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "setfiles" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "setfiles" /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged-unix-update If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56409r824341_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "setfiles" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/setfiles -F perm=x -F auid>=1000 -F auid!=unset -k privileged-unix-update The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "chacl" command in TOSS must generate an audit record.
AU-3 - Medium - CCI-000130 - V-253007 - SV-253007r958412_rule
RMF Control
AU-3
Severity
M
CCI
CCI-000130
Version
TOSS-04-030540
Vuln IDs
  • V-253007
Rule IDs
  • SV-253007r958412_rule
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 "chacl" command is used to change the access control list of a file or directory. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215
Checks: C-56460r824343_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "chacl" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w chacl /etc/audit/audit.rules -a always,exit -F path=/usr/bin/chacl -F perm=x -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56410r824344_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chacl" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
TOSS must allow only the Information System Security Manager (ISSM) (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.
AU-12 - Medium - CCI-000171 - V-253008 - SV-253008r958444_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000171
Version
TOSS-04-030550
Vuln IDs
  • V-253008
Rule IDs
  • SV-253008r958444_rule
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.
Checks: C-56461r824346_chk

Verify that the files in directory "/etc/audit/rules.d/" and "/etc/audit/auditd.conf" file have a mode of "0640" or less permissive by using the following commands: $ sudo ls -l /etc/audit/rules.d -rw-r----- 1 root root 1280 Feb 16 17:09 audit.rules $ sudo ls -l /etc/audit/auditd.conf -rw-r----- 1 root root 621 Sep 22 17:19 auditd.conf If the files in the "/etc/audit/rules.d/" directory or the "/etc/audit/auditd.conf" file have a mode more permissive than "0640", this is a finding.

Fix: F-56411r824347_fix

Configure the files in directory "/etc/audit/rules.d/" and the "/etc/audit/auditd.conf" file to have a mode of "0640" with the following commands: $ sudo chmod 0640 /etc/audit/rules.d/audit.rules $ sudo chmod 0640 /etc/audit/rules.d/[customrulesfile].rules $ sudo chmod 0640 /etc/audit/auditd.conf

b
Successful/unsuccessful uses of the chmod system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253009 - SV-253009r958446_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-030560
Vuln IDs
  • V-253009
Rule IDs
  • SV-253009r958446_rule
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 "chmod" system calls are used to change file permissions. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206
Checks: C-56462r824349_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "chmod" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w chmod /etc/audit/audit.rules -a always,exit -F arch=b32 -S chmod -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chmod -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56412r824350_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chmod" command by adding or updating the following line to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the chown system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253010 - SV-253010r958446_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-030570
Vuln IDs
  • V-253010
Rule IDs
  • SV-253010r958446_rule
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 "chown" system call is used to change file owner and group. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206
Checks: C-56463r824352_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "chown" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w chown /etc/audit/audit.rules -a always,exit -F arch=b32 -S chown -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chown -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56413r824353_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chown" command by adding or updating the following line to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the creat system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253011 - SV-253011r958446_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-030580
Vuln IDs
  • V-253011
Rule IDs
  • SV-253011r958446_rule
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 "creat" system call is used to open and possibly create a file or device. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219
Checks: C-56464r824355_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "creat" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -iw creat /etc/audit/audit.rules -a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56414r824356_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "creat" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the fchmod system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253012 - SV-253012r958446_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-030590
Vuln IDs
  • V-253012
Rule IDs
  • SV-253012r958446_rule
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 "fchmod" system call is used to change permissions of a file. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206
Checks: C-56465r824358_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "fchmod" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w fchmod /etc/audit/audit.rules -a always,exit -F arch=b32 -S fchmod -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchmod -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56415r824359_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchmod" system call by adding or updating the following line to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the fchmodat system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253013 - SV-253013r958446_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-030600
Vuln IDs
  • V-253013
Rule IDs
  • SV-253013r958446_rule
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 "fchmodat" system call is used to change permissions of a file relative to a directory file descriptor. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206
Checks: C-56466r824361_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "fchmodat" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w fchmodat /etc/audit/audit.rules -a always,exit -F arch=b32 -S fchmodat -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchmodat -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56416r824362_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchmodat" system call by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the fchown system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253014 - SV-253014r958446_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-030610
Vuln IDs
  • V-253014
Rule IDs
  • SV-253014r958446_rule
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 "fchown" system call is used to change the ownership of a file referred to by the open file descriptor. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206
Checks: C-56467r824364_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "fchown" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w fchown /etc/audit/audit.rules -a always,exit -F arch=b32 -S fchown -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchown -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56417r824365_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchown" system call by adding or updating the following line to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the fchownat system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253015 - SV-253015r958446_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-030620
Vuln IDs
  • V-253015
Rule IDs
  • SV-253015r958446_rule
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 "fchownat" system call is used to change ownership of a file relative to a directory file descriptor. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206
Checks: C-56468r824367_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "fchownat" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w fchownat /etc/audit/audit.rules -a always,exit -F arch=b32 -S fchownat -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchownat -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56418r824368_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchownat" system call by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the ftruncate system call system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253016 - SV-253016r958446_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-030630
Vuln IDs
  • V-253016
Rule IDs
  • SV-253016r958446_rule
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 "truncate" and "ftruncate" system calls are used to truncate a file to a specified length. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219
Checks: C-56469r824370_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "ftruncate" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -iw ftruncate /etc/audit/audit.rules -a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56419r824371_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ftruncate" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the lchown system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253017 - SV-253017r958446_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-030640
Vuln IDs
  • V-253017
Rule IDs
  • SV-253017r958446_rule
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 "lchown" system call is used to change the ownership of the file specified by a path, which does not dereference symbolic links. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206
Checks: C-56470r824373_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "lchown" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w lchown /etc/audit/audit.rules -a always,exit -F arch=b32 -S lchown -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lchown -F auid&gt;=1000 -F auid!=unset -k perm_mod If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56420r824374_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "lchown" system call by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the open system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253018 - SV-253018r958446_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-030650
Vuln IDs
  • V-253018
Rule IDs
  • SV-253018r958446_rule
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 "open system" call opens a file specified by a pathname. If the specified file does not exist, it may optionally be created by "open." When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219
Checks: C-56471r824376_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "open" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -iw open /etc/audit/audit.rules -a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56421r824377_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "open" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the open_by_handle_at system call system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253019 - SV-253019r958446_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-030660
Vuln IDs
  • V-253019
Rule IDs
  • SV-253019r958446_rule
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 "name_to_handle_at" and "open_by_handle_at" system calls split the functionality of openat into two parts: "name_to_handle_at" returns an opaque handle that corresponds to a specified file; "open_by_handle_at" opens the file corresponding to a handle returned by a previous call to "name_to_handle_at" and returns an open file descriptor. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219
Checks: C-56472r824379_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "open_by_handle_at" system call by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -iw open_by_handle_at /etc/audit/audit.rules -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56422r824380_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "open_by_handle_at" system call by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the openat system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253020 - SV-253020r958446_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-030670
Vuln IDs
  • V-253020
Rule IDs
  • SV-253020r958446_rule
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 "openat" system call opens a file specified by a relative pathname. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219
Checks: C-56473r824382_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "openat" system calls by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -iw openat /etc/audit/audit.rules -a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56423r824383_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "openat" command by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the truncate system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253021 - SV-253021r958446_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-030680
Vuln IDs
  • V-253021
Rule IDs
  • SV-253021r958446_rule
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 "truncate" system calls are used to truncate a file to a specified length. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219
Checks: C-56474r824385_chk

Verify TOSS generates an audit record when successful/unsuccessful attempts to use the "truncate" system calls by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -iw truncate /etc/audit/audit.rules -a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid&gt;=1000 -F auid!=unset -k perm_access If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56424r824386_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "truncate" system calls by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -k perm_access The audit daemon must be restarted for the changes to take effect.

b
TOSS audit tools must be owned by "root".
AU-9 - Medium - CCI-001493 - V-253022 - SV-253022r991557_rule
RMF Control
AU-9
Severity
M
CCI
CCI-001493
Version
TOSS-04-030750
Vuln IDs
  • V-253022
Rule IDs
  • SV-253022r991557_rule
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. Satisfies: SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099
Checks: C-56475r824736_chk

Verify the audit tools are owned by "root" to prevent any unauthorized access, deletion, or modification. Check the owner of each audit tool by running the following command: $ sudo stat -c "%U %n" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/rsyslogd /sbin/augenrules root /sbin/auditctl root /sbin/aureport root /sbin/ausearch root /sbin/autrace root /sbin/auditd root /sbin/rsyslogd root /sbin/augenrules If any of the audit tools are not owned by "root", this is a finding.

Fix: F-56425r825979_fix

Configure the audit tools to be owned by "root", by running the following command: $ sudo chown root [audit_tool] Replace "[audit_tool]" with each audit tool not owned by "root".

b
TOSS must use cryptographic mechanisms to protect the integrity of audit tools.
AU-9 - Medium - CCI-001496 - V-253023 - SV-253023r991567_rule
RMF Control
AU-9
Severity
M
CCI
CCI-001496
Version
TOSS-04-030780
Vuln IDs
  • V-253023
Rule IDs
  • SV-253023r991567_rule
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.
Checks: C-56476r824739_chk

Verify that Advanced Intrusion Detection Environment (AIDE) is properly configured to use cryptographic mechanisms to protect the integrity of audit tools. If AIDE is not installed, ask the System Administrator how file integrity checks are performed on the system. Check the selection lines to ensure AIDE is configured to add/check with the following command: $ sudo egrep '(\/usr\/sbin\/(audit|au|rsys))' /etc/aide.conf /usr/sbin/auditctl p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/auditd p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/ausearch p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/aureport p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/autrace p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/rsyslogd p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/augenrules p+i+n+u+g+s+b+acl+xattrs+sha512 If any of the audit tools listed above do not have an appropriate selection line, ask the system administrator to indicate what cryptographic mechanisms are being used to protect the integrity of the audit tools. If there is no evidence of integrity protection, this is a finding. If any of the audit tools are not installed on the system, the corresponding AIDE rule is not applicable.

Fix: F-56426r824740_fix

Add or update the following lines to "/etc/aide.conf", to protect the integrity of the audit tools. # Audit Tools /usr/sbin/auditctl p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/auditd p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/ausearch p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/aureport p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/autrace p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/rsyslogd p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/augenrules p+i+n+u+g+s+b+acl+xattrs+sha512

b
TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group".
AC-2 - Medium - CCI-002130 - V-253024 - SV-253024r958684_rule
RMF Control
AC-2
Severity
M
CCI
CCI-002130
Version
TOSS-04-030790
Vuln IDs
  • V-253024
Rule IDs
  • SV-253024r958684_rule
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.
Checks: C-56477r825981_chk

Verify TOSS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group". Check the auditing rules in "/etc/audit/audit.rules" with the following command: $ sudo grep /etc/group /etc/audit/audit.rules -w /etc/group -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56427r825982_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/group -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b
TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow".
AC-2 - Medium - CCI-002130 - V-253025 - SV-253025r958684_rule
RMF Control
AC-2
Severity
M
CCI
CCI-002130
Version
TOSS-04-030800
Vuln IDs
  • V-253025
Rule IDs
  • SV-253025r958684_rule
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.
Checks: C-56478r825984_chk

Verify TOSS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow". Check the auditing rules in "/etc/audit/audit.rules" with the following command: $ sudo grep /etc/gshadow /etc/audit/audit.rules -w /etc/gshadow -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56428r825985_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/gshadow -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b
TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd".
AC-2 - Medium - CCI-002130 - V-253026 - SV-253026r958684_rule
RMF Control
AC-2
Severity
M
CCI
CCI-002130
Version
TOSS-04-030810
Vuln IDs
  • V-253026
Rule IDs
  • SV-253026r958684_rule
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.
Checks: C-56479r825987_chk

Verify TOSS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd". Check the auditing rules in "/etc/audit/audit.rules" with the following command: $ sudo grep /etc/passwd /etc/audit/audit.rules -w /etc/passwd -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56429r825988_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/passwd -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b
TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd".
AC-2 - Medium - CCI-002130 - V-253027 - SV-253027r958684_rule
RMF Control
AC-2
Severity
M
CCI
CCI-002130
Version
TOSS-04-030820
Vuln IDs
  • V-253027
Rule IDs
  • SV-253027r958684_rule
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.
Checks: C-56480r825990_chk

Verify TOSS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd". Check the auditing rules in "/etc/audit/audit.rules" with the following command: $ sudo grep /etc/security/opasswd /etc/audit/audit.rules -w /etc/security/opasswd -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56430r825991_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/security/opasswd -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b
TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers".
AC-2 - Medium - CCI-002130 - V-253028 - SV-253028r958684_rule
RMF Control
AC-2
Severity
M
CCI
CCI-002130
Version
TOSS-04-030840
Vuln IDs
  • V-253028
Rule IDs
  • SV-253028r958684_rule
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.
Checks: C-56481r825993_chk

Verify TOSS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers". Check the auditing rules in "/etc/audit/audit.rules" with the following command: $ sudo grep /etc/sudoers /etc/audit/audit.rules -w /etc/sudoers -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56431r825994_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/sudoers -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b
TOSS must generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers.d/".
AC-2 - Medium - CCI-002130 - V-253029 - SV-253029r958684_rule
RMF Control
AC-2
Severity
M
CCI
CCI-002130
Version
TOSS-04-030850
Vuln IDs
  • V-253029
Rule IDs
  • SV-253029r958684_rule
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.
Checks: C-56482r825996_chk

Verify TOSS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers.d/". Check the auditing rules in "/etc/audit/audit.rules" with the following command: $ sudo grep /etc/sudoers.d/ /etc/audit/audit.rules -w /etc/sudoers.d/ -p wa -k identity If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56432r825997_fix

Configure TOSS to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers.d/". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -w /etc/sudoers.d/ -p wa -k identity The audit daemon must be restarted for the changes to take effect.

b
The TOSS audit system must prevent all software from executing at higher privilege levels than users executing the software and the audit system must be configured to audit the execution of privileged functions.
AC-6 - Medium - CCI-002233 - V-253030 - SV-253030r958730_rule
RMF Control
AC-6
Severity
M
CCI
CCI-002233
Version
TOSS-04-030860
Vuln IDs
  • V-253030
Rule IDs
  • SV-253030r958730_rule
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. Satisfies: SRG-OS-000326-GPOS-00126, SRG-OS-000327-GPOS-00127
Checks: C-56483r824760_chk

Verify TOSS audits the execution of privileged functions. Check if TOSS is configured to audit the execution of the "execve" system call, by running the following command: $ sudo grep execve /etc/audit/audit.rules -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k execpriv -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k execpriv If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56433r824761_fix

Configure TOSS to audit the execution of the "execve" system call. Add or update the following file system rules to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -k execpriv -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -k execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -k execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -k execpriv The audit daemon must be restarted for the changes to take effect.

b
TOSS must allocate audit record storage capacity to store at least one week's worth of audit records, when audit records are not immediately sent to a central audit record storage facility.
AU-4 - Medium - CCI-001849 - V-253031 - SV-253031r958752_rule
RMF Control
AU-4
Severity
M
CCI
CCI-001849
Version
TOSS-04-030890
Vuln IDs
  • V-253031
Rule IDs
  • SV-253031r958752_rule
In order to ensure TOSS systems have a sufficient storage capacity in which to write the audit logs, TOSS needs to be able to allocate audit record storage capacity. The task of allocating audit record storage capacity is usually performed during initial installation of TOSS. If an external logging system is used to aggregate and store logs for at least one week, this requirement is Not Applicable.
Checks: C-56484r824763_chk

Verify TOSS allocates audit record storage capacity to store at least one week of audit records when audit records are not immediately sent to a central audit record storage facility. If logs are immediately sent to a central audit record storage facility, this requirement is Not Applicable. Determine to which partition the audit records are being written with the following command: $ sudo grep log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Check the size of the partition to which audit records are written (with the example being /var/log/audit/) with the following command: $ sudo df -h /var/log/audit/audit.log /dev/sda2 24G 10.4G 13.6G 43% /var/log/audit If the audit records are not written to a partition made specifically for audit records (/var/log/audit is a separate partition), determine the amount of space being used by other files in the partition with the following command: $ sudo du -sh [audit_partition] 1.8G /var/log/audit If the audit record partition is not allocated for sufficient storage capacity, this is a finding. Note: The partition size needed to capture a week of audit records is based on the activity level of the system and the total storage capacity available. Typically, 10.0 GB of storage space for audit records should be sufficient.

Fix: F-56434r824764_fix

Allocate enough storage capacity for at least one week of audit records when audit records are not immediately sent to a central audit record storage facility. If audit records are stored on a partition made specifically for audit records, resize the partition with sufficient space to contain one week of audit records. If audit records are not stored on a partition made specifically for audit records, a new partition with sufficient space will need be to be created.

b
The TOSS audit records must be offloaded onto a different system or storage media from the system being audited.
AU-4 - Medium - CCI-001851 - V-253032 - SV-253032r958754_rule
RMF Control
AU-4
Severity
M
CCI
CCI-001851
Version
TOSS-04-030900
Vuln IDs
  • V-253032
Rule IDs
  • SV-253032r958754_rule
Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Offloading is a common process in information systems with limited audit storage capacity. TOSS installation media provides "rsyslogd." "rsyslogd" is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with "gnutls" (which is a secure communications library implementing the SSL, TLS, and DTLS protocols), and now there is a method to securely encrypt and offload auditing. Rsyslog provides three ways to forward message: the traditional UDP transport, which is extremely lossy but standard; the plain TCP based transport, which loses messages only during certain situations but is widely available; and the RELP transport, which does not lose messages but is currently available only as part of the rsyslogd 3.15.0 and above. Examples of each configuration: UDP *.* @remotesystemname TCP *.* @@remotesystemname RELP *.* :omrelp:remotesystemname:2514 Note that a port number was given as there is no standard port for RELP. Satisfies: SRG-OS-000342-GPOS-00133, SRG-OS-000479-GPOS-00224
Checks: C-56485r944958_chk

Verify the audit system offloads audit records onto a different system or media from the system being audited with the following command: $ sudo grep @@ /etc/rsyslog.conf /etc/rsyslog.d/*.conf /etc/rsyslog.conf:*.* @@[remoteloggingserver]:[port] If a remote server is not configured, or the line is commented out, ask the System Administrator to indicate how the audit logs are offloaded to a different system or media. If there is no evidence that the audit logs are being offloaded to another system or media, this is a finding.

Fix: F-56435r944959_fix

Multiple software applications other than rsyslog may be used by the system to accomplish this requirement. This Fix assumes rsyslog is used for offloading logs from the system. Configure the operating system to offload audit records onto a different system or media from the system being audited by specifying the remote logging server in "/etc/rsyslog.conf" or "/etc/rsyslog.d/[customfile].conf" with the name or IP address of the log aggregation server. *.* @@[remoteloggingserver]:[port]

b
TOSS must label all off-loaded audit logs before sending them to the central log server.
AU-4 - Medium - CCI-001851 - V-253033 - SV-253033r958754_rule
RMF Control
AU-4
Severity
M
CCI
CCI-001851
Version
TOSS-04-030910
Vuln IDs
  • V-253033
Rule IDs
  • SV-253033r958754_rule
Without establishing what type of events occurred, the source of events, where events occurred, and the outcome of events, 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. Enriched logging is needed to determine who, what, and when events occur on a system. Without this, determining root cause of an event will be much more difficult. When audit logs are not labeled before they are sent to a central log server, the audit data will not be able to be analyzed and tied back to the correct system. Satisfies: SRG-OS-000342-GPOS-00133, SRG-OS-000479-GPOS-00224
Checks: C-56486r824769_chk

Verify the TOSS audit Daemon is configured to label all off-loaded audit logs, with the following command: $ sudo grep "name_format" /etc/audit/auditd.conf name_format = hostname If the "name_format" option is not "hostname", "fqd", or "numeric", or the line is commented out, this is a finding.

Fix: F-56436r824770_fix

Edit the /etc/audit/auditd.conf file and add or update the "name_format" option to one of "hostname", "fqd", or "numeric": name_format = hostname The audit daemon must be restarted for changes to take effect.

b
The TOSS audit system must be configured to audit any usage of the "fsetxattr" system call.
AU-12 - Medium - CCI-000172 - V-253034 - SV-253034r991570_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-030990
Vuln IDs
  • V-253034
Rule IDs
  • SV-253034r991570_rule
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). "Fsetxattr" is a system call used to set an extended attribute value. This is used to set extended attributes on a file. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The auid representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000458-GPOS-00203, SRG-OS-000463-GPOS-00207
Checks: C-56487r824772_chk

Verify if TOSS is configured to audit the execution of the "fsetxattr" system call, by running the following command: $ sudo grep -w fsetxattr /etc/audit/audit.rules -a always,exit -F arch=b32 -S fsetxattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S fsetxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid=0 -k perm_mod If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56437r824773_fix

Configure TOSS to audit the execution of the "fsetxattr" system call, by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S fsetxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid=0 -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
The TOSS audit system must be configured to audit any usage of the "lsetxattr" system call.
AU-12 - Medium - CCI-000172 - V-253035 - SV-253035r991570_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-031000
Vuln IDs
  • V-253035
Rule IDs
  • SV-253035r991570_rule
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). "Lsetxattr" is a system call used to set an extended attribute value. This is used to set extended attributes on a symbolic link. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way. Satisfies: SRG-OS-000458-GPOS-00203, SRG-OS-000463-GPOS-00207
Checks: C-56488r824775_chk

Verify if TOSS is configured to audit the execution of the "lsetxattr" system call, by running the following command: $ sudo grep -w lsetxattr /etc/audit/audit.rules -a always,exit -F arch=b32 -S lsetxattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S lsetxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid=0 -k perm_mod If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56438r824776_fix

Configure TOSS to audit the execution of the "lsetxattr" system call, by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S lsetxattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid=0 -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the fremovexattr system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253036 - SV-253036r991577_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-031100
Vuln IDs
  • V-253036
Rule IDs
  • SV-253036r991577_rule
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). "Fremovexattr" is a system call that removes extended attributes. This is used for removal of extended attributes from a file. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way.
Checks: C-56489r824778_chk

Verify if TOSS is configured to audit the execution of the "fremovexattr" system call, by running the following command: $ sudo grep -w fremovexattr /etc/audit/audit.rules -a always,exit -F arch=b32 -S fremovexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S fremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid=0 -k perm_mod If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56439r824779_fix

Configure TOSS to audit the execution of the "fremovexattr" system call by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S fremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid=0 -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "lremovexattr" system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253037 - SV-253037r991577_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-031110
Vuln IDs
  • V-253037
Rule IDs
  • SV-253037r991577_rule
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). "Lremovexattr" is a system call that removes extended attributes. This is used for removal of extended attributes from symbolic links. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way.
Checks: C-56490r824781_chk

Verify if TOSS is configured to audit the execution of the "lremovexattr" system call, by running the following command: $ sudo grep -w lremovexattr /etc/audit/audit.rules -a always,exit -F arch=b32 -S lremovexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S lremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid=0 -k perm_mod If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56440r824782_fix

Configure TOSS to audit the execution of the "lremovexattr" system call, by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S lremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid=0 -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "removexattr" system call in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253038 - SV-253038r991577_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-031120
Vuln IDs
  • V-253038
Rule IDs
  • SV-253038r991577_rule
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). "Removexattr" is a system call that removes extended attributes. When a user logs on, the AUID is set to the UID of the account that is being authenticated. Daemons are not user sessions and have the loginuid set to "-1." The AUID representation is an unsigned 32-bit integer, which equals "4294967295." The audit system interprets "-1", "4294967295", and "unset" in the same way.
Checks: C-56491r824784_chk

Verify if TOSS is configured to audit the execution of the "removexattr" system call, by running the following command: $ sudo grep -w removexattr /etc/audit/audit.rules -a always,exit -F arch=b32 -S removexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid&gt;=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S removexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid=0 -k perm_mod If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-56441r824785_fix

Configure TOSS to audit the execution of the "removexattr" system call, by adding or updating the following lines to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b32 -S removexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid=0 -k perm_mod The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful modifications to the "lastlog" file in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253039 - SV-253039r991578_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-031130
Vuln IDs
  • V-253039
Rule IDs
  • SV-253039r991578_rule
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). Satisfies: SRG-OS-000470-GPOS-00214, SRG-OS-000473-GPOS-00218
Checks: C-56492r824787_chk

Verify TOSS generates an audit record when successful/unsuccessful modifications to the "lastlog" file by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w lastlog /etc/audit/audit.rules -w /var/log/lastlog -p wa -k logins If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56442r824788_fix

Configure the audit system to generate an audit event for any successful/unsuccessful modifications to the "lastlog" file by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -w /var/log/lastlog -p wa -k logins The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of "semanage" in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253040 - SV-253040r991579_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-031140
Vuln IDs
  • V-253040
Rule IDs
  • SV-253040r991579_rule
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 "semanage" command is used to configure certain elements of SELinux policy without requiring modification to or recompilation from policy sources.
Checks: C-56493r824790_chk

Verify that an audit event is generated for any successful/unsuccessful use of "semanage" by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "semanage" /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56443r824791_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "semanage" by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/semanage -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "gpasswd" command in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253041 - SV-253041r991579_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-031150
Vuln IDs
  • V-253041
Rule IDs
  • SV-253041r991579_rule
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 "gpasswd" command is used to administer /etc/group and /etc/gshadow. Every group can have administrators, members and a password.
Checks: C-56494r824793_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "gpasswd" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w gpasswd /etc/audit/audit.rules -a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56444r824794_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "gpasswd" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "mount" command in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253042 - SV-253042r991579_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-031160
Vuln IDs
  • V-253042
Rule IDs
  • SV-253042r991579_rule
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 "mount" command is used to mount a filesystem.
Checks: C-56495r824796_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "mount" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w /usr/bin/mount /etc/audit/audit.rules -a always,exit -F path=/usr/bin/mount -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56445r824797_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "mount" command by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "mount" syscall in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253043 - SV-253043r991579_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-031170
Vuln IDs
  • V-253043
Rule IDs
  • SV-253043r991579_rule
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 "mount" syscall is used to mount a filesystem.
Checks: C-56496r824799_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "mount" syscall by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "\-S mount" /etc/audit/audit.rules -a always,exit -F arch=b32 -S mount -F auid&gt;=1000 -F auid!=unset -k privileged -a always,exit -F arch=b64 -S mount -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56446r824800_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "mount" syscall by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F arch=b32 -S mount -F auid>=1000 -F auid!=unset -k privileged -a always,exit -F arch=b64 -S mount -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "su" command in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253044 - SV-253044r991579_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-031180
Vuln IDs
  • V-253044
Rule IDs
  • SV-253044r991579_rule
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 "su" command allows a user to run commands with a substitute user and group ID.
Checks: C-56497r824802_chk

Verify TOSS generates audit records when successful/unsuccessful attempts to use the "su" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w /usr/bin/su /etc/audit/audit.rules -a always,exit -F path=/usr/bin/su -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56447r824803_fix

Configure TOSS to generate audit records when successful/unsuccessful attempts to use the "su" command occur by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/su -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "umount" command in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253045 - SV-253045r991579_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-031190
Vuln IDs
  • V-253045
Rule IDs
  • SV-253045r991579_rule
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 "umount" command is used to unmount a filesystem.
Checks: C-56498r824805_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "umount" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w /usr/bin/umount /etc/audit/audit.rules -a always,exit -F path=/usr/bin/umount -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56448r824806_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "umount" command by adding or updating the following rules in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "unix_update" in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253046 - SV-253046r991579_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-031200
Vuln IDs
  • V-253046
Rule IDs
  • SV-253046r991579_rule
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). "unix_update" is a helper program for the "pam_unix" module that updates the password for a given user. It is not intended to be run directly from the command line and logs a security violation if done so.
Checks: C-56499r824808_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "unix_update" by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "unix_update" /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56449r824809_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "unix_update" by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "usermod" command in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253047 - SV-253047r991579_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-031210
Vuln IDs
  • V-253047
Rule IDs
  • SV-253047r991579_rule
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 "usermod" command modifies the system account files to reflect the changes that are specified on the command line.
Checks: C-56500r824811_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "usermod" command by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w usermod /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56450r824812_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "usermod" command by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of "unix_chkpwd" in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253048 - SV-253048r991579_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-031220
Vuln IDs
  • V-253048
Rule IDs
  • SV-253048r991579_rule
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 "unix_chkpwd" command is a helper program for the pam_unix module that verifies the password of the current user. It also checks password and account expiration dates in shadow. It is not intended to be run directly from the command line and logs a security violation if done so.
Checks: C-56501r824814_chk

Verify that an audit event is generated for any successful/unsuccessful use of "unix_chkpwd" by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "unix_chkpwd" /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56451r824815_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "unix_chkpwd" by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of "userhelper" in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253049 - SV-253049r991579_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-031230
Vuln IDs
  • V-253049
Rule IDs
  • SV-253049r991579_rule
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 "userhelper" command is not intended to be run interactively. "Userhelper" provides a basic interface to change a user's password, gecos information, and shell. The main difference between this program and its traditional equivalents (passwd, chfn, chsh) is that prompts are written to standard out to make it easy for a graphical user interface wrapper to interface to it as a child process.
Checks: C-56502r824817_chk

Verify that an audit event is generated for any successful/unsuccessful use of "userhelper" by performing the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w "userhelper" /etc/audit/audit.rules -a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid&gt;=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56452r824818_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "userhelper" by adding or updating the following rule in the "/etc/audit/rules.d/audit.rules" file: -a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -k privileged The audit daemon must be restarted for the changes to take effect.

b
Successful/unsuccessful uses of the "kmod" command in TOSS must generate an audit record.
AU-12 - Medium - CCI-000172 - V-253050 - SV-253050r991580_rule
RMF Control
AU-12
Severity
M
CCI
CCI-000172
Version
TOSS-04-031240
Vuln IDs
  • V-253050
Rule IDs
  • SV-253050r991580_rule
"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 "kmod" command is used to control Linux Kernel modules. Satisfies: SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222
Checks: C-56503r824820_chk

Verify that TOSS is configured to audit the execution of the module management program "kmod", by running the following command: $ sudo grep "/usr/bin/kmod" /etc/audit/audit.rules -a always,exit -F path=/usr/bin/kmod -F perm=x -F auid&gt;=1000 -F auid!=unset -k modules If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-56453r824821_fix

Configure TOSS to audit the execution of the module management program "kmod" by adding or updating the following line to "/etc/audit/rules.d/audit.rules": -a always,exit -F path=/usr/bin/kmod -F perm=x -F auid>=1000 -F auid!=unset -k modules The audit daemon must be restarted for the changes to take effect.

b
The auditd service must be running in TOSS.
CM-6 - Medium - CCI-000366 - V-253051 - SV-253051r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-031340
Vuln IDs
  • V-253051
Rule IDs
  • SV-253051r991589_rule
Configuring TOSS to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across the 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.
Checks: C-56504r824823_chk

Verify the audit service is enabled and active with the following commands: $ sudo systemctl is-enabled auditd enabled $ sudo systemctl is-active auditd active If the service is not "enabled" and "active" this is a finding.

Fix: F-56454r824824_fix

Start the auditd service and enable the auditd service with the following commands: $ sudo systemctl start auditd.service $ sudo systemctl enable auditd.service

b
The TOSS audit system must audit local events.
Medium - CCI-004188 - V-253052 - SV-253052r991589_rule
RMF Control
Severity
M
CCI
CCI-004188
Version
TOSS-04-031350
Vuln IDs
  • V-253052
Rule IDs
  • SV-253052r991589_rule
Without establishing what type of events occurred, the source of events, where events occurred, and the outcome of events, 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.
Checks: C-56505r824826_chk

Verify the TOSS audit Daemon is configured to include local events, with the following command: $ sudo grep local_events /etc/audit/auditd.conf local_events = yes If the value of the "local_events" option is not set to "yes", or the line is commented out, this is a finding.

Fix: F-56455r824827_fix

Configure TOSS to audit local events on the system. Add or update the following line in "/etc/audit/auditd.conf" file: local_events = yes

a
TOSS must resolve audit information before writing to disk.
CM-6 - Low - CCI-000366 - V-253053 - SV-253053r991589_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
TOSS-04-031360
Vuln IDs
  • V-253053
Rule IDs
  • SV-253053r991589_rule
Without establishing what type of events occurred, the source of events, where events occurred, and the outcome of events, 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. Enriched logging aids in making sense of who, what, and when events occur on a system. Without this, determining root cause of an event will be much more difficult.
Checks: C-56506r824829_chk

Verify the TOSS audit daemon is configured to resolve audit information before writing to disk, with the following command: $ sudo grep "log_format" /etc/audit/auditd.conf log_format = ENRICHED If the "log_format" option is not "ENRICHED", or the line is commented out, this is a finding.

Fix: F-56456r824830_fix

Edit the /etc/audit/auditd.conf file and add or update the "log_format" option: log_format = ENRICHED The audit daemon must be restarted for changes to take effect.

b
TOSS must have the packages required for offloading audit logs installed.
CM-6 - Medium - CCI-000366 - V-253054 - SV-253054r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-031370
Vuln IDs
  • V-253054
Rule IDs
  • SV-253054r991589_rule
Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Offloading is a common process in information systems with limited audit storage capacity. TOSS installation media provides "rsyslogd." "rsyslogd" is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with "gnutls" (which is a secure communications library implementing the SSL, TLS, and DTLS protocols), and now there is a method to securely encrypt and offload auditing. Rsyslog provides three ways to forward message: the traditional UDP transport, which is extremely lossy but standard; the plain TCP based transport, which loses messages only during certain situations but is widely available; and the RELP transport, which does not lose messages but is currently available only as part of the rsyslogd 3.15.0 and above. Examples of each configuration: UDP *.* @remotesystemname TCP *.* @@remotesystemname RELP *.* :omrelp:remotesystemname:2514 Note that a port number was given as there is no standard port for RELP.
Checks: C-56507r824832_chk

Verify the operating system has the packages required for offloading audit logs installed with the following commands: $ sudo yum list installed rsyslog rsyslog.x86_64 8.2102.0-5.el8 @AppStream If the "rsyslog" package is not installed, ask the administrator to indicate how audit logs are being offloaded and what packages are installed to support it. If there is no evidence of audit logs being offloaded, this is a finding.

Fix: F-56457r824833_fix

Configure the operating system to offload audit logs by installing the required packages with the following command: $ sudo yum install rsyslog

b
TOSS must have the packages required for encrypting offloaded audit logs installed.
CM-6 - Medium - CCI-000366 - V-253055 - SV-253055r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-031380
Vuln IDs
  • V-253055
Rule IDs
  • SV-253055r991589_rule
Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Offloading is a common process in information systems with limited audit storage capacity. TOSS installation media provides "rsyslogd." "rsyslogd" is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with "rsyslog-gnutls" (which is a secure communications library implementing the SSL, TLS, and DTLS protocols), and now there is a method to securely encrypt and offload auditing. Rsyslog provides three ways to forward message: the traditional UDP transport, which is extremely lossy but standard; the plain TCP based transport, which loses messages only during certain situations but is widely available; and the RELP transport, which does not lose messages but is currently available only as part of the rsyslogd 3.15.0 and above. Examples of each configuration: UDP *.* @remotesystemname TCP *.* @@remotesystemname RELP *.* :omrelp:remotesystemname:2514 Note that a port number was given as there is no standard port for RELP.
Checks: C-56508r824835_chk

Verify the operating system has the packages required for encrypting offloaded audit logs installed with the following commands: $ sudo yum list installed rsyslog-gnutls rsyslog-gnutls.x86_64 8.2102.0-5.el8 @AppStream If the "rsyslog-gnutls" package is not installed, ask the administrator to indicate how audit logs are being encrypted during offloading and what packages are installed to support it. If there is no evidence of audit logs being encrypted during offloading, this is a finding.

Fix: F-56458r824836_fix

Configure the operating system to encrypt offloaded audit logs by installing the required packages with the following command: $ sudo yum install rsyslog-gnutls

b
TOSS must monitor remote access methods.
AC-17 - Medium - CCI-000067 - V-253056 - SV-253056r958406_rule
RMF Control
AC-17
Severity
M
CCI
CCI-000067
Version
TOSS-04-040010
Vuln IDs
  • V-253056
Rule IDs
  • SV-253056r958406_rule
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).
Checks: C-56509r824838_chk

Verify that TOSS monitors all remote access methods. Check that remote access methods are being logged by running the following command: $ sudo grep -E '(auth.*|authpriv.*|daemon.*)' /etc/rsyslog.conf auth.*;authpriv.*;daemon.* /var/log/secure If any of "auth.*", "authpriv.*" or "daemon.*" are not configured to be logged, this is a finding.

Fix: F-56459r824839_fix

Configure TOSS to monitor all remote access methods by adding or updating the following lines to the "/etc/rsyslog.conf" file: auth.*;authpriv.*;daemon.* /var/log/secure The "rsyslog" service must be restarted for the changes to take effect. To restart the "rsyslog" service, run the following command: $ sudo systemctl restart rsyslog.service

b
TOSS must force a frequent session key renegotiation for SSH connections by the client.
AC-17 - Medium - CCI-000068 - V-253057 - SV-253057r958408_rule
RMF Control
AC-17
Severity
M
CCI
CCI-000068
Version
TOSS-04-040020
Vuln IDs
  • V-253057
Rule IDs
  • SV-253057r958408_rule
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. Session key regeneration limits the chances of a session key becoming compromised.
Checks: C-56510r824841_chk

Verify the SSH client is configured to force frequent session key renegotiation with the following command: $ sudo grep -i RekeyLimit /etc/ssh/ssh_config RekeyLimit 1G 1h If "RekeyLimit" does not have a maximum data amount and maximum time defined, is missing or commented out, this is a finding.

Fix: F-56460r824842_fix

Configure the system to force a frequent session key renegotiation for SSH connections by the client by add or modifying the following line in the "/etc/ssh/ssh_config" file: RekeyLimit 1G 1h Restart the SSH daemon for the settings to take effect. $ sudo systemctl restart sshd.service

b
TOSS must force a frequent session key renegotiation for SSH connections to the server.
AC-17 - Medium - CCI-000068 - V-253058 - SV-253058r958408_rule
RMF Control
AC-17
Severity
M
CCI
CCI-000068
Version
TOSS-04-040030
Vuln IDs
  • V-253058
Rule IDs
  • SV-253058r958408_rule
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. Session key regeneration limits the chances of a session key becoming compromised.
Checks: C-56511r824844_chk

Verify the SSH server is configured to force frequent session key renegotiation with the following command: $ sudo grep -i RekeyLimit /etc/ssh/sshd_config RekeyLimit 1G 1h If "RekeyLimit" does not have a maximum data amount and maximum time defined, is missing or commented out, this is a finding.

Fix: F-56461r824845_fix

Configure the system to force a frequent session key renegotiation for SSH connections to the server by add or modifying the following line in the "/etc/ssh/sshd_config" file: RekeyLimit 1G 1h Restart the SSH daemon for the settings to take effect. $ sudo systemctl restart sshd.service

c
TOSS 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.
AC-17 - High - CCI-000068 - V-253059 - SV-253059r958408_rule
RMF Control
AC-17
Severity
H
CCI
CCI-000068
Version
TOSS-04-040040
Vuln IDs
  • V-253059
Rule IDs
  • SV-253059r958408_rule
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. TOSS utilizes GRUB 2 as the default bootloader. Note that GRUB 2 command-line parameters are defined in the "kernelopts" variable of the /boot/grub2/grubenv file for all kernel boot entries. The command "fips-mode-setup" modifies the "kernelopts" variable, which in turn updates all kernel boot entries. The fips=1 kernel option needs to be added to the kernel command line during system installation so that key generation is done with FIPS-approved algorithms and continuous monitoring tests in place. Users must also ensure the system has plenty of entropy during the installation process by moving the mouse around, or if no mouse is available, ensuring that many keystrokes are typed. The recommended amount of keystrokes is 256 and more. Less than 256 keystrokes may generate a non-unique key. Satisfies: SRG-OS-000033-GPOS-00014, SRG-OS-000396-GPOS-00176, SRG-OS-000478-GPOS-00223
Checks: C-56512r824847_chk

Verify TOSS implements DoD-approved encryption to protect the confidentiality of remote access sessions. Check to see if FIPS mode is enabled with the following command: $ fips-mode-setup --check FIPS mode is enabled If FIPS mode is "enabled", check to see if the kernel boot parameter is configured for FIPS mode with the following command: $ sudo grub2-editenv list | grep fips kernelopts=root=/dev/mapper/rhel-root ro crashkernel=auto resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet fips=1 boot=UUID=8d171156-cd61-421c-ba41-1c021ac29e82 If the kernel boot parameter is configured to use FIPS mode, check to see if the system is in FIPS mode with the following command: $ sudo cat /proc/sys/crypto/fips_enabled 1 If FIPS mode is not "on", the kernel boot parameter is not configured for FIPS mode, or the system does not have a value of "1" for "fips_enabled" in "/proc/sys/crypto", this is a finding. If the hardware configuration of the operating system does not allow for enabling FIPS mode, and has been documented with the Information System Security Officer (ISSO), this requirement is Not Applicable.

Fix: F-56462r824848_fix

Configure the operating system to implement DoD-approved encryption by following the steps below: To enable strict FIPS compliance, the fips=1 kernel option needs to be added to the kernel boot parameters during system installation so key generation is done with FIPS-approved algorithms and continuous monitoring tests in place. Enable FIPS mode after installation (not strict FIPS compliant) with the following command: $ sudo fips-mode-setup --enable Reboot the system for the changes to take effect.

b
TOSS must enforce password complexity by requiring that at least one uppercase character be used.
Medium - CCI-004066 - V-253060 - SV-253060r986589_rule
RMF Control
Severity
M
CCI
CCI-004066
Version
TOSS-04-040050
Vuln IDs
  • V-253060
Rule IDs
  • SV-253060r986589_rule
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. TOSS utilizes "pwquality" as a mechanism to enforce password complexity. Note that in order to require uppercase characters, without degrading the "minlen" value, the credit value must be expressed as a negative number in "/etc/security/pwquality.conf."
Checks: C-56513r824850_chk

Verify the value for "ucredit" in "/etc/security/pwquality.conf" with the following command: $ sudo grep ucredit /etc/security/pwquality.conf ucredit = -1 If the value of "ucredit" is a positive number or is commented out, this is a finding.

Fix: F-56463r824851_fix

Configure the operating system to enforce password complexity by requiring that at least one uppercase character be used by setting the "ucredit" option. Add the following line to /etc/security/pwquality.conf (or modify the line to have the required value): ucredit = -1

b
TOSS must enforce password complexity by requiring that at least one lowercase character be used.
Medium - CCI-004066 - V-253061 - SV-253061r986591_rule
RMF Control
Severity
M
CCI
CCI-004066
Version
TOSS-04-040060
Vuln IDs
  • V-253061
Rule IDs
  • SV-253061r986591_rule
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. TOSS utilizes "pwquality" as a mechanism to enforce password complexity. Note that in order to require lowercase characters, without degrading the "minlen" value, the credit value must be expressed as a negative number in "/etc/security/pwquality.conf."
Checks: C-56514r824853_chk

Verify the value for "lcredit" in "/etc/security/pwquality.conf" with the following command: $ sudo grep lcredit /etc/security/pwquality.conf lcredit = -1 If the value of "lcredit" is a positive number or is commented out, this is a finding.

Fix: F-56464r986590_fix

Configure the operating system to enforce password complexity by requiring that at least one lowercase character be used by setting the "lcredit" option. Add the following line to /etc/security/pwquality.conf (or modify the line to have the required value): lcredit = -1

b
TOSS must enforce password complexity by requiring that at least one numeric character be used.
Medium - CCI-004066 - V-253062 - SV-253062r986592_rule
RMF Control
Severity
M
CCI
CCI-004066
Version
TOSS-04-040070
Vuln IDs
  • V-253062
Rule IDs
  • SV-253062r986592_rule
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. TOSS utilizes "pwquality" as a mechanism to enforce password complexity. Note that in order to require numeric characters, without degrading the minlen value, the credit value must be expressed as a negative number in "/etc/security/pwquality.conf."
Checks: C-56515r824856_chk

Verify the value for "dcredit" in "/etc/security/pwquality.conf" with the following command: $ sudo grep dcredit /etc/security/pwquality.conf dcredit = -1 If the value of "dcredit" is a positive number or is commented out, this is a finding.

Fix: F-56465r824857_fix

Configure the operating system to enforce password complexity by requiring that at least one numeric character be used by setting the "dcredit" option. Add the following line to /etc/security/pwquality.conf (or modify the line to have the required value): dcredit = -1

b
TOSS must require the change of at least eight characters when passwords are changed.
Medium - CCI-004066 - V-253063 - SV-253063r986593_rule
RMF Control
Severity
M
CCI
CCI-004066
Version
TOSS-04-040080
Vuln IDs
  • V-253063
Rule IDs
  • SV-253063r986593_rule
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. TOSS utilizes "pwquality" as a mechanism to enforce password complexity. The "difok" option sets the number of characters in a password that must not be present in the old password.
Checks: C-56516r824859_chk

Verify the value of the "difok" option in "/etc/security/pwquality.conf" with the following command: $ sudo grep difok /etc/security/pwquality.conf difok = 8 If the value of "difok" is set to less than "8" or is commented out, this is a finding.

Fix: F-56466r824860_fix

Configure the operating system to require the change of at least eight of the total number of characters when passwords are changed by setting the "difok" option. Add the following line to "/etc/security/pwquality.conf" (or modify the line to have the required value): difok = 8

b
TOSS must store only encrypted representations of passwords.
Medium - CCI-004062 - V-253064 - SV-253064r986594_rule
RMF Control
Severity
M
CCI
CCI-004062
Version
TOSS-04-040090
Vuln IDs
  • V-253064
Rule IDs
  • SV-253064r986594_rule
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. 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. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DOD requirements.
Checks: C-56517r824862_chk

Verify that the TOSS shadow password suite configuration is set to encrypt password with a FIPS 140-2-approved cryptographic hashing algorithm. Check the hashing algorithm that is being used to hash passwords with the following command: $ sudo grep -i crypt /etc/login.defs ENCRYPT_METHOD SHA512 If "ENCRYPT_METHOD" does not equal SHA512 or greater, this is a finding.

Fix: F-56467r824863_fix

Configure TOSS to encrypt all stored passwords. Edit/Modify the following line in the "/etc/login.defs" file and set "ENCRYPT_METHOD" to SHA512. ENCRYPT_METHOD SHA512

b
TOSS must not have the rsh-server package installed.
IA-5 - Medium - CCI-000197 - V-253065 - SV-253065r987796_rule
RMF Control
IA-5
Severity
M
CCI
CCI-000197
Version
TOSS-04-040100
Vuln IDs
  • V-253065
Rule IDs
  • SV-253065r987796_rule
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 rsh-server service provides an unencrypted remote access service that does not provide for the confidentiality and integrity of user passwords or the remote session and has very weak authentication. Satisfies: SRG-OS-000074-GPOS-00042, SRG-OS-000095-GPOS-00049
Checks: C-56518r824865_chk

Check to see if the rsh-server package is installed with the following command: $ sudo yum list installed rsh-server If the rsh-server package is installed, this is a finding.

Fix: F-56468r824866_fix

Configure the operating system to disable nonessential capabilities by removing the rsh-server package from the system with the following command: $ sudo yum remove rsh-server

b
TOSS must enforce 24 hours/one day as the minimum password lifetime.
Medium - CCI-004066 - V-253066 - SV-253066r986597_rule
RMF Control
Severity
M
CCI
CCI-004066
Version
TOSS-04-040110
Vuln IDs
  • V-253066
Rule IDs
  • SV-253066r986597_rule
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.
Checks: C-56519r986595_chk

Verify that TOSS enforces 24 hours/one day as the minimum password lifetime for new user accounts. Check for the value of "PASS_MIN_DAYS" in "/etc/login.defs" with the following command: $ sudo grep -i pass_min_days /etc/login.defs PASS_MIN_DAYS 1 If the "PASS_MIN_DAYS" parameter value is not "1" or greater, or is commented out, this is a finding.

Fix: F-56469r986596_fix

Configure the operating system to enforce 24 hours/one day as the minimum password lifetime. Add the following line in "/etc/login.defs" (or modify the line to have the required value): PASS_MIN_DAYS 1

b
TOSS must enforce a 60-day maximum password lifetime restriction.
Medium - CCI-004066 - V-253067 - SV-253067r986598_rule
RMF Control
Severity
M
CCI
CCI-004066
Version
TOSS-04-040120
Vuln IDs
  • V-253067
Rule IDs
  • SV-253067r986598_rule
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.
Checks: C-56520r824871_chk

Verify that TOSS enforces a 60-day maximum password lifetime for new user accounts by running the following command: $ sudo grep -i pass_max_days /etc/login.defs PASS_MAX_DAYS 60 If the "PASS_MAX_DAYS" parameter value is greater than "60", or commented out, this is a finding.

Fix: F-56470r824872_fix

Configure TOSS to enforce a 60-day maximum password lifetime. Add, or modify the following line in the "/etc/login.defs" file: PASS_MAX_DAYS 60

b
TOSS must enforce a minimum 15-character password length.
Medium - CCI-004066 - V-253069 - SV-253069r986599_rule
RMF Control
Severity
M
CCI
CCI-004066
Version
TOSS-04-040140
Vuln IDs
  • V-253069
Rule IDs
  • SV-253069r986599_rule
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.
Checks: C-56522r824877_chk

Verify TOSS enforces a minimum 15-character password length. The "minlen" option sets the minimum number of characters in a new password. Check for the value of the "minlen" option in "/etc/security/pwquality.conf" with the following command: $ sudo grep minlen /etc/security/pwquality.conf minlen = 15 If the command does not return a "minlen" value of 15 or greater, this is a finding.

Fix: F-56472r824878_fix

Configure TOSS to enforce a minimum 15-character password length. Add the following line to "/etc/security/pwquality.conf" (or modify the line to have the required value): minlen = 15

b
TOSS must cover or disable the built-in or attached camera when not in use.
CM-7 - Medium - CCI-000381 - V-253070 - SV-253070r958478_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
TOSS-04-040150
Vuln IDs
  • V-253070
Rule IDs
  • SV-253070r958478_rule
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. Failing to disconnect from collaborative computing devices (i.e., cameras) can result in subsequent compromises of organizational information. Providing easy methods to physically disconnect from such devices after a collaborative computing session helps to ensure participants actually carry out the disconnect activity without having to go through complex and tedious procedures.
Checks: C-56523r824880_chk

If the device or operating system does not have a camera installed, this requirement is Not Applicable. This requirement is not applicable to mobile devices (smartphones and tablets), where the use of the camera is a local AO decision. This requirement is not applicable to dedicated VTC suites located in approved VTC locations that are centrally managed. For an external camera, if there is not a method for the operator to manually disconnect the camera at the end of collaborative computing sessions, this is a finding. For a built-in camera, the camera must be protected by a camera cover (e.g., laptop camera cover slide) when not in use. If the built-in camera is not protected with a camera cover, or is not physically disabled, this is a finding. If the camera is not disconnected, covered, or physically disabled, determine if it is being disabled via software with the following commands: Determine if the camera is disabled via blacklist with the following command: $ sudo grep blacklist /etc/modprobe.d/* /etc/modprobe.d/blacklist.conf:blacklist uvcvideo Determine if a camera driver is in use with the following command: $ sudo dmesg | grep -i video [ 44.630131] ACPI: Video Device [VGA] [ 46.655714] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/LNXVIDEO:00/input/input7 [ 46.670133] videodev: Linux video capture interface: v2.00 [ 47.226424] uvcvideo: Found UVC 1.00 device WebCam (0402:7675) [ 47.235752] usbcore: registered new interface driver uvcvideo [ 47.235756] USB Video Class driver (1.1.1) If the camera driver blacklist is missing, a camera driver is determined to be in use, and the collaborative computing device has not been authorized for use, this is a finding.

Fix: F-56473r824881_fix

Configure the operating system to disable the built-in or attached camera when not in use. First determine the driver being used by the camera with the following command: $ sudo dmesg | grep -i video [ 44.630131] ACPI: Video Device [VGA] [ 46.655714] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/LNXVIDEO:00/input/input7 [ 46.670133] videodev: Linux video capture interface: v2.00 [ 47.226424] uvcvideo: Found UVC 1.00 device WebCam (0402:7675) [ 47.235752] usbcore: registered new interface driver uvcvideo [ 47.235756] USB Video Class driver (1.1.1) Next, build or modify the "/etc/modprobe.d/blacklist.conf" file by using the following example: ##Disable WebCam blacklist uvcvideo Reboot the system for the settings to take effect.

b
TOSS must disable IEEE 1394 (FireWire) Support.
CM-7 - Medium - CCI-000381 - V-253071 - SV-253071r958478_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
TOSS-04-040160
Vuln IDs
  • V-253071
Rule IDs
  • SV-253071r958478_rule
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. The IEEE 1394 (FireWire) is a serial bus standard for high-speed real-time communication. Disabling FireWire protects the system against exploitation of any flaws in its implementation.
Checks: C-56524r824883_chk

Verify the operating system disables the ability to load the firewire-core kernel module. $ sudo grep -r firewire-core /etc/modprobe.d/* | grep install install firewire-core /bin/false If the command does not return any output, or the line is commented out, and use of the firewire-core protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding. Verify the operating system disables the ability to use the firewire-core kernel module. Check to see if the firewire-core kernel module is disabled with the following command: $ sudo grep -r firewire-core /etc/modprobe.d/* | grep "blacklist" blacklist firewire-core If the command does not return any output or the output is not "blacklist firewire-core", and use of the firewire-core kernel module is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56474r824884_fix

Configure the operating system to disable the ability to use the firewire-core kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install firewire-core /bin/false blacklist firewire-core Reboot the system for the settings to take effect.

b
TOSS must disable mounting of cramfs.
CM-7 - Medium - CCI-000381 - V-253072 - SV-253072r958478_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
TOSS-04-040170
Vuln IDs
  • V-253072
Rule IDs
  • SV-253072r958478_rule
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. Removing support for unneeded filesystem types reduces the local attack surface of the server. Compressed ROM/RAM file system (or cramfs) is a read-only file system designed for simplicity and space efficiency. It is mainly used in embedded and small footprint systems.
Checks: C-56525r824886_chk

Verify the operating system disables the ability to load the cramfs kernel module. $ sudo grep -r cramfs /etc/modprobe.d/* | grep install install cramfs /bin/false If the command does not return any output, or the line is commented out, and use of the cramfs protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding. Verify the operating system disables the ability to use the cramfs kernel module. Check to see if the cramfs kernel module is disabled with the following command: $ sudo grep -r cramfs /etc/modprobe.d/* | grep "blacklist" blacklist cramfs If the command does not return any output or the output is not "blacklist cramfs", and use of the cramfs kernel module is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56475r824887_fix

Configure the operating system to disable the ability to use the cramfs kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install cramfs /bin/false blacklist cramfs Reboot the system for the settings to take effect.

b
TOSS must disable network management of the chrony daemon.
CM-7 - Medium - CCI-000381 - V-253073 - SV-253073r958478_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
TOSS-04-040180
Vuln IDs
  • V-253073
Rule IDs
  • SV-253073r958478_rule
Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time when 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. Not exposing the management interface of the chrony daemon on the network diminishes the attack space. TOSS utilizes the "timedatectl" command to view the status of the "systemd-timesyncd.service." The "timedatectl" status will display the local time, UTC, and the offset from UTC. Note that USNO offers authenticated NTP service to DoD and U.S. Government agencies operating on the NIPR and SIPR networks. Visit https://www.usno.navy.mil/USNO/time/ntp/dod-customers for more information.
Checks: C-56526r824889_chk

Verify TOSS disables network management of the chrony daemon with the following command: $ sudo grep -w 'cmdport' /etc/chrony.conf cmdport 0 If the "cmdport" option is not set to "0", is commented out or missing, this is a finding.

Fix: F-56476r824890_fix

Configure the operating system disable network management of the chrony daemon by adding/modifying the following line in the /etc/chrony.conf file. cmdport 0

b
TOSS must disable the asynchronous transfer mode (ATM) protocol.
CM-7 - Medium - CCI-000381 - V-253074 - SV-253074r958478_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
TOSS-04-040190
Vuln IDs
  • V-253074
Rule IDs
  • SV-253074r958478_rule
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. Failing to disconnect unused protocols can result in a system compromise. The Asynchronous Transfer Mode (ATM) is a protocol operating on network, data link, and physical layers, based on virtual circuits and virtual paths. Disabling ATM protects the system against exploitation of any flaws in its implementation.
Checks: C-56527r824892_chk

Verify the operating system disables the ability to load the ATM protocol kernel module. $ sudo grep -r atm /etc/modprobe.d/* | grep install install atm /bin/false If the command does not return any output, or the line is commented out, and use of the ATM protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding. Verify the operating system disables the ability to use the ATM protocol. Check to see if the ATM protocol is disabled with the following command: $ sudo grep -r atm /etc/modprobe.d/* | grep "blacklist" blacklist atm If the command does not return any output or the output is not "blacklist atm", and use of the ATM protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56477r824893_fix

Configure the operating system to disable the ability to use the ATM protocol kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install atm /bin/false blacklist atm Reboot the system for the settings to take effect.

b
TOSS must disable the controller area network (CAN) protocol.
CM-7 - Medium - CCI-000381 - V-253075 - SV-253075r958478_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
TOSS-04-040200
Vuln IDs
  • V-253075
Rule IDs
  • SV-253075r958478_rule
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. Failing to disconnect unused protocols can result in a system compromise. The Controller Area Network (CAN) is a serial communications protocol, which was initially developed for automotive and is now also used in marine, industrial, and medical applications. Disabling CAN protects the system against exploitation of any flaws in its implementation.
Checks: C-56528r824895_chk

Verify the operating system disables the ability to load the CAN protocol kernel module. $ sudo grep -r can /etc/modprobe.d/* | grep install install can /bin/false If the command does not return any output, or the line is commented out, and use of the CAN protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding. Verify the operating system disables the ability to use the CAN protocol. Check to see if the CAN protocol is disabled with the following command: $ sudo grep -r can /etc/modprobe.d/* | grep "blacklist" blacklist can If the command does not return any output or the output is not "blacklist can", and use of the CAN protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56478r824896_fix

Configure the operating system to disable the ability to use the CAN protocol kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install can /bin/false blacklist can Reboot the system for the settings to take effect.

b
TOSS must disable the stream control transmission (SCTP) protocol.
CM-7 - Medium - CCI-000381 - V-253076 - SV-253076r958478_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
TOSS-04-040210
Vuln IDs
  • V-253076
Rule IDs
  • SV-253076r958478_rule
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. Failing to disconnect unused protocols can result in a system compromise. The Stream Control Transmission Protocol (SCTP) is a transport layer protocol, designed to support the idea of message-oriented communication, with several streams of messages within one connection. Disabling SCTP protects the system against exploitation of any flaws in its implementation.
Checks: C-56529r824898_chk

Verify the operating system disables the ability to load the SCTP protocol kernel module. $ sudo grep -r sctp /etc/modprobe.d/* | grep install install sctp /bin/false If the command does not return any output, or the line is commented out, and use of the SCTP protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding. Verify the operating system disables the ability to use the SCTP protocol. Check to see if the SCTP protocol is disabled with the following command: $ sudo grep -r sctp /etc/modprobe.d/* | grep "blacklist" blacklist sctp If the command does not return any output or the output is not "blacklist sctp", and use of the SCTP protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56479r824899_fix

Configure the operating system to disable the ability to use the SCTP protocol kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install sctp /bin/false blacklist sctp Reboot the system for the settings to take effect.

b
TOSS must disable the transparent inter-process communication (TIPC) protocol.
CM-7 - Medium - CCI-000381 - V-253077 - SV-253077r958478_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
TOSS-04-040220
Vuln IDs
  • V-253077
Rule IDs
  • SV-253077r958478_rule
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. Failing to disconnect unused protocols can result in a system compromise. The Transparent Inter-Process Communication (TIPC) protocol is designed to provide communications between nodes in a cluster. Disabling TIPC protects the system against exploitation of any flaws in its implementation.
Checks: C-56530r824901_chk

Verify the operating system disables the ability to load the TIPC protocol kernel module. $ sudo grep -r tipc /etc/modprobe.d/* | grep install install tipc /bin/false If the command does not return any output, or the line is commented out, and use of the TIPC protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding. Verify the operating system disables the ability to use the TIPC protocol. Check to see if the TIPC protocol is disabled with the following command: $ sudo grep -r tipc /etc/modprobe.d/* | grep "blacklist" blacklist tipc If the command does not return any output or the output is not "blacklist tipc", and use of the TIPC protocol is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56480r824902_fix

Configure the operating system to disable the ability to use the TIPC protocol kernel module. Add or update the following lines in the file "/etc/modprobe.d/blacklist.conf": install tipc /bin/false blacklist tipc Reboot the system for the settings to take effect.

b
TOSS must not have any automated bug reporting tools installed.
CM-7 - Medium - CCI-000381 - V-253078 - SV-253078r958478_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
TOSS-04-040230
Vuln IDs
  • V-253078
Rule IDs
  • SV-253078r958478_rule
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. Verify the operating system is configured to disable non-essential capabilities. The most secure way of ensuring a non-essential capability is disabled is to not have the capability installed.
Checks: C-56531r824904_chk

Check to see if any automated bug reporting packages are installed with the following command: $ sudo yum list installed abrt* If any automated bug reporting package is installed, this is a finding.

Fix: F-56481r824905_fix

Configure the operating system to disable nonessential capabilities by removing automated bug reporting packages from the system with the following command: $ sudo yum remove abrt*

b
TOSS must not have the sendmail package installed.
CM-7 - Medium - CCI-000381 - V-253079 - SV-253079r958478_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
TOSS-04-040250
Vuln IDs
  • V-253079
Rule IDs
  • SV-253079r958478_rule
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. Verify the operating system is configured to disable non-essential capabilities. The most secure way of ensuring a non-essential capability is disabled is to not have the capability installed.
Checks: C-56532r824907_chk

Check to see if the sendmail package is installed with the following command: $ sudo yum list installed sendmail If the sendmail package is installed, this is a finding.

Fix: F-56482r824908_fix

Configure the operating system to disable non-essential capabilities by removing the sendmail package from the system with the following command: $ sudo yum remove sendmail

b
TOSS must not have the telnet-server package installed.
CM-7 - Medium - CCI-000381 - V-253080 - SV-253080r958478_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000381
Version
TOSS-04-040260
Vuln IDs
  • V-253080
Rule IDs
  • SV-253080r958478_rule
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. Verify the operating system is configured to disable non-essential capabilities. The most secure way of ensuring a non-essential capability is disabled is to not have the capability installed. The telnet service provides an unencrypted remote access service that does not provide for the confidentiality and integrity of user passwords or the remote session. If a privileged user were to log on using this service, the privileged user password could be compromised.
Checks: C-56533r824910_chk

Check to see if the telnet-server package is installed with the following command: $ sudo yum list installed telnet-server If the telnet-server package is installed, this is a finding.

Fix: F-56483r824911_fix

Configure the operating system to disable non-essential capabilities by removing the telnet-server package from the system with the following command: $ sudo yum remove telnet-server

b
TOSS 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.
CM-7 - Medium - CCI-000382 - V-253081 - SV-253081r958480_rule
RMF Control
CM-7
Severity
M
CCI
CCI-000382
Version
TOSS-04-040270
Vuln IDs
  • V-253081
Rule IDs
  • SV-253081r958480_rule
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.
Checks: C-56534r824913_chk

Inspect the firewall configuration and running services to verify it is configured to prohibit or restrict the use of functions, ports, protocols, and/or services that are unnecessary or prohibited. Check which services are currently active with the following command: $ sudo firewall-cmd --list-all-zones custom (active) target: DROP icmp-block-inversion: no interfaces: ens33 sources: services: dhcpv6-client dns http https ldaps rpc-bind ssh ports: masquerade: no forward-ports: icmp-blocks: rich rules: Ask the System Administrator for the site or program Ports, Protocols, and Services Management Component Local Service Assessment (PPSM CLSA). Verify the services allowed by the firewall match the PPSM CLSA. If there are additional ports, protocols, or services that are not in the PPSM CLSA, or there are ports, protocols, or services that are prohibited by the PPSM Category Assurance List (CAL), this is a finding.

Fix: F-56484r824914_fix

Update the host's firewall settings and/or running services to comply with the PPSM Component Local Service Assessment (CLSA) for the site or program and the PPSM CAL.

b
TOSS must be configured to disable USB mass storage.
IA-3 - Medium - CCI-000778 - V-253082 - SV-253082r986606_rule
RMF Control
IA-3
Severity
M
CCI
CCI-000778
Version
TOSS-04-040280
Vuln IDs
  • V-253082
Rule IDs
  • SV-253082r986606_rule
USB mass storage permits easy introduction of unknown devices, thereby facilitating malicious activity. Satisfies: SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-00163
Checks: C-56535r986605_chk

Verify the operating system disables the ability to load the USB Storage kernel module. $ sudo grep -r usb-storage /etc/modprobe.d/* | grep "install" install usb-storage /bin/false If the command does not return any output, or the line is commented out, and use of USB Storage is not documented with the information system security officer (ISSO) as an operational requirement, this is a finding. Verify the operating system disables the ability to use USB mass storage devices. Check to see if USB mass storage is disabled with the following command: $ sudo grep -r usb-storage /etc/modprobe.d/* | grep "blacklist" blacklist usb-storage If the command does not return any output or the output is not "blacklist usb-storage", and use of USB storage devices is not documented with the ISSO as an operational requirement, this is a finding.

Fix: F-56485r942858_fix

Configure the operating system to disable the ability to use the USB Storage kernel module. Create a file under "/etc/modprobe.d" with the following command: $ sudo touch /etc/modprobe.d/usb-storage.conf Add the following line to the created file: install usb-storage /bin/false Configure the operating system to disable the ability to use USB mass storage devices. $ sudo vi /etc/modprobe.d/blacklist.conf Add or update the line: blacklist usb-storage

b
TOSS must be configured so that all network connections associated with SSH traffic are terminated at the end of the session or after 10 minutes of inactivity, except to fulfill documented and validated mission requirements.
SC-10 - Medium - CCI-001133 - V-253083 - SV-253083r986603_rule
RMF Control
SC-10
Severity
M
CCI
CCI-001133
Version
TOSS-04-040290
Vuln IDs
  • V-253083
Rule IDs
  • SV-253083r986603_rule
Terminating an idle SSH session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle SSH 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 deallocating 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. TOSS utilizes /etc/ssh/sshd_config for configurations of OpenSSH. Within the sshd_config the product of the values of "ClientAliveInterval" and "ClientAliveCountMax" are used to establish the inactivity threshold. The "ClientAliveInterval" is a timeout interval in seconds after which if no data has been received from the client, sshd will send a message through the encrypted channel to request a response from the client. The "ClientAliveCountMax" is the number of client alive messages that may be sent without sshd receiving any messages back from the client. If this threshold is met, sshd will disconnect the client. The default setting for "ClientAliveCountMax" is "3." If "ClientAliveInterval is set to "15" and "ClientAliveCountMax" is left at the default, unresponsive SSH clients will be disconnected after approximately 45 seconds. Satisfies: SRG-OS-000126-GPOS-00066, SRG-OS-000163-GPOS-00072, SRG-OS-000279-GPOS-00109
Checks: C-56536r986601_chk

Verify all network connections associated with SSH traffic are automatically terminated at the end of the session or after 10 minutes of inactivity, or as long as documented with the information system security officer (ISSO) as an operational requirement. Check that the "ClientAliveInterval" variable is set to a value of "600" or less and that the "ClientAliveCountMax" is set to "1" by performing the following command: $ sudo grep -i clientalive /etc/ssh/sshd_config ClientAliveInterval 600 ClientAliveCountMax 1 If "ClientAliveInterval" and "ClientAliveCountMax" do not exist, does not have a product value of "600" or less in "/etc/ssh/sshd_config", or is commented out, this is a finding.

Fix: F-56486r986602_fix

Configure TOSS to automatically terminate all network connections associated with SSH traffic at the end of a session or after 10 minutes of inactivity, or as long as documented with the information system security officer (ISSO) as an operational requirement. Modify or append the following lines in the "/etc/ssh/sshd_config" file to have a product value of "600" or less: ClientAliveInterval 600 ClientAliveCountMax 1 In order for the changes to take effect, the SSH daemon must be restarted. $ sudo systemctl restart sshd.service

a
TOSS must have policycoreutils package installed.
SC-3 - Low - CCI-001084 - V-253084 - SV-253084r958518_rule
RMF Control
SC-3
Severity
L
CCI
CCI-001084
Version
TOSS-04-040310
Vuln IDs
  • V-253084
Rule IDs
  • SV-253084r958518_rule
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. Policycoreutils contains the policy core utilities that are required for basic operation of an SELinux-enabled system. These utilities include load_policy to load SELinux policies, setfile to label filesystems, newrole to switch roles, and run_init to run /etc/init.d scripts in the proper context.
Checks: C-56537r824922_chk

Verify the operating system has the policycoreutils package installed with the following command: $ sudo yum list installed policycoreutils policycoreutils.x86_64 2.9-16.el8 @anaconda If the policycoreutils package is not installed, this is a finding.

Fix: F-56487r824923_fix

Configure the operating system to have the policycoreutils package installed with the following command: $ sudo yum install policycoreutils

b
All TOSS local disk partitions must implement cryptographic mechanisms to prevent unauthorized disclosure or modification of all information that requires at rest protection.
SC-28 - Medium - CCI-001199 - V-253085 - SV-253085r958552_rule
RMF Control
SC-28
Severity
M
CCI
CCI-001199
Version
TOSS-04-040330
Vuln IDs
  • V-253085
Rule IDs
  • SV-253085r958552_rule
TOSS 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). Satisfies: SRG-OS-000185-GPOS-00079, SRG-OS-000404-GPOS-00183, SRG-OS-000405-GPOS-00184
Checks: C-56538r824925_chk

Verify TOSS prevents unauthorized disclosure or modification of all information requiring at-rest protection by using disk encryption. If there is a documented and approved reason for not having data-at-rest encryption, this requirement is Not Applicable. Verify all local system partitions are encrypted with the following command: $ sudo blkid /dev/mapper/rhel-root: UUID="67b7d7fe-de60-6fd0-befb-e6748cf97743" TYPE="crypto_LUKS" Every persistent disk partition present must be of TYPE "crypto_LUKS." If any partitions other than pseudo file systems (such as /proc or /sys) are not type "crypto_LUKS", ask the administrator to indicate how the partitions are encrypted. If there is no evidence that all local disk partitions are encrypted, this is a finding.

Fix: F-56488r824926_fix

Configure TOSS to prevent unauthorized modification of all information at rest by using disk encryption. Encrypting a partition in an already installed system is more difficult, because existing partitions will need to be resized and changed. To encrypt an entire partition, dedicate a partition for encryption in the partition layout.

b
TOSS must limit privileges to change software resident within software libraries.
CM-5 - Medium - CCI-001499 - V-253086 - SV-253086r991560_rule
RMF Control
CM-5
Severity
M
CCI
CCI-001499
Version
TOSS-04-040340
Vuln IDs
  • V-253086
Rule IDs
  • SV-253086r991560_rule
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 TOSS 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.
Checks: C-56539r824928_chk

Verify the system commands contained in the following directories are owned by "root" or an appropriate system account with the following command: $ sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -user root -exec ls -l {} \; If any system commands are returned which are not owned by an appropriate system account, this is a finding. Verify the system-wide shared library files are owned by "root" or an appropriate system account with the following command: $ sudo find -L /lib /lib64 /usr/lib /usr/lib64 ! -user root -exec ls -l {} \; If any system wide shared library file is returned which is not owned by an appropriate system account, this is a finding.

Fix: F-56489r824929_fix

Configure the system commands to be protected from unauthorized access. Run the following command, replacing "[FILE]" with any system command file not owned by "root." $ sudo chown root [FILE] Configure the system-wide shared library files (/lib, /lib64, /usr/lib and /usr/lib64) to be protected from unauthorized access. Run the following command, replacing "[FILE]" with any library file not owned by "root." $ sudo chown root [FILE]

b
TOSS must enforce password complexity by requiring that at least one special character be used.
Medium - CCI-004066 - V-253087 - SV-253087r991561_rule
RMF Control
Severity
M
CCI
CCI-004066
Version
TOSS-04-040350
Vuln IDs
  • V-253087
Rule IDs
  • SV-253087r991561_rule
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. TOSS utilizes "pwquality" as a mechanism to enforce password complexity. Note that to require special characters without degrading the "minlen" value, the credit value must be expressed as a negative number in "/etc/security/pwquality.conf."
Checks: C-56540r824931_chk

Verify the value for "ocredit" in "/etc/security/pwquality.conf" with the following command: $ sudo grep ocredit /etc/security/pwquality.conf ocredit = -1 If the value of "ocredit" is a positive number or is commented out, this is a finding.

Fix: F-56490r824932_fix

Configure the operating system to enforce password complexity by requiring that at least one special character be used by setting the "ocredit" option. Add the following line to /etc/security/pwquality.conf (or modify the line to have the required value): ocredit = -1

b
A firewall must be installed on TOSS.
AC-17 - Medium - CCI-002314 - V-253088 - SV-253088r958672_rule
RMF Control
AC-17
Severity
M
CCI
CCI-002314
Version
TOSS-04-040370
Vuln IDs
  • V-253088
Rule IDs
  • SV-253088r958672_rule
"Firewalld" provides an easy and effective way to block/limit remote access to the system via ports, services, and protocols. 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. TOSS functionality (e.g., SSH) 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).
Checks: C-56541r824934_chk

Verify that "firewalld" is installed and active with the following commands: $ sudo yum list installed firewalld firewalld.noarch 0.9.3-7.el8 $ sudo systemctl is-active firewalld active If the "firewalld" package is not installed and "active", ask the System Administrator if another firewall is installed. If no firewall is installed and active this is a finding.

Fix: F-56491r824935_fix

Install "firewalld" and enable with the following commands: $ sudo yum install firewalld.noarch $ sudo systemctl enable firewalld

b
TOSS must take appropriate action when the internal event queue is full.
AU-4 - Medium - CCI-001851 - V-253089 - SV-253089r958754_rule
RMF Control
AU-4
Severity
M
CCI
CCI-001851
Version
TOSS-04-040390
Vuln IDs
  • V-253089
Rule IDs
  • SV-253089r958754_rule
Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Offloading is a common process in information systems with limited audit storage capacity. TOSS installation media provides "rsyslogd." "rsyslogd" is a system utility providing support for message logging. Support for both internet and UNIX domain sockets enables this utility to support both local and remote logging. Couple this utility with "gnutls" (which is a secure communications library implementing the SSL, TLS, and DTLS protocols), and now there is a method to securely encrypt and offload auditing.
Checks: C-56542r826064_chk

Verify the audit system is configured to take an appropriate action when the internal event queue is full: $ sudo grep -i overflow_action /etc/audit/auditd.conf overflow_action = syslog If the value of the "overflow_action" option is not set to "syslog", "single", "halt", or the line is commented out, ask the System Administrator to indicate how the audit logs are offloaded to a different system or media. If there is no evidence that the transfer of the audit logs being offloaded to another system or media takes appropriate action if the internal event queue becomes full, this is a finding.

Fix: F-56492r824938_fix

Edit the /etc/audit/auditd.conf file and add or update the "overflow_action" option to one of "syslog", "single", or "halt": overflow_action = syslog The audit daemon must be restarted for changes to take effect.

b
TOSS must accept Personal Identity Verification (PIV) credentials.
IA-2 - Medium - CCI-001953 - V-253090 - SV-253090r958816_rule
RMF Control
IA-2
Severity
M
CCI
CCI-001953
Version
TOSS-04-040420
Vuln IDs
  • V-253090
Rule IDs
  • SV-253090r958816_rule
The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access. The DoD has mandated the use of the Common Access Card (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.
Checks: C-56543r824940_chk

Verify TOSS accepts PIV credentials. Check that the "opensc" package is installed on the system with the following command: $ sudo yum list installed opensc opensc.x86_64 0.20.0-4.el8 @anaconda Check that "opensc" accepts PIV cards with the following command: $ sudo opensc-tool --list-drivers | grep -i piv PIV-II Personal Identity Verification Card If the "opensc" package is not installed and the "opensc-tool" driver list does not include "PIV-II", this is a finding.

Fix: F-56493r824941_fix

Configure TOSS to accept PIV credentials. Install the "opensc" package using the following command: $ sudo yum install opensc

b
TOSS must implement DoD-approved encryption in the OpenSSL package.
MA-4 - Medium - CCI-002890 - V-253091 - SV-253091r958848_rule
RMF Control
MA-4
Severity
M
CCI
CCI-002890
Version
TOSS-04-040440
Vuln IDs
  • V-253091
Rule IDs
  • SV-253091r958848_rule
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. TOSS incorporates system-wide crypto policies by default. The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/openssl.config file.
Checks: C-56544r824943_chk

Verify the OpenSSL library is configured to use only ciphers employing FIPS 140-2-approved algorithms: Verify that system-wide crypto policies are in effect: $ sudo grep -i opensslcnf.config /etc/pki/tls/openssl.cnf .include /etc/crypto-policies/back-ends/opensslcnf.config If the "opensslcnf.config" is not defined in the "/etc/pki/tls/openssl.cnf" file, this is a finding. Verify which system-wide crypto policy is in use: $ sudo update-crypto-policies --show FIPS:OSPP If the system-wide crypto policy is set to anything other than "FIPS" or "FIPS:OSPP", this is a finding.

Fix: F-56494r824944_fix

Configure the TOSS OpenSSL library to use only ciphers employing FIPS 140-2-approved algorithms with the following command: $ sudo fips-mode-setup --enable A reboot is required for the changes to take effect.

b
A firewall must be able to protect against or limit the effects of Denial of Service (DoS) attacks by ensuring TOSS can implement rate-limiting measures on impacted network interfaces.
SC-5 - Medium - CCI-002385 - V-253092 - SV-253092r958902_rule
RMF Control
SC-5
Severity
M
CCI
CCI-002385
Version
TOSS-04-040480
Vuln IDs
  • V-253092
Rule IDs
  • SV-253092r958902_rule
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 TOSS 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 exists 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. Since version 0.6.0, "firewalld" has incorporated "nftables" as its backend support. Utilizing the limit statement in "nftables" can help to mitigate DoS attacks.
Checks: C-56545r824946_chk

Verify "firewalld" has "nftables" set as the default backend: $ sudo grep -i firewallbackend /etc/firewalld/firewalld.conf # FirewallBackend FirewallBackend=nftables If the "nftables" is not set as the "firewallbackend" default, this is a finding.

Fix: F-56495r824947_fix

Configure "nftables" to be the default "firewallbackend" for "firewalld" by adding or editing the following line in "/etc/firewalld/firewalld.conf": FirewallBackend=nftables Establish rate-limiting rules based on organization-defined types of DoS attacks on impacted network interfaces.

b
TOSS must implement non-executable data to protect its memory from unauthorized code execution.
SI-16 - Medium - CCI-002824 - V-253093 - SV-253093r958928_rule
RMF Control
SI-16
Severity
M
CCI
CCI-002824
Version
TOSS-04-040490
Vuln IDs
  • V-253093
Rule IDs
  • SV-253093r958928_rule
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 be either hardware-enforced or software-enforced with hardware providing the greater strength of mechanism. Examples of attacks are buffer overflow attacks.
Checks: C-56546r824949_chk

Verify the NX (no-execution) bit flag is set on the system. Check that the no-execution bit flag is set with the following commands: $ sudo dmesg | grep NX [ 0.000000] NX (Execute Disable) protection: active If "dmesg" does not show "NX (Execute Disable) protection" active, check the cpuinfo settings with the following command: $ sudo less /proc/cpuinfo | grep -i flags flags : fpu vme de pse tsc ms nx rdtscp lm constant_tsc If "flags" does not contain the "nx" flag, this is a finding.

Fix: F-56496r824950_fix

The NX bit execute protection must be enabled in the system BIOS.

a
YUM must remove all software components after updated versions have been installed on TOSS.
SI-2 - Low - CCI-002617 - V-253094 - SV-253094r958936_rule
RMF Control
SI-2
Severity
L
CCI
CCI-002617
Version
TOSS-04-040500
Vuln IDs
  • V-253094
Rule IDs
  • SV-253094r958936_rule
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.
Checks: C-56547r824952_chk

Verify the operating system removes all software components after updated versions have been installed. Check if YUM is configured to remove unneeded packages with the following command: $ sudo grep -i clean_requirements_on_remove /etc/dnf/dnf.conf clean_requirements_on_remove=True If "clean_requirements_on_remove" is not set to either "1", "True", or "yes", commented out, or is missing from "/etc/dnf/dnf.conf", this is a finding.

Fix: F-56497r824953_fix

Configure the operating system to remove all software components after updated versions have been installed. Set the "clean_requirements_on_remove" option to "True" in the "/etc/dnf/dnf.conf" file: clean_requirements_on_remove=True

b
TOSS must enable the "SELinux" targeted policy.
SI-6 - Medium - CCI-002696 - V-253095 - SV-253095r958944_rule
RMF Control
SI-6
Severity
M
CCI
CCI-002696
Version
TOSS-04-040510
Vuln IDs
  • V-253095
Rule IDs
  • SV-253095r958944_rule
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.
Checks: C-56548r824955_chk

Ensure TOSS verifies correct operation of all security functions. Check if "SELinux" is active and is enforcing the targeted policy with the following command: $ sudo sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 If the "Loaded policy name" is not set to "targeted", this is a finding. Verify that the /etc/selinux/config file is configured to the "SELINUXTYPE" to "targeted": $ sudo grep -i "selinuxtype" /etc/selinux/config | grep -v '^#' SELINUXTYPE = targeted If no results are returned or "SELINUXTYPE" is not set to "targeted", this is a finding.

Fix: F-56498r824956_fix

Configure the operating system to verify correct operation of all security functions. Set the "SELinuxtype" to the "targeted" policy by modifying the "/etc/selinux/config" file to have the following line: SELINUXTYPE=targeted A reboot is required for the changes to take effect.

b
TOSS must prevent the use of dictionary words for passwords.
CM-6 - Medium - CCI-000366 - V-253096 - SV-253096r991587_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040540
Vuln IDs
  • V-253096
Rule IDs
  • SV-253096r991587_rule
If TOSS 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.
Checks: C-56549r824958_chk

Verify TOSS prevents the use of dictionary words for passwords. Determine if the field "dictcheck" is set in the "/etc/security/pwquality.conf" or "/etc/security/pwquality.conf.d/*.conf" files with the following command: $ sudo grep -r dictcheck /etc/security/pwquality.conf /etc/security/pwquality.conf.d /etc/security/pwquality.conf:dictcheck=1 If the "dictcheck" parameter is not set to "1", or is commented out, this is a finding.

Fix: F-56499r824959_fix

Configure TOSS to prevent the use of dictionary words for passwords. Add or update the following line in the "/etc/security/pwquality.conf" file or a configuration file in the /etc/pwquality.conf.d/ directory to contain the "dictcheck" parameter: dictcheck=1

b
TOSS must enforce a delay of at least four seconds between logon prompts following a failed logon attempt.
CM-6 - Medium - CCI-000366 - V-253097 - SV-253097r991588_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040550
Vuln IDs
  • V-253097
Rule IDs
  • SV-253097r991588_rule
Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account.
Checks: C-56550r824961_chk

Verify the operating system enforces a delay of at least four seconds between console logon prompts following a failed logon attempt with the following command: $ sudo grep -i fail_delay /etc/login.defs FAIL_DELAY 4 If the value of "FAIL_DELAY" is not set to "4" or greater, or the line is commented out, this is a finding.

Fix: F-56500r824962_fix

Configure the operating system to enforce a delay of at least four seconds between logon prompts following a failed console logon attempt. Modify the "/etc/login.defs" file to set the "FAIL_DELAY" parameter to "4" or greater: FAIL_DELAY 4

c
A File Transfer Protocol (FTP) server package must not be installed unless mission essential on TOSS.
CM-6 - High - CCI-000366 - V-253098 - SV-253098r991589_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
TOSS-04-040560
Vuln IDs
  • V-253098
Rule IDs
  • SV-253098r991589_rule
The FTP service provides an unencrypted remote access that does not provide for the confidentiality and integrity of user passwords or the remote session. If a privileged user were to log on using this service, the privileged user password could be compromised. SSH or other encrypted file transfer methods must be used in place of this service.
Checks: C-56551r824964_chk

Verify an FTP server has not been installed on the system with the following commands: $ sudo yum list installed *ftpd* vsftpd.x86_64 3.0.3-28.el8 appstream If an FTP server is installed and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56501r824965_fix

Document the FTP server package with the ISSO as an operational requirement or remove it from the system with the following command: $ sudo yum remove vsftpd

b
All TOSS local files and directories must have a valid group owner.
CM-6 - Medium - CCI-000366 - V-253099 - SV-253099r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040570
Vuln IDs
  • V-253099
Rule IDs
  • SV-253099r991589_rule
Files without a valid group owner may be unintentionally inherited if a group is assigned the same Group Identifier (GID) as the GID of the files without a valid group owner.
Checks: C-56552r824967_chk

Verify all local files and directories on TOSS have a valid group with the following command: Note: The value after -fstype must be replaced with the filesystem type. XFS is used as an example. $ sudo find / -fstype xfs -nogroup If any files on the system do not have an assigned group, this is a finding. Note: Command may produce error messages from the /proc and /sys directories.

Fix: F-56502r824968_fix

Either remove all files and directories from TOSS that do not have a valid group, or assign a valid group to all files and directories on the system with the "chgrp" command: $ sudo chgrp <group> <file>

b
All TOSS local files and directories must have a valid owner.
CM-6 - Medium - CCI-000366 - V-253100 - SV-253100r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040580
Vuln IDs
  • V-253100
Rule IDs
  • SV-253100r991589_rule
Unowned files and directories may be unintentionally inherited if a user is assigned the same User Identifier "UID" as the UID of the un-owned files.
Checks: C-56553r824970_chk

Verify all local files and directories on TOSS have a valid owner with the following command: Note: The value after -fstype must be replaced with the filesystem type. XFS is used as an example. $ sudo find / -fstype xfs -nouser If any files on the system do not have an assigned owner, this is a finding. Note: Command may produce error messages from the /proc and /sys directories.

Fix: F-56503r824971_fix

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 TOSS with the "chown" command: $ sudo chown <user> <file>

b
Cron logging must be implemented in TOSS.
CM-6 - Medium - CCI-000366 - V-253101 - SV-253101r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040590
Vuln IDs
  • V-253101
Rule IDs
  • SV-253101r991589_rule
Cron logging can be used to trace the successful or unsuccessful execution of cron jobs. It can also be used to spot intrusions into the use of the cron facility by unauthorized and malicious users.
Checks: C-56554r824973_chk

Verify that "rsyslog" is configured to log cron events with the following command: Note: If another logging package is used, substitute the utility configuration file for "/etc/rsyslog.conf" or "/etc/rsyslog.d/*.conf" files. $ sudo grep -r cron /etc/rsyslog.conf /etc/rsyslog.d /etc/rsyslog.conf:*.info;mail.none;authpriv.none;cron.none /var/log/messages /etc/rsyslog.conf:# Log cron stuff /etc/rsyslog.conf:cron.* /var/log/cron If the command does not return a response, check for cron logging all facilities with the following command. $ sudo grep -r /var/log/messages /etc/rsyslog.conf /etc/rsyslog.d /etc/rsyslog.conf:*.info;mail.none;authpriv.none;cron.none /var/log/messages If "rsyslog" is not logging messages for the cron facility or all facilities, this is a finding.

Fix: F-56504r824974_fix

Configure "rsyslog" to log all cron messages by adding or updating the following line to "/etc/rsyslog.conf" or a configuration file in the /etc/rsyslog.d/ directory: cron.* /var/log/cron The rsyslog daemon must be restarted for the changes to take effect: $ sudo systemctl restart rsyslog.service

b
If the Trivial File Transfer Protocol (TFTP) server is required, the TOSS TFTP daemon must be configured to operate in secure mode.
CM-6 - Medium - CCI-000366 - V-253102 - SV-253102r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040600
Vuln IDs
  • V-253102
Rule IDs
  • SV-253102r991589_rule
Restricting TFTP to a specific directory prevents remote users from copying, transferring, or overwriting system files.
Checks: C-56555r824976_chk

Verify the TFTP daemon is configured to operate in secure mode with the following commands: $ sudo yum list installed tftp-server tftp-server.x86_64 x.x-x.el8 If a TFTP server is not installed, this is Not Applicable. If a TFTP server is installed, check for the server arguments with the following command: $ sudo grep server_args /etc/xinetd.d/tftp server_args = -s /var/lib/tftpboot If the "server_args" line does not have a "-s" option, and a subdirectory is not assigned, this is a finding.

Fix: F-56505r824977_fix

Configure the TFTP daemon to operate in secure mode by adding the following line to "/etc/xinetd.d/tftp" (or modify the line to have the required value): server_args = -s /var/lib/tftpboot

b
The graphical display manager must not be installed on TOSS unless approved.
CM-6 - Medium - CCI-000366 - V-253103 - SV-253103r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040610
Vuln IDs
  • V-253103
Rule IDs
  • SV-253103r991589_rule
Internet services that are not required for system or application processes must not be active to decrease the attack surface of the system. Graphical display managers have a long history of security vulnerabilities and must not be used, unless approved and documented.
Checks: C-56556r824979_chk

Verify that the system is configured to boot to the command line: $ systemctl get-default multi-user.target If the system default target is not set to "multi-user.target" and the Information System Security Officer (ISSO) lacks a documented requirement for a graphical user interface, this is a finding. Verify that a graphical user interface is not installed: $ rpm -qa | grep xorg | grep server Ask the System Administrator if use of a graphical user interface is an operational requirement. If the use of a graphical user interface on the system is not documented with the ISSO, this is a finding.

Fix: F-56506r824980_fix

Document the requirement for a graphical user interface with the ISSO or reinstall the operating system without the graphical user interface. If reinstallation is not feasible, then continue with the following procedure: Open an SSH session and enter the following commands: $ sudo systemctl set-default multi-user.target $ sudo yum remove xorg-x11-server-Xorg xorg-x11-server-common xorg-x11-server-utils xorg-x11-server-Xwayland A reboot is required for the changes to take effect.

a
The TOSS file integrity tool must be configured to verify Access Control Lists (ACLs).
CM-6 - Low - CCI-000366 - V-253104 - SV-253104r991589_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
TOSS-04-040630
Vuln IDs
  • V-253104
Rule IDs
  • SV-253104r991589_rule
ACLs can provide permissions beyond those permitted through the file mode and must be verified by file integrity tools. TOSS installation media come with a file integrity tool, Advanced Intrusion Detection Environment (AIDE).
Checks: C-56557r824982_chk

Verify the file integrity tool is configured to verify ACLs. Note: AIDE is highly configurable at install time. This requirement assumes the "aide.conf" file is under the "/etc" directory. If AIDE is not installed, ask the System Administrator how file integrity checks are performed on the system. Use the following command to determine if the file is in a location other than "/etc/aide/aide.conf": $ sudo find / -name aide.conf Check the "aide.conf" file to determine if the "acl" rule has been added to the rule list being applied to the files and directories selection lists with the following command: $ sudo egrep "[+]?acl" /etc/aide.conf VarFile = OwnerMode+n+l+X+acl If the "acl" rule is not being used on all selection lines in the "/etc/aide.conf" file, is commented out, or ACLs are not being checked by another file integrity tool, this is a finding.

Fix: F-56507r824983_fix

Configure the file integrity tool to check file and directory ACLs. If AIDE is installed, ensure the "acl" rule is present on all file and directory selection lists.

a
The TOSS file integrity tool must be configured to verify extended attributes.
CM-6 - Low - CCI-000366 - V-253105 - SV-253105r991589_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
TOSS-04-040640
Vuln IDs
  • V-253105
Rule IDs
  • SV-253105r991589_rule
Extended attributes in file systems are used to contain arbitrary data and file metadata with security implications. TOSS installation media come with a file integrity tool, Advanced Intrusion Detection Environment (AIDE).
Checks: C-56558r824985_chk

Verify the file integrity tool is configured to verify extended attributes. If AIDE is not installed, ask the System Administrator how file integrity checks are performed on the system. Note: AIDE is highly configurable at install time. This requirement assumes the "aide.conf" file is under the "/etc" directory. Use the following command to determine if the file is in another location: $ sudo find / -name aide.conf Check the "aide.conf" file to determine if the "xattrs" rule has been added to the rule list being applied to the files and directories selection lists. An example rule that includes the "xattrs" rule follows: All= p+i+n+u+g+s+m+S+sha512+acl+xattrs+selinux /bin All # apply the custom rule to the files in bin /sbin All # apply the same custom rule to the files in sbin If the "xattrs" rule is not being used on all uncommented selection lines in the "/etc/aide.conf" file, or extended attributes are not being checked by another file integrity tool, this is a finding.

Fix: F-56508r824986_fix

Configure the file integrity tool to check file and directory extended attributes. If AIDE is installed, ensure the "xattrs" rule is present on all uncommented file and directory selection lists.

b
The TOSS SSH daemon must perform strict mode checking of home directory configuration files.
CM-6 - Medium - CCI-000366 - V-253106 - SV-253106r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040650
Vuln IDs
  • V-253106
Rule IDs
  • SV-253106r991589_rule
If other users have access to modify user-specific SSH configuration files, they may be able to log on to the system as another user.
Checks: C-56559r824988_chk

Verify the SSH daemon performs strict mode checking of home directory configuration files with the following command: $ sudo grep -i strictmodes /etc/ssh/sshd_config StrictModes yes If "StrictModes" is set to "no", is missing, or the returned line is commented out, this is a finding.

Fix: F-56509r824989_fix

Configure SSH to perform strict mode checking of home directory configuration files. Uncomment the "StrictModes" keyword in "/etc/ssh/sshd_config" and set the value to "yes": StrictModes yes The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

b
The TOSS SSH private host key files must have mode 0600 or less permissive.
CM-6 - Medium - CCI-000366 - V-253107 - SV-253107r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040660
Vuln IDs
  • V-253107
Rule IDs
  • SV-253107r991589_rule
If an unauthorized user obtains the private SSH host key file, the host could be impersonated.
Checks: C-56560r824991_chk

Verify the SSH private host key files have mode "0600" or less permissive with the following command: $ sudo ls -l /etc/ssh/ssh_host*key -rw------- 1 root ssh_keys 668 Nov 28 06:43 ssh_host_dsa_key -rw------- 1 root ssh_keys 582 Nov 28 06:43 ssh_host_key -rw------- 1 root ssh_keys 887 Nov 28 06:43 ssh_host_rsa_key If any private host key file has a mode more permissive than "0600", this is a finding.

Fix: F-56510r824992_fix

Configure the mode of SSH private host key files under "/etc/ssh" to "0600" with the following command: $ sudo chmod 0600 /etc/ssh/ssh_host*key The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

b
The TOSS SSH public host key files must have mode 0644 or less permissive.
CM-6 - Medium - CCI-000366 - V-253108 - SV-253108r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040670
Vuln IDs
  • V-253108
Rule IDs
  • SV-253108r991589_rule
If a public host key file is modified by an unauthorized user, the SSH service may be compromised.
Checks: C-56561r824994_chk

Verify the SSH public host key files have mode "0644" or less permissive with the following command: $ sudo ls -l /etc/ssh/*.pub -rw-r--r-- 1 root root 618 Nov 28 06:43 ssh_host_dsa_key.pub -rw-r--r-- 1 root root 347 Nov 28 06:43 ssh_host_key.pub -rw-r--r-- 1 root root 238 Nov 28 06:43 ssh_host_rsa_key.pub If any key.pub file has a mode more permissive than "0644", this is a finding. Note: SSH public key files may be found in other directories on the system depending on the installation.

Fix: F-56511r824995_fix

Change the mode of public host key files under "/etc/ssh" to "0644" with the following command: $ sudo chmod 0644 /etc/ssh/*key.pub The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command: $ sudo systemctl restart sshd.service

c
The x86 Ctrl-Alt-Delete key sequence must be disabled on TOSS.
CM-6 - High - CCI-000366 - V-253109 - SV-253109r991589_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
TOSS-04-040680
Vuln IDs
  • V-253109
Rule IDs
  • SV-253109r991589_rule
A locally logged-on user, who presses Ctrl-Alt-Delete when at the console, can reboot the system. If accidentally pressed, as could happen in the case of a mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. In a graphical user environment, risk of unintentional reboot from the Ctrl-Alt-Delete sequence is reduced because the user will be prompted before any action is taken.
Checks: C-56562r824997_chk

Verify TOSS is not configured to reboot the system when Ctrl-Alt-Delete is pressed with the following command: $ sudo systemctl status ctrl-alt-del.target ctrl-alt-del.target Loaded: masked (Reason: Unit ctrl-alt-del.target is masked.) Active: inactive (dead) If the "ctrl-alt-del.target" is loaded and not masked, this is a finding.

Fix: F-56512r824998_fix

Configure the system to disable the Ctrl-Alt-Delete sequence for the command line with the following command: $ sudo systemctl mask ctrl-alt-del.target Created symlink /etc/systemd/system/ctrl-alt-del.target -> /dev/null Reload the daemon for this change to take effect. $ sudo systemctl daemon-reload

c
TOSS must be a vendor-supported release.
CM-6 - High - CCI-000366 - V-253110 - SV-253110r991589_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
TOSS-04-040690
Vuln IDs
  • V-253110
Rule IDs
  • SV-253110r991589_rule
An operating system release is considered "supported" if the vendor continues to provide security patches for the product. With an unsupported release, it will not be possible to resolve security issues discovered in the system software.
Checks: C-56563r825000_chk

Verify the version of the operating system is vendor supported. Check the version of the operating system with the following command: $ sudo cat /etc/toss-release toss-release-4.3-3 Current End of support for TOSS 4.3 is 30 April 2022. Current End of support for TOSS 4.4 is 30 November 2023. Current End of support for TOSS 4.5 is 30 April 2023. Current End of support for TOSS 4.6 is 30 November 2023. Current End of support for TOSS 4.7 is 30 April 2024. Current End of support for TOSS 4.8 is 31 May 2029. If the release is not supported by the vendor, this is a finding.

Fix: F-56513r825001_fix

Upgrade to a supported version of TOSS.

b
TOSS must be configured to prevent unrestricted mail relaying.
CM-6 - Medium - CCI-000366 - V-253111 - SV-253111r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040700
Vuln IDs
  • V-253111
Rule IDs
  • SV-253111r991589_rule
If unrestricted mail relaying is permitted, unauthorized senders could use this host as a mail relay for the purpose of sending spam or other unauthorized activity.
Checks: C-56564r825003_chk

Verify the system is configured to prevent unrestricted mail relaying. Determine if "postfix" is installed with the following commands: $ sudo yum list installed postfix postfix.x86_64 2:3.5.8-2.el8 If postfix is not installed, this is Not Applicable. If postfix is installed, determine if it is configured to reject connections from unknown or untrusted networks with the following command: $ sudo postconf -n smtpd_client_restrictions smtpd_client_restrictions = permit_mynetworks, reject If the "smtpd_client_restrictions" parameter contains any entries other than "permit_mynetworks" and "reject", this is a finding.

Fix: F-56514r825004_fix

If "postfix" is installed, 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'

b
TOSS must define default permissions for logon and non-logon shells.
CM-6 - Medium - CCI-000366 - V-253112 - SV-253112r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040710
Vuln IDs
  • V-253112
Rule IDs
  • SV-253112r991589_rule
The umask controls the default access mode assigned to newly created files. A umask of 077 limits new files to mode 600 or less permissive. Although umask can be represented as a four-digit number, the first digit representing special access modes is typically ignored or required to be "0." This requirement applies to the globally configured system defaults and the local interactive user defaults for each account on the system.
Checks: C-56565r825006_chk

Verify that the umask default for installed shells is "077." Check for the value of the "UMASK" parameter in the "/etc/bashrc" and "/etc/csh.cshrc" files with the following command: Note: If the value of the "UMASK" parameter is set to "000" in either the "/etc/bashrc" or the "/etc/csh.cshrc" files, the severity is raised to a CAT I. $ sudo grep -i umask /etc/bashrc /etc/csh.cshrc /etc/bashrc: umask 077 /etc/bashrc: umask 077 /etc/csh.cshrc: umask 077 /etc/csh.cshrc: umask 077 If the value for the "UMASK" parameter is not "077", or the "UMASK" parameter is missing or is commented out, this is a finding.

Fix: F-56515r825007_fix

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. Add or edit the lines for the "UMASK" parameter in the "/etc/bashrc" and "etc/csh.cshrc" files to "077": UMASK 077

b
TOSS must disable access to network bpf syscall from unprivileged processes.
CM-6 - Medium - CCI-000366 - V-253113 - SV-253113r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040720
Vuln IDs
  • V-253113
Rule IDs
  • SV-253113r991589_rule
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.
Checks: C-56566r825009_chk

Verify TOSS prevents privilege escalation thru the kernel by disabling access to the bpf syscall with the following commands: $ sudo sysctl kernel.unprivileged_bpf_disabled kernel.unprivileged_bpf_disabled = 1 If the returned line does not have a value of "1", or a line is not returned, this is a finding.

Fix: F-56516r825010_fix

Configure TOSS to prevent privilege escalation thru the kernel by disabling access to the bpf syscall by adding the following line to a file in the "/etc/sysctl.d" directory: kernel.unprivileged_bpf_disabled = 1 The system configuration files need to be reloaded for the changes to take effect. To reload the contents of the files, run the following command: $ sudo sysctl --system

b
TOSS must enable hardening for the Berkeley Packet Filter Just-in-time compiler.
CM-6 - Medium - CCI-000366 - V-253114 - SV-253114r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040730
Vuln IDs
  • V-253114
Rule IDs
  • SV-253114r991589_rule
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. Enabling hardening for the Berkeley Packet Filter (BPF) Just-in-time (JIT) compiler aids in mitigating JIT spraying attacks. Setting the value to "2" enables JIT hardening for all users.
Checks: C-56567r825012_chk

Verify TOSS enables hardening for the BPF JIT with the following commands: $ sudo sysctl net.core.bpf_jit_harden net.core.bpf_jit_harden = 2 If the returned line does not have a value of "2", or a line is not returned, this is a finding.

Fix: F-56517r825013_fix

Configure TOSS to enable hardening for the BPF JIT compiler by adding the following line to a file in the "/etc/sysctl.d" directory: net.core.bpf_jit_harden = 2 The system configuration files need to be reloaded for the changes to take effect. To reload the contents of the files, run the following command: $ sudo sysctl --system

b
TOSS must enable the hardware random number generator entropy gatherer service.
CM-6 - Medium - CCI-000366 - V-253115 - SV-253115r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040740
Vuln IDs
  • V-253115
Rule IDs
  • SV-253115r991589_rule
The most important characteristic of a random number generator is its randomness, namely its ability to deliver random numbers that are impossible to predict. Entropy in computer security is associated with the unpredictability of a source of randomness. The random source with high entropy tends to achieve a uniform distribution of random values. Random number generators are one of the most important building blocks of cryptosystems. The rngd service feeds random data from hardware device to kernel random device. Quality (non-predictable) random number generation is important for several security functions (i.e., ciphers).
Checks: C-56568r825015_chk

Check that TOSS has enabled the hardware random number generator entropy gatherer service. Verify the rngd service is enabled and active with the following commands: $ sudo systemctl is-enabled rngd enabled $ sudo systemctl is-active rngd active If the service is not "enable and "active", this is a finding.

Fix: F-56518r825016_fix

Start the rngd service and enable the rngd service with the following commands: $ sudo systemctl start rngd.service $ sudo systemctl enable rngd.service

a
TOSS must ensure the SSH server uses strong entropy.
CM-6 - Low - CCI-000366 - V-253116 - SV-253116r991589_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
TOSS-04-040750
Vuln IDs
  • V-253116
Rule IDs
  • SV-253116r991589_rule
The most important characteristic of a random number generator is its randomness, namely its ability to deliver random numbers that are impossible to predict. Entropy in computer security is associated with the unpredictability of a source of randomness. The random source with high entropy tends to achieve a uniform distribution of random values. Random number generators are one of the most important building blocks of cryptosystems. The SSH implementation in TOSS uses the OPENSSL library, which does not use high-entropy sources by default. By using the SSH_USE_STRONG_RNG environment variable the OPENSSL random generator is reseeded from /dev/random. This setting is not recommended on computers without the hardware random generator because insufficient entropy causes the connection to be blocked until enough entropy is available.
Checks: C-56569r825018_chk

Verify the operating system SSH server uses strong entropy with the following command: $ sudo grep -i ssh_use_strong_rng /etc/sysconfig/sshd SSH_USE_STRONG_RNG=32 If the "SSH_USE_STRONG_RNG" line does not equal "32", is commented out or missing, this is a finding.

Fix: F-56519r825019_fix

Configure the operating system SSH server to use strong entropy. Add or modify the following line in the "/etc/sysconfig/sshd" file. SSH_USE_STRONG_RNG=32 The SSH service must be restarted for changes to take effect.

a
TOSS must have the packages required to use the hardware random number generator entropy gatherer service.
CM-6 - Low - CCI-000366 - V-253117 - SV-253117r991589_rule
RMF Control
CM-6
Severity
L
CCI
CCI-000366
Version
TOSS-04-040760
Vuln IDs
  • V-253117
Rule IDs
  • SV-253117r991589_rule
The most important characteristic of a random number generator is its randomness, namely its ability to deliver random numbers that are impossible to predict. Entropy in computer security is associated with the unpredictability of a source of randomness. The random source with high entropy tends to achieve a uniform distribution of random values. Random number generators are one of the most important building blocks of cryptosystems. The rngd service feeds random data from hardware device to kernel random device. Quality (non-predictable) random number generation is important for several security functions (i.e., ciphers).
Checks: C-56570r825021_chk

Check that TOSS has the packages required to enable the hardware random number generator entropy gatherer service with the following command: $ sudo yum list installed rng-tools rng-tools.x86_64 6.13-1.git.d207e0b6.el8 @anaconda If the "rng-tools" package is not installed, this is a finding.

Fix: F-56520r825022_fix

Install the packages required to enable the hardware random number generator entropy gatherer service with the following command: $ sudo yum install rng-tools

b
TOSS must ignore IPv4 Internet Control Message Protocol (ICMP) redirect messages.
CM-6 - Medium - CCI-000366 - V-253118 - SV-253118r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040770
Vuln IDs
  • V-253118
Rule IDs
  • SV-253118r991589_rule
ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.
Checks: C-56571r825024_chk

Verify TOSS ignores IPv4 ICMP redirect messages. Note: If IPv4 is disabled on the system, this requirement is Not Applicable. Check the value of the "accept_redirects" variables with the following command: $ sudo sysctl net.ipv4.conf.all.accept_redirects net.ipv4.conf.all.accept_redirects = 0 If the returned line does not have a value of "0", a line is not returned, or the line is commented out, this is a finding.

Fix: F-56521r825025_fix

Configure TOSS to ignore IPv4 ICMP redirect messages with the following command: $ sudo sysctl -w net.ipv4.conf.all.accept_redirects=0 If "0" is not the system's default value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv4.conf.all.accept_redirects = 0

b
TOSS must ignore IPv6 Internet Control Message Protocol (ICMP) redirect messages.
CM-6 - Medium - CCI-000366 - V-253119 - SV-253119r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040780
Vuln IDs
  • V-253119
Rule IDs
  • SV-253119r991589_rule
ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.
Checks: C-56572r825027_chk

Verify TOSS ignores IPv6 ICMP redirect messages. Note: If IPv6 is disabled on the system, this requirement is Not Applicable. Check the value of the "accept_redirects" variables with the following command: $ sudo sysctl net.ipv6.conf.all.accept_redirects net.ipv6.conf.all.accept_redirects = 0 If the returned line does not have a value of "0", a line is not returned, or the line is commented out, this is a finding.

Fix: F-56522r825028_fix

Configure TOSS to ignore IPv6 ICMP redirect messages with the following command: $ sudo sysctl -w net.ipv6.conf.all.accept_redirects=0 If "0" is not the system's default value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv6.conf.all.accept_redirects = 0

b
TOSS must not accept router advertisements on all IPv6 interfaces by default.
CM-6 - Medium - CCI-000366 - V-253120 - SV-253120r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040790
Vuln IDs
  • V-253120
Rule IDs
  • SV-253120r991589_rule
Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this software is used when not required, system network information may be unnecessarily transmitted across the network. An illicit router advertisement message could result in a man-in-the-middle attack.
Checks: C-56573r825030_chk

Verify TOSS does not accept router advertisements on all IPv6 interfaces by default, unless the system is a router. Note: If IPv6 is disabled on the system, this requirement is Not Applicable. Check to see if router advertisements are not accepted by default by using the following command: $ sudo sysctl net.ipv6.conf.default.accept_ra net.ipv6.conf.default.accept_ra = 0 If the "accept_ra" value is not "0" and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56523r825031_fix

Configure TOSS to not accept router advertisements on all IPv6 interfaces by default unless the system is a router with the following commands: $ sudo sysctl -w net.ipv6.conf.default.accept_ra=0 If "0" is not the system's default value then add or update the following lines in the appropriate file under "/etc/sysctl.d": net.ipv6.conf.default.accept_ra=0

b
TOSS must not accept router advertisements on all IPv6 interfaces.
CM-6 - Medium - CCI-000366 - V-253121 - SV-253121r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040800
Vuln IDs
  • V-253121
Rule IDs
  • SV-253121r991589_rule
Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this software is used when not required, system network information may be unnecessarily transmitted across the network. An illicit router advertisement message could result in a man-in-the-middle attack.
Checks: C-56574r825033_chk

Verify TOSS does not accept router advertisements on all IPv6 interfaces, unless the system is a router. Note: If IPv6 is disabled on the system, this requirement is Not Applicable. Check to see if router advertisements are not accepted by using the following command: $ sudo sysctl net.ipv6.conf.all.accept_ra net.ipv6.conf.all.accept_ra = 0 If the "accept_ra" value is not "0" and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix: F-56524r825034_fix

Configure TOSS to not accept router advertisements on all IPv6 interfaces unless the system is a router with the following commands: $ sudo sysctl -w net.ipv6.conf.all.accept_ra=0 If "0" is not the system's default value then add or update the following lines in the appropriate file under "/etc/sysctl.d": net.ipv6.conf.all.accept_ra=0

c
TOSS must not allow blank or null passwords in the password-auth file.
CM-6 - High - CCI-000366 - V-253122 - SV-253122r991589_rule
RMF Control
CM-6
Severity
H
CCI
CCI-000366
Version
TOSS-04-040810
Vuln IDs
  • V-253122
Rule IDs
  • SV-253122r991589_rule
If an account has an empty password, anyone could log on and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.
Checks: C-56575r825036_chk

To verify that null passwords cannot be used, run the following command: $ sudo grep -i nullok /etc/pam.d/password-auth If output is produced, this is a finding.

Fix: F-56525r825037_fix

Remove any instances of the "nullok" option in the "/etc/pam.d/password-auth" file to prevent logons with empty passwords. Note: Manual changes to the listed file may be overwritten by the "authselect" program.

b
TOSS must not allow interfaces to perform Internet Control Message Protocol (ICMP) redirects by default.
CM-6 - Medium - CCI-000366 - V-253123 - SV-253123r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040820
Vuln IDs
  • V-253123
Rule IDs
  • SV-253123r991589_rule
ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table, possibly revealing portions of the network topology. There are notable differences between Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6). There is only a directive to disable sending of IPv4 redirected packets. Refer to RFC4294 for an explanation of "IPv6 Node Requirements", which resulted in this difference between IPv4 and IPv6.
Checks: C-56576r825039_chk

Verify TOSS does not allow interfaces to perform Internet Protocol version 4 (IPv4) ICMP redirects by default. Note: If IPv4 is disabled on the system, this requirement is Not Applicable. Check the value of the "default send_redirects" variables with the following command: $ sudo sysctl net.ipv4.conf.default.send_redirects net.ipv4.conf.default.send_redirects=0 If the returned line does not have a value of "0", or a line is not returned, this is a finding.

Fix: F-56526r825040_fix

Configure TOSS to not allow interfaces to perform Internet Protocol version 4 (IPv4) ICMP redirects by default with the following command: $ sudo sysctl -w net.ipv4.conf.default.send_redirects=0 If "0" is not the system's default value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv4.conf.default.send_redirects=0

b
TOSS must not forward IPv4 source-routed packets by default.
CM-6 - Medium - CCI-000366 - V-253124 - SV-253124r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040830
Vuln IDs
  • V-253124
Rule IDs
  • SV-253124r991589_rule
Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when forwarding is enabled and the system is functioning as a router.
Checks: C-56577r825042_chk

Verify TOSS does not accept IPv4 source-routed packets by default. Note: If IPv4 is disabled on the system, this requirement is Not Applicable. Check the value of the accept source route variable with the following command: $ sudo sysctl net.ipv4.conf.default.accept_source_route net.ipv4.conf.default.accept_source_route = 0 If the returned line does not have a value of "0", a line is not returned, or the line is commented out, this is a finding.

Fix: F-56527r825043_fix

Configure TOSS to not forward IPv4 source-routed packets by default with the following command: $ sudo sysctl -w net.ipv4.conf.default.accept_source_route=0 If "0" is not the system's default value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv4.conf.default.accept_source_route=0

b
TOSS must not forward IPv4 source-routed packets.
CM-6 - Medium - CCI-000366 - V-253125 - SV-253125r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040840
Vuln IDs
  • V-253125
Rule IDs
  • SV-253125r991589_rule
Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when forwarding is enabled and the system is functioning as a router.
Checks: C-56578r825045_chk

Verify TOSS does not accept IPv4 source-routed packets. Note: If IPv4 is disabled on the system, this requirement is Not Applicable. Check the value of the accept source route variable with the following command: $ sudo sysctl net.ipv4.conf.all.accept_source_route net.ipv4.conf.all.accept_source_route = 0 If the returned line does not have a value of "0", a line is not returned, or the line is commented out, this is a finding.

Fix: F-56528r825046_fix

Configure TOSS to not forward IPv4 source-routed packets with the following command: $ sudo sysctl -w net.ipv4.conf.all.accept_source_route=0 If "0" is not the system's all value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv4.conf.all.accept_source_route=0

b
TOSS must not forward IPv6 source-routed packets by default.
CM-6 - Medium - CCI-000366 - V-253126 - SV-253126r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040850
Vuln IDs
  • V-253126
Rule IDs
  • SV-253126r991589_rule
Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when forwarding is enabled and the system is functioning as a router.
Checks: C-56579r825048_chk

Verify TOSS does not accept IPv6 source-routed packets by default. Note: If IPv6 is disabled on the system, this requirement is Not Applicable. Check the value of the accept source route variable with the following command: $ sudo sysctl net.ipv6.conf.default.accept_source_route net.ipv6.conf.default.accept_source_route = 0 If the returned line does not have a value of "0", a line is not returned, or the line is commented out, this is a finding.

Fix: F-56529r825049_fix

Configure TOSS to not forward IPv6 source-routed packets by default with the following command: $ sudo sysctl -w net.ipv6.conf.default.accept_source_route=0 If "0" is not the system's default value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv6.conf.default.accept_source_route=0

b
TOSS must not forward IPv6 source-routed packets.
CM-6 - Medium - CCI-000366 - V-253127 - SV-253127r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040860
Vuln IDs
  • V-253127
Rule IDs
  • SV-253127r991589_rule
Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when forwarding is enabled and the system is functioning as a router.
Checks: C-56580r825051_chk

Verify TOSS does not accept IPv6 source-routed packets. Note: If IPv6 is disabled on the system, this requirement is Not Applicable. Check the value of the accept source route variable with the following command: $ sudo sysctl net.ipv6.conf.all.accept_source_route net.ipv6.conf.all.accept_source_route = 0 If the returned line does not have a value of "0", a line is not returned, or the line is commented out, this is a finding.

Fix: F-56530r825052_fix

Configure TOSS to not forward IPv6 source-routed packets with the following command: $ sudo sysctl -w net.ipv6.conf.all.accept_source_route=0 If "0" is not the system's all value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv6.conf.all.accept_source_route=0

b
TOSS must not respond to Internet Control Message Protocol (ICMP) echoes sent to a broadcast address.
CM-6 - Medium - CCI-000366 - V-253128 - SV-253128r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040870
Vuln IDs
  • V-253128
Rule IDs
  • SV-253128r991589_rule
Responding to broadcast ICMP echoes facilitates network mapping and provides a vector for amplification attacks. There are notable differences between Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6). IPv6 does not implement the same method of broadcast as IPv4. Instead, IPv6 uses multicast addressing to the all-hosts multicast group. Refer to RFC4294 for an explanation of "IPv6 Node Requirements", which resulted in this difference between IPv4 and IPv6.
Checks: C-56581r825054_chk

Verify TOSS does not respond to ICMP echoes sent to a broadcast address. Note: If IPv4 is disabled on the system, this requirement is Not Applicable. Check the value of the "icmp_echo_ignore_broadcasts" variable with the following command: $ sudo sysctl net.ipv4.icmp_echo_ignore_broadcasts net.ipv4.icmp_echo_ignore_broadcasts = 1 If the returned line does not have a value of "1", a line is not returned, or the retuned line is commented out, this is a finding.

Fix: F-56531r825055_fix

Configure TOSS to not respond to IPv4 ICMP echoes sent to a broadcast address with the following command: $ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1 If "1" is not the system's default value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv4.icmp_echo_ignore_broadcasts=1

b
TOSS must not send Internet Control Message Protocol (ICMP) redirects.
CM-6 - Medium - CCI-000366 - V-253129 - SV-253129r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040880
Vuln IDs
  • V-253129
Rule IDs
  • SV-253129r991589_rule
ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table, possibly revealing portions of the network topology. There are notable differences between Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6). There is only a directive to disable sending of IPv4 redirected packets. Refer to RFC4294 for an explanation of "IPv6 Node Requirements", which resulted in this difference between IPv4 and IPv6.
Checks: C-56582r825057_chk

Verify TOSS does not IPv4 ICMP redirect messages. Note: If IPv4 is disabled on the system, this requirement is Not Applicable. Check the value of the "all send_redirects" variables with the following command: $ sudo sysctl net.ipv4.conf.all.send_redirects net.ipv4.conf.all.send_redirects = 0 If the returned line does not have a value of "0", or a line is not returned, this is a finding.

Fix: F-56532r825058_fix

Configure TOSS to not allow interfaces to perform IPv4 ICMP redirects with the following command: $ sudo sysctl -w net.ipv4.conf.all.send_redirects=0 If "0" is not the system's default value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv4.conf.all.send_redirects=0

b
TOSS must prevent IPv4 Internet Control Message Protocol (ICMP) redirect messages from being accepted.
CM-6 - Medium - CCI-000366 - V-253130 - SV-253130r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040890
Vuln IDs
  • V-253130
Rule IDs
  • SV-253130r991589_rule
ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.
Checks: C-56583r825060_chk

Verify TOSS will not accept IPv4 ICMP redirect messages. Note: If IPv4 is disabled on the system, this requirement is Not Applicable. Check the value of the default "accept_redirects" variables with the following command: $ sudo sysctl net.ipv4.conf.default.accept_redirects net.ipv4.conf.default.accept_redirects = 0 If the returned line does not have a value of "0", a line is not returned, or the line is commented out, this is a finding.

Fix: F-56533r825061_fix

Configure TOSS to prevent IPv4 ICMP redirect messages from being accepted with the following command: $ sudo sysctl -w net.ipv4.conf.default.accept_redirects=0 If "0" is not the system's default value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv4.conf.default.accept_redirects=0

b
TOSS must prevent IPv6 Internet Control Message Protocol (ICMP) redirect messages from being accepted.
CM-6 - Medium - CCI-000366 - V-253131 - SV-253131r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040900
Vuln IDs
  • V-253131
Rule IDs
  • SV-253131r991589_rule
ICMP redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.
Checks: C-56584r825063_chk

Verify TOSS will not accept IPv6 ICMP redirect messages. Note: If IPv6 is disabled on the system, this requirement is Not Applicable. Check the value of the default "accept_redirects" variables with the following command: $ sudo sysctl net.ipv6.conf.default.accept_redirects net.ipv6.conf.default.accept_redirects = 0 If the returned line does not have a value of "0", a line is not returned, or the line is commented out, this is a finding.

Fix: F-56534r825064_fix

Configure TOSS to prevent IPv6 ICMP redirect messages from being accepted with the following command: $ sudo sysctl -w net.ipv6.conf.default.accept_redirects=0 If "0" is not the system's default value then add or update the following line in the appropriate file under "/etc/sysctl.d": net.ipv6.conf.default.accept_redirects=0

b
TOSS must restrict exposed kernel pointer addresses access.
CM-6 - Medium - CCI-000366 - V-253132 - SV-253132r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040910
Vuln IDs
  • V-253132
Rule IDs
  • SV-253132r991589_rule
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.
Checks: C-56585r825066_chk

Verify TOSS restricts exposed kernel pointer addresses access with the following commands: $ sudo sysctl kernel.kptr_restrict kernel.kptr_restrict = 1 If the returned line does not have a value of "1", or a line is not returned, this is a finding.

Fix: F-56535r825067_fix

Configure TOSS to restrict exposed kernel pointer addresses access by adding the following line to a file in the "/etc/sysctl.d" directory: kernel.kptr_restrict = 1 The system configuration files need to be reloaded for the changes to take effect. To reload the contents of the files, run the following command: $ sudo sysctl --system

b
TOSS must restrict privilege elevation to authorized personnel.
CM-6 - Medium - CCI-000366 - V-253133 - SV-253133r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040920
Vuln IDs
  • V-253133
Rule IDs
  • SV-253133r991589_rule
The sudo command allows a user to execute programs with elevated (administrator) privileges. It prompts the user for their password and confirms the request to execute a command by checking a file, called sudoers. If the "sudoers" file is not configured correctly, any user defined on the system can initiate privileged actions on the target system.
Checks: C-56586r825069_chk

Verify the "sudoers" file restricts sudo access to authorized personnel. $ sudo grep -iwr 'ALL[[:blank:]]\+ALL' /etc/sudoers /etc/sudoers.d If the either of the following entries are returned, this is a finding: ALL ALL=(ALL) ALL ALL ALL=(ALL:ALL) ALL

Fix: F-56536r825070_fix

Remove the following entries from the sudoers file: ALL ALL=(ALL) ALL ALL ALL=(ALL:ALL) ALL

b
TOSS must use reverse path filtering on all IPv4 interfaces.
CM-6 - Medium - CCI-000366 - V-253134 - SV-253134r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040930
Vuln IDs
  • V-253134
Rule IDs
  • SV-253134r991589_rule
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. Enabling reverse path filtering drops packets with source addresses that are not routable. There is not an equivalent filter for IPv6 traffic.
Checks: C-56587r825072_chk

Verify TOSS uses reverse path filtering on all IPv4 interfaces with the following commands: $ sudo sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.all.rp_filter = 1 If the returned line does not have a value of "1", or a line is not returned, this is a finding.

Fix: F-56537r825073_fix

Configure TOSS to use reverse path filtering on all IPv4 interfaces by adding the following line to a file in the "/etc/sysctl.d" directory: net.ipv4.conf.all.rp_filter = 1 The system configuration files need to be reloaded for the changes to take effect. To reload the contents of the files, run the following command: $ sudo sysctl --system

b
TOSS network interfaces must not be in promiscuous mode.
CM-6 - Medium - CCI-000366 - V-253135 - SV-253135r991589_rule
RMF Control
CM-6
Severity
M
CCI
CCI-000366
Version
TOSS-04-040940
Vuln IDs
  • V-253135
Rule IDs
  • SV-253135r991589_rule
Network interfaces in promiscuous mode allow for the capture of all network traffic visible to the system. If unauthorized individuals can access these applications, it may allow them to collect information such as logon IDs, passwords, and key exchanges between systems. If the system is being used to perform a network troubleshooting function, the use of these tools must be documented with the Information System Security Officer (ISSO) and restricted to only authorized personnel.
Checks: C-56588r825075_chk

Verify network interfaces are not in promiscuous mode unless approved by the ISSO and documented. Check for the status with the following command: $ sudo ip link | grep -i promisc If network interfaces are found on the system in promiscuous mode and their use has not been approved by the ISSO and documented, this is a finding.

Fix: F-56538r825076_fix

Configure network interfaces to turn off promiscuous mode unless approved by the ISSO and documented. Set the promiscuous mode of an interface to off with the following command: $ sudo ip link set dev <devicename> multicast off promisc off

b
TOSS must enable kernel parameters to enforce discretionary access control on symlinks.
AC-3 - Medium - CCI-002165 - V-253136 - SV-253136r958702_rule
RMF Control
AC-3
Severity
M
CCI
CCI-002165
Version
TOSS-04-040950
Vuln IDs
  • V-253136
Rule IDs
  • SV-253136r958702_rule
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. By enabling the fs.protected_symlinks kernel parameter, symbolic links are permitted to be followed only when outside a sticky world-writable directory, or when the UID of the link and follower match, or when the directory owner matches the symlink's owner. Disallowing such symlinks helps mitigate vulnerabilities based on insecure file system accessed by privileged programs, avoiding an exploitation vector exploiting unsafe use of open() or creat(). Satisfies: SRG-OS-000312-GPOS-00122, SRG-OS-000324-GPOS-00125
Checks: C-56589r825078_chk

Verify the operating system is configured to enable DAC on symlinks with the following commands: Check the status of the fs.protected_symlinks kernel parameter. $ sudo sysctl fs.protected_symlinks fs.protected_symlinks = 1 If "fs.protected_symlinks" is not set to "1" or is missing, this is a finding. Check that the configuration files are present to enable this kernel parameter. $ sudo grep -r fs.protected_symlinks /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf /etc/sysctl.d/*.conf /etc/sysctl.d/99-sysctl.conf:fs.protected_symlinks = 1 If "fs.protected_symlinks" is not set to "1", is missing or commented out, this is a finding. If conflicting results are returned, this is a finding.

Fix: F-56539r825079_fix

Configure the operating system to enable DAC on symlinks. Add or edit the following line in a system configuration file, in the "/etc/sysctl.d/" directory: fs.protected_symlinks = 1 Load settings from all system configuration files with the following command: $ sudo sysctl --system

b
TOSS must enable kernel parameters to enforce discretionary access control on hardlinks.
AC-3 - Medium - CCI-002165 - V-253137 - SV-253137r958702_rule
RMF Control
AC-3
Severity
M
CCI
CCI-002165
Version
TOSS-04-040960
Vuln IDs
  • V-253137
Rule IDs
  • SV-253137r958702_rule
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. By enabling the fs.protected_hardlinks kernel parameter, users can no longer create soft or hard links to files they do not own. Disallowing such hardlinks mitigate vulnerabilities based on insecure file system accessed by privileged programs, avoiding an exploitation vector exploiting unsafe use of open() or creat(). Satisfies: SRG-OS-000312-GPOS-00122, SRG-OS-000324-GPOS-00125
Checks: C-56590r825081_chk

Verify the operating system is configured to enable DAC on hardlinks with the following commands: Check the status of the fs.protected_hardlinks kernel parameter. $ sudo sysctl fs.protected_hardlinks fs.protected_hardlinks = 1 If "fs.protected_hardlinks" is not set to "1" or is missing, this is a finding. Check that the configuration files are present to enable this kernel parameter. $ sudo grep -r fs.protected_hardlinks /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf /etc/sysctl.d/*.conf /etc/sysctl.d/99-sysctl.conf:fs.protected_hardlinks = 1 If "fs.protected_hardlinks" is not set to "1", is missing or commented out, this is a finding. If conflicting results are returned, this is a finding.

Fix: F-56540r825082_fix

Configure the operating system to enable DAC on hardlinks. Add or edit the following line in a system configuration file, in the "/etc/sysctl.d/" directory: fs.protected_hardlinks = 1 Load settings from all system configuration files with the following command: $ sudo sysctl --system