What changed in Red Hat Enterprise Linux 9 SCAP Benchmark V2R10V2R10 changes

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 9 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 9 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-257784 in V2R10

Title

RHEL 9 must require a boot loader superuser password.RHEL 9 must require authentication upon booting into single-user and maintenance modes.

Check text

AND - /etc/grub2.cfg:superusers exists and has a name. textfilecontent54_test (check: all, existence: all_exist) object textfilecontent54_object: filepath equals "/etc/grub2.cfg"; pattern pattern match "^\\s*set\\s+superusers\\s*=\\s*\"(\\S+)\"\\s*$"; instance greater than or equal "1" state textfilecontent54_state: subexpression pattern match "^\\S+$" OR - /boot/grub2/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/grub2/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\\." Note: - For systems that use UEFI, this is not applicable. Verify the /boot loader superuser password has been set with the following command: $ sudo grep password_pbkdf2 /etcefi/grub2EFI/redhat/user.cfg password_pbkdf2 <superusers-accountname> ${:GRUB2_PASSWORD} To verifyexists theand boothas loadera superuserPBKDF2/SHA512 account password hasassigned. textfilecontent54_test been(check: set and the password encryptedall, runexistence: theall_exist) object following commandtextfilecontent54_object: $ sudofilepath catequals "/boot/grub2efi/EFI/redhat/user.cfg"; GRUB2_PASSWORD=grub.pbkdf2.sha512.10000.C4E08AC72FBFF7E837FD267BFAD7AEB3D42DDC 2C99F2A94DD5E2E75C2DC331B719FE55D9411745F82D1B6CFD9E927D61925F9BBDD1CFAA0080E0 916F7AB46E0D.1302284FCCC52CD73BA3671C6C12C26FF50BA873293B24EE2A96EE3B57963E6D7 0C83964B473EC8F93B07FE749AA6710269E904A9B08A6BBACB00A2D242AD828pattern Ifpattern amatch "^\\s*GRUB2_PASSWORD=(\\S+)\\b"; isinstance notgreater set,than thisor isequal a"1" state findingtextfilecontent54_state: subexpression pattern match "^grub\\.pbkdf2\\.sha512\\."

Discussion

To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DODDoW-approved PKIs, all DODDoW systems (e.g., web servers and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode.

V-257787 in V2R10

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 9 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 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 Satisfies: SRG-OS-000132-GPOS-00067, SRG-OS-000138-GPOS-00069

V-257797 in V2R10

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 9 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 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 Satisfies: SRG-OS-000132-GPOS-00067, SRG-OS-000138-GPOS-00069

V-257798 in V2R10

Check text

AND - /etc/dnf/dnf.conf gpgcheck=1 textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: filepath equals "/etc/dnf/dnf.conf"; pattern pattern match "^gpgcheck=(.*)$"; instance greater than or equal "1" state textfilecontent54_state: subexpression equalspattern match "(?i)^(True|1" Verify that dnf always checks the GPG signature of software packages originating from external software repositories before installation: |yes)$ grep -w gpgcheck /etc/dnf/dnf.conf gpgcheck=1 If "gpgcheck" is not set to "1", or if the option is missing or commented out, ask the system administrator how the GPG signatures of software packages are being verified. If there is no process to verify GPG signatures that is approved by the organization, this is a finding.

Fix text

Configure RHEL 9 dnf to always check the GPG signature of software packages originating from external software repositories before installation. Add or update the following line in the [main] section of the "/etc/dnf/dnf.conf" file: gpgcheck=1 Note: Any of the following are acceptable: "1", "on", or "true" (keywords containing letters are case insensitive).

V-257820 in V2R10

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 "(?i)^(True|1|yes)$" Verify that dnf always checks the GPG signature of locally installed software packages before installation: $ grep localpkg_gpgcheck /etc/dnf/dnf.conf localpkg_gpgcheck=1 If "localpkg_gpgcheck" is not set to "1", or if the option is missing or commented out, ask the system administrator how the GPG signatures of local software packages are being verified. If there is no process to verify GPG signatures that is approved by the organization, this is a finding.

Fix text

Configure RHEL 9 dnf to always check the GPG signature of local software packages before installation. Add or update the following line in the [main] section of the "/etc/dnf/dnf.conf" file: localpkg_gpgcheck=1 Note: Any of the following are acceptable: "1", "on", or "true" (keywords containing letters are case insensitive).

V-257821 in V2R10

Check text

AND - Every /etc/yum.repos.d/*.repo:[{reponame}] has a gpgcheck entry set to '1', 'true', or 'false'. 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 "(?i)\\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 "(?i)\\n\\s*gpgcheck\\s*=\\s*(False|0|no)\\s*(\\n|$)" Verify all software repositories defined in "/etc/yum.repos.d/" have been configured with "gpgcheck" enabled: $ grep -w gpgcheck /etc/yum.repos.d/*.repo | more /etc/yum.repos.d/redhat.repo:gpgcheck = 1 For all listed repos, if "gpgcheck" is not set to "1", or if the option is missing or commented out, ask the system administrator how the GPG signatures of local software packages are being verified. If there is no process to verify GPG signatures that is approved by the organization, this is a finding.

Fix text

Configure allRHEL 9 software repositories defined in "/etc/yum.repos.d/" to have "gpgcheck" enabled with the following command: $ sudo sed -i 's/gpgcheck\s*=.*/gpgcheck=1/g' /etc/yum.repos.d/* Note: Any of the following are acceptable: "1", "on", or "true" (keywords containing letters are case insensitive).

