Canonical Ubuntu 24.04 LTS Security Technical Implementation Guide

Checks: C-74682r1067134_chk

Verify that Advanced Intrusion Detection Environment (AIDE) is installed and verifies the correct operation of all security functions with the following command: $ dpkg -l | grep aide ii aide 0.18.6-2build2 amd64 Advanced Intrusion Detection Environment - dynamic binary ii aide-common 0.18.6-2build2 all Advanced Intrusion Detection Environment - Common files 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.

Fix: F-74583r1067135_fix

Install the "AIDE" file integrity package: $ sudo apt install -y aide

Generate Mitigation Statement:

Checks: C-74683r1066437_chk

Note: If AIDE is not installed, this finding is not applicable. Verify Advanced Intrusion Detection Environment (AIDE) is configured on the system by preforming a manual check: $ sudo aide -c /etc/aide/aide.conf --check Example output: ... Start timestamp: 2024-10-30 14:22:38 -0400 (AIDE 0.18.6) AIDE found differences between database and filesystem!! ... If AIDE is being used for system file integrity checking and the command fails, this is a finding.

Fix: F-74584r1066438_fix

Initialize the AIDE package (this may take a few minutes): $ sudo aideinit Running aide --init... 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 -c /etc/aide/aide.conf --check Example output: ... Start timestamp: 2024-10-30 14:22:38 -0400 (AIDE 0.18.6) AIDE found differences between database and filesystem!! ... Done.

Generate Mitigation Statement:

Checks: C-74684r1066440_chk

Note: If AIDE is not installed, this finding is not applicable. Check the AIDE configuration file integrity installed on the system (the default configuration file is located at /etc/aide/aide.conf or in /etc/aide/aide.conf.d/) with the following command: $ sudo sha256sum /etc/aide/aide.conf f3bbea2552f2c5b475627850d8a5fba1659df6466986d5a18948d9821ecbe491 /etc/aide/aide.conf Download the original aide-common package in the /tmp directory: $ cd /tmp; apt download aide-common Generate the checksum from the aide.conf file in the downloaded .deb package: $ sudo dpkg-deb --fsys-tarfile /tmp/aide-common_0.18.6-2build2_all.deb | tar -xO ./usr/share/aide/config/aide/aide.conf | sha256sum f3bbea2552f2c5b475627850d8a5fba1659df6466986d5a18948d9821ecbe491 - If the checksums of the system file (/etc/aide/aide.conf) and the extracted file do not match, this is a finding. To verify the frequency of the file integrity checks, inspect the contents of the scheduled jobs as follows: Checking scheduled cron jobs: $ grep -r aide /etc/cron* /etc/crontab /etc/cron.daily/dailyaidecheck:SCRIPT="/usr/share/aide/bin/dailyaidecheck" Checking the systemd timer (this will show when the next scheduled run occurs and the last time the AIDE check was triggered): $ sudo systemctl list-timers | grep aide Thu 2024-10-31 02:01:58 EDT 10h Wed 2024-10-30 13:47:41 EDT - dailyaidecheck.timer dailyaidecheck.service The contents of these files can be inspected with the following commands: $ sudo systemctl cat dailyaidecheck.timer $ sudo systemctl cat dailyaidecheck.service If there is no AIDE script file in the cron directories or in the systemd timer, this is a finding.

Fix: F-74585r1068394_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 --wildcards ./usr/share/aide/config/cron.daily/dailyaidecheck* -C / Copy it to the cron.daily directory: $ sudo cp -f /usr/share/aide/config/cron.daily/aide /etc/cron.daily/dailyaidecheck*

Generate Mitigation Statement:

Checks: C-74685r1066443_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 set to "yes", is commented out, or is missing, this is a finding.

Fix: F-74586r1067137_fix

Configure Ubuntu 24.04 LTS 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 as follows: SILENTREPORTS=no

Generate Mitigation Statement:

Checks: C-74686r1067139_chk

Verify the log service is installed properly with the following command: $ dpkg -l | grep rsyslog ii rsyslog 8.2312.0-3ubuntu9 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-74587r1067140_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 install -y rsyslog Enable the log service with the following command: $ sudo systemctl enable --now rsyslog

Generate Mitigation Statement:

Checks: C-74687r1066449_chk

Verify that the Uncomplicated Firewall (ufw) is installed with the following command: $ dpkg -l | grep ufw ii ufw 0.36.2-6 all program for managing a Netfilter firewall 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-74588r1067142_fix

Install the ufw by using the following command: $ sudo apt install -y ufw

Generate Mitigation Statement:

Checks: C-74688r1066452_chk

Verify the ufw is enabled on the system with the following command: $ sudo ufw status Status: active If the above command returns the status as "inactive" or any type of error, this is a finding. If the ufw is not installed, ask the system administrator if another application firewall is installed. If a different firewall is active on the system, this is not a finding.

Fix: F-74589r1067144_fix

Enable the ufw by using the following command: $ sudo ufw enable Note: Enabling the firewall will potentially disrupt ssh sessions.

Generate Mitigation Statement:

Checks: C-74689r1067146_chk

Verify the audit service is configured to produce audit records with the following command: $ dpkg -l | grep auditd ii auditd 1:3.0.7-1build1 amd64 User space tools for security auditing If the "auditd" package is not installed, this is a finding.

Fix: F-74590r1067147_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 install -y auditd

Generate Mitigation Statement:

Checks: C-74690r1066458_chk

Verify the audit service is enabled with the following command: $ systemctl is-enabled auditd.service enabled 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-74591r1066459_fix

Configure the audit service to produce audit records containing the information needed to establish when (date and time) an event occurred. 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

Generate Mitigation Statement:

Checks: C-74692r1066464_chk

Verify Ubuntu 24.04 LTS has AppArmor installed with the following command: $ dpkg -l | grep apparmor ii apparmor 4.0.1really4.0.1-0ubuntu0.24.04.3 amd64 user-space parser utility for AppArmor ii libapparmor1:amd64 4.0.1really4.0.1-0ubuntu0.24.04.3 amd64 changehat AppArmor library If the AppArmor package is not installed, this is a finding.

Fix: F-74593r1066465_fix

Install "AppArmor" with the following command: $ sudo apt install apparmor 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. Refer to the AppArmor documentation for more information on configuring profiles.

Generate Mitigation Statement:

Checks: C-74693r1066467_chk

Verify Ubuntu 24.04 LTS AppArmor active with the following commands: $ 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-74594r1066468_fix

Enable "apparmor" with the following command: $ 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. Refer to the AppArmor documentation for more information on configuring profiles.

Generate Mitigation Statement:

Checks: C-74694r1067152_chk

Verify Ubuntu 24.04 LTS has the "libpam-pwquality" package installed with the following command: $ dpkg -l | grep libpam-pwquality ii libpam-pwquality:amd64 1.4.5-3build1 amd64 PAM module to check password strength If "libpam-pwquality" is not installed, this is a finding.

Fix: F-74595r1067153_fix

Install the "pam_pwquality" package by using the following command: $ sudo apt install -y libpam-pwquality

Generate Mitigation Statement:

Checks: C-74695r1066473_chk

Verify Ubuntu 24.04 LTS has the packages required for multifactor authentication installed with the following command: $ dpkg -l | grep sssd ii sssd 2.9.4-1.1ubuntu6.1 amd64 System Security Services Daemon -- metapackage ii sssd-ad 2.9.4-1.1ubuntu6.1 amd64 System Security Services Daemon -- Active Directory back end ii sssd-ad-common 2.9.4-1.1ubuntu6.1 amd64 System Security Services Daemon -- PAC responder ii sssd-common 2.9.4-1.1ubuntu6.1 amd64 System Security Services Daemon -- common files ii sssd-ipa 2.9.4-1.1ubuntu6.1 amd64 System Security Services Daemon -- IPA back end ii sssd-krb5 2.9.4-1.1ubuntu6.1 amd64 System Security Services Daemon -- Kerberos back end ii sssd-krb5-common 2.9.4-1.1ubuntu6.1 amd64 System Security Services Daemon -- Kerberos helpers ii sssd-ldap 2.9.4-1.1ubuntu6.1 amd64 System Security Services Daemon -- LDAP back end ii sssd-proxy 2.9.4-1.1ubuntu6.1 amd64 System Security Services Daemon -- proxy back end If the "sssd" package is not installed, this is a finding. The additional sssd components listed by the command may differ from configuration to configuration. Ensure that "libpam-sss" (the PAM integration module for SSSD) is installed with the following command: $ dpkg -l | grep libpam-sss i libpam-sss:amd64 2.9.4-1.1ubuntu6.1 amd64 Pam module for the System Security Services Daemon Ensure that "libnss-sss" (the NSS module for retrieving user and group information) is installed with the following command: $ dpkg -l | grep libnss-sss ii libnss-sss:amd64 2.9.4-1.1ubuntu6.1 amd64 Nss library for the System Security Services Daemon

