Canonical Ubuntu 20.04 LTS Security Technical Implementation Guide

Version

UBTU-20-010016

Vuln IDs

V-238209

Rule IDs

SV-238209r653802_rule

Setting the most restrictive default permissions ensures that when new accounts are created they do not have unnecessary access.

Checks: C-41419r653800_chk

Verify the Ubuntu operating system defines default permissions for all authenticated users in such a way that the user can read and modify only their own files. Verify the Ubuntu operating system defines default permissions for all authenticated users with the following command: $ grep -i "umask" /etc/login.defs UMASK 077 If the "UMASK" variable is set to "000", this is a finding with the severity raised to a CAT I. If the value of "UMASK" is not set to "077", is commented out, or is missing completely, this is a finding.

Fix: F-41378r653801_fix

Configure the system to define the default permissions for all authenticated users in such a way that the user can read and modify only their own files. Edit the "UMASK" parameter in the "/etc/login.defs" file to match the example below: UMASK 077

b

The Ubuntu operating system must implement smart card logins for multifactor authentication for local and network access to privileged and non-privileged accounts.

IA-2 - Medium - CCI-000765 - V-238210 - SV-238210r917810_rule

RMF Control

IA-2

Severity

M

CCI

CCI-000765

Version

UBTU-20-010033

Vuln IDs

V-238210

Rule IDs

SV-238210r917810_rule

Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased. Multifactor authentication requires using two or more factors to achieve authentication. Factors include: 1) something a user knows (e.g., password/PIN); 2) something a user has (e.g., cryptographic identification device, token); and 3) something a user is (e.g., biometric). A privileged account is defined as an information system account with authorizations of a privileged user. Network access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, or the internet). The DoD CAC with DoD-approved PKI is an example of multifactor authentication. Satisfies: SRG-OS-000105-GPOS-00052, SRG-OS-000106-GPOS-00053, SRG-OS-000107-GPOS-00054, SRG-OS-000108-GPOS-00055

Checks: C-41420r917809_chk

Verify the Ubuntu operating system has the packages required for multifactor authentication installed with the following commands: $ dpkg -l | grep libpam-pkcs11 ii libpam-pkcs11 0.6.8-4 amd64 Fully featured PAM module for using PKCS#11 smart cards If the "libpam-pkcs11" package is not installed, this is a finding. Verify the sshd daemon allows public key authentication with the following command: $ grep -ir pubkeyauthentication /etc/ssh/sshd_config* PubkeyAuthentication yes If this option is set to "no" or is missing, this is a finding. If conflicting results are returned, this is a finding.

Fix: F-41379r653804_fix

Configure the Ubuntu operating system to use multifactor authentication for network access to accounts. Add or update "pam_pkcs11.so" in "/etc/pam.d/common-auth" to match the following line: auth [success=2 default=ignore] pam_pkcs11.so Set the sshd option "PubkeyAuthentication yes" in the "/etc/ssh/sshd_config" file.

b

The Ubuntu operating system must use strong authenticators in establishing nonlocal maintenance and diagnostic sessions.

MA-4 - Medium - CCI-000877 - V-238211 - SV-238211r877395_rule

RMF Control

MA-4

Severity

M

CCI

CCI-000877

Version

UBTU-20-010035

Vuln IDs

V-238211

Rule IDs

SV-238211r877395_rule

Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, PKI where certificates are stored on a token protected by a password, passphrase, or biometric.

Checks: C-41421r858518_chk

Verify the Ubuntu operating system is configured to use strong authenticators in the establishment of nonlocal maintenance and diagnostic maintenance. Verify that "UsePAM" is set to "yes" in "/etc/ssh/sshd_config: $ grep -r ^UsePAM /etc/ssh/sshd_config* UsePAM yes If "UsePAM" is not set to "yes", this is a finding. If conflicting results are returned, this is a finding.

Fix: F-41380r653807_fix

Configure the Ubuntu operating system to use strong authentication when establishing nonlocal maintenance and diagnostic sessions. Add or modify the following line to /etc/ssh/sshd_config: UsePAM yes

b

The Ubuntu operating system must immediately terminate all network connections associated with SSH traffic after a period of inactivity.

MA-4 - Medium - CCI-000879 - V-238212 - SV-238212r858521_rule

RMF Control

MA-4

Severity

M

CCI

CCI-000879

Version

UBTU-20-010036

Vuln IDs

V-238212

Rule IDs

SV-238212r858521_rule

Automatic session termination addresses the termination of user-initiated logical sessions in contrast to the termination of network connections that are associated with communications sessions (i.e., network disconnect). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational information system. Such user sessions can be terminated (and thus terminate user access) without terminating network sessions. Session termination terminates all processes associated with a user's logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use. This capability is typically reserved for specific Ubuntu operating system functionality where the system owner, data owner, or organization requires additional assurance.

Checks: C-41422r858520_chk

Verify that all network connections associated with SSH traffic automatically terminate after a period of inactivity. Verify the "ClientAliveCountMax" variable is set in the "/etc/ssh/sshd_config" file by performing the following command: $ sudo grep -ir clientalivecountmax /etc/ssh/sshd_config* ClientAliveCountMax 1 If "ClientAliveCountMax" is not set, is not set to "1", or is commented out, this is a finding. If conflicting results are returned, this is a finding.

Fix: F-41381r653810_fix

Configure the Ubuntu operating system to automatically terminate inactive SSH sessions after a period of inactivity. Modify or append the following line in the "/etc/ssh/sshd_config" file, replacing "[Count]" with a value of 1: ClientAliveCountMax 1 Restart the SSH daemon for the changes to take effect: $ sudo systemctl restart sshd.service

b

The Ubuntu operating system must immediately terminate all network connections associated with SSH traffic at the end of the session or after 10 minutes of inactivity.

SC-10 - Medium - CCI-001133 - V-238213 - SV-238213r858523_rule

RMF Control

SC-10

Severity

M

CCI

CCI-001133

Version

UBTU-20-010037

Vuln IDs

V-238213

Rule IDs

SV-238213r858523_rule

Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element. Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, and de-allocating networking assignments at the application level if multiple application sessions are using a single operating system-level network connection. This does not mean that the operating system terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.

Checks: C-41423r858522_chk

Verify that all network connections associated with SSH traffic are automatically terminated at the end of the session or after 10 minutes of inactivity. Verify the "ClientAliveInterval" variable is set to a value of "600" or less by performing the following command: $ sudo grep -ir clientalive /etc/ssh/sshd_config* ClientAliveInterval 600 If "ClientAliveInterval" does not exist, is not set to a value of "600" or less in "/etc/ssh/sshd_config", or is commented out, this is a finding. If conflicting results are returned, this is a finding.

Fix: F-41382r653813_fix

Configure the Ubuntu operating system to automatically terminate all network connections associated with SSH traffic at the end of a session or after a 10-minute period of inactivity. Modify or append the following line in the "/etc/ssh/sshd_config" file replacing "[Interval]" with a value of "600" or less: ClientAliveInterval 600 Restart the SSH daemon for the changes to take effect: $ sudo systemctl restart sshd.service

b

The Ubuntu operating system must display the Standard Mandatory DoD Notice and Consent Banner before granting any local or remote connection to the system.

AC-8 - Medium - CCI-000048 - V-238214 - SV-238214r858525_rule

RMF Control

AC-8

Severity

M

CCI

CCI-000048

Version

UBTU-20-010038

Vuln IDs

V-238214

Rule IDs

SV-238214r858525_rule

Display of a standardized and approved use notification before granting access to the publicly accessible 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 DoD 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-000228-GPOS-00088, SRG-OS-000023-GPOS-00006

Checks: C-41424r858524_chk

Verify the Ubuntu operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the Ubuntu operating system via an SSH logon with the following command: $ grep -ir banner /etc/ssh/sshd_config* /etc/ssh/sshd_config:Banner /etc/issue.net The command will return the banner option along with the name of the file that contains the SSH banner. If the line is commented out, this is a finding. If conflicting results are returned, this is a finding. Verify the specified banner file matches the Standard Mandatory DoD Notice and Consent Banner exactly: $ cat /etc/issue.net "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 DoD Notice and Consent Banner exactly, this is a finding.

Fix: F-41383r653816_fix

Set the parameter Banner in "/etc/ssh/sshd_config" to point to the "/etc/issue.net" file: $ sudo sed -i '/^Banner/d' /etc/ssh/sshd_config $ sudo sed -i '$aBanner /etc/issue.net' /etc/ssh/sshd_config Either create the file containing the banner or replace the text in the file with the Standard Mandatory DoD Notice and Consent Banner. The DoD 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." Restart the SSH daemon for the changes to take effect and then signal the SSH server to reload the configuration file: $ sudo systemctl -s SIGHUP kill sshd

c

The Ubuntu operating system must use SSH to protect the confidentiality and integrity of transmitted information.

SC-8 - High - CCI-002418 - V-238215 - SV-238215r916422_rule

RMF Control

SC-8

Severity

H

CCI

CCI-002418

Version

UBTU-20-010042

Vuln IDs

V-238215

Rule IDs

SV-238215r916422_rule

Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered. This requirement applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). 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 organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000425-GPOS-00189, SRG-OS-000426-GPOS-00190

Checks: C-41425r653818_chk

Verify the SSH package is installed with the following command: $ sudo dpkg -l | grep openssh ii openssh-client 1:7.6p1-4ubuntu0.1 amd64 secure shell (SSH) client, for secure access to remote machines ii openssh-server 1:7.6p1-4ubuntu0.1 amd64 secure shell (SSH) server, for secure access from remote machines ii openssh-sftp-server 1:7.6p1-4ubuntu0.1 amd64 secure shell (SSH) sftp server module, for SFTP access from remote machines If the "openssh" server package is not installed, this is a finding. Verify the "sshd.service" is loaded and active with the following command: $ sudo systemctl status sshd.service | egrep -i "(active|loaded)" Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2019-01-24 22:52:58 UTC; 1 weeks 3 days ago If "sshd.service" is not active or loaded, this is a finding.

Fix: F-41384r653819_fix

Install the "ssh" meta-package on the system with the following command: $ sudo apt install ssh Enable the "ssh" service to start automatically on reboot with the following command: $ sudo systemctl enable sshd.service ensure the "ssh" service is running $ sudo systemctl start sshd.service

b

The Ubuntu operating system must configure the SSH daemon to use Message Authentication Codes (MACs) employing FIPS 140-2 approved cryptographic hashes to prevent the unauthorized disclosure of information and/or detect changes to information during transmission.

AC-17 - Medium - CCI-001453 - V-238216 - SV-238216r877465_rule

RMF Control

AC-17

Severity

M

CCI

CCI-001453

Version

UBTU-20-010043

Vuln IDs

V-238216

Rule IDs

SV-238216r877465_rule

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Encrypting information for transmission protects information from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic hash functions which have common application in digital signatures, checksums, and message authentication codes. Satisfies: SRG-OS-000424-GPOS-00188, SRG-OS-000250-GPOS-00093, SRG-OS-000393-GPOS-00173

Checks: C-41426r858526_chk

Verify the SSH daemon is configured to only use MACs that employ FIPS 140-2 approved ciphers with the following command: $ grep -ir macs /etc/ssh/sshd_config* MACs hmac-sha2-512,hmac-sha2-256 If any ciphers other than "hmac-sha2-512" or "hmac-sha2-256" are listed, the order differs from the example above, or the returned line is commented out, this is a finding. If conflicting results are returned, this is a finding.

Fix: F-41385r653822_fix

Configure the Ubuntu operating system to allow the SSH daemon to only use MACs that employ FIPS 140-2 approved ciphers. Add the following line (or modify the line to have the required value) to the "/etc/ssh/sshd_config" file (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): MACs hmac-sha2-512,hmac-sha2-256 Restart the SSH daemon for the changes to take effect: $ sudo systemctl reload sshd.service

b

The Ubuntu operating system must configure the SSH daemon to use FIPS 140-2 approved ciphers to prevent the unauthorized disclosure of information and/or detect changes to information during transmission.

AC-17 - Medium - CCI-000068 - V-238217 - SV-238217r877465_rule

RMF Control

AC-17

Severity

M

CCI

CCI-000068

Version

UBTU-20-010044

Vuln IDs

V-238217

Rule IDs

SV-238217r877465_rule

Without cryptographic integrity protections, information can be altered by unauthorized users without detection. Remote access (e.g., RDP) is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Encrypting information for transmission protects information from unauthorized disclosure and modification. Cryptographic mechanisms implemented to protect information integrity include, for example, cryptographic hash functions which have common application in digital signatures, checksums, and message authentication codes. By specifying a cipher list with the order of ciphers being in a "strongest to weakest" orientation, the system will automatically attempt to use the strongest cipher for securing SSH connections. Satisfies: SRG-OS-000424-GPOS-00188, SRG-OS-000033-GPOS-00014, SRG-OS-000394-GPOS-00174

Checks: C-41427r858528_chk

Verify the SSH daemon is configured to only implement FIPS-approved algorithms by running the following command: $ grep -r 'Ciphers' /etc/ssh/sshd_config* Ciphers aes256-ctr,aes192-ctr,aes128-ctr If any ciphers other than "aes256-ctr", "aes192-ctr", or "aes128-ctr" are listed, the order differs from the example above, the "Ciphers" keyword is missing, or the returned line is commented out, this is a finding. If conflicting results are returned, this is a finding.

Fix: F-41386r653825_fix

Configure the Ubuntu operating system to allow the SSH daemon to only implement FIPS-approved algorithms. Add the following line (or modify the line to have the required value) to the "/etc/ssh/sshd_config" file (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): Ciphers aes256-ctr,aes192-ctr,aes128-ctr Restart the SSH daemon for the changes to take effect: $ sudo systemctl restart sshd.service

c

The Ubuntu operating system must not allow unattended or automatic login via SSH.

CM-6 - High - CCI-000366 - V-238218 - SV-238218r877377_rule

RMF Control

CM-6

Severity

H

CCI

Version

UBTU-20-010047

Vuln IDs

V-238218

Rule IDs

SV-238218r877377_rule

Failure to restrict system access to authenticated users negatively impacts Ubuntu operating system security.

Checks: C-41428r858530_chk

Verify that unattended or automatic login via SSH is disabled with the following command: $ egrep -r '(Permit(.*?)(Passwords|Environment))' /etc/ssh/sshd_config PermitEmptyPasswords no PermitUserEnvironment no If "PermitEmptyPasswords" or "PermitUserEnvironment" keywords are not set to "no", are missing completely, or are commented out, this is a finding. If conflicting results are returned, this is a finding.

Fix: F-41387r653828_fix

Configure the Ubuntu operating system to allow the SSH daemon to not allow unattended or automatic login to the system. Add or edit the following lines in the "/etc/ssh/sshd_config" file: PermitEmptyPasswords no PermitUserEnvironment no Restart the SSH daemon for the changes to take effect: $ sudo systemctl restart sshd.service

c

The Ubuntu operating system must be configured so that remote X connections are disabled, unless to fulfill documented and validated mission requirements.

CM-6 - High - CCI-000366 - V-238219 - SV-238219r858533_rule

RMF Control

CM-6

Severity

H

CCI

Version

UBTU-20-010048

Vuln IDs

V-238219

Rule IDs

SV-238219r858533_rule

The security risk of using X11 forwarding is that the client's X11 display server may be exposed to attack when the SSH client requests forwarding. A System Administrator may have a stance in which they want to protect clients that may expose themselves to attack by unwittingly requesting X11 forwarding, which can warrant a ''no'' setting. X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user's X11 authorization database) can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring if the ForwardX11Trusted option is also enabled. If X11 services are not required for the system's intended function, they should be disabled or restricted as appropriate to the system’s needs.

Checks: C-41429r858532_chk

Verify that X11Forwarding is disabled with the following command: $ grep -ir x11forwarding /etc/ssh/sshd_config* | grep -v "^#" X11Forwarding no If the "X11Forwarding" keyword is set to "yes" and is not documented with the Information System Security Officer (ISSO) as an operational requirement or is missing, this is a finding. If conflicting results are returned, this is a finding.

Fix: F-41388r653831_fix

Edit the "/etc/ssh/sshd_config" file to uncomment or add the line for the "X11Forwarding" keyword and set its value to "no" (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): X11Forwarding no Restart the SSH daemon for the changes to take effect: $ sudo systemctl restart sshd.service

b

The Ubuntu operating system SSH daemon must prevent remote hosts from connecting to the proxy display.

CM-6 - Medium - CCI-000366 - V-238220 - SV-238220r858535_rule

RMF Control

CM-6

Severity

M

CCI

Version

UBTU-20-010049

Vuln IDs

V-238220

Rule IDs

SV-238220r858535_rule

When X11 forwarding is enabled, there may be additional exposure to the server and client displays if the sshd proxy display is configured to listen on the wildcard address. By default, sshd binds the forwarding server to the loopback address and sets the hostname part of the DISPLAY environment variable to localhost. This prevents remote hosts from connecting to the proxy display.

Checks: C-41430r858534_chk

Verify the SSH daemon prevents remote hosts from connecting to the proxy display. Check the SSH X11UseLocalhost setting with the following command: $ sudo grep -ir x11uselocalhost /etc/ssh/sshd_config* X11UseLocalhost yes If the "X11UseLocalhost" keyword is set to "no", is missing, or is commented out, this is a finding. If conflicting results are returned, this is a finding.

Fix: F-41389r653834_fix

Configure the SSH daemon to prevent remote hosts from connecting to the proxy display. Edit the "/etc/ssh/sshd_config" file to uncomment or add the line for the "X11UseLocalhost" keyword and set its value to "yes" (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): X11UseLocalhost yes Restart the SSH daemon for the changes to take effect: $ sudo systemctl restart sshd.service

a

The Ubuntu operating system must enforce password complexity by requiring that at least one upper-case character be used.

IA-5 - Low - CCI-000192 - V-238221 - SV-238221r653838_rule

RMF Control

IA-5

Severity

L

CCI

CCI-000192

Version

UBTU-20-010050

Vuln IDs

V-238221

Rule IDs

SV-238221r653838_rule

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Checks: C-41431r653836_chk

Verify the Ubuntu operating system enforces password complexity by requiring that at least one upper-case character be used. Determine if the field "ucredit" is set in the "/etc/security/pwquality.conf" file with the following command: $ grep -i "ucredit" /etc/security/pwquality.conf ucredit=-1 If the "ucredit" parameter is greater than "-1" or is commented out, this is a finding.

Fix: F-41390r653837_fix

Add or update the "/etc/security/pwquality.conf" file to contain the "ucredit" parameter: ucredit=-1

a

The Ubuntu operating system must enforce password complexity by requiring that at least one lower-case character be used.

IA-5 - Low - CCI-000193 - V-238222 - SV-238222r653841_rule

RMF Control

IA-5

Severity

L

CCI

CCI-000193

Version

UBTU-20-010051

Vuln IDs

V-238222

Rule IDs

SV-238222r653841_rule

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Checks: C-41432r653839_chk

Verify the Ubuntu operating system enforces password complexity by requiring that at least one lower-case character be used. Determine if the field "lcredit" is set in the "/etc/security/pwquality.conf" file with the following command: $ grep -i "lcredit" /etc/security/pwquality.conf lcredit=-1 If the "lcredit" parameter is greater than "-1" or is commented out, this is a finding.

Fix: F-41391r653840_fix

Add or update the "/etc/security/pwquality.conf" file to contain the "lcredit" parameter: lcredit=-1

a

The Ubuntu operating system must enforce password complexity by requiring that at least one numeric character be used.

IA-5 - Low - CCI-000194 - V-238223 - SV-238223r653844_rule

RMF Control

IA-5

Severity

L

CCI

CCI-000194

Version

UBTU-20-010052

Vuln IDs

V-238223

Rule IDs

SV-238223r653844_rule

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Checks: C-41433r653842_chk

Verify the Ubuntu operating system enforces password complexity by requiring that at least one numeric character be used. Determine if the field "dcredit" is set in the "/etc/security/pwquality.conf" file with the following command: $ grep -i "dcredit" /etc/security/pwquality.conf dcredit=-1 If the "dcredit" parameter is greater than "-1" or is commented out, this is a finding.

Fix: F-41392r653843_fix

Configure the Ubuntu operating system to enforce password complexity by requiring that at least one numeric character be used. Add or update the "/etc/security/pwquality.conf" file to contain the "dcredit" parameter: dcredit=-1

a

The Ubuntu operating system must require the change of at least 8 characters when passwords are changed.

IA-5 - Low - CCI-000195 - V-238224 - SV-238224r653847_rule

RMF Control

IA-5

Severity

L

CCI

CCI-000195

Version

UBTU-20-010053

Vuln IDs

V-238224

Rule IDs

SV-238224r653847_rule

If the operating system allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks. The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different. If the password length is an odd number then number of changed characters must be rounded up. For example, a password length of 15 characters must require the change of at least 8 characters.