V-257822 in V2R10

Check text

AND - /etc/dnf/dnf.conf: clean_requirements_on_remove is set to True, 1 or yes textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: filepath equals "/etc/dnf/dnf.conf"; pattern pattern match "^[ \\t]s*clean_requirements_on_remove[ \\t]s*=[ \\t]s*(?:True|1|yes\\w+)[ \\t]b\\s*$"; instance greater than or equal "1" Verify state RHEL 9 removes all software components after updated versions have been installed with the following commandtextfilecontent54_state: $ grepsubexpression -ipattern clean_requirements_on_removematch /etc/dnf/dnf.conf clean_requirements_on_remove=True If "clean_requirements_on_remove" is not set to "(?i)^(True|1|yes)$", this is a finding.

Fix text

Configure RHEL 9 to remove all software components after updated versions have been installed. Edit the file "/etc/dnf/dnf.conf" by adding or editing the following line: clean_requirements_on_remove=True Note: Any of the following are acceptable: "1", "on", or "true" (keywords containing letters are case insensitive).

V-257824 in V2R10

Check text

AND - package openssl-pkcs11 is installed rpminfo_test (check: all, existence: all_exist) object rpminfo_object: name equals "openssl-pkcs11" Note: If the system administrator demonstrates the use of an approved alternate multifactor authentication method, this requirement is Not Applicable. Verify that RHEL 9 has the openssl-pkcs11 package installed with the following command: $ dnf list --installed openssl-pkcs11 Example output: openssl-pkcs.i686 0.4.11-7.el9 openssl-pkcs.x86_64 0.4.11-7.el9 If the "openssl-pkcs11" package is not installed, this is a finding.

Discussion

Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. A privileged account is defined as an information system account with authorizations of a privileged user. The DODDoW common access card (CAC) with DODDoW-approved PKI is an example of multifactor authentication. Satisfies: SRG-OS-000105-GPOS-00052, SRG-OS-000375-GPOS-00160, SRG-OS-000376-GPOS-00161, SRG-OS-000377-GPOS-00162

V-257838 in V2R10

Title

The RHEL 9 file system automounter function must be disabled unless required.

Check text

AND OR AND - The autofs.service LoadState is inactivemasked if it exists. systemdunitproperty_test (check: all, existence: any_exist) object systemdunitproperty_object: property equals "ActiveStateLoadState"; unit equals "autofs.service" state systemdunitproperty_state: value equals "inactivemasked" Note: - If the autofs .service UnitFileState is notmasked installed,if thisit requirement is Not Applicableexists. Verify systemdunitproperty_test that(check: theall, RHELexistence: 9any_exist) object filesystemdunitproperty_object: systemproperty automountequals function"UnitFileState"; hasunit beenequals disabled with the following command: $ systemctl is-enabled "autofs.service" masked If state thesystemdunitproperty_state: returned value isequals not "masked", - "disabled", or "Failed to get unit file state for autofs.service forUnitFileState autofs"is anddisabled isif notit documentedexists. systemdunitproperty_test as(check: anall, operationalexistence: requirementany_exist) object withsystemdunitproperty_object: theproperty informationequals system"UnitFileState"; securityunit officerequals (ISSO),"autofs.service" state thissystemdunitproperty_state: isvalue aequals finding."disabled"

Fix text

Configure RHEL 9 to disable and mask the ability to automount devices. The "autofs" service can be disabled with the following command: $ sudo systemctl mask --now autofs.service

Discussion

AnWithout authenticationidentifying processdevices, resistsunidentified replayor attacksunknown ifdevices itmay isbe impracticalintroduced, tothereby achievefacilitating amalicious successfulactivity. Peripherals authenticationinclude, bybut recordingare andnot replayinglimited ato, previousdevices authenticationsuch messageas flash drives, external storage, and printers. Satisfies: SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-00163, SRG-OS-000480-GPOS-00227

V-257849 in V2R10

Check text

AND - oval:mil.disa.stig.linux:tst:23050500 rpminfo_test (check: all, existence: ) object rpminfo_object: name equals "firewalld" Run the following command to determine if the firewalld package is installed with the following command: $ dnf list --installed firewalld Example output: firewalld.noarch 1.0.0-4.el9 If the "firewall" package is not 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, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. RHEL 9 functionality (e.g., SSH) must be capable of taking enforcement action if the audit reveals unauthorized activity. Automated control of remote access sessions allows organizations to ensure ongoing compliance with remote access policies by enforcing connection rules of remote access applications on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets). Satisfies: SRG-OS-000096-GPOS-00050, SRG-OS-000297-GPOS-00115, SRG-OS-000298-GPOS-00116, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00232

V-257935 in V2R10

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 command: $ systemctl is-active firewalld active If the firewalld service is not 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, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. RHEL 9 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). Satisfies: SRG-OS-000096-GPOS-00050, SRG-OS-000297-GPOS-00115, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00232

V-257936 in V2R10

Check text

