What changed in Red Hat Enterprise Linux 10 STIG V1R3V1R3 changes

Check text

Verify RHEL 10 dnf always checks the GPG signature of software packages originating from external software repositories before installation with the following command: $ sudo grep -w gpgcheck /etc/dnf/dnf.conf gpgcheck=1 If "gpgcheck" is not set to either "1", "true", or "yes" (keywords containing letters are case insensitive), or if the option is missing or commented out, ask the system administrator how the GPG signatures of software packages are being verified. If no process to verify GPG signatures has been approved by the organization, this is a finding.

Fix text

Configure RHEL 10 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", "true", or "yes" (keywords containing letters are case insensitive).

V-280932 in V1R3

Check text

Verify RHEL 10 dnf always checks the GPG signature of locally installed software packages before installation with the following command: $ sudo grep localpkg_gpgcheck /etc/dnf/dnf.conf localpkg_gpgcheck=1 If "localpkg_gpgcheck" is not set to either "1", "true", or "yes" (keywords containing letters are case insensitive), 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 no process to verify GPG signatures has been approved by the organization, this is a finding.

Fix text

Configure RHEL 10 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", "true", or "yes" (keywords containing letters are case insensitive).

V-280933 in V1R3

Check text

Verify RHEL 10 software repositories defined in "/etc/yum.repos.d/" have been configured with "gpgcheck" enabled with the following command: $ sudo grep -w gpgcheck /etc/yum.repos.d/*.repo | more gpgcheck = 1 If "localpkg_gpgcheckgpgcheck" for software packages and repositories is not set to either "1", "true", or "yes" (keywords containing letters are case insensitive), 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 no process to verify GPG signatures has been approved by the organization, this is a finding.

Fix text

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

V-280934 in V1R3

Check text

Verify RHEL 10 removes all software components after updated versions have been installed with the following command: $ sudo grep -i clean_requirements_on_remove /etc/dnf/dnf.conf clean_requirements_on_remove=True If "clean_requirements_on_remove" is not set to either "True1", "true", or "yes" (keywords containing letters are case insensitive), this is a finding.

Fix text

Configure RHEL 10 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", "true", or "yes" (keywords containing letters are case insensitive).

V-280942 in V1R3

Check text

Verify RHEL 10 does not have an FTP server package installed with the following command: $ sudo dnf list --installed vsftpvsftpd Error: No matching Packages to list If the "vsftpvsftpd" package is installed, this is a finding.

Fix text

Configure RHEL 10 to not have the FTP package installed with the following command (using "vsftpd" as an example): $ sudo dnf -y remove vsftpd

V-280951 in V1R3

Discussion

The "firewalld" package 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, that 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, nonorganizational-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. RHEL 10 functionality (e.g., Secure Shell [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-00232

V-280955 in V1R3

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 10 functionality (e.g., Remote Desktop Protocol [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-00232

V-280956 in V1R3

Discussion

Failure to restrict network connectivity only to authorized systems permits inbound connections from malicious systems. It also permits outbound connections that may facilitate exfiltration of DODDoW data. RHEL 10 incorporates the "firewalld" daemon, which allows for many different configurations. One of these configurations is zones. Zones can be used in a deny-all, allow-by-exception approach. The default "drop" zone will drop all incoming network packets unless it is explicitly allowed by the configuration file or is related to an outgoing network connection.

V-280957 in V1R3

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 10 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 login attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logins 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. 4) All kernel module load, unload, and restart actions. Satisfies: SRG-OS-000062-GPOS-00031, SRG-OS-000471-GPOS-00215

V-280965 in V1R3

Discussion

The use of Personal Identity Verification (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-280975 in V1R3

Check text

Verify RHEL 10 has the "rsyslogdrsyslog" package installed with the following command: $ sudo dnf list --installed rsyslog Installed Packages rsyslog.x86_64 8.2412.0-1.el10 @AppStream If the "rsyslogdrsyslog" package is not installed, this is a finding.

Fix text

Configure RHEL 10 to have the "rsyslogd" package installed with the following command: $ sudo dnf -y install rsyslogd

V-280983 in V1R3

Check text

Verify RHEL 10 rsyslog is configured to log cron events with the following command: Note: If another logging package is used, substitute the utility configuration file for "/etc/rsyslog.conf" or "/etc/rsyslog.d/*.conf" files. $ sudo grep -s "cron.1*" /etc/rsyslog.conf /etc/rsyslog.d/*.conf /etc/rsyslog.conf:*.info;mail.none;authpriv.none;d/99-cron-stig.none /var/log/messages /etc/rsyslog.conf:cron.* action(type="omfile" file="/var/log/cron") If the command does not return a responseline demonstrating logging to /var/log/cron, checkperform fora functional cron loggingtest. Inject alla facilitiesmessage into the cron logging facility with the following command: $ logger -p local0cron.info "Test message for all facilities.STIG-TEST-CRON-LOGGING" Check theif logsit forsuccessfully wrote to the testdedicated messagelog file with the following command: $ sudo tailgrep "STIG-TEST-CRON-LOGGING" /var/log/messagescron Jul 16 11:33:00 RHEL10Sim pdosadmin[33692]: STIG-TEST-CRON-LOGGING If "rsyslog" is not logging messages for the cron facility or all facilities, this is a finding.

Fix text

Configure RHEL 10 rsyslog to log all cron messages by adding or updating the following line to "/etc/rsyslog.conf" or a configuration file in the "/etc/rsyslog.d/" directory: cron.* /var/log/cron RestartThe the rsyslog daemon withmust thebe followingrestarted command for the changes to take effect: $ sudo systemctl restart rsyslog.service

V-280991 in V1R3

Check text

Note: If the system administrator demonstrates the use of an approved alternate multifactor authentication method, this requirement is not applicable. Verify RHEL 10 has the "openssl-pkcs11-provider" package installed with the following command: $ sudo dnf list --installed pkcs11-provider Installed Packages pkcs11-provider.x86_64 1.0-3.el10_0 @rhel-10-for-x86_64-baseos-rpms If the "openssl-pkcs11-provider" package is not installed, this is a finding.

Fix text

Configure RHEL 10 to have the "openssl-pkcs11-provider" package installed with the following command: $ sudo dnf -y install pkcs11-provider

Discussion

Without the use of multifactor authentication (MFA), the ease of access to privileged functions is greatly increased. MultifactorMFA 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 authenticationMFA. Satisfies: SRG-OS-000105-GPOS-00052, SRG-OS-000375-GPOS-00160, SRG-OS-000377-GPOS-00162

V-281005 in V1R3

Title

RHEL 10 must be configured so that Secure Shell (SSH) clients use only DODDoW-approved encryption ciphers employing FIPS 140-3-validated cryptographic hash algorithms to protect the confidentiality of SSH client connections.

Discussion

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., Remote Desktop Protocol [RDP]) is access to DODDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganizational-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 that use asymmetric cryptography. This enables distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. RHEL 10 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. Satisfies: SRG-OS-000033-GPOS-00014, SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093, SRG-OS-000393-GPOS-00173, SRG-OS-000394-GPOS-00174, SRG-OS-000423-GPOS-00187

V-281010 in V1R3

Title

RHEL 10 must be configured so that Secure Shell (SSH) servers use only DODDoW-approved encryption ciphers employing FIPS 140-3-validated cryptographic hash algorithms to protect the confidentiality of SSH server connections.

Discussion

Without cryptographic integrity protections, unauthorized users can alter information without detection. Remote access (e.g., Remote Desktop Protocol [RDP]) is access to DODDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganizational-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 that use asymmetric cryptography. This enables distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. RHEL 10 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. Satisfies: SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093

V-281011 in V1R3

Title

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

Discussion

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., Remote Desktop Protocol [RDP]) is access to DODDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganizational-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 that use asymmetric cryptography. This enables distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash. RHEL 10 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. Satisfies: SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093

V-281012 in V1R3

Title

RHEL 10 must be configured so that Secure Shell (SSH) servers use only DODDoW-approved Message Authentication Codes (MACs) employing FIPS 140-3-validated cryptographic hash algorithms to protect the confidentiality of SSH server connections.

Discussion

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., Remote Desktop Protocol [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 10 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. Satisfies: SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093

V-281013 in V1R3

Title

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

V-281015 in V1R3

Check text

Verify RHEL 10 cryptographic policies are not overridden. Verify the configured policy matches the generated policy with the following command: $ sudo update-crypto-policies --check The configured policy matches the generated policy If the returned message does not match the above, but instead matches the following, this is a finding: The configured policy does NOT match the generated policy List all of the crypto backends configured on the system with the following command: $ ls -l /etc/crypto-policies/back-ends/ lrwxrwxrwx. 1 root root 40 Nov 13 16:29 bind.config -> /usr/share/crypto-policies/FIPS/bind.txt lrwxrwxrwx. 1 root root 42 Nov 13 16:29 gnutls.config -> /usr/share/crypto-policies/FIPS/gnutls.txt lrwxrwxrwx. 1 root root 40 Nov 13 16:29 java.config -> /usr/share/crypto-policies/FIPS/java.txt lrwxrwxrwx. 1 root root 46 Nov 13 16:29 javasystem.config -> /usr/share/crypto-policies/FIPS/javasystem.txt lrwxrwxrwx. 1 root root 40 Nov 13 16:29 krb5.config -> /usr/share/crypto-policies/FIPS/krb5.txt lrwxrwxrwx. 1 root root 45 Nov 13 16:29 libreswan.config -> /usr/share/crypto-policies/FIPS/libreswan.txt lrwxrwxrwx. 1 root root 42 Nov 13 16:29 libssh.config -> /usr/share/crypto-policies/FIPS/libssh.txt -rw-r--r--. 1 root root 398 Nov 13 16:29 nss.config lrwxrwxrwx. 1 root root 43 Nov 13 16:29 openssh.config -> /usr/share/crypto-policies/FIPS/openssh.txt lrwxrwxrwx. 1 root root 49 Nov 13 16:29 opensshserver.config -> /usr/share/crypto-policies/FIPS/opensshserver.txt lrwxrwxrwx. 1 root root 46 Nov 13 16:29 opensslcnf.config -> /usr/share/crypto-policies/FIPS/opensslcnf.txt lrwxrwxrwx. 1 root root 43 Nov 13 16:29 openssl.config -> /usr/share/crypto-policies/FIPS/openssl.txt lrwxrwxrwx. 1 root root 48 Nov 13 16:29 openssl_fips.config -> /usr/share/crypto-policies/FIPS/openssl_fips.txt If the paths do not point to the respective files under "/usr/share/crypto-policies/FIPS" path, this is a finding. Note: nss.config should not be symlinked. Note: If there is an operational need to use a subpolicy that causes the links to the crypto backends to break, this is a finding, and exceptions must be made by the authorizing official and documented with the information system security officer.

V-281016 in V1R3

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 information system components that are, or use, such products. This can be verified by acceptance/validation processes in DODDoW or other government agencies.

V-281073 in V1R3

Check text

Verify RHEL 10 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 to indicate how the system is taking action if the allocated storage is about to reach capacity. If the "space_leftadmin_space_left" value is not configured to the correct value, this is a finding.

V-281107 in V1R3

Check text

Verify RHEL 10 isgenerates configuredaudit torecords auditfor the execution of the "gpasswd" command with the following command: $ sudo auditctl -l | grep '/usr/bin/gpasswd' -a always,exit -SF allarch=b32 -F path=/usr/bin/gpasswd -F perm=x -F auid>key=1000privileged-gpasswd -a always,exit -F auid!arch=b64 -1F path=/usr/bin/gpasswd -F perm=x -F key=privileged-gpasswd If the command does not return athese linelines, or the linelines isare commented out, this is a finding.

Fix text

Configure RHEL 10 to generate audit records upon successful and unsuccessful attempts to use the "gpasswd" command by adding or updating the following rulerules in "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -F path=/usr/bin/gpasswd -F perm=x -k privileged-gpasswd -a always,exit -F auid>arch=1000b64 -F auid!path=unset/usr/bin/gpasswd -F perm=x -k privileged-gpasswd RestartTo load the auditrules daemonto with the followingkernel commandimmediately, foruse the changesfollowing to take effectcommand: $ sudo serviceaugenrules auditd restart--load

V-281131 in V1R3

Check text

Verify RHEL 10 generates audit records for allsuccessful account creations, modifications, disabling, and terminationunsuccessful eventsuses thatof affectthe "/etc/passwd" command with the following command: $ sudo auditctl -l | egrepgrep '(/usr/bin/passwd)' -a always,exit -SF allarch=b32 -F path=/usr/bin/passwd -F perm=x -F auid>key=1000privileged-passwd -a always,exit -F auid!arch=b64 -1F path=/usr/bin/passwd -F perm=x -F key=privileged-passwd If the command does not return athese linelines, or the linelines isare commented out, this is a finding.

Fix text

Configure RHEL 10 to generate audit records upon successful and unsuccessful attempts to use the "passwd" command by adding or updating the following rulerules in "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -F path=/usr/bin/passwd -F perm=x -k privileged-passwd -a always,exit -F auid>arch=1000b64 -F auid!path=unset/usr/bin/passwd -F perm=x -k privileged-passwd RestartTo load the auditrules daemonto with the followingkernel commandimmediately, foruse the changesfollowing to take effectcommand: $ sudo serviceaugenrules auditd restart--load

V-281135 in V1R3

Check text

Verify RHEL 10 is configured to audit the execution of the "mount" command with the following command: $ sudo auditctl -l | grep mount -a always,exit -F arch=b32 -S mount -F auid>=1000 -F auid!=unset -k exportprivileged-mount -a always,exit -F arch=b64 -S mount -F auid>=1000 -F auid!=unset -k exportprivileged-mount If the command does not return a line, or the line is commented out, this is a finding.

Fix text

Configure RHEL 10 to generate audit records upon successful and unsuccessful attempts to use the "mount" command by adding or updating the following rule in "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S mount -F auid>=1000 -F auid!=unset -k exportprivileged-mount -a always,exit -F arch=b64 -S mount -F auid>=1000 -F auid!=unset -k exportprivileged-mount Restart the audit daemon with the following command for the changes to take effect: $ sudo service auditd restart

V-281147 in V1R3

Check text

Verify RHEL 10 generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers" with the following command: $ sudo auditctl -l | grep '/etc/sudoers[^.]' -a always,exit -F arch=b32 -F path=/etc/sudoers -F perm=wa -F key=loginsidentity -a always,exit -F arch=b64b32 -F path=/etc/sudoers -F perm=wa -F key=loginsidentity If the command does not return a line, or the line is commented out, this is a finding.

Fix text

Configure RHEL 10 to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -F path=/etc/sudoers -F perm=wa -F key=loginsidentity -a always,exit -F arch=b64 -F path=/etc/sudoers -F perm=wa -F key=loginsidentity Restart the audit daemon with the following command for the changes to take effect: $ sudo serviceaugenrules auditd restart--load

V-281154 in V1R3

Check text

Verify RHEL 10 generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers.d/" with the following command: $ sudo auditctl -l | grep /etc/sudoers.d -a always,exit -F arch=b32 -F path=/etc/sudoers.d/ -F perm=wa -F key=identity -a always,exit -F arch=b64 -F path=/etc/sudoers.d/ -F perm=wa -F key=identity If the command does not return a line, or the line is commented out, this is a finding.

Fix text

Configure RHEL 10 to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/sudoers.d/". Add or update the following file system rule to "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -F path=/etc/sudoers.d/ -F perm=wa -F key=identity -a always,exit -F arch=b64 -F path=/etc/sudoers.d/ -F perm=wa -F key=identity Restart the audit daemon with the following command for the changes to take effect: $ sudo service auditd restart

V-281155 in V1R3

Title

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

Check text

Verify RHEL 10 generates audit records for all account creations, modifications, disabling,to and termination events that affect "/etc/security/opasswd" with the following command: $ sudo auditctl -l | egrepgrep '(/etc/security/opasswd)' -a always,exit -F arch=b32 -F path=/etc/security/opasswd -F perm=wa -F key=identity -a always,exit -F arch=b64 -F path=/etc/security/opasswd -F perm=wa -F key=identity If the command does not return athese linelines, or the linelines isare commented out, this is a finding.

Fix text

Configure RHEL 10 to generate audit records for all account creations, modifications, disabling,to and termination events that affect "/etc/security/opasswd". Add by adding or updateupdating the following filerules systemin rule to "/etc/audit/rules.d/auditidentity.rules": -a always,exit -F arch=b32 -F path=/etc/security/opasswd -F perm=wa -Fk key=identity -a always,exit -F arch=b64 -F path=(/etc/security/opasswd -F perm=wa -Fk key=identity RestartTo load the auditrules daemonto with the followingkernel commandimmediately, foruse the changesfollowing to take effectcommand: $ sudo serviceaugenrules auditd restart--load

V-281158 in V1R3

Title

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

Check text

Verify that RHEL 10 requires a bootpassword loaderfor superuserthe passwordGRUB with2 thebootloader followingto command: $prevent sudounauthorized grepmodifications password_pbkdf2to /etc/grub2boot parameters.cfg password_pbkdf2 &ltsuperusers-accountname> ${GRUB2_PASSWORD} ToCheck verify the bootunified loaderconfiguration superuserfile accountwhere passwordthe hasGRUB been2 set and the password encrypted,is run the following commandstored: $# sudo catgrep -iw "GRUB2_PASSWORD" /boot/grub2/user.cfg GRUB2_PASSWORD=grub.pbkdf2.sha512.10000.C4E08AC72FBFF7E837FD267BFAD7AEB3D42DDC[password_hash] 2C99F2A94DD5E2E75C2DC331B719FE55D9411745F82D1B6CFD9E927D61925F9BBDD1CFAA0080E0 916F7AB46E0D.1302284FCCC52CD73BA3671C6C12C26FF50BA873293B24EE2A96EE3B57963E6D7 0C83964B473EC8F93B07FE749AA6710269E904A9B08A6BBACB00A2D242AD828 If athe "GRUB2_PASSWORD" entry does not exist, is commented out, or if the hash does not setbegin with "grub.pbkdf2.sha512", this is a finding.

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-281166 in V1R3

Check text

Verify that RHEL 10 system accounts do not have an interactive login shell. Run with the following command to list any system account (UID &lt 1000) that has an interactive shell, excluding authorized system utility accounts (root, sync, shutdown, halt): $ $ awk -F: '(($3 > 0 &lt1000& $3 &lt 1000) && $1 !~ /^(halt|sync|shutdown)$/ && $7 !~ /(nologin|false)$/) {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 IdentifyIf the listedcommand systemreturns accounts that have a shell other than nologin. 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)output, this is a finding.

Fix text

Configure RHEL 10 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 &ltuser> with the user that has a login shell. $ sudo usermod --shell /usr/sbin/nologin &ltuser> Do not perform the steps in this section on the root account. Doing so will cause the system to become inaccessible.

V-281168 in V1R3

Title

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

Check text

Verify that RHEL 10 enforces a 60180-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 60180 If the "PASS_MAX_DAYS" parameter value is greater than "60180", or is commented out, this is a finding.

Fix text

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

Discussion

Any password, no matter how complex, can eventually be cracked; therefore, passwords mustneed to be changed periodically. If the operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the operating system passwords could be compromised. Setting the password maximum age ensures users are required to periodically change their passwords. Requiring shorter password lifetimes increases the risk of users writing down the password in a convenient location subject to physical compromise.

V-281169 in V1R3

Title

RHEL 10 must, for user account passwords, have a 6180-day maximum password lifetime restriction.

Check text

Verify RHEL 10 enforces a 60180-day maximum time period for existing user account passwords with the following commands: $ sudo awk -F: '$5 > 60180 {print $1 "" "" $5}' /etc/shadow $ sudo awk -F: '$5 &lt= 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 RHEL 10 to enforce a 60180-day maximum password lifetime restriction on user account passwords. Set the 60180-day maximum password lifetime restriction with the following command: $ sudo passwd -x 60180 [user]

Discussion

Any password, no matter how complex, can eventually be cracked.; Thereforetherefore, passwords mustneed to be changed periodically. If theRHEL operating10 system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that theRHEL operating10 system passwords could be compromised.

V-281170 in V1R3

Discussion

The shorter the password, the lower the number of possible combinations that must 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 10 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, those components will not only be required but 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-281181 in V1R3

Discussion

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified; therefore, they cannot be relied on to provide confidentiality or integrity, and DODDoW data may be compromised. RHEL 10 systems using 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 use authentication that meets DODDoW requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system. Satisfies: SRG-OS-000073-GPOS-00041, SRG-OS-000120-GPOS-00061

V-281217 in V1R3

Discussion

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied on to provide confidentiality or integrity, and DODDoW data may be compromised. RHEL 10 systems using 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 use authentication that meets DODDoW requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general-purpose computing system. Satisfies: SRG-OS-000073-GPOS-00041, SRG-OS-000120-GPOS-00061

V-281219 in V1R3

Discussion

Passwords must 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. Passwords that are encrypted with a weak algorithm are no more protected than if they are kept in plain text. This setting ensures user and group account administration utilities are configured to store only encrypted representations of passwords. Additionally, the "crypt_style" configuration option ensures the use of a strong hashing algorithm that makes password cracking attacks more difficult. The default for Red Hat 10 is yescrypt. Although yescrypt is structurally built using an outer layer of SHA-256 (which is a NIST-approved algorithm), the yescrypt algorithm as a whole is not recognized or validated by the National Institute of Standards and Technology (NIST) Cryptographic Module Validation Program (CMVP).

V-281222 in V1R3

Check text

Note: If the libuser package is not installed, this requirement is not applicable. Verify RHEL 10 user and group account administration utilities are configured to store only encrypted representations of passwords with the following command: $ sudo grep crypt-i "^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.

Fix text

Configure RHEL 10 to use the SHA-512 algorithm for password hashing. Add or change the following line in the "[defaultdefaults]" section of the "/etc/libuser.conf" file: crypt_style = sha512

V-281223 in V1R3

Title

RHEL 10 must display the Standard Mandatory DODoW Notice and Consent Banner before granting local or remote access to the system via a Secure Shell (SSH) login.

Check text

Verify RHEL 10 is configured so that any SSH connection to the operating system displays the Standard Mandatory DODDoW Notice and Consent Banner before granting access to the system. Check for the location of the banner file currently being used with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '1r' | tr '1n' ' ' | xargs sudo grep -iH '^1s*banner' /etc/ssh/sshd_config.d/10-stig.conf:Banner /etc/issue If the line is commented out or the file is missing, this is a finding.

Fix text

Configure RHEL 10 to display the Standard Mandatory DODDoW Notice and Consent Banner before granting access to the system via SSH. Edit a file in "/etc/ssh/sshd_config.d" to uncomment or add the banner keyword and configure it to point to a file that will contain the login 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-281224 in V1R3

Title

RHEL 10 must display the Standard Mandatory DODoW Notice and Consent Banner before granting local or remote access to the system via a graphical user login.

Check text

Note: This requirement assumes the use of the RHEL 10 default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is not applicable. Verify RHEL 10 displays the Standard Mandatory DODDoW Notice and Consent Banner before granting access to the operating system via a graphical user login with the following command: $ gsettings get org.gnome.login-screen banner-message-text banner-message-text= 'You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.1nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:1n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.1n-At any time, the USG may inspect and seize data stored on this IS.1n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.1n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.1n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. ' Note: The "1n " characters are for formatting only. They will not be displayed on the graphical interface. If the banner does not match the Standard Mandatory DODDoW Notice and Consent Banner exactly, this is a finding.

Fix text

Configure RHEL 10 to display the Standard Mandatory DODDoW Notice and Consent Banner before granting access to the system. Add the following lines to the [org/gnome/login-screen] section of the "/etc/dconf/db/local.d/01-banner-message": banner-message-text='You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.1nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:1n-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.1n-At any time, the USG may inspect and seize data stored on this IS.1n-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.1n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.1n-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. ' Note: The "1n " characters are for formatting only. They will not be displayed on the graphical interface. Run the following command to update the database: $ sudo dconf update

Discussion

Display of a standardized and approved use notification before granting access to the operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via login interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with applicable DODDoW policy. Use the following verbiage for operating systems that can accommodate banners of 1300 characters: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Satisfies: SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088

V-281225 in V1R3

Title

RHEL 10 must display the Standard Mandatory DODoW Notice and Consent Banner before granting local or remote access to the system via a command line user login.

Check text

Verify RHEL 10 displays the Standard Mandatory DODDoW Notice and Consent Banner before granting access to the operating system via a command line login screen with the following command: $ cat /etc/issue If the banner is set correctly, it will return the following text: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." If the banner text does not match the Standard Mandatory DODDoW Notice and Consent Banner exactly, or the line is commented out, this is a finding.

Fix text

Configure RHEL 10 to display the Standard Mandatory DODDoW Notice and Consent Banner before granting access to the system via command line login. Edit the "/etc/issue" file to replace the default text with the Standard Mandatory DODDoW Notice and Consent Banner. The DODDoW-required text is: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."

V-281227 in V1R3

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. OpenSSH uses the first occurrence of a keyword it sees, and drop-in files are read in lexicographical order at the start of the configuration. Red Hat recommends using drop-in files rather than changing base configuration files. Satisfies: SRG-OS-000105-GPOS-00052, SRG-OS-000106-GPOS-00053, SRG-OS-000107-GPOS-00054, SRG-OS-000108-GPOS-00055

V-281263 in V1R3

Discussion

This requirement applies to wireless peripheral technologies (e.g., wireless mice, keyboards, displays, etc.) used with RHEL 10 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. Even though some wireless peripherals, such as mice and pointing devices, do not ordinarily carry information that must be protected, modification of communications with these wireless peripherals may be used to compromise the RHEL 10 operating system. Satisfies: SRG-OS-000095-GPOS-00049, SRG-OS-000300-GPOS-00118

V-281289 in V1R3

Discussion

This requirement applies to wireless peripheral technologies (e.g., wireless mice, keyboards, displays, etc.) used with RHEL 10 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. Even though some wireless peripherals, such as mice and pointing devices, do not ordinarily carry information that must be protected, modification of communications with these wireless peripherals may be used to compromise the RHEL 10 operating system. Satisfies: SRG-OS-000299-GPOS-00117, SRG-OS-000300-GPOS-00118, SRG-OS-000424-GPOS-00188, SRG-OS-000481-GPOS-00481

V-281290 in V1R3

Title

RHEL 10 must automatically exit interactive command shell user sessions after 150 minutes of inactivity.

V-281295 in V1R3

Check text

Verify RHEL 10 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 10 to disable the "CtrlAltDelBurstAction". Update theby adding it to a drop file in a "/etc/systemd/system.conf.d/" configuration file: If asno followsdrop 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-281298 in V1R3

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

V-281305 in V1R3

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

V-281306 in V1R3

Title

RHEL 10 must disable file system automount function unless required.

Check text

Note: If the "autofs" service is not installed, this requirement is not applicable. Verify RHEL 10 is configured so that the file system automount function has been disabled with the following command: $ systemctl is-enabled autofs maskednot-found If the returned value is not "masked", "disabled", or "not-found" and is not documented as an operational requirement with the information system security officer, this is a finding.

Discussion

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

V-281323 in V1R3

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 public key infrastructure (PKI) is an example of multifactor authentication. Satisfies: SRG-OS-000375-GPOS-00160, SRG-OS-000105-GPOS-00052, SRG-OS-000106-GPOS-00053, SRG-OS-000107-GPOS-00054, SRG-OS-000108-GPOS-00055

V-281324 in V1R3

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 10 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, SRG-OS-000705-GPOS-00150

V-281325 in V1R3

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-281327 in V1R3

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-281328 in V1R3

Check text

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

Fix text

Configure RHEL 10, for PKI-based authentication, to validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor. Obtain a valid copy of the DODDoW root CA file from the PKI CA certificate bundle from cyber.mil and copy the DoD_PKE_CA_chainDoW_PKE_CA_chain.pem into the following file: /etc/sssd/pki/sssd_auth_ca_db.pem

V-281329 in V1R3

Check text

Verify RHEL 10 is securely comparing internal information system clocks at least every 24 hours with an NTP server with the following commands: $ sudo grep maxpoll /etc/chrony.conf server 0.us.pool.ntp.mil iburst maxpoll 16 If the "maxpoll" option is set to a number greater than 16, or the line is missing or commented out, this is a finding. Verify the "chrony.conf" file is configured to an authoritative DODDoW time source by running the following command: $ sudo grep -i server /etc/chrony.conf server 0.us.pool.ntp.mil If the parameter "server" is not set or is not set to an authoritative DODDoW time source, 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. Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network. Depending on the infrastructure being used, the "pool" directive may not be supported. Authoritative time sources include the United States Naval Observatory (USNO) time servers, a time server designated for the appropriate DODDoW network (NIPRNet/SIPRNet), and/or the Global Positioning System (GPS). Satisfies: SRG-OS-000355-GPOS-00143, SRG-OS-000356-GPOS-00144, SRG-OS-000359-GPOS-00146, SRG-OS-000785-GPOS-00250

V-281336 in V1R3