Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
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.
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.
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.
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
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.
Create a new private and public key pair that utilizes a passcode with the following command: $ sudo ssh-keygen -n [passphrase]
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.
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
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.
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
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.
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.
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.
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
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.
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
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.
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.
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.
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.
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.
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]
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
Start and enable the rsyslog service with the following commands: $ sudo systemctl start rsyslog.service $ sudo systemctl enable rsyslog.service
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.
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
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.
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
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.
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
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.
Configure the "sudo" command to require reauthentication. Edit the /etc/sudoers file: $ sudo visudo Add or modify the following line: Defaults timestamp_timeout=0
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.
Configure TOSS to implement multifactor authentication by installing the required package with the following command: $ sudo yum install openssl-pkcs11
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.
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
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.
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
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.
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
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.
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
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.
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.
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.
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
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.
Remove any found ."shosts" files from the system. $ sudo rm /[path]/[to]/[file]/.shosts
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.
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.
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.
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
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.
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
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.
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.
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
Edit the file "/etc/passwd" and provide each interactive user account that has a duplicate User ID (UID) with a unique UID.
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.
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
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.
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.
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.
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.
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.
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/
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.
Configure the system to disable all wireless network interfaces with the following command: $ sudo nmcli radio all off
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.
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
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.
Remove any occurrence of "!authenticate" found in "/etc/sudoers" file or files in the "/etc/sudoers.d" directory.
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.
Remove any occurrence of "NOPASSWD" found in "/etc/sudoers" file or files in the "/etc/sudoers.d" directory.
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.
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
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>=1000)&&($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.
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
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>=1000)&&($7 !~ /nologin/){print $1, $3, $6}' /etc/passwd If any interactive users do not have a home directory assigned, this is a finding.
Assign home directories to all local interactive users on TOSS that currently do not have a home directory assigned.
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.
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
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.
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
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.
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.
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.
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
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.
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.
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.
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
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>=1000)&&($7 !~ /nologin/){print $6}' /etc/passwd) -maxdepth 0 -not -perm 770 -ls If there is any output, this is a finding.
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
Check that all user home directories are owned by the root user with the following command: $ find $(awk -F: '($3>=1000)&&($7 !~ /nologin/){print $6}' /etc/passwd) -maxdepth 0 -not -user root -ls If there is any output, this is a finding.
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
Check that all user home directories are owned by the user's primary group with the following command: $ awk -F: '($3>=1000)&&($7 !~ /nologin/)&&("stat -c '%g' " $6 | getline dir_group)&&(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.
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
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.
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.
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.
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
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>=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.
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.
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.
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
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.
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."
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.
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."
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.
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."
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.
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
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.
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
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.
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/."
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.
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/."
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.
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.
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.
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
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>=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.
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.
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>=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.
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.
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>=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.
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.
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>=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.
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.
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>=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.
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.
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>=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.
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.
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>=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.
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.
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>=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.
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.
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>=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.
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.
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>=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.
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.
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>=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.
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.
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>=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 If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S rename -F auid>=1000 -F auid!=unset -k delete If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S renameat -F auid>=1000 -F auid!=unset -k delete If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S rmdir -F auid>=1000 -F auid!=unset -k delete If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S unlink -F auid>=1000 -F auid!=unset -k delete If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k delete -a always,exit -F arch=b64 -S unlinkat -F auid>=1000 -F auid!=unset -k delete If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=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 If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=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 If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=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.
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.
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>=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.
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.
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>=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.
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.
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>=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.
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.
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.
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
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>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chmod -F auid>=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.
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.
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>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S chown -F auid>=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.
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.
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>=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 If the command does not return all lines, or the lines are commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchmod -F auid>=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.
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.
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>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchmodat -F auid>=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.
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.
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>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchown -F auid>=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.
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.
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>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S fchownat -F auid>=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.
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.
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>=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 If the command does not return all lines, or the lines are commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k perm_mod -a always,exit -F arch=b64 -S lchown -F auid>=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.
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.
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>=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 If the command does not return all lines, or the lines are commented out, this is a finding.
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.
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>=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 If the command does not return all lines, or the lines are commented out, this is a finding.
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.
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>=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 If the command does not return all lines, or the lines are commented out, this is a finding.
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.
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>=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 If the command does not return all lines, or the lines are commented out, this is a finding.
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.
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.
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".
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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]
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.
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.
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>=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 If the command does not return all lines, or the lines are commented out, this is a finding.
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.
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>=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 If the command does not return all lines, or the lines are commented out, this is a finding.
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.
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>=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 If the command does not return all lines, or the lines are commented out, this is a finding.
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.
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>=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 If the command does not return all lines, or the lines are commented out, this is a finding.
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.
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>=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 If the command does not return all lines, or the lines are commented out, this is a finding.
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.
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.
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.
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>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k privileged -a always,exit -F arch=b64 -S mount -F auid>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k privileged If the command does not return a line, or the line is commented out, this is a finding.
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.
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>=1000 -F auid!=unset -k modules If the command does not return a line, or the line is commented out, this is a finding.
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.
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.
Start the auditd service and enable the auditd service with the following commands: $ sudo systemctl start auditd.service $ sudo systemctl enable auditd.service
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.
Configure TOSS to audit local events on the system. Add or update the following line in "/etc/audit/auditd.conf" file: local_events = yes
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.
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.
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.
Configure the operating system to offload audit logs by installing the required packages with the following command: $ sudo yum install rsyslog
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.
Configure the operating system to encrypt offloaded audit logs by installing the required packages with the following command: $ sudo yum install rsyslog-gnutls
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.
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
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.
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
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.
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
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.
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.
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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*
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.
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
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.
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
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.
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.
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.
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
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.
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