AND - net.ipv4.tcp_syncookies setting in kernel to 1 sysctl_test (check: all, existence: all_exist) object sysctl_object: name equals "net.ipv4.tcp_syncookies" state sysctl_state: value equals "1" Verify RHEL 9 is configured to use IPv4 TCP syncookies. Check the value of all "tcp_syncookies" variables with the following command: $ sudo sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_syncookies = 1 If the network parameter "ipv4.tcp_syncookies" is not equal to "1" or nothing is returned, 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 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 Satisfies: SRG-OS-000480-GPOS-00227, SRG-OS-000420-GPOS-00186, SRG-OS-000142-GPOS-00071

V-257957 in V2R10

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 9 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-257960 in V2R10

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 9 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-257961 in V2R10

Title

RHEL 9 must display the Standard Mandatory DODoW Notice and Consent Banner before granting local or remote access to the system via a SSH logon.

Check text

AND - /etc/ssh/sshd_config:banner == /filepath textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: state textfilecontent54_state: subexpression pattern match "^\\/.+$" - /etc/ssh/sshd_config:banner != none textfilecontent54_test (check: all, existence: none_exist) object textfilecontent54_object: Verify any SSH connection to RHEL 9 displays the Standard Mandatory DOD Notice and Consent Banner before granting access to the system. Check for the location of the banner file being used with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*banner' /etc/ssh/sshd_config.d/80-bannerPointer.conf: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.

Fix text

Configure RHEL 9 to display the Standard Mandatory DODDoW Notice and Consent Banner before granting access to the system via ssh. Edit the "etc/ssh/sshd_config" file or a file in "/etc/ssh/sshd_config.d" 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

V-257981 in V2R10

Check text

AND OR AND - sshd_config includes sshd_config.d textfilecontent54_test (check: at least one, existence: at_least_one_exists) object textfilecontent54_object: pattern pattern match "^\\s*include\\s+(.*)\\s*$"; instance greater than or equal "1"; filepath equals "/etc/ssh/sshd_config"; behaviors equals "" state textfilecontent54_state: subexpression equals "/etc/ssh/sshd_config.d/*.conf" - /etc/ssh/sshd_config.d: PubkeyAuthentication is set to yes textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: pattern pattern match "^\\s*(?i)PubkeyAuthentication(?-i)[ \\t]+([\\w\\\"]+)[\\s]*(?:|(?:#.*))?$"; path equals "/etc/ssh/sshd_config.d"; filename pattern match "^.+\\.conf$"; instance greater than or equal "1"; behaviors equals "" state textfilecontent54_state: subexpression pattern match "^(yes|\"yes\")$" - /etc/ssh/sshd_config: PubkeyAuthentication is set to yes textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: pattern pattern match "^\\s*(?i)PubkeyAuthentication(?-i)[ \\t]+([\\w\\\"]+)[\\s]*(?:|(?:#.*))?$"; instance greater than or equal "1"; filepath equals "/etc/ssh/sshd_config"; behaviors equals "" state textfilecontent54_state: subexpression pattern match "^(yes|\"yes\")$" Note: If the system administrator demonstrates the use of an approved alternate multifactor authentication method, this requirement is Not Applicable. Verify that RHEL 9 SSH daemon accepts public key encryption with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*pubkeyauthentication' PubkeyAuthentication yes If "PubkeyAuthentication" is set to no, the line is commented out, or the line is missing, this is a finding.

Discussion

Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. A privileged account is defined as an information system account with authorizations of a privileged user. A DODDoW common access card (CAC) with DODDoW-approved PKI is an example of multifactor authentication. Satisfies: SRG-OS-000105-GPOS-00052, SRG-OS-000106-GPOS-00053, SRG-OS-000107-GPOS-00054, SRG-OS-000108-GPOS-00055

V-257983 in V2R10

Title

The RHEL 9 SSH server must be configured to use only DODDoW-approved encryption ciphers employing FIPS 140-3 validated cryptographic hash algorithms to protect the confidentiality of SSH server connections.

Check text

AND - opensshserver.config ciphers correct textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: filepath equals "/etc/crypto-policies/back-ends/opensshserver.config"; pattern pattern match "^\\s*(?i)Ciphers(?-i)[ \\t]+(\\S+)[\\s]*(?:|(?:#.*))?$"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "aes256-gcm@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr" state textfilecontent54_state: subexpression equals "\"aes256-gcm@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr\"" Verify the SSH server is configured to use only ciphers employing FIPS 140-3 approved algorithms. To verify the ciphers in the systemwide SSH configuration file, use the following command: $ sudo grep -i Ciphers /etc/crypto-policies/back-ends/opensshserver.config Ciphers aes256-gcm@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr If the cipher entries in the "opensshserver.config" file have any ciphers other than "aes256-gcm@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr", or they are missing or commented out, this is a finding.

Discussion

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) 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. Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. RHEL 9 incorporates systemwide crypto policies by default. The SSH configuration file has no effect on the ciphers, MACs, or algorithms unless specifically defined in the /etc/sysconfig/sshd file. The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/opensshserver.config file.

V-257989 in V2R10

Check text

AND - oval:mil.disa.stig.ind:tst:25799100 textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: filepath equals "/etc/crypto-policies/back-ends/opensshserver.config"; pattern pattern match "^\\s*MACs\\s+(\\S+)\\s*$"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512" state textfilecontent54_state: subexpression equals "\"hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512\"" Verify the SSH server is configured to use only MACs employing FIPS 140-3 approved algorithms. To verify the MACs in the systemwide SSH configuration file, use the following command: $ sudo grep -i MACs /etc/crypto-policies/back-ends/opensshserver.config MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512 If the MACs entries in the "opensshserver.config" file have any hashes other than "hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512", or they are missing or commented out, this is a finding.