Fix: F-74596r1067155_fix

Install the sssd.service and the required pam packages with the following commands: $ sudo apt install -y sssd $ sudo apt install -y libpam-sss $ sudo apt install -y libnss-sss

Generate Mitigation Statement:

Checks: C-74696r1066476_chk

Verify the "sssd.service" is enabled and active with the following commands: $ sudo systemctl is-enabled sssd enabled $ sudo systemctl is-active sssd active If "sssd.service" is not active or enabled, this is a finding.

Fix: F-74597r1066477_fix

Enable the "sssd.service to start automatically on reboot with the following command: $ sudo systemctl enable sssd.service ensure the "sssd" service is running $ sudo systemctl start sssd.service

Generate Mitigation Statement:

Checks: C-74700r1067106_chk

Verify that the SSH daemon is configured to implement only FIPS-approved algorithms with the following command: $ sudo grep -r 'Ciphers' /etc/ssh/sshd_config* Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes128-ctr If any ciphers other than "Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes128-ctr" are listed, the "Ciphers" keyword is missing, or the returned line is commented out, or if multiple conflicting ciphers are returned, this is a finding.

Fix: F-74601r1066489_fix

Configure Ubuntu 24.04 LTS 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-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes128-ctr Restart the "sshd" service for changes to take effect: $ sudo systemctl restart sshd

Generate Mitigation Statement:

Checks: C-74701r1067108_chk

Verify the SSH daemon is configured to only use MACs that employ FIPS 140-3 approved ciphers with the following command: $ grep -irs macs /etc/ssh/sshd_config* MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256 If any algorithms other than "hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256" are listed, the returned line is commented out, or if conflicting results are returned, this is a finding.

Fix: F-74602r1067109_fix

Configure Ubuntu 24.04 LTS to allow the SSH daemon to only use MACs that employ FIPS 140-3 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-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256 Restart the "sshd" service for changes to take effect: $ sudo systemctl restart sshd

Generate Mitigation Statement:

Checks: C-74702r1067111_chk

Verify that the SSH daemon is configured to use only FIPS-validated key exchange algorithms with the following command: $ sudo grep -ir kexalgorithms /etc/ssh/sshd_config* KexAlgorithms ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group14-sha256 If "KexAlgorithms" does not contain only the algorithms "ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group14-sha256,diffie-hellman-group-exchange-sha256", is commented out, or is missing, this is a finding.

Fix: F-74603r1066495_fix

Configure the SSH daemon to use only FIPS-validated key exchange algorithms by adding or modifying the following line in "/etc/ssh/sshd_config": KexAlgorithms ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group14-sha256 Restart the "sshd" service for changes to take effect: $ sudo systemctl restart sshd

Generate Mitigation Statement:

Checks: C-74703r1067113_chk

Verify the SSH client is configured to use only ciphers employing FIPS 140-3 approved algorithms with the following command: $ sudo grep -r 'Ciphers' /etc/ssh/ssh_config* Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes128-ctr If any ciphers other than "Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes128-ctr" are listed, the "Ciphers" keyword is missing, or the returned line is commented out, or if multiple conflicting ciphers are returned, this is a finding.

Fix: F-74604r1067114_fix

Configure the Ubuntu 24.04 LTS SSH client to use only ciphers employing FIPS 140-3 approved algorithms by updating the "/etc/ssh/ssh_config" file with the following line: Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes128-ctr Restart the "ssh" service for changes to take effect: $ sudo systemctl restart ssh

Generate Mitigation Statement:

Checks: C-74704r1067116_chk

Verify the SSH client is configured to use only ciphers employing FIPS 140-3 approved algorithms with the following command: $ sudo grep -ir macs /etc/ssh/ssh_config* MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256 If any ciphers other than "hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256" are listed, or the returned line is commented out, this is a finding.

Fix: F-74605r1067117_fix

Configure the Ubuntu 24.04 LTS SSH client to use only MACs employing FIPS 140-3 approved algorithms by updating the "/etc/ssh/ssh_config" file with the following line: MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256 Restart the "ssh" service for changes to take effect: $ sudo systemctl restart ssh

Generate Mitigation Statement:

Checks: C-74705r1066503_chk

Verify the "opensc-pcks11" package is installed on the system with the following command: $ dpkg -l | grep opensc-pkcs11 ii opensc-pkcs11:amd64 0.25.0~rc1-1build2 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-74606r1067160_fix

Configure Ubuntu 24.04 LTS to accept PIV credentials. Install the "opensc-pkcs11" package using the following command: $ sudo apt install -y opensc-pkcs11

Generate Mitigation Statement:

Checks: C-74706r1067162_chk

Verify the "libpam-pcks11" package is installed on the system with the following command: $ dpkg -l | grep libpam-pkcs11 ii libpam-pkcs11 0.6.12-2build3 amd64 Fully featured PAM module for using PKCS#11 smart cards If the "libpam-pcks11" package is not installed, this is a finding.

Fix: F-74607r1067163_fix

Configure Ubuntu 24.04 LTS to accept PIV credentials that are managed through the PAM framework. Install the "libpam-pkcs11" package using the following command: $ sudo apt install -y libpam-pkcs11

Generate Mitigation Statement:

Checks: C-74707r1067165_chk

Verify Ubuntu 24.04 LTS has the "vlock" package installed with the following command: $ dpkg -l | grep vlock ii vlock 2.2.2-10 amd64 Virtual Console locking program If "vlock" is not installed, this is a finding.

Fix: F-74608r1067166_fix

Install the "vlock" package (if it is not already installed) by running the following command: $ sudo apt install -y vlock

Generate Mitigation Statement:

Checks: C-74709r1066515_chk

Verify that Ubuntu 24.04 LTS enables auditing at system startup in grub with the following command $ sudo grep "^\s*linux" /boot/grub/grub.cfg linux /vmlinuz-6.8.0-31-generic root=UUID=c92a542f-aee4-4af9-94b2-203624ccb8e3 ro audit=1 quiet splash $vt_handoff linux /vmlinuz-6.8.0-31-generic root=UUID=c92a542f-aee4-4af9-94b2-203624ccb8e3 ro recovery nomodeset dis_ucode_ldr audit=1 If any linux lines do not contain "audit=1", this is a finding.

Fix: F-74610r1066516_fix

Configure Ubuntu 24.04 LTS to produce audit records at system startup. Edit the "/etc/default/grub" file and add "audit=1" to the "GRUB_CMDLINE_LINUX" option so that the line looks like this: GRUB_CMDLINE_LINUX="audit=1" To update the grub config file, run: $ sudo update-grub

Generate Mitigation Statement:

Checks: C-74711r1066521_chk

Note: If Ubuntu 24.04 LTS does not have a graphical user interface installed, this requirement is not applicable. Verify the Ubuntu operation system has a graphical user interface session lock configured to activate after 10 minutes of inactivity with the following commands: Set the following settings to verify the graphical user interface session is configured to lock the graphical user session after 10 minutes of inactivity: **$ gsettings get org.gnome.desktop.screensaver lock-enabled true $ gsettings get org.gnome.desktop.screensaver lock-delay uint32 0 $ gsettings get org.gnome.desktop.session idle-delay uint32 600 Note: If "lock-enabled" is not set to "true", this is a finding. If "lock-delay" is set to a value greater than "0", or if "idle-delay" is set to a value greater than "600", or either settings are missing, this is a finding.

Fix: F-74612r1066522_fix

Configure Ubuntu 24.04 LTS to lock the current graphical user interface session after 10 minutes of inactivity. Set the following settings to allow graphical user interface session lock to initiate after 10 minutes of inactivity: $ gsettings set org.gnome.desktop.screensaver lock-enabled true $ gsettings set org.gnome.desktop.screensaver lock-delay 0 $ gsettings set org.gnome.desktop.session idle-delay 600

Generate Mitigation Statement:

Checks: C-74712r1066524_chk

Note: If Ubuntu 24.04 LTS does not have a graphical user interface installed, this requirement is not applicable. Verify the Ubuntu operation system has a graphical user interface session lock enabled with the following command: $ sudo gsettings get org.gnome.desktop.screensaver lock-enabled true If "lock-enabled" is not set to "true", this is a finding.

Fix: F-74613r1066525_fix

Configure Ubuntu 24.04 LTS to allow a user to lock the current graphical user interface session. Set the "lock-enabled" setting to allow graphical user interface session locks with the following command: $ gsettings set org.gnome.desktop.screensaver lock-enabled true

Generate Mitigation Statement:

Checks: C-74713r1066527_chk

Verify Ubuntu 24.04 LTS automatically terminates a user session after inactivity timeouts have expired with the following command: $ sudo grep -E "\bTMOUT=[0-9]+" /etc/bash.bashrc /etc/profile.d/* /etc/profile.d/99-terminal_tmout.sh:TMOUT=600 If "TMOUT" is not set, or if the value is "0" or is commented out, this is a finding.

Fix: F-74614r1066528_fix

Configure Ubuntu 24.04 LTS to automatically terminate a user session after inactivity timeouts have expired or at shutdown. Create the file "/etc/profile.d/99-terminal_tmout.sh" file if it does not exist. Modify or append the following line in the "/etc/profile.d/99-terminal_tmout.sh " file: TMOUT=600 This will set a timeout value of 10 minutes for all future sessions. To set the timeout for the current sessions, execute the following command over the terminal session: $ export TMOUT=600

Generate Mitigation Statement:

Checks: C-74714r1066530_chk

Verify that Ubuntu 24.04 LTS monitors all remote access methods with 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-74615r1066531_fix

Configure Ubuntu 24.04 LTS 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

Generate Mitigation Statement:

Checks: C-74715r1066533_chk

Verify temporary accounts have been provisioned with an expiration date of 72 hours with the following command: $ 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-74616r1066534_fix

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

Generate Mitigation Statement:

Checks: C-74716r1066536_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: $ grep INACTIVE /etc/default/useradd INACTIVE=35 If "INACTIVE" is not set to a value 0&lt;[VALUE]&lt;=35, is commented out, or is missing, this is a finding.

Fix: F-74617r1066537_fix

Configure Ubuntu 24.04 LTS to disable account identifiers after 35 days of inactivity after 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.

Generate Mitigation Statement:

Checks: C-74717r1066539_chk

Verify Ubuntu 24.04 LTS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd" 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-74618r1066540_fix

Configure Ubuntu 24.04 LTS 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

Generate Mitigation Statement:

Checks: C-74718r1066542_chk

Verify Ubuntu 24.04 LTS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group" 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-74619r1066543_fix

Configure Ubuntu 24.04 LTS 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

Generate Mitigation Statement:

Checks: C-74719r1066545_chk

Verify Ubuntu 24.04 LTS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/shadow" 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-74620r1066546_fix

Configure Ubuntu 24.04 LTS 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

Generate Mitigation Statement:

Checks: C-74720r1066548_chk

Verify Ubuntu 24.04 LTS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow" 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-74621r1066549_fix

Configure Ubuntu 24.04 LTS 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

Generate Mitigation Statement:

Checks: C-74721r1066551_chk

Verify Ubuntu 24.04 LTS generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd" 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-74622r1066552_fix

Configure Ubuntu 24.04 LTS 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

Generate Mitigation Statement:

Checks: C-74722r1066554_chk

Verify Ubuntu 24.04 LTS audits the execution of privilege functions by auditing the "execve" system call 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-74623r1066555_fix

Configure Ubuntu 24.04 LTS 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

Generate Mitigation Statement:

Checks: C-74724r1066560_chk

Verify Ubuntu 24.04 LTS displays the Standard Mandatory DOD Notice and Consent Banner before granting access via an SSH logon with the following command: $ sudo 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, missing, or 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-74625r1066561_fix

Configure Ubuntu 24.04 LTS to display the Standard Mandatory DOD Notice and Consent Banner before granting access via an SSH logon. 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

Generate Mitigation Statement:

Checks: C-74725r1066563_chk

Note: If the system does not have a graphical user interface installed, this requirement is not applicable. Verify Ubuntu 24.04 LTS is configured to display the Standard Mandatory DOD Notice and Consent Banner before granting access to Ubuntu 24.04 LTS via a graphical user logon with the following command: $ grep ^banner-message-enable /etc/gdm3/greeter.dconf-defaults banner-message-enable=true If the value for "banner-message-enable" is set to "false", the line is commented out, or no value is returned, this is a finding.

Fix: F-74626r1066564_fix

Configure Ubuntu 24.04 LTS to display the Standard Mandatory DOD Notice and Consent Banner before granting access to Ubuntu 24.04 LTS via a graphical user logon. Edit the "/etc/gdm3/greeter.dconf-defaults" file. Look for the "banner-message-enable" parameter under the "[org/gnome/login-screen]" section and uncomment it (remove the leading "#" characters): [org/gnome/login-screen] banner-message-enable=true Update the GDM with the new configuration: $ sudo dconf update $ sudo systemctl restart gdm3

Generate Mitigation Statement:

Checks: C-74726r1066566_chk

Note: If the system does not have a graphical user interface installed, this requirement is not applicable. Verify Ubuntu 24.04 LTS displays the Standard Mandatory DOD Notice and Consent Banner before granting access to Ubuntu 24.04 LTS via a graphical user logon with the command: $ grep ^banner-message-text /etc/gdm3/greeter.dconf-defaults banner-message-text="You are accessing a U.S. Government \(USG\) Information System \(IS\) that is provided for USG-authorized use only.\s+By using this IS \(which includes any device attached to this IS\), you consent to the following conditions:\s+-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.\s+-At any time, the USG may inspect and seize data stored on this IS.\s+-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.\s+-This IS includes security measures \(e.g., authentication and access controls\) to protect USG interests--not for your personal benefit or privacy.\s+-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-message-text is missing, commented out, or does not match the Standard Mandatory DOD Notice and Consent Banner exactly, this is a finding.

Fix: F-74627r1066567_fix

Configure Ubuntu 24.04 LTS displays the Standard Mandatory DOD Notice and Consent Banner before granting access to Ubuntu 24.04 LTS via a graphical user logon. Edit the "/etc/gdm3/greeter.dconf-defaults" file. Set the "banner-message-text" line to contain the appropriate banner message text as shown below: banner-message-text='You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.\n\nBy using this IS (which includes any device attached to this IS), you consent to the following conditions:\n\n-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.\n\n-At any time, the USG may inspect and seize data stored on this IS.\n\n-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.\n\n-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.\n\n-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.' Update the GDM with the new configuration: $ sudo dconf update $ sudo systemctl restart gdm3

Generate Mitigation Statement:

Checks: C-74727r1066569_chk

Verify Ubuntu 24.04 LTS is configured to prompt a user to acknowledge the Standard Mandatory DOD Notice and Consent Banner before granting access with the following command: $ less /etc/profile.d/ssh_confirm.sh #!/bin/bash if [ -n "$SSH_CLIENT" ] || [ -n "$SSH_TTY" ]; then while true; do read -p " 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. Do you agree? [y/N] " yn case $yn in [Yy]* ) break ;; [Nn]* ) exit 1 ;; esac done fi If the output does not match the text above, this is a finding.

Fix: F-74628r1066570_fix

Configure Ubuntu 24.04 LTS to prompt a user to acknowledge the Standard Mandatory DOD Notice and Consent Banner before granting access: $ sudo vi /etc/profile.d/ssh_confirm.sh #!/bin/bash if [ -n "$SSH_CLIENT" ] || [ -n "$SSH_TTY" ]; then while true; do read -p " 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. Do you agree? [y/N] " yn case $yn in [Yy]* ) break ;; [Nn]* ) exit 1 ;; esac done fi Note: The "ssh_confirm.sh" script is provided as a supplemental file to this document.

Generate Mitigation Statement:

Checks: C-74729r1066575_chk

Verify the systemwide 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" '{}' \; If any files are found to be group-writable or world-writable, this is a finding.

Fix: F-74630r1066576_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 '{}' \;

Generate Mitigation Statement:

Checks: C-74730r1066578_chk

Verify the systemwide 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 systemwide library file is returned, this is a finding.

Fix: F-74631r1066579_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 '{}' \;

Generate Mitigation Statement:

Checks: C-74731r1066581_chk

Verify the systemwide 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 systemwide library directory is returned, this is a finding.

Fix: F-74632r1066582_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 '{}' \;

Generate Mitigation Statement:

Checks: C-74732r1066584_chk

Verify the systemwide 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 systemwide shared library file is returned and is not group-owned by a required system account, this is a finding.

Fix: F-74633r1066585_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]

Generate Mitigation Statement:

Checks: C-74733r1066587_chk

Verify the systemwide 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 systemwide shared library directory is returned, this is a finding.

Fix: F-74634r1066588_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 '{}' \;

Generate Mitigation Statement:

Checks: C-74734r1066590_chk

Verify the system commands contained in the following directories 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-74635r1066591_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 '{}' \;

Generate Mitigation Statement:

Checks: C-74735r1066593_chk

Verify the system commands contained in the following directories are owned by root, or a required system account, with the following command: $ 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 not owned by a required system account, this is a finding.

Fix: F-74636r1066594_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]

Generate Mitigation Statement:

Checks: C-74736r1066596_chk

Verify the system commands contained in the following directories are group-owned by root or a required system account with the following command: $ find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin \-type f -perm -u=x -exec stat --format="%n %G" {} + | \awk '$2 != "root" &amp;&amp; $2 != "daemon" &amp;&amp; $2 != "adm" &amp;&amp; $2 != "shadow" &amp;&amp; $2 != "mail" &amp;&amp; $2 != "crontab" &amp;&amp; $2 != "_ssh"' Note: The above command uses awk to filter out common system accounts. If your system uses other required system accounts, add them to the awk condition to filter them out of the results. If any system commands are returned that are not group-owned by a required system account, this is a finding.

Fix: F-74637r1066597_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 [SYSTEMACCOUNT] [FILE]

Generate Mitigation Statement:

Checks: C-74737r1066599_chk

Verify Ubuntu 24.04 LTS 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-74638r1066600_fix

Configure Ubuntu 24.04 LTS 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

Generate Mitigation Statement:

Checks: C-74738r1066602_chk

Verify that Ubuntu 24.04 LTS uses "pwquality" to enforce the password complexity rules. Verify the pwquality module is being enforced by Ubuntu 24.04 LTS with 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 the value of "retry" is set to "0" or is greater than "3", or if a line is not returned, this is a finding.

Fix: F-74639r1066603_fix

Configure Ubuntu 24.04 LTS to use "pwquality" to enforce password complexity rules. 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: Ensure the value of "retry" is between "1" and "3".

Generate Mitigation Statement:

Checks: C-74740r1066608_chk

Verify the "/etc/sudoers" file has no occurrences of "NOPASSWD" or "!authenticate" with the following command: $ sudo egrep -i '(nopasswd|!authenticate)' /etc/sudoers /etc/sudoers.d/* If any occurrences of "NOPASSWD" or "!authenticate" return from the command, this is a finding.

Fix: F-74641r1066609_fix

Remove any occurrence of "NOPASSWD" or "!authenticate" found in "/etc/sudoers" file or files in the "/etc/sudoers.d" directory.

Generate Mitigation Statement:

Checks: C-74742r1066614_chk

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

Fix: F-74643r1066615_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

Generate Mitigation Statement:

Checks: C-74748r1066632_chk

Verify Ubuntu 24.04 LTS generates audit records for all events that affect "/var/log/journal" with the following command: $ sudo auditctl -l | grep journal -w /var/log/journal -p wa -k systemd_journal 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-74649r1066633_fix

Configure Ubuntu 24.04 LTS to generate audit records for events that affect "/var/log/journal". Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /var/log/journal -p wa -k systemd_journal To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74749r1066635_chk

Verify Ubuntu 24.04 LTS defines default permissions for all authenticated users in such a way that the user can read and modify only their own files with the following command: $ grep -i '^\s*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, this is a finding.

Fix: F-74650r1066636_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

Generate Mitigation Statement:

Checks: C-74751r1067127_chk

Verify that Ubuntu 24.04 LTS disables ability to load the USB storage kernel module with the following command: $ sudo grep usb-storage /etc/modprobe.d/* | grep "/bin/true" /etc/modprobe.d/DISASTIG.conf:install usb-storage /bin/true If the command does not return any output, or the line is commented out, this is a finding. Verify Ubuntu 24.04 LTS disables the ability to use USB mass storage device. $ sudo grep usb-storage /etc/modprobe.d/* | grep -i "blacklist" /etc/modprobe.d/DISASTIG.conf:blacklist usb-storage If the command does not return any output, or the line is commented out, this is a finding.

Fix: F-74652r1066642_fix

Configure Ubuntu 24.04 LTS to disable using the USB storage kernel module with the following command: $ sudo su -c "echo install usb-storage /bin/true >> /etc/modprobe.d/DISASTIG.conf" Configure Ubuntu 24.04 LTS to disable the ability to use USB mass storage devices with the following command: $ sudo su -c "echo blacklist usb-storage >> /etc/modprobe.d/DISASTIG.conf"

Generate Mitigation Statement:

Checks: C-74752r1066644_chk

Check the firewall configuration for any unnecessary or prohibited functions, ports, protocols, and/or services with 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 Components Local Services Assessment (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-74653r1066645_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>

Generate Mitigation Statement:

Checks: C-74753r1066647_chk

Verify Ubuntu 24.04 LTS contains no duplicate User IDs (UIDs) for interactive users with the following command: $ awk -F ":" 'list[$3]++{print $1, $3}' /etc/passwd If output is produced and the accounts listed are interactive user accounts, this is a finding.

Fix: F-74654r1066648_fix

Edit the file "/etc/passwd" and provide each interactive user account that has a duplicate UID with a unique UID.

Generate Mitigation Statement:

Checks: C-74754r1066650_chk

Verify that the "pam_pkcs11.so" module is configured with the following command: $ grep -r pam_pkcs11.so /etc/pam.d/common-auth auth [success=2 default=ignore] pam_pkcs11.so If the module is not configured, is missing, or commented out, this is a finding.

Fix: F-74655r1066651_fix

Configure Ubuntu 24.04 LTS to use multifactor authentication for 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

Generate Mitigation Statement:

Checks: C-74755r1067129_chk

Verify the sshd daemon allows public key authentication with the following command: $ sudo grep -r ^PubkeyAuthentication /etc/ssh/sshd_config* /etc/ssh/sshd_config:PubkeyAuthentication yes If "PubkeyAuthentication" is not set to "yes", is commented out, is missing, or conflicting results are returned, this is a finding.

Fix: F-74656r1066654_fix

Configure Ubuntu 24.04 LTS to use multifactor authentication for access to accounts. Set the sshd option "PubkeyAuthentication" to "yes" in the "/etc/ssh/sshd_config" file. PubkeyAuthentication yes

Generate Mitigation Statement:

Checks: C-74756r1066656_chk

Verify Ubuntu 24.04 LTS electronically verifies PIV credentials via certificate status checking 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 every returned "cert_policy" line is not set to "ocsp_on", or the line is commented out, this is a finding.

Fix: F-74657r1066657_fix

Configure Ubuntu 24.04 LTS 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".

Generate Mitigation Statement:

Checks: C-74757r1066659_chk

Verify Ubuntu 24.04 LTS prevents direct logins to the root account with the following command: $ sudo passwd -S root root L 04/08/2024 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-74658r1066660_fix

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

Generate Mitigation Statement:

Checks: C-74758r1066662_chk

Verify the Ubuntu operating system stores only encrypted representations of passwords with the following command: $ grep pam_unix.so /etc/pam.d/common-password password [success=1 default=ignore] pam_unix.so obscure sha512 shadow remember=5 rounds=100000 If the "sha512" parameter value is missing from the "pam_unix.so" line, this is a finding.

Fix: F-74659r1066663_fix

Configure Ubuntu 24.04 LTS to store encrypted representations of passwords. Add or modify the "sha512" 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=100000

Generate Mitigation Statement:

Checks: C-74759r1066665_chk

Verify Ubuntu 24.04 LTS enforces password complexity by requiring that at least one uppercase character be used with the following command: $ grep -i "ucredit" /etc/security/pwquality.conf ucredit=-1 If the "ucredit" parameter is greater than "-1", is commented out, or is missing, this is a finding.

Fix: F-74660r1066666_fix

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

Generate Mitigation Statement:

Checks: C-74760r1066668_chk

Verify Ubuntu 24.04 LTS enforces password complexity by requiring that at least one lowercase character be used with the following command: $ grep -i "lcredit" /etc/security/pwquality.conf lcredit=-1 If the "lcredit" parameter is greater than "-1", is commented out, or is missing, this is a finding.

Fix: F-74661r1066669_fix

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

Generate Mitigation Statement:

Checks: C-74761r1066671_chk

Verify Ubuntu 24.04 LTS 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", is commented out, or is missing, this is a finding.

Fix: F-74662r1066672_fix

Configure Ubuntu 24.04 LTS 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

Generate Mitigation Statement:

Checks: C-74762r1066674_chk

Verify Ubuntu 24.04 LTS requires the change of at least eight characters when passwords are changed 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-74663r1066675_fix

Configure Ubuntu 24.04 LTS 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

Generate Mitigation Statement:

Checks: C-74763r1066677_chk

Verify Ubuntu 24.04 LTS enforces a 24 hours/1 day minimum password lifetime for new user accounts with the following command: $ grep -i ^PASS_MIN_DAYS /etc/login.defs PASS_MIN_DAYS 1 If the "PASS_MIN_DAYS" parameter value is less than "1" or is commented out, this is a finding.

Fix: F-74664r1066678_fix

Configure Ubuntu 24.04 LTS to enforce a 24 hours/1 day minimum password lifetime. Add or modify the following line in the "/etc/login.defs" file: PASS_MIN_DAYS 1

Generate Mitigation Statement:

Checks: C-74764r1066680_chk

Verify Ubuntu 24.04 LTS enforces a 60-day maximum password lifetime for new user accounts with the following command: $ grep -i ^PASS_MAX_DAYS /etc/login.defs PASS_MAX_DAYS 60 If the "PASS_MAX_DAYS" parameter value is less than "60" or is commented out, this is a finding.

Fix: F-74665r1066681_fix

Configure Ubuntu 24.04 LTS to enforce a 60-day maximum password lifetime. Add or modify the following line in the "/etc/login.defs" file: PASS_MAX_DAYS 60

Generate Mitigation Statement:

Checks: C-74765r1066683_chk

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

Fix: F-74666r1066684_fix

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

Generate Mitigation Statement:

Checks: C-74766r1066686_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", is commented out, or is missing, this is a finding.

Fix: F-74667r1066687_fix

Configure Ubuntu 24.04 LTS 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

Generate Mitigation Statement:

Checks: C-74768r1066692_chk

Verify Ubuntu 24.04 LTS, for PKI-based authentication, has valid certificates by constructing a certification path to an accepted trust anchor. Ensure the pam service is listed under [sssd] with the following command: $ sudo grep -A 1 '^\[sssd\]' /etc/sssd/sssd.conf [sssd] services = nss,pam,ssh If "pam" is not listed in services, this is a finding. Additionally, ensure the pam service is set to use pam for smart card authentication in the [pam] section of /etc/sssd/sssd.conf with the following command: $ sudo grep -A 1 '^\[pam]' /etc/sssd/sssd.conf [pam] pam_cert_auth = True If "pam_cert_auth = True" is not returned, this is a finding. Ensure "ca" is enabled in "certificate_verification" with the following command: $ sudo grep certificate_verification /etc/sssd/sssd.conf certificate_verification = ca_cert,ocsp If "certificate_verification" is not set to "ca" or the line is commented out, this is a finding.

Fix: F-74669r1066693_fix

Configure Ubuntu 24.04 LTS, for PKI-based authentication, to validate certificates by constructing a certification path to an accepted trust anchor. Add or update the /etc/sssd/sssd.conf so that the following entries are in the correct sections of the file: $ sudo vi /etc/sssd/sssd.conf [sssd] services = nss,pam,ssh config_file_version = 2 [pam] pam_cert_auth = True [domain/example.com] ldap_user_certificate = usercertificate;binary certificate_verification = ca_cert,ocsp ca_cert = /etc/ssl/certs/ca-certificates.crt

Generate Mitigation Statement:

Checks: C-74770r1066698_chk

Verify Ubuntu 24.04 LTS, 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-74671r1067168_fix

Configure Ubuntu 24.04 LTS, 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 "https://manpages.ubuntu.com/manpages/xenial/man8/pam_pkcs11.8.html".

Generate Mitigation Statement:

Checks: C-74771r1066701_chk

Note: If smart card authentication is not being used on the system, this is not applicable. Verify Ubuntu 24.04 LTS, for PKI-based authentication, uses local revocation data when unable to access it from the network with the following command: $ 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-74672r1066702_fix

Configure Ubuntu 24.04 LTS, 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".

Generate Mitigation Statement:

Checks: C-74772r1067123_chk

Verify the shadow password suite configuration is set to encrypt passwords with a FIPS 140-3 approved cryptographic hashing algorithm with the following command: $ grep -i ENCRYPT_METHOD /etc/login.defs ENCRYPT_METHOD SHA512 If "ENCRYPT_METHOD" does not equal SHA512 or greater, this is a finding.

Fix: F-74673r1066705_fix

Configure Ubuntu 24.04 LTS 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

Generate Mitigation Statement:

Checks: C-74773r1066707_chk

Verify Ubuntu 24.04 LTS audits activities performed during nonlocal maintenance and diagnostic sessions 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-74674r1066708_fix

Configure Ubuntu 24.04 LTS 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

Generate Mitigation Statement:

Checks: C-74774r1066710_chk

Verify Ubuntu 24.04 LTS is configured to use strong authenticators in the establishment of nonlocal maintenance and diagnostic maintenance with the following command: $ sudo grep -r ^UsePAM /etc/ssh/sshd_config* /etc/ssh/sshd_config:UsePAM yes If "UsePAM" is not set to "yes", conflicting results are returned, the line is commented out, or is missing, this is a finding.

Fix: F-74675r1066711_fix

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

Generate Mitigation Statement:

Checks: C-74775r1066713_chk

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

Fix: F-74676r1066714_fix

Configure Ubuntu 24.04 LTS 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 ssh.service

Generate Mitigation Statement:

Checks: C-74776r1066716_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 with the following command: $ grep -ir ClientAliveInterval /etc/ssh/sshd_config* /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", if conflicting results are returned, is commented out, or is missing, this is a finding.

Fix: F-74677r1066717_fix

Configure Ubuntu 24.04 LTS to automatically terminate all network connections associated with SSH traffic at the end of a session or after a 10-minute period of inactivity. In the file /etc/ssh/sshd_config set ClientAliveInterval to a value of "600" or less: ClientAliveInterval 600 Restart the SSH daemon for the changes to take effect: $ sudo systemctl restart sshd.service

Generate Mitigation Statement:

Checks: C-74778r1066722_chk

Verify the directory containing the root certificates for Ubuntu 24.04 LTS contains certificate files for DOD PKI-established CAs by iterating over all files in the "/etc/ssl/certs" directory and checking if, at least one, has the subject matching "DOD ROOT CA". $ grep -ir DOD /etc/ssl/certs DOD_PKE_CA_chain.pem If no root certificate is found, this is a finding.

Fix: F-74679r1066723_fix

Configure Ubuntu 24.04 LTS to use of DOD PKI-established CAs 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 CA 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

Generate Mitigation Statement:

Checks: C-74779r1066725_chk

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

Fix: F-74680r1066726_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.

Generate Mitigation Statement:

Checks: C-74780r1066728_chk

Note: If there is a documented and approved mission requirement for data-at-rest to not be encrypted, this requirement is not applicable. Verify Ubuntu 24.04 LTS 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-74681r1066729_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.

Generate Mitigation Statement:

Checks: C-74783r1066737_chk

Verify all public (world-writeable) directories have the public sticky bit set with 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-74684r1066738_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]

Generate Mitigation Statement:

Checks: C-74786r1066746_chk

Verify Ubuntu 24.04 LTS is configured to use 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 -ir net.ipv4.tcp_syncookies /etc/sysctl.d/*.conf /run/sysctl.d/*.conf /usr/local/lib/sysctl.d/*.conf /usr/lib/sysctl.d/*.conf /lib/sysctl.d/*.conf /etc/sysctl.conf 2&gt; /dev/null /etc/sysctl.d/99-sysctl.conf:net.ipv4.tcp_syncookies=1 /etc/sysctl.conf:net.ipv4.tcp_syncookies=1 If the "net.ipv4.tcp_syncookies" option is not set to "1", is commented out, or is missing, this is a finding.

Fix: F-74687r1066747_fix

Configure Ubuntu 24.04 LTS to use TCP syncookies with 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

Generate Mitigation Statement:

Checks: C-74787r1066749_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: $ ss -l46ut Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process tcp LISTEN 0 511 *:http *:* tcp LISTEN 0 128 [::]:ssh [::]:* tcp LISTEN 0 128 [::]:ipp [::]:* tcp LISTEN 0 128 [::]:smtp [::]:* For each entry, verify the Uncomplicated Firewall (ufw) is configured to rate limit the service ports with the following command: $ sudo ufw status Status: active To Action From -- ------ ---- 80/tcp LIMIT Anywhere 25/tcp LIMIT Anywhere Anywhere DENY 177.60.7.4 443 LIMIT Anywhere 22/tcp LIMIT Anywhere 80/tcp (v6) LIMIT Anywhere 25/tcp (v6) LIMIT Anywhere 22/tcp (v6) LIMIT Anywhere (v6) 25 DENY OUT Anywhere 25 (v6) DENY OUT Anywhere (v6) If any port with a state of "LISTEN" that does not have an action of "DENY", is not marked with the "LIMIT" action, this is a finding. If the Status is set to anything other than "active" this is a finding.

Fix: F-74688r1066750_fix

Configure the application firewall to protect against or limit the effects of DoS attacks by ensuring Ubuntu 24.04 LTS is implementing rate-limiting measures on impacted network interfaces. To change the Status of ufw to "active" use the following command: $ sudo ufw enable 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

Generate Mitigation Statement:

Checks: C-74788r1066752_chk

Note: This requirement is not applicable for systems that do not have physical wireless network radios. Verify there are no wireless interfaces configured on the system with the following command: $ ls -L -d /sys/class/net/*/wireless | xargs dirname | xargs basename If a wireless interface is configured and has not been documented and approved by the information system security officer (ISSO), this is a finding.

