Linux STIGs

Verify the telnet package is not installed on Ubuntu 24.04 LTS with the following command: $ dpkg -l | grep telnetd If the telnetd package is installed, this is a finding.

Remove the telnet package from Ubuntu 24.04 LTS with the following command: $ sudo apt remove telnetd

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

Configure Ubuntu 24.04 LTS to disable nonessential capabilities by removing the rsh-server package from the system with the following command: $ sudo apt remove rsh-server

Note: If NFS mounts are authorized and in use on the system, this control is not applicable. Verify that Ubuntu 24.04 LTS does not have the nfs-kernel-server package installed. Determine if packages are installed: $ sudo dpkg -l | grep -E 'nfs-kernel-server' If the nfs-kernel-server package is installed, this is a finding.

Configure the Ubuntu 24.04 LTS operating system to disable nonessential capabilities by removing the nfs-kernel-server package from the system with the following commands: Remove packages if present: $ sudo apt purge --yes nfs-kernel-server Remove any unneeded dependencies: $ sudo apt autoremove --yes Verify that NFS services are gone: $ sudo systemctl list-units --type=service | grep nfs

Verify the SSH package is installed with the following command: $ dpkg -l | grep openssh ii openssh-client 1:9.6p1-3ubuntu13.5 amd64 secure shell (SSH) client, for secure access to remote machines ii openssh-server 1:9.6p1-3ubuntu13.5 amd64 secure shell (SSH) server, for secure access from remote machines ii openssh-sftp-server 1:9.6p1-3ubuntu13.5 amd64 secure shell (SSH) sftp server module, for SFTP access from remote machines If the "openssh" server package is not installed, this is a finding.

Install the "ssh" meta-package on the system with the following command: $ sudo apt install -y ssh

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

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

Verify Ubuntu 24.04 LTS requires a password for authentication upon booting into single-user and maintenance modes with the following command: $ sudo grep -i password /boot/grub/grub.cfg password_pbkdf2 root grub.pbkdf2.sha512.10000.MFU48934NJA87HF8NSD34493GDHF84NG If the root password entry does not begin with "password_pbkdf2", this is a finding.

Configure the system to require a password for authentication upon booting into single-user and maintenance modes. Generate an encrypted (grub) password for root with the following command: $ grub-mkpasswd-pbkdf2 Enter Password: Reenter Password: PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.MFU48934NJD84NF8NSD39993JDHF84NG Using the hash from the output, modify the "/etc/grub.d/40_custom" file with the following command to add a boot password: $ sudo sed -i '$i set superusers=\"root\"\npassword_pbkdf2 root ' /etc/grub.d/40_custom where is the hash generated by grub-mkpasswd-pbkdf2 command. Generate an updated "grub.conf" file with the new password by using the following command: $ sudo update-grub

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

Edit the "/etc/ssh/sshd_config" file to uncomment or add the line for the "X11Forwarding" keyword and set its value to "no" (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor): X11Forwarding no Restart SSH for the changes to take effect: $ sudo systemctl restart ssh

Verify Ubuntu 24.04 LTS is not configured to reboot the system when Ctrl-Alt-Delete is pressed when using a graphical user interface with the following command: $ gsettings get org.gnome.settings-daemon.plugins.media-keys logout @as [] If the "logout" key is bound to an action, is commented out, or is missing, this is a finding.

Configure Ubuntu 24.04 LTS to disable the Ctrl-Alt-Delete sequence when using a graphical user interface. Create or edit a file named /etc/dconf/db/local.d/00-mediakeys with the following contents: [org/gnome/settings-daemon/plugins/media-keys] logout=@as [] Update the dconf settings: $ sudo dconf update

Verify Ubuntu 24.04 LTS is not configured to reboot the system when Ctrl-Alt-Delete is pressed with the following command: $ systemctl status ctrl-alt-del.target o ctrl-alt-del.target Loaded: masked (Reason: Unit ctrl-alt-del.target is masked.) Active: inactive (dead) If the "ctrl-alt-del.target" is not masked, this is a finding.

Configure the system to disable the Ctrl-Alt-Delete sequence for the command line with the following commands: $ sudo systemctl disable ctrl-alt-del.target [...] $ sudo systemctl mask ctrl-alt-del.target Created symlink /etc/systemd/system/ctrl-alt-del.target ? /dev/null. Reload the daemon to take effect: $ sudo systemctl daemon-reload

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

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

To verify null passwords cannot be used, run the following command: $ grep nullok /etc/pam.d/common-password /etc/pam.d/common-auth If this produces any output, this is a finding.