Discussion

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) 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. Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. RHEL 9 incorporates systemwide crypto policies by default. The SSH configuration file has no effect on the ciphers, MACs, or algorithms unless specifically defined in the /etc/sysconfig/sshd file. The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/opensshserver.config file.

V-257991 in V2R10

Title

RHEL 9 must displenayble the Standard Mandatory DODoW Notice and Consent Banner before granting local or remote access to the system via a graphical user logon.

Check text

AND - /etc/dconf/db/local.d/* has banner-message-enable set to true textfilecontent54_test (check: all, existence: all_exist) object textfilecontent54_object: pattern pattern match "^\\s*banner-message-enable\\s*=\\s*(\\w+)$"; path equals "/etc/dconf/db/local.d"; filename pattern match ".*"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "true" Verify RHEL 9 displays the Standard Mandatory DOD Notice and Consent Banner before granting access to the operating system via a graphical user logon. Note: This requirement assumes the use of the RHEL 9 default graphical user interface, the GNOME desktop environment. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Determine if the operating system displays a banner at the logon screen with the following command: $ gsettings get org.gnome.login-screen banner-message-enable true If the result is "false", this is a finding.

Fix text

Configure RHEL 9 to displayenable the Standard Mandatory DODDoW Notice and Consent Banner before granting access to the system via a graphical user logon. Create a database to contain the system-wide graphical user logon settings (if it does not already exist) with the following command: $ sudo touch /etc/dconf/db/local.d/01-banner-message Add the following lines to the [org/gnome/login-screen] section of the "/etc/dconf/db/local.d/01-banner-message": [org/gnome/login-screen] banner-message-enable=true Run the following command to update the database: $ sudo dconf update

V-258012 in V2R10

Check text

AND - oval:mil.disa.stig.ind:tst:23047000 textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: filepath equals "/etc/usbguard/usbguard-daemon.conf"; pattern pattern match "^\\s*AuditBackend\\s*=\\s*(\\w+)\\s*(?:#.*)?$"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "LinuxAudit" To verify that Linux Audit logging is enabled for the USBGuard daemon with the following command: $ sudo grep AuditBackend /etc/usbguard/usbguard-daemon.conf AuditBackend=LinuxAudit If "AuditBackend" is not set to "LinuxAudit", this is a finding. If the system is virtual machine with no virtual or physical USB peripherals attached, this is not 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. If auditing is enabled late in the startup process, the actions of some startup processes may not be audited. Some audit systems also maintain state information only available if auditing is enabled before a given process is created. 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 9 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.

V-258037 in V2R10

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" Verify that RHEL 9 disables the ability to load the Bluetooth kernel module with the following command: $ sudo grep -r bluetooth /etc/modprobe.conf /etc/modprobe.d/* install bluetooth /bin/false blacklist bluetooth If the command does not return any output, or the lines are commented out, and use of Bluetooth is not documented with the information system security officer (ISSO) as an operational requirement, this is a finding.

Discussion

This requirement applies to wireless peripheral technologies (e.g., wireless mice, keyboards, displays, etc.) used with RHEL 9 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 Authorizing Official (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 9 operating system. Satisfies: SRG-OS-000095-GPOS-00049, SRG-OS-000300-GPOS-00118

V-258039 in V2R10

Title

RHEL 9 user account passwords for new users or password changes must have a 6180-day maximum password lifetime restriction in /etc/login.defs.

Check text

AND - oval:mil.disa.stig.ind:tst:25804100 textfilecontent54_test (check: all, existence: ) 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 greater than "0" state textfilecontent54_state: subexpression less than or equal "60180" Verify that RHEL 9 enforces a 60-day maximum password lifetime for new user accounts by running the following command: $ grep -i pass_max_days /etc/login.defs PASS_MAX_DAYS 60 If the "PASS_MAX_DAYS" parameter value is greater than "60", or commented out, this is a finding.

Fix text

Configure RHEL 9 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-258041 in V2R10

Title

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

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" Verify the maximum time period for existing passwords is restricted to 60 days with the following commands: $ sudo awk -F: '$5 > 60 {printf "%s %d\n", $1, $5}' /etc/shadow $ sudo awk -F: '$5 <= 0 {printf "%s %d\n", $1, $5}' /etc/shadow If any results are returned that are not associated with a system account, this is a finding.

Fix text

Configure noncompliant accounts to enforce a 6180-day maximum password lifetime restriction. $ sudo passwd -x 6180 [user]

V-258042 in V2R10

Check text

AND - The system accounts other than root have the login shell configured to /sbin/nologin. password_test (check: all, existence: ) object password_object: state password_state: login_shell pattern match "/sbin/nologin|/usr/sbin/nologin" Verify that system accounts must not have an interactive login shell with the following command: $ awk -F: '($3<1000){print $1 ":" $3 ":" $7}' /etc/passwd root:0:/bin/bash bin:1:/sbin/nologin daemon:2:/sbin/nologin adm:3:/sbin/nologin lp:4:/sbin/nologin Identify the system accounts from this listing that do not have a nologin shell. If any system account (other than the root account) has a login shell and it is not documented with the information system security officer (ISSO), this is a finding.

Fix text

Configure RHEL 9 so that all noninteractive accounts on the system do not have an interactive shell assigned to them. If the system account needs a shell assigned for mission operations, document the need with the information system security officer (ISSO). Run the following command to disable the interactive shell for a specific noninteractive user account: Replace <user> with the user that has a login shell. $ sudo usermod --shell /usr/sbin/nologin <user> Do not perform the steps in this section on the root account. Doing so will cause the system to become inaccessible.

V-258046 in V2R10

Check text

AND - The system terminates idle user sessions. textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: filepath equals "/etc/systemd/logind.conf"; pattern pattern match "^\\s*StopIdleSessionSec\\s*=\\s*(-?\\d*)\\s*(?:#.*)?$"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "600" Verify RHEL 9 logs out sessions that are idle for 10 minutes with the following command: $ systemd-analyze cat-config systemd/logind.conf | grep StopIdleSessionSec #StopIdleSessionSec=infinity StopIdleSessionSec=600 If "StopIdleSessionSec" is not configured to "600" seconds, this is a finding.

V-258077 in V2R10

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 RHEL 9 requires reauthentication when using the "sudo" command to elevate privileges with the following command: $ sudo grep -ir 'timestamp_timeout' /etc/sudoers /etc/sudoers.d/ /etc/sudoers:Defaults timestamp_timeout=0 If results are returned from more than one file location, 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 RHEL 9 to reauthenticate "sudo"every commandsinvocation afterof the specified"sudo" timeout:command. Add the following line to "/etc/sudoers" or a file in "/etc/sudoers.d": Defaults timestamp_timeout=0 Remove any duplicate definitions.

V-258084 in V2R10

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 that RHEL 9 enforces a minimum 15-character password length with the following command: $ grep minlen /etc/security/pwquality.conf /etc/security/pwquality.conf.d/*.conf minlen = 15 If the command does not return a "minlen" value of "15" or greater, does not return a line, or the line is 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. RHEL 9 uses "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, but they will not count toward the total "score" of "minlen". This will enable "minlen" to require a 15-character minimum. The DODDoW minimum password requirement is 15 characters.

V-258107 in V2R10

Check text

AND - libuser.conf, defaults/crypt_style exists textfilecontent54_test (check: at least one, existence: at_least_one_exists) object textfilecontent54_object: filepath equals "/etc/libuser.conf"; pattern pattern match "^\\[defaults]((?:\\r?\\n(?:[^[\\r\\n].*)?)*)"; instance greater than or equal "1" state textfilecontent54_state: subexpression pattern match "\\n\\s*crypt_style\\s*=\\s*(\\S*)\\s*(\\n|$)" - libuser.conf, crypt_style = sha512 textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: filepath equals "/etc/libuser.conf"; pattern pattern match "^\\s*crypt_style\\s*=\\s*(\\S+)\\s*$"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "sha512" Verify the user and group account administration utilities are configured to store only encrypted representations of passwords with the following command: $ grep crypt_style /etc/libuser.conf crypt_style = sha512 If the "crypt_style" variable is not set to "sha512", is not in the defaults section, is commented out, or does not exist, this is a finding.

V-258116 in V2R10

Check text

AND - sssd.conf: pam_cert_auth = True textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: state textfilecontent54_state: subexpression case insensitive equals "true" Note: If the system administrator (SA) demonstrates the use of an approved alternate multifactor authentication method, this requirement is Not Applicable. To verify that RHEL 9 has smart cards enabled in System Security Services Daemon (SSSD), run the following command: $ sudo grep -ir pam_cert_auth /etc/sssd/sssd.conf /etc/sssd/conf.d/ pam_cert_auth = True If "pam_cert_auth" is not set to "True", the line is commented out, or the line is missing, this is a finding.

Discussion

Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. A privileged account is defined as an information system account with authorizations of a privileged user. The DODDoW Common Access Card (CAC) with DODDoW-approved PKI is an example of multifactor authentication. Satisfies: SRG-OS-000375-GPOS-00160, SRG-OS-000105-GPOS-00052

V-258122 in V2R10

Check text

AND - sssd config: certificate_verification: ocsp_dgst=sha512 textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: state textfilecontent54_state: subexpression pattern match "(?i)(^|,)ocsp_dgst=sha512(,|$)" Note: If the system administrator (SA) demonstrates the use of an approved alternate multifactor authentication method, this requirement is not applicable. Verify the operating system implements Online Certificate Status Protocol (OCSP) and is using the proper digest value on the system with the following command: $ sudo grep -sir certificate_verification /etc/sssd/sssd.conf /etc/sssd/conf.d/ | grep -v "^#" /etc/sssd/conf.d/certificate_verification:certificate_verification = ocsp_dgst=sha512 If the certificate_verification line is missing from the [sssd] section, or is missing "ocsp_dgst=sha512", ask the administrator to indicate what type of multifactor authentication is being used and how the system implements certificate status checking. If there is no evidence of certificate status checking being used, this is a finding.

Discussion

Using an authentication device, such as a DODDoW common access card (CAC) or token that is separate from the information system, ensures that even if the information system is compromised, credentials stored on the authentication device will not be affected. Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification (PIV) card and the DODDoW CAC. RHEL 9 includes multiple options for configuring certificate status checking, but for this requirement focuses on the System Security Services Daemon (SSSD). By default, SSSD performs Online Certificate Status Protocol (OCSP) checking and certificate verification using a sha256 digest function. Satisfies: SRG-OS-000375-GPOS-00160, SRG-OS-000377-GPOS-00162

V-258123 in V2R10

Check text

AND - opensc package is installed rpminfo_test (check: all, existence: at_least_one_exists) object rpminfo_object: name equals "opensc" Verify that RHEL 9 has the opensc package installed with the following command: $ dnf list --installed opensc Example output: opensc.x86_64 0.22.0-2.el9 If the "opensc" package is not installed, this is a finding.

Discussion

The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access. The DODDoW has mandated the use of the common access card (CAC) to support identity management and personal authentication for systems covered under Homeland Security Presidential Directive (HSPD) 12, as well as making the CAC a primary component of layered protection for national security systems. Satisfies: SRG-OS-000375-GPOS-00160, SRG-OS-000376-GPOS-00161

V-258126 in V2R10

Check text

AND - emergency.service config correct textfilecontent54_test (check: all, existence: all_exist) object textfilecontent54_object: filepath equals "/usr/lib/systemd/system/emergency.service"; pattern pattern match "^ExecStart=(.*)$"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "-/usr/lib/systemd/systemd-sulogin-shell emergency" Verify RHEL 9 requires authentication for emergency mode with the following command: $ grep sulogin /usr/lib/systemd/system/emergency.service ExecStart=-/usr/lib/systemd/systemd-sulogin-shell emergency If the line is not returned from the default systemd file, use the following command to look for modifications to the emergency.service: $ grep sulogin /etc/systemd/system/emergency.service.d/*.conf If the line is not returned from either location this is a finding. Note: The configuration setting can only be in either the default location, or in the drop in file, not both locations.

Fix text

Configure RHEL 9 to require authentication for emergency mode. Create a directory for supplementary configuration files: $ sudo mkdir /etc/systemd/system/emergency.service.d/ CopyCreate thea original file emergency.service file to the new directory with: $ sudo cp /usr/lib/systemd/system/emergency.service /etc/systemd/system/emergency.service.d/emergency.service.conf Open the new file: $ sudo vi /etc/systemd/system/emergency.service.d/emergency.service.conf Add orthese modifylines theto following line in the new file: [Service] ExecStart= ExecStart=-/usr/lib/systemd/systemd-sulogin-shell emergency Comment out or remove the ExecStart and ExecStartPre lines in /usr/lib/systemd/system/emergency.service as they can only exist in one location. Apply changes to unit files without rebooting the system: $ sudo systemctl daemon-reload

Discussion

To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DODDoW-approved PKIs, all DODDoW systems (e.g., web servers and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. This requirement prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password.

V-258128 in V2R10

Check text

AND OR - /usr/lib/systemd/system/rescue.service:ExecStart is set to -/usr/lib/systemd/systemd-sulogin-shell rescue textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: pattern pattern match "^\\s*ExecStart=-\\/usr\\/lib\\/systemd\\/systemd-sulogin-shell\\srescue$"; path equals "/usr/lib/systemd/system"; filename equals "rescue.service"; instance greater than or equal "1" - /etc/systemd/system/rescue.service.d/*.conf:ExecStart is set to -/usr/lib/systemd/systemd-sulogin-shell rescue textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: pattern pattern match "^\\s*ExecStart=-\\/usr\\/lib\\/systemd\\/systemd-sulogin-shell\\srescue$"; path equals "/etc/systemd/system/rescue.service.d"; filename pattern match "^.+\\.conf$"; instance greater than or equal "1" Verify RHEL 9 requires authentication for single-user mode with the following command: $ grep sulogin /usr/lib/systemd/system/rescue.service ExecStart=-/usr/lib/systemd/systemd-sulogin-shell rescue If the line is not returned from the default systemd file, use the following command to look for modifications to the rescue.service: $ grep sulogin /etc/systemd/system/rescue.service.d/*.conf If the line is not returned from either location this is a finding. Note: The configuration setting can only be in either the default location, or in the drop in file, not both locations.

Fix text

Configure RHEL 9 to require authentication for single-user mode. Create a directory for supplementary configuration files: $ sudo mkdir /etc/systemd/system/rescue.service.d/ CopyCreate thea original file rescue.service file to the new directory with: $ sudo cp /usr/lib/systemd/system/rescue.service /etc/systemd/system/rescue.service.d/rescue.service.conf Open the new file: $ sudo vi etc/systemd/system/rescue.service.d/rescue.service.conf Add thisthese linelines to the new file: [Service] ExecStart= ExecStart=-/usr/lib/systemd/systemd-sulogin-shell rescue Comment out or remove the ExecStart and ExecStartPre lines in /usr/lib/systemd/system/rescue.service as they can only exist in one location. Apply changes to unit files without rebooting the system: $ sudo systemctl daemon-reload

Discussion

To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DODDoW-approved PKIs, all DODDoW systems (e.g., web servers and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. This requirement prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password. To modify properties, such as dependencies or timeouts, of a service that is handled by a SysV initscript, do not modify the initscript itself. Instead, create a systemd drop-in configuration file for the service. Then manage this service in the same way as a normal systemd service. For example, to extend the configuration of the network service, do not modify the /etc/rc.d/init.d/network initscript file. Instead, create new directory /etc/systemd/system/network.service.d/ and a systemd drop-in file /etc/systemd/system/network.service.d/my_config.conf. Then, put the modified values into the drop-in file. Note: systemd knows the network service as network.service, which is why the created directory must be called "network.service.d".

V-258129 in V2R10

Check text

AND - /etc/audit/auditd.conf: admin_space_left = 5% textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: filepath equals "/etc/audit/auditd.conf"; pattern pattern match "(?i)^\\s*admin_space_left\\s*=\\s*(\\S+)\\s*(?:#.*)?$"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "5%" Verify RHEL 9 takes action when allocated audit record storage volume reaches 95 percent of the repository maximum audit record storage capacity with the following command: $ sudo grep -w admin_space_left /etc/audit/auditd.conf admin_space_left = 5% If the value of the "admin_space_left" keyword is not set to 5 percent of the storage volume allocated to audit logs, or if the line is commented out, ask the system administrator (SA) to indicate how the system is taking action if the allocated storage is about to reach capacity. If the "space_left" value is not configured to the correct value, this is a finding.

Discussion

If action is not taken when storage volume reaches 95 percent utilization, the auditing system may fail when the storage volume reaches capacity. While "%" is fully compliant for auditd.conf, you must account for how auditd processes it. The percentage-to-megabyte conversion occurs only when the audit daemon starts. If you dynamically resize the underlying logical volume/partition where /var/log/audit resides while the system is running, the daemon will not automatically know. You must reload it to trigger a recalculation.

V-258158 in V2R10

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 with the following command: $ sudo find /etc/audit/rules.d/ /etc/audit/audit.rules /etc/audit/auditd.conf -type f -exec stat -c "%a %n" {} \; 600 /etc/audit/rules.d/audit.rules 600 /etc/audit/audit.rules 600 /etc/audit/auditd.conf If the audit configuration files 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-258171 in V2R10

Check text

AND - Audit 32-bit invocations of /usr/bin/gpasswd 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+-SF\\s+all)?arch=b32\\s+-FS\\s+path=/usr/bin/gpasswdexecve\\s+(-F\\s+permpath=([rwa]*x[rwa]*)/usr/bin/gpasswd\\s+)(?:-F\\s+auid>=1000\\s+-F\\s+auid!=(4294967295|-1|unset))?\\s*(-F\\s+perm=([rwa]*x[rwa]*))(\\s+(-k\\s+|-F\\s+key=)[-\\Sw]+)?*\\s*$"; instance greater than or equal "1" Verify - thatAudit RHEL64-bit 9invocations is configured to audit the execution of the "/usr/bin/gpasswd" textfilecontent54_test command(check: withall, theexistence: followingall_exist) object commandtextfilecontent54_object: $ sudofilepath auditctlequals -l"/etc/audit/audit.rules"; |pattern greppattern gpasswd match "^\\s*-a \\s+(always,exit |exit,always)\\s+-F\\s+arch=b64\\s+-S all \\s+execve\\s+-F \\s+path=/usr/bin/gpasswd \\s+(?:-F perm=x -F \\s+auid>=1000 \\s+-F \\s+auid!=(4294967295|-1 |unset))?\\s*(-F \\s+perm=([rwa]*x[rwa]*))(\\s+(-k\\s+|-F\\s+key=privileged)[-gpasswd If\\w]+)*\\s*$"; theinstance commandgreater doesthan not return a line, or theequal line is commented out, this is a finding."1"

Fix text

Configure RHEL 9 to generate audit records upon successful/unsuccessful attempts to use the "gpasswd" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -F path=/usr/bin/gpasswd -F perm=x -k identity -a always,exit -F auid>arch=1000b64 -F auid!path=unset/usr/bin/gpasswd -kF privilegedperm=x -gpasswdk identity To load the rules to the kernel immediately, use the following command: $ sudo augenrules --load

V-258194 in V2R10

Check text

AND - Audit 32-bit invocations of /usr/bin/passwd 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+-SF\\s+all)?arch=b32\\s+-F\\s+path=/usr/bin/passwd\\s+(-F\\s+perm=([rwa]*x[rwa]*)\\s+)?:-F\\s+auid>=1000\\s+-F\\s+auid!=(4294967295|-1|unset))?\\s*(-F\\s+perm=([rwa]*x[rwa]*))(\\s+(-k\\s+|-F\\s+key=)[-\\Sw]+)?*\\s*$"; instance greater than or equal "1" Verify - RHELAudit 964-bit generatesinvocations auditof records/usr/bin/passwd textfilecontent54_test for(check: all account creations, modifications,existence: disabling,all_exist) object andtextfilecontent54_object: terminationfilepath eventsequals that affect "/etc/gshadowaudit/audit.rules"; withpattern thepattern followingmatch command: $ sudo auditctl "^\\s*-l | egrep '(/usr/bin/passwd)' -a \\s+(always,exit |exit,always)\\s+-S all F\\s+arch=b64\\s+-F \\s+path=/usr/bin/passwd \\s+(?:-F perm=x -F \\s+auid>=1000 \\s+-F \\s+auid!=(4294967295|-1 |unset))?\\s*(-F \\s+perm=([rwa]*x[rwa]*))(\\s+(-k\\s+|-F\\s+key=privileged)[-passwd If\\w]+)*\\s*$"; theinstance commandgreater doesthan not return a line, or theequal line is commented out, this is a finding."1"

Fix text

Configure RHEL 9 to generate audit records upon successful/unsuccessful attempts to use the "passwd" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -F path=/usr/bin/passwd -F perm=x -k identity -a always,exit -F auid>arch=1000b64 -F auid!path=unset/usr/bin/passwd -kF privilegedperm=x -passwdk identity To load the rules to the kernel immediately, use the following command: $ sudo augenrules --load

V-258198 in V2R10

Title

RHEL 9 must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/security/opasswd.

Check text

AND - Audit 32-bit invocations of /etc/security/opasswd 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+-F\\s+arch=b32?\\s+-F\\s+path=\\/etc\\/security\\/opasswd\\s+-F\\s*perm=([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)(\\s+(-k\\s+|-F\\s+key=)\\S+)?\\s*$"; instance greater than or equal "1" - Audit 64-bit invocations of /etc/security/opasswd 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+-F\\s+arch=b64?\\s+-F\\s+path=\\/etc\\/security\\/opasswd\\s+-F\\s*perm=([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*)(\\s+(-k\\s+|-F\\s+key=)\\S+)?\\s*$"; instance greater than or equal "1" Verify RHEL 9 generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd" with the following command: $ sudo auditctl -l | egrep '(/etc/security/opasswd)' -a always,exit -F arch=b32 -F path=/etc/security/opasswd -F perm=wa -k identity -a always,exit -F arch=b64 -F path=/etc/security/opasswd -F perm=wa -k identity If the command does not return a line, or the line is commented out, this is a finding.

Fix text

Configure RHEL 9 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": -a always,exit -F arch=b32 -F path=/etc/security/opasswd -F perm=wa -k identity -a always,exit -F arch=b64 -F path=/etc/security/opasswd -F perm=wa -k identity To load the rules to the kernel immediately, use the following command: $ sudo augenrules --load

V-258221 in V2R10

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 in /etc/pam.d/password-auth with the following command: $ grep "^password.*pam_unix.so.*sha512" /etc/pam.d/password-auth password sufficient pam_unix.so sha512 If "sha512" is missing, or the line is commented out, this is a finding. If the system administrator (SA) can demonstrate that the required configuration is contained in a PAM configuration file included or substacked from the system-auth file, this is not 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 9 systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. FIPS 140-3 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-258233 in V2R10

Title

RHEL 9 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" Verify that BIND uses the system crypto policy with the following command: Note: If the "bind" package is not installed, this requirement is Not Applicable. $ sudo grep include /etc/named.conf include "/etc/crypto-policies/back-ends/bind.config";' If BIND is installed and the BIND config file doesn't contain the include "/etc/crypto-policies/back-ends/bind.config" directive, or the line is commented out, this is a finding.

V-258242 in V2R10

Title

The RHEL 9 SSH client must be configured to use only DODDoW-approved encryption ciphers employing FIPS 140-3 validated cryptographic hash algorithms to protect the confidentiality of SSH client connections.

Check text

AND - openssh.config ciphers correct textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: filepath equals "/etc/crypto-policies/back-ends/openssh.config"; pattern pattern match "^\\s*(?i)Ciphers(?-i)[ \\t]+(\\S+)[\\s]*(?:|(?:#.*))?$"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "aes256-gcm@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr" state textfilecontent54_state: subexpression equals "\"aes256-gcm@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr\"" Verify the SSH client is configured to use only ciphers employing FIPS 140-3 approved algorithms. To verify the ciphers in the systemwide SSH configuration file, use the following command: $ grep -i Ciphers /etc/crypto-policies/back-ends/openssh.config Ciphers aes256-gcm@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr If the cipher entries in the "openssh.config" file have any ciphers other than "aes256-gcm@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr", or they are missing or commented out, this is a finding.

Discussion

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) 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. Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography, enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. RHEL 9 incorporates systemwide crypto policies by default. The SSH configuration file has no effect on the ciphers, MACs, or algorithms unless specifically defined in the /etc/sysconfig/sshd file. The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/openssh.config file.

V-270177 in V2R10

Title

The RHEL 9 SSH client must be configured to use only DODDoW-approved Message Authentication Codes (MACs) employing FIPS 140-3 validated cryptographic hash algorithms to protect the confidentiality of SSH client connections.

Check text

AND - oval:mil.disa.stig.ind:tst:27017800 textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: filepath equals "/etc/crypto-policies/back-ends/openssh.config"; pattern pattern match "^\\s*MACs\\s+(\\S+)\\s*$"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512" state textfilecontent54_state: subexpression equals "\"hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512\"" Verify the SSH client is configured to use only MACs employing FIPS 140-3 approved algorithms. To verify the MACs in the systemwide SSH configuration file, use the following command: $ grep -i MACs /etc/crypto-policies/back-ends/openssh.config MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512 If the MACs entries in the "openssh.config" file have any hashes other than "hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha2-512", or they are missing or commented out, this is a finding.

Discussion

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) 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. Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography, enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. RHEL 9 incorporates systemwide crypto policies by default. The SSH configuration file has no effect on the ciphers, MACs, or algorithms unless specifically defined in the /etc/sysconfig/sshd file. The employed algorithms can be viewed in the /etc/crypto-policies/back-ends/openssh.config file.

V-270178 in V2R10