What changed in Red Hat Enterprise Linux 8 SCAP Benchmark V2R9V2R9 changes

Check text

AND - The RHEL 8 minor version is supported. textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: pattern pattern match "^\\s*PRETTY_NAME=\"Red Hat Enterprise Linux 8\\.(\\d+)\\b"; path equals "/etc"; filename equals "os-release"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "8" state textfilecontent54_state: subexpression equals "10" Verify the version of the operating system is vendor supported. Note: The lifecycle time spans and dates are subject to adjustment. Check the version of the operating system with the following command: $ sudo cat /etc/redhat-release Red Hat Enterprise Linux Server release 8.6 (Ootpa) Current End of Extended Update Support for RHEL 8.1 is 30 November 2021. Current End of Extended Update Support for RHEL 8.2 is 30 April 2022. Current End of Extended Update Support for RHEL 8.4 is 31 May 2023. Current End of Maintenance Support for RHEL 8.5 is 31 May 2022. Current End of Extended Update Support for RHEL 8.6 is 31 May 2024. Current End of Maintenance Support for RHEL 8.7 is 31 May 2023. Current End of Extended Update Support for RHEL 8.8 is 31 May 2025. Current End of Maintenance Support for RHEL 8.9 is 31 May 2024. Current End of Maintenance Support for RHEL 8.10 is 31 May 2029. If the release is not supported by the vendor, this is a finding.

Discussion

An operating system release is considered "supported" if the vendor continues to provide security patches for the product. With an unsupported release, it will not be possible to resolve security issues discovered in the system software. Red Hat offers the Extended Update Support (EUS) add-on to a Red Hat Enterprise Linux subscription, for a fee, for those customers who wish to standardize on a specific minor release for an extended period. The RHEL 8 minor releases eligible for EUS are 8.1, 8.2, 8.4, 8.6, and 8.8. Each RHEL 8 EUS stream is available for 24 months from the availability of the minor release. RHEL 8.10 will be the final minor release overall. For more details on the Red Hat Enterprise Linux Life Cycle visit https://access.redhat.com/support/policy/updates/errata/. Note: The life-cycle time spans and dates are subject to adjustment. The version is still supported but has been superseded and must be removed from the enclave network or upgraded to a supported version. Red Hat Enterprise Linux 8 General Availability: May 7, 2019 Full Support: May 7, 2019 to May 31, 2024 Maintenance Support: Jun 1, 2024 to May 31, 2029 Extended Life Cycle (ELC): Jun 1, 2029 to May 31, 2033 Long-Life Add-On: Jun 1, 2033 to Ongoing Final Minor Release: 8.10

V-230221 in V2R9

Check text