If an account is configured for password authentication but does not have an assigned password, it is possible to log on to the account without authenticating. Remove any instances of the "nullok" option in "/etc/pam.d/common-password" and "/etc/pam.d/common-auth" to prevent logons with empty passwords.

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

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

Verify that authenticated certificates are mapped to the appropriate user group in the "/etc/sssd/sssd.conf" file with the following command: $ grep -i ldap_user_certificate /etc/sssd/sssd.conf ldap_user_certificate=userCertificate;binary

Configure sssd to map authenticated certificates to the appropriate user group by adding the following line to the "/etc/sssd/sssd.conf" file: ldap_user_certificate=userCertificate;binary

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

Configure the system to run in FIPS mode. Add "fips=1" to the kernel parameter during Ubuntu 24.04 LTSs install. Enabling a FIPS mode on a pre-existing system involves a number of modifications to Ubuntu 24.04 LTS. Refer to the Ubuntu Pro security certification documentation for instructions. A subscription to the "Ubuntu Pro" plan is required to obtain the FIPS Kernel cryptographic modules and enable FIPS. Note: Ubuntu Pro security certification instructions can be found at: https://ubuntu.com/security/certifications/docs/fips-enablement The basic steps use the following commands: $ sudo pro attach $ sudo pro enable fips-updates

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.

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.

Verify the sudo group has only members who require access to security functions with the following command: $ grep sudo /etc/group sudo:x:27:foo If the sudo group contains users not needing access to security functions, this is a finding.

Configure the sudo group with only members requiring access to security functions. To remove a user from the sudo group, run: $ sudo gpasswd -d sudo

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.3 LTS" Check the subscription status of the system with the following command: $ pro status If the installed version of Ubuntu 24.04 LTS is not supported, this is a finding.

Upgrade to a supported version of Ubuntu 24.04 LTS.

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.

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

Note: If a file integrity tool other than Advanced Intrusion Detection Environment (AIDE) is employed, this requirement is not applicable. Verify AIDE is configured on the system by performing 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.

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.

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.

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*

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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.

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.

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.

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.

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

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

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

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.

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

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 [email protected],[email protected],aes256-ctr,aes128-ctr If any ciphers other than "Ciphers [email protected],[email protected],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.

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 [email protected],[email protected],aes256-ctr,aes128-ctr Restart the "sshd" service for changes to take effect: $ sudo systemctl restart sshd

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 [email protected],[email protected],hmac-sha2-512,hmac-sha2-256 If any algorithms other than "[email protected],[email protected],hmac-sha2-512,hmac-sha2-256" are listed, the returned line is commented out, or if conflicting results are returned, this is a finding.

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 [email protected],[email protected],hmac-sha2-512,hmac-sha2-256 Restart the "sshd" service for changes to take effect: $ sudo systemctl restart sshd

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

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

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 [email protected],[email protected],aes256-ctr,aes128-ctr If any ciphers other than "Ciphers [email protected],[email protected],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.

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 [email protected],[email protected],aes256-ctr,aes128-ctr Restart the "ssh" service for changes to take effect: $ sudo systemctl restart ssh

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

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 [email protected],[email protected],hmac-sha2-512,hmac-sha2-256 Restart the "ssh" service for changes to take effect: $ sudo systemctl restart ssh

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.

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

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.

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

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.

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

Verify Ubuntu 24.04 LTS system accounts do not have an interactive login shell with the following command: Run the following command to list any system account (UID 0 && $3 < 1000) && $1 !~ /^(halt|sync|shutdown)$/ && $7 !~ /(nologin|false)$/) {print $1 ":" $3 ":" $7}' /etc/passwd If the command returns any output, this is a finding.

Configure Ubuntu 24.04 LTS so that all noninteractive accounts on the system do not have an interactive shell assigned to them. If the system account needs a shell assigned for mission operations, document the need with the information system security officer (ISSO). Run the following command to disable the interactive shell for a specific noninteractive user account: $ sudo usermod -s /usr/sbin/nologin

Verify Ubuntu 24.04 LTS enables auditing at system startup in GRUB. Check the main GRUB defaults to ensure that auditing is enabled: $ sudo grep -ir GRUB_CMDLINE_LINUX /etc/default/grub /etc/default/grub:GRUB_CMDLINE_LINUX_DEFAULT="audit=1" /etc/default/grub:GRUB_CMDLINE_LINUX="audit=1" If any linux lines do not contain "audit=1", this is a finding. Check the generated GRUB configuration to ensure that the setting is propagated to the bootloader: $ 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. Note: Output details may vary by system.

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 and to the "GRUB_CMDLINE_LINUX_DEFAULT" option. GRUB_CMDLINE_LINUX_DEFAULT="audit=1" GRUB_CMDLINE_LINUX="audit=1" To update the grub config file, run: $ sudo update-grub

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.