Checks: C-41434r653845_chk

Verify the Ubuntu operating system requires the change of at least eight characters when passwords are changed. Determine if the field "difok" is set in the "/etc/security/pwquality.conf" file with the following command: $ grep -i "difok" /etc/security/pwquality.conf difok=8 If the "difok" parameter is less than "8" or is commented out, this is a finding.

Fix: F-41393r653846_fix

Configure the Ubuntu operating system to require the change of at least eight characters when passwords are changed. Add or update the "/etc/security/pwquality.conf" file to include the "difok=8" parameter: difok=8

b

The Ubuntu operating system must enforce a minimum 15-character password length.

IA-5 - Medium - CCI-000205 - V-238225 - SV-238225r832942_rule

RMF Control

IA-5

Severity

M

CCI

CCI-000205

Version

UBTU-20-010054

Vuln IDs

V-238225

Rule IDs

SV-238225r832942_rule

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

Checks: C-41435r832941_chk

Verify the pwquality configuration file enforces a minimum 15-character password length by running the following command: $ grep -i minlen /etc/security/pwquality.conf minlen=15 If "minlen" parameter value is not "15" or higher or is commented out, this is a finding.

Fix: F-41394r653849_fix

Configure the Ubuntu operating system to enforce a minimum 15-character password length. Add or modify the "minlen" parameter value to the "/etc/security/pwquality.conf" file: minlen=15

a

The Ubuntu operating system must enforce password complexity by requiring that at least one special character be used.

IA-5 - Low - CCI-001619 - V-238226 - SV-238226r653853_rule

RMF Control

IA-5

Severity

L

CCI

CCI-001619

Version

UBTU-20-010055

Vuln IDs

V-238226

Rule IDs

SV-238226r653853_rule

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor in determining how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Special characters are those characters that are not alphanumeric. Examples include: ~ ! @ # $ % ^ *.

Checks: C-41436r653851_chk

Determine if the field "ocredit" is set in the "/etc/security/pwquality.conf" file with the following command: $ grep -i "ocredit" /etc/security/pwquality.conf ocredit=-1 If the "ocredit" parameter is greater than "-1" or is commented out, this is a finding.

Fix: F-41395r653852_fix

Configure the Ubuntu operating system to enforce password complexity by requiring that at least one special character be used. Add or update the following line in the "/etc/security/pwquality.conf" file to include the "ocredit=-1" parameter: ocredit=-1

b

The Ubuntu operating system must prevent the use of dictionary words for passwords.

CM-6 - Medium - CCI-000366 - V-238227 - SV-238227r653856_rule

RMF Control

CM-6

Severity

M

CCI

Version

UBTU-20-010056

Vuln IDs

V-238227

Rule IDs

SV-238227r653856_rule

If the Ubuntu operating system allows the user to select passwords based on dictionary words, then this increases the chances of password compromise by increasing the opportunity for successful guesses and brute-force attacks.

Checks: C-41437r653854_chk

Verify the Ubuntu operating system uses the "cracklib" library to prevent the use of dictionary words with the following command: $ grep dictcheck /etc/security/pwquality.conf dictcheck=1 If the "dictcheck" parameter is not set to "1" or is commented out, this is a finding.

Fix: F-41396r653855_fix

Configure the Ubuntu operating system to prevent the use of dictionary words for passwords. Add or update the following line in the "/etc/security/pwquality.conf" file to include the "dictcheck=1" parameter: dictcheck=1

b

The Ubuntu operating system must be configured so that when passwords are changed or new passwords are established, pwquality must be used.

CM-6 - Medium - CCI-000366 - V-238228 - SV-238228r653859_rule

RMF Control

CM-6

Severity

M

CCI

Version

UBTU-20-010057

Vuln IDs

V-238228

Rule IDs

SV-238228r653859_rule

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. "pwquality" enforces complex password construction configuration and has the ability to limit brute-force attacks on the system.

Checks: C-41438r653857_chk

Verify the Ubuntu operating system has the "libpam-pwquality" package installed by running the following command: $ dpkg -l libpam-pwquality ii libpam-pwquality:amd64 1.4.0-2 amd64 PAM module to check password strength If "libpam-pwquality" is not installed, this is a finding. Verify that the operating system uses "pwquality" to enforce the password complexity rules. Verify the pwquality module is being enforced by the Ubuntu operating system by running the following command: $ grep -i enforcing /etc/security/pwquality.conf enforcing = 1 If the value of "enforcing" is not "1" or the line is commented out, this is a finding. Check for the use of "pwquality" with the following command: $ cat /etc/pam.d/common-password | grep requisite | grep pam_pwquality password requisite pam_pwquality.so retry=3 If no output is returned or the line is commented out, this is a finding. If the value of "retry" is set to "0" or greater than "3", this is a finding.

Fix: F-41397r653858_fix

Configure the operating system to use "pwquality" to enforce password complexity rules. Install the "pam_pwquality" package by using the following command: $ sudo apt-get install libpam-pwquality -y Add the following line to "/etc/security/pwquality.conf" (or modify the line to have the required value): enforcing = 1 Add the following line to "/etc/pam.d/common-password" (or modify the line to have the required value): password requisite pam_pwquality.so retry=3 Note: The value of "retry" should be between "1" and "3".

b

The Ubuntu operating system, for PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.

IA-5 - Medium - CCI-000185 - V-238229 - SV-238229r653862_rule

RMF Control

IA-5

Severity

M

CCI

CCI-000185

Version

UBTU-20-010060

Vuln IDs

V-238229

Rule IDs

SV-238229r653862_rule

Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted. A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement.

Checks: C-41439r653860_chk

Verify the Ubuntu operating system, for PKI-based authentication, has valid certificates by constructing a certification path to an accepted trust anchor. Determine which pkcs11 module is being used via the "use_pkcs11_module" in "/etc/pam_pkcs11/pam_pkcs11.conf" and then ensure "ca" is enabled in "cert_policy" with the following command: $ sudo grep use_pkcs11_module /etc/pam_pkcs11/pam_pkcs11.conf | awk '/pkcs11_module opensc {/,/}/' /etc/pam_pkcs11/pam_pkcs11.conf | grep cert_policy | grep ca cert_policy = ca,signature,ocsp_on; If "cert_policy" is not set to "ca" or the line is commented out, this is a finding.

Fix: F-41398r653861_fix

Configure the Ubuntu operating system, for PKI-based authentication, to validate certificates by constructing a certification path to an accepted trust anchor. Determine which pkcs11 module is being used via the "use_pkcs11_module" in "/etc/pam_pkcs11/pam_pkcs11.conf" and ensure "ca" is enabled in "cert_policy". Add or update the "cert_policy" to ensure "ca" is enabled: cert_policy = ca,signature,ocsp_on; If the system is missing an "/etc/pam_pkcs11/" directory and an "/etc/pam_pkcs11/pam_pkcs11.conf", find an example to copy into place and modify accordingly at "/usr/share/doc/libpam-pkcs11/examples/pam_pkcs11.conf.example.gz".

b

The Ubuntu operating system must implement multifactor authentication for remote access to privileged accounts in such a way that one of the factors is provided by a device separate from the system gaining access.

IA-2 - Medium - CCI-001948 - V-238230 - SV-238230r853410_rule

RMF Control

IA-2

Severity

M

CCI

CCI-001948

Version

UBTU-20-010063

Vuln IDs

V-238230

Rule IDs

SV-238230r853410_rule

Using an authentication device, such as a 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 DoD Common Access Card. A privileged account is defined as an information system account with authorizations of a privileged user. Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. 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).

Checks: C-41440r653863_chk

Verify the Ubuntu operating system has the packages required for multifactor authentication installed with the following commands: $ dpkg -l | grep libpam-pkcs11 ii libpam-pkcs11 0.6.8-4 amd64 Fully featured PAM module for using PKCS#11 smart cards If the "libpam-pkcs11" package is not installed, this is a finding.

Fix: F-41399r653864_fix

Configure the Ubuntu operating system to implement multifactor authentication by installing the required packages. Install the "libpam-pkcs11" package on the system with the following command: $ sudo apt install libpam-pkcs11

b

The Ubuntu operating system must accept Personal Identity Verification (PIV) credentials.

IA-2 - Medium - CCI-001953 - V-238231 - SV-238231r853411_rule

RMF Control

IA-2

Severity

M

CCI

CCI-001953

Version

UBTU-20-010064

Vuln IDs

V-238231

Rule IDs

SV-238231r853411_rule

The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access. DoD has mandated the use of the 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.

Checks: C-41441r653866_chk

Verify the Ubuntu operating system accepts PIV credentials. Verify the "opensc-pcks11" package is installed on the system with the following command: $ dpkg -l | grep opensc-pkcs11 ii opensc-pkcs11:amd64 0.15.0-1Ubuntu1 amd64 Smart card utilities with support for PKCS#15 compatible cards If the "opensc-pcks11" package is not installed, this is a finding.

Fix: F-41400r653867_fix

Configure the Ubuntu operating system to accept PIV credentials. Install the "opensc-pkcs11" package using the following command: $ sudo apt-get install opensc-pkcs11

b

The Ubuntu operating system must electronically verify Personal Identity Verification (PIV) credentials.

IA-2 - Medium - CCI-001954 - V-238232 - SV-238232r853412_rule

RMF Control

IA-2

Severity

M

CCI

CCI-001954

Version

UBTU-20-010065

Vuln IDs

V-238232

Rule IDs

SV-238232r853412_rule

The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access. DoD has mandated the use of the 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.

Checks: C-41442r653869_chk

Verify the Ubuntu operating system electronically verifies PIV credentials. Verify that certificate status checking for multifactor authentication is implemented with the following command: $ sudo grep use_pkcs11_module /etc/pam_pkcs11/pam_pkcs11.conf | awk '/pkcs11_module opensc {/,/}/' /etc/pam_pkcs11/pam_pkcs11.conf | grep cert_policy | grep ocsp_on cert_policy = ca,signature,ocsp_on; If "cert_policy" is not set to "ocsp_on", or the line is commented out, this is a finding.

Fix: F-41401r653870_fix

Configure the Ubuntu operating system to do certificate status checking for multifactor authentication. Modify all of the "cert_policy" lines in "/etc/pam_pkcs11/pam_pkcs11.conf" to include "ocsp_on".

b

The Ubuntu operating system for PKI-based authentication, must implement a local cache of revocation data in case of the inability to access revocation information via the network.

IA-5 - Medium - CCI-001991 - V-238233 - SV-238233r880870_rule

RMF Control

IA-5

Severity

M

CCI

CCI-001991

Version

UBTU-20-010066

Vuln IDs

V-238233

Rule IDs

SV-238233r880870_rule

Without configuring a local cache of revocation data, there is the potential to allow access to users who are no longer authorized (users with revoked certificates).

Checks: C-41443r653872_chk

Verify the Ubuntu operating system, for PKI-based authentication, uses local revocation data when unable to access it from the network. Verify that "crl_offline" or "crl_auto" is part of the "cert_policy" definition in "/etc/pam_pkcs11/pam_pkcs11.conf" using the following command: # sudo grep cert_policy /etc/pam_pkcs11/pam_pkcs11.conf | grep -E -- 'crl_auto|crl_offline' cert_policy = ca,signature,ocsp_on,crl_auto; If "cert_policy" is not set to include "crl_auto" or "crl_offline", this is a finding.

Fix: F-41402r880869_fix

Configure the Ubuntu operating system, for PKI-based authentication, to use local revocation data when unable to access the network to obtain it remotely. Add or update the "cert_policy" option in "/etc/pam_pkcs11/pam_pkcs11.conf" to include "crl_auto" or "crl_offline". cert_policy = ca,signature,ocsp_on, crl_auto; If the system is missing an "/etc/pam_pkcs11/" directory and an "/etc/pam_pkcs11/pam_pkcs11.conf", find an example to copy into place and modify accordingly at "/usr/share/doc/libpam-pkcs11/examples/pam_pkcs11.conf.example.gz".

a

The Ubuntu operating system must prohibit password reuse for a minimum of five generations.

IA-5 - Low - CCI-000196 - V-238234 - SV-238234r832945_rule

RMF Control

IA-5

Severity

L

CCI

CCI-000196

Version

UBTU-20-010070

Vuln IDs

V-238234

Rule IDs

SV-238234r832945_rule

Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. If the information system or application allows the user to consecutively reuse their password when that password has exceeded its defined lifetime, the end result is a password that is not changed as per policy requirements. Satisfies: SRG-OS-000077-GPOS-00045, SRG-OS-000073-GPOS-00041

Checks: C-41444r832943_chk

Verify the Ubuntu operating system prevents passwords from being reused for a minimum of five generations by running the following command: $ grep -i remember /etc/pam.d/common-password password [success=1 default=ignore] pam_unix.so obscure sha512 shadow remember=5 rounds=5000 If the "remember" parameter value is not greater than or equal to "5", is commented out, or is not set at all, this is a finding.

Fix: F-41403r832944_fix

Configure the Ubuntu operating system to prevent passwords from being reused for a minimum of five generations. Add or modify the "remember" parameter value to the following line in "/etc/pam.d/common-password" file: password [success=1 default=ignore] pam_unix.so obscure sha512 shadow remember=5 rounds=5000

a

The Ubuntu operating system must automatically lock an account until the locked account is released by an administrator when three unsuccessful logon attempts have been made.

AC-7 - Low - CCI-000044 - V-238235 - SV-238235r853414_rule

RMF Control

AC-7

Severity

L

CCI

CCI-000044

Version

UBTU-20-010072

Vuln IDs

V-238235

Rule IDs

SV-238235r853414_rule

By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account. Satisfies: SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005

Checks: C-41445r802381_chk

Verify that the Ubuntu operating system utilizes the "pam_faillock" module with the following command: $ grep faillock /etc/pam.d/common-auth auth [default=die] pam_faillock.so authfail auth sufficient pam_faillock.so authsucc If the pam_faillock.so module is not present in the "/etc/pam.d/common-auth" file, this is a finding. Verify the pam_faillock module is configured to use the following options: $ sudo egrep 'silent|audit|deny|fail_interval| unlock_time' /etc/security/faillock.conf audit silent deny = 3 fail_interval = 900 unlock_time = 0 If the "silent" keyword is missing or commented out, this is a finding. If the "audit" keyword is missing or commented out, this is a finding. If the "deny" keyword is missing, commented out, or set to a value greater than 3, this is a finding. If the "fail_interval" keyword is missing, commented out, or set to a value greater than 900, this is a finding. If the "unlock_time" keyword is missing, commented out, or not set to 0, this is a finding.

Fix: F-41404r802382_fix

Configure the Ubuntu operating system to utilize the "pam_faillock" module. Edit the /etc/pam.d/common-auth file. Add the following lines below the "auth" definition for pam_unix.so: auth [default=die] pam_faillock.so authfail auth sufficient pam_faillock.so authsucc Configure the "pam_faillock" module to use the following options: Edit the /etc/security/faillock.conf file and add/update the following keywords and values: audit silent deny = 3 fail_interval = 900 unlock_time = 0

b

The Ubuntu operating system must be configured so that the script which runs each 30 days or less to check file integrity is the default one.

SI-6 - Medium - CCI-002699 - V-238236 - SV-238236r853415_rule

RMF Control

SI-6

Severity

M

CCI

CCI-002699

Version

UBTU-20-010074

Vuln IDs

V-238236

Rule IDs

SV-238236r853415_rule

Without verification of the security functions, security functions may not operate correctly and the failure may go unnoticed. Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. Notifications provided by information systems include, for example, electronic alerts to System Administrators, messages to local computer consoles, and/or hardware indications, such as lights. This requirement applies to the Ubuntu operating system performing security function verification/testing and/or systems and environments that require this functionality.

Checks: C-41446r653881_chk

Verify that the Advanced Intrusion Detection Environment (AIDE) default script used to check file integrity each 30 days or less is unchanged. Download the original aide-common package in the /tmp directory: $ cd /tmp; apt download aide-common Fetch the SHA1 of the original script file: $ dpkg-deb --fsys-tarfile /tmp/aide-common_*.deb | tar -xO ./usr/share/aide/config/cron.daily/aide | sha1sum 32958374f18871e3f7dda27a58d721f471843e26 - Compare with the SHA1 of the file in the daily or monthly cron directory: $ sha1sum /etc/cron.{daily,monthly}/aide 2>/dev/null 32958374f18871e3f7dda27a58d721f471843e26 /etc/cron.daily/aide If there is no AIDE script file in the cron directories, or the SHA1 value of at least one file in the daily or monthly cron directory does not match the SHA1 of the original, this is a finding.

Fix: F-41405r653882_fix

The cron file for AIDE is fairly complex as it creates the report. This file is installed with the "aide-common" package, and the default can be restored by copying it from the package: Download the original package to the /tmp dir: $ cd /tmp; apt download aide-common Extract the aide script to its original place: $ dpkg-deb --fsys-tarfile /tmp/aide-common_*.deb | sudo tar -x ./usr/share/aide/config/cron.daily/aide -C / Copy it to the cron.daily directory: $ sudo cp -f /usr/share/aide/config/cron.daily/aide /etc/cron.daily/aide

a

The Ubuntu operating system must enforce a delay of at least 4 seconds between logon prompts following a failed logon attempt.

CM-6 - Low - CCI-000366 - V-238237 - SV-238237r653886_rule

RMF Control

CM-6

Severity

L

CCI

Version

UBTU-20-010075

Vuln IDs

V-238237

Rule IDs

SV-238237r653886_rule

Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account.

Checks: C-41447r653884_chk

Verify the Ubuntu operating system enforces a delay of at least 4 seconds between logon prompts following a failed logon attempt with the following command: $ grep pam_faildelay /etc/pam.d/common-auth auth required pam_faildelay.so delay=4000000 If the line is not present or is commented out, this is a finding.

Fix: F-41406r653885_fix

Configure the Ubuntu operating system to enforce a delay of at least 4 seconds between logon prompts following a failed logon attempt. Edit the file "/etc/pam.d/common-auth" and set the parameter "pam_faildelay" to a value of 4000000 or greater: auth required pam_faildelay.so delay=4000000

b

The Ubuntu operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/passwd.

AC-2 - Medium - CCI-000018 - V-238238 - SV-238238r853416_rule

RMF Control

AC-2

Severity

M

CCI

Version

UBTU-20-010100

Vuln IDs

V-238238

Rule IDs

SV-238238r853416_rule

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to create an account. Auditing account creation actions provides logging that can be used for forensic purposes. To address access requirements, many operating systems may be integrated with enterprise level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Satisfies: SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000458-GPOS-00203, SRG-OS-000463-GPOS-00207, SRG-OS-000476-GPOS-00221

Checks: C-41448r653887_chk

Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd". Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep passwd -w /etc/passwd -p wa -k usergroup_modification If the command does not return a line that matches the example 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.

Fix: F-41407r653888_fix

Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd". Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/passwd -p wa -k usergroup_modification To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/group.

AC-2 - Medium - CCI-000018 - V-238239 - SV-238239r853417_rule

RMF Control

AC-2

Severity

M

CCI

Version

UBTU-20-010101

Vuln IDs

V-238239

Rule IDs

SV-238239r853417_rule

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to create an account. Auditing account creation actions provides logging that can be used for forensic purposes. To address access requirements, many operating systems may be integrated with enterprise level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Satisfies: SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000458-GPOS-00203, SRG-OS-000476-GPOS-00221

Checks: C-41449r653890_chk

Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group". Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep group -w /etc/group -p wa -k usergroup_modification If the command does not return a line that matches the example 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.

Fix: F-41408r653891_fix

Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group". Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/group -p wa -k usergroup_modification To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/shadow.

AC-2 - Medium - CCI-000018 - V-238240 - SV-238240r853418_rule

RMF Control

AC-2

Severity

M

CCI

Version

UBTU-20-010102

Vuln IDs

V-238240

Rule IDs

SV-238240r853418_rule

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to create an account. Auditing account creation actions provides logging that can be used for forensic purposes. To address access requirements, many operating systems may be integrated with enterprise level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Satisfies: SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000458-GPOS-00203, SRG-OS-000476-GPOS-00221

Checks: C-41450r653893_chk

Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/shadow". Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep shadow -w /etc/shadow -p wa -k usergroup_modification If the command does not return a line that matches the example 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.

Fix: F-41409r653894_fix

Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/shadow". Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/shadow -p wa -k usergroup_modification To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/gshadow.

AU-12 - Medium - CCI-000172 - V-238241 - SV-238241r853419_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010103

Vuln IDs

V-238241

Rule IDs

SV-238241r853419_rule

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to create an account. Auditing account creation actions provides logging that can be used for forensic purposes. To address access requirements, many operating systems may be integrated with enterprise level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Satisfies: SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000458-GPOS-00203, SRG-OS-000476-GPOS-00221

