What changed in Oracle Linux 8 SCAP Benchmark V2R10V2R10 changes

Check text

AND - The Oracle Linux 8 minor version is supported. textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: pattern pattern match "^\\s*Oracle Linux Server release 8\\.(\\d+)\\b"; path equals "/etc"; filename equals "oracle-release"; instance greater than or equal "1" state textfilecontent54_state: subexpression greater than or equal "0" Verify the version of the operating system is vendor supported. Check the version of the operating system with the following command: $ sudo cat /etc/oracle-release Oracle Linux Server release 8.10 If the release is not supported by the vendor, this is a finding.

Discussion

Configuring the operating system to implement organization-wideorganizationwide security implementation guides and security checklists verifies compliance with federal standards and establishes a common security baseline across the DODDoW that reflects the most restrictive security posture consistent with operational requirements. Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture and/or functionality of the system. Security-related parameters are parameters impacting the security state of the system, including the parameters required to satisfy other security control requirements. Security-related parameters include, for example, registry settings; account, file, and directory permission settings; and settings for functions, ports, protocols, services, and remote connections. End Of Life dates for Oracle Linux 8 releases are as follows: Current end of Premier Support for Oracle Linux 8 is July 2029. Current end of Extended Support for Oracle Linux 8 is July 2032. Each minor version reaches end of life when the new version is released.

V-248521 in V2R10

Check text

AND - /proc/sys/crypto/fips_enabled is set to 1 textfilecontent54_test (check: all, existence: all_exist) object textfilecontent54_object: filepath equals "/proc/sys/crypto/fips_enabled"; pattern pattern match "^(\\d+)$"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "1" - /boot/grub2/grubenv:kernelopts contains fips=1 textfilecontent54_test (check: all, existence: all_exist) object textfilecontent54_object: filepath equals "/boot/grub2/grubenv"; pattern pattern match "^\\s*kernelopts=[^#]*fips=(\\d+)\\b"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "1" Verify the operating system implements DOD-approved encryption to protect the confidentiality of remote access sessions. Check to see if FIPS mode is enabled with the following command: $ fips-mode-setup --check FIPS mode is enabled If FIPS mode is "enabled", check if the kernel boot parameter is configured for FIPS mode with the following command: $ sudo grub2-editenv list | grep fips kernelopts=...fips=1 If the kernel boot parameter is configured to use FIPS mode, check to see if the system is in FIPS mode with the following command: $ sudo cat /proc/sys/crypto/fips_enabled 1 If FIPS mode is not "enabled", the kernel boot parameter is not configured for FIPS mode, or the system does not have a value of "1" for "fips_enabled" in "/proc/sys/crypto", this is a finding.

Fix text

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

V-248524 in V2R10

Check text

