What changed in Oracle Linux 8 STIG V2R10V2R10 changes

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

Verify the operating system implements DODDoW-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

Title

OL 8 must display the Standard Mandatory DODoW Notice and Consent Banner before granting local or remote access to the system via an SSH logon.

Check text

Verify that any publicly accessible 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 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' banner /etc/issue This command will return the banner keyword and the name of the file that contains the SSH banner (in this case "/etc/issue"). If the line is commented out, this is a finding. If conflicting results are returned, this is a finding. View the file specified by the banner keyword to check that it matches the text of the Standard Mandatory DODDoW Notice and Consent Banner: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." If the system does not display a graphical logon banner or the banner does not match the Standard Mandatory DODDoW Notice and Consent Banner, this is a finding. If the text in the file does not match the Standard Mandatory DODDoW Notice and Consent Banner, this is a finding.

Fix text

Configure OL 8 to display the Standard Mandatory DODDoW Notice and Consent Banner before granting access to the system via the SSH. Edit the "/etc/ssh/sshd_config" file to uncomment the banner keyword and configure it to point to a file that will contain the logon banner (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor). An example configuration line is: banner /etc/issue Either create the file containing the banner or replace the text in the file 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." The SSH service must be restarted for changes to take effect.

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 logon 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." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't." Satisfies: SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088

V-248526 in V2R10

Title

OL 8 must display the Standard Mandatory DoDW Notice and Consent Banner before granting local or remote access to the system via a graphical user logon.

Check text

Note: This requirement assumes the use of the OL 8 default graphical user interface, Gnome Shell. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Verify OL 8 displays the Standard Mandatory DoDDoW Notice and Consent Banner before granting access to the operating system via a graphical user logon. Check that the operating system displays the exact Standard Mandatory DoDDoW Notice and Consent Banner text with the command: $ sudo grep banner-message-text /etc/dconf/db/local.d/* 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 OL 8 to display the Standard Mandatory DoDDoW Notice and Consent Banner before granting access to the system. Note: If the system does not have a graphical user interface installed, this requirement is Not Applicable. 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 logon 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-248528 in V2R10

Title

OL 8 must display the Standard Mandatory DoDW Notice and Consent Banner before granting local or remote access to the system via a command line user logon.

Check text

Verify OL 8 displays the Standard Mandatory DoDDoW Notice and Consent Banner before granting access to the operating system via a command line user logon. Check that OL 8 displays a banner at the command line login screen with the following command: $ sudo 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, this is a finding.

Fix text

Configure OL 8 to display the Standard Mandatory DoDDoW Notice and Consent Banner before granting access to the system via command line logon. 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."

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 logon 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-248529 in V2R10

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

Verify OL 8, for PKI-based authentication, has valid certificates by constructing a certification path (which includes status information) to an accepted trust anchor. Note: If the system administrator (SA) demonstrates the use of an approved alternate multifactor authentication method, this requirement is Not Applicable. Check that the system has a valid DODDoW 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 installed in the "/etc/sssd/pki/sssd_auth_ca_db.pem" location, this is a finding.

Fix text

Configure OL 8, 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 at cyber.mil and copy it into the following file: /etc/sssd/pki/sssd_auth_ca_db.pem

V-248531 in V2R10

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

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

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

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

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

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

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.

V-248551 in V2R10

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

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

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

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

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 from more than one file location, this is a finding. If "timestamp_timeout" is set to a value other than "0" (including negative numbernumbers), is commented out, or nois resultsmissing are returnedentirely, 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

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

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. OL 8 includes multiple options for configuring certificate status checking but for this requirement focuses on the system security services daemon (sssd). By default, sssd performs Online Certificate Status Protocol (OCSP) checking and certificate verification using a sha256 digest function. Satisfies: SRG-OS-000375-GPOS-00160, SRG-OS-000377-GPOS-00162

V-248587 in V2R10

Discussion

The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access. The DoDDoW has mandated the use of the Common Access Card (CAC) to support identity management and personal authentication for systems covered under Homeland Security Presidential Directive (HSPD) 12, as well as making the CAC a primary component of layered protection for national security systems.

V-248588 in V2R10

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

Discussion

If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary accounts must be set upon account creation. Temporary accounts are established as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. If temporary accounts are used, OL 8 must be configured to automatically terminate these types of accounts after a DoDDoW-defined time period of 72 hours. To address access requirements, many OL 8 operating systems may be integrated with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements.

V-248651 in V2R10

Title

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

Check text

Verify that OL 8 enforces a 60180-day maximum password lifetime for new user accounts by running the following command: $ sudo grep -iPASS_MAX_DAYS pass_max_days /etc/login.defs PASS_MAX_DAYS 60180 If the "PASS_MAX_DAYS" parameter value is greater than "60180", is not set, or is 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

Verify the maximum time period for existing passwords is restricted to 60180 days 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 non-compliant accounts to enforce a 6180-day maximum password lifetime restriction. $ sudo chage -M 6180 [user]

V-248697 in V2R10

Discussion

Using an authentication device, such as a Common Access Card (CAC) or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device. 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 card and the DODDoW CAC. There are various methods of implementing multifactor authentication for OL 8. Some methods include a local system multifactor account mapping or joining the system to a domain and using an idM server or Microsoft Windows Active Directory server. Any of these methods will require that the client operating system handle the multifactor authentication correctly. Satisfies: SRG-OS-000105-GPOS-00052, SRG-OS-000106-GPOS-00053, SRG-OS-000107-GPOS-00054, SRG-OS-000108-GPOS-00055

V-248702 in V2R10

Fix text

Configure OL 8 to disable access to the system for account identifiers with 35 days of inactivity. Add/Modify the following line to "/etc/pam.d/system-auth" above the "pam_unix.so" statement: auth required pam_lastlog.so inactive=35 Note: The DODDoW recommendation is 35 days, but a lower value is acceptable.

V-248703 in V2R10

Fix text

Configure OL 8 to disable access to the system for account identifiers with 35 days of inactivity. Add/Modify the following line to "/etc/pam.d/password-auth" above the "pam_unix.so" statement: auth required pam_lastlog.so inactive=35 Note: The DODDoW recommendation is 35 days, but a lower value is acceptable.

V-248704 in V2R10

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

Verify that "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.d/99-cron-stig.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 byinto inspectingthe cron logging facility with the "/etc/rsyslog.conf"following orcommand: $ "/etc/rsyslog.d/*.conf"logger files-p cron.info "STIG-TEST-CRON-LOGGING" LookCheck forif it successfully wrote to the dedicated log file with the following entrycommand: *.*$ sudo grep "STIG-TEST-CRON-LOGGING" /var/log/messages cron 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 "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 The rsyslog daemon must be restarted for the changes to take effect: $ sudo systemctl restart rsyslog.service

V-248723 in V2R10

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

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. From "Pam_Faillock man" pages: Note the default directory that "pam_faillock" uses is usually cleared on system boot so the access will be reenabled after system reboot. If that is undesirable, a different tally directory must be set with the "dir" option. 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-248801 in V2R10

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

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-248803 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

Verify that the "files in the directory /etc/audit/rules.d/*.rules" and "/etc/audit/auditd.conf" file have a mode of "0640"0600 or less permissive bywith using the following commandscommand: $ sudo lsfind -al /etc/audit/rules.d/ -type f -name "*.rules" -rw-r-----exec 1stat root-c root"%a 1280%n" Feb{} 161; 600 17:09 /etc/audit/rules.d/audit.rules $ Verify sudothat lsthe -alfiles /etc/audit/audit.rules and /etc/audit/auditd.conf have -rw-r-----a 1mode rootof root0600 621or Sepless 22permissive 2014with auditd.confthe following command: If $ thesudo stat -c "%a %n" /etc/audit/audit.rules /etc/audit/auditd.dconf 600 /*etc/audit/audit.rules" 600 or "/etc/audit/auditd.conf" If any of the audit configuration files have a mode more permissive than "06400600", 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

Title

OL 8 must compare internal information system clocks at least every 24 hours with a server synchronized to an authoritative time source, such as the United States Naval Observatory (USNO) time servers, or a time server designated for the appropriate DODDoW network (NIPRNet/SIPRNet), and/or the Global Positioning System (GPS).

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. Organizations should consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints). If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis. Time stamps generated by the operating system include date and time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. OL 8 uses the "timedatectl" command to view the status of the "systemd-timesyncd.service". The "timedatectl" status will display the local time, UTC, and the offset from UTC. Note that USNO offers authenticated NTP service to DODDoW and U.S. Government agencies operating on the NIPR and SIPR networks. Visit https://www.usno.navy.mil/USNO/time/ntp/dodDoW-customers for more information. Satisfies: SRG-OS-000355-GPOS-00143, SRG-OS-000356-GPOS-00144, SRG-OS-000359-GPOS-00146

V-248820 in V2R10

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

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

Note: If the "autofs" service is not installed, this requirement is not applicable. Verify OL 8 disables the ability to automount devices. Determine if the automounter service is active with the following command: $ sudo systemctl status autofs autofs.service is- Automounts filesystems on demand Loaded: loaded (/usr/lib/systemd/system/enabled autofs.service; disabled) Active: inactive (dead) masked If the "autofs"returned statusvalue is setnot to"masked", "activedisabled", or "not-found", this is a finding.

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

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

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

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

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. Satisfies: SRG-OS-000299-GPOS-00117, SRG-OS-000300-GPOS-00118, SRG-OS-000481-GPOS-000481

V-248842 in V2R10

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

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

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 -iRiHs "^1s*CtrlAltDelBurstAction" /etc/systemd/system.conf /etc/systemd/system.conf.d/*.conf /etc/systemd/system.conf.d/55-CtrlAltDel-BurstAction.conf: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.

V-248889 in V2R10

Check text

Note: For cloud hosted systems where "ClientAliveInterval" (V-248553) is configured, this setting is not applicable. 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

Check text

Verify OL 8 implementsis DOD-approvedset encryption to protectuse thea confidentialityDoW-approved ofFIPS remote140-3-compliant accesssystemwide sessionscryptographic policy. ShowVerify the configuredcurrent systemwide cryptographic crypto-policy bywith running the following command: $ sudo update-crypto-policies --show FIPS If the mainsystemwide crypto-policy name is not set to "FIPS", this is a finding. IfVerify the AD-SUPPORTcurrent subpolicyminimum modulecrypto-policy isconfiguration includedwith (e.g.,the "FIPSfollowing commands:AD $ sudo grep -SUPPORT"),E and'rsa_size|hash' Active/etc/crypto-policies/state/CURRENT.pol hash Directory= supportSHA2-256 isSHA2-384 notSHA2-512 documentedSHA2-224 asSHA3-256 anSHA3-384 operationalSHA3-512 min_rsa_size requirement= with2048 If the information"hash" systemvalues securitydo officernot (ISSO)include at least the following FIPS 140-3-compliant algorithms, this is a finding.: If"SHA2-256 theSHA2-384 NOSHA2-ENFORCE512 SHA2-EMS224 subpolicySHA3-256 moduleSHA3-384 isSHA3-512" If includedany (e.g.,algorithms include "FIPS:NO-ENFORCE-EMSSHA1") or a hash value less than "224", andthis notis enforcinga EMSfinding. If the "min_rsa_size" is not documentedset asto ana operationalvalue requirementof withat theleast ISSO"2048", this is a finding. If anythese othercommands subpolicydo modulenot isreturn includedany output, this is a finding.

Fix text

Configure OL 8 to implementuse DODa DoW-approved encryptionFIPS by140-3-compliant followingsystemwide thecryptographic steps below:policy. ToSet enable strict FIPS compliance, the fips=1systemwide kernelcrypto-policy optionto mustFIPS bewith added to the kernelfollowing bootcommand: $ parameterssudo duringupdate-crypto-policies system--set installation so that key generation is done with FIPS-approved Setting algorithmssystem andpolicy continuousto monitoring tests in place.FIPS EnableNote: FIPSSystemwide modecrypto-policies afterare installationapplied (noton strictapplication FIPS-compliant)startup. withIt theis followingrecommended command: $to sudorestart fips-mode-setup --enable Reboot the system for the changeschange of policies to fully take effectplace.

V-283446 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.

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.

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.

V-283451 in V2R10

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/opensshserver.config file.

V-283457 in V2R10

Title

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

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/opensshserver.config file.

V-283458 in V2R10