Checks: C-41451r653896_chk

Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow". Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep gshadow -w /etc/gshadow -p wa -k usergroup_modification If the command does not return a line that matches the example 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.

Fix: F-41410r653897_fix

Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow". Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/gshadow -p wa -k usergroup_modification To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/opasswd.

AC-2 - Medium - CCI-000018 - V-238242 - SV-238242r853420_rule

RMF Control

AC-2

Severity

M

CCI

Version

UBTU-20-010104

Vuln IDs

V-238242

Rule IDs

SV-238242r853420_rule

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to create an account. Auditing account creation actions provides logging that can be used for forensic purposes. To address access requirements, many operating systems may be integrated with enterprise level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Satisfies: SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000458-GPOS-00203, SRG-OS-000476-GPOS-00221

Checks: C-41452r653899_chk

Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd". Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep opasswd -w /etc/security/opasswd -p wa -k usergroup_modification If the command does not return a line that matches the example 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.

Fix: F-41411r653900_fix

Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd". Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/security/opasswd -p wa -k usergroup_modification To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must alert the ISSO and SA (at a minimum) in the event of an audit processing failure.

AU-5 - Medium - CCI-000139 - V-238243 - SV-238243r653904_rule

RMF Control

AU-5

Severity

M

CCI

CCI-000139

Version

UBTU-20-010117

Vuln IDs

V-238243

Rule IDs

SV-238243r653904_rule

It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.

Checks: C-41453r653902_chk

Verify that the SA and ISSO (at a minimum) are notified in the event of an audit processing failure with the following command: $ sudo grep '^action_mail_acct = root' /etc/audit/auditd.conf action_mail_acct = <administrator_account> If the value of the "action_mail_acct" keyword is not set to an accounts for security personnel, the "action_mail_acct" keyword is missing, or the returned line is commented out, this is a finding.

Fix: F-41412r653903_fix

Configure "auditd" service to notify the SA and ISSO in the event of an audit processing failure. Edit the following line in "/etc/audit/auditd.conf" to ensure administrators are notified via email for those situations: action_mail_acct = <administrator_account> Note: Change "administrator_account" to an account for security personnel. Restart the "auditd" service so the changes take effect: $ sudo systemctl restart auditd.service

b

The Ubuntu operating system must shut down by default upon audit failure (unless availability is an overriding concern).

AU-5 - Medium - CCI-000140 - V-238244 - SV-238244r653907_rule

RMF Control

AU-5

Severity

M

CCI

CCI-000140

Version

UBTU-20-010118

Vuln IDs

V-238244

Rule IDs

SV-238244r653907_rule

It is critical that when the operating system is at risk of failing to process audit logs as required, it takes action to mitigate the failure. Audit processing failures include: software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode. When availability is an overriding concern, other approved actions in response to an audit failure are as follows: 1) If the failure was caused by the lack of audit record storage capacity, the operating system must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner. 2) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the operating system must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.

Checks: C-41454r653905_chk

Verify the Ubuntu operating system takes the appropriate action when the audit storage volume is full with the following command: $ sudo grep '^disk_full_action' /etc/audit/auditd.conf disk_full_action = HALT If the value of the "disk_full_action" option is not "SYSLOG", "SINGLE", or "HALT", or the line is commented out, this is a finding.

Fix: F-41413r653906_fix

Configure the Ubuntu operating system to shut down by default upon audit failure (unless availability is an overriding concern). Add or update the following line (depending on configuration, "disk_full_action" can be set to "SYSLOG", "HALT" or "SINGLE") in "/etc/audit/auditd.conf" file: disk_full_action = HALT Restart the "auditd" service so the changes take effect: $ sudo systemctl restart auditd.service

b

The Ubuntu operating system must be configured so that audit log files are not read or write-accessible by unauthorized users.

AU-9 - Medium - CCI-000162 - V-238245 - SV-238245r653910_rule

RMF Control

AU-9

Severity

M

CCI

CCI-000162

Version

UBTU-20-010122

Vuln IDs

V-238245

Rule IDs

SV-238245r653910_rule

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028

Checks: C-41455r653908_chk