AND - /etc/rsyslog.conf: auth.* is configured to be logged textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: - /etc/rsyslog.conf: authpriv.* is configured to be logged textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: - /etc/rsyslog.conf: daemon.* is configured to be logged textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: Verify that RHEL 8 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 /etc/rsyslog.d/*.conf /etc/rsyslog.d/*.conf auth.*;authpriv.*;daemon.* /var/log/secure If "auth.*", "authpriv.*" or "daemon.*" are not configured to be logged, this is a finding.

Discussion

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

V-230228 in V2R9

Check text

AND - /etc/login.defs:ENCRYPT_METHOD >= SHA512 textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: filepath equals "/etc/login.defs"; pattern pattern match "^\\s*ENCRYPT_METHOD\\s+([^#\\r\\n]*)"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "SHA512" Verify that the 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.

Discussion

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and DoDDoW data may be compromised. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoDDoW requirements.

V-230231 in V2R9

Check text

AND - /bootetc/efi/EFI/redhat/grubgrub2.cfg:superusers exists and has a name. textfilecontent54_test (check: all, existence: all_exist) object textfilecontent54_object: filepath equals "/bootetc/grub2-efi/EFI/redhat/grub.cfg"; pattern pattern match "^\\s*set\\s+superusers\\s*=\\s*\"(\\w+)\"\\s*$"; instance greater than or equal "1" state textfilecontent54_state: subexpression pattern match "^\\S+$" OR - /boot/efigrub2/EFI/redhat/user.cfg:GRUB2_PASSWORD exists and has a PBKDF2/SHA512 password assigned. textfilecontent54_test (check: all, existence: all_exist) object textfilecontent54_object: filepath equals "/boot/efigrub2/EFI/redhat/user.cfg"; pattern pattern match "^\\s*GRUB2_PASSWORD=(\\S+)\\b"; instance greater than or equal "1" state textfilecontent54_state: subexpression pattern match "^grub\\.pbkdf2\\.sha512\\." For - systems that use BIOS, this is Not Applicable/boot/efi/EFI/redhat/user. Checkcfg:GRUB2_PASSWORD toexists seeand ifhas ana encryptedPBKDF2/SHA512 grub superusers password is setassigned. textfilecontent54_test On(check: systems that use UEFIall, useexistence: theall_exist) object following commandtextfilecontent54_object: $ sudofilepath grepequals -iw grub2_password "/boot/efi/EFI/redhat/user.cfg "; pattern pattern match "^\\s*GRUB2_PASSWORD=grub.pbkdf2.sha512.[password_hash] If(\\S+)\\b"; theinstance grubgreater superusersthan passwordor doesequal not"1" state begintextfilecontent54_state: withsubexpression pattern match "^grub\\.pbkdf2\\.sha512", this is a finding\\."

Fix text

Configure the system to require a grubGRUB bootloader password for the grub superusers account. Use with the "grub2-setpassword" command, which automatically creates/overwrites and sets the correct permissions for the unified "/boot/efigrub2/EFI/redhat/user.cfg" file. Generate anusing encryptedthe grub2required passwordPBKDF2 forSHA512 hashing algorithm. Generate the grubencrypted superusersGRUB account2 password with the following command: $# sudo grub2-setpassword Enter password: Confirm password: Note: Do not manually edit the GRUB configuration files to set this password; always use the provided utility to ensure the correct hashing algorithm is applied and the file is placed in the active configuration directory.

V-230234 in V2R9

Check text

AND - /etc/pam.d/password-auth:password includes pam_unix.so sha512 textfilecontent54_test (check: all, existence: only_one_exists) object textfilecontent54_object: pattern pattern match "^[ \\t]*password[ \\t]+sufficient[ \\t]+pam_unix\\.so(?:[ \\t]+|(?:[ \\t][^#\\r\\f\\n]+[ \\t]))sha512(?:[ \\t]|$)"; path equals "/etc/pam.d"; filename equals "password-auth"; instance greater than or equal "1" 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.

Discussion

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore, cannot be relied upon to provide confidentiality or integrity, and DoDDoW data may be compromised. RHEL 8 systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoDDoW requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.

V-230237 in V2R9

Check text

AND - /etc/*.keytab does not exist. file_test (check: all, existence: none_exist) object file_object: path equals "/etc"; filename pattern match "\\.keytab$" Verify that RHEL 8 prevents system daemons from using Kerberos for authentication. If the system is a server utilizing krb5-server-1.17-18.el8.x86_64 or newer, this requirement is not applicable. If the system is a workstation utilizing krb5-workstation-1.17-18.el8.x86_64 or newer, this requirement is not applicable. Check if there are available keytabs with the following command: $ sudo ls -al /etc/*.keytab If this command produces any file(s), this is a finding.

Discussion

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore, cannot be relied upon to provide confidentiality or integrity, and DoDDoW data may be compromised. RHEL 8 systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. The key derivation function (KDF) in Kerberos is not FIPS compatible. Ensuring the system does not have any keytab files present prevents system daemons from using Kerberos for authentication. A keytab is a file containing pairs of Kerberos principals and encrypted keys. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoDDoW requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.

V-230238 in V2R9

Check text

AND - package krb5-workstation is not installed rpminfo_test (check: all, existence: none_exist) object rpminfo_object: name equals "krb5-workstation" Verify the krb5-workstation package has not been installed on the system with the following commands: If the system is a server or is utilizing krb5-workstation-1.17-18.el8.x86_64 or newer, this is Not Applicable. $ sudo yum list installed krb5-workstation krb5-workstation.x86_64 1.17-9.el8 repository If the krb5-workstation package is installed and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Discussion

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore, cannot be relied upon to provide confidentiality or integrity, and DoDDoW data may be compromised. RHEL 8 systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. Currently, Kerberos does not utilize FIPS 140-2 cryptography. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoDDoW requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.

V-230239 in V2R9

Check text

AND - Every /etc/yum.repos.d/*.repo:[{reponame}] has a gpgcheck entry set to 1. textfilecontent54_test (check: all, existence: all_exist) object textfilecontent54_object: pattern pattern match "^\\s*\\[[^]]+\\]\\s*\\n(?:[^[]*\\n)*"; path equals "/etc/yum.repos.d"; filename pattern match "\\.repo$"; instance greater than or equal "1" state textfilecontent54_state: text pattern match "\\n\\s*gpgcheck\\s*=\\s*(True|1|yes)\\s*(\\n|$)" - No /etc/yum.repos.d/*.repo:[{reponame}] has a gpgcheck entry set to 0. textfilecontent54_test (check: none satisfy, existence: all_exist) object textfilecontent54_object: pattern pattern match "^\\s*\\[[^]]+\\]\\s*\\n(?:[^[]*\\n)*"; path equals "/etc/yum.repos.d"; filename pattern match "\\.repo$"; instance greater than or equal "1" state textfilecontent54_state: text pattern match "\\n\\s*gpgcheck\\s*=\\s*(False|0|no)\\s*(\\n|$)" Verify the operating system prevents the installation of patches, service packs, device drivers, or operating system components from a repository without verification that 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 grep -E '^\[.*\]|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.

Discussion

Changes to any software components can have significant effects on the overall security of the operating system. This requirement ensures the software has not been tampered with and that it has been provided by a trusted vendor. Accordingly, patches, service packs, device drivers, or operating system components must be signed with a certificate recognized and approved by the organization. Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This verifies the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. The operating system should not have to verify the software again. This requirement does not mandate DoDDoW certificates for this purpose; however, the certificate used to verify the software must be from an approved CA.

V-230264 in V2R9

Check text

AND - /etc/dnf/dnf.conf: localpkg_gpgcheck is set to True, 1, or yes. textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: filepath equals "/etc/dnf/dnf.conf"; pattern pattern match "^\\s*localpkg_gpgcheck\\s*=\\s*(\\w+)\\b\\s*$"; instance greater than or equal "1" state textfilecontent54_state: subexpression pattern match "^(True|1|yes)$" Verify the operating system prevents the installation of patches, service packs, device drivers, or operating system components from a repository without verification that they have been digitally signed using a certificate that is recognized and approved by the organization. Determine if YUM is configured to perform a signature check on local packages with the following command: $ sudo grep -i localpkg_gpgcheck /etc/dnf/dnf.conf localpkg_gpgcheck=1 If "localpkg_gpgcheck" is not set to "1", "True", or "yes", is commented out, or is missing from "/etc/dnf/dnf.conf", this is a finding.

Discussion

Changes to any software components can have significant effects on the overall security of the operating system. This requirement ensures the software has not been tampered with and that it has been provided by a trusted vendor. Accordingly, patches, service packs, device drivers, or operating system components must be signed with a certificate recognized and approved by the organization. Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This verifies the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. The operating system should not have to verify the software again. This requirement does not mandate DODDoW certificates for this purpose; however, the certificate used to verify the software must be from an approved CA.

V-230265 in V2R9

Check text

AND - kernel.dmesg_restrict setting in kernel is 1 sysctl_test (check: all, existence: all_exist) object sysctl_object: name equals "kernel.dmesg_restrict" state sysctl_state: value equals "1" Verify RHEL 8 is configured to restrict access to the kernel message buffer. Check the status of the "kernel.dmesg_restrict" kernel parameter with the following command: $ sudo sysctl kernel.dmesg_restrict kernel.dmesg_restrict = 1 If "kernel.dmesg_restrict" is not set to "1" or is missing, this is a finding.

Discussion

Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DoDDoW or other government agencies. There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components. Restricting access to the kernel message buffer limits access to only root. This prevents attackers from gaining additional system information as a non-privilegednonprivileged user. The sysctl --system command will load settings from all system configuration files. All configuration files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same option, the entry in the file with the lexicographically latest name will take precedence. Files are read from directories in the following list from top to bottom. Once a file of a given filename is loaded, any file of the same name in subsequent directories is ignored. /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf

V-230269 in V2R9

Check text

AND - kernel.perf_event_paranoid setting in kernel is 2 sysctl_test (check: all, existence: all_exist) object sysctl_object: name equals "kernel.perf_event_paranoid" state sysctl_state: value equals "2" Verify RHEL 8 is configured to prevent kernel profiling by nonprivileged users. Check the status of the "kernel.perf_event_paranoid" kernel parameter. $ sudo sysctl kernel.perf_event_paranoid kernel.perf_event_paranoid = 2 If "kernel.perf_event_paranoid" is not set to "2" or is missing, this is a finding.

Discussion

Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DoDDoW or other government agencies. There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components. Setting the kernel.perf_event_paranoid kernel parameter to "2" prevents attackers from gaining additional system information as a non-privilegednonprivileged user. The sysctl --system command will load settings from all system configuration files. All configuration files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same option, the entry in the file with the lexicographically latest name will take precedence. Files are read from directories in the following list from top to bottom. Once a file of a given filename is loaded, any file of the same name in subsequent directories is ignored. /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf

V-230270 in V2R9

Check text

AND - package openssl-pkcs11 is installed rpminfo_test (check: all, existence: all_exist) object rpminfo_object: name equals "openssl-pkcs11" Verify the operating system has the packages required for multifactor authentication installed with the following commands: $ sudo yum list installed openssl-pkcs11 openssl-pkcs11.x86_64 0.4.8-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.

Discussion

Using an authentication device, such as a DoDDoW Commoncommon Accessaccess Cardcard (CAC) or token that is separate from the information system, ensures that even if the information system is compromised, credentials stored on the authentication device will not be affected. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification (PIV) card and the DoDDoW CAC. A privileged account is defined as an information system account with authorizations of a privileged user. Remote access is access to DoDDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, nonnonorganization-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management).

V-230273 in V2R9

Check text

AND - rsyslog is enabled systemdunitproperty_test (check: all, existence: at_least_one_exists) object systemdunitproperty_object: property equals "UnitFileState"; unit equals "rsyslog.service" state systemdunitproperty_state: value equals "enabled" - rsyslog is active systemdunitproperty_test (check: all, existence: at_least_one_exists) object systemdunitproperty_object: property equals "ActiveState"; unit equals "rsyslog.service" state systemdunitproperty_state: value equals "active" 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.

Discussion

Configuring RHEL 8 to implement organization-wideorganizationwide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across the DoDDoW that reflects the most restrictive security posture consistent with operational requirements. Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture and/or functionality of the system. Security-related parameters are those parameters impacting the security state of the system, including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: registry settings; account, file, directory permission settings; and settings for functions, ports, protocols, services, and remote connections.

V-230298 in V2R9

Title

RHEL 8 user account passwords must have a 6180-day maximum password lifetime restriction.

Check text

AND - 0 -lt /etc/loginoval:mil.defsdisa.stig.ind:PASS_MAX_DAYS -le 60tst:25804100 textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: filepath equals "/etc/login.defs"; pattern pattern match "^[ \\st]*PASS_MAX_DAYS[ \\st]+(\\d*+)[ \\t]*$"; instance greater than or equal "1" state textfilecontent54_state: subexpression lessgreater than or equal "600" state textfilecontent54_state: subexpression greaterless than "0" Verifyor thatequal RHEL 8 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_DAYS180" parameter value is greater than "60", or commented out, this is a finding.

Fix text

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

V-230366 in V2R9

Title

RHEL 8 user account passwords must be configured so that existing passwords are restricted to a 6180-day maximum lifetime.

Check text

AND - No password in /etc/shadow has a maximum password age of 0 or greater than 60180 shadow_test (check: all, existence: any_exist) object shadow_object: filter equals "oval:mil.disa.stig.unix:ste:23036702"; username pattern match ".+" state shadow_state: chg_req greater than "0" state shadow_state: chg_req less than or equal "60180" - Root password in /etc/shadow does not have a maximum password age of 0 or greater than 60180 shadow_test (check: all, existence: all_exist) object shadow_object: username equals "root" state shadow_state: chg_req greater than "0" state shadow_state: chg_req less than or equal "60180" Check whether the maximum time period for existing passwords is restricted to 60 days with the following commands: $ sudo awk -F: '$5 > 60 {print $1 " " $5}' /etc/shadow $ sudo awk -F: '$5 <= 0 {print $1 " " $5}' /etc/shadow If any results are returned that are not associated with a system account, this is a finding.

Fix text

Configure non-compliant accounts to enforce a 6180-day maximum password lifetime restriction. $ sudo chage -M 6180 [user]

V-230367 in V2R9

Check text

AND - passwords must have a minimum of 15 characters textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: state textfilecontent54_state: subexpression greater than or equal "15" Verify the operating system 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 with the following command: $ sudo grep -r minlen /etc/security/pwquality.conf* /etc/security/pwquality.conf:minlen = 15 If the command does not return a "minlen" value of 15 or greater, this is a finding. If conflicting results are returned, this is a finding.

Discussion

The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to increase exponentially the time and/or resources required to compromise the password. RHEL 8 utilizes "pwquality" as a mechanism to enforce password complexity. Configurations are set in the "etc/security/pwquality.conf" file. The "minlen", sometimes noted as minimum length, acts as a "score" of complexity based on the credit components of the "pwquality" module. By setting the credit components to a negative value, not only will those components be required, they will not count towards the total "score" of "minlen". This will enable "minlen" to require a 15-character minimum. The DoDDoW minimum password requirement is 15 characters.

V-230369 in V2R9

Check text

AND - /etc/login.defs: PASS_MIN_LEN = 15 or greater textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: filepath equals "/etc/login.defs"; pattern pattern match "^\\s*PASS_MIN_LEN\\s+(\\d+)\\s*$"; instance greater than or equal "1" state textfilecontent54_state: subexpression greater than or equal "15" Verify that RHEL 8 enforces a minimum 15-character password length for new user accounts by running the following command: $ sudo grep -i pass_min_len /etc/login.defs PASS_MIN_LEN 15 If the "PASS_MIN_LEN" parameter value is less than "15", or commented out, this is a finding.

Discussion

The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to increase exponentially the time and/or resources required to compromise the password. The DoDDoW minimum password requirement is 15 characters.

V-230370 in V2R9

Check text

AND - /etc/default/useradd: INACTIVE is set to 35 or less, but not -1 textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: filepath equals "/etc/default/useradd"; pattern pattern match "(?i)^\\s*INACTIVE\\s*=\\s*(-?\\d+)\\s*$"; instance greater than or equal "1" state textfilecontent54_state: subexpression greater than or equal "0" state textfilecontent54_state: subexpression less than or equal "35" Verify the account identifiers (individuals, groups, roles, and devices) are disabled after 35 days of inactivity with the following command: Check the account inactivity value by performing the following command: $ sudo grep -i inactive /etc/default/useradd INACTIVE=35 If "INACTIVE" is set to "-1", a value greater than "35", or is commented out, this is a finding.

Fix text

Configure RHEL 8 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 DoDDoW 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.

V-230373 in V2R9

Check text

AND - /etc/login.defs: FAIL_DELAY = 4 or greater textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: filepath equals "/etc/login.defs"; pattern pattern match "^\\s*FAIL_DELAY\\s+(\\d+)\\s*$"; instance greater than or equal "1" state textfilecontent54_state: subexpression greater than or equal "4" Verify the operating system enforces a delay of at least four seconds between console logon prompts following a failed logon attempt with the following command: $ sudo grep -i fail_delay /etc/login.defs FAIL_DELAY 4 If the value of "FAIL_DELAY" is not set to "4" or greater, or the line is commented out, this is a finding.

Discussion

Configuring the operating system to implement organization-wide security implementation guides and security checklists verifies compliance with federal standards and establishes a common security baseline across the DoDDoW that reflects the most restrictive security posture consistent with operational requirements. Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture and/or functionality of the system. Security-related parameters are those parameters impacting the security state of the system, including the parameters required to satisfy other security control requirements. Security-related parameters include, for example, registry settings; account, file, and directory permission settings; and settings for functions, ports, protocols, services, and remote connections.

V-230378 in V2R9

Check text

AND - Audit invocations of /usr/bin/kmod textfilecontent54_test (check: all, existence: all_exist) object textfilecontent54_object: filepath equals "/etc/audit/audit.rules"; pattern pattern match "^\\s*-a\\s+(always,exit|exit,always)(?:\\s+-S\\s+all)?\\s+-F\\s+path=/usr/bin/kmod\\s+(-F\\s+perm=([rwa]*x[rwa]*)\\s+)?-F\\s+auid>=1000\\s+-F\\s+auid!=(4294967295|-1|unset)(\\s+(-k\\s+|-F\\s+key=)\\S+)?\\s*$"; instance greater than or equal "1" Verify if RHEL 8 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.

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The "kmod" command is used to control Linux Kernel modules. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DoDDoW has defined the list of events for which RHEL 8 will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions. Satisfies: SRG-OS-000062-GPOS-00031, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222

V-230465 in V2R9

Check text

AND - Audit modifications to /var/log/lastlog textfilecontent54_test (check: all, existence: all_exist) object textfilecontent54_object: filepath equals "/etc/audit/audit.rules"; pattern pattern match "^\\s*-w\\s+/var/log/lastlog(\\s+-p\\s*([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*))?(\\s+(-k\\s+|-F\\s+key=)\\w+)?\\s*$"; instance greater than or equal "1" Verify RHEL 8 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.

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one. Audit records can be generated from various components within the information system (e.g., module or policy filter). The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. DoDDoW has defined the list of events for which RHEL 8 will provide an audit record generation capability as the following: 1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); 2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; 3) All account creations, modifications, disabling, and terminations; and 4) All kernel module load, unload, and restart actions. Satisfies: SRG-OS-000062-GPOS-00031, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000473-GPOS-00218

V-230467 in V2R9

Check text

AND - /etc/audit/auditd.conf has mode 0600 or less permissive file_test (check: all, existence: ) object file_object: filepath equals "/etc/audit/auditd.conf" state file_state: gexec equals "false"; oread equals "false"; uexec equals "false"; sticky equals "false"; sgid equals "false"; suid equals "false"; oexec equals "false"; owrite equals "false"; gread equals "false"; gwrite equals "false" - .rules files in /etc/audit/rules.d have mode 0600 or less permissive file_test (check: all, existence: ) object file_object: path equals "/etc/audit/rules.d"; filename pattern match ".rules$" state file_state: gexec equals "false"; oread equals "false"; uexec equals "false"; sticky equals "false"; sgid equals "false"; suid equals "false"; oexec equals "false"; owrite equals "false"; gread equals "false"; gwrite equals "false" - /etc/audit/audit.rules has mode 0600 or less permissive file_test (check: all, existence: ) object file_object: filepath equals "/etc/audit/audit.rules" state file_state: gexec equals "false"; oread equals "false"; uexec equals "false"; sticky equals "false"; sgid equals "false"; suid equals "false"; oexec equals "false"; owrite equals "false"; gread equals "false"; gwrite equals "false" Verify that the files in directory "/etc/audit/rules.d/" and "/etc/audit/auditd.conf" file have a mode of "0600" or less permissive by using the following commands: $ sudo find /etc/audit/rules.d/ -type f -name *.rules -exec ls -al {} \; -rw-------. 1 root root 284 May 1 20:30 /etc/audit/rules.d/audit.rules $ sudo ls -l /etc/audit/auditd.conf -rw------- 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 "0600", this is a finding.

Fix text

Configure the rules files in the directory "/etc/audit/rules.d/", the /etc/audit/audit.rules file, and the "/etc/audit/auditd.conf" file to have a mode of "0600" with the following commands: $ sudo chmodfind 0600 /etc/audit/rules.d/audit -type f -name "*.rules" -exec chmod 0600 {} + $ sudo chmod 0600 /etc/audit/rulesaudit.d/[customrulesfile].rules $ sudo chmod 0600 /etc/audit/auditd.conf

V-230471 in V2R9

Check text

AND - oval:mil.disa.stig.ind:tst:23048500 textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: filepath equals "/etc/chrony.conf"; pattern pattern match "^[ \\t]*port[ \\t]+(\\d+)[ \\t]*$"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "0" Note: If the system is approved and documented by the information system security officer (ISSO) to function as an NTP time server, this requirement is Not Applicable. Verify RHEL 8 disables the chrony daemon from acting as a server with the following command: $ sudo grep -w 'port' /etc/chrony.conf port 0 If the "port" option is not set to "0", is commented out or missing, this is a finding.

Discussion

Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. Minimizing the exposure of the server functionality of the chrony daemon diminishes the attack surface. RHEL 8 utilizes the "timedatectl" command to view the status of the "systemd-timesyncd.service". The "timedatectl" status will display the local time, Coordinated Universal Time (UTC), and the offset from UTC. Note that USNO offers authenticated NTP service to DODDoW and U.S. Government agencies operating on the NIPR and SIPR networks. Visit https://www.usno.navy.mil/USNO/time/ntp/DODDoW-customers for more information.

V-230485 in V2R9

Check text

AND - /etc/chrony.conf: cmdport option is set to 0 textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: filepath equals "/etc/chrony.conf"; pattern pattern match "^[ \\t]*cmdport[ \\t]+0[ \\t]*$"; instance greater than or equal "1" Note: If the system is approved and documented by the information system security officer (ISSO) to function as an NTP time server, this requirement is Not Applicable. Verify RHEL 8 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.

Discussion

Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. Not exposing the management interface of the chrony daemon on the network diminishes the attack space. RHEL 8 utilizes the "timedatectl" command to view the status of the "systemd-timesyncd.service". The "timedatectl" status will display the local time, Coordinated Universal Time (UTC), and the offset from UTC. Note that USNO offers authenticated NTP service to DODDoW and U.S. Government agencies operating on the NIPR and SIPR networks. Visit https://www.usno.navy.mil/USNO/time/ntp/DODDoW-customers for more information.

V-230486 in V2R9

Check text

AND - oval:mil.disa.stig.linux:tst:23050500 rpminfo_test (check: all, existence: ) object rpminfo_object: name equals "firewalld" Verify that "firewalld" is installed with the following commands: $ sudo yum list installed firewalld firewalld.noarch 0.7.0-5.el8 If the "firewalld" package is not installed, ask the System Administrator if another firewall is installed. If no firewall is installed this is a finding.

Discussion

"Firewalld" provides an easy and effective way to block/limit remote access to the system via ports, services, and protocols. Remote access services, such as those providing remote access to network devices and information systems, which lack automated control capabilities, increase risk and make remote user access management difficult at best. Remote access is access to DoDDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, nonnonorganization-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. RHEL 8 functionality (e.g., RDP) must be capable of taking enforcement action if the audit reveals unauthorized activity. Automated control of remote access sessions allows organizations to ensure ongoing compliance with remote access policies by enforcing connection rules of remote access applications on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).

V-230505 in V2R9

Check text

AND - /etc/modprobe.d contains a file that contains 'install bluetooth /bin/false' textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: pattern pattern match "^[ \\t]*install[ \\t]+bluetooth[ \\t]+/bin/false[ \\t]*$"; path equals "/etc/modprobe.d"; filename pattern match ".*"; instance greater than or equal "1" - /etc/modprobe.d contains a file that contains 'blacklist bluetooth' textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: pattern pattern match "^[ \\t]*blacklist[ \\t]+bluetooth[ \\t]*$"; path equals "/etc/modprobe.d"; filename pattern match ".*"; instance greater than or equal "1" If the device or operating system does not have a Bluetooth adapter installed, this requirement is not applicable. This requirement is not applicable to mobile devices (smartphones and tablets), where the use of Bluetooth is a local AO decision. Determine if Bluetooth is disabled with the following command: $ sudo grep bluetooth /etc/modprobe.d/* /etc/modprobe.d/bluetooth.conf:install bluetooth /bin/false If the Bluetooth driver blacklist entry is missing, a Bluetooth driver is determined to be in use, and the collaborative computing device has not been authorized for use, this is a finding. Verify the operating system disables the ability to use Bluetooth with the following command: $ sudo grep -r bluetooth /etc/modprobe.d | grep -i "blacklist" | grep -v "^#" blacklist bluetooth If the command does not return any output or the output is not "blacklist bluetooth", and use of Bluetooth is not documented with the ISSO as an operational requirement, this is a finding.

Discussion

Without protection of communications with wireless peripherals, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read, altered, or used to compromise the RHEL 8 operating system. This requirement applies to wireless peripheral technologies (e.g., wireless mice, keyboards, displays, etc.) used with RHEL 8 systems. Wireless peripherals (e.g., Wi-Fi/Bluetooth/IR Keyboards, Mice, and Pointing Devices and Near Field Communications [NFC]) present a unique challenge by creating an open, unsecured port on a computer. Wireless peripherals must meet DoDDoW requirements for wireless data transmission and be approved for use by the Authorizingauthorizing Officialofficial (AO). Even though some wireless peripherals, such as mice and pointing devices, do not ordinarily carry information that need to be protected, modification of communications with these wireless peripherals may be used to compromise the RHEL 8 operating system. Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of communications with wireless peripherals can be accomplished by physical means (e.g., employing physical barriers to wireless radio frequencies) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. If the wireless peripheral is only passing telemetry data, encryption of the data may not be required.

V-230507 in V2R9

Check text

AND - /etc/systemd/system.conf:CtrlAltDelBurstAction is set to none. textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: state textfilecontent54_state: subexpression equals "none" Verify RHEL 8 is configured to not reboot the system when Ctrl-Alt-Delete is pressed seven times within two seconds with the following command: $ sudo grep -iR CtrlAltDelBurstAction /etc/systemd/system* /etc/systemd/system.conf.d/55-CtrlAltDel-BurstAction.conf:CtrlAltDelBurstAction=none If the "CtrlAltDelBurstAction" is not set to "none", is commented out, or is missing, this is a finding.

Fix text

Configure RHEL 8 to disable the CtrlAltDelBurstAction by adding it to a drop file in a "/etc/systemd/system.conf.d/" configuration file: If no drop file exists, create one with the following command: $ sudo mkdir -p /etc/systemd/system.conf.d && sudo vi /etc/systemd/system.conf.d/55-CtrlAltDel-BurstAction.conf Edit the file to contain the setting by adding the following text: [Manager] CtrlAltDelBurstAction=none Reload the daemon for this change to take effect. $ sudo systemctl daemon-reload

V-230531 in V2R9

Check text

AND - package krb5-workstation is not installed rpminfo_test (check: all, existence: none_exist) object rpminfo_object: name equals "krb5-server" Verify the krb5-server package has not been installed on the system with the following commands: If the system is a workstation or is utilizing krb5-server-1.17-18.el8.x86_64 or newer, this is Not Applicable $ sudo yum list installed krb5-server krb5-server.x86_64 1.17-9.el8 repository If the krb5-server package is installed and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Discussion

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore, cannot be relied upon to provide confidentiality or integrity, and DoDDoW data may be compromised. RHEL 8 systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. Currently, Kerberos does not utilize FIPS 140-2 cryptography. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoDDoW requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.

V-237640 in V2R9

Check text

AND - Defaults timestamp_timeout is configured to a positive number in /etc/sudoers or /etc/sudoers.d. textfilecontent54_test (check: all, existence: only_one_exists) object textfilecontent54_object: state textfilecontent54_state: subexpression equals "0" Verify the operating system requires re-authentication when using the "sudo" command to elevate privileges. $ sudo grep -ir 'timestamp_timeout' /etc/sudoers /etc/sudoers.d /etc/sudoers:Defaults timestamp_timeout=0 If conflicting results are returned, this is a finding. If "timestamp_timeout" is set to a negative number, is commented out, or no results are returned, this is a finding.

Fix text

Configure the "sudo"OS command to requirereauthenticate re-authentication. Editevery theinvocation /etc/sudoersof file: $the "sudo" visudocommand. Add or modify the following line: Defaults timestamp_timeout=[value] Note:to The "[value]/etc/sudoers" mustor be a numberfile thatin is greater than or equal to "0"/etc/sudoers.d": Defaults timestamp_timeout=0 Remove any duplicate or conflicting lines from /etc/sudoers and /etc/sudoersdefinitions.d/ files.

V-237643 in V2R9

Check text

AND - /etc/pam.d/system-auth:password includes pam_unix.so sha512 textfilecontent54_test (check: all, existence: only_one_exists) object textfilecontent54_object: pattern pattern match "^[ \\t]*password[ \\t]+sufficient[ \\t]+pam_unix\\.so(?:[ \\t]+|(?:[ \\t][^#\\r\\f\\n]+[ \\t]))sha512(?:[ \\t]|$)"; path equals "/etc/pam.d"; filename equals "system-auth"; instance greater than or equal "1" Verify that pam_unix.so module is configured to use sha512. Check that 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.

Discussion

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore, cannot be relied upon to provide confidentiality or integrity, and DoDDoW data may be compromised. RHEL 8 systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoDDoW requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system.

V-244524 in V2R9

Check text

AND - The firewall daemon is active systemdunitproperty_test (check: all, existence: at_least_one_exists) object systemdunitproperty_object: property equals "ActiveState"; unit equals "firewalld.service" state systemdunitproperty_state: value equals "active" Verify that "firewalld" is active with the following commands: $ sudo systemctl is-active firewalld active If the "firewalld" package is not "active", ask the System Administrator if another firewall is installed. If no firewall is installed and active this is a finding.

Discussion

"Firewalld" provides an easy and effective way to block/limit remote access to the system via ports, services, and protocols. Remote access services, such as those providing remote access to network devices and information systems, which lack automated control capabilities, increase risk and make remote user access management difficult at best. Remote access is access to DoDDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, nonnonorganization-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. RHEL 8 functionality (e.g., RDP) must be capable of taking enforcement action if the audit reveals unauthorized activity. Automated control of remote access sessions allows organizations to ensure ongoing compliance with remote access policies by enforcing connection rules of remote access applications on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).

V-244544 in V2R9

Check text

AND - system-auth pam_pwquality textfilecontent54_test (check: at least one, existence: at_least_one_exists) object textfilecontent54_object: pattern pattern match "^\\s*password\\s+(?:required|requisite)\\s+(.*)$"; instance greater than or equal "1"; filepath equals "/etc/pam.d/system-auth"; behaviors equals "" state textfilecontent54_state: subexpression pattern match "^pam_pwquality.so(\\s|$)" Verify the operating system uses "pwquality" to enforce the password complexity rules. Check for the use of "pwquality" in the system-auth file with the following command: $ sudo cat /etc/pam.d/system-auth | grep pam_pwquality password requisite pam_pwquality.so If the command does not return a line containing the value "pam_pwquality.so" as shown, or the line is commented out, this is a finding.

Fix text

Configure the operating system to use "pwquality" to enforce password complexity rules. Add the following line to the "/etc/pam.d/system-auth" file (or modify the line to have the required value): password requisiterequired pam_pwquality.so

V-251713 in V2R9

Title

RHEL 8 must implement DODoW-approved encryption in the bind package.

Check text

AND - named.conf includes crypto-policy textfilecontent54_test (check: at least one, existence: at_least_one_exists) object textfilecontent54_object: filepath equals "/etc/named.conf"; pattern pattern match "^\\s*include\\s+\"(.*)\"\\s*;\\s*$"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "/etc/crypto-policies/back-ends/bind.config" Note: If the "bind" package is not installed, this requirement is Not Applicable. Verify BIND uses the system crypto policy with the following command: $ sudo grep include /etc/named.conf include "/etc/crypto-policies/back-ends/bind.config";' If BIND is installed and the BIND config file does not contain the include "/etc/crypto-policies/back-ends/bind.config" directive, or the line is commented out, this is a finding.

V-279931 in V2R9

Check text

AND - net.ipv4.conf.all.log_martians setting in kernel set to 1 sysctl_test (check: all, existence: all_exist) object sysctl_object: name equals "net.ipv4.conf.all.log_martians" state sysctl_state: value equals "1" Verify RHEL 8 logs IPv4 martian packets. Check the value of the "log_martians" variable with the following command: $ sudo sysctl net.ipv4.conf.all.log_martians net.ipv4.conf.all.log_martians = 1 If "net.ipv4.conf.all.log_martians" is not set to "1" or is missing, this is a finding.

Discussion

The presence of "martian" packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. Logging these packets enables this activity to be detected. Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DODDoW or other government agencies. There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components. Restricting access to the kernel message buffer limits access to only root. This prevents attackers from gaining additional system information as a nonprivileged user. The sysctl --system command will load settings from all system configuration files. All configuration files are sorted by their filename in lexicographical order, regardless of the directories in which they reside. If multiple files specify the same option, the entry in the file with the lexicographically latest name will take precedence. Files are read from directories in the following list from top to bottom. Once a file of a given filename is loaded, any file of the same name in subsequent directories is ignored. /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf

V-284948 in V2R9

Check text

AND - net.ipv4.conf.default.log_martians setting in kernel is 1 sysctl_test (check: all, existence: all_exist) object sysctl_object: name equals "net.ipv4.conf.default.log_martians" state sysctl_state: value equals "1" Verify RHEL 8 logs IPv4 martian packets by default. Check the value of the "default.log_martians" variable with the following command: $ sudo sysctl net.ipv4.conf.default.log_martians net.ipv4.conf.default.log_martians = 1 If "net.ipv4.conf.default.log_martians" is not set to "1" or is missing, this is a finding.

Discussion

The presence of "martian" packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. Logging these packets enables this activity to be detected. Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DODDoW or other government agencies. There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components. Restricting access to the kernel message buffer limits access to only root. This prevents attackers from gaining additional system information as a nonprivileged user. The sysctl --system command will load settings from all system configuration files. All configuration files are sorted by their filename in lexicographical order, regardless of the directories in which they reside. If multiple files specify the same option, the entry in the file with the lexicographically latest name will take precedence. Files are read from directories in the following list from top to bottom. Once a file of a given filename is loaded, any file of the same name in subsequent directories is ignored. /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf

V-284949 in V2R9