Select any two versions of this STIG to compare the individual requirements
Select any old version/release of this STIG to view the previous requirements
Verify that the Ubuntu operating system expires temporary user accounts within 72 hours or less. For every existing temporary account, run the following command to obtain its account expiration information: $ sudo chage -l system_account_name | grep expires Password expires : Aug 07, 2019 Account expires : Aug 07, 2019 Verify that each of these accounts has an expiration date set within 72 hours of account creation. If any temporary account does not expire within 72 hours of that account's creation, this is a finding.
If a temporary account must be created, configure the system to terminate the account after a 72-hour time period with the following command to set an expiration date on it. Substitute "system_account_name" with the account to be created. $ sudo chage -E $(date -d "+3 days" +%F) system_account_name
Verify the Ubuntu operating system is configured to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the operating system via a graphical user logon. Note: If the system does not have a graphical user interface installed, this requirement is Not Applicable. Check that the operating banner message for the graphical user logon is enabled with the following command: $ grep ^banner-message-enable /etc/gdm3/greeter.dconf-defaults banner-message-enable=true If the line is commented out or set to "false", this is a finding.
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): Note: The lines are all near the bottom of the file but not adjacent to each other. [org/gnome/login-screen] banner-message-enable=true Update the GDM with the new configuration: $ sudo dconf update $ sudo systemctl restart gdm3
Verify the Ubuntu operating system displays the Standard Mandatory DOD Notice and Consent Banner before granting access to the operating system via a graphical user logon. Note: If the system does not have a graphical user interface installed, this requirement is Not Applicable. Verify the operating system displays the exact approved Standard Mandatory DOD Notice and Consent Banner text 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.\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.' If the banner-message-text is missing, commented out, or does not match the Standard Mandatory DOD Notice and Consent Banner exactly, this is a finding.
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 Ubuntu operation system has a graphical user interface session lock enabled. Note: If the Ubuntu operating system does not have a graphical user interface installed, this requirement is Not Applicable. Get the "lock-enabled" setting to verify the graphical user interface session has the lock enabled with the following command: $ sudo gsettings get org.gnome.desktop.screensaver lock-enabled true If "lock-enabled" is not set to "true", this is a finding.
Configure the Ubuntu operating system to allow a user to lock the current graphical user interface session. Note: If the Ubuntu operating system does not have a graphical user interface installed, this requirement is Not Applicable. Set the "lock-enabled" setting to allow graphical user interface session locks with the following command: $ sudo gsettings set org.gnome.desktop.screensaver lock-enabled true
Verify the Ubuntu operating system has the "vlock" package installed by running the following command: $ dpkg -l | grep vlock 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-get install vlock
Verify that "use_mappers" is set to "pwent" in "/etc/pam_pkcs11/pam_pkcs11.conf" file: $ grep use_mappers /etc/pam_pkcs11/pam_pkcs11.conf use_mappers = pwent If "use_mappers" is not found or the list does not contain "pwent" this is a finding.
Set "use_mappers=pwent" in "/etc/pam_pkcs11/pam_pkcs11.conf" or, if there is already a comma-separated list of mappers, add it to the list, separated by comma, and before the null mapper. 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 Ubuntu operating system enforces a 24 hours/1 day minimum password lifetime for new user accounts by running 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 the Ubuntu operating system 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 the Ubuntu operating system enforces a 60-day maximum password lifetime for new user accounts by running the following command: $ grep -i ^pass_max_days /etc/login.defs PASS_MAX_DAYS 60 If the "PASS_MAX_DAYS" parameter value is greater than 60, or commented out, this is a finding.
Configure the Ubuntu operating system to enforce a 60-day maximum password lifetime. Add or modify the following line in the "/etc/login.defs" file: PASS_MAX_DAYS 60
Run the following command to verify the encrypted password is set: $ 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 <hash>' /etc/grub.d/40_custom where <hash> 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 the Ubuntu operating system 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 the sudo group has only members who should have access to security functions. $ 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 <username> sudo
Verify the operating system automatically terminates a user session after inactivity timeouts have expired. Check that the "TMOUT" environment variable is set in the "/etc/bash.bashrc" file or in any file inside the "/etc/profile.d/" directory by performing the following command: $ grep -E "\bTMOUT=[0-9]+" /etc/bash.bashrc /etc/profile.d/* TMOUT=600 If "TMOUT" is not set, or if the value is "0" or is commented out, this is a finding.
Configure the operating system 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 the "/etc/sudoers" file has no occurrences of "NOPASSWD" or "!authenticate" by running the following command: $ sudo egrep -i '(nopasswd|!authenticate)' /etc/sudoers /etc/sudoers.d/* If any occurrences of "NOPASSWD" or "!authenticate" return from the command, this is a finding.
Remove any occurrence of "NOPASSWD" or "!authenticate" found in "/etc/sudoers" file or files in the "/etc/sudoers.d" directory.
Verify the Ubuntu operating system defines default permissions for all authenticated users in such a way that the user can read and modify only their own files. Verify the Ubuntu operating system defines default permissions for all authenticated users with the following command: $ grep -i "umask" /etc/login.defs UMASK 077 If the "UMASK" variable is set to "000", this is a finding with the severity raised to a CAT I. If the value of "UMASK" is not set to "077", is commented out, or is missing completely, this is a finding.
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 the Ubuntu operating system has the packages required for multifactor authentication installed with the following commands: $ dpkg -l | grep libpam-pkcs11 ii libpam-pkcs11 0.6.8-4 amd64 Fully featured PAM module for using PKCS#11 smart cards If the "libpam-pkcs11" package is not installed, this is a finding. Verify the sshd daemon allows public key authentication with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*pubkeyauthentication' PubkeyAuthentication yes If this option is set to "no" or is missing, this is a finding. If conflicting results are returned, this is a finding.
Configure the Ubuntu operating system to use multifactor authentication for network access to accounts. Add or update the following line in "/etc/pam.d/common-auth", placing it above any lines containing "pam_unix.so": auth [success=2 default=ignore] pam_pkcs11.so Set the sshd option "PubkeyAuthentication yes" in the "/etc/ssh/sshd_config" file.
Verify the Ubuntu operating system is configured to use strong authenticators in the establishment of nonlocal maintenance and diagnostic maintenance. Verify that "UsePAM" is set to "yes" in "/etc/ssh/sshd_config: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*usepam' UsePAM yes If "UsePAM" is not set to "yes", this is a finding. If conflicting results are returned, this is a finding.
Configure the Ubuntu operating system to use strong authentication when establishing nonlocal maintenance and diagnostic sessions. Add or modify the following line to /etc/ssh/sshd_config: UsePAM yes
Verify all network connections associated with SSH traffic automatically terminate after a period of inactivity. Verify the "ClientAliveCountMax" variable is set in the "/etc/ssh/sshd_config" file by performing the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*clientalivecountmax' ClientAliveCountMax 1 If "ClientAliveCountMax" is not set, is not set to "1", or is commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure the Ubuntu operating system to automatically terminate inactive SSH sessions after a period of inactivity. Modify or append the following line in the "/etc/ssh/sshd_config" file, replacing "[Count]" with a value of 1: ClientAliveCountMax 1 Restart the SSH daemon for the changes to take effect: $ sudo systemctl restart sshd.service
Verify all network connections associated with SSH traffic are automatically terminated at the end of the session or after 10 minutes of inactivity. Verify the "ClientAliveInterval" variable is set to a value of "600" or less by performing the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*clientaliveinterval' ClientAliveInterval 600 If "ClientAliveInterval" does not exist, is not set to a value of "600" or less in "/etc/ssh/sshd_config", or is commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure the Ubuntu operating system to automatically terminate all network connections associated with SSH traffic at the end of a session or after a 10-minute period of inactivity. Modify or append the following line in the "/etc/ssh/sshd_config" file replacing "[Interval]" with a value of "600" or less: ClientAliveInterval 600 Restart the SSH daemon for the changes to take effect: $ sudo systemctl restart sshd.service
Verify the Ubuntu operating system displays the Standard Mandatory DOD Notice and Consent Banner before granting access to the Ubuntu operating system via an SSH logon with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*banner' /etc/ssh/sshd_config:Banner /etc/issue.net The command will return the banner option along with the name of the file that contains the SSH banner. If the line is commented out, this is a finding. If conflicting results are returned, this is a finding. Verify the specified banner file matches the Standard Mandatory DOD Notice and Consent Banner exactly: $ cat /etc/issue.net "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." If the banner text does not match the Standard Mandatory DOD Notice and Consent Banner exactly, this is a finding.
Set the parameter Banner in "/etc/ssh/sshd_config" to point to the "/etc/issue.net" file: $ sudo sed -i '/^Banner/d' /etc/ssh/sshd_config $ sudo sed -i '$aBanner /etc/issue.net' /etc/ssh/sshd_config Either create the file containing the banner or replace the text in the file with the Standard Mandatory DOD Notice and Consent Banner. The DOD required text is: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Restart the SSH daemon for the changes to take effect and then signal the SSH server to reload the configuration file: $ sudo systemctl -s SIGHUP kill sshd
Verify the SSH package is installed with the following command: $ sudo dpkg -l | grep openssh ii openssh-client 1:7.6p1-4ubuntu0.1 amd64 secure shell (SSH) client, for secure access to remote machines ii openssh-server 1:7.6p1-4ubuntu0.1 amd64 secure shell (SSH) server, for secure access from remote machines ii openssh-sftp-server 1:7.6p1-4ubuntu0.1 amd64 secure shell (SSH) sftp server module, for SFTP access from remote machines If the "openssh" server package is not installed, this is a finding. Verify the "sshd.service" is loaded and active with the following command: $ sudo systemctl status sshd.service | egrep -i "(active|loaded)" Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2019-01-24 22:52:58 UTC; 1 weeks 3 days ago If "sshd.service" is not active or loaded, this is a finding.
Install the "ssh" meta-package on the system with the following command: $ sudo apt install ssh Enable the "ssh" service to start automatically on reboot with the following command: $ sudo systemctl enable sshd.service ensure the "ssh" service is running $ sudo systemctl start sshd.service
Verify the SSH daemon is configured to only use MACs that employ FIPS 140-2 approved ciphers with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*macs' MACs hmac-sha2-512,hmac-sha2-256 If any ciphers other than "hmac-sha2-512" or "hmac-sha2-256" are listed, the order differs from the example above, or the returned line is commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure the Ubuntu operating system to allow the SSH daemon to only use MACs that employ FIPS 140-2 approved ciphers. Add the following line (or modify the line to have the required value) to the "/etc/ssh/sshd_config" file (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor): MACs hmac-sha2-512,hmac-sha2-256 Restart the SSH daemon for the changes to take effect: $ sudo systemctl reload sshd.service
Verify the SSH daemon is configured to only implement FIPS-approved algorithms by running the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*ciphers' Ciphers aes256-ctr,aes192-ctr,aes128-ctr If any ciphers other than "aes256-ctr", "aes192-ctr", or "aes128-ctr" are listed, the order differs from the example above, the "Ciphers" keyword is missing, or the returned line is commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure the Ubuntu operating system to allow the SSH daemon to only implement FIPS-approved algorithms. Add the following line (or modify the line to have the required value) to the "/etc/ssh/sshd_config" file (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor): Ciphers aes256-ctr,aes192-ctr,aes128-ctr Restart the SSH daemon for the changes to take effect: $ sudo systemctl restart sshd.service
Verify that unattended or automatic login via SSH is disabled with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iEH '^\s*(permit(.*?)(passwords|environment))' PermitEmptyPasswords no PermitUserEnvironment no If "PermitEmptyPasswords" or "PermitUserEnvironment" keywords are not set to "no", are missing completely, or are commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure the Ubuntu operating system to allow the SSH daemon to not allow unattended or automatic login to the system. Add or edit the following lines in the "/etc/ssh/sshd_config" file: PermitEmptyPasswords no PermitUserEnvironment no Restart the SSH daemon for the changes to take effect: $ sudo systemctl restart sshd.service
Verify that X11Forwarding is disabled with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*x11forwarding' X11Forwarding no If the "X11Forwarding" keyword is set to "yes" and is not documented with the information system security officer (ISSO) as an operational requirement or is missing, this is a finding. If conflicting results are returned, this is a finding.
Edit the "/etc/ssh/sshd_config" file to uncomment or add the line for the "X11Forwarding" keyword and set its value to "no" (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor): X11Forwarding no Restart the SSH daemon for the changes to take effect: $ sudo systemctl restart sshd.service
Verify the SSH daemon prevents remote hosts from connecting to the proxy display. Check the SSH X11UseLocalhost setting with the following command: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*x11uselocalhost' X11UseLocalhost yes If the "X11UseLocalhost" keyword is set to "no", is missing, or is commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure the SSH daemon to prevent remote hosts from connecting to the proxy display. Edit the "/etc/ssh/sshd_config" file to uncomment or add the line for the "X11UseLocalhost" keyword and set its value to "yes" (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor): X11UseLocalhost yes Restart the SSH daemon for the changes to take effect: $ sudo systemctl restart sshd.service
Verify the Ubuntu operating system enforces password complexity by requiring that at least one upper-case character be used. Determine if the field "ucredit" is set in the "/etc/security/pwquality.conf" file with the following command: $ grep -i "ucredit" /etc/security/pwquality.conf ucredit=-1 If the "ucredit" parameter is greater than "-1" or is commented out, this is a finding.
Add or update the "/etc/security/pwquality.conf" file to contain the "ucredit" parameter: ucredit=-1
Verify the Ubuntu operating system enforces password complexity by requiring that at least one lower-case character be used. Determine if the field "lcredit" is set in the "/etc/security/pwquality.conf" file with the following command: $ grep -i "lcredit" /etc/security/pwquality.conf lcredit=-1 If the "lcredit" parameter is greater than "-1" or is commented out, this is a finding.
Add or update the "/etc/security/pwquality.conf" file to contain the "lcredit" parameter: lcredit=-1
Verify the Ubuntu operating system enforces password complexity by requiring that at least one numeric character be used. Determine if the field "dcredit" is set in the "/etc/security/pwquality.conf" file with the following command: $ grep -i "dcredit" /etc/security/pwquality.conf dcredit=-1 If the "dcredit" parameter is greater than "-1" or is commented out, this is a finding.
Configure the Ubuntu operating system to enforce password complexity by requiring that at least one numeric character be used. Add or update the "/etc/security/pwquality.conf" file to contain the "dcredit" parameter: dcredit=-1
Verify the Ubuntu operating system requires the change of at least eight characters when passwords are changed. Determine if the field "difok" is set in the "/etc/security/pwquality.conf" file with the following command: $ grep -i "difok" /etc/security/pwquality.conf difok=8 If the "difok" parameter is less than "8" or is commented out, this is a finding.
Configure the Ubuntu operating system to require the change of at least eight characters when passwords are changed. Add or update the "/etc/security/pwquality.conf" file to include the "difok=8" parameter: difok=8
Verify the pwquality configuration file enforces a minimum 15-character password length by running the following command: $ grep -i minlen /etc/security/pwquality.conf minlen=15 If "minlen" parameter value is not "15" or higher or is commented out, this is a finding.
Configure the Ubuntu operating system to enforce a minimum 15-character password length. Add or modify the "minlen" parameter value to the "/etc/security/pwquality.conf" file: minlen=15
Determine if the field "ocredit" is set in the "/etc/security/pwquality.conf" file with the following command: $ grep -i "ocredit" /etc/security/pwquality.conf ocredit=-1 If the "ocredit" parameter is greater than "-1" or is commented out, this is a finding.
Configure the Ubuntu operating system to enforce password complexity by requiring that at least one special character be used. Add or update the following line in the "/etc/security/pwquality.conf" file to include the "ocredit=-1" parameter: ocredit=-1
Verify the Ubuntu operating system uses the "cracklib" library to prevent the use of dictionary words with the following command: $ grep dictcheck /etc/security/pwquality.conf dictcheck=1 If the "dictcheck" parameter is not set to "1" or is commented out, this is a finding.
Configure the Ubuntu operating system to prevent the use of dictionary words for passwords. Add or update the following line in the "/etc/security/pwquality.conf" file to include the "dictcheck=1" parameter: dictcheck=1
Verify the Ubuntu operating system has the "libpam-pwquality" package installed by running the following command: $ dpkg -l libpam-pwquality ii libpam-pwquality:amd64 1.4.0-2 amd64 PAM module to check password strength If "libpam-pwquality" is not installed, this is a finding. Verify that the operating system uses "pwquality" to enforce the password complexity rules. Verify the pwquality module is being enforced by the Ubuntu operating system by running the following command: $ grep -i enforcing /etc/security/pwquality.conf enforcing = 1 If the value of "enforcing" is not "1" or the line is commented out, this is a finding. Check for the use of "pwquality" with the following command: $ cat /etc/pam.d/common-password | grep requisite | grep pam_pwquality password requisite pam_pwquality.so retry=3 If no output is returned or the line is commented out, this is a finding. If the value of "retry" is set to "0" or greater than "3", this is a finding.
Configure the operating system to use "pwquality" to enforce password complexity rules. Install the "pam_pwquality" package by using the following command: $ sudo apt-get install libpam-pwquality -y Add the following line to "/etc/security/pwquality.conf" (or modify the line to have the required value): enforcing = 1 Add the following line to "/etc/pam.d/common-password" (or modify the line to have the required value): password requisite pam_pwquality.so retry=3 Note: The value of "retry" should be between "1" and "3".
Verify the Ubuntu operating system, for PKI-based authentication, has valid certificates by constructing a certification path to an accepted trust anchor. Determine which pkcs11 module is being used via the "use_pkcs11_module" in "/etc/pam_pkcs11/pam_pkcs11.conf" and then ensure "ca" is enabled in "cert_policy" with the following command: $ sudo grep use_pkcs11_module /etc/pam_pkcs11/pam_pkcs11.conf | awk '/pkcs11_module opensc {/,/}/' /etc/pam_pkcs11/pam_pkcs11.conf | grep cert_policy | grep ca cert_policy = ca,signature,ocsp_on; If "cert_policy" is not set to "ca" or the line is commented out, this is a finding.
Configure the Ubuntu operating system, for PKI-based authentication, to validate certificates by constructing a certification path to an accepted trust anchor. Determine which pkcs11 module is being used via the "use_pkcs11_module" in "/etc/pam_pkcs11/pam_pkcs11.conf" and ensure "ca" is enabled in "cert_policy". Add or update the "cert_policy" to ensure "ca" is enabled: cert_policy = ca,signature,ocsp_on; If the system is missing an "/etc/pam_pkcs11/" directory and an "/etc/pam_pkcs11/pam_pkcs11.conf", find an example to copy into place and modify accordingly at "/usr/share/doc/libpam-pkcs11/examples/pam_pkcs11.conf.example.gz".
Verify the Ubuntu operating system has the packages required for multifactor authentication installed with the following commands: $ dpkg -l | grep libpam-pkcs11 ii libpam-pkcs11 0.6.8-4 amd64 Fully featured PAM module for using PKCS#11 smart cards If the "libpam-pkcs11" package is not installed, this is a finding.
Configure the Ubuntu operating system to implement multifactor authentication by installing the required packages. Install the "libpam-pkcs11" package on the system with the following command: $ sudo apt install libpam-pkcs11
Verify the Ubuntu operating system accepts PIV credentials. Verify the "opensc-pcks11" package is installed on the system with the following command: $ dpkg -l | grep opensc-pkcs11 ii opensc-pkcs11:amd64 0.15.0-1Ubuntu1 amd64 Smart card utilities with support for PKCS#15 compatible cards If the "opensc-pcks11" package is not installed, this is a finding.
Configure the Ubuntu operating system to accept PIV credentials. Install the "opensc-pkcs11" package using the following command: $ sudo apt-get install opensc-pkcs11
Verify the Ubuntu operating system electronically verifies PIV credentials. Verify that certificate status checking for multifactor authentication is implemented with the following command: $ sudo grep use_pkcs11_module /etc/pam_pkcs11/pam_pkcs11.conf | awk '/pkcs11_module opensc {/,/}/' /etc/pam_pkcs11/pam_pkcs11.conf | grep cert_policy | grep ocsp_on cert_policy = ca,signature,ocsp_on; If "cert_policy" is not set to "ocsp_on", or the line is commented out, this is a finding.
Configure the Ubuntu operating system to do certificate status checking for multifactor authentication. Modify all of the "cert_policy" lines in "/etc/pam_pkcs11/pam_pkcs11.conf" to include "ocsp_on".
Verify the Ubuntu operating system, for PKI-based authentication, uses local revocation data when unable to access it from the network. Verify that "crl_offline" or "crl_auto" is part of the "cert_policy" definition in "/etc/pam_pkcs11/pam_pkcs11.conf" using the following command: # sudo grep cert_policy /etc/pam_pkcs11/pam_pkcs11.conf | grep -E -- 'crl_auto|crl_offline' cert_policy = ca,signature,ocsp_on,crl_auto; If "cert_policy" is not set to include "crl_auto" or "crl_offline", this is a finding.
Configure the Ubuntu operating system, for PKI-based authentication, to use local revocation data when unable to access the network to obtain it remotely. Add or update the "cert_policy" option in "/etc/pam_pkcs11/pam_pkcs11.conf" to include "crl_auto" or "crl_offline". cert_policy = ca,signature,ocsp_on, crl_auto; If the system is missing an "/etc/pam_pkcs11/" directory and an "/etc/pam_pkcs11/pam_pkcs11.conf", find an example to copy into place and modify accordingly at "/usr/share/doc/libpam-pkcs11/examples/pam_pkcs11.conf.example.gz".
Verify the Ubuntu operating system prevents passwords from being reused for a minimum of five generations by running the following command: $ grep -i remember /etc/pam.d/common-password password [success=1 default=ignore] pam_unix.so obscure sha512 shadow remember=5 rounds=5000 If the "remember" parameter value is not greater than or equal to "5", is commented out, or is not set at all, this is a finding.
Configure the Ubuntu operating system to prevent passwords from being reused for a minimum of five generations. Add or modify the "remember" parameter value to the following line in "/etc/pam.d/common-password" file: password [success=1 default=ignore] pam_unix.so obscure sha512 shadow remember=5 rounds=5000
Verify that the Ubuntu operating system utilizes the "pam_faillock" module with the following command: $ grep faillock /etc/pam.d/common-auth auth [default=die] pam_faillock.so authfail auth sufficient pam_faillock.so authsucc If the pam_faillock.so module is not present in the "/etc/pam.d/common-auth" file, this is a finding. Verify the pam_faillock module is configured to use the following options: $ sudo egrep 'silent|audit|deny|fail_interval| unlock_time' /etc/security/faillock.conf audit silent deny = 3 fail_interval = 900 unlock_time = 0 If the "silent" keyword is missing or commented out, this is a finding. If the "audit" keyword is missing or commented out, this is a finding. If the "deny" keyword is missing, commented out, or set to a value greater than 3, this is a finding. If the "fail_interval" keyword is missing, commented out, or set to a value greater than 900, this is a finding. If the "unlock_time" keyword is missing, commented out, or not set to 0, this is a finding.
Configure the Ubuntu operating system to utilize the "pam_faillock" module. Edit the /etc/pam.d/common-auth file. Add the following lines below the "auth" definition for pam_unix.so: auth [default=die] pam_faillock.so authfail auth sufficient pam_faillock.so authsucc Configure the "pam_faillock" module to use the following options: Edit the /etc/security/faillock.conf file and add/update the following keywords and values: audit silent deny = 3 fail_interval = 900 unlock_time = 0
Verify that the Advanced Intrusion Detection Environment (AIDE) default script used to check file integrity each 30 days or less is unchanged. Download the original aide-common package in the /tmp directory: $ cd /tmp; apt download aide-common Fetch the SHA1 of the original script file: $ dpkg-deb --fsys-tarfile /tmp/aide-common_*.deb | tar -xO ./usr/share/aide/config/cron.daily/aide | sha1sum 32958374f18871e3f7dda27a58d721f471843e26 - Compare with the SHA1 of the file in the daily or monthly cron directory: $ sha1sum /etc/cron.{daily,monthly}/aide 2>/dev/null 32958374f18871e3f7dda27a58d721f471843e26 /etc/cron.daily/aide If there is no AIDE script file in the cron directories, or the SHA1 value of at least one file in the daily or monthly cron directory does not match the SHA1 of the original, this is a finding.
The cron file for AIDE is fairly complex as it creates the report. This file is installed with the "aide-common" package, and the default can be restored by copying it from the package: Download the original package to the /tmp dir: $ cd /tmp; apt download aide-common Extract the aide script to its original place: $ dpkg-deb --fsys-tarfile /tmp/aide-common_*.deb | sudo tar -x ./usr/share/aide/config/cron.daily/aide -C / Copy it to the cron.daily directory: $ sudo cp -f /usr/share/aide/config/cron.daily/aide /etc/cron.daily/aide
Verify the Ubuntu operating system enforces a delay of at least 4 seconds between logon prompts following a failed logon attempt with the following command: $ grep pam_faildelay /etc/pam.d/common-auth auth required pam_faildelay.so delay=4000000 If the line is not present or is commented out, this is a finding.
Configure the Ubuntu operating system to enforce a delay of at least 4 seconds between logon prompts following a failed logon attempt. Edit the file "/etc/pam.d/common-auth" and set the parameter "pam_faildelay" to a value of 4000000 or greater: auth required pam_faildelay.so delay=4000000
Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd". Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep passwd -w /etc/passwd -p wa -k usergroup_modification If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd". Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/passwd -p wa -k usergroup_modification To reload the rules file, issue the following command: $ sudo augenrules --load
Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group". Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep group -w /etc/group -p wa -k usergroup_modification If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group". Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/group -p wa -k usergroup_modification To reload the rules file, issue the following command: $ sudo augenrules --load
Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/shadow". Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep shadow -w /etc/shadow -p wa -k usergroup_modification If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/shadow". Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/shadow -p wa -k usergroup_modification To reload the rules file, issue the following command: $ sudo augenrules --load
Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow". Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep gshadow -w /etc/gshadow -p wa -k usergroup_modification If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow". Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/gshadow -p wa -k usergroup_modification To reload the rules file, issue the following command: $ sudo augenrules --load
Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd". Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep opasswd -w /etc/security/opasswd -p wa -k usergroup_modification If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd". Add or update the following rule to "/etc/audit/rules.d/stig.rules": -w /etc/security/opasswd -p wa -k usergroup_modification To reload the rules file, issue the following command: $ sudo augenrules --load
Verify that the SA and ISSO (at a minimum) are notified in the event of an audit processing failure with the following command: $ sudo grep '^action_mail_acct = root' /etc/audit/auditd.conf action_mail_acct = <administrator_account> If the value of the "action_mail_acct" keyword is not set to an accounts for security personnel, the "action_mail_acct" keyword is missing, or the returned line is commented out, this is a finding.
Configure "auditd" service to notify the SA and ISSO in the event of an audit processing failure. Edit the following line in "/etc/audit/auditd.conf" to ensure administrators are notified via email for those situations: action_mail_acct = <administrator_account> Note: Change "administrator_account" to an account for security personnel. Restart the "auditd" service so the changes take effect: $ sudo systemctl restart auditd.service
Verify the Ubuntu operating system takes the appropriate action when the audit storage volume is full with the following command: $ sudo grep '^disk_full_action' /etc/audit/auditd.conf disk_full_action = HALT If the value of the "disk_full_action" option is not "SYSLOG", "SINGLE", or "HALT", or the line is commented out, this is a finding.
Configure the Ubuntu operating system to shut down by default upon audit failure (unless availability is an overriding concern). Add or update the following line (depending on configuration, "disk_full_action" can be set to "SYSLOG", "HALT" or "SINGLE") in "/etc/audit/auditd.conf" file: disk_full_action = HALT Restart the "auditd" service so the changes take effect: $ sudo systemctl restart auditd.service
Verify that the audit log files have a mode of "0600" or less permissive. Determine where the audit logs are stored with the following command: $ sudo grep -iw log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, determine if the audit log files have a mode of "0600" or less by using the following command: $ sudo stat -c "%n %a" /var/log/audit/* /var/log/audit/audit.log 600 If the audit log files have a mode more permissive than "0600", this is a finding.
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 by using the following command: $ sudo stat -c "%n %U" /var/log/audit/* /var/log/audit/audit.log root If the audit log files are owned by an user other than "root", this is a finding.
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 by using the following command: $ sudo stat -c "%n %G" /var/log/audit/* /var/log/audit/audit.log root If the audit log files are owned by a group other than "root", this is a finding.
Configure the audit log directory and its underlying files to be owned by "root" group. Set the "log_group" parameter of the audit configuration file to the "root" value so when a new log file is created, its group owner is properly set: $ sudo sed -i '/^log_group/D' /etc/audit/auditd.conf $ sudo sed -i /^log_file/a'log_group = root' /etc/audit/auditd.conf Last, signal the audit daemon to reload the configuration file to update the group owners of existing files: $ sudo systemctl kill auditd -s SIGHUP
Verify that the audit log directory has a mode of "0750" or less permissive. Determine where the audit logs are stored with the following command: $ sudo grep -iw ^log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, determine if the directory has a mode of "0750" or less by using the following command: $ sudo stat -c "%n %a" /var/log/audit /var/log/audit/* /var/log/audit 750 /var/log/audit/audit.log 600 If the audit log directory has a mode more permissive than "0750", this is a finding.
Configure the audit log directory to have a mode of "0750" or less permissive. Determine where the audit logs are stored with the following command: $ sudo grep -iw ^log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Using the path of the directory containing the audit logs, configure the audit log directory to have a mode of "0750" or less permissive by using the following command: $ sudo chmod -R g-w,o-rwx /var/log/audit
Verify that "/etc/audit/audit.rules", "/etc/audit/rules.d/*", and "/etc/audit/auditd.conf" files have a mode of "0640" or less permissive by using the following command: $ sudo ls -al /etc/audit/ /etc/audit/rules.d/ /etc/audit/: -rw-r----- 1 root root 804 Nov 25 11:01 auditd.conf -rw-r----- 1 root root 9128 Dec 27 09:56 audit.rules -rw-r----- 1 root root 9373 Dec 27 09:56 audit.rules.prev -rw-r----- 1 root root 127 Feb 7 2018 audit-stop.rules drwxr-x--- 2 root root 4096 Dec 27 09:56 rules.d /etc/audit/rules.d/: -rw-r----- 1 root root 10357 Dec 27 09:56 stig.rules If "/etc/audit/audit.rule","/etc/audit/rules.d/*", or "/etc/audit/auditd.conf" file have a mode more permissive than "0640", this is a finding.
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 that "/etc/audit/audit.rules", "/etc/audit/rules.d/*" and "/etc/audit/auditd.conf" files are owned by root account by using the following command: $ sudo ls -al /etc/audit/ /etc/audit/rules.d/ /etc/audit/: drwxr-x--- 3 root root 4096 Nov 25 11:02 . drwxr-xr-x 130 root root 12288 Dec 19 13:42 .. -rw-r----- 1 root root 804 Nov 25 11:01 auditd.conf -rw-r----- 1 root root 9128 Dec 27 09:56 audit.rules -rw-r----- 1 root root 9373 Dec 27 09:56 audit.rules.prev -rw-r----- 1 root root 127 Feb 7 2018 audit-stop.rules drwxr-x--- 2 root root 4096 Dec 27 09:56 rules.d /etc/audit/rules.d/: drwxr-x--- 2 root root 4096 Dec 27 09:56 . drwxr-x--- 3 root root 4096 Nov 25 11:02 .. -rw-r----- 1 root root 10357 Dec 27 09:56 stig.rules If the "/etc/audit/audit.rules", "/etc/audit/rules.d/*", or "/etc/audit/auditd.conf" file is owned by a user other than "root", this is a finding.
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 that "/etc/audit/audit.rules", "/etc/audit/rules.d/*", and "/etc/audit/auditd.conf" files are owned by root group by using the following command: $ sudo ls -al /etc/audit/ /etc/audit/rules.d/ /etc/audit/: -rw-r----- 1 root root 804 Nov 25 11:01 auditd.conf -rw-r----- 1 root root 9128 Dec 27 09:56 audit.rules -rw-r----- 1 root root 9373 Dec 27 09:56 audit.rules.prev -rw-r----- 1 root root 127 Feb 7 2018 audit-stop.rules drwxr-x--- 2 root root 4096 Dec 27 09:56 rules.d /etc/audit/rules.d/: -rw-r----- 1 root root 10357 Dec 27 09:56 stig.rules If the "/etc/audit/audit.rules", "/etc/audit/rules.d/*", or "/etc/audit/auditd.conf" file is owned by a group other than "root", this is a finding.
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 the Ubuntu operating system generates audit records upon successful/unsuccessful attempts to use the "su" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep '/bin/su' -a always,exit -S all -F path=/bin/su -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from the example output above.
Configure the Ubuntu operating system to generate audit records when successful/unsuccessful attempts to use the "su" command occur. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F path=/bin/su -F perm=x -F auid>=1000 -F auid!=unset -k privileged-priv_change To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify the Ubuntu operating system generates audit records upon successful/unsuccessful attempts to use the "chfn" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep '/usr/bin/chfn' -a always,exit -S all -F path=/usr/bin/chfn -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k privileged-chfn To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify the Ubuntu operating system generates audit records upon successful/unsuccessful attempts to use the "mount" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep '/usr/bin/mount' -a always,exit -S all -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k privileged-mount To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify the Ubuntu operating system generates audit records upon successful/unsuccessful attempts to use the "umount" command Check the configured audit rules with the following commands: $ sudo auditctl -l | grep '/usr/bin/umount' -a always,exit -S all -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k privileged-umount To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "ssh-agent" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep '/usr/bin/ssh-agent' -a always,exit -S all -F path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k privileged-ssh To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "ssh-keysign" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep ssh-keysign -a always,exit -S all -F path=/usr/lib/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k privileged-ssh To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "setxattr", "fsetxattr", "lsetxattr", "removexattr", "fremovexattr", and "lremovexattr" system calls. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep xattr -a always,exit -F arch=b32 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b32 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid>=1000 -F auid!=-1 -k perm_mod -a always,exit -F arch=b64 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid=0 -k perm_mod If the command does not return audit rules for the "setxattr", "fsetxattr", "lsetxattr", "removexattr", "fremovexattr" and "lremovexattr" syscalls or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "setxattr", "fsetxattr", "lsetxattr", "removexattr", "fremovexattr", and "lremovexattr" system calls. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid=0 -k perm_mod -a always,exit -F arch=b64 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S setxattr,fsetxattr,lsetxattr,removexattr,fremovexattr,lremovexattr -F auid=0 -k perm_mod Note: For 32-bit architectures, only the 32-bit specific entries are required. To reload the rules file, issue the following command: $ sudo augenrules --load
Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "chown", "fchown", "fchownat", and "lchown" system calls. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep chown -a always,exit -F arch=b32 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return audit rules for the "chown", "fchown", "fchownat", and "lchown" syscalls or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chown", "fchown", "fchownat", and "lchown" system calls. Add or update the following rules in the "/etc/audit/rules.d/stig.rules": -a always,exit -F arch=b32 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=4294967295 -k perm_chng Note: For 32-bit architectures, only the 32-bit specific entries are required. To reload the rules file, issue the following command: $ sudo augenrules --load
Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "chmod", "fchmod", and "fchmodat" system calls. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep chmod -a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -k perm_chng -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -k perm_chng If the command does not return audit rules for the "chmod", "fchmod" and "fchmodat" syscalls or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chmod", "fchmod", and "fchmodat" system calls. Add or update the following rules in the "/etc/audit/rules.d/stig.rules": -a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. To reload the rules file, issue the following command: $ sudo augenrules --load
Verify the Ubuntu operating system generates an audit record upon unsuccessful attempts to use the "creat", "open", "openat", "open_by_handle_at", "truncate", and "ftruncate" system calls. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep 'open\|truncate\|creat' -a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k perm_access -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k perm_access If the command does not return audit rules for the "creat", "open", "openat", "open_by_handle_at", "truncate", and "ftruncate" syscalls or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the audit system to generate an audit event for any unsuccessful use of the"creat", "open", "openat", "open_by_handle_at", "truncate", and "ftruncate" system calls. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access Notes: For 32-bit architectures, only the 32-bit specific entries are required. To reload the rules file, issue the following command: $ sudo augenrules --load
Verify that an audit event is generated for any successful/unsuccessful use of the "sudo" command. Check the configured audit rules with the following command: $ sudo auditctl -l | grep /usr/bin/sudo -a always,exit -S all -F path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k priv_cmd To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "sudoedit" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep /usr/bin/sudoedit -a always,exit -S all -F path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k priv_cmd To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "chsh" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep chsh -a always,exit -S all -F path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=-1 -F key=priv_cmd If the command does not return a line that matches the example or the line is commented out, this is a finding. Notes: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
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!=unset -k priv_cmd To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "newgrp" command. Check the configured audit rules with the following commands: $ sudo auditctl -l | grep newgrp -a always,exit -S all -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k priv_cmd To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "chcon" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep chcon -a always,exit -S all -F path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k perm_chng To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "apparmor_parser" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep apparmor_parser -a always,exit -S all -F path=/sbin/apparmor_parser -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k perm_chng To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "setfacl" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep setfacl -a always,exit -S all -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k perm_chng To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful attempts to use the "chacl" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep chacl -a always,exit -S all -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k perm_chng To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful modifications to the "tallylog" file. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep tallylog -w /var/log/tallylog -p wa -k logins If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the audit system to generate an audit event for any successful/unsuccessful modifications to the "tallylog" file. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -w /var/log/tallylog -p wa -k logins To reload the rules file, issue the following command: $ sudo augenrules --load
Verify the Ubuntu operating system generates an audit record upon successful/unsuccessful modifications to the "faillog" file. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep faillog -w /var/log/faillog -p wa -k logins If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
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 the Ubuntu operating system generates an audit record when successful/unsuccessful modifications to the "lastlog" file occur. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep lastlog -w /var/log/lastlog -p wa -k logins If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
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. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep -w passwd -a always,exit -S all -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=-1 -F key=privileged-passwd If the command does not return a line that matches the example or the line is commented out, this is a finding. Note: The "key" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
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!=unset -k privileged-passwd To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify that an audit event is generated for any successful/unsuccessful use of the "unix_update" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep -w unix_update -a always,exit -S all -F path=/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k privileged-unix-update To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify that an audit event is generated for any successful/unsuccessful use of the "gpasswd" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep -w gpasswd -a always,exit -S all -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k privileged-gpasswd To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify that an audit event is generated for any successful/unsuccessful use of the "chage" command Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep -w chage -a always,exit -S all -F path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k privileged-chage To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify that an audit event is generated for any successful/unsuccessful use of the "usermod" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep -w usermod -a always,exit -S all -F path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k privileged-usermod To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify that an audit event is generated for any successful/unsuccessful use of the "crontab" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep -w crontab -a always,exit -S all -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k privileged-crontab To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify that an audit event is generated for any successful/unsuccessful use of the "pam_timestamp_check" command. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep -w pam_timestamp_check -a always,exit -S all -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=-1 -F key=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 "key=" value is arbitrary and can be different from 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!=unset -k privileged-pam_timestamp_check To reload the rules file, issue the following command: $ sudo augenrules --load Note: The "-k <keyname>" at the end of the line gives the rule a unique meaning to help during an audit investigation. The <keyname> does not need to match the example above.
Verify the Ubuntu operating system generates an audit record for any successful/unsuccessful attempts to use the "init_module" and "finit_module" syscalls. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep init_module -a always,exit -F arch=b32 -S init_module,finit_module -F auid>=1000 -F auid!=-1 -k module_chng -a always,exit -F arch=b64 -S init_module,finit_module -F auid>=1000 -F auid!=-1 -k module_chng If the command does not return audit rules for the "init_module" and "finit_module" syscalls or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "init_module" and "finit_module" syscalls. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S init_module,finit_module -F auid>=1000 -F auid!=4294967295 -k module_chng -a always,exit -F arch=b64 -S init_module,finit_module -F auid>=1000 -F auid!=4294967295 -k module_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. To reload the rules file, issue the following command: $ sudo augenrules --load
Verify the Ubuntu operating system generates an audit record for any successful/unsuccessful attempts to use the "delete_module" syscall. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep -w delete_module -a always,exit -F arch=b32 -S delete_module -F auid>=1000 -F auid!=-1 -k module_chng -a always,exit -F arch=b64 -S delete_module -F auid>=1000 -F auid!=-1 -k module_chng If the command does not return a line that matches the example or the line is commented out, this is a finding. Notes: - For 32-bit architectures, only the 32-bit specific output lines from the commands are required. - The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "delete_module" syscall. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b32 -S delete_module -F auid>=1000 -F auid!=4294967295 -k module_chng -a always,exit -F arch=b64 -S delete_module -F auid>=1000 -F auid!=4294967295 -k module_chng Notes: For 32-bit architectures, only the 32-bit specific entries are required. To reload the rules file, issue the following command: $ sudo augenrules --load
Verify the audit service is configured to produce audit records with the following command: $ dpkg -l | grep auditd If the "auditd" package is not installed, this is a finding. Verify the audit service is enabled with the following command: $ systemctl is-enabled auditd.service If the command above returns "disabled", this is a finding. Verify the audit service is properly running and active on the system with the following command: $ systemctl is-active auditd.service active If the command above returns "inactive", this is a finding.
Configure the audit service to produce audit records containing the information needed to establish when (date and time) an event occurred. Install the audit service (if the audit service is not already installed) with the following command: $ sudo apt-get install auditd Enable the audit service with the following command: $ sudo systemctl enable auditd.service To reload the rules file, issue the following command: $ sudo augenrules --load
Verify that the Ubuntu operating system enables auditing at system startup. Verify that the auditing is enabled in grub with the following command: $ sudo grep "^\s*linux" /boot/grub/grub.cfg linux /boot/vmlinuz-5.4.0-31-generic root=UUID=74d13bcd-6ebd-4493-b5d2-3ebc37d01702 ro audit=1 linux /boot/vmlinuz-5.4.0-31-generic root=UUID=74d13bcd-6ebd-4493-b5d2-3ebc37d01702 ro recovery nomodeset audit=1 If any linux lines do not contain "audit=1", this is a finding.
Configure the Ubuntu operating system to produce audit records at system startup. Edit the "/etc/default/grub" file and add "audit=1" to the "GRUB_CMDLINE_LINUX" option. To update the grub config file, run: $ sudo update-grub
Verify the Ubuntu operating system configures the audit tools to have a file permission of 0755 or less to prevent unauthorized access by running the following command: $ stat -c "%n %a" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules /sbin/auditctl 755 /sbin/aureport 755 /sbin/ausearch 755 /sbin/autrace 755 /sbin/auditd 755 /sbin/audispd 755 /sbin/augenrules 755 If any of the audit tools have a mode more permissive than 0755, this is a finding.
Configure the audit tools on the Ubuntu operating system to be protected from unauthorized access by setting the correct permissive mode using the following command: $ sudo chmod 0755 [audit_tool] Replace "[audit_tool]" with the audit tool that does not have the correct permissions.
Verify the Ubuntu operating system configures the audit tools to be owned by root to prevent any unauthorized access. Check the ownership by running the following command: $ stat -c "%n %U" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules /sbin/auditctl root /sbin/aureport root /sbin/ausearch root /sbin/autrace root /sbin/auditd root /sbin/audispd root /sbin/augenrules root If any of the audit tools are not owned by root, this is a finding.
Configure the audit tools on the Ubuntu operating system to be protected from unauthorized access by setting the file owner as root using the following command: $ sudo chown root [audit_tool] Replace "[audit_tool]" with each audit tool not owned by root.
Verify the Ubuntu operating system configures the audit tools to be group-owned by root to prevent any unauthorized access. Check the group ownership by running the following command: $ stat -c "%n %G" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules /sbin/auditctl root /sbin/aureport root /sbin/ausearch root /sbin/autrace root /sbin/auditd root /sbin/audispd root /sbin/augenrules root If any of the audit tools are not group-owned by root, this is a finding.
Configure the audit tools on the Ubuntu operating system to be protected from unauthorized access by setting the file group as root using the following command: $ sudo chown :root [audit_tool] Replace "[audit_tool]" with each audit tool not group-owned by root.
Verify that Advanced Intrusion Detection Environment (AIDE) is properly configured to use cryptographic mechanisms to protect the integrity of audit tools. Check the selection lines that AIDE is configured to add/check with the following command: $ egrep '(\/sbin\/(audit|au))' /etc/aide/aide.conf /sbin/auditctl p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/auditd p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/ausearch p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/aureport p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/autrace p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/audispd p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/augenrules p+i+n+u+g+s+b+acl+xattrs+sha512 If any of the seven audit tools do not have appropriate selection lines, this is a finding.
Add or update the following selection lines for "/etc/aide/aide.conf" to protect the integrity of the audit tools: # Audit Tools /sbin/auditctl p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/auditd p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/ausearch p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/aureport p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/autrace p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/audispd p+i+n+u+g+s+b+acl+xattrs+sha512 /sbin/augenrules p+i+n+u+g+s+b+acl+xattrs+sha512
Verify the Ubuntu operating system audits the execution of privilege functions by auditing the "execve" system call. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep execve -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -F key=execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -F key=execpriv -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -F key=execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -F key=execpriv If the command does not return lines that match the example or the lines are commented out, this is a finding. Notes: - For 32-bit architectures, only the 32-bit specific output lines from the commands are required. - The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the Ubuntu operating system to audit the execution of all privileged functions. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -F key=execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -F key=execpriv -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -F key=execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -F key=execpriv Notes: For 32-bit architectures, only the 32-bit specific entries are required. To reload the rules file, issue the following command: $ sudo augenrules --load
Verify the Ubuntu operating system allocates audit record storage capacity to store at least one week's worth of audit records when audit records are not immediately sent to a central audit record storage facility. Determine which partition the audit records are being written to with the following command: $ sudo grep ^log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Check the size of the partition that audit records are written to (with the example being "/var/log/audit/") with the following command: $ sudo df –h /var/log/audit/ /dev/sda2 24G 10.4G 13.6G 43% /var/log/audit If the audit records are not written to a partition made specifically for audit records ("/var/log/audit" is a separate partition), determine the amount of space being used by other files in the partition with the following command: $ sudo du –sh [audit_partition] 1.8G /var/log/audit Note: The partition size needed to capture a week's worth of audit records is based on the activity level of the system and the total storage capacity available. In normal circumstances, 10.0 GB of storage space for audit records will be sufficient. If the audit record partition is not allocated for sufficient storage capacity, this is a finding.
Allocate enough storage capacity for at least one week's worth of audit records when audit records are not immediately sent to a central audit record storage facility. If audit records are stored on a partition made specifically for audit records, use the "parted" program to resize the partition with sufficient space to contain one week's worth of audit records. If audit records are not stored on a partition made specifically for audit records, a new partition with sufficient amount of space will need be to be created. Set the auditd server to point to the mount point where the audit records must be located: $ sudo sed -i -E 's@^(log_file\s*=\s*).*@\1 <log mountpoint>/audit.log@' /etc/audit/auditd.conf where <log mountpoint> is the aforementioned mount point.
Verify the audit event multiplexor is configured to offload audit records to a different system or storage media from the system being audited. Check that audisp-remote plugin is installed: $ sudo dpkg -s audispd-plugins If status is "not installed", this is a finding. Check that the records are being offloaded to a remote server with the following command: $ sudo grep -i active /etc/audisp/plugins.d/au-remote.conf active = yes If "active" is not set to "yes", or the line is commented out, this is a finding. Check that audisp-remote plugin is configured to send audit logs to a different system: $ sudo grep -i ^remote_server /etc/audisp/audisp-remote.conf remote_server = 192.168.122.126 If the "remote_server" parameter is not set, is set with a local address, or is set with an invalid address, this is a finding.
Configure the audit event multiplexor to offload audit records to a different system or storage media from the system being audited. Install the audisp-remote plugin: $ sudo apt-get install audispd-plugins -y Set the audisp-remote plugin as active by editing the "/etc/audisp/plugins.d/au-remote.conf" file: $ sudo sed -i -E 's/active\s*=\s*no/active = yes/' /etc/audisp/plugins.d/au-remote.conf Set the address of the remote machine by editing the "/etc/audisp/audisp-remote.conf" file: $ sudo sed -i -E 's/(remote_server\s*=).*/\1 <remote addr>/' /etc/audisp/audisp-remote.conf where <remote addr> must be substituted by the address of the remote server receiving the audit log. Make the audit service reload its configuration files: $ sudo systemctl restart auditd.service
Verify the Ubuntu operating system notifies the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75% of the repository maximum audit record storage capacity with the following command: $ sudo grep ^space_left_action /etc/audit/auditd.conf space_left_action email $ sudo grep ^space_left /etc/audit/auditd.conf space_left 250000 If the "space_left" parameter is missing, set to blanks, or set to a value less than 25% of the space free in the allocated audit record storage, this is a finding. If the "space_left_action" parameter is missing or set to blanks, this is a finding. If the "space_left_action" is set to "syslog", the system logs the event but does not generate a notification, and this is a finding. If the "space_left_action" is set to "exec", the system executes a designated script. If this script informs the SA of the event, this is not a finding. If the "space_left_action" is set to "email", check the value of the "action_mail_acct" parameter with the following command: $ sudo grep ^action_mail_acct /etc/audit/auditd.conf action_mail_acct root@localhost The "action_mail_acct" parameter, if missing, defaults to "root". If the "action_mail_acct parameter" is not set to the email address of the SA(s) and/or ISSO, this is a finding. Note: If the email address of the System Administrator is on a remote system, a mail package must be available.
Edit "/etc/audit/auditd.conf" and set the "space_left_action" parameter to "exec" or "email". If the "space_left_action" parameter is set to "email", set the "action_mail_acct" parameter to an email address for the SA and ISSO. If the "space_left_action" parameter is set to "exec", ensure the command being executed notifies the SA and ISSO. Edit "/etc/audit/auditd.conf" and set the "space_left" parameter to be at least 25% of the repository maximum audit record storage capacity.
To verify the time zone is configured to use UTC or GMT, run the following command. $ timedatectl status | grep -i "time zone" Timezone: UTC (UTC, +0000) If "Timezone" is not set to UTC or GMT, this is a finding.
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]
Verify the Ubuntu operating system audits activities performed during nonlocal maintenance and diagnostic sessions. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep sudo.log -w /var/log/sudo.log -p wa -k maintenance If the command does not return lines that match the example or the lines are commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the Ubuntu operating system to audit activities performed during nonlocal maintenance and diagnostic sessions. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -w /var/log/sudo.log -p wa -k maintenance To reload the rules file, issue the following command: $ sudo augenrules --load
Verify the Ubuntu operating system generates audit records for any successful/unsuccessful use of "unlink", "unlinkat", "rename", "renameat", and "rmdir" system calls. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep 'unlink\|rename\|rmdir' -a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat,rmdir -F auid>=1000 -F auid!=-1 -F key=delete -a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat,rmdir -F auid>=1000 -F auid!=-1 -F key=delete If the command does not return audit rules for the "unlink", "unlinkat", "rename", "renameat", and "rmdir" syscalls or the lines are commented out, this is a finding. Notes: For 32-bit architectures, only the 32-bit specific output lines from the commands are required. The "key" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the audit system to generate audit events for any successful/unsuccessful use of "unlink", "unlinkat", "rename", "renameat", and "rmdir" system calls. Add or update the following rules in the "/etc/audit/rules.d/stig.rules" file: -a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat,rmdir -F auid>=1000 -F auid!=4294967295 -k delete -a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat,rmdir -F auid>=1000 -F auid!=4294967295 -k delete Notes: For 32-bit architectures, only the 32-bit specific entries are required. To reload the rules file, issue the following command: $ sudo augenrules --load
Verify the Ubuntu operating system generates audit records showing start and stop times for user access to the system via the "/var/log/wtmp" file. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep '/var/log/wtmp' -w /var/log/wtmp -p wa -k logins If the command does not return a line matching the example or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
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 the Ubuntu operating system generates audit records showing start and stop times for user access to the system via the "/var/run/utmp" file. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep '/var/run/utmp' -w /var/run/utmp -p wa -k logins If the command does not return a line matching the example or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
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 the Ubuntu operating system generates audit records showing start and stop times for user access to the system via the "/var/log/btmp" file. Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep '/var/log/btmp' -w /var/log/btmp -p wa -k logins If the command does not return a line matching the example or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
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 the Ubuntu operating system is configured to audit the execution of the module management program "modprobe" by running the following command: $ sudo auditctl -l | grep "/sbin/modprobe" -w /sbin/modprobe -p x -k modules If the command does not return a line, or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the Ubuntu operating system to audit the execution of the module management program "modprobe". Add or update the following rule in the "/etc/audit/rules.d/stig.rules" file: -w /sbin/modprobe -p x -k modules To reload the rules file, issue the following command: $ sudo augenrules --load
Verify the Ubuntu operating system is configured to audit the execution of the module management program "kmod". Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep kmod -w /bin/kmod -p x -k module If the command does not return a line, or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the Ubuntu operating system to audit the execution of the module management program "kmod". Add or update the following rule in the "/etc/audit/rules.d/stig.rules" file: -w /bin/kmod -p x -k modules To reload the rules file, issue the following command: $ sudo augenrules --load
Verify the Ubuntu operating system is configured to audit the execution of the partition management program "fdisk". Check the currently configured audit rules with the following command: $ sudo auditctl -l | grep fdisk -w /usr/sbin/fdisk -p x -k fdisk If the command does not return a line, or the line is commented out, this is a finding. Note: The "-k" allows for specifying an arbitrary identifier, and the string after it does not need to match the example output above.
Configure the Ubuntu operating system to audit the execution of the partition management program "fdisk". Add or update the following rule in the "/etc/audit/rules.d/stig.rules" file: -w /usr/sbin/fdisk -p x -k fdisk To reload the rules file, issue the following command: $ sudo augenrules --load
Note: If this is an interconnected system, this is Not Applicable. Verify there is a script that offloads audit data and that script runs weekly. Check if there is a script in the "/etc/cron.weekly" directory that offloads audit data: # sudo ls /etc/cron.weekly audit-offload Check if the script inside the file does offloading of audit logs to external media. If the script file does not exist or does not offload audit logs, this is a finding.
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 the Ubuntu operating system limits the number of concurrent sessions to 10 for all accounts and/or account types by running the following command: $ grep maxlogins /etc/security/limits.conf | grep -v '^* hard maxlogins' The result must contain the following line: * hard maxlogins 10 If the "maxlogins" item is missing or the value is not set to 10 or less or is commented out, this is a finding.
Configure the Ubuntu operating system to limit the number of concurrent sessions to 10 for all accounts and/or account types. Add the following line to the top of the "/etc/security/limits.conf" file: * hard maxlogins 10
Verify that the Ubuntu operating system monitors all remote access methods. Check that remote access methods are being logged by running the following command: $ grep -E -r '^(auth,authpriv\.\*|daemon\.\*)' /etc/rsyslog.* /etc/rsyslog.d/50-default.conf:auth,authpriv.* /var/log/auth.log /etc/rsyslog.d/50-default.conf:daemon.* /var/log/messages If "auth.*", "authpriv.*", or "daemon.*" are not configured to be logged in at least one of the config files, this is a finding.
Configure the Ubuntu operating system to monitor all remote access methods by adding the following lines to the "/etc/rsyslog.d/50-default.conf" file: auth.*,authpriv.* /var/log/secure daemon.* /var/log/messages For the changes to take effect, restart the "rsyslog" service with the following command: $ sudo systemctl restart rsyslog.service
Verify that the shadow password suite configuration is set to encrypt passwords with a FIPS 140-2 approved cryptographic hashing algorithm. Check the hashing algorithm that is being used to hash passwords with the following command: $ cat /etc/login.defs | grep -i encrypt_method ENCRYPT_METHOD SHA512 If "ENCRYPT_METHOD" does not equal SHA512 or greater, this is a finding.
Configure the Ubuntu operating system to encrypt all stored passwords. Edit/modify the following line in the "/etc/login.defs" file and set "ENCRYPT_METHOD" to SHA512: ENCRYPT_METHOD SHA512
Verify that the telnet package is not installed on the Ubuntu operating system by running the following command: $ dpkg -l | grep telnetd If the package is installed, this is a finding.
Remove the telnet package from the Ubuntu operating system by running the following command: $ sudo apt-get 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 the Ubuntu operating system to disable non-essential capabilities by removing the rsh-server package from the system with the following command: $ sudo apt-get remove rsh-server
Verify the Ubuntu operating system is configured to prohibit or restrict the use of functions, ports, protocols, and/or services as defined in the Ports, Protocols, and Services Management (PPSM) Category Assignments List (CAL) and vulnerability assessments. Check the firewall configuration for any unnecessary or prohibited functions, ports, protocols, and/or services by running the following command: $ sudo ufw show raw Chain OUTPUT (policy ACCEPT) target prot opt sources destination Chain INPUT (policy ACCEPT 1 packets, 40 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Ask the System Administrator for the site or program PPSM CLSA. Verify the services allowed by the firewall match the PPSM CLSA. If there are any additional ports, protocols, or services that are not included in the PPSM CLSA, this is a finding. If there are any ports, protocols, or services that are prohibited by the PPSM CAL, this is a finding.
Add all ports, protocols, or services allowed by the PPSM CLSA by using the following command: $ sudo ufw allow <direction> <port/protocol/service> where the direction is "in" or "out" and the port is the one corresponding to the protocol or service allowed. To deny access to ports, protocols, or services, use: $ sudo ufw deny <direction> <port/protocol/service>
Verify the Ubuntu operating system prevents direct logins to the root account with the following command: $ sudo passwd -S root root L 04/23/2020 0 99999 7 -1 If the output does not contain "L" in the second field to indicate the account is locked, this is a finding.
Configure the Ubuntu operating system to prevent direct logins to the root account by performing the following operations: $ sudo passwd -l root
Verify the account identifiers (individuals, groups, roles, and devices) are disabled after 35 days of inactivity with the following command: Check the account inactivity value by performing the following command: $ sudo grep INACTIVE /etc/default/useradd INACTIVE=35 If "INACTIVE" is not set to a value 0<[VALUE]<=35, or is commented out, this is a finding.
Configure the Ubuntu operating system to disable account identifiers after 35 days of inactivity since the password expiration. Run the following command to change the configuration for adduser: $ sudo useradd -D -f 35 Note: DoD recommendation is 35 days, but a lower value is acceptable. The value "0" will disable the account immediately after the password expires.
Verify temporary accounts have been provisioned with an expiration date of 72 hours. For every existing temporary account, run the following command to obtain its account expiration information: $ sudo chage -l <temporary_account_name> | grep -i "account expires" Verify each of these accounts has an expiration date set within 72 hours. If any temporary accounts have no expiration date set or do not expire within 72 hours, this is a finding.
Configure the operating system to expire temporary accounts after 72 hours with the following command: $ sudo chage -E $(date -d +3days +%Y-%m-%d) <temporary_account_name>
Verify that all public (world-writeable) directories have the public sticky bit set. Find world-writable directories that lack the sticky bit by running the following command: $ sudo find / -type d -perm -002 ! -perm -1000 If any world-writable directories are found missing the sticky bit, this is a finding.
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 the Ubuntu operating system is configured to use TCP syncookies. Check the value of TCP syncookies with the following command: $ sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_syncookies = 1 If the value is not "1", this is a finding. Check the saved value of TCP syncookies with the following command: $ sudo grep -i net.ipv4.tcp_syncookies /etc/sysctl.conf /etc/sysctl.d/* | grep -v '#' If no output is returned, this is a finding.
Configure the Ubuntu operating system to use TCP syncookies by running the following command: $ sudo sysctl -w net.ipv4.tcp_syncookies=1 If "1" is not the system's default value, add or update the following line in "/etc/sysctl.conf": net.ipv4.tcp_syncookies = 1
Verify that kernel core dumps are disabled unless needed. Check if "kdump" service is active with the following command: $ systemctl is-active kdump.service inactive If the "kdump" service is active, ask the SA if the use of the service is required and documented with the ISSO. If the service is active and is not documented, this is a finding.
If kernel core dumps are not required, disable the "kdump" service with the following command: $ sudo systemctl disable kdump.service If kernel core dumps are required, document the need with the ISSO.
If there is a documented and approved reason for not having data-at-rest encryption, this requirement is Not Applicable. Verify the Ubuntu operating system prevents unauthorized disclosure or modification of all information requiring at-rest protection by using disk encryption. Determine the partition layout for the system with the following command: #sudo fdisk -l (..) Disk /dev/vda: 15 GiB, 16106127360 bytes, 31457280 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 83298450-B4E3-4B19-A9E4-7DF147A5FEFB Device Start End Sectors Size Type /dev/vda1 2048 4095 2048 1M BIOS boot /dev/vda2 4096 2101247 2097152 1G Linux filesystem /dev/vda3 2101248 31455231 29353984 14G Linux filesystem (...) Verify the system partitions are all encrypted with the following command: # more /etc/crypttab Every persistent disk partition present must have an entry in the file. If any partitions other than the boot partition or pseudo file systems (such as /proc or /sys) are not listed, this is a finding.
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 Ubuntu operating system has all system log files under the "/var/log" directory with a permission set to "640" or less permissive by using the following command: Note: The btmp, wtmp, and lastlog files are excluded. Refer to the Discussion for details. $ sudo find /var/log -perm /137 ! -name '*[bw]tmp' ! -name '*lastlog' -type f -exec stat -c "%n %a" {} \; If the command displays any output, this is a finding.
Configure the Ubuntu operating system to set permissions of all log files under the "/var/log" directory to "640" or more restricted by using the following command: Note: The btmp, wtmp, and lastlog files are excluded. Refer to the Discussion for details. $ sudo find /var/log -perm /137 ! -name '*[bw]tmp' ! -name '*lastlog' -type f -exec chmod 640 '{}' \;
Verify that the Ubuntu operating system configures the "/var/log" directory to be group-owned by syslog with the following command: $ sudo stat -c "%n %G" /var/log /var/log syslog If the "/var/log" directory is not group-owned by syslog, this is a finding.
Configure the Ubuntu operating system to have syslog group-own the "/var/log" directory by running the following command: $ sudo chgrp syslog /var/log
Verify the Ubuntu operating system configures the "/var/log" directory to be owned by root with the following command: $ sudo stat -c "%n %U" /var/log /var/log root If the "/var/log" directory is not owned by root, this is a finding.
Configure the Ubuntu operating system to have root own the "/var/log" directory by running the following command: $ sudo chown root /var/log
Verify that the Ubuntu operating system configures the "/var/log" directory with a mode of "755" or less permissive with the following command: Note: If rsyslog is active and enabled on the operating system, this requirement is not applicable. $ stat -c "%n %a" /var/log /var/log 755 If a value of "755" or less permissive is not returned, this is a finding.
Configure the Ubuntu operating system to have permissions of "0755" for the "/var/log" directory by running the following command: $ sudo chmod 0755 /var/log
Verify that the Ubuntu operating system configures the "/var/log/syslog" file to be group-owned by adm with the following command: $ sudo stat -c "%n %G" /var/log/syslog /var/log/syslog adm If the "/var/log/syslog" file is not group-owned by adm, this is a finding.
Configure the Ubuntu operating system to have adm group-own the "/var/log/syslog" file by running the following command: $ sudo chgrp adm /var/log/syslog
Verify that the Ubuntu operating system configures the "/var/log/syslog" file to be owned by syslog with the following command: $ sudo stat -c "%n %U" /var/log/syslog /var/log/syslog syslog If the "/var/log/syslog" file is not owned by syslog, this is a finding.
Configure the Ubuntu operating system to have syslog own the "/var/log/syslog" file by running the following command: $ sudo chown syslog /var/log/syslog
Verify that the Ubuntu operating system configures the "/var/log/syslog" file with mode 0640 or less permissive by running the following command: $ sudo stat -c "%n %a" /var/log/syslog /var/log/syslog 640 If a value of "640" or less permissive is not returned, this is a finding.
Configure the Ubuntu operating system to have permissions of 0640 for the "/var/log/syslog" file by running the following command: $ sudo chmod 0640 /var/log/syslog
Verify the system commands directories have mode 0755 or less permissive: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Check that the system command directories have mode 0755 or less permissive with the following command: $ find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -perm /022 -type d -exec stat -c "%n %a" '{}' \; If any directories are found to be group-writable or world-writable, this is a finding.
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: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Use the following command for the check: $ sudo find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -user root -type d -exec stat -c "%n %U" '{}' \; If any system commands directories are returned, this is a finding.
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: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Run the check with the following command: $ sudo find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -group root -type d -exec stat -c "%n %G" '{}' \; If any system commands directories are returned that are not Set Group ID up on execution (SGID) files and owned by a privileged account, this is a finding.
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 the system-wide shared library files contained in the directories "/lib", "/lib64", and "/usr/lib" have mode 0755 or less permissive with the following command: $ sudo find /lib /lib64 /usr/lib -perm /022 -type f -exec stat -c "%n %a" '{}' \; /usr/lib64/pkcs11-spy.so If any files are found to be group-writable or world-writable, this is a finding.
Configure the library files to be protected from unauthorized access. Run the following command: $ sudo find /lib /lib64 /usr/lib -perm /022 -type f -exec chmod 755 '{}' \;
Verify the system-wide shared library directories "/lib", "/lib64", and "/usr/lib have mode 0755 or less permissive with the following command: $ sudo find /lib /lib64 /usr/lib -perm /022 -type d -exec stat -c "%n %a" '{}' \; If any of the aforementioned directories are found to be group-writable or world-writable, this is a finding.
Configure the shared library directories to be protected from unauthorized access. Run the following command: $ sudo find /lib /lib64 /usr/lib -perm /022 -type d -exec chmod 755 '{}' \;
Verify the system-wide shared library files contained in the directories "/lib", "/lib64", and "/usr/lib" are owned by root with the following command: $ sudo find /lib /usr/lib /lib64 ! -user root -type f -exec stat -c "%n %U" '{}' \; If any system-wide library file is returned, this is a finding.
Configure the system library files to be protected from unauthorized access. Run the following command: $ sudo find /lib /usr/lib /lib64 ! -user root -type f -exec chown root '{}' \;
Verify the system-wide shared library directories "/lib", "/lib64", and "/usr/lib" are owned by root with the following command: $ sudo find /lib /usr/lib /lib64 ! -user root -type d -exec stat -c "%n %U" '{}' \; If any system-wide library directory is returned, this is a finding.
Configure the library files and their respective parent directories to be protected from unauthorized access. Run the following command: $ sudo find /lib /usr/lib /lib64 ! -user root -type d -exec chown root '{}' \;
Verify the system-wide library files contained in the directories "/lib", "/lib64", and "/usr/lib" are group-owned by root, or a required system account, with the following command: $ sudo find /lib /usr/lib /lib64 ! -group root -type f -exec stat -c "%n %G" '{}' \; If any system-wide shared library file is returned and is not group-owned by a required system account, this is a finding.
Configure the system library files to be protected from unauthorized access. Run the following command, replacing "[FILE]" with any system command file not group-owned by "root" or a required system account: $ sudo chgrp root [FILE]
Verify the system-wide library directories "/lib", "/lib64", and "/usr/lib" are group-owned by root with the following command: $ sudo find /lib /usr/lib /lib64 ! -group root -type d -exec stat -c "%n %G" '{}' \; If any system-wide shared library directory is returned, this is a finding.
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 log service is configured to collect system failure events. Check that the log service is installed properly with the following command: $ dpkg -l | grep rsyslog ii rsyslog 8.32.0-1ubuntu4 amd64 reliable system and kernel logging daemon If the "rsyslog" package is not installed, this is a finding. Check that the log service is enabled with the following command: $ systemctl is-enabled rsyslog enabled If the command above returns "disabled", this is a finding. Check that the log service is properly running and active on the system with the following command: $ systemctl is-active rsyslog active If the command above returns "inactive", this is a finding.
Configure the log service to collect failure events. Install the log service (if the log service is not already installed) with the following command: $ sudo apt-get install rsyslog Enable the log service with the following command: $ sudo systemctl enable --now rsyslog
Verify that the Uncomplicated Firewall is installed with the following command: $ dpkg -l | grep ufw ii ufw 0.36-6 If the "ufw" package is not installed, ask the System Administrator if another application firewall is installed. If no application firewall is installed, this is a finding.
Install the Uncomplicated Firewall by using the following command: $ sudo apt-get install ufw
Verify the Uncomplicated Firewall is enabled on the system by running the following command: $ systemctl is-enabled ufw If the above command returns the status as "disabled", this is a finding. Verify the Uncomplicated Firewall is active on the system by running the following command: $ systemctl is-active ufw If the above command returns "inactive" or any kind of error, this is a finding. If the Uncomplicated Firewall is not installed, ask the System Administrator if another application firewall is installed. If no application firewall is installed, this is a finding.
Enable the Uncomplicated Firewall by using the following command: $ sudo systemctl enable --now ufw.service
If the system is not networked, this requirement is Not Applicable. The system clock must be configured to compare the system clock at least every 24 hours to the authoritative time source. Check the value of "maxpoll" in the "/etc/chrony/chrony.conf" file with the following command: $ sudo grep maxpoll /etc/chrony/chrony.conf server tick.usno.navy.mil iburst maxpoll 16 If the "maxpoll" option is set to a number greater than 16 or the line is commented out, this is a finding. Verify that the "chrony.conf" file is configured to an authoritative DoD time source by running the following command: $ grep -i server /etc/chrony/chrony.conf server tick.usno.navy.mil iburst maxpoll 16 server tock.usno.navy.mil iburst maxpoll 16 server ntp2.usno.navy.mil iburst maxpoll 16 If the parameter "server" is not set, is not set to an authoritative DoD time source, or is commented out, this is a finding.
If the system is not networked, this requirement is Not Applicable. To configure the system clock to compare the system clock at least every 24 hours to the authoritative time source, edit the "/etc/chrony/chrony.conf" file. Add or correct the following lines, by replacing "[source]" in the following line with an authoritative DoD time source: server [source] iburst maxpoll = 16 If the "chrony" service was running and the value of "maxpoll" or "server" was updated, the service must be restarted using the following command: $ sudo systemctl restart chrony.service
Verify the operating system synchronizes internal system clocks to the authoritative time source when the time difference is greater than one second. Check the value of "makestep" by running the following command: $ sudo grep makestep /etc/chrony/chrony.conf makestep 1 -1 If the makestep option is commented out or is not set to "1 -1", this is a finding.
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 that APT is configured to prevent the installation of patches, service packs, device drivers, or Ubuntu operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization. Check that the "AllowUnauthenticated" variable is not set at all or is set to "false" with the following command: $ grep AllowUnauthenticated /etc/apt/apt.conf.d/* /etc/apt/apt.conf.d/01-vendor-Ubuntu:APT::Get::AllowUnauthenticated "false"; If any of the files returned from the command with "AllowUnauthenticated" are set to "true", this is a finding.
Configure APT to prevent the installation of patches, service packs, device drivers, or Ubuntu operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization. Remove/update any APT configuration files that contain the variable "AllowUnauthenticated" to "false", or remove "AllowUnauthenticated" entirely from each file. Below is an example of setting the "AllowUnauthenticated" variable to "false": APT::Get::AllowUnauthenticated "false";
Verify the operating system prevents program execution in accordance with local policies. Check that AppArmor is installed and active by running the following command, $ dpkg -l | grep apparmor If the "apparmor" package is not installed, this is a finding. $ systemctl is-active apparmor.service active If "active" is not returned, this is a finding. $ systemctl is-enabled apparmor.service enabled If "enabled" is not returned, this is a finding.
Install "AppArmor" (if it is not installed) with the following command: $ sudo apt-get install apparmor $ sudo systemctl enable apparmor.service Start "apparmor" with the following command: $ sudo systemctl start apparmor.service Note: AppArmor must have properly configured profiles for applications and home directories. All configurations will be based on the actual system setup and organization and normally are on a per role basis. See the AppArmor documentation for more information on configuring profiles.
If smart card authentication is not being used on the system, this s Not Applicable. Verify that PAM prohibits the use of cached authentications after one day with the following command: $ sudo grep offline_credentials_expiration /etc/sssd/sssd.conf /etc/sssd/conf.d/*.conf offline_credentials_expiration = 1 If "offline_credentials_expiration" is not set to a value of "1" in "/etc/sssd/sssd.conf" or in a file with a name ending in .conf in the "/etc/sssd/conf.d/" directory, this is a finding.
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 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 the Ubuntu operating systems install. Enabling a FIPS mode on a pre-existing system involves a number of modifications to the Ubuntu operating system. Refer to the Ubuntu Server 20.04 FIPS 140-2 security policy document for instructions. A subscription to the "Ubuntu Pro" plan is required to obtain the FIPS Kernel cryptographic modules and enable FIPS.
Verify the directory containing the root certificates for the Ubuntu operating system contains certificate files for DoD PKI-established certificate authorities by iterating over all files in the "/etc/ssl/certs" directory and checking if, at least one, has the subject matching "DOD ROOT CA". If none is found, this is a finding.
Configure the Ubuntu operating system to use of DoD PKI-established certificate authorities for verification of the establishment of protected sessions. Edit the "/etc/ca-certificates.conf" file, adding the character "!" to the beginning of all uncommented lines that do not start with the "!" character with the following command: $ sudo sed -i -E 's/^([^!#]+)/!\1/' /etc/ca-certificates.conf Add at least one DoD certificate authority to the "/usr/local/share/ca-certificates" directory in the PEM format. Update the "/etc/ssl/certs" directory with the following command: $ sudo update-ca-certificates
Verify an application firewall is configured to rate limit any connection to the system. Check all the services listening to the ports with the following command: $ sudo ss -l46ut Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process tcp LISTEN 0 128 [::]:ssh [::]:* For each entry, verify that the Uncomplicated Firewall is configured to rate limit the service ports with the following command: $ sudo ufw status Status: active To Action From -- ------ ---- 22/tcp LIMIT Anywhere 22/tcp (v6) LIMIT Anywhere (v6) If any port with a state of "LISTEN" is not marked with the "LIMIT" action, this is a finding.
Configure the application firewall to protect against or limit the effects of DoS attacks by ensuring the Ubuntu operating system is implementing rate-limiting measures on impacted network interfaces. Check all the services listening to the ports with the following command: $ sudo ss -l46ut Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process tcp LISTEN 0 128 [::]:ssh [::]:* For each service with a port listening to connections, run the following command, replacing "[service]" with the service that needs to be rate limited. $ sudo ufw limit [service] Rate-limiting can also be done on an interface. An example of adding a rate-limit on the eth0 interface follows: $ sudo ufw limit in on eth0
Verify the NX (no-execution) bit flag is set on the system with the following commands: $ sudo dmesg | grep -i "execute disable" [ 0.000000] NX (Execute Disable) protection: active If "dmesg" does not show "NX (Execute Disable) protection: active", check the cpuinfo settings with the following command: $ grep flags /proc/cpuinfo | grep -w nx | sort -u flags : fpu vme de pse tsc ms nx rdtscp lm constant_tsc If "flags" does not contain the "nx" flag, this is a finding.
Configure the Ubuntu operating system to enable NX. If "nx" is not showing up in "/proc/cpuinfo", and the system's BIOS setup configuration permits toggling the No Execution bit, set it to "enable".
Verify the Ubuntu operating system implements address space layout randomization (ASLR) with the following command: $ sudo sysctl kernel.randomize_va_space kernel.randomize_va_space = 2 If nothing is returned, verify the kernel parameter "randomize_va_space" is set to "2" with the following command: $ cat /proc/sys/kernel/randomize_va_space 2 If "kernel.randomize_va_space" is not set to "2", this is a finding. Verify that a saved value of the "kernel.randomize_va_space" variable is not defined. $ sudo egrep -R "^kernel.randomize_va_space=[^2]" /etc/sysctl.conf /etc/sysctl.d If this returns a result, this is a finding.
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 is configured to remove all software components after updated versions have been installed with the following command: $ grep -i remove-unused /etc/apt/apt.conf.d/50unattended-upgrades Unattended-Upgrade::Remove-Unused-Dependencies "true"; Unattended-Upgrade::Remove-Unused-Kernel-Packages "true"; If the "::Remove-Unused-Dependencies" and "::Remove-Unused-Kernel-Packages" parameters are not set to "true" or are missing or commented out, this is a finding.
Configure APT to remove all software components after updated versions have been installed. Add or updated the following options to the "/etc/apt/apt.conf.d/50unattended-upgrades" file: Unattended-Upgrade::Remove-Unused-Dependencies "true"; Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Verify that Advanced Intrusion Detection Environment (AIDE) is installed and verifies the correct operation of all security functions. Check that the AIDE package is installed with the following command: $ sudo dpkg -l | grep aide ii aide 0.16.1-1build2 amd64 Advanced Intrusion Detection Environment - static binary If AIDE is not installed, ask the System Administrator how file integrity checks are performed on the system. If there is no application installed to perform integrity checks, this is a finding. If AIDE is installed, check if it has been initialized with the following command: $ sudo aide.wrapper --check If the output is "Couldn't open file /var/lib/aide/aide.db for reading", this is a finding.
Install AIDE, initialize it, and perform a manual check. Install AIDE: $ sudo apt install aide Initialize it (this may take a few minutes): $ sudo aideinit Running aide --init... Example output: Start timestamp: 2022-11-20 11:53:17 -0700 (AIDE 0.16) AIDE initialized database at /var/lib/aide/aide.db.new Verbose level: 6 Number of entries: 119543 --------------------------------------------------- The attributes of the (uncompressed) database(s): --------------------------------------------------- /var/lib/aide/aide.db.new RMD160 : PiEP1DX91JMcHnRSPnpFqNfIFr4= TIGER : /zM5yQBnOIoEH0jplJE5v6S0rUErbTXL SHA256 : BE2iHtBN9lEX53l4R/p7t1al0dIlsgPc Lg4YI08+/Jk= SHA512 : JIdGeNVRgtBPPSwun9St+9cwUrgIIKUW KVTksZXJ29Tt+luC/XNDcjIub7fbPVw/ EcTDsvYtt9MBmBxw1wCYng== CRC32 : jB2FVw== HAVAL : Jhe+fqaDpkswpWSnOTN28TO05QFHsjdq RcFZwCVUGTQ= GOST : WFrarVyxpXbKdW9SAaOy1Te8rSodV3/q nLsXuP7YujA= End timestamp: 2022-11-20 11:58:19 -0700 (run time: 5m 2s) The new database will need to be renamed to be read by AIDE: $ sudo cp -p /var/lib/aide/aide.db.new /var/lib/aide/aide.db Perform a manual check: $ sudo aide.wrapper --check Example output: Start timestamp: 2022-11-20 11:59:16 -0700 (AIDE 0.16) AIDE found differences between database and filesystem!! ... Done.
Verify that Advanced Intrusion Detection Environment (AIDE) notifies the System Administrator when anomalies in the operation of any security functions are discovered with the following command: $ sudo grep SILENTREPORTS /etc/default/aide SILENTREPORTS=no If SILENTREPORTS is uncommented and set to "yes", this is a finding.
Configure the Ubuntu operating system to notify designated personnel if baseline configurations are changed in an unauthorized manner. Modify the "SILENTREPORTS" parameter in the "/etc/default/aide" file with a value of "no" if it does not already exist.
Verify users are provided with feedback on when account accesses last occurred. Check that "pam_lastlog" is used and not silent with the following command: $ grep pam_lastlog /etc/pam.d/login session required pam_lastlog.so showfailed If "pam_lastlog" is missing from "/etc/pam.d/login" file, is not "required", or the "silent" option is present, this is a finding.
Configure the Ubuntu operating system to provide users with feedback on when account accesses last occurred by setting the required configuration options in "/etc/pam.d/login". Add the following line to the top of "/etc/pam.d/login": session required pam_lastlog.so showfailed
Verify the Uncomplicated Firewall is enabled on the system by running the following command: $ systemctl status ufw.service | grep -i "active:" Active: active (exited) since Mon 2016-10-17 12:30:29 CDT; 1s ago If the above command returns the status as "inactive", this is a finding. If the Uncomplicated Firewall is not installed, ask the System Administrator if another application firewall is installed. If no application firewall is installed, this is a finding.
Enable the Uncomplicated Firewall by using the following command: $ sudo systemctl enable ufw.service If the Uncomplicated Firewall is not currently running on the system, start it with the following command: $ sudo systemctl start ufw.service
Verify the system commands contained in the following directories have mode 0755 or less permissive: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Check that the system command files have mode 0755 or less permissive with the following command: $ sudo find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -perm /022 -type f -exec stat -c "%n %a" '{}' \; If any files are found to be group-writable or world-writable, this is a finding.
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: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Use the following command for the check: $ sudo find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -user root -type f -exec stat -c "%n %U" '{}' \; If any system commands are returned and are not owned by a required system account, this is a finding.
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: /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin Run the check with the following command: $ sudo find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -group root -type f ! -perm /2000 -exec stat -c "%n %G" '{}' \; If any system commands are returned that are not Set Group ID upon execution (SGID) files and group-owned by a required system account, this is a finding.
Configure the system commands to be protected from unauthorized access. Run the following command, replacing "[FILE]" with any system command file not group-owned by "root" or a required system account: $ sudo chgrp root [FILE]
Verify the Ubuntu operating system is not configured to reboot the system when Ctrl-Alt-Delete is pressed when using a graphical user interface. Check that the "logout" target is not bound to an action with the following command: # grep logout /etc/dconf/db/local.d/* logout='' If the "logout" key is bound to an action, is commented out, or is missing, this is a finding.
Configure the system to disable the Ctrl-Alt-Delete sequence when using a graphical user interface by creating or editing the /etc/dconf/db/local.d/00-disable-CAD file. Add the setting to disable the Ctrl-Alt-Delete sequence for the graphical user interface: [org/gnome/settings-daemon/plugins/media-keys] logout='' Update the dconf settings: # dconf update
Verify the Ubuntu operating system is not configured to reboot the system when Ctrl-Alt-Delete is pressed. Check that the "ctrl-alt-del.target" (otherwise also known as reboot.target) is not active with the following command: $ sudo systemctl status ctrl-alt-del.target ctrl-alt-del.target Loaded: masked (Reason: Unit ctrl-alt-del.target is masked.) Active: inactive (dead) If the "ctrl-alt-del.target" is not masked, this is a finding.
Configure the system to disable the Ctrl-Alt-Delete sequence for the command line with the following commands: $ sudo systemctl disable ctrl-alt-del.target $ sudo systemctl mask ctrl-alt-del.target Reload the daemon to take effect: $ sudo systemctl daemon-reload
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 that null passwords cannot be used, run the following command: $ sudo grep nullok /etc/pam.d/* If this produces any output, it may be possible to log on with accounts with empty passwords. If null passwords can be used, this is a finding.
If an account is configured for password authentication but does not have an assigned password, it may be possible to log on to the account without authenticating. Remove any instances of the "nullok" option in "/etc/pam.d/common-password" to prevent logons with empty passwords.
Verify that Ubuntu operating system disables ability to load the USB storage kernel module. # grep usb-storage /etc/modprobe.d/* | grep "/bin/false" install usb-storage /bin/false If the command does not return any output, or the line is commented out, this is a finding. Verify the operating system disables the ability to use USB mass storage device. # grep usb-storage /etc/modprobe.d/* | grep -i "blacklist" blacklist usb-storage If the command does not return any output, or the line is commented out, this is a finding.
Configure the Ubuntu operating system to disable using the USB storage kernel module. Create a file under "/etc/modprobe.d" to contain the following: # sudo su -c "echo install usb-storage /bin/false >> /etc/modprobe.d/DISASTIG.conf" Configure the operating system to disable the ability to use USB mass storage devices. # sudo su -c "echo blacklist usb-storage >> /etc/modprobe.d/DISASTIG.conf"
Note: This requirement is Not Applicable for systems that do not have physical wireless network radios. Verify that 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 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 <interface name> For each interface listed, find their respective module with the following command: $ basename $(readlink -f /sys/class/net/<interface name>/device/driver) where <interface name> must be substituted by the actual interface name. Create a file in the "/etc/modprobe.d" directory and for each module, add the following line: install <module name> /bin/false For each module from the system, execute the following command to remove it: $ sudo modprobe -r <module name>
Verify the SSH server is configured to use only FIPS-validated key exchange algorithms: $ sudo /usr/sbin/sshd -dd 2>&1 | awk '/filename/ {print $4}' | tr -d '\r' | tr '\n' ' ' | xargs sudo grep -iH '^\s*kexalgorithms' KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256 If "KexAlgorithms" is not configured, is commented out, or does not contain only the algorithms "ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256" in exact order, this is a finding.
Configure the SSH server to use only FIPS-validated key exchange algorithms by adding or modifying the following line in "/etc/ssh/sshd_config": KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256 Restart the "sshd" service for changes to take effect: $ sudo systemctl restart sshd
Verify the operating system is configured to restrict access to the kernel message buffer with the following commands: $ sudo sysctl kernel.dmesg_restrict kernel.dmesg_restrict = 1 If "kernel.dmesg_restrict" is not set to "1" or is missing, this is a finding. Check that the configuration files are present to enable this kernel parameter: $ 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.conf:kernel.dmesg_restrict = 1 /etc/sysctl.d/99-sysctl.conf:kernel.dmesg_restrict = 1 If "kernel.dmesg_restrict" is not set to "1", is missing or commented out, this is a finding. If conflicting results are returned, this is a finding.
Configure the operating system 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