Verify that the audit log files have a mode of "0600" or less permissive. Determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, determine if the audit log files have a mode of "0600" or less by using the following command: $ sudo stat -c "%n %a" /var/log/audit/* /var/log/audit/audit.log 600 If the audit log files have a mode more permissive than "0600", this is a finding.

Fix: F-41414r653909_fix

Configure the audit log files to have a mode of "0600" or less permissive. Determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, configure the audit log files to have a mode of "0600" or less permissive by using the following command: $ sudo chmod 0600 /var/log/audit/*

b

The Ubuntu operating system must be configured to permit only authorized users ownership of the audit log files.

AU-9 - Medium - CCI-000162 - V-238246 - SV-238246r653913_rule

RMF Control

AU-9

Severity

M

CCI

CCI-000162

Version

UBTU-20-010123

Vuln IDs

V-238246

Rule IDs

SV-238246r653913_rule

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Checks: C-41456r653911_chk

Verify the audit log files are owned by "root" account. Determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, determine if the audit log files are owned by the "root" user by using the following command: $ sudo stat -c "%n %U" /var/log/audit/* /var/log/audit/audit.log root If the audit log files are owned by an user other than "root", this is a finding.

Fix: F-41415r653912_fix

Configure the audit log directory and its underlying files to be owned by "root" user. Determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, configure the audit log files to be owned by "root" user by using the following command: $ sudo chown root /var/log/audit/*

b

The Ubuntu operating system must permit only authorized groups ownership of the audit log files.

AU-9 - Medium - CCI-000162 - V-238247 - SV-238247r832947_rule

RMF Control

AU-9

Severity

M

CCI

CCI-000162

Version

UBTU-20-010124

Vuln IDs

V-238247

Rule IDs

SV-238247r832947_rule

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit operating system activity. Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Checks: C-41457r802384_chk

Verify the group owner is set to own newly created audit logs in the audit configuration file with the following command: $ sudo grep -iw log_group /etc/audit/auditd.conf log_group = root If the value of the "log_group" parameter is other than "root", this is a finding. Determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, determine if the audit log files are owned by the "root" group by using the following command: $ sudo stat -c "%n %G" /var/log/audit/* /var/log/audit/audit.log root If the audit log files are owned by a group other than "root", this is a finding.

Fix: F-41416r832946_fix

Configure the audit log directory and its underlying files to be owned by "root" group. Set the "log_group" parameter of the audit configuration file to the "root" value so when a new log file is created, its group owner is properly set: $ sudo sed -i '/^log_group/D' /etc/audit/auditd.conf $ sudo sed -i /^log_file/a'log_group = root' /etc/audit/auditd.conf Last, signal the audit daemon to reload the configuration file to update the group owners of existing files: $ sudo systemctl kill auditd -s SIGHUP

b

The Ubuntu operating system must be configured so that the audit log directory is not write-accessible by unauthorized users.

AU-9 - Medium - CCI-000164 - V-238248 - SV-238248r653919_rule

RMF Control

AU-9

Severity

M

CCI

CCI-000164

Version

UBTU-20-010128

Vuln IDs

V-238248

Rule IDs

SV-238248r653919_rule

If audit information were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is impossible to achieve. To ensure the veracity of audit information, the operating system must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit information system activity.

Checks: C-41458r653917_chk

Verify that the audit log directory has a mode of "0750" or less permissive. Determine where the audit logs are stored with the following command: $ sudo grep -iw ^log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, determine if the directory has a mode of "0750" or less by using the following command: $ sudo stat -c "%n %a" /var/log/audit /var/log/audit/* /var/log/audit 750 /var/log/audit/audit.log 600 If the audit log directory has a mode more permissive than "0750", this is a finding.

Fix: F-41417r653918_fix

Configure the audit log directory to have a mode of "0750" or less permissive. Determine where the audit logs are stored with the following command: $ sudo grep -iw ^log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, configure the audit log directory to have a mode of "0750" or less permissive by using the following command: $ sudo chmod -R g-w,o-rwx /var/log/audit

b

The Ubuntu operating system must be configured so that audit configuration files are not write-accessible by unauthorized users.

AU-12 - Medium - CCI-000171 - V-238249 - SV-238249r653922_rule

RMF Control

AU-12

Severity

M

CCI

CCI-000171

Version

UBTU-20-010133

Vuln IDs

V-238249

Rule IDs

SV-238249r653922_rule

Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Checks: C-41459r653920_chk

Verify that "/etc/audit/audit.rules", "/etc/audit/rules.d/*", and "/etc/audit/auditd.conf" files have a mode of "0640" or less permissive by using the following command: $ sudo ls -al /etc/audit/ /etc/audit/rules.d/ /etc/audit/: -rw-r----- 1 root root 804 Nov 25 11:01 auditd.conf -rw-r----- 1 root root 9128 Dec 27 09:56 audit.rules -rw-r----- 1 root root 9373 Dec 27 09:56 audit.rules.prev -rw-r----- 1 root root 127 Feb 7 2018 audit-stop.rules drwxr-x--- 2 root root 4096 Dec 27 09:56 rules.d /etc/audit/rules.d/: -rw-r----- 1 root root 10357 Dec 27 09:56 stig.rules If "/etc/audit/audit.rule","/etc/audit/rules.d/*", or "/etc/audit/auditd.conf" file have a mode more permissive than "0640", this is a finding.

Fix: F-41418r653921_fix

Configure "/etc/audit/audit.rules", "/etc/audit/rules.d/*", and "/etc/audit/auditd.conf" files to have a mode of "0640" by using the following command: $ sudo chmod -R 0640 /etc/audit/audit*.{rules,conf} /etc/audit/rules.d/*

b

The Ubuntu operating system must permit only authorized accounts to own the audit configuration files.

AU-12 - Medium - CCI-000171 - V-238250 - SV-238250r653925_rule

RMF Control

AU-12

Severity

M

CCI

CCI-000171

Version

UBTU-20-010134

Vuln IDs

V-238250

Rule IDs

SV-238250r653925_rule

Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Checks: C-41460r653923_chk

Verify that "/etc/audit/audit.rules", "/etc/audit/rules.d/*" and "/etc/audit/auditd.conf" files are owned by root account by using the following command: $ sudo ls -al /etc/audit/ /etc/audit/rules.d/ /etc/audit/: drwxr-x--- 3 root root 4096 Nov 25 11:02 . drwxr-xr-x 130 root root 12288 Dec 19 13:42 .. -rw-r----- 1 root root 804 Nov 25 11:01 auditd.conf -rw-r----- 1 root root 9128 Dec 27 09:56 audit.rules -rw-r----- 1 root root 9373 Dec 27 09:56 audit.rules.prev -rw-r----- 1 root root 127 Feb 7 2018 audit-stop.rules drwxr-x--- 2 root root 4096 Dec 27 09:56 rules.d /etc/audit/rules.d/: drwxr-x--- 2 root root 4096 Dec 27 09:56 . drwxr-x--- 3 root root 4096 Nov 25 11:02 .. -rw-r----- 1 root root 10357 Dec 27 09:56 stig.rules If the "/etc/audit/audit.rules", "/etc/audit/rules.d/*", or "/etc/audit/auditd.conf" file is owned by a user other than "root", this is a finding.

Fix: F-41419r653924_fix

Configure "/etc/audit/audit.rules", "/etc/audit/rules.d/*" and "/etc/audit/auditd.conf" files to be owned by root user by using the following command: $ sudo chown root /etc/audit/audit*.{rules,conf} /etc/audit/rules.d/*

b

The Ubuntu operating system must permit only authorized groups to own the audit configuration files.

AU-12 - Medium - CCI-000171 - V-238251 - SV-238251r653928_rule

RMF Control

AU-12

Severity

M

CCI

CCI-000171

Version

UBTU-20-010135

Vuln IDs

V-238251

Rule IDs

SV-238251r653928_rule

Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Checks: C-41461r653926_chk

Verify that "/etc/audit/audit.rules", "/etc/audit/rules.d/*", and "/etc/audit/auditd.conf" files are owned by root group by using the following command: $ sudo ls -al /etc/audit/ /etc/audit/rules.d/ /etc/audit/: -rw-r----- 1 root root 804 Nov 25 11:01 auditd.conf -rw-r----- 1 root root 9128 Dec 27 09:56 audit.rules -rw-r----- 1 root root 9373 Dec 27 09:56 audit.rules.prev -rw-r----- 1 root root 127 Feb 7 2018 audit-stop.rules drwxr-x--- 2 root root 4096 Dec 27 09:56 rules.d /etc/audit/rules.d/: -rw-r----- 1 root root 10357 Dec 27 09:56 stig.rules If the "/etc/audit/audit.rules", "/etc/audit/rules.d/*", or "/etc/audit/auditd.conf" file is owned by a group other than "root", this is a finding.

Fix: F-41420r653927_fix

Configure "/etc/audit/audit.rules", "/etc/audit/rules.d/*", and "/etc/audit/auditd.conf" files to be owned by root group by using the following command: $ sudo chown :root /etc/audit/audit*.{rules,conf} /etc/audit/rules.d/*

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the su command.

AU-12 - Medium - CCI-000172 - V-238252 - SV-238252r653931_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010136

Vuln IDs

V-238252

Rule IDs

SV-238252r653931_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41462r653929_chk

Verify the Ubuntu operating system generates audit records upon successful/unsuccessful attempts to use the "su" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep '/bin/su' -a always,exit -F path=/bin/su -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-priv_change If the command does not return lines that match the example or the lines are 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.

Fix: F-41421r653930_fix

Configure the Ubuntu operating system to generate audit records when successful/unsuccessful attempts to use the "su" command occur. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/bin/su -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-priv_change To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the chfn command.

AU-12 - Medium - CCI-000172 - V-238253 - SV-238253r653934_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010137

Vuln IDs

V-238253

Rule IDs

SV-238253r653934_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41463r653932_chk

Verify the Ubuntu operating system generates audit records upon successful/unsuccessful attempts to use the "chfn" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep '/usr/bin/chfn' -a always,exit -F path=/usr/bin/chfn -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-chfn If the command does not return lines that match the example or the lines are 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.

Fix: F-41422r653933_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "chfn" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/chfn -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-chfn To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the mount command.

AU-12 - Medium - CCI-000172 - V-238254 - SV-238254r653937_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010138

Vuln IDs

V-238254

Rule IDs

SV-238254r653937_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41464r653935_chk

Verify the Ubuntu operating system generates audit records upon successful/unsuccessful attempts to use the "mount" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep '/usr/bin/mount' -a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-mount If the command does not return lines that match the example or the lines are 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.

Fix: F-41423r653936_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "mount" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-mount To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the umount command.

AU-12 - Medium - CCI-000172 - V-238255 - SV-238255r653940_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010139

Vuln IDs

V-238255

Rule IDs

SV-238255r653940_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41465r653938_chk

Verify if the Ubuntu operating system generates audit records upon successful/unsuccessful attempts to use the "umount" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep '/usr/bin/umount' -a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-umount If the command does not return lines that match the example or the lines are 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.

Fix: F-41424r653939_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "umount" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-umount To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the ssh-agent command.

AU-12 - Medium - CCI-000172 - V-238256 - SV-238256r653943_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010140

Vuln IDs

V-238256

Rule IDs

SV-238256r653943_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41466r653941_chk

Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "ssh-agent" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep '/usr/bin/ssh-agent' -a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-ssh If the command does not return lines that match the example or the lines are 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.

Fix: F-41425r653942_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ssh-agent" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-ssh To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the ssh-keysign command.

AU-12 - Medium - CCI-000172 - V-238257 - SV-238257r653946_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010141

Vuln IDs

V-238257

Rule IDs

SV-238257r653946_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41467r653944_chk

Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "ssh-keysign" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep ssh-keysign -a always,exit -F path=/usr/lib/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-ssh If the command does not return lines that match the example or the lines are 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.

Fix: F-41426r653945_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ssh-keysign" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/lib/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-ssh To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for any use of the setxattr, fsetxattr, lsetxattr, removexattr, fremovexattr, and lremovexattr system calls.

AU-12 - Medium - CCI-000172 - V-238258 - SV-238258r808474_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010142

Vuln IDs

V-238258

Rule IDs

SV-238258r808474_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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 system call rules are loaded into a matching engine that intercepts each syscall that all programs on the system makes. Therefore, it is very important to only use syscall rules when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance is helped, though, by combining syscalls into one rule whenever possible. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206

Checks: C-41468r808472_chk

Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "setxattr", "fsetxattr", "lsetxattr", "removexattr", "fremovexattr", and "lremovexattr" system calls. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep xattr -a always,exit -F arch=b32 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b32 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b64 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid=0 -k perm_mod If the command does not return audit rules for the "setxattr", "fsetxattr", "lsetxattr", "removexattr", "fremovexattr" and "lremovexattr" syscalls or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

Fix: F-41427r808473_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "setxattr", "fsetxattr", "lsetxattr", "removexattr", "fremovexattr", and "lremovexattr" system calls. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid=0 -k perm_mod Note: For 32-bit architectures, only the 32-bit specific entries are required. To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the chown, fchown, fchownat, and lchown system calls.

AU-12 - Medium - CCI-000172 - V-238264 - SV-238264r808477_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010148

Vuln IDs

V-238264

Rule IDs

SV-238264r808477_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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 system call rules are loaded into a matching engine that intercepts each syscall that all programs on the system makes. Therefore, it is very important to only use syscall rules when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance is helped, though, by combining syscalls into one rule whenever possible. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206

Checks: C-41474r808475_chk

Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "chown", "fchown", "fchownat", and "lchown" system calls. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep chown -a always,exit -F arch=b32 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return audit rules for the "chown", "fchown", "fchownat", and "lchown" syscalls or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

Fix: F-41433r808476_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chown", "fchown", "fchownat", and "lchown" system calls. Add or update the following rules in the "/etc/audit/rules.d/stig.rules": -a always,exit -F arch=b32 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=4294967295 -k perm_chng Note: For 32-bit architectures, only the 32-bit specific entries are required. To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the chmod, fchmod, and fchmodat system calls.

AU-12 - Medium - CCI-000172 - V-238268 - SV-238268r808480_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010152

Vuln IDs

V-238268

Rule IDs

SV-238268r808480_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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 system call rules are loaded into a matching engine that intercepts each syscall that all programs on the system makes. Therefore, it is very important to only use syscall rules when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance is helped, though, by combining syscalls into one rule whenever possible. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000462-GPOS-00206

Checks: C-41478r808478_chk

Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "chmod", "fchmod", and "fchmodat" system calls. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep chmod -a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return audit rules for the "chmod", "fchmod" and "fchmodat" syscalls or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

Fix: F-41437r808479_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chmod", "fchmod", and "fchmodat" system calls. Add or update the following rules in the "/etc/audit/rules.d/stig.rules": -a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the creat, open, openat, open_by_handle_at, truncate, and ftruncate system calls.

AU-12 - Medium - CCI-000172 - V-238271 - SV-238271r808483_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010155

Vuln IDs

V-238271

Rule IDs

SV-238271r808483_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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 system call rules are loaded into a matching engine that intercepts each syscall that all programs on the system makes. Therefore, it is very important to only use syscall rules when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance is helped, though, by combining syscalls into one rule whenever possible. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000474-GPOS-00219

Checks: C-41481r808481_chk

Verify the Ubuntu operating system generates an audit record upon unsuccessful attempts to use the "creat", "open", "openat", "open_by_handle_at", "truncate", and "ftruncate" system calls. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep 'open\|truncate\|creat' -a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access If the command does not return audit rules for the "creat", "open", "openat", "open_by_handle_at", "truncate", and "ftruncate" syscalls or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

Fix: F-41440r808482_fix

Configure the audit system to generate an audit event for any unsuccessful use of the"creat", "open", "openat", "open_by_handle_at", "truncate", and "ftruncate" system calls. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access Notes: For 32-bit architectures, only the 32-bit specific entries are required. To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the sudo command.

AU-12 - Medium - CCI-000172 - V-238277 - SV-238277r654006_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010161

Vuln IDs

V-238277

Rule IDs

SV-238277r654006_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41487r654004_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "sudo" command. Check the configured audit rules with the following command: $ sudo auditctl -l | grep /usr/bin/sudo -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=-1 -k priv_cmd If the command does not return a line that matches the example 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.

Fix: F-41446r654005_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "sudo" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the sudoedit command.

AU-12 - Medium - CCI-000172 - V-238278 - SV-238278r654009_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010162

Vuln IDs

V-238278

Rule IDs

SV-238278r654009_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41488r654007_chk

Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "sudoedit" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep /usr/bin/sudoedit -a always,exit -F path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=-1 -k priv_cmd If the command does not return a line that matches the example 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.

Fix: F-41447r654008_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "sudoedit" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules": -a always,exit -F path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the chsh command.

AU-12 - Medium - CCI-000172 - V-238279 - SV-238279r654012_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010163

Vuln IDs

V-238279

Rule IDs

SV-238279r654012_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41489r654010_chk

Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "chsh" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep chsh -a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=-1 -k priv_cmd If the command does not return a line that matches the example or the line is commented out, this is a finding. Notes: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

Fix: F-41448r654011_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chsh" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the newgrp command.

AU-12 - Medium - CCI-000172 - V-238280 - SV-238280r654015_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010164

Vuln IDs

V-238280

Rule IDs

SV-238280r654015_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41490r654013_chk

Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "newgrp" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep newgrp -a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=-1 -k priv_cmd If the command does not return a line that matches the example 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.

Fix: F-41449r654014_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "newgrp" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the chcon command.

AU-12 - Medium - CCI-000172 - V-238281 - SV-238281r654018_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010165

Vuln IDs

V-238281

Rule IDs

SV-238281r654018_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41491r654016_chk

Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "chcon" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep chcon -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return a line that matches the example 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.

Fix: F-41450r654017_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chcon" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the apparmor_parser command.

AU-12 - Medium - CCI-000172 - V-238282 - SV-238282r654021_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010166

Vuln IDs

V-238282

Rule IDs

SV-238282r654021_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41492r654019_chk

Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "apparmor_parser" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep apparmor_parser -a always,exit -F path=/sbin/apparmor_parser -F perm=x -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return a line that matches the example 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.

Fix: F-41451r654020_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "apparmor_parser" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/sbin/apparmor_parser -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the setfacl command.

AU-12 - Medium - CCI-000172 - V-238283 - SV-238283r654024_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010167

Vuln IDs

V-238283

Rule IDs

SV-238283r654024_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41493r654022_chk

Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "setfacl" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep setfacl -a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return a line that matches the example 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.

Fix: F-41452r654023_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "setfacl" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the chacl command.

AU-12 - Medium - CCI-000172 - V-238284 - SV-238284r928523_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010168

Vuln IDs

V-238284

Rule IDs

SV-238284r928523_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41494r928522_chk

Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "chacl" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep chacl -a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return a line that matches the example 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.

Fix: F-41453r654026_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chacl" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for the use and modification of the tallylog file.

AU-12 - Medium - CCI-000172 - V-238285 - SV-238285r654030_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010169

Vuln IDs

V-238285

Rule IDs

SV-238285r654030_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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). Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000470-GPOS-00214, SRG-OS-000473-GPOS-00218

Checks: C-41495r654028_chk

Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful modifications to the "tallylog" file. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep tallylog -w /var/log/tallylog -p wa -k logins If the command does not return a line that matches the example 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.

Fix: F-41454r654029_fix

Configure the audit system to generate an audit event for any successful/unsuccessful modifications to the "tallylog" file. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -w /var/log/tallylog -p wa -k logins To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for the use and modification of faillog file.

AU-12 - Medium - CCI-000172 - V-238286 - SV-238286r654033_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010170

Vuln IDs

V-238286

Rule IDs

SV-238286r654033_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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). Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000470-GPOS-00214, SRG-OS-000473-GPOS-00218

Checks: C-41496r654031_chk

Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful modifications to the "faillog" file. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep faillog -w /var/log/faillog -p wa -k logins If the command does not return a line that matches the example 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.

Fix: F-41455r654032_fix

Configure the audit system to generate an audit event for any successful/unsuccessful modifications to the "faillog" file. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -w /var/log/faillog -p wa -k logins To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for the use and modification of the lastlog file.

AU-12 - Medium - CCI-000172 - V-238287 - SV-238287r654036_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010171

Vuln IDs

V-238287

Rule IDs

SV-238287r654036_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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). Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000470-GPOS-00214, SRG-OS-000473-GPOS-00218

Checks: C-41497r654034_chk

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful modifications to the "lastlog" file occur. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep lastlog -w /var/log/lastlog -p wa -k logins If the command does not return a line that matches the example 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.

Fix: F-41456r654035_fix

Configure the audit system to generate an audit event for any successful/unsuccessful modifications to the "lastlog" file. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -w /var/log/lastlog -p wa -k logins To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the passwd command.

AU-12 - Medium - CCI-000172 - V-238288 - SV-238288r833012_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010172

Vuln IDs

V-238288

Rule IDs

SV-238288r833012_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41498r833011_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "passwd" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep -w passwd -a always,exit -S all -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-passwd If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The "key" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

Fix: F-41457r832949_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "passwd" command. Add or update the following rule in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-passwd To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the unix_update command.

AU-12 - Medium - CCI-000172 - V-238289 - SV-238289r654042_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010173

Vuln IDs

V-238289

Rule IDs

SV-238289r654042_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41499r654040_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "unix_update" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep -w unix_update -a always,exit -F path=/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-unix-update If the command does not return a line that matches the example 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.

Fix: F-41458r654041_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "unix_update" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-unix-update To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the gpasswd command.

AU-12 - Medium - CCI-000172 - V-238290 - SV-238290r654045_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010174

Vuln IDs

V-238290

Rule IDs

SV-238290r654045_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41500r654043_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "gpasswd" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep -w gpasswd -a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-gpasswd If the command does not return a line that matches the example 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.

Fix: F-41459r654044_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "gpasswd" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-gpasswd To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the chage command.

AU-12 - Medium - CCI-000172 - V-238291 - SV-238291r654048_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010175

Vuln IDs

V-238291

Rule IDs

SV-238291r654048_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41501r654046_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "chage" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep -w chage -a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-chage If the command does not return a line that matches the example 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.

Fix: F-41460r654047_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "chage" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-chage To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the usermod command.

AU-12 - Medium - CCI-000172 - V-238292 - SV-238292r654051_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010176

Vuln IDs

V-238292

Rule IDs

SV-238292r654051_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41502r654049_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "usermod" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep -w usermod -a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-usermod If the command does not return a line that matches the example 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.

Fix: F-41461r654050_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "usermod" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-usermod To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the crontab command.

AU-12 - Medium - CCI-000172 - V-238293 - SV-238293r654054_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010177

Vuln IDs

V-238293

Rule IDs

SV-238293r654054_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41503r654052_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "crontab" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep -w crontab -a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-crontab If the command does not return a line that matches the example 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.

Fix: F-41462r654053_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "crontab" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-crontab To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the pam_timestamp_check command.

AU-12 - Medium - CCI-000172 - V-238294 - SV-238294r654057_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010178

Vuln IDs

V-238294

Rule IDs

SV-238294r654057_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41504r654055_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "pam_timestamp_check" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep -w pam_timestamp_check -a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-pam_timestamp_check If the command does not return a line that matches the example 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.

Fix: F-41463r654056_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "pam_timestamp_check" command. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-pam_timestamp_check To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the init_module and finit_module syscalls.

AU-12 - Medium - CCI-000172 - V-238295 - SV-238295r808486_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010179

Vuln IDs

V-238295

Rule IDs

SV-238295r808486_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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 system call rules are loaded into a matching engine that intercepts each syscall that all programs on the system makes. Therefore, it is very important to only use syscall rules when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance is helped, though, by combining syscalls into one rule whenever possible. Satisfies: SRG-OS-000064-GPOS-00033, SRG-OS-000471-GPOS-00216

Checks: C-41505r808484_chk

Verify the Ubuntu operating system generates an audit record for any successful/unsuccessful attempts to use the "init_module" and "finit_module" syscalls. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep init_module -a always,exit -F arch=b32 -S init_module,finit_module -F auid>=1000 -F auid!=-1 -k module_chng -a always,exit -F arch=b64 -S init_module,finit_module -F auid>=1000 -F auid!=-1 -k module_chng If the command does not return audit rules for the "init_module" and "finit_module" syscalls or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

Fix: F-41464r808485_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "init_module" and "finit_module" syscalls. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S init_module,finit_module -F auid>=1000 -F auid!=4294967295 -k module_chng -a always,exit -F arch=b64 -S init_module,finit_module -F auid>=1000 -F auid!=4294967295 -k module_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for successful/unsuccessful uses of the delete_module syscall.

AU-12 - Medium - CCI-000172 - V-238297 - SV-238297r802387_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010181

Vuln IDs

V-238297

Rule IDs

SV-238297r802387_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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). Satisfies: SRG-OS-000477-GPOS-00222

Checks: C-41507r654064_chk

Verify the Ubuntu operating system generates an audit record for any successful/unsuccessful attempts to use the "delete_module" syscall. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep -w delete_module -a always,exit -F arch=b32 -S delete_module -F auid>=1000 -F auid!=-1 -k module_chng -a always,exit -F arch=b64 -S delete_module -F auid>=1000 -F auid!=-1 -k module_chng If the command does not return a line that matches the example or the line is commented out, this is a finding. Notes: - For 32-bit architectures, only the 32-bit specific output lines from the commands are required. - The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

Fix: F-41466r654065_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "delete_module" syscall. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S delete_module -F auid>=1000 -F auid!=4294967295 -k module_chng -a always,exit -F arch=b64 -S delete_module -F auid>=1000 -F auid!=4294967295 -k module_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must produce audit records and reports containing information to establish when, where, what type, the source, and the outcome for all DoD-defined auditable events and actions in near real time.

AU-3 - Medium - CCI-000130 - V-238298 - SV-238298r853421_rule

RMF Control

AU-3

Severity

M

CCI

CCI-000130

Version

UBTU-20-010182

Vuln IDs

V-238298

Rule IDs

SV-238298r853421_rule

Without establishing the when, where, type, source, and outcome of events that occurred, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack. 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 record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked. Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information. Successful incident response and auditing relies on timely, accurate system information and analysis in order to allow the organization to identify and respond to potential incidents in a proficient manner. If the operating system does not provide the ability to centrally review the operating system logs, forensic analysis is negatively impacted. Associating event types with detected events in the Ubuntu operating system audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured operating system. Satisfies: SRG-OS-000122-GPOS-00063, SRG-OS-000037-GPOS-00015, SRG-OS-000038-GPOS-00016, SRG-OS-000039-GPOS-00017, SRG-OS-000040-GPOS-00018, SRG-OS-000041-GPOS-00019, SRG-OS-000042-GPOS-00020, SRG-OS-000042-GPOS-00021, SRG-OS-000051-GPOS-00024, SRG-OS-000054-GPOS-00025, SRG-OS-000062-GPOS-00031, SRG-OS-000337-GPOS-00129, SRG-OS-000348-GPOS-00136, SRG-OS-000349-GPOS-00137, SRG-OS-000350-GPOS-00138, SRG-OS-000351-GPOS-00139, SRG-OS-000352-GPOS-00140, SRG-OS-000353-GPOS-00141, SRG-OS-000354-GPOS-00142, SRG-OS-000475-GPOS-00220

Checks: C-41508r654067_chk

Verify the audit service is configured to produce audit records with the following command: $ dpkg -l | grep auditd If the "auditd" package is not installed, this is a finding. Verify the audit service is enabled with the following command: $ systemctl is-enabled auditd.service If the command above returns "disabled", this is a finding. Verify the audit service is properly running and active on the system with the following command: $ systemctl is-active auditd.service active If the command above returns "inactive", this is a finding.

Fix: F-41467r654068_fix

Configure the audit service to produce audit records containing the information needed to establish when (date and time) an event occurred. Install the audit service (if the audit service is not already installed) with the following command: $ sudo apt-get install auditd Enable the audit service with the following command: $ sudo systemctl enable auditd.service To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must initiate session audits at system start-up.

AU-14 - Medium - CCI-001464 - V-238299 - SV-238299r654072_rule

RMF Control

AU-14

Severity

M

CCI

CCI-001464

Version

UBTU-20-010198

Vuln IDs

V-238299

Rule IDs

SV-238299r654072_rule

If auditing is enabled late in the start-up process, the actions of some start-up processes may not be audited. Some audit systems also maintain state information only available if auditing is enabled before a given process is created.

Checks: C-41509r654070_chk

Verify that the Ubuntu operating system enables auditing at system startup. Verify that the auditing is enabled in grub with the following command: $ sudo grep "^\s*linux" /boot/grub/grub.cfg linux /boot/vmlinuz-5.4.0-31-generic root=UUID=74d13bcd-6ebd-4493-b5d2-3ebc37d01702 ro audit=1 linux /boot/vmlinuz-5.4.0-31-generic root=UUID=74d13bcd-6ebd-4493-b5d2-3ebc37d01702 ro recovery nomodeset audit=1 If any linux lines do not contain "audit=1", this is a finding.

Fix: F-41468r654071_fix

Configure the Ubuntu operating system to produce audit records at system startup. Edit the "/etc/default/grub" file and add "audit=1" to the "GRUB_CMDLINE_LINUX" option. To update the grub config file, run: $ sudo update-grub

b

The Ubuntu operating system must configure audit tools with a mode of 0755 or less permissive.

AU-9 - Medium - CCI-001493 - V-238300 - SV-238300r654075_rule

RMF Control

AU-9

Severity

M

CCI

CCI-001493

Version

UBTU-20-010199

Vuln IDs

V-238300

Rule IDs

SV-238300r654075_rule

Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. Satisfies: SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098

Checks: C-41510r654073_chk

Verify the Ubuntu operating system configures the audit tools to have a file permission of 0755 or less to prevent unauthorized access by running the following command: $ stat -c "%n %a" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules /sbin/auditctl 755 /sbin/aureport 755 /sbin/ausearch 755 /sbin/autrace 755 /sbin/auditd 755 /sbin/audispd 755 /sbin/augenrules 755 If any of the audit tools have a mode more permissive than 0755, this is a finding.

Fix: F-41469r654074_fix

Configure the audit tools on the Ubuntu operating system to be protected from unauthorized access by setting the correct permissive mode using the following command: $ sudo chmod 0755 [audit_tool] Replace "[audit_tool]" with the audit tool that does not have the correct permissions.

b

The Ubuntu operating system must configure audit tools to be owned by root.

AU-9 - Medium - CCI-001493 - V-238301 - SV-238301r654078_rule

RMF Control

AU-9

Severity

M

CCI

CCI-001493

Version

UBTU-20-010200

Vuln IDs

V-238301

Rule IDs

SV-238301r654078_rule

Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. Satisfies: SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098

Checks: C-41511r654076_chk

Verify the Ubuntu operating system configures the audit tools to be owned by root to prevent any unauthorized access. Check the ownership by running the following command: $ stat -c "%n %U" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules /sbin/auditctl root /sbin/aureport root /sbin/ausearch root /sbin/autrace root /sbin/auditd root /sbin/audispd root /sbin/augenrules root If any of the audit tools are not owned by root, this is a finding.

Fix: F-41470r654077_fix

Configure the audit tools on the Ubuntu operating system to be protected from unauthorized access by setting the file owner as root using the following command: $ sudo chown root [audit_tool] Replace "[audit_tool]" with each audit tool not owned by root.

b

The Ubuntu operating system must configure the audit tools to be group-owned by root.

AU-9 - Medium - CCI-001493 - V-238302 - SV-238302r654081_rule

RMF Control

AU-9

Severity

M

CCI

CCI-001493

Version

UBTU-20-010201

Vuln IDs

V-238302

Rule IDs

SV-238302r654081_rule

Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. Satisfies: SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098

Checks: C-41512r654079_chk

Verify the Ubuntu operating system configures the audit tools to be group-owned by root to prevent any unauthorized access. Check the group ownership by running the following command: $ stat -c "%n %G" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules /sbin/auditctl root /sbin/aureport root /sbin/ausearch root /sbin/autrace root /sbin/auditd root /sbin/audispd root /sbin/augenrules root If any of the audit tools are not group-owned by root, this is a finding.

Fix: F-41471r654080_fix

Configure the audit tools on the Ubuntu operating system to be protected from unauthorized access by setting the file group as root using the following command: $ sudo chown :root [audit_tool] Replace "[audit_tool]" with each audit tool not group-owned by root.

b

The Ubuntu operating system must use cryptographic mechanisms to protect the integrity of audit tools.

AU-9 - Medium - CCI-001496 - V-238303 - SV-238303r877393_rule

RMF Control

AU-9

Severity

M

CCI

CCI-001496

Version

UBTU-20-010205

Vuln IDs

V-238303

Rule IDs

SV-238303r877393_rule

Protecting the integrity of the tools used for auditing purposes is a critical step toward ensuring the integrity of audit information. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. It is not uncommon for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs. To address this risk, audit tools must be cryptographically signed in order to provide the capability to identify when the audit tools have been modified, manipulated, or replaced. An example is a checksum hash of the file or files.

Checks: C-41513r654082_chk

Verify that Advanced Intrusion Detection Environment (AIDE) is properly configured to use cryptographic mechanisms to protect the integrity of audit tools. Check the selection lines that AIDE is configured to add/check with the following command: $ egrep '(\/sbin\/(audit|au))' /etc/aide/aide.conf /sbin/auditctl p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/auditd p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/ausearch p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/aureport p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/autrace p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/audispd p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/augenrules p+i+n+u+g+s+b+acl+xattrs+sha512 If any of the seven audit tools do not have appropriate selection lines, this is a finding.

Fix: F-41472r654083_fix

Add or update the following selection lines for "/etc/aide/aide.conf" to protect the integrity of the audit tools: # Audit Tools /sbin/auditctl p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/auditd p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/ausearch p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/aureport p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/autrace p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/audispd p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/augenrules p+i+n+u+g+s+b+acl+xattrs+sha512

b

The Ubuntu operating system must prevent all software from executing at higher privilege levels than users executing the software and the audit system must be configured to audit the execution of privileged functions.

AC-6 - Medium - CCI-002233 - V-238304 - SV-238304r853422_rule

RMF Control

AC-6

Severity

M

CCI

CCI-002233

Version

UBTU-20-010211

Vuln IDs

V-238304

Rule IDs

SV-238304r853422_rule

In certain situations, software applications/programs need to execute with elevated privileges to perform required functions. However, if the privileges required for execution are at a higher level than the privileges assigned to organizational users invoking such applications/programs, those users are indirectly provided with greater privileges than assigned by the organizations. Some programs and processes are required to operate at a higher privilege level and therefore should be excluded from the organization-defined software list after review. Satisfies: SRG-OS-000326-GPOS-00126, SRG-OS-000327-GPOS-00127

Checks: C-41514r654085_chk

Verify the Ubuntu operating system audits the execution of privilege functions by auditing the "execve" system call. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep execve -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -F key=execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -F key=execpriv -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -F key=execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -F key=execpriv If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: - For 32-bit architectures, only the 32-bit specific output lines from the commands are required. - The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

Fix: F-41473r654086_fix

Configure the Ubuntu operating system to audit the execution of all privileged functions. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -F key=execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -F key=execpriv -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -F key=execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -F key=execpriv Notes: For 32-bit architectures, only the 32-bit specific entries are required. To reload the rules file, issue the following command: $ sudo augenrules --load

a

The Ubuntu operating system must allocate audit record storage capacity to store at least one weeks' worth of audit records, when audit records are not immediately sent to a central audit record storage facility.

AU-4 - Low - CCI-001849 - V-238305 - SV-238305r877391_rule

RMF Control

AU-4

Severity

L

CCI

CCI-001849

Version

UBTU-20-010215

Vuln IDs

V-238305

Rule IDs

SV-238305r877391_rule

In order to ensure operating systems have a sufficient storage capacity in which to write the audit logs, operating systems need to be able to allocate audit record storage capacity. The task of allocating audit record storage capacity is usually performed during initial installation of the operating system.

Checks: C-41515r654088_chk

Verify the Ubuntu operating system allocates audit record storage capacity to store at least one week's worth of audit records when audit records are not immediately sent to a central audit record storage facility. Determine which partition the audit records are being written to with the following command: $ sudo grep ^log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Check the size of the partition that audit records are written to (with the example being "/var/log/audit/") with the following command: $ sudo df –h /var/log/audit/ /dev/sda2 24G 10.4G 13.6G 43% /var/log/audit If the audit records are not written to a partition made specifically for audit records ("/var/log/audit" is a separate partition), determine the amount of space being used by other files in the partition with the following command: $ sudo du –sh [audit_partition] 1.8G /var/log/audit Note: The partition size needed to capture a week's worth of audit records is based on the activity level of the system and the total storage capacity available. In normal circumstances, 10.0 GB of storage space for audit records will be sufficient. If the audit record partition is not allocated for sufficient storage capacity, this is a finding.

Fix: F-41474r654089_fix

Allocate enough storage capacity for at least one week's worth of audit records when audit records are not immediately sent to a central audit record storage facility. If audit records are stored on a partition made specifically for audit records, use the "parted" program to resize the partition with sufficient space to contain one week's worth of audit records. If audit records are not stored on a partition made specifically for audit records, a new partition with sufficient amount of space will need be to be created. Set the auditd server to point to the mount point where the audit records must be located: $ sudo sed -i -E 's@^(log_file\s*=\s*).*@\1 <log mountpoint>/audit.log@' /etc/audit/auditd.conf where <log mountpoint> is the aforementioned mount point.

a

The Ubuntu operating system audit event multiplexor must be configured to off-load audit logs onto a different system or storage media from the system being audited.

AU-4 - Low - CCI-001851 - V-238306 - SV-238306r877390_rule

RMF Control

AU-4

Severity

L

CCI

CCI-001851

Version

UBTU-20-010216

Vuln IDs

V-238306

Rule IDs

SV-238306r877390_rule

Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Off-loading is a common process in information systems with limited audit storage capacity. Satisfies: SRG-OS-000342-GPOS-00133, SRG-OS-000479-GPOS-00224

Checks: C-41516r654091_chk

Verify the audit event multiplexor is configured to offload audit records to a different system or storage media from the system being audited. Check that audisp-remote plugin is installed: $ sudo dpkg -s audispd-plugins If status is "not installed", this is a finding. Check that the records are being offloaded to a remote server with the following command: $ sudo grep -i active /etc/audisp/plugins.d/au-remote.conf active = yes If "active" is not set to "yes", or the line is commented out, this is a finding. Check that audisp-remote plugin is configured to send audit logs to a different system: $ sudo grep -i ^remote_server /etc/audisp/audisp-remote.conf remote_server = 192.168.122.126 If the "remote_server" parameter is not set, is set with a local address, or is set with an invalid address, this is a finding.

Fix: F-41475r654092_fix

Configure the audit event multiplexor to offload audit records to a different system or storage media from the system being audited. Install the audisp-remote plugin: $ sudo apt-get install audispd-plugins -y Set the audisp-remote plugin as active by editing the "/etc/audisp/plugins.d/au-remote.conf" file: $ sudo sed -i -E 's/active\s*=\s*no/active = yes/' /etc/audisp/plugins.d/au-remote.conf Set the address of the remote machine by editing the "/etc/audisp/audisp-remote.conf" file: $ sudo sed -i -E 's/(remote_server\s*=).*/\1 <remote addr>/' /etc/audisp/audisp-remote.conf where <remote addr> must be substituted by the address of the remote server receiving the audit log. Make the audit service reload its configuration files: $ sudo systemctl restart auditd.service