Fix: F-74689r1066753_fix

List all the wireless interfaces with the following command: $ ls -L -d /sys/class/net/*/wireless | xargs dirname | xargs basename For each interface, configure the system to disable wireless network interfaces with the following command: $ sudo ifdown <interface name> For each interface listed, find their respective module with the following command: $ basename $(readlink -f /sys/class/net/<interface name>/device/driver) where <interface name> must be substituted by the actual interface name. Create a file in the "/etc/modprobe.d" directory and for each module, add the following line: install <module name> /bin/true For each module from the system, execute the following command to remove it: $ sudo modprobe -r <module name>

Generate Mitigation Statement:

Checks: C-74789r1066755_chk

Verify Ubuntu 24.04 LTS has all system log files under the /var/log directory with a permission set to "640" or less permissive with 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-74690r1066756_fix

Configure Ubuntu 24.04 LTS 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 '{}' \;

Generate Mitigation Statement:

Checks: C-74790r1066758_chk

Verify the /run/log/journal and /var/log/journal directories have permissions set to "2640" or less permissive with the following command: $ sudo find /run/log/journal /var/log/journal -type d -exec stat -c "%n %a" {} \; /run/log/journal 2640 /var/log/journal 2640 /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e 2640 If any output returned has a permission set greater than 2640, this is a finding. Verify all files in the /run/log/journal and /var/log/journal directories have permissions set to "640" or less permissive with the following command: $ sudo find /run/log/journal /var/log/journal -type f -exec stat -c "%n %a" {} \; /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/system.journal 640 /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/user-1000@0005f97cd4a8c9b5a.journal~ 640 /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/system@0005f97cd2a1e0a7-d58b848af46813a4.journal~ 640 /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/system@0005f97cb900e501-55ea053b7f75ae1c.journal~ 640 /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/user-1000.journal 640 If any output returned has a permission set greater than "640", this is a finding.

Fix: F-74691r1066759_fix

Configure the system to set the appropriate permissions to the files and directories used by the systemd journal: $ sudo nano /usr/lib/tmpfiles.d/systemd.conf Edit the following lines of the configuration file: z /run/log/journal 2640 root systemd-journal - - Z /run/log/journal/%m ~2640 root systemd-journal - - z /var/log/journal 2640 root systemd-journal - - z /var/log/journal/%m 2640 root systemd-journal - - z /var/log/journal/%m/system.journal 0640 root systemd-journal - - Note: The system must be restarted for these settings to take effect.

Generate Mitigation Statement:

Checks: C-74791r1066761_chk

Verify the journalctl command has a permission set of "740" with the following command: $ sudo find /usr/bin/journalctl -exec stat -c "%n %a" {} \; /usr/bin/journalctl 740 If journalctl is not set to "740", this is a finding

Fix: F-74692r1066762_fix

Configure journalctl to have a permission set of "740": $ sudo chmod 740 /usr/bin/journalctl

Generate Mitigation Statement:

Checks: C-74792r1068366_chk

Verify the journalctl command is owned by "root" with the following command: $ sudo find /usr/bin/journalctl -exec stat -c "%n %U" {} \; /usr/bin/journalctl root If journalctl is not owned by "root", this is a finding.

Fix: F-74693r1066765_fix

Configure journalctl to be owned by "root": $ sudo chown root /usr/bin/journalctl

Generate Mitigation Statement:

Checks: C-74793r1066767_chk

Verify the journalctl command is group-owned by "root" with the following command: $ sudo find /usr/bin/journalctl -exec stat -c "%n %G" {} \; /usr/bin/journalctl root If journalctl is not group-owned by "root", this is a finding

Fix: F-74694r1066768_fix

Configure journalctl to be group-owned by "root": $ sudo chown :root /usr/bin/journalctl

Generate Mitigation Statement:

Checks: C-74794r1066770_chk

Verify the /run/log/journal and /var/log/journal directories are group-owned by "systemd-journal" with the following command: $ sudo find /run/log/journal /var/log/journal -type d -exec stat -c "%n %G" {} \; /run/log/journal systemd-journal /var/log/journal systemd-journal /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e systemd-journal If any output returned is not group-owned by "systemd-journal", this is a finding.

Fix: F-74695r1067180_fix

Configure the system to set the appropriate group-ownership to the directories used by the systemd journal: $ sudo nano /usr/lib/tmpfiles.d/systemd.conf Edit the following lines of the configuration file: z /run/log/journal 2640 root systemd-journal - - z /var/log/journal 2640 root systemd-journal - - Note: The system must be restarted for these settings to take effect.

Generate Mitigation Statement:

Checks: C-74795r1066773_chk

Verify the /run/log/journal and /var/log/journal files are group-owned by "systemd-journal" with the following command: $ sudo find /run/log/journal /var/log/journal -type f -exec stat -c "%n %G" {} \; /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/system.journal systemd-journal /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/user-1000@0005f97cd4a8c9b5-f088232c3718485a.journal~ systemd-journal /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/system@0005f97cd2a1e0a7-d58b848af46813a4.journal~ systemd-journal /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/system@0005f97cb900e501-55ea053b7f75ae1c.journal~ systemd-journal /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/user-1000.journal systemd-journal If any output returned is not group-owned by "systemd-journal", this is a finding.

Fix: F-74696r1066774_fix

Configure the system to set the appropriate group-ownership to the files used by the systemd journal: Z /run/log/journal/%m ~2640 root systemd-journal - - z /var/log/journal/%m 2640 root systemd-journal - - z /var/log/journal/%m/system.journal 0640 root systemd-journal - - Note: The system must be restarted for these settings to take effect.

Generate Mitigation Statement:

Checks: C-74796r1066776_chk

Verify the /run/log/journal and /var/log/journal directories are owned by "root" with the following command: $ sudo find /run/log/journal /var/log/journal -type d -exec stat -c "%n %U" {} \; /run/log/journal root /var/log/journal root /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e root If any output returned is not owned by "root", this is a finding.

Fix: F-74697r1066777_fix

Configure the system to set the appropriate ownership to the directories used by the systemd journal: $ sudo nano /usr/lib/tmpfiles.d/systemd.conf Edit the following lines of the configuration file: z /run/log/journal 2640 root systemd-journal - - z /var/log/journal 2640 root systemd-journal - - Note: The system must be restarted for these settings to take effect.

Generate Mitigation Statement:

Checks: C-74797r1066779_chk

Verify the /run/log/journal and /var/log/journal files are owned by "root" with the following command: $ sudo find /run/log/journal /var/log/journal -type f -exec stat -c "%n %U" {} \; /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/system.journal root /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/user-1000@0005f97cd4a8c9b5-f088232c3718485a.journal~ root /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/system@0005f97cd2a1e0a7-d58b848af46813a4.journal~ root /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/system@0005f97cb900e501-55ea053b7f75ae1c.journal~ root /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/user-1000.journal root If any output returned is not owned by "root", this is a finding.

Fix: F-74698r1066780_fix

Configure the system to set the appropriate ownership to the files used by the systemd journal: $ sudo nano /usr/lib/tmpfiles.d/systemd.conf Edit the following lines of the configuration file: Z /run/log/journal/%m ~2640 root systemd-journal - - z /var/log/journal/%m 2640 root systemd-journal - - z /var/log/journal/%m/system.journal 0640 root systemd-journal - - Note: The system must be restarted for these settings to take effect.

Generate Mitigation Statement:

Checks: C-74798r1066782_chk

Verify that Ubuntu 24.04 LTS configures the /var/log directory to be group-owned by "syslog" with the following command: $ 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-74699r1066783_fix

Configure Ubuntu 24.04 LTS to have syslog group-own the /var/log directory with the following command: $ sudo chgrp syslog /var/log

Generate Mitigation Statement:

Checks: C-74799r1066785_chk

Verify Ubuntu 24.04 LTS configures the /var/log directory to be owned by "root" with the following command: $ 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-74700r1066786_fix

Configure Ubuntu 24.04 LTS to have root own the /var/log directory by running the following command: $ sudo chown root /var/log

Generate Mitigation Statement:

Checks: C-74800r1066788_chk

Note: If rsyslog is active and enabled on Ubuntu 24.04 LTS, this requirement is not applicable. Verify Ubuntu 24.04 LTS configures the /var/log directory with a mode of "755" or less permissive with the following command: $ 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-74701r1066789_fix

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

Generate Mitigation Statement:

Checks: C-74801r1066791_chk

Verify that Ubuntu 24.04 LTS configures the /var/log/syslog file to be group-owned by "adm" with the following command: $ 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-74702r1066792_fix

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

Generate Mitigation Statement:

Checks: C-74802r1066794_chk

Verify that Ubuntu 24.04 LTS configures the /var/log/syslog file to be owned by "syslog" with the following command: $ 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-74703r1066795_fix

Configure Ubuntu 24.04 LTS to have syslog own the /var/log/syslog file by running the following command: $ sudo chown syslog /var/log/syslog

Generate Mitigation Statement:

Checks: C-74803r1066797_chk

Verify that Ubuntu 24.04 LTS configures the /var/log/syslog file with mode "0640" or less permissive with the following command: $ 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-74704r1066798_fix

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

Generate Mitigation Statement:

Checks: C-74804r1066800_chk

Verify the NX (no-execution) bit flag is set on the system with the following command: $ 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-74705r1066801_fix

Configure Ubuntu 24.04 LTS 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".

Generate Mitigation Statement:

Checks: C-74805r1066803_chk

Verify Ubuntu 24.04 LTS implements address space layout randomization (ASLR) with the following command: $ 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-74706r1066804_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

Generate Mitigation Statement:

Checks: C-74806r1066806_chk

Verify APT 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", are commented out, or are missing, this is a finding.

Fix: F-74707r1066807_fix

Configure APT to remove all software components after updated versions have been installed. Add or update 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";

Generate Mitigation Statement:

Checks: C-74807r1066809_chk

Verify the version of Ubuntu 24.04 LTS is vendor supported with the following command: $ grep DISTRIB_DESCRIPTION /etc/lsb-release DISTRIB_DESCRIPTION="Ubuntu 24.04.1 LTS" If the installed version of Ubuntu 24.04 LTS is not supported, this is a finding.

Fix: F-74708r1066810_fix

Upgrade to a supported version of Ubuntu 24.04 LTS.

Generate Mitigation Statement:

Checks: C-74808r1068368_chk

Verify /etc/audit/audit.rules, /etc/audit/rules.d/*, and /etc/audit/auditd.conf files have a mode of "0640" or less permissive with 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 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 244 Dec 27 09:56 audit.rules -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 files have a mode more permissive than "0640", this is a finding.

Fix: F-74709r1066813_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/*

Generate Mitigation Statement:

Checks: C-74809r1066815_chk

Verify /etc/audit/audit.rules, /etc/audit/rules.d/*, and /etc/audit/auditd.conf files are owned by "root" account with 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 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 244 Dec 27 09:56 audit.rules -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-74710r1066816_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/*

Generate Mitigation Statement:

Checks: C-74810r1066818_chk

Verify /etc/audit/audit.rules, /etc/audit/rules.d/*, and /etc/audit/auditd.conf files are owned by "root" group with 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 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 244 Dec 27 09:56 audit.rules -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-74711r1066819_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/*

Generate Mitigation Statement:

Checks: C-74811r1066821_chk

Verify Ubuntu 24.04 LTS generates audit records upon successful/unsuccessful attempts to use the "su" command with the following command: $ sudo auditctl -l | grep /bin/su -a always,exit -F path=/bin/su -F perm=x -F auid&gt;=1000 -F auid!=-1 -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-74712r1066822_fix

Configure Ubuntu 24.04 LTS 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!=-1 -k privileged-priv_change To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74812r1066824_chk

Verify Ubuntu 24.04 LTS generates audit records upon successful/unsuccessful attempts to use the "chfn" command with the following command: $ sudo auditctl -l | grep /usr/bin/chfn -a always,exit -F path=/usr/bin/chfn -F perm=x -F auid&gt;=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-74713r1066825_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!=-1 -k privileged-chfn To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74813r1066827_chk

Verify Ubuntu 24.04 LTS generates audit records upon successful/unsuccessful attempts to use the "mount" command with the following command: $ sudo auditctl -l | grep /usr/bin/mount -a always,exit -F path=/usr/bin/mount -F perm=x -F auid&gt;=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-74714r1066828_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!=-1 -k privileged-mount To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74814r1066830_chk

Verify Ubuntu 24.04 LTS generates audit records upon successful/unsuccessful attempts to use the "umount" command with the following command: $ sudo auditctl -l | grep /usr/bin/umount -a always,exit -F path=/usr/bin/umount -F perm=x -F auid&gt;=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-74715r1066831_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!=-1 -k privileged-umount To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74815r1066833_chk

Verify Ubuntu 24.04 LTS generates an audit record upon successful/unsuccessful attempts to use the "ssh-agent" command with the following command: $ sudo auditctl -l | grep /usr/bin/ssh-agent -a always,exit -F path=/usr/bin/ssh-agent -F perm=x -F auid&gt;=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-74716r1066834_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!=-1 -k privileged-ssh To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74816r1066836_chk

Verify Ubuntu 24.04 LTS generates an audit record upon successful/unsuccessful attempts to use the "ssh-keysign" command with the following command: $ sudo auditctl -l | grep ssh-keysign -a always,exit -F path=/usr/lib/openssh/ssh-keysign -F perm=x -F auid&gt;=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-74717r1066837_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!=-1 -k privileged-ssh To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74817r1068370_chk

Verify Ubuntu 24.04 LTS generates an audit record upon successful/unsuccessful attempts to use the "setxattr", "fsetxattr", "lsetxattr", "removexattr", "fremovexattr", and "lremovexattr" system calls with the following command: $ sudo auditctl -l | grep xattr -a always,exit -F arch=b32 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid&gt;=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&gt;=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-74718r1066840_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!=-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 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

Generate Mitigation Statement:

Checks: C-74818r1068372_chk

Verify Ubuntu 24.04 LTS generates an audit record upon successful/unsuccessful attempts to use the "chown", "fchown", "fchownat", and "lchown" system calls with the following command: $ sudo auditctl -l | grep chown -a always,exit -F arch=b32 -S chown,fchown,fchownat,lchown -F auid&gt;=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F auid&gt;=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-74719r1066843_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!=-1 -k perm_chng -a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=-1 -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

Generate Mitigation Statement:

Checks: C-74819r1068374_chk

Verify Ubuntu 24.04 LTS generates an audit record upon successful/unsuccessful attempts to use the "chmod", "fchmod", and "fchmodat" system calls with the following command: $ sudo auditctl -l | grep chmod -a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid&gt;=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid&gt;=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-74720r1066846_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!=-1 -k perm_chng -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -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

Generate Mitigation Statement:

Checks: C-74820r1068376_chk

Verify Ubuntu 24.04 LTS generates an audit record upon unsuccessful attempts to use the "creat", "open", "openat", "open_by_handle_at", "truncate", and "ftruncate" system calls with the following command: $ 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&gt;=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&gt;=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&gt;=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&gt;=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-74721r1068377_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!=-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 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

Generate Mitigation Statement:

Checks: C-74821r1066851_chk

Verify an audit event is generated for any successful/unsuccessful use of the "sudo" command with the following command: $ sudo auditctl -l | grep /usr/bin/sudo -a always,exit -F path=/usr/bin/sudo -F perm=x -F auid&gt;=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-74722r1066852_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!=-1 -k priv_cmd To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74822r1066854_chk

Verify Ubuntu 24.04 LTS generates an audit record upon successful/unsuccessful attempts to use the "sudoedit" command with the following command: $ sudo auditctl -l | grep /usr/bin/sudoedit -a always,exit -F path=/usr/bin/sudoedit -F perm=x -F auid&gt;=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-74723r1066855_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!=-1 -k priv_cmd To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74823r1068379_chk

Verify Ubuntu 24.04 LTS generates an audit record upon successful/unsuccessful attempts to use the "chsh" command with the following command: $ sudo auditctl -l | grep chsh -a always,exit -F path=/usr/bin/chsh -F perm=x -F auid&gt;=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-74724r1066858_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!=-1 -k priv_cmd To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74824r1066860_chk

Verify Ubuntu 24.04 LTS generates an audit record upon successful/unsuccessful attempts to use the "newgrp" command with the following command: $ sudo auditctl -l | grep newgrp -a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid&gt;=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-74725r1066861_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!=-1 -k priv_cmd To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74825r1066863_chk

Verify Ubuntu 24.04 LTS generates an audit record upon successful/unsuccessful attempts to use the "chcon" command with the following command: $ sudo auditctl -l | grep chcon -a always,exit -F path=/usr/bin/chcon -F perm=x -F auid&gt;=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-74726r1066864_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!=-1 -k perm_chng To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74826r1066866_chk

Verify Ubuntu 24.04 LTS generates an audit record upon successful/unsuccessful attempts to use the "apparmor_parser" command with the following command: $ sudo auditctl -l | grep apparmor_parser -a always,exit -F path=/sbin/apparmor_parser -F perm=x -F auid&gt;=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-74727r1066867_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!=-1 -k perm_chng To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74827r1066869_chk

Verify Ubuntu 24.04 LTS generates an audit record upon successful/unsuccessful attempts to use the "setfacl" command with the following command: $ sudo auditctl -l | grep setfacl -a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid&gt;=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-74728r1066870_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!=-1 -k perm_chng To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74828r1066872_chk

Verify Ubuntu 24.04 LTS generates an audit record upon successful/unsuccessful attempts to use the "chacl" command with the following command: $ sudo audtctl -l | grep chacl -a always,exit -F path=/usr/bin/chacl -F perm=x -F auid&gt;=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-74729r1066873_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!=-1 -k perm_chng To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74829r1066875_chk

Verify Ubuntu 24.04 LTS generates an audit record upon successful/unsuccessful modifications to the "faillog" file 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-74730r1066876_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

Generate Mitigation Statement:

Checks: C-74830r1066878_chk

Verify Ubuntu 24.04 LTS generates an audit record when successful/unsuccessful modifications to the "lastlog" file occur 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-74731r1066879_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

Generate Mitigation Statement:

Checks: C-74831r1068381_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "passwd" command 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&gt;=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 "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

Fix: F-74732r1066882_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!=-1 -k privileged-passwd To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74832r1066884_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "unix_update" command with the following command: $ sudo auditctl -l | grep -w unix_update -a always,exit -F path=/sbin/unix_update -F perm=x -F auid&gt;=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-74733r1066885_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!=-1 -k privileged-unix-update To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74833r1066887_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "gpasswd" command with the following command: $ sudo auditctl -l | grep -w gpasswd -a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid&gt;=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-74734r1066888_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!=-1 -k privileged-gpasswd To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74834r1066890_chk

Verify that an audit event is generated for any successful/unsuccessful use of the "chage" command with the following command: $ sudo auditctl -l | grep -w chage -a always,exit -F path=/usr/bin/chage -F perm=x -F auid&gt;=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-74735r1066891_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!=-1 -k privileged-chage To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74835r1066893_chk

Verify an audit event is generated for any successful/unsuccessful use of the "usermod" command with the following command: $ sudo auditctl -l | grep -w usermod -a always,exit -F path=/usr/sbin/usermod -F perm=x -F auid&gt;=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-74736r1066894_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!=-1 -k privileged-usermod To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74836r1066896_chk

Verify an audit event is generated for any successful/unsuccessful use of the "crontab" command with the following command: $ sudo auditctl -l | grep -w crontab -a always,exit -F path=/usr/bin/crontab -F perm=x -F auid&gt;=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-74737r1066897_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!=-1 -k privileged-crontab To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74837r1066899_chk

Verify an audit event is generated for any successful/unsuccessful use of the "pam_timestamp_check" command 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&gt;=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-74738r1066900_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!=-1 -k privileged-pam_timestamp_check To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74838r1068383_chk

Verify Ubuntu 24.04 LTS generates an audit record for any successful/unsuccessful attempts to use the "init_module" and "finit_module" syscalls with the following command: $ sudo auditctl -l | grep init_module -a always,exit -F arch=b32 -S init_module,finit_module -F auid&gt;=1000 -F auid!=-1 -k module_chng -a always,exit -F arch=b64 -S init_module,finit_module -F auid&gt;=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-74739r1066903_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!=-1 -k module_chng -a always,exit -F arch=b64 -S init_module,finit_module -F auid>=1000 -F auid!=-1 -k module_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

Generate Mitigation Statement:

Checks: C-74839r1068385_chk

Verify Ubuntu 24.04 LTS generates an audit record for any successful/unsuccessful attempts to use the "delete_module" syscall with the following command: $ sudo auditctl -l | grep -w delete_module -a always,exit -F arch=b32 -S delete_module -F auid&gt;=1000 -F auid!=-1 -k module_chng -a always,exit -F arch=b64 -S delete_module -F auid&gt;=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-74740r1066906_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!=-1 -k module_chng -a always,exit -F arch=b64 -S delete_module -F auid>=1000 -F auid!=-1 -k module_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

Generate Mitigation Statement:

Checks: C-74840r1066908_chk

Verify Ubuntu 24.04 LTS generates audit records for all modifications that affect "/etc/sudoers" with the following command: $ sudo auditctl -l | grep sudoers -w /etc/sudoers -p wa -k privilege_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-74741r1066909_fix

Configure Ubuntu 24.04 LTS to generate audit records for all modifications that affect "/etc/sudoers". Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/sudoers -p wa -k privilege_modification To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74841r1066911_chk

Verify Ubuntu 24.04 LTS generates audit records for all modifications that affect "/etc/sudoers.d" directory with the following command: $ sudo auditctl -l | grep sudoers.d -w /etc/sudoers.d -p wa -k privilege_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-74742r1066912_fix

Configure Ubuntu 24.04 LTS to generate audit records for all modifications that affect "/etc/sudoers.d" directory. Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/sudoers.d -p wa -k privilege_modification To reload the rules file, issue the following command: $ sudo augenrules --load

Generate Mitigation Statement:

Checks: C-74842r1068387_chk

Verify Ubuntu 24.04 LTS generates audit records for any successful/unsuccessful use of "unlink", "unlinkat", "rename", "renameat", and "rmdir" system calls 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&gt;=1000 -F auid!=-1 -F key=delete -a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat,rmdir -F auid&gt;=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 "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

Fix: F-74743r1066915_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!=-1 -k delete -a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat,rmdir -F auid>=1000 -F auid!=-1 -k delete 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

Generate Mitigation Statement:

Checks: C-74843r1066917_chk

Verify Ubuntu 24.04 LTS generates audit records showing start and stop times for user access to the system via the "/var/log/wtmp" file 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-74744r1066918_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

Generate Mitigation Statement:

Checks: C-74844r1066920_chk

Verify Ubuntu 24.04 LTS generates audit records showing start and stop times for user access to the system via the "/var/run/utmp" file 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-74745r1066921_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

Generate Mitigation Statement:

Checks: C-74845r1066923_chk

Verify Ubuntu 24.04 LTS generates audit records showing start and stop times for user access to the system via the "/var/log/btmp" file 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-74746r1066924_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

Generate Mitigation Statement:

Checks: C-74846r1066926_chk

Verify if Ubuntu 24.04 LTS is configured to audit the execution of the module management program "modprobe" with 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-74747r1066927_fix

Configure Ubuntu 24.04 LTS 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

Generate Mitigation Statement:

Checks: C-74847r1066929_chk

Verify Ubuntu 24.04 LTS is configured to audit the execution of the module management program "kmod" 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-74748r1066930_fix

Configure Ubuntu 24.04 LTS 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

Generate Mitigation Statement:

Checks: C-74848r1066932_chk

Verify Ubuntu 24.04 LTS is configured to audit the execution of the partition management program "fdisk" 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-74749r1066933_fix

Configure Ubuntu 24.04 LTS 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

Generate Mitigation Statement:

Checks: C-74854r1066950_chk

Verify Ubuntu 24.04 LTS configures the audit tools to have a file permission of "0755" or less to prevent unauthorized access with 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-74755r1066951_fix

Configure the audit tools on Ubuntu 24.04 LTS 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.

Generate Mitigation Statement:

Checks: C-74855r1066953_chk

Verify Ubuntu 24.04 LTS configures the audit tools to be owned by root to prevent any unauthorized access with 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-74756r1066954_fix

Configure the audit tools on Ubuntu 24.04 LTS 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.

Generate Mitigation Statement:

Checks: C-74856r1066956_chk

Verify Ubuntu 24.04 LTS configures the audit tools to be group-owned by root to prevent any unauthorized access with 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-74757r1066957_fix

Configure the audit tools on Ubuntu 24.04 LTS 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.

Generate Mitigation Statement:

Checks: C-74857r1066959_chk

Verify the system commands 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-74758r1066960_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 '{}' \;

Generate Mitigation Statement:

Checks: C-74858r1066962_chk

Verify the system commands directories are owned by root with the following command: $ 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-74759r1066963_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 '{}' \;

Generate Mitigation Statement:

Checks: C-74859r1066965_chk

Verify the system commands directories are group-owned by root 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-74760r1066966_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 '{}' \;

Generate Mitigation Statement:

Checks: C-74860r1066968_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 with 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-74761r1066969_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/*

Generate Mitigation Statement:

Checks: C-74861r1066971_chk