Configure Ubuntu 24.04 LTS to lock the current graphical user interface session after 10 minutes of inactivity. Create or edit a file named /etc/dconf/db/local.d/00-screensaver with the following contents: [org/gnome/desktop/session] idle-delay=uint32 900 [org/gnome/desktop/screensaver] lock-enabled=true lock-delay=uint32 600 Update the dconf settings: $ sudo dconf update

Note: This requirement assumes the use of the Ubuntu 24.04 LTS default graphical user interface, the GNOME desktop environment. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Verify Ubuntu 24.04 LTS disables the ability of the user to override the graphical user interface automount setting. Determine which profile the system database is using with the following command: $ sudo grep system-db /etc/dconf/profile/user system-db:local Check that the automount setting is locked from nonprivileged user modification with the following command: Note: The example below is using the database "local" for the system, so the path is "/etc/dconf/db/local.d". This path must be modified if a database other than "local" is being used. $ grep 'automount-open' /etc/dconf/db/local.d/locks/* /org/gnome/desktop/media-handling/automount-open If the command does not return at least the example result, this is a finding.

Configure Ubuntu 24.04 LTS so the GNOME desktop does not allow a user to change the setting that disables automated mounting of removable media. Add the following line to "/etc/dconf/db/local.d/locks/00-security-settings-lock" to prevent user modification: /org/gnome/desktop/media-handling/automount-open Update the dconf system databases: $ sudo dconf update

Note: This requirement assumes the use of the Ubuntu 24.04 LTS default graphical user interface, the GNOME desktop environment. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Verify Ubuntu 24.04 LTS disables ability of the user to override the graphical user interface autorun setting. Determine which profile the system database is using with the following command: $ gsettings writable org.gnome.desktop.media-handling autorun-never false If "autorun-never" is writable, the result is "true". If this is not documented with the information system security officer (ISSO) as an operational requirement, this is a finding.

Configure the Ubuntu 24.04 LTS GNOME desktop to not allow a user to change the setting that disables autorun on removable media. Add the following line to "/etc/dconf/db/local.d/locks/00-security-settings-lock" to prevent user modification: /org/gnome/desktop/media-handling/autorun-never Update the dconf system databases: $ sudo dconf update

Note: This requirement assumes the use of the Ubuntu 24.04 LTS default graphical user interface, the GNOME desktop environment. If the system does not have any graphical user interface installed, this requirement is Not Applicable. Verify Ubuntu 24.04 LTS disables the ability of the user to override the smart card removal action setting. $ gsettings writable org.gnome.settings-daemon.peripherals.smartcard removal-action false If "removal-action" is writable and the result is "true", this is a finding.

Configure Ubuntu 24.04 LTS to prevent a user from overriding the disabling of the graphical user smart card removal action. Add the following line to "/etc/dconf/db/local.d/locks/00-security-settings-lock": /org/gnome/settings-daemon/peripherals/smartcard/removal-action Update the dconf system databases: $ sudo dconf update

Note: This requirement assumes the use of the Ubuntu 24.04 LTS default graphical user interface, the GNOME desktop environment. If the system does not have any graphical user interface installed, this requirement is Not Applicable. To verify the screensaver is configured to be blank, run the following command: $ gsettings writable org.gnome.desktop.screensaver picture-uri false If "picture-uri" is writable and the result is "true", this is a finding.

Configure Ubuntu 24.04 LTS to prevent a user from overriding the picture-uri setting for graphical user interfaces. In the file "/etc/dconf/db/local.d/00-security-settings", add or update the following lines: [org/gnome/desktop/screensaver] picture-uri='' Prevent user modification by adding the following line to "/etc/dconf/db/local.d/locks/00-security-settings-lock": /org/gnome/desktop/screensaver/picture-uri Update the dconf system databases: $ sudo dconf update

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.

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

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 If "auth.*", "authpriv.*", or "daemon.*" are not configured to be logged in at least one of the config files, this is a finding.

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

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

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)

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<[VALUE]<=35, is commented out, or is missing, this is a finding.

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: DoW recommendation is 35 days, but a lower value is acceptable. The value "0" will disable the account immediately after the password expires.

Verify Ubuntu 24.04 LTS is configured to audit the execution of any system call made by cron as root or as any privileged user. $ sudo auditctl -l | grep /etc/cron.d -w /etc/cron.d -p wa -k cronjobs $ sudo auditctl -l | grep /var/spool/cron -w /var/spool/cron -p wa -k cronjobs If either of these commands does not return the expected output, or the lines are commented out, this is a finding.

Configure Ubuntu 24.04 LTS to audit the execution of any system call made by cron as root or as any privileged user. Add or update the following file system rules to "/etc/audit/rules.d/stig.rules": -w /etc/cron.d/ -p wa -k cronjobs -w /var/spool/cron/ -p wa -k cronjobs To load the rules to the kernel immediately, use the following command: $ sudo augenrules --load

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

Verify Ubuntu 24.04 LTS displays the Standard Mandatory DoW 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 DoW 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 DoW Notice and Consent Banner exactly, this is a finding.

Configure Ubuntu 24.04 LTS to display the Standard Mandatory DoW 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 DoW Notice and Consent Banner. The DoW 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

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

Configure Ubuntu 24.04 LTS to display the Standard Mandatory DoW 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

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 DoW 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 DoW Notice and Consent Banner exactly, this is a finding.

Configure Ubuntu 24.04 LTS displays the Standard Mandatory DoW 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

Verify the systemwide shared library files contained in the directories "/lib", "/lib64", "/usr/lib", and "/usr/lib64" have mode 0755 or less permissive. Check that the systemwide shared library files have mode 0755 or less permissive with the following command: $ sudo find /lib /lib64 /usr/lib /usr/lib64 -type f -name '*.so*' -perm /022 -exec stat -c "%n %a" {} + If any output is returned, this is a finding.

Configure the systemwide shared library files contained in the directories "/lib", "/lib64", "/usr/lib", and "/usr/lib64" to have mode 0755 or less permissive with the following command: $ sudo find /lib /lib64 /usr/lib /usr/lib64 -type f -name '*.so*' -perm /022 -exec chmod go-w {} +

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

Configure the systemwide shared library files contained in the directories "/lib", "/lib64", "/usr/lib", and "/usr/lib64" to be owned by root with the following command: $ sudo find /lib /lib64 /usr/lib /usr/lib64 -type f -name '*.so*' ! -user root -exec chown root {} +

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

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

Verify the systemwide shared library files contained in the directories "/lib", "/lib64", "/usr/lib", and "/usr/lib64" are group owned by root with the following command: $ sudo find /lib /lib64 /usr/lib /usr/lib64 -type f -name '*.so*' ! -group root -exec stat -c "%n %G" {} + If any output is returned, this is a finding.

Configure the systemwide shared library files contained in the directories "/lib", "/lib64", "/usr/lib", and "/usr/lib64" to be group owned by root with the following command: $ sudo find /lib /lib64 /usr/lib /usr/lib64 -type f -name '*.so*' ! -group root -exec chown :root {} +

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.

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 '{}' \;

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.

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 '{}' \;

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.

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]

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" && $2 != "daemon" && $2 != "adm" && $2 != "shadow" && $2 != "mail" && $2 != "crontab" && $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.

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]

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.

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

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.

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

Verify the operating system restricts privilege elevation to authorized personnel with the following command: $ sudo grep -iwR 'ALL' /etc/sudoers /etc/sudoers.d/ | grep -v '#' If either of the following entries are returned, this is a finding: ALL ALL=(ALL) ALL ALL ALL=(ALL:ALL) ALL

Configure the operating system to restrict privilege elevation to authorized personnel. Remove the following entries from the /etc/sudoers file or any configuration file under /etc/sudoers.d/: ALL ALL=(ALL) ALL ALL ALL=(ALL:ALL) ALL

Verify that "/etc/sudoers" has no occurrences of "NOPASSWD" with the following command: $ sudo egrep -iR 'NOPASSWD' /etc/sudoers /etc/sudoers.d/ If any occurrences of "NOPASSWD" are returned from the command and have not been documented with the information system security officer (ISSO) as an organizationally defined administrative group using multifactor authentication (MFA), this is a finding.

Configure the operating system to not allow users to execute privileged actions without authenticating with a password. Remove any occurrence of "NOPASSWD" found in "/etc/sudoers" file or files in the "/etc/sudoers.d" directory. $ sudo find /etc/sudoers /etc/sudoers.d -type f -exec sed -i '/NOPASSWD/ s/^/# /g' {} \;

Verify the "/etc/sudoers" file has no occurrences of "!authenticate" with the following command: $ sudo egrep -iR '!authenticate' /etc/sudoers /etc/sudoers.d/ If any occurrences of "!authenticate" return from the command, this is a finding.

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

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.

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 SSH for the changes to take effect: $ sudo systemctl restart ssh

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.

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

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.

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

Verify that Ubuntu 24.04 LTS disables the ability to load the USB storage kernel module with the following command: $ sudo grep usb-storage /etc/modprobe.d/* | grep "/bin/false" /etc/modprobe.d/DISASTIG.conf:install usb-storage /bin/false 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 devices. $ 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.

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/false >> /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"

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.

Add all ports, protocols, or services allowed by the PPSM CLSA by using the following command: $ sudo ufw allow 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

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.

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

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.

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

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.

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

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.

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

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.

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

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 rounds=100000 If "sha512" is missing from the "pam_unix.so" line, or if the "rounds" is set to less than 100000, this is a finding.

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 rounds=100000

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.

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

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.

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

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.

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

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.

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

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.

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

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

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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 SSH for the changes to take effect: $ sudo systemctl restart ssh

Verify the directory containing the root certificates for Ubuntu 24.04 LTS contains certificate files for DoW 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 DoW /etc/ssl/certs DoW_PKE_CA_chain.pem If no root certificate is found, this is a finding.

Configure Ubuntu 24.04 LTS to use of DoW 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

Verify kernel core dumps are disabled unless needed with the following command: $ systemctl status kdump-tools.service o kdump-tools.service Loaded: masked (Reason: Unit kdump-tools.service is masked.) Active: inactive (dead) If kdump-tools is not installed the output will be: Unit kdump-tools.service could not be found. If "kdump-tools.service" is not masked and inactive, 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.

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

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.

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]

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

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

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.

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

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.

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 For each interface listed, find their respective module with the following command: $ basename $(readlink -f /sys/class/net//device/driver) where 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 /bin/true For each module from the system, execute the following command to remove it: $ sudo modprobe -r

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, lastlog, history, and eipp.log.xz files are excluded from this check. 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.

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, lastlog, history, and eipp.log.xz 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 '{}' \;

Verify the /run/log/journal and /var/log/journal directories have permissions set to default values with the following command: $ sudo find /run/log/journal /var/log/journal -type d -exec stat -c "%n %a" {} \; /run/log/journal 2755 /var/log/journal 2755 /var/log/journal/6a52424faa6e480ea5fc7346b9345792 2755 If any output returned has a permission set greater than 2755, 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/[email protected]~ 640 /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/[email protected]~ 640 /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/[email protected]~ 640 /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/user-1000.journal 640 If any output returned has a permission set greater than "640", this is a finding.

Configure the system to set the appropriate permissions to the files and directories used by the systemd journal. Create a drop-in file if it does not already exist with the following command: $ sudo vi /etc/tmpfiles.d/zzz-systemd-stig.conf Add or modify the following lines in the "/usr/lib/tmpfiles.d/zzz-systemd-stig.conf" file: z /run/log/journal 2755 root systemd-journal - - Z /run/log/journal/%m ~2750 root systemd-journal - - z /var/log/journal 2755 root systemd-journal - - z /var/log/journal/%m 2755 root systemd-journal - - z /var/log/journal/%m/system.journal 0640 root systemd-journal - - Note: Restart the system for these settings to take effect.

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

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

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.

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

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

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

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.

Configure the system to set the appropriate group-ownership to the directories used by the systemd journal. Create a drop-in file if it does not already exist with the following command: $ sudo vi /etc/tmpfiles.d/zzz-systemd-stig.conf Add or modify the following lines in the "/usr/lib/tmpfiles.d/zzz-systemd-stig.conf" file: z /run/log/journal 2755 root systemd-journal - - Z /run/log/journal/%m ~2750 root systemd-journal - - z /var/log/journal 2755 root systemd-journal - - z /var/log/journal/%m 2755 root systemd-journal - - z /var/log/journal/%m/system.journal 0640 root systemd-journal - - Note: Restart the system for these settings to take effect.

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/[email protected]~ systemd-journal /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/[email protected]~ systemd-journal /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/[email protected]~ 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.

Configure the system to set the appropriate group-ownership to the files used by the systemd journal. Create a drop-in file if it does not already exist with the following command: $ sudo vi /etc/tmpfiles.d/zzz-systemd-stig.conf Add or modify the following lines in the "/usr/lib/tmpfiles.d/zzz-systemd-stig.conf" file: Z /run/log/journal/%m ~0640 root systemd-journal - - z /var/log/journal/%m 0640 root systemd-journal - - z /var/log/journal/%m/system.journal 0640 root systemd-journal - - Note: Restart the system for these settings to take effect.

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.

Configure the system to set the appropriate ownership to the directories used by the systemd journal. Create a drop-in file if it does not already exist with the following command: $ sudo vi /etc/tmpfiles.d/zzz-systemd-stig.conf Add or modify the following lines in the "/usr/lib/tmpfiles.d/zzz-systemd-stig.conf" file: z /run/log/journal 2755 root systemd-journal - - Z /run/log/journal/%m ~2750 root systemd-journal - - z /var/log/journal 2755 root systemd-journal - - z /var/log/journal/%m 2755 root systemd-journal - - z /var/log/journal/%m/system.journal 0640 root systemd-journal - - Note: Restart the system for these settings to take effect.

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/[email protected]~ root /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/[email protected]~ root /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/[email protected]~ root /var/log/journal/d5745ad455d34fb8b6f78be37c1fcd3e/user-1000.journal root If any output returned is not owned by "root", this is a finding.

Configure the system to set the appropriate ownership to the files used by the systemd journal. Create a drop-in file if it does not already exist with the following command: $ sudo vi /etc/tmpfiles.d/zzz-systemd-stig.conf Add or modify the following lines in the "/usr/lib/tmpfiles.d/zzz-systemd-stig.conf" file: z /run/log/journal 2755 root systemd-journal - - Z /run/log/journal/%m ~2750 root systemd-journal - - z /var/log/journal 2755 root systemd-journal - - z /var/log/journal/%m 2755 root systemd-journal - - z /var/log/journal/%m/system.journal 0640 root systemd-journal - - Note: Restart the system for these settings to take effect.

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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";

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.

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/*

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.

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/*

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.

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/*

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

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

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

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

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

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

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

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

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

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

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

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

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>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b32 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b64 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid=0 -k perm_mod If the command does not return audit rules for the "setxattr", "fsetxattr", "lsetxattr", "removexattr", "fremovexattr" and "lremovexattr" syscalls or the lines are commented out, this is a finding. Notes: - For 32-bit architectures, only the 32-bit specific output lines from the commands are required. - The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

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

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>=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return audit rules for the "chown", "fchown", "fchownat", and "lchown" syscalls or the lines are commented out, this is a finding. Notes: - For 32-bit architectures, only the 32-bit specific output lines from the commands are required. - The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

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

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>=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return audit rules for the "chmod", "fchmod" and "fchmodat" syscalls or the lines are commented out, this is a finding. Notes: - For 32-bit architectures, only the 32-bit specific output lines from the commands are required. - The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

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

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>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access If the command does not return audit rules for the "creat", "open", "openat", "open_by_handle_at", "truncate", and "ftruncate" syscalls or the lines are commented out, this is a finding. Notes: - For 32-bit architectures, only the 32-bit specific output lines from the commands are required. - The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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.

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

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

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

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

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

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

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

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

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

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

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

Verify an audit event is generated for any successful/unsuccessful use of the "useradd" command with the following command: $ sudo auditctl -l | grep -w useradd -a always,exit -F path=/usr/sbin/useradd -F perm=x -F auid>=1000 -F auid!=-1 -k privileged-useradd 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.

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

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

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

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

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

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>=1000 -F auid!=-1 -k module_chng -a always,exit -F arch=b64 -S init_module,finit_module -F auid>=1000 -F auid!=-1 -k module_chng If the command does not return audit rules for the "init_module" and "finit_module" syscalls or the lines are commented out, this is a finding. Notes: - For 32-bit architectures, only the 32-bit specific output lines from the commands are required. - The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

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

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>=1000 -F auid!=-1 -k module_chng -a always,exit -F arch=b64 -S delete_module -F auid>=1000 -F auid!=-1 -k module_chng If the command does not return a line that matches the example or the line is commented out, this is a finding. Notes: - For 32-bit architectures, only the 32-bit specific output lines from the commands are required. - The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

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

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.

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

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.

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

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>=1000 -F auid!=-1 -F key=delete -a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat,rmdir -F auid>=1000 -F auid!=-1 -F key=delete If the command does not return audit rules for the "unlink", "unlinkat", "rename", "renameat", and "rmdir" syscalls or the lines are commented out, this is a finding. Notes: - For 32-bit architectures, only the 32-bit specific output lines from the commands are required. - The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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/augenrules 755 If any of the audit tools have a mode more permissive than "0755", this is a finding.

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.

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/augenrules root If any of the audit tools are not owned by root, this is a finding.

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.

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/augenrules root If any of the audit tools are not group owned by root, this is a finding.

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.

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.

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 '{}' \;

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.

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 '{}' \;

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.

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 '{}' \;

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.

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/*

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

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

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

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

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

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

Verify the running audit system prevents unauthorized changes (is immutable) with the following command: $ sudo auditctl -s | grep "enabled" enabled 2 If the "enabled" value returned is not "2", this is a finding. Verify that the audit system is configured to be immutable across reboots with the following command: $ grep -E '^-e 2' /etc/audit/rules.d/*.rules /etc/audit/rules.d/99-finalize.rules:-e 2 If the "-e 2" option is not configured in a rules file under "/etc/audit/rules.d/", this is a finding.

Configure the audit system to set the audit rules to be immutable by performing the following steps: Create or edit a finalized rules file (e.g., "/etc/audit/rules.d/99-finalize.rules") and append the following option as the absolute last line: -e 2 Compile and load the new rules into the active kernel: $ sudo augenrules --load Note: Once this rule is active, further changes to the audit configuration will be blocked. A system reboot will be required to apply any future audit rule modifications.

Verify that the Advanced Intrusion Detection Environment (AIDE) is configured to use cryptographic mechanisms to protect the integrity of the audit tools. First, verify that the audit tools are configured within AIDE's sub-configuration directory with the following command: $ find /etc/aide/aide.conf /etc/aide/aide.conf.d/ -type f -exec grep -H -E '^(|/usr)/sbin/au(dit(ctl|d)|search|report|rules|trace)[[:space:]]' {} + If any of the six core audit tools (for both /usr/sbin/ and /sbin/ paths) do not return from the command, or if they are not configured with the exact rule p+i+n+u+g+s+b+acl+xattrs+sha512, this is a finding. /etc/aide/aide.conf.d/90-stig_audit_tools:/usr/sbin/auditctl p+i+n+u+g+s+b+acl+xattrs+sha512 /etc/aide/aide.conf.d/90-stig_audit_tools:/usr/sbin/auditd p+i+n+u+g+s+b+acl+xattrs+sha512 /etc/aide/aide.conf.d/90-stig_audit_tools:/usr/sbin/ausearch p+i+n+u+g+s+b+acl+xattrs+sha512 /etc/aide/aide.conf.d/90-stig_audit_tools:/usr/sbin/aureport p+i+n+u+g+s+b+acl+xattrs+sha512 /etc/aide/aide.conf.d/90-stig_audit_tools:/usr/sbin/autrace p+i+n+u+g+s+b+acl+xattrs+sha512 /etc/aide/aide.conf.d/90-stig_audit_tools:/sbin/auditctl p+i+n+u+g+s+b+acl+xattrs+sha512 /etc/aide/aide.conf.d/90-stig_audit_tools:/sbin/auditd p+i+n+u+g+s+b+acl+xattrs+sha512 /etc/aide/aide.conf.d/90-stig_audit_tools:/sbin/ausearch p+i+n+u+g+s+b+acl+xattrs+sha512 /etc/aide/aide.conf.d/90-stig_audit_tools:/sbin/aureport p+i+n+u+g+s+b+acl+xattrs+sha512 /etc/aide/aide.conf.d/90-stig_audit_tools:/sbin/autrace p+i+n+u+g+s+b+acl+xattrs+sha512

Configure AIDE to protect the integrity of the audit tools by performing the following steps: Create a dedicated configuration file inside AIDE's sub-configuration directory: $ sudo nano /etc/aide/aide.conf.d/90-stig_audit_tools Add configuration rules: # Modern Canonical Paths /usr/sbin/auditctl p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/auditd p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/ausearch p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/aureport p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/autrace p+i+n+u+g+s+b+acl+xattrs+sha512 /usr/sbin/augenrules p+i+n+u+g+s+b+acl+xattrs+sha512 # Legacy Paths /sbin/auditctl p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/auditd p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/ausearch p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/aureport p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/autrace p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/augenrules p+i+n+u+g+s+b+acl+xattrs+sha512 If the legacy "/sbin/" paths are defined inside the main "/etc/aide/aide.conf" file, edit "/etc/aide/aide.conf" and comment those lines out using a "#" to prevent duplicate definition conflicts. Validate the modified AIDE configuration to ensure no syntax warnings or errors are present: $ sudo aide -c /etc/aide/aide.conf --config-check This command should return no output. Initialize the updated baseline database (this may take a few minutes): $ sudo aideinit Copy the newly generated database into the production directory: $ sudo cp -p /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Verify the "systemd-timesyncd" package is not installed with the following command: $ dpkg -l | grep systemd-timesyncd If the "systemd-timesyncd" package is installed, this is a finding.

The "systemd-timesyncd" package will be uninstalled as part of the "chrony" package install. Purge the remaining configuration files for "systemd-timesyncd" from Ubuntu 24.04 LTS: $ sudo apt-get purge systemd-timesyncd

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

Uninstall the "ntp" package using the following command: $ sudo apt remove ntp If there are additional configuration files on the system that must be removed, the following command can be used instead: $ sudo apt-get purge ntp

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

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

Verify the "chrony" package is installed using the following command: $ dpkg -l | grep chrony ii chrony 4.5-1ubuntu4.1 amd64 Versatile implementation of the Network Time Protocol If the "chrony" package is not installed, this is a finding.

Install the "chrony" network time protocol package using the following command: $ sudo apt install -y chrony

Verify Ubuntu 24.04 LTS limits the number of concurrent sessions to 10 for all accounts and/or account types with the following command: $ grep -r maxlogins /etc/security/limits.conf /etc/security/limits.d/*.conf /etc/security/limits.d/maxlogins.conf:* hard maxlogins 10 If the "maxlogins" item does not have a value of "10" or less, is commented out, or is missing, this is a finding.

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

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

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

Verify that APT is configured to prevent the installation of patches, service packs, device drivers, or Ubuntu 24.04 LTS components without verification they have been digitally signed using a certificate recognized and approved by the organization with the following command: $ grep AllowUnauthenticated /etc/apt/apt.conf.d/* If any files are returned from the command with "AllowUnauthenticated" are set to "true", this is a finding.

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

Verify Ubuntu 24.04 LTS enforces a delay of at least four seconds between logon prompts following a failed logon attempt with the following command: $ grep pam_faildelay /etc/pam.d/common-auth auth required pam_faildelay.so delay=4000000 If the value for "delay" is not set to "4000000" or greater, the line is commented out, or is missing, this is a finding.

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

Note: If smart card authentication is not being used on the system, this requirement is not applicable. Verify PAM prohibits the use of cached authentications after one day with the following command: $ sudo grep offline_credentials_expiration /etc/sssd/sssd.conf /etc/sssd/conf.d/*.conf offline_credentials_expiration = 1 If "offline_credentials_expiration" in "/etc/sssd/sssd.conf" or in a file with a name ending in .conf in the "/etc/sssd/conf.d/" directory, is not set to "1", is commented out, is missing, or conflicting results are returned, this is a finding.

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

Verify Ubuntu 24.04 LTS is configured to restrict access to the kernel message buffer with the following command: $ sysctl kernel.dmesg_restrict kernel.dmesg_restrict = 1 If "kernel.dmesg_restrict" is not set to "1" or is missing, this is a finding. Verify there are no configurations that enable the kernel dmesg function: $ sudo grep -r kernel.dmesg_restrict /run/sysctl.d/* /etc/sysctl.d/* /usr/local/lib/sysctl.d/* /usr/lib/sysctl.d/* /lib/sysctl.d/* /etc/sysctl.conf 2> /dev/null /etc/sysctl.d/10-kernel-hardening.conf:kernel.dmesg_restrict = 1 If any instance of "kernel.dmesg_restrict" is uncommented and set to "0", or if conflicting results are returned, this is a finding.

Configure Ubuntu 24.04 LTS to restrict access to the kernel message buffer. Set the system to the required kernel parameter by adding or modifying the following line in /etc/sysctl.conf or a config file in the /etc/sysctl.d/ directory: kernel.dmesg_restrict = 1 Remove any configurations that conflict with the above from the following locations: /run/sysctl.d/ /etc/sysctl.d/ /usr/local/lib/sysctl.d/ /usr/lib/sysctl.d/ /lib/sysctl.d/ /etc/sysctl.conf Reload settings from all system configuration files with the following command: $ sudo sysctl --system

Note: If the system is not networked, this requirement is not applicable. Verify Ubuntu 24.04 LTS is configured to compare the system clock at least every 24 hours to an authoritative time source with the following command: $ sudo grep -ir maxpoll /etc/chrony* server [source] iburst maxpoll 16 If the parameter "server" is not set, is not set to an authoritative DoW time source, or is commented out, this is a finding. If the "maxpoll" option is set to a number greater than 16, the line is commented out, or is missing, this is a finding.

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

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

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

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

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

Note: If this is an interconnected system, this is not applicable. Verify there is a script that offloads audit data and that script runs weekly with the following command: $ ls /etc/cron.weekly audit-offload Check if the script inside the file offloads audit logs to external media. If the script file does not exist or does not offload audit logs, this is a finding.

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

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

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

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

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

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

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