AND - /etc/rsyslog.conf: auth.* is configured to be logged textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: - /etc/rsyslog.conf: authpriv.* is configured to be logged textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: - /etc/rsyslog.conf: daemon.* is configured to be logged textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: Verify that OL 8 monitors all remote access methods. Check that remote access methods are being logged by running the following command: $ sudo grep -E '(auth\.\*|authpriv\.\*|daemon\.\*)' /etc/rsyslog.conf /etc/rsyslog.d/*.conf /etc/rsyslog.conf:auth.*;authpriv.*;daemon.* /var/log/secure If "auth.*", "authpriv.*", or "daemon.*" are not configured to be logged, this is a finding.

Discussion

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

V-248530 in V2R10

Check text

AND - /etc/login.defs:ENCRYPT_METHOD >= SHA512 textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: filepath equals "/etc/login.defs"; pattern pattern match "^\\s*ENCRYPT_METHOD\\s+([^#\\r\\n]*)"; instance greater than or equal "1" state textfilecontent54_state: subexpression equals "SHA512" Verify that the shadow password suite configuration is set to encrypt passwords with a FIPS 140-2 approved cryptographic hashing algorithm. Check the hashing algorithm that is being used to hash passwords with the following command: $ sudo cat /etc/login.defs | grep -i crypt ENCRYPT_METHOD SHA512 If "ENCRYPT_METHOD" does not equal SHA512 or greater, this is a finding.

Discussion

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

V-248533 in V2R10

Check text

AND - /etc/pam.d/system-auth:password includes pam_unix.so sha512 textfilecontent54_test (check: all, existence: only_one_exists) object textfilecontent54_object: pattern pattern match "^[ \\t]*password[ \\t]+sufficient[ \\t]+pam_unix\\.so(?:[ \\t]+|(?:[ \\t][^#\\r\\f\\n]+[ \\t]))sha512(?:[ \\t]|$)"; path equals "/etc/pam.d"; filename equals "system-auth"; instance greater than or equal "1" Verify that the "pam_unix.so" module is configured to use sha512. Check that pam_unix.so module is configured to use sha512 in /etc/pam.d/system-auth with the following command: $ sudo grep password /etc/pam.d/system-auth | grep pam_unix password sufficient pam_unix.so sha512 If "sha512" is missing, or is commented out, this is a finding.

Discussion

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

V-248543 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: $ sudo grep password /etc/pam.d/password-auth | grep pam_unix password sufficient pam_unix.so sha512 If "sha512" is missing, or is commented out, this is a finding.

Discussion

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

V-248544 in V2R10

Check text

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

Discussion

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

V-248545 in V2R10

Check text

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

Discussion

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied on to provide confidentiality or integrity, and DoDDoW data may be compromised. OL 8 systems using encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. Currently, Kerberos does not use FIPS 140-2 cryptography. FIPS 140-2 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.

V-248546 in V2R10

Check text

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

Discussion

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied on to provide confidentiality or integrity, and DoDDoW data may be compromised. OL 8 systems using encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. Currently, Kerberos does not use FIPS 140-2 cryptography. FIPS 140-2 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.

V-248547 in V2R10

Check text

AND - Every /etc/yum.repos.d/*.repo:[{reponame}] has a gpgcheck entry set to 1. textfilecontent54_test (check: all, existence: all_exist) object textfilecontent54_object: pattern pattern match "^\\s*\\[[^]]+\\]\\s*\\n(?:[^[]*\\n)*"; path equals "/etc/yum.repos.d"; filename pattern match "\\.repo$"; instance greater than or equal "1" state textfilecontent54_state: text pattern match "\\n\\s*gpgcheck\\s*=\\s*(True|1|yes)\\s*(\\n|$)" - No /etc/yum.repos.d/*.repo:[{reponame}] has a gpgcheck entry set to 0. textfilecontent54_test (check: none satisfy, existence: all_exist) object textfilecontent54_object: pattern pattern match "^\\s*\\[[^]]+\\]\\s*\\n(?:[^[]*\\n)*"; path equals "/etc/yum.repos.d"; filename pattern match "\\.repo$"; instance greater than or equal "1" state textfilecontent54_state: text pattern match "\\n\\s*gpgcheck\\s*=\\s*(False|0|no)\\s*(\\n|$)" Check that YUM verifies the signature of packages from a repository prior to install with the following command: $ sudo grep gpgcheck /etc/yum.repos.d/*.repo gpgcheck=1 If "gpgcheck" is not set to "1", or if options are missing or commented out, ask the system administrator (SA) how the certificates for patches and other operating system components are verified. If there is no process to validate certificates that is approved by the organization, this is a finding.

Discussion

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

V-248574 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 "^(True|1|yes)$" Verify the operating system prevents the installation of patches, service packs, device drivers, or operating system components from a repository without verification that they have been digitally signed using a certificate that is recognized and approved by the organization. Determine if YUM is configured to perform a signature check on local packages with the following command: $ sudo grep -i localpkg_gpgcheck /etc/dnf/dnf.conf localpkg_gpgcheck=1 If "localpkg_gpgcheck" is not set to "1", "True", or "yes", is commented out, or is missing from "/etc/dnf/dnf.conf", this is a finding.

Discussion

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

V-248575 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 OL 8 is configured to restrict access to the kernel message buffer with the following commands: Check the status of the kernel.dmesg_restrict kernel parameter. $ 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

V-248579 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 OL 8 is configured to prevent kernel profiling by nonprivileged users with the following commands: Check the status of the kernel.perf_event_paranoid kernel parameter. $ 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

V-248580 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 the operating system requires re-authentication when using the "sudo" command to elevate privileges. $ sudo grep -Eir 'timestamp_timeout' /etc/sudoers /etc/sudoers.d* /etc/sudoers:Defaults timestamp_timeout=0 If conflicting results are returned, this is a finding. If "timestamp_timeout" is set to a negative number, is commented out, or no results are returned, this is a finding.

Fix text

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

V-248585 in V2R10

Check text

AND - package openssl-pkcs11 is installed rpminfo_test (check: all, existence: all_exist) object rpminfo_object: name equals "openssl-pkcs11" Verify the operating system has the package required for multifactor authentication installed with the following command: $ sudo yum list installed openssl-pkcs11 openssl-pkcs11.x86_64 0.4.8-2.el8 @anaconda If the "openssl-pkcs11" package is not installed, ask the administrator to indicate what type of multifactor authentication is being used and what packages are installed to support it. If there is no evidence of multifactor authentication being used, this is a finding.

Discussion

Using an authentication device, such as a DODDoW 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. A privileged account is defined as an information system account with authorizations of a privileged user. Remote access is access to DODDoW nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management).

V-248586 in V2R10

Check text

AND - rsyslog is enabled systemdunitproperty_test (check: all, existence: at_least_one_exists) object systemdunitproperty_object: property equals "UnitFileState"; unit equals "rsyslog.service" state systemdunitproperty_state: value equals "enabled" - rsyslog is active systemdunitproperty_test (check: all, existence: at_least_one_exists) object systemdunitproperty_object: property equals "ActiveState"; unit equals "rsyslog.service" state systemdunitproperty_state: value equals "active" Verify the rsyslog service is enabled and active with the following commands: $ sudo systemctl is-enabled rsyslog enabled $ sudo systemctl is-active rsyslog active If the service is not enabled and active, this is a finding.

Discussion

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

V-248615 in V2R10

Title

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

Check text

AND - 0 -lt /etc/loginoval:mil.defsdisa.stig.ind:PASS_MAX_DAYS -le 60tst:25804100 textfilecontent54_test (check: all, existence: at_least_one_exists) object textfilecontent54_object: filepath equals "/etc/login.defs"; pattern pattern match "^[ \\st]*PASS_MAX_DAYS[ \\st]+(\\d*+)[ \\t]*$"; instance greater than or equal "1" state textfilecontent54_state: subexpression lessgreater than or equal "600" state textfilecontent54_state: subexpression greaterless than "0" Verifyor thatequal OL 8 enforces a 60-day maximum password lifetime for new user accounts by running the following command: $ sudo grep -i pass_max_days /etc/login.defs PASS_MAX_DAYS 60 If the "PASS_MAX_DAYS180" parameter value is greater than "60", or commented out, this is a finding.

Fix text

Configure OL 8 to enforce a 60180-day maximum password lifetime. AddModify or modify the following line in the "/etc/login.defs" file: to set the "PASS_MAX_DAYS" parameter to 180 or greater: PASS_MAX_DAYS 60180

V-248696 in V2R10

Title

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

Check text

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

Fix text

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

V-248697 in V2R10

Check text

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

Discussion

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

V-248712 in V2R10

Check text

AND - Audit invocations of /bin/kmod. Use file watch syntax. textfilecontent54_test (check: all, existence: ) object textfilecontent54_object: filepath equals "/etc/audit/audit.rules"; pattern pattern match "^\\s*-w\\s+/usr/bin/kmod(?:\\s+-p\\s+[rwa]*x[rwa]*)?(?:\\s+(?:-k\\s+|-F\\s+key=)\\S+)*\\s*$"; instance greater than or equal "1" Verify OL 8 is configured to audit the execution of the module management program "kmod" by running the following command: $ sudo grep "/usr/bin/kmod" /etc/audit/audit.rules -w /usr/bin/kmod -p x -k modules If the command does not return a line or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

Discussion

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

V-248800 in V2R10

Check text

AND - Audit modifications to /var/log/lastlog textfilecontent54_test (check: all, existence: all_exist) object textfilecontent54_object: filepath equals "/etc/audit/audit.rules"; pattern pattern match "^\\s*-w\\s+/var/log/lastlog(\\s+-p\\s*([rx]*w[rx]*a[rx]*|[rx]*a[rx]*w[rx]*))?(\\s+(-k\\s+|-F\\s+key=)\\w+)?\\s*$"; instance greater than or equal "1" Verify OL 8 generates an audit record for any attempted modifications to the "lastlog" file by running the following command to check the file system rules in "/etc/audit/audit.rules": $ sudo grep -w lastlog /etc/audit/audit.rules -w /var/log/lastlog -p wa -k logins If the command does not return a line or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

Discussion

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

V-248802 in V2R10

Title

OL 8 must allow only the Informationinformation Systemsystem Securitysecurity Managermanager (ISSM) (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.

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 the "/etc/audit/rules.d/*.rules" and "/etc/audit/auditd.conf" file have a mode of "0640" or less permissive by using the following commands: $ sudo ls -al /etc/audit/rules.d/*.rules -rw-r----- 1 root root 1280 Feb 16 17:09 audit.rules $ sudo ls -al /etc/audit/auditd.conf -rw-r----- 1 root root 621 Sep 22 2014 auditd.conf If the "/etc/audit/rules.d/*.rules" or "/etc/audit/auditd.conf" files have a mode more permissive than "0640", 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" filesfile to have a mode of "0640"0600 with the following commands: $ sudo chmodfind 0640 /etc/audit/rules.d/ -type f -name "*.rules" -exec chmod 0600 {} + $ sudo chmod 06400600 /etc/audit/audit.rules $ sudo chmod 0600 /etc/audit/auditd.conf

V-248806 in V2R10

Check text

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

Discussion

Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. Minimizing the exposure of the server functionality of the chrony daemon diminishes the attack surface. Note that USNO offers authenticated NTP service to DODDoW and U.S. Government agencies operating on the NIPR and SIPR networks. Visit https://www.usno.navy.mil/USNO/time/ntp/DODDoW-customers for more information.

V-248821 in V2R10

Check text

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

Discussion

Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. Minimizing the exposure of the server functionality of the chrony daemon diminishes the attack surface. Note that USNO offers authenticated NTP service to DODDoW and U.S. Government agencies operating on the NIPR and SIPR networks. Visit https://www.usno.navy.mil/USNO/time/ntp/DODDoW-customers for more information.

V-248822 in V2R10

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" Verify - OLautofs.service 8UnitFileState disablesis themasked abilityif toit automount devicesexists. systemdunitproperty_test Determine(check: ifall, theexistence: automounterany_exist) object servicesystemdunitproperty_object: isproperty activeequals with"UnitFileState"; theunit followingequals command: "autofs.service" state $systemdunitproperty_state: sudovalue systemctlequals status autofs "masked" - autofs.service -UnitFileState Automountsis filesystemsdisabled onif demandit exists. Loaded: systemdunitproperty_test loaded (/usr/lib/systemd/system/autofs.service;check: disabled)all, Activeexistence: inactive (deadany_exist) object Ifsystemdunitproperty_object: theproperty equals "autofsUnitFileState"; statusunit isequals set to "activeautofs.service" state thissystemdunitproperty_state: isvalue aequals finding."disabled"

Fix text

Configure OL 8 to disable the ability to automount devices. TurnThe off"autofs" theservice automountcan servicebe disabled with the following commandscommand: $ sudo systemctl stopmask autofs $--now sudo systemctl disable autofs.service

Discussion

VerifyWithout theidentifying operatingdevices, systemunidentified disablesor theunknown ability to automount devices. may Determinebe ifintroduced, automounterthereby servicefacilitating ismalicious active with the following command: $ sudo systemctl status autofs autofsactivity.service - Automounts filesystems on demand Loaded: loaded (/usr/lib/systemd/system/autofs.service; disabled) Active:Peripherals inactiveinclude, (dead)but are Ifnot thelimited "autofs" status is set to, "active"such anddevices is not documented with the information system security officer (ISSO) as anflash operational requirementdrives, thisexternal isstorage, aand findingprinters.

V-248836 in V2R10

Check text

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

Discussion

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

V-248840 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 commands: $ sudo systemctl is-active firewalld active If the "firewalld" package is not "active", ask the System Administrator if another firewall is installed. If no firewall is installed and active this is a finding.

Discussion

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

V-248841 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" If the device or operating system does not have a Bluetooth adapter installed, this requirement is not applicable. This requirement is not applicable to mobile devices (smartphones and tablets), where the use of Bluetooth is a local AO decision. Determine if Bluetooth is disabled with the following command: $ sudo grep -r bluetooth /etc/modprobe.d /etc/modprobe.d/bluetooth.conf:install bluetooth /bin/false If the command does not return any output or the line is commented out and the collaborative computing device has not been authorized for use, this is a finding. Verify the operating system disables the ability to use Bluetooth with the following command: $ sudo grep -r bluetooth /etc/modprobe.d | grep -i "blacklist" | grep -v "^#" blacklist bluetooth If the command does not return any output or the output is not "blacklist bluetooth", and use of Bluetooth is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Discussion

Without protection of communications with wireless peripherals, confidentiality and integrity may be compromised because unprotected communications can be intercepted and read, altered, or used to compromise the OL 8 operating system. This requirement applies to wireless peripheral technologies (e.g., wireless mice, keyboards, displays, etc.) used with OL 8 systems. Wireless peripherals (e.g., Wi-Fi/Bluetooth/IR keyboards, mice, and pointing devices and Near Field Communications [NFC]) present a unique challenge by creating an open, unsecured port on a computer. Wireless peripherals must meet DoDDoW requirements for wireless data transmission and be approved for use by the Authorizing Official (AO). Although 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 OL 8 operating system. Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of communications with wireless peripherals can be accomplished by physical means (e.g., employing physical barriers to wireless radio frequencies) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, logical means (cryptography) do not have to be employed, and vice versa. If the wireless peripheral is only passing telemetry data, encryption of the data may not be required.

V-248843 in V2R10

Check text

AND OR - /etc/ssh/sshd_config:RekeyLimit maximum data and time are greater than zero. textfilecontent54_test (check: all, existence: all_exist) object textfilecontent54_object: pattern pattern match "^\\s*RekeyLimit\\s+\\d+[kmg]?\\s+\\d+[smdhw]?\\s*"; instance greater than or equal "1"; filepath equals "/etc/ssh/sshd_config"; behaviors equals "" state textfilecontent54_state: text pattern match "^(?i)\\s*RekeyLimit\\s+[1-9][0-9]*[kmg]?\\s+([1-9][0-9]*[smhdw]?)+\\s*$" 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:RekeyLimit maximum data and time are greater than zero. textfilecontent54_test (check: all, existence: all_exist) object textfilecontent54_object: pattern pattern match "^\\s*RekeyLimit\\s+\\d+[kmg]?\\s+\\d+[smdhw]?\\s*"; path equals "/etc/ssh/sshd_config.d"; filename pattern match "^.+\\.conf$"; instance greater than or equal "1"; behaviors equals "" state textfilecontent54_state: text pattern match "^(?i)\\s*RekeyLimit\\s+[1-9][0-9]*[kmg]?\\s+([1-9][0-9]*[smhdw]?)+\\s*$" Verify the SSH server is configured to force frequent session key renegotiation 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*rekeylimit' RekeyLimit 1G 1h If "RekeyLimit" does not have a maximum data amount and maximum time defined or is missing or commented out, this is a finding. If conflicting results are returned, this is a finding.

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. Session key regeneration limits the chances of a session key becoming compromised.

V-248868 in V2R10

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 OL 8 is not configured to 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:CtrlAltDelBurstAction=none If the "CtrlAltDelBurstAction" is not set to "none" or is commented out or missing, this is a finding.

Fix text

Configure OL 8 to disable the CtrlAltDelBurstAction by adding it to a dropconfig file in athe "/etc/systemd/system.conf.d/" configurationdrop-in filedirectory: If no drop-in filedirectory exists, create one with the following command: $ sudo mkdir -p /etc/systemd/system.conf.d && sudotouch vi /etc/systemd/system.conf.d/55-CtrlAltDel-BurstAction.conf EditAdd the filesetting to contain the setting by adding the following textfile: $ echo "CtrlAltDelBurstAction=none Reload" the>> daemon for this change to take effect/etc/systemd/system. $ sudo systemctl daemonconf.d/55-reloadCtrlAltDel-BurstAction.conf

V-248871 in V2R10

Title

OL 8 must disable access to the network "bpf" syscall from unonprivileged processes.

Check text

AND - kernel.unprivileged_bpf_disabled setting in kernel is '1'. sysctl_test (check: all, existence: all_exist) object sysctl_object: name equals "kernel.unprivileged_bpf_disabled" state sysctl_state: value equals "1" Verify that OL 8 prevents privilege escalation through the kernel by disabling access to the bpf system call with the following commands: $ sysctl kernel.unprivileged_bpf_disabled kernel.unprivileged_bpf_disabled = 1 If the returned line does not have a value of "1", or a line is not returned, this is a finding.

V-248889 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 OL 8 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-257259 in V2R10

Title

The OL 8 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. Verify the ciphers in the systemwide SSH configuration file using 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. OL 8 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-283448 in V2R10

Title

The OL 8 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. OL 8 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-283449 in V2R10

Title

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

Check text

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

V-283451 in V2R10