a

The Ubuntu operating system must immediately notify the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75% of the repository maximum audit record storage capacity.

AU-5 - Low - CCI-001855 - V-238307 - SV-238307r877389_rule

RMF Control

AU-5

Severity

L

CCI

CCI-001855

Version

UBTU-20-010217

Vuln IDs

V-238307

Rule IDs

SV-238307r877389_rule

If security personnel are not notified immediately when storage volume reaches 75% utilization, they are unable to plan for audit record storage capacity expansion.

Checks: C-41517r654094_chk

Verify the Ubuntu operating system notifies the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75% of the repository maximum audit record storage capacity with the following command: $ sudo grep ^space_left_action /etc/audit/auditd.conf space_left_action email $ sudo grep ^space_left /etc/audit/auditd.conf space_left 250000 If the "space_left" parameter is missing, set to blanks, or set to a value less than 25% of the space free in the allocated audit record storage, this is a finding. If the "space_left_action" parameter is missing or set to blanks, this is a finding. If the "space_left_action" is set to "syslog", the system logs the event but does not generate a notification, and this is a finding. If the "space_left_action" is set to "exec", the system executes a designated script. If this script informs the SA of the event, this is not a finding. If the "space_left_action" is set to "email", check the value of the "action_mail_acct" parameter with the following command: $ sudo grep ^action_mail_acct /etc/audit/auditd.conf action_mail_acct root@localhost The "action_mail_acct" parameter, if missing, defaults to "root". If the "action_mail_acct parameter" is not set to the email address of the SA(s) and/or ISSO, this is a finding. Note: If the email address of the System Administrator is on a remote system, a mail package must be available.

Fix: F-41476r654095_fix

Edit "/etc/audit/auditd.conf" and set the "space_left_action" parameter to "exec" or "email". If the "space_left_action" parameter is set to "email", set the "action_mail_acct" parameter to an email address for the SA and ISSO. If the "space_left_action" parameter is set to "exec", ensure the command being executed notifies the SA and ISSO. Edit "/etc/audit/auditd.conf" and set the "space_left" parameter to be at least 25% of the repository maximum audit record storage capacity.

a

The Ubuntu operating system must record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT).

AU-8 - Low - CCI-001890 - V-238308 - SV-238308r877383_rule

RMF Control

AU-8

Severity

L

CCI

CCI-001890

Version

UBTU-20-010230

Vuln IDs

V-238308

Rule IDs

SV-238308r877383_rule

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.

Checks: C-41518r654097_chk

To verify the time zone is configured to use UTC or GMT, run the following command. $ timedatectl status | grep -i "time zone" Timezone: UTC (UTC, +0000) If "Timezone" is not set to UTC or GMT, this is a finding.

Fix: F-41477r654098_fix

To configure the system time zone to use UTC or GMT, run the following command, replacing [ZONE] with UTC or GMT: $ sudo timedatectl set-timezone [ZONE]

b

The Ubuntu operating system must generate audit records for privileged activities, nonlocal maintenance, diagnostic sessions and other system-level access.

AU-12 - Medium - CCI-000172 - V-238309 - SV-238309r853427_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010244

Vuln IDs

V-238309

Rule IDs

SV-238309r853427_rule

If events associated with nonlocal administrative access or diagnostic sessions are not logged, a major tool for assessing and investigating attacks would not be available. This requirement addresses auditing-related issues associated with maintenance tools used specifically for diagnostic and repair actions on organizational information systems. Nonlocal maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. This requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system, for example, the software implementing "ping," "ls," "ipconfig," or the hardware and software implementing the monitoring port of an Ethernet switch. Satisfies: SRG-OS-000392-GPOS-00172, SRG-OS-000471-GPOS-00215

Checks: C-41519r654100_chk

Verify the Ubuntu operating system audits activities performed during nonlocal maintenance and diagnostic sessions. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep sudo.log -w /var/log/sudo.log -p wa -k maintenance If the command does not return lines that match the example or the lines are 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.

Fix: F-41478r654101_fix

Configure the Ubuntu operating system to audit activities performed during nonlocal maintenance and diagnostic sessions. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -w /var/log/sudo.log -p wa -k maintenance To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for any successful/unsuccessful use of unlink, unlinkat, rename, renameat, and rmdir system calls.

AU-12 - Medium - CCI-000172 - V-238310 - SV-238310r832953_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010267

Vuln IDs

V-238310

Rule IDs

SV-238310r832953_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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 system call rules are loaded into a matching engine that intercepts each syscall that all programs on the system makes. Therefore, it is very important to only use syscall rules when absolutely necessary since these affect performance. The more rules, the bigger the performance hit. The performance is helped, though, by combining syscalls into one rule whenever possible.

Checks: C-41520r832951_chk

Verify the Ubuntu operating system generates audit records for any successful/unsuccessful use of "unlink", "unlinkat", "rename", "renameat", and "rmdir" system calls. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep 'unlink\|rename\|rmdir' -a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat,rmdir -F auid>=1000 -F auid!=-1 -F key=delete -a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat,rmdir -F auid>=1000 -F auid!=-1 -F key=delete If the command does not return audit rules for the "unlink", "unlinkat", "rename", "renameat", and "rmdir" syscalls or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The "key" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

Fix: F-41479r832952_fix

Configure the audit system to generate audit events for any successful/unsuccessful use of "unlink", "unlinkat", "rename", "renameat", and "rmdir" system calls. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat,rmdir -F auid>=1000 -F auid!=4294967295 -k delete -a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat,rmdir -F auid>=1000 -F auid!=4294967295 -k delete Notes: For 32-bit architectures, only the 32-bit specific entries are required. To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for the /var/log/wtmp file.

AU-12 - Medium - CCI-000172 - V-238315 - SV-238315r654120_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010277

Vuln IDs

V-238315

Rule IDs

SV-238315r654120_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41525r654118_chk

Verify the Ubuntu operating system generates audit records showing start and stop times for user access to the system via the "/var/log/wtmp" file. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep '/var/log/wtmp' -w /var/log/wtmp -p wa -k logins If the command does not return a line matching the example 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.

Fix: F-41484r654119_fix

Configure the audit system to generate audit events showing start and stop times for user access via the "/var/log/wtmp" file. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -w /var/log/wtmp -p wa -k logins To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for the /var/run/utmp file.

AU-12 - Medium - CCI-000172 - V-238316 - SV-238316r880873_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010278

Vuln IDs

V-238316

Rule IDs

SV-238316r880873_rule

Without generating audit records specific to the security and mission needs of the organization, 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).

Checks: C-41526r880871_chk

Verify the Ubuntu operating system generates audit records showing start and stop times for user access to the system via the "/var/run/utmp" file. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep '/var/run/utmp' -w /var/run/utmp -p wa -k logins If the command does not return a line matching the example 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.

Fix: F-41485r880872_fix

Configure the audit system to generate audit events showing start and stop times for user access via the "/var/run/utmp" file. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -w /var/run/utmp -p wa -k logins To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records for the /var/log/btmp file.

AU-12 - Medium - CCI-000172 - V-238317 - SV-238317r654126_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010279

Vuln IDs

V-238317

Rule IDs

SV-238317r654126_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41527r654124_chk

Verify the Ubuntu operating system generates audit records showing start and stop times for user access to the system via the "/var/log/btmp" file. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep '/var/log/btmp' -w /var/log/btmp -p wa -k logins If the command does not return a line matching the example 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.

Fix: F-41486r654125_fix

Configure the audit system to generate audit events showing start and stop times for user access via the "/var/log/btmp file". Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -w /var/log/btmp -p wa -k logins To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records when successful/unsuccessful attempts to use modprobe command.

AU-12 - Medium - CCI-000172 - V-238318 - SV-238318r654129_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010296

Vuln IDs

V-238318

Rule IDs

SV-238318r654129_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41528r654127_chk

Verify if the Ubuntu operating system is configured to audit the execution of the module management program "modprobe" by running the following command: $ sudo auditctl -l | grep "/sbin/modprobe" -w /sbin/modprobe -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.

Fix: F-41487r654128_fix

Configure the Ubuntu operating system to audit the execution of the module management program "modprobe". Add or update the following rule in the "/etc/audit/rules.d/stig.rules" file: -w /sbin/modprobe -p x -k modules To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records when successful/unsuccessful attempts to use the kmod command.

AU-12 - Medium - CCI-000172 - V-238319 - SV-238319r654132_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010297

Vuln IDs

V-238319

Rule IDs

SV-238319r654132_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41529r654130_chk

Verify the Ubuntu operating system is configured to audit the execution of the module management program "kmod". Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep kmod -w /bin/kmod -p x -k module 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.

Fix: F-41488r654131_fix

Configure the Ubuntu operating system to audit the execution of the module management program "kmod". Add or update the following rule in the "/etc/audit/rules.d/stig.rules" file: -w /bin/kmod -p x -k modules To reload the rules file, issue the following command: $ sudo augenrules --load

b

The Ubuntu operating system must generate audit records when successful/unsuccessful attempts to use the fdisk command.

AU-12 - Medium - CCI-000172 - V-238320 - SV-238320r832956_rule

RMF Control

AU-12

Severity

M

CCI

Version

UBTU-20-010298

Vuln IDs

V-238320

Rule IDs

SV-238320r832956_rule

Without generating audit records that are specific to the security and mission needs of the organization, 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).

Checks: C-41530r832954_chk

Verify the Ubuntu operating system is configured to audit the execution of the partition management program "fdisk". Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep fdisk -w /usr/sbin/fdisk -p x -k fdisk 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.

Fix: F-41489r832955_fix

Configure the Ubuntu operating system to audit the execution of the partition management program "fdisk". Add or update the following rule in the "/etc/audit/rules.d/stig.rules" file: -w /usr/sbin/fdisk -p x -k fdisk To reload the rules file, issue the following command: $ sudo augenrules --load

a

The Ubuntu operating system must have a crontab script running weekly to offload audit events of standalone systems.

AU-4 - Low - CCI-001851 - V-238321 - SV-238321r853428_rule

RMF Control

AU-4

Severity

L

CCI

CCI-001851

Version

UBTU-20-010300

Vuln IDs

V-238321

Rule IDs

SV-238321r853428_rule

Information stored in one location is vulnerable to accidental or incidental deletion or alteration. Offloading is a common process in information systems with limited audit storage capacity.

Checks: C-41531r654136_chk

Note: If this is an interconnected system, this is Not Applicable. Verify there is a script that offloads audit data and that script runs weekly. Check if there is a script in the "/etc/cron.weekly" directory that offloads audit data: # sudo ls /etc/cron.weekly audit-offload Check if the script inside the file does offloading of audit logs to external media. If the script file does not exist or does not offload audit logs, this is a finding.

Fix: F-41490r654137_fix

Create a script that offloads audit logs to external media and runs weekly. The script must be located in the "/etc/cron.weekly" directory.

a

The Ubuntu operating system must limit the number of concurrent sessions to ten for all accounts and/or account types.

AC-10 - Low - CCI-000054 - V-238323 - SV-238323r877399_rule

RMF Control

AC-10

Severity

L

CCI

CCI-000054

Version

UBTU-20-010400

Vuln IDs

V-238323

Rule IDs

SV-238323r877399_rule

The Ubuntu operating system management includes the ability to control the number of users and user sessions that utilize an operating system. Limiting the number of allowed users and sessions per user is helpful in reducing the risks related to DoS attacks. This requirement addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions should be defined based upon mission needs and the operational environment for each system.

Checks: C-41533r654142_chk

Verify the Ubuntu operating system limits the number of concurrent sessions to 10 for all accounts and/or account types by running the following command: $ grep maxlogins /etc/security/limits.conf | grep -v '^* hard maxlogins' The result must contain the following line: * hard maxlogins 10 If the "maxlogins" item is missing or the value is not set to 10 or less or is commented out, this is a finding.

Fix: F-41492r654143_fix

Configure the Ubuntu operating system to limit the number of concurrent sessions to 10 for all accounts and/or account types. Add the following line to the top of the "/etc/security/limits.conf" file: * hard maxlogins 10

b

The Ubuntu operating system must monitor remote access methods.

AC-17 - Medium - CCI-000067 - V-238324 - SV-238324r832959_rule

RMF Control

AC-17

Severity

M

CCI

CCI-000067

Version

UBTU-20-010403

Vuln IDs

V-238324

Rule IDs

SV-238324r832959_rule

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 DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Automated monitoring of remote access sessions allows organizations to detect cyber attacks and also 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).

Checks: C-41534r832957_chk

Verify that the Ubuntu operating system monitors all remote access methods. Check that remote access methods are being logged by running the following command: $ grep -E -r '^(auth,authpriv\.\*|daemon\.\*)' /etc/rsyslog.* /etc/rsyslog.d/50-default.conf:auth,authpriv.* /var/log/auth.log /etc/rsyslog.d/50-default.conf:daemon.* /var/log/messages If "auth.*", "authpriv.*", or "daemon.*" are not configured to be logged in at least one of the config files, this is a finding.

Fix: F-41493r832958_fix

Configure the Ubuntu operating system to monitor all remote access methods by adding the following lines to the "/etc/rsyslog.d/50-default.conf" file: auth.*,authpriv.* /var/log/secure daemon.* /var/log/messages For the changes to take effect, restart the "rsyslog" service with the following command: $ sudo systemctl restart rsyslog.service

b

The Ubuntu operating system must encrypt all stored passwords with a FIPS 140-2 approved cryptographic hashing algorithm.

IA-7 - Medium - CCI-000803 - V-238325 - SV-238325r654150_rule

RMF Control

IA-7

Severity

M

CCI

CCI-000803

Version

UBTU-20-010404

Vuln IDs

V-238325

Rule IDs

SV-238325r654150_rule

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.

Checks: C-41535r654148_chk

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: $ cat /etc/login.defs | grep -i encrypt_method ENCRYPT_METHOD SHA512 If "ENCRYPT_METHOD" does not equal SHA512 or greater, this is a finding.

Fix: F-41494r654149_fix

Configure the Ubuntu operating system to encrypt all stored passwords. Edit/modify the following line in the "/etc/login.defs" file and set "ENCRYPT_METHOD" to SHA512: ENCRYPT_METHOD SHA512

c

The Ubuntu operating system must not have the telnet package installed.

IA-5 - High - CCI-000197 - V-238326 - SV-238326r877396_rule

RMF Control

IA-5

Severity

H

CCI

CCI-000197

Version

UBTU-20-010405

Vuln IDs

V-238326

Rule IDs

SV-238326r877396_rule

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.

Checks: C-41536r654151_chk

Verify that the telnet package is not installed on the Ubuntu operating system by running the following command: $ dpkg -l | grep telnetd If the package is installed, this is a finding.

Fix: F-41495r654152_fix

Remove the telnet package from the Ubuntu operating system by running the following command: $ sudo apt-get remove telnetd

c

The Ubuntu operating system must not have the rsh-server package installed.

CM-7 - High - CCI-000381 - V-238327 - SV-238327r654156_rule

RMF Control

CM-7

Severity

H

CCI

CCI-000381

Version

UBTU-20-010406

Vuln IDs

V-238327

Rule IDs

SV-238327r654156_rule

It is detrimental for operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Examples of non-essential capabilities include, but are not limited to, games, software packages, tools, and demonstration software, not related to requirements or providing a wide array of functionality not required for every mission, but which cannot be disabled.

Checks: C-41537r654154_chk

Verify the rsh-server package is installed with the following command: $ dpkg -l | grep rsh-server If the rsh-server package is installed, this is a finding.

Fix: F-41496r654155_fix

Configure the Ubuntu operating system to disable non-essential capabilities by removing the rsh-server package from the system with the following command: $ sudo apt-get remove rsh-server

b

The Ubuntu operating system must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the PPSM CAL and vulnerability assessments.

CM-7 - Medium - CCI-000382 - V-238328 - SV-238328r654159_rule

RMF Control

CM-7

Severity

M

CCI

CCI-000382

Version

UBTU-20-010407

Vuln IDs

V-238328

Rule IDs

SV-238328r654159_rule

In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. Operating systems are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., VPN and IPS); however, doing so increases risk over limiting the services provided by any one component. To support the requirements and principles of least functionality, the operating system must support the organizational requirements, providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues.

Checks: C-41538r654157_chk

Verify the Ubuntu operating system is configured to prohibit or restrict the use of functions, ports, protocols, and/or services as defined in the Ports, Protocols, and Services Management (PPSM) Category Assignments List (CAL) and vulnerability assessments. Check the firewall configuration for any unnecessary or prohibited functions, ports, protocols, and/or services by running the following command: $ sudo ufw show raw Chain OUTPUT (policy ACCEPT) target prot opt sources destination Chain INPUT (policy ACCEPT 1 packets, 40 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Ask the System Administrator for the site or program PPSM CLSA. Verify the services allowed by the firewall match the PPSM CLSA. If there are any additional ports, protocols, or services that are not included in the PPSM CLSA, this is a finding. If there are any ports, protocols, or services that are prohibited by the PPSM CAL, this is a finding.

Fix: F-41497r654158_fix

Add all ports, protocols, or services allowed by the PPSM CLSA by using the following command: $ sudo ufw allow <direction> <port/protocol/service> where the direction is "in" or "out" and the port is the one corresponding to the protocol or service allowed. To deny access to ports, protocols, or services, use: $ sudo ufw deny <direction> <port/protocol/service>

b

The Ubuntu operating system must prevent direct login into the root account.

IA-2 - Medium - CCI-000770 - V-238329 - SV-238329r654162_rule

RMF Control

IA-2

Severity

M

CCI

CCI-000770

Version

UBTU-20-010408

Vuln IDs

V-238329

Rule IDs

SV-238329r654162_rule

To assure individual accountability and prevent unauthorized access, organizational users must be individually identified and authenticated. A group authenticator is a generic account used by multiple individuals. Use of a group authenticator alone does not uniquely identify individual users. Examples of the group authenticator is the UNIX OS "root" user account, the Windows "Administrator" account, the "sa" account, or a "helpdesk" account. For example, the UNIX and Windows operating systems offer a 'switch user' capability allowing users to authenticate with their individual credentials and, when needed, 'switch' to the administrator role. This method provides for unique individual authentication prior to using a group authenticator. Users (and any processes acting on behalf of users) need to be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization, which outlines specific user actions that can be performed on the operating system without identification or authentication. Requiring individuals to be authenticated with an individual authenticator prior to using a group authenticator allows for traceability of actions, as well as adding an additional level of protection of the actions that can be taken with group account knowledge.

Checks: C-41539r654160_chk

Verify the Ubuntu operating system prevents direct logins to the root account with the following command: $ sudo passwd -S root root L 04/23/2020 0 99999 7 -1 If the output does not contain "L" in the second field to indicate the account is locked, this is a finding.

Fix: F-41498r654161_fix

Configure the Ubuntu operating system to prevent direct logins to the root account by performing the following operations: $ sudo passwd -l root

b

The Ubuntu operating system must disable account identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.

IA-4 - Medium - CCI-000795 - V-238330 - SV-238330r928525_rule

RMF Control

IA-4

Severity

M

CCI

CCI-000795

Version

UBTU-20-010409

Vuln IDs

V-238330

Rule IDs

SV-238330r928525_rule

Inactive identifiers pose a risk to systems and applications because attackers may exploit an inactive identifier and potentially obtain undetected access to the system. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Operating systems need to track periods of inactivity and disable application identifiers after 35 days of inactivity.

Checks: C-41540r654163_chk

Verify the account identifiers (individuals, groups, roles, and devices) are disabled after 35 days of inactivity with the following command: Check the account inactivity value by performing the following command: $ sudo grep INACTIVE /etc/default/useradd INACTIVE=35 If "INACTIVE" is not set to a value 0<[VALUE]<=35, or is commented out, this is a finding.

Fix: F-41499r928524_fix

Configure the Ubuntu operating system to disable account identifiers after 35 days of inactivity since the password expiration. Run the following command to change the configuration for adduser: $ sudo useradd -D -f 35 Note: DoD recommendation is 35 days, but a lower value is acceptable. The value "0" will disable the account immediately after the password expires.

a

The Ubuntu operating system must automatically expire temporary accounts within 72 hours.

AC-2 - Low - CCI-001682 - V-238331 - SV-238331r902885_rule

RMF Control

AC-2

Severity

L

CCI

CCI-001682

Version

UBTU-20-010410

Vuln IDs

V-238331

Rule IDs

SV-238331r902885_rule

Temporary accounts are privileged or nonprivileged accounts that are established during pressing circumstances, such as new software or hardware configuration or an incident response, where the need for prompt account activation requires bypassing normal account authorization procedures. If any inactive temporary accounts are left enabled on the system and are not either manually removed or automatically expired within 72 hours, the security posture of the system will be degraded and exposed to exploitation by unauthorized users or insider threat actors. Temporary accounts are different from emergency accounts. Emergency accounts, also known as "last resort" or "break glass" accounts, are local logon accounts enabled on the system for emergency use by authorized system administrators to manage a system when standard logon methods are failing or not available. Emergency accounts are not subject to manual removal or scheduled expiration requirements. The automatic expiration of temporary accounts may be extended as needed by the circumstances but it must not be extended indefinitely. A documented permanent account should be established for privileged users who need long-term maintenance accounts.

Checks: C-41541r902860_chk

Verify temporary accounts have been provisioned with an expiration date of 72 hours. For every existing temporary account, run the following command to obtain its account expiration information: $ sudo chage -l <temporary_account_name> | grep -i "account expires" Verify each of these accounts has an expiration date set within 72 hours. If any temporary accounts have no expiration date set or do not expire within 72 hours, this is a finding.

Fix: F-41500r902861_fix

Configure the operating system to expire temporary accounts after 72 hours with the following command: $ sudo chage -E $(date -d +3days +%Y-%m-%d) <temporary_account_name>

b

The Ubuntu operating system must set a sticky bit on all public directories to prevent unauthorized and unintended information transferred via shared system resources.

SC-4 - Medium - CCI-001090 - V-238332 - SV-238332r654171_rule

RMF Control

SC-4

Severity

M

CCI

CCI-001090

Version

UBTU-20-010411

Vuln IDs

V-238332

Rule IDs

SV-238332r654171_rule

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 DoD 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.

Checks: C-41542r654169_chk

Verify that all public (world-writeable) directories have the public sticky bit set. Find world-writable directories that lack the sticky bit by running the following command: $ sudo find / -type d -perm -002 ! -perm -1000 If any world-writable directories are found missing the sticky bit, this is a finding.

Fix: F-41501r654170_fix

Configure all public directories to have the sticky bit set to prevent unauthorized and unintended information transferred via shared system resources. Set the sticky bit on all public directories using the following command, replacing "[Public Directory]" with any directory path missing the sticky bit: $ sudo chmod +t [Public Directory]

b

The Ubuntu operating system must be configured to use TCP syncookies.

SC-5 - Medium - CCI-001095 - V-238333 - SV-238333r654174_rule

RMF Control

SC-5

Severity

M

CCI

CCI-001095

Version

UBTU-20-010412

Vuln IDs

V-238333

Rule IDs

SV-238333r654174_rule

DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. Managing excess capacity ensures that sufficient capacity is available to counter flooding attacks. Employing increased capacity and service redundancy may reduce the susceptibility to some DoS attacks. Managing excess capacity may include, for example, establishing selected usage priorities, quotas, or partitioning.

Checks: C-41543r654172_chk

Verify the Ubuntu operating system is configured to use TCP syncookies. Check the value of TCP syncookies with the following command: $ sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_syncookies = 1 If the value is not "1", this is a finding. Check the saved value of TCP syncookies with the following command: $ sudo grep -i net.ipv4.tcp_syncookies /etc/sysctl.conf /etc/sysctl.d/* | grep -v '#' If no output is returned, this is a finding.

Fix: F-41502r654173_fix

Configure the Ubuntu operating system to use TCP syncookies by running the following command: $ sudo sysctl -w net.ipv4.tcp_syncookies=1 If "1" is not the system's default value, add or update the following line in "/etc/sysctl.conf": net.ipv4.tcp_syncookies = 1

b

The Ubuntu operating system must disable kernel core dumps so that it can fail to a secure state if system initialization fails, shutdown fails or aborts fail.

SC-24 - Medium - CCI-001190 - V-238334 - SV-238334r654177_rule

RMF Control

SC-24

Severity

M

CCI

CCI-001190

Version

UBTU-20-010413

Vuln IDs

V-238334

Rule IDs

SV-238334r654177_rule

Kernel core dumps may contain the full contents of system memory at the time of the crash. Kernel core dumps may consume a considerable amount of disk space and may result in denial of service by exhausting the available space on the target file system partition.

Checks: C-41544r654175_chk

Verify that kernel core dumps are disabled unless needed. Check if "kdump" service is active with the following command: $ systemctl is-active kdump.service inactive If the "kdump" service is active, ask the SA if the use of the service is required and documented with the ISSO. If the service is active and is not documented, this is a finding.

Fix: F-41503r654176_fix

If kernel core dumps are not required, disable the "kdump" service with the following command: $ sudo systemctl disable kdump.service If kernel core dumps are required, document the need with the ISSO.

b

Ubuntu operating systems handling data requiring "data at rest" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest.

SC-28 - Medium - CCI-001199 - V-238335 - SV-238335r654180_rule

RMF Control

SC-28

Severity

M

CCI

CCI-001199

Version

UBTU-20-010414

Vuln IDs

V-238335

Rule IDs

SV-238335r654180_rule

Information at rest refers to the state of information when it is located on a secondary storage device (e.g., disk drive and tape drive, when used for backups) within an operating system. This requirement addresses protection of user-generated data, as well as operating system-specific configuration data. Organizations may choose to employ different mechanisms to achieve confidentiality and integrity protections, as appropriate, in accordance with the security category and/or classification of the information.

Checks: C-41545r654178_chk

If there is a documented and approved reason for not having data-at-rest encryption, this requirement is Not Applicable. Verify the Ubuntu operating system prevents unauthorized disclosure or modification of all information requiring at-rest protection by using disk encryption. Determine the partition layout for the system with the following command: #sudo fdisk -l (..) Disk /dev/vda: 15 GiB, 16106127360 bytes, 31457280 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 83298450-B4E3-4B19-A9E4-7DF147A5FEFB Device Start End Sectors Size Type /dev/vda1 2048 4095 2048 1M BIOS boot /dev/vda2 4096 2101247 2097152 1G Linux filesystem /dev/vda3 2101248 31455231 29353984 14G Linux filesystem (...) Verify the system partitions are all encrypted with the following command: # more /etc/crypttab Every persistent disk partition present must have an entry in the file. If any partitions other than the boot partition or pseudo file systems (such as /proc or /sys) are not listed, this is a finding.

Fix: F-41504r654179_fix

To encrypt an entire partition, dedicate a partition for encryption in the partition layout. Note: Encrypting a partition in an already-installed system is more difficult because it will need to be resized and existing partitions changed.

a

The Ubuntu operating system must deploy Endpoint Security for Linux Threat Prevention (ENSLTP).

SI-2 - Low - CCI-001233 - V-238336 - SV-238336r858538_rule

RMF Control

SI-2

Severity

L

CCI

CCI-001233

Version

UBTU-20-010415

Vuln IDs

V-238336

Rule IDs

SV-238336r858538_rule

Without the use of automated mechanisms to scan for security flaws on a continuous and/or periodic basis, the operating system or other system components may remain vulnerable to the exploits presented by undetected software flaws. To support this requirement, the operating system may have an integrated solution incorporating continuous scanning using HBSS and periodic scanning using other tools, as specified in the requirement.

Checks: C-41546r858536_chk

The Ubuntu operating system is not compliant with this requirement; hence, it is a finding. However, the severity level can be mitigated to a CAT III if the ENSLTP module is installed and running. Check that the "mcafeetp" package has been installed: # dpkg -l | grep mcafeetp If the "mcafeetp" package is not installed, this finding will remain as a CAT II. Check that the daemon is running: # /opt/McAfee/ens/tp/init/mfetpd-control.sh status If the daemon is not running, this finding will remain as a CAT II.

Fix: F-41505r858537_fix

The Ubuntu operating system is not compliant with this requirement; however, the severity level can be mitigated to a CAT III if the ENSLTP module is installed and running. Configure the Ubuntu operating system to use ENSLTP. Install the "mcafeetp" package via the ePO server.

b

The Ubuntu operating system must generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.

SI-11 - Medium - CCI-001312 - V-238337 - SV-238337r880876_rule

RMF Control

SI-11

Severity

M

CCI

CCI-001312

Version

UBTU-20-010416

Vuln IDs

V-238337

Rule IDs

SV-238337r880876_rule

Any operating system providing too much information in error messages risks compromising the data and security of the structure, and content of error messages needs to be carefully considered by the organization. Organizations carefully consider the structure/content of error messages. The extent to which information systems are able to identify and handle error conditions is guided by organizational policy and operational requirements. Information that could be exploited by adversaries includes, for example, erroneous logon attempts with passwords entered by mistake as the username, mission/business information that can be derived from (if not stated explicitly by) information recorded, and personal information, such as account numbers, social security numbers, and credit card numbers. The /var/log/btmp, /var/log/wtmp, and /var/log/lastlog files have group write and global read permissions to allow for the lastlog function to perform. Limiting the permissions beyond this configuration will result in the failure of functions that rely on the lastlog database.

Checks: C-41547r880874_chk

Verify the Ubuntu operating system has all system log files under the "/var/log" directory with a permission set to "640" or less permissive by using the following command: Note: The btmp, wtmp, and lastlog files are excluded. Refer to the Discussion for details. $ sudo find /var/log -perm /137 ! -name '*[bw]tmp' ! -name '*lastlog' -type f -exec stat -c "%n %a" {} \; If the command displays any output, this is a finding.

Fix: F-41506r880875_fix

Configure the Ubuntu operating system to set permissions of all log files under the "/var/log" directory to "640" or more restricted by using the following command: Note: The btmp, wtmp, and lastlog files are excluded. Refer to the Discussion for details. $ sudo find /var/log -perm /137 ! -name '*[bw]tmp' ! -name '*lastlog' -type f -exec chmod 640 '{}' \;

b

The Ubuntu operating system must configure the /var/log directory to be group-owned by syslog.

SI-11 - Medium - CCI-001314 - V-238338 - SV-238338r654189_rule

RMF Control

SI-11

Severity

M

CCI

Version

UBTU-20-010417

Vuln IDs

V-238338

Rule IDs

SV-238338r654189_rule

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Checks: C-41548r654187_chk

Verify that the Ubuntu operating system configures the "/var/log" directory to be group-owned by syslog with the following command: $ sudo stat -c "%n %G" /var/log /var/log syslog If the "/var/log" directory is not group-owned by syslog, this is a finding.

Fix: F-41507r654188_fix

Configure the Ubuntu operating system to have syslog group-own the "/var/log" directory by running the following command: $ sudo chgrp syslog /var/log

b

The Ubuntu operating system must configure the /var/log directory to be owned by root.

SI-11 - Medium - CCI-001314 - V-238339 - SV-238339r654192_rule

RMF Control

SI-11

Severity

M

CCI

Version

UBTU-20-010418

Vuln IDs

V-238339

Rule IDs

SV-238339r654192_rule

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Checks: C-41549r654190_chk

Verify the Ubuntu operating system configures the "/var/log" directory to be owned by root with the following command: $ sudo stat -c "%n %U" /var/log /var/log root If the "/var/log" directory is not owned by root, this is a finding.

Fix: F-41508r654191_fix

Configure the Ubuntu operating system to have root own the "/var/log" directory by running the following command: $ sudo chown root /var/log

b

The Ubuntu operating system must configure the /var/log directory to have mode "0755" or less permissive.

SI-11 - Medium - CCI-001314 - V-238340 - SV-238340r880879_rule

RMF Control

SI-11

Severity

M

CCI

Version

UBTU-20-010419

Vuln IDs

V-238340

Rule IDs

SV-238340r880879_rule

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, personally identifiable information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Checks: C-41550r880877_chk

Verify that the Ubuntu operating system configures the "/var/log" directory with a mode of "755" or less permissive with the following command: Note: If rsyslog is active and enabled on the operating system, this requirement is not applicable. $ stat -c "%n %a" /var/log /var/log 755 If a value of "755" or less permissive is not returned, this is a finding.

Fix: F-41509r880878_fix

Configure the Ubuntu operating system to have permissions of "0755" for the "/var/log" directory by running the following command: $ sudo chmod 0755 /var/log

b

The Ubuntu operating system must configure the /var/log/syslog file to be group-owned by adm.

SI-11 - Medium - CCI-001314 - V-238341 - SV-238341r654198_rule

RMF Control

SI-11

Severity

M

CCI

Version

UBTU-20-010420

Vuln IDs

V-238341

Rule IDs

SV-238341r654198_rule

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Checks: C-41551r654196_chk

Verify that the Ubuntu operating system configures the "/var/log/syslog" file to be group-owned by adm with the following command: $ sudo stat -c "%n %G" /var/log/syslog /var/log/syslog adm If the "/var/log/syslog" file is not group-owned by adm, this is a finding.

Fix: F-41510r654197_fix

Configure the Ubuntu operating system to have adm group-own the "/var/log/syslog" file by running the following command: $ sudo chgrp adm /var/log/syslog

b

The Ubuntu operating system must configure /var/log/syslog file to be owned by syslog.

SI-11 - Medium - CCI-001314 - V-238342 - SV-238342r654201_rule

RMF Control

SI-11

Severity

M

CCI

Version

UBTU-20-010421

Vuln IDs

V-238342

Rule IDs

SV-238342r654201_rule

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Checks: C-41552r654199_chk

Verify that the Ubuntu operating system configures the "/var/log/syslog" file to be owned by syslog with the following command: $ sudo stat -c "%n %U" /var/log/syslog /var/log/syslog syslog If the "/var/log/syslog" file is not owned by syslog, this is a finding.

Fix: F-41511r654200_fix

Configure the Ubuntu operating system to have syslog own the "/var/log/syslog" file by running the following command: $ sudo chown syslog /var/log/syslog

b

The Ubuntu operating system must configure /var/log/syslog file with mode 0640 or less permissive.

SI-11 - Medium - CCI-001314 - V-238343 - SV-238343r654204_rule

RMF Control

SI-11

Severity

M

CCI

Version

UBTU-20-010422

Vuln IDs

V-238343

Rule IDs

SV-238343r654204_rule

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Checks: C-41553r654202_chk

Verify that the Ubuntu operating system configures the "/var/log/syslog" file with mode 0640 or less permissive by running the following command: $ sudo stat -c "%n %a" /var/log/syslog /var/log/syslog 640 If a value of "640" or less permissive is not returned, this is a finding.

Fix: F-41512r654203_fix

Configure the Ubuntu operating system to have permissions of 0640 for the "/var/log/syslog" file by running the following command: $ sudo chmod 0640 /var/log/syslog

b

The Ubuntu operating system must have directories that contain system commands set to a mode of 0755 or less permissive.

AU-9 - Medium - CCI-001495 - V-238344 - SV-238344r654207_rule

RMF Control

AU-9

Severity

M

CCI

CCI-001495

Version

UBTU-20-010423

Vuln IDs

V-238344

Rule IDs

SV-238344r654207_rule

Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user has in order to make access decisions regarding the deletion of audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Checks: C-41554r654205_chk

Verify the system commands directories have mode 0755 or less permissive: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Check that the system command directories have mode 0755 or less permissive with the following command: $ find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -perm /022 -type d -exec stat -c "%n %a" '{}' \; If any directories are found to be group-writable or world-writable, this is a finding.

Fix: F-41513r654206_fix

Configure the system commands directories to be protected from unauthorized access. Run the following command: $ sudo find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -perm /022 -type d -exec chmod -R 755 '{}' \;

b

The Ubuntu operating system must have directories that contain system commands owned by root.

AU-9 - Medium - CCI-001495 - V-238345 - SV-238345r654210_rule

RMF Control

AU-9

Severity

M

CCI

CCI-001495

Version

UBTU-20-010424

Vuln IDs

V-238345

Rule IDs

SV-238345r654210_rule

Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user has in order to make access decisions regarding the deletion of audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Checks: C-41555r654208_chk

Verify the system commands directories are owned by root: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Use the following command for the check: $ sudo find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -user root -type d -exec stat -c "%n %U" '{}' \; If any system commands directories are returned, this is a finding.

Fix: F-41514r654209_fix

Configure the system commands directories to be protected from unauthorized access. Run the following command: $ sudo find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -user root -type d -exec chown root '{}' \;

b

The Ubuntu operating system must have directories that contain system commands group-owned by root.

AU-9 - Medium - CCI-001495 - V-238346 - SV-238346r654213_rule

RMF Control

AU-9

Severity

M

CCI

CCI-001495

Version

UBTU-20-010425

Vuln IDs

V-238346

Rule IDs

SV-238346r654213_rule

Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information. Operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user has in order to make access decisions regarding the deletion of audit tools. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Checks: C-41556r654211_chk

Verify the system commands directories are group-owned by root: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Run the check with the following command: $ sudo find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -group root -type d -exec stat -c "%n %G" '{}' \; If any system commands directories are returned that are not Set Group ID up on execution (SGID) files and owned by a privileged account, this is a finding.

Fix: F-41515r654212_fix

Configure the system commands directories to be protected from unauthorized access. Run the following command: $ sudo find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -group root -type d -exec chgrp root '{}' \;

b

The Ubuntu operating system library files must have mode 0755 or less permissive.

CM-5 - Medium - CCI-001499 - V-238347 - SV-238347r654216_rule

RMF Control

CM-5

Severity

M

CCI

Version

UBTU-20-010426

Vuln IDs

V-238347

Rule IDs

SV-238347r654216_rule

If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Checks: C-41557r654214_chk

Verify the system-wide shared library files contained in the directories "/lib", "/lib64", and "/usr/lib" have mode 0755 or less permissive with the following command: $ sudo find /lib /lib64 /usr/lib -perm /022 -type f -exec stat -c "%n %a" '{}' \; /usr/lib64/pkcs11-spy.so If any files are found to be group-writable or world-writable, this is a finding.

Fix: F-41516r654215_fix

Configure the library files to be protected from unauthorized access. Run the following command: $ sudo find /lib /lib64 /usr/lib -perm /022 -type f -exec chmod 755 '{}' \;

b

The Ubuntu operating system library directories must have mode 0755 or less permissive.

CM-5 - Medium - CCI-001499 - V-238348 - SV-238348r654219_rule

RMF Control

CM-5

Severity

M

CCI

Version

UBTU-20-010427

Vuln IDs

V-238348

Rule IDs

SV-238348r654219_rule

If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Checks: C-41558r654217_chk

Verify the system-wide shared library directories "/lib", "/lib64", and "/usr/lib have mode 0755 or less permissive with the following command: $ sudo find /lib /lib64 /usr/lib -perm /022 -type d -exec stat -c "%n %a" '{}' \; If any of the aforementioned directories are found to be group-writable or world-writable, this is a finding.

Fix: F-41517r654218_fix

Configure the shared library directories to be protected from unauthorized access. Run the following command: $ sudo find /lib /lib64 /usr/lib -perm /022 -type d -exec chmod 755 '{}' \;

b

The Ubuntu operating system library files must be owned by root.

CM-5 - Medium - CCI-001499 - V-238349 - SV-238349r654222_rule

RMF Control

CM-5

Severity

M

CCI

Version

UBTU-20-010428

Vuln IDs

V-238349

Rule IDs

SV-238349r654222_rule

If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Checks: C-41559r654220_chk

Verify the system-wide shared library files contained in the directories "/lib", "/lib64", and "/usr/lib" are owned by root with the following command: $ sudo find /lib /usr/lib /lib64 ! -user root -type f -exec stat -c "%n %U" '{}' \; If any system-wide library file is returned, this is a finding.

Fix: F-41518r654221_fix

Configure the system library files to be protected from unauthorized access. Run the following command: $ sudo find /lib /usr/lib /lib64 ! -user root -type f -exec chown root '{}' \;

b

The Ubuntu operating system library directories must be owned by root.

CM-5 - Medium - CCI-001499 - V-238350 - SV-238350r654225_rule

RMF Control

CM-5

Severity

M

CCI

Version

UBTU-20-010429

Vuln IDs

V-238350

Rule IDs

SV-238350r654225_rule

If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Checks: C-41560r654223_chk

Verify the system-wide shared library directories "/lib", "/lib64", and "/usr/lib" are owned by root with the following command: $ sudo find /lib /usr/lib /lib64 ! -user root -type d -exec stat -c "%n %U" '{}' \; If any system-wide library directory is returned, this is a finding.

Fix: F-41519r654224_fix

Configure the library files and their respective parent directories to be protected from unauthorized access. Run the following command: $ sudo find /lib /usr/lib /lib64 ! -user root -type d -exec chown root '{}' \;

b

The Ubuntu operating system library files must be group-owned by root or a system account.

CM-5 - Medium - CCI-001499 - V-238351 - SV-238351r832962_rule

RMF Control

CM-5

Severity

M

CCI

Version

UBTU-20-010430

Vuln IDs

V-238351

Rule IDs

SV-238351r832962_rule

If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Checks: C-41561r832960_chk

Verify the system-wide library files contained in the directories "/lib", "/lib64", and "/usr/lib" are group-owned by root, or a required system account, with the following command: $ sudo find /lib /usr/lib /lib64 ! -group root -type f -exec stat -c "%n %G" '{}' \; If any system-wide shared library file is returned and is not group-owned by a required system account, this is a finding.

Fix: F-41520r832961_fix

Configure the system library files to be protected from unauthorized access. Run the following command, replacing "[FILE]" with any system command file not group-owned by "root" or a required system account: $ sudo chgrp root [FILE]

b

The Ubuntu operating system library directories must be group-owned by root.

CM-5 - Medium - CCI-001499 - V-238352 - SV-238352r654231_rule

RMF Control

CM-5

Severity

M

CCI

Version

UBTU-20-010431

Vuln IDs

V-238352

Rule IDs

SV-238352r654231_rule

If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Checks: C-41562r654229_chk

Verify the system-wide library directories "/lib", "/lib64", and "/usr/lib" are group-owned by root with the following command: $ sudo find /lib /usr/lib /lib64 ! -group root -type d -exec stat -c "%n %G" '{}' \; If any system-wide shared library directory is returned, this is a finding.

Fix: F-41521r654230_fix

Configure the system library directories to be protected from unauthorized access. Run the following command: $ sudo find /lib /usr/lib /lib64 ! -group root -type d -exec chgrp root '{}' \;

b

The Ubuntu operating system must be configured to preserve log records from failure events.

SC-24 - Medium - CCI-001665 - V-238353 - SV-238353r654234_rule

RMF Control

SC-24

Severity

M

CCI

CCI-001665

Version

UBTU-20-010432

Vuln IDs

V-238353

Rule IDs

SV-238353r654234_rule

Failure to a known state can address safety or security in accordance with the mission/business needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving operating system state information helps to facilitate operating system restart and return to the operational mode of the organization with least disruption to mission/business processes.

Checks: C-41563r654232_chk

Verify the log service is configured to collect system failure events. Check that the log service is installed properly with the following command: $ dpkg -l | grep rsyslog ii rsyslog 8.32.0-1ubuntu4 amd64 reliable system and kernel logging daemon If the "rsyslog" package is not installed, this is a finding. Check that the log service is enabled with the following command: $ systemctl is-enabled rsyslog enabled If the command above returns "disabled", this is a finding. Check that the log service is properly running and active on the system with the following command: $ systemctl is-active rsyslog active If the command above returns "inactive", this is a finding.

Fix: F-41522r654233_fix

Configure the log service to collect failure events. Install the log service (if the log service is not already installed) with the following command: $ sudo apt-get install rsyslog Enable the log service with the following command: $ sudo systemctl enable --now rsyslog

b

The Ubuntu operating system must have an application firewall installed in order to control remote access methods.

AC-17 - Medium - CCI-002314 - V-238354 - SV-238354r853429_rule

RMF Control

AC-17

Severity

M

CCI

CCI-002314

Version

UBTU-20-010433

Vuln IDs

V-238354

Rule IDs

SV-238354r853429_rule

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 DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Ubuntu operating system 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).

Checks: C-41564r654235_chk

Verify that the Uncomplicated Firewall is installed with the following command: $ dpkg -l | grep ufw ii ufw 0.36-6 If the "ufw" package is not installed, ask the System Administrator if another application firewall is installed. If no application firewall is installed, this is a finding.

Fix: F-41523r654236_fix

Install the Uncomplicated Firewall by using the following command: $ sudo apt-get install ufw

b

The Ubuntu operating system must enable and run the uncomplicated firewall(ufw).

AC-17 - Medium - CCI-002314 - V-238355 - SV-238355r853430_rule

RMF Control

AC-17

Severity

M

CCI

CCI-002314

Version

UBTU-20-010434

Vuln IDs

V-238355

Rule IDs

SV-238355r853430_rule

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 DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Ubuntu operating system 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).

Checks: C-41565r654238_chk

Verify the Uncomplicated Firewall is enabled on the system by running the following command: $ systemctl is-enabled ufw If the above command returns the status as "disabled", this is a finding. Verify the Uncomplicated Firewall is active on the system by running the following command: $ systemctl is-active ufw If the above command returns "inactive" or any kind of error, this is a finding. If the Uncomplicated Firewall is not installed, ask the System Administrator if another application firewall is installed. If no application firewall is installed, this is a finding.

Fix: F-41524r654239_fix

Enable the Uncomplicated Firewall by using the following command: $ sudo systemctl enable --now ufw.service

b

The Ubuntu operating system must, for networked systems, compare internal information system clocks at least every 24 hours with a server which is synchronized to one of the redundant United States Naval Observatory (USNO) time servers, or a time server designated for the appropriate DoD network (NIPRNet/SIPRNet), and/or the Global Positioning System (GPS).

AU-8 - Medium - CCI-001891 - V-238356 - SV-238356r877038_rule

RMF Control

AU-8

Severity

M

CCI

CCI-001891

Version

UBTU-20-010435

Vuln IDs

V-238356

Rule IDs

SV-238356r877038_rule

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).

Checks: C-41566r808490_chk

If the system is not networked, this requirement is Not Applicable. The system clock must be configured to compare the system clock at least every 24 hours to the authoritative time source. Check the value of "maxpoll" in the "/etc/chrony/chrony.conf" file with the following command: $ sudo grep maxpoll /etc/chrony/chrony.conf server tick.usno.navy.mil iburst maxpoll 16 If the "maxpoll" option is set to a number greater than 16 or the line is commented out, this is a finding. Verify that the "chrony.conf" file is configured to an authoritative DoD time source by running the following command: $ grep -i server /etc/chrony/chrony.conf server tick.usno.navy.mil iburst maxpoll 16 server tock.usno.navy.mil iburst maxpoll 16 server ntp2.usno.navy.mil iburst maxpoll 16 If the parameter "server" is not set, is not set to an authoritative DoD time source, or is commented out, this is a finding.

Fix: F-41525r808491_fix

If the system is not networked, this requirement is Not Applicable. To configure the system clock to compare the system clock at least every 24 hours to the authoritative time source, edit the "/etc/chrony/chrony.conf" file. Add or correct the following lines, by replacing "[source]" in the following line with an authoritative DoD time source: server [source] iburst maxpoll = 16 If the "chrony" service was running and the value of "maxpoll" or "server" was updated, the service must be restarted using the following command: $ sudo systemctl restart chrony.service

a

The Ubuntu operating system must synchronize internal information system clocks to the authoritative time source when the time difference is greater than one second.

AU-8 - Low - CCI-002046 - V-238357 - SV-238357r853432_rule

RMF Control

AU-8

Severity

L

CCI

CCI-002046

Version

UBTU-20-010436

Vuln IDs

V-238357

Rule IDs

SV-238357r853432_rule

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. 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 setting time periods for different types of systems (e.g., financial, legal, or mission-critical systems). Organizations should also consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints). This requirement is related to the comparison done every 24 hours in SRG-OS-000355 because a comparison must be done in order to determine the time difference.

Checks: C-41567r654244_chk

Verify the operating system synchronizes internal system clocks to the authoritative time source when the time difference is greater than one second. Check the value of "makestep" by running the following command: $ sudo grep makestep /etc/chrony/chrony.conf makestep 1 -1 If the makestep option is commented out or is not set to "1 -1", this is a finding.

Fix: F-41526r654245_fix

Configure chrony to synchronize the internal system clocks to the authoritative source when the time difference is greater than one second by doing the following: Edit the "/etc/chrony/chrony.conf" file and add: makestep 1 -1 Restart the chrony service: $ sudo systemctl restart chrony.service

b

The Ubuntu operating system must notify designated personnel if baseline configurations are changed in an unauthorized manner. The file integrity tool must notify the system administrator (SA) when changes to the baseline configuration or anomalies in the operation of any security functions are discovered.

CM-3 - Medium - CCI-001744 - V-238358 - SV-238358r917812_rule

RMF Control

CM-3

Severity

M

CCI

CCI-001744

Version

UBTU-20-010437

Vuln IDs

V-238358

Rule IDs

SV-238358r917812_rule

Unauthorized changes to the baseline configuration could make the system vulnerable to various attacks or allow unauthorized access to the operating system. Changes to operating system configurations can have unintended side effects, some of which may be relevant to security. Detecting such changes and providing an automated response can help avoid unintended, negative consequences that could ultimately affect the security state of the operating system. The operating system's IMO/ISSO and SAs must be notified via email and/or monitoring system trap when there is an unauthorized modification of a configuration item.

Checks: C-41568r917811_chk

Verify that Advanced Intrusion Detection Environment (AIDE) notifies the SA when anomalies in the operation of any security functions are discovered with the following command: $ grep SILENTREPORTS /etc/default/aide SILENTREPORTS=no If SILENTREPORTS is commented out, this is a finding. If SILENTREPORTS is set to "yes", this is a finding. If SILENTREPORTS is not set to "no", this is a finding.

Fix: F-41527r654248_fix

Configure the Ubuntu operating system to notify designated personnel if baseline configurations are changed in an unauthorized manner. Modify the "SILENTREPORTS" parameter in the "/etc/default/aide" file with a value of "no" if it does not already exist.

b

The Ubuntu operating system's Advance Package Tool (APT) must be configured to prevent the installation of patches, service packs, device drivers, or Ubuntu operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization.

CM-5 - Medium - CCI-001749 - V-238359 - SV-238359r877463_rule

RMF Control

CM-5

Severity

M

CCI

CCI-001749

Version

UBTU-20-010438

Vuln IDs

V-238359

Rule IDs

SV-238359r877463_rule

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 ensures 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 DoD certificates for this purpose; however, the certificate used to verify the software must be from an approved CA.

Checks: C-41569r654250_chk

Verify that APT is configured to prevent the installation of patches, service packs, device drivers, or Ubuntu operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization. Check that the "AllowUnauthenticated" variable is not set at all or is set to "false" with the following command: $ grep AllowUnauthenticated /etc/apt/apt.conf.d/* /etc/apt/apt.conf.d/01-vendor-Ubuntu:APT::Get::AllowUnauthenticated "false"; If any of the files returned from the command with "AllowUnauthenticated" are set to "true", this is a finding.

Fix: F-41528r654251_fix

Configure APT to prevent the installation of patches, service packs, device drivers, or Ubuntu operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization. Remove/update any APT configuration files that contain the variable "AllowUnauthenticated" to "false", or remove "AllowUnauthenticated" entirely from each file. Below is an example of setting the "AllowUnauthenticated" variable to "false": APT::Get::AllowUnauthenticated "false";

b

The Ubuntu operating system must be configured to use AppArmor.

CM-7 - Medium - CCI-001764 - V-238360 - SV-238360r853435_rule

RMF Control

CM-7

Severity

M

CCI

CCI-001764

Version

UBTU-20-010439

Vuln IDs

V-238360

Rule IDs

SV-238360r853435_rule

Control of program execution is a mechanism used to prevent execution of unauthorized programs. Some operating systems may provide a capability that runs counter to the mission or provides users with functionality that exceeds mission requirements. This includes functions and services installed at the operating system-level. Some of the programs, installed by default, may be harmful or may not be necessary to support essential organizational operations (e.g., key missions, functions). Removal of executable programs is not always possible; therefore, establishing a method of preventing program execution is critical to maintaining a secure system baseline. Methods for complying with this requirement include restricting execution of programs in certain environments, while preventing execution in other environments; or limiting execution of certain program functionality based on organization-defined criteria (e.g., privileges, subnets, sandboxed environments, or roles). Satisfies: SRG-OS-000368-GPOS-00154, SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000312-GPOS-00124, SRG-OS-000324-GPOS-00125, SRG-OS-000370-GPOS-00155

Checks: C-41570r654253_chk

Verify the operating system prevents program execution in accordance with local policies. Check that AppArmor is installed and active by running the following command, $ dpkg -l | grep apparmor If the "apparmor" package is not installed, this is a finding. $ systemctl is-active apparmor.service active If "active" is not returned, this is a finding. $ systemctl is-enabled apparmor.service enabled If "enabled" is not returned, this is a finding.

Fix: F-41529r654254_fix

Install "AppArmor" (if it is not installed) with the following command: $ sudo apt-get install apparmor $ sudo systemctl enable apparmor.service Start "apparmor" with the following command: $ sudo systemctl start apparmor.service Note: AppArmor must have properly configured profiles for applications and home directories. All configurations will be based on the actual system setup and organization and normally are on a per role basis. See the AppArmor documentation for more information on configuring profiles.

b

The Ubuntu operating system must allow the use of a temporary password for system logons with an immediate change to a permanent password.

IA-5 - Medium - CCI-002041 - V-238361 - SV-238361r853436_rule

RMF Control

IA-5

Severity

M

CCI

CCI-002041

Version

UBTU-20-010440

Vuln IDs

V-238361

Rule IDs

SV-238361r853436_rule

Without providing this capability, an account may be created without a password. Non-repudiation cannot be guaranteed once an account is created if a user is not forced to change the temporary password upon initial logon. Temporary passwords are typically used to allow access when new accounts are created or passwords are changed. It is common practice for administrators to create temporary passwords for user accounts which allow the users to log on, yet force them to change the password once they have successfully authenticated.

Checks: C-41571r654256_chk

Verify a policy exists that ensures when a user account is created, it is created using a method that forces a user to change their password upon their next login. If a policy does not exist, this is a finding.

Fix: F-41530r654257_fix

Create a policy that ensures when a user is created, it is created using a method that forces a user to change their password upon their next login. Below are two examples of how to create a user account that requires the user to change their password upon their next login. $ sudo chage -d 0 [UserName] or $ sudo passwd -e [UserName]

a

The Ubuntu operating system must be configured such that Pluggable Authentication Module (PAM) prohibits the use of cached authentications after one day.

IA-5 - Low - CCI-002007 - V-238362 - SV-238362r853437_rule

RMF Control

IA-5

Severity

L

CCI

CCI-002007

Version

UBTU-20-010441

Vuln IDs

V-238362

Rule IDs

SV-238362r853437_rule

If cached authentication information is out-of-date, the validity of the authentication information may be questionable.

Checks: C-41572r654259_chk

If smart card authentication is not being used on the system, this s Not Applicable. Verify that PAM prohibits the use of cached authentications after one day with the following command: $ sudo grep offline_credentials_expiration /etc/sssd/sssd.conf /etc/sssd/conf.d/*.conf offline_credentials_expiration = 1 If "offline_credentials_expiration" is not set to a value of "1" in "/etc/sssd/sssd.conf" or in a file with a name ending in .conf in the "/etc/sssd/conf.d/" directory, this is a finding.

Fix: F-41531r654260_fix

Configure PAM to prohibit the use of cached authentications after one day. Add or change the following line in "/etc/sssd/sssd.conf" just below the line "[pam]": offline_credentials_expiration = 1 Note: It is valid for this configuration to be in a file with a name that ends with ".conf" and does not begin with a "." in the "/etc/sssd/conf.d/" directory instead of the "/etc/sssd/sssd.conf" file.

c

The Ubuntu operating system must implement NIST FIPS-validated cryptography to protect classified information and for the following: To provision digital signatures, to generate cryptographic hashes, and to protect unclassified information requiring confidentiality and cryptographic protection in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.

SC-13 - High - CCI-002450 - V-238363 - SV-238363r880881_rule

RMF Control

SC-13

Severity

H

CCI

CCI-002450

Version

UBTU-20-010442

Vuln IDs

V-238363

Rule IDs

SV-238363r880881_rule

Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. Satisfies: SRG-OS-000396-GPOS-00176, SRG-OS-000478-GPOS-00223

Checks: C-41573r654262_chk

Verify the system is configured to run in FIPS mode with the following command: $ grep -i 1 /proc/sys/crypto/fips_enabled 1 If a value of "1" is not returned, this is a finding.

Fix: F-41532r880880_fix

Configure the system to run in FIPS mode. Add "fips=1" to the kernel parameter during the Ubuntu operating systems install. Enabling a FIPS mode on a pre-existing system involves a number of modifications to the Ubuntu operating system. Refer to the Ubuntu Server 18.04 FIPS 140-2 security policy document for instructions. A subscription to the "Ubuntu Pro" plan is required to obtain the FIPS Kernel cryptographic modules and enable FIPS.

b

The Ubuntu operating system must use DoD PKI-established certificate authorities for verification of the establishment of protected sessions.

SC-23 - Medium - CCI-002470 - V-238364 - SV-238364r880902_rule

RMF Control

SC-23

Severity

M

CCI

CCI-002470

Version

UBTU-20-010443

Vuln IDs

V-238364

Rule IDs

SV-238364r880902_rule

Untrusted Certificate Authorities (CA) can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoD systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoD-approved CA, trust of this CA has not been established. The DoD will only accept PKI-certificates obtained from a DoD-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of SSL/TLS certificates.

Checks: C-41574r880900_chk

Verify the directory containing the root certificates for the Ubuntu operating system contains certificate files for DoD PKI-established certificate authorities by iterating over all files in the "/etc/ssl/certs" directory and checking if, at least one, has the subject matching "DOD ROOT CA". If none is found, this is a finding.

Fix: F-41533r880901_fix

Configure the Ubuntu operating system to use of DoD PKI-established certificate authorities for verification of the establishment of protected sessions. Edit the "/etc/ca-certificates.conf" file, adding the character "!" to the beginning of all uncommented lines that do not start with the "!" character with the following command: $ sudo sed -i -E 's/^([^!#]+)/!\1/' /etc/ca-certificates.conf Add at least one DoD certificate authority to the "/usr/local/share/ca-certificates" directory in the PEM format. Update the "/etc/ssl/certs" directory with the following command: $ sudo update-ca-certificates

b

Ubuntu operating system must implement cryptographic mechanisms to prevent unauthorized modification of all information at rest.

SC-28 - Medium - CCI-002475 - V-238365 - SV-238365r877379_rule

RMF Control

SC-28

Severity

M

CCI

CCI-002475

Version

UBTU-20-010444

Vuln IDs

V-238365

Rule IDs

SV-238365r877379_rule

Operating systems handling data requiring "data at rest" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest. Selection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields).

Checks: C-41575r654268_chk

If there is a documented and approved reason for not having data-at-rest encryption, this requirement is Not Applicable. Verify the Ubuntu operating system prevents unauthorized disclosure or modification of all information requiring at-rest protection by using disk encryption. Determine the partition layout for the system with the following command: $ sudo fdisk -l (..) Disk /dev/vda: 15 GiB, 16106127360 bytes, 31457280 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 83298450-B4E3-4B19-A9E4-7DF147A5FEFB Device Start End Sectors Size Type /dev/vda1 2048 4095 2048 1M BIOS boot /dev/vda2 4096 2101247 2097152 1G Linux filesystem /dev/vda3 2101248 31455231 29353984 14G Linux filesystem (...) Verify that the system partitions are all encrypted with the following command: $ more /etc/crypttab Every persistent disk partition present must have an entry in the file. If any partitions other than the boot partition or pseudo file systems (such as /proc or /sys) are not listed, this is a finding.

Fix: F-41534r654269_fix

To encrypt an entire partition, dedicate a partition for encryption in the partition layout. Note: Encrypting a partition in an already-installed system is more difficult because it will need to be resized and existing partitions changed.

b

Ubuntu operating system must implement cryptographic mechanisms to prevent unauthorized disclosure of all information at rest.

SC-28 - Medium - CCI-002476 - V-238366 - SV-238366r877378_rule

RMF Control

SC-28

Severity

M

CCI

CCI-002476

Version

UBTU-20-010445

Vuln IDs

V-238366

Rule IDs

SV-238366r877378_rule

Operating systems handling data requiring "data at rest" protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest. Selection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields).

Checks: C-41576r654271_chk

If there is a documented and approved reason for not having data-at-rest encryption, this requirement is Not Applicable. Verify the Ubuntu operating system prevents unauthorized disclosure or modification of all information requiring at-rest protection by using disk encryption. Determine the partition layout for the system with the following command: $sudo fdisk -l (..) Disk /dev/vda: 15 GiB, 16106127360 bytes, 31457280 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 83298450-B4E3-4B19-A9E4-7DF147A5FEFB Device Start End Sectors Size Type /dev/vda1 2048 4095 2048 1M BIOS boot /dev/vda2 4096 2101247 2097152 1G Linux filesystem /dev/vda3 2101248 31455231 29353984 14G Linux filesystem (...) Verify that the system partitions are all encrypted with the following command: $ more /etc/crypttab Every persistent disk partition present must have an entry in the file. If any partitions other than the boot partition or pseudo file systems (such as /proc or /sys) are not listed, this is a finding.

Fix: F-41535r654272_fix

To encrypt an entire partition, dedicate a partition for encryption in the partition layout. Note: Encrypting a partition in an already-installed system is more difficult because it will need to be resized and existing partitions changed.

b

The Ubuntu operating system must configure the uncomplicated firewall to rate-limit impacted network interfaces.

SC-5 - Medium - CCI-002385 - V-238367 - SV-238367r853444_rule

RMF Control

SC-5

Severity

M

CCI

CCI-002385

Version

UBTU-20-010446

Vuln IDs

V-238367

Rule IDs

SV-238367r853444_rule

Denial of service (DoS) is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. This requirement addresses the configuration of the operating system to mitigate the impact of DoS attacks that have occurred or are ongoing on system availability. For each system, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or establishing memory partitions). Employing increased capacity and bandwidth, combined with service redundancy, may reduce the susceptibility to some DoS attacks.

Checks: C-41577r654274_chk

Verify an application firewall is configured to rate limit any connection to the system. Check all the services listening to the ports with the following command: $ sudo ss -l46ut Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process tcp LISTEN 0 128 [::]:ssh [::]:* For each entry, verify that the Uncomplicated Firewall is configured to rate limit the service ports with the following command: $ sudo ufw status Status: active To Action From -- ------ ---- 22/tcp LIMIT Anywhere 22/tcp (v6) LIMIT Anywhere (v6) If any port with a state of "LISTEN" is not marked with the "LIMIT" action, this is a finding.

Fix: F-41536r654275_fix

Configure the application firewall to protect against or limit the effects of DoS attacks by ensuring the Ubuntu operating system is implementing rate-limiting measures on impacted network interfaces. Check all the services listening to the ports with the following command: $ sudo ss -l46ut Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process tcp LISTEN 0 128 [::]:ssh [::]:* For each service with a port listening to connections, run the following command, replacing "[service]" with the service that needs to be rate limited. $ sudo ufw limit [service] Rate-limiting can also be done on an interface. An example of adding a rate-limit on the eth0 interface follows: $ sudo ufw limit in on eth0

b

The Ubuntu operating system must implement nonexecutable data to protect its memory from unauthorized code execution.

SI-16 - Medium - CCI-002824 - V-238368 - SV-238368r880910_rule

RMF Control

SI-16

Severity

M

CCI

CCI-002824

Version

UBTU-20-010447

Vuln IDs

V-238368

Rule IDs

SV-238368r880910_rule

Some adversaries launch attacks with the intent of executing code in nonexecutable regions of memory or in memory locations that are prohibited. Security safeguards employed to protect memory include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can either be hardware-enforced or software-enforced with hardware providing the greater strength of mechanism. Examples of attacks are buffer overflow attacks.

Checks: C-41578r880909_chk

Verify the NX (no-execution) bit flag is set on the system with the following commands: $ sudo dmesg | grep -i "execute disable" [ 0.000000] NX (Execute Disable) protection: active If "dmesg" does not show "NX (Execute Disable) protection: active", check the cpuinfo settings with the following command: $ grep flags /proc/cpuinfo | grep -w nx | sort -u flags : fpu vme de pse tsc ms nx rdtscp lm constant_tsc If "flags" does not contain the "nx" flag, this is a finding.

Fix: F-41537r654278_fix

Configure the Ubuntu operating system to enable NX. If "nx" is not showing up in "/proc/cpuinfo", and the system's BIOS setup configuration permits toggling the No Execution bit, set it to "enable".

b

The Ubuntu operating system must implement address space layout randomization to protect its memory from unauthorized code execution.

SI-16 - Medium - CCI-002824 - V-238369 - SV-238369r853446_rule

RMF Control

SI-16

Severity

M

CCI

CCI-002824

Version

UBTU-20-010448

Vuln IDs

V-238369

Rule IDs

SV-238369r853446_rule

Some adversaries launch attacks with the intent of executing code in non-executable regions of memory or in memory locations that are prohibited. Security safeguards employed to protect memory include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can either be hardware-enforced or software-enforced with hardware providing the greater strength of mechanism. Examples of attacks are buffer overflow attacks.

Checks: C-41579r654280_chk

Verify the Ubuntu operating system implements address space layout randomization (ASLR) with the following command: $ sudo sysctl kernel.randomize_va_space kernel.randomize_va_space = 2 If nothing is returned, verify the kernel parameter "randomize_va_space" is set to "2" with the following command: $ cat /proc/sys/kernel/randomize_va_space 2 If "kernel.randomize_va_space" is not set to "2", this is a finding. Verify that a saved value of the "kernel.randomize_va_space" variable is not defined. $ sudo egrep -R "^kernel.randomize_va_space=[^2]" /etc/sysctl.conf /etc/sysctl.d If this returns a result, this is a finding.

Fix: F-41538r654281_fix

Remove the "kernel.randomize_va_space" entry found in the "/etc/sysctl.conf" file or any file located in the "/etc/sysctl.d/" directory. After the line has been removed, the kernel settings from all system configuration files must be reloaded before any of the changes will take effect. Run the following command to reload all of the kernel system configuration files: $ sudo sysctl --system

b

The Ubuntu operating system must be configured so that Advance Package Tool (APT) removes all software components after updated versions have been installed.

SI-2 - Medium - CCI-002617 - V-238370 - SV-238370r853447_rule

RMF Control

SI-2

Severity

M

CCI

CCI-002617

Version

UBTU-20-010449

Vuln IDs

V-238370

Rule IDs

SV-238370r853447_rule

Previous versions of software components that are not removed from the information system after updates have been installed may be exploited by adversaries. Some information technology products may remove older versions of software automatically from the information system.

Checks: C-41580r654283_chk

Verify is configured to remove all software components after updated versions have been installed with the following command: $ grep -i remove-unused /etc/apt/apt.conf.d/50unattended-upgrades Unattended-Upgrade::Remove-Unused-Dependencies "true"; Unattended-Upgrade::Remove-Unused-Kernel-Packages "true"; If the "::Remove-Unused-Dependencies" and "::Remove-Unused-Kernel-Packages" parameters are not set to "true" or are missing or commented out, this is a finding.

Fix: F-41539r654284_fix

Configure APT to remove all software components after updated versions have been installed. Add or updated the following options to the "/etc/apt/apt.conf.d/50unattended-upgrades" file: Unattended-Upgrade::Remove-Unused-Dependencies "true"; Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";

b

The Ubuntu operating system must use a file integrity tool to verify correct operation of all security functions.

SI-6 - Medium - CCI-002696 - V-238371 - SV-238371r880913_rule

RMF Control

SI-6

Severity

M

CCI

CCI-002696

Version

UBTU-20-010450

Vuln IDs

V-238371

Rule IDs

SV-238371r880913_rule

Without verification of the security functions, security functions may not operate correctly and the failure may go unnoticed. Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters. This requirement applies to the Ubuntu operating system performing security function verification/testing and/or systems and environments that require this functionality.

Checks: C-41581r880911_chk

Verify that Advanced Intrusion Detection Environment (AIDE) is installed and verifies the correct operation of all security functions. Check that the AIDE package is installed with the following command: $ sudo dpkg -l | grep aide ii aide 0.16.1-1build2 amd64 Advanced Intrusion Detection Environment - static binary If AIDE is not installed, ask the System Administrator how file integrity checks are performed on the system. If there is no application installed to perform integrity checks, this is a finding. If AIDE is installed, check if it has been initialized with the following command: $ sudo aide.wrapper --check If the output is "Couldn't open file /var/lib/aide/aide.db for reading", this is a finding.

Fix: F-41540r880912_fix

Install AIDE, initialize it, and perform a manual check. Install AIDE: $ sudo apt install aide Initialize it (this may take a few minutes): $ sudo aideinit Running aide --init... Example output: Start timestamp: 2022-11-20 11:53:17 -0700 (AIDE 0.16) AIDE initialized database at /var/lib/aide/aide.db.new Verbose level: 6 Number of entries: 119543 --------------------------------------------------- The attributes of the (uncompressed) database(s): --------------------------------------------------- /var/lib/aide/aide.db.new RMD160 : PiEP1DX91JMcHnRSPnpFqNfIFr4= TIGER : /zM5yQBnOIoEH0jplJE5v6S0rUErbTXL SHA256 : BE2iHtBN9lEX53l4R/p7t1al0dIlsgPc Lg4YI08+/Jk= SHA512 : JIdGeNVRgtBPPSwun9St+9cwUrgIIKUW KVTksZXJ29Tt+luC/XNDcjIub7fbPVw/ EcTDsvYtt9MBmBxw1wCYng== CRC32 : jB2FVw== HAVAL : Jhe+fqaDpkswpWSnOTN28TO05QFHsjdq RcFZwCVUGTQ= GOST : WFrarVyxpXbKdW9SAaOy1Te8rSodV3/q nLsXuP7YujA= End timestamp: 2022-11-20 11:58:19 -0700 (run time: 5m 2s) The new database will need to be renamed to be read by AIDE: $ sudo cp -p /var/lib/aide/aide.db.new /var/lib/aide/aide.db Perform a manual check: $ sudo aide.wrapper --check Example output: Start timestamp: 2022-11-20 11:59:16 -0700 (AIDE 0.16) AIDE found differences between database and filesystem!! ... Done.

b

The Ubuntu operating system must notify designated personnel if baseline configurations are changed in an unauthorized manner. The file integrity tool must notify the System Administrator when changes to the baseline configuration or anomalies in the operation of any security functions are discovered.

SI-6 - Medium - CCI-002702 - V-238372 - SV-238372r853449_rule

RMF Control

SI-6

Severity

M

CCI

CCI-002702

Version

UBTU-20-010451

Vuln IDs

V-238372

Rule IDs

SV-238372r853449_rule

Unauthorized changes to the baseline configuration could make the system vulnerable to various attacks or allow unauthorized access to the Ubuntu operating system. Changes to Ubuntu operating system configurations can have unintended side effects, some of which may be relevant to security. Detecting such changes and providing an automated response can help avoid unintended, negative consequences that could ultimately affect the security state of the Ubuntu operating system. The Ubuntu operating system's IMO/ISSO and SAs must be notified via email and/or monitoring system trap when there is an unauthorized modification of a configuration item.

Checks: C-41582r654289_chk

Verify that Advanced Intrusion Detection Environment (AIDE) notifies the System Administrator when anomalies in the operation of any security functions are discovered with the following command: $ sudo grep SILENTREPORTS /etc/default/aide SILENTREPORTS=no If SILENTREPORTS is uncommented and set to "yes", this is a finding.

Fix: F-41541r654290_fix

Configure the Ubuntu operating system to notify designated personnel if baseline configurations are changed in an unauthorized manner. Modify the "SILENTREPORTS" parameter in the "/etc/default/aide" file with a value of "no" if it does not already exist.

a

The Ubuntu operating system must display the date and time of the last successful account logon upon logon.

AC-9 - Low - CCI-000052 - V-238373 - SV-238373r858539_rule

RMF Control

AC-9

Severity

L

CCI

CCI-000052

Version

UBTU-20-010453

Vuln IDs

V-238373

Rule IDs

SV-238373r858539_rule

Configuration settings are the set of parameters that can be changed in hardware, software, or firmware components of the system that affect the security posture and/or functionality of the system. Security-related parameters are those parameters impacting the security state of the system, including the parameters required to satisfy other security control requirements. Security-related parameters include, for example: registry settings; account, file, directory permission settings; and settings for functions, ports, protocols, services, and remote connections.

Checks: C-41583r654292_chk

Verify users are provided with feedback on when account accesses last occurred. Check that "pam_lastlog" is used and not silent with the following command: $ grep pam_lastlog /etc/pam.d/login session required pam_lastlog.so showfailed If "pam_lastlog" is missing from "/etc/pam.d/login" file, is not "required", or the "silent" option is present, this is a finding.

Fix: F-41542r654293_fix

Configure the Ubuntu operating system to provide users with feedback on when account accesses last occurred by setting the required configuration options in "/etc/pam.d/login". Add the following line to the top of "/etc/pam.d/login": session required pam_lastlog.so showfailed

b

The Ubuntu operating system must have an application firewall enabled.

CM-6 - Medium - CCI-000366 - V-238374 - SV-238374r654297_rule

RMF Control

CM-6

Severity

M

CCI

Version

UBTU-20-010454

Vuln IDs

V-238374

Rule IDs

SV-238374r654297_rule

Firewalls protect computers from network attacks by blocking or limiting access to open network ports. Application firewalls limit which applications are allowed to communicate over the network.

Checks: C-41584r654295_chk

Verify the Uncomplicated Firewall is enabled on the system by running the following command: $ systemctl status ufw.service | grep -i "active:" Active: active (exited) since Mon 2016-10-17 12:30:29 CDT; 1s ago If the above command returns the status as "inactive", this is a finding. If the Uncomplicated Firewall is not installed, ask the System Administrator if another application firewall is installed. If no application firewall is installed, this is a finding.

Fix: F-41543r654296_fix

Enable the Uncomplicated Firewall by using the following command: $ sudo systemctl enable ufw.service If the Uncomplicated Firewall is not currently running on the system, start it with the following command: $ sudo systemctl start ufw.service

b

The Ubuntu operating system must have system commands set to a mode of 0755 or less permissive.

CM-5 - Medium - CCI-001499 - V-238376 - SV-238376r654303_rule

RMF Control

CM-5

Severity

M

CCI

Version

UBTU-20-010456

Vuln IDs

V-238376

Rule IDs

SV-238376r654303_rule

If the Ubuntu operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to Ubuntu operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Checks: C-41586r654301_chk

Verify the system commands contained in the following directories have mode 0755 or less permissive: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Check that the system command files have mode 0755 or less permissive with the following command: $ sudo find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -perm /022 -type f -exec stat -c "%n %a" '{}' \; If any files are found to be group-writable or world-writable, this is a finding.

Fix: F-41545r654302_fix

Configure the system commands to be protected from unauthorized access. Run the following command: $ sudo find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -perm /022 -type f -exec chmod 755 '{}' \;

b

The Ubuntu operating system must have system commands owned by root or a system account.

CM-5 - Medium - CCI-001499 - V-238377 - SV-238377r832968_rule

RMF Control

CM-5

Severity

M

CCI

Version

UBTU-20-010457

Vuln IDs

V-238377

Rule IDs

SV-238377r832968_rule

If the Ubuntu operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to Ubuntu operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Checks: C-41587r832966_chk

Verify the system commands contained in the following directories are owned by root, or a required system account: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Use the following command for the check: $ sudo find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -user root -type f -exec stat -c "%n %U" '{}' \; If any system commands are returned and are not owned by a required system account, this is a finding.

Fix: F-41546r832967_fix

Configure the system commands and their respective parent directories to be protected from unauthorized access. Run the following command, replacing "[FILE]" with any system command file not owned by "root" or a required system account: $ sudo chown root [FILE]

b

The Ubuntu operating system must have system commands group-owned by root or a system account.

CM-5 - Medium - CCI-001499 - V-238378 - SV-238378r832971_rule

RMF Control

CM-5

Severity

M

CCI

Version

UBTU-20-010458

Vuln IDs

V-238378

Rule IDs

SV-238378r832971_rule

If the Ubuntu operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to Ubuntu operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Checks: C-41588r832969_chk

Verify the system commands contained in the following directories are group-owned by root or a required system account: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Run the check with the following command: $ sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -group root -type f ! -perm /2000 -exec stat -c "%n %G" '{}' \; If any system commands are returned that are not Set Group ID upon execution (SGID) files and group-owned by a required system account, this is a finding.

Fix: F-41547r832970_fix

Configure the system commands to be protected from unauthorized access. Run the following command, replacing "[FILE]" with any system command file not group-owned by "root" or a required system account: $ sudo chgrp root [FILE]

c

The Ubuntu operating system must disable the x86 Ctrl-Alt-Delete key sequence if a graphical user interface is installed.

CM-6 - High - CCI-000366 - V-238379 - SV-238379r654312_rule

RMF Control

CM-6

Severity

H

CCI

Version

UBTU-20-010459

Vuln IDs

V-238379

Rule IDs

SV-238379r654312_rule

A locally logged-on user who presses Ctrl-Alt-Delete, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of a mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. In the graphical environment, risk of unintentional reboot from the Ctrl-Alt-Delete sequence is reduced because the user will be prompted before any action is taken.

Checks: C-41589r654310_chk

Verify the Ubuntu operating system is not configured to reboot the system when Ctrl-Alt-Delete is pressed when using a graphical user interface. Check that the "logout" target is not bound to an action with the following command: # grep logout /etc/dconf/db/local.d/* logout='' If the "logout" key is bound to an action, is commented out, or is missing, this is a finding.

Fix: F-41548r654311_fix

Configure the system to disable the Ctrl-Alt-Delete sequence when using a graphical user interface by creating or editing the /etc/dconf/db/local.d/00-disable-CAD file. Add the setting to disable the Ctrl-Alt-Delete sequence for the graphical user interface: [org/gnome/settings-daemon/plugins/media-keys] logout='' Update the dconf settings: # dconf update

c

The Ubuntu operating system must disable the x86 Ctrl-Alt-Delete key sequence.

CM-6 - High - CCI-000366 - V-238380 - SV-238380r832974_rule

RMF Control

CM-6

Severity

H

CCI

Version

UBTU-20-010460

Vuln IDs

V-238380

Rule IDs

SV-238380r832974_rule

A locally logged-on user who presses Ctrl-Alt-Delete, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of a mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot.

Checks: C-41590r832972_chk

Verify the Ubuntu operating system is not configured to reboot the system when Ctrl-Alt-Delete is pressed. Check that the "ctrl-alt-del.target" (otherwise also known as reboot.target) is not active with the following command: $ sudo systemctl status ctrl-alt-del.target ctrl-alt-del.target Loaded: masked (Reason: Unit ctrl-alt-del.target is masked.) Active: inactive (dead) If the "ctrl-alt-del.target" is not masked, this is a finding.

Fix: F-41549r832973_fix

Configure the system to disable the Ctrl-Alt-Delete sequence for the command line with the following commands: $ sudo systemctl disable ctrl-alt-del.target $ sudo systemctl mask ctrl-alt-del.target Reload the daemon to take effect: $ sudo systemctl daemon-reload

c

The Ubuntu operating system must not have accounts configured with blank or null passwords.

CM-6 - High - CCI-000366 - V-251503 - SV-251503r808506_rule

RMF Control

CM-6

Severity

H

CCI

Version

UBTU-20-010462

Vuln IDs

V-251503

Rule IDs

SV-251503r808506_rule

If an account has an empty password, anyone could log on and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.

Checks: C-54938r808504_chk

Check the "/etc/shadow" file for blank passwords with the following command: $ sudo awk -F: '!$2 {print $1}' /etc/shadow If the command returns any results, this is a finding.

Fix: F-54892r808505_fix

Configure all accounts on the system to have a password or lock the account with the following commands: Perform a password reset: $ sudo passwd [username] Lock an account: $ sudo passwd -l [username]

c

The Ubuntu operating system must not allow accounts configured with blank or null passwords.

CM-6 - High - CCI-000366 - V-251504 - SV-251504r832977_rule

RMF Control

CM-6

Severity

H

CCI