Canonical Ubuntu 16.04 Security Technical Implementation Guide

V1R2 2019-03-13       U_Canonical_Ubuntu_16-04_LTS_STIG_V1R2_Manual-xccdf.xml
V1R1 2018-07-18       U_Canonical_Ubuntu_16-04_LTS_STIG_V1R1_Manual-xccdf.xml
This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: [email protected]
Comparison
All 231
No Change 166
Updated 63
Added 1
Removed 1
V-75389 No Change
Findings ID: UBTU-16-010000 Rule ID: SV-90069r1_rule Severity: high CCI: CCI-001230

Discussion

An Ubuntu operating system release is considered "supported" if the vendor continues to provide security patches for the product. With an unsupported release, it will not be possible to resolve security issues discovered in the system software.

Checks

Verify the version of the Ubuntu operating system is vendor supported.

Check the version of the Ubuntu operating system with the following command:

# cat /etc/lsb-release

DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.1 LTS"

Current End of Life for Ubuntu 16.04 LTS is April 2021.

If the release is not supported by the vendor, this is a finding.

Fix

Upgrade to a supported version of the Ubuntu operating system.
V-75391 Updated
Findings ID: UBTU-16-010010 Rule ID: SV-90071r45_rule Severity: medium CCI: CCI-000366

Discussion

Timely patching is critical for maintaining the operational availability, confidentiality, and integrity of information technology (IT) systems. However, failure to keep Ubuntu operating system and application software patched is a common mistake made by IT professionals. New patches are released daily, and it is often difficult for even experienced System Administrators to keep abreast of all the new patches. When new weaknesses in an Ubuntu operating system exist, patches are usually made available by the vendor to resolve the problems. If the most recent security patches and updates are not installed, unauthorized users may take advantage of weaknesses in the unpatched software. The lack of prompt attention to patching could result in a system compromise.

Checks

Verify the Ubuntu operating system security patches and updates are installed and up to date. Updates are required to be applied with a frequency determined by the site or Program Management Office (PMO).

Obtain the list of available package security updates from Ubuntu. The URL for updates is https://www.Ubuntu.com/usn/. It is important to note that updates provided by Ubuntu may not be present on the system if the underlying packages are not installed.

Check that the available package security updates have been installed on the system with the following command:

# /usr/lib/update-notifier/apt-check --human-readable

246 packages can be updated.
0 updates are security updates.

If security package updates have not been performed on the system within the timeframe that the site/program documentation requires, this is a finding.

Typical update frequency may be overridden by Information Assurance Vulnerability Alert (IAVA) notifications from JFHQ-DoDIN.

If the Ubuntu operating system is in non-compliance with the Information Assurance Vulnerability Management (IAVM) process, this is a finding.

Fix

Install the Ubuntu operating system patches or updated packages available from Canonical within 30 days or sooner as local policy dictates.
V-75393 Updated
Findings ID: UBTU-16-010020 Rule ID: SV-90073r23_rule Severity: medium CCI: CCI-000048

Discussion

Display of a standardized and approved use notification before granting access to the Ubuntu operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.

The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for Ubuntu operating systems that can accommodate banners of 1300 characters:

"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.

By using this IS (which includes any device attached to this IS), you consent to the following conditions:

-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

-At any time, the USG may inspect and seize data stored on this IS.

-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.

-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."

Use the following verbiage for Ubuntu operating systems that have severe limitations on the number of characters that can be displayed in the banner:

"I've read & consent to terms in IS user agreem't."

Satisfies: SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088

Checks

Verify the Ubuntu operating system security patches and updates are installed and up to date. Updates are required to be applied with a frequency determined by the site or Program Management Office (PMO).

Obtain the list of available package security updates from Ubuntu. The URL for updates is https://www.Ubuntu.com/usn/. It is important to note that updates provided by Ubuntu may not be present on the system if the underlying packages are not installed.

Check that the available package security updates have been installed on the system with the following command:

# /usr/lib/update-notifier/apt-check --human-readable

246 packages can be updated.
0 updates are security updates.

If security package updates have not been performed on the system within the timeframe that the site/program documentation requires, this is a finding.

Typical update frequency may be overridden by Information Assurance Vulnerability Alert (IAVA) notifications from JFHQ-DoDIN.

If the Ubuntu operating system is in non-compliance with the Information Assurance Vulnerability Management (IAVM) process
displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the Ubuntu operating system via a Gnome graphical user logon.

Note: If the system does not have a graphical user logon this item is Not Applicable.

Note: If the system is using lightdm, this is a finding. There is no greater configuration that can be applied to meet the requirement.

Check that the Ubuntu operating system displays a banner at the logon screen with the following command:

# grep banner-message-enable /etc/dconf/db/local.d/*
banner-message-enable=true

If "banner-message-enable" is not set to "true", is missing, set to "false", or is commented out
, this is a finding.

Fix

Configure the Ubuntu operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system.

Create a database that will contain the system wide graphical user logon settings (if it does not already exist) with the following command:

# sudo touch /etc/dconf/db/local.d/01-banner-message

Add the following line to the "[org/gnome/login-screen]" section of the "/etc/dconf/db/local.d/01-banner-message" file:

[org/gnome/login-screen]
banner-message-enable=true
V-75435 Updated
Findings ID: UBTU-16-010030 Rule ID: SV-90115r23_rule Severity: medium CCI: CCI-000048

Discussion

Display of a standardized and approved use notification before granting access to the Ubuntu operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.

The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for Ubuntu operating systems
that can accommodate banners of 1300 characters:

"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.

By using this IS (which includes any device attached to this IS), you consent to the following conditions:

-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

-At any time, the USG may inspect and seize data stored on this IS.

-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.

-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."


Use the following verbiage for Ubuntu operating systems that have severe limitations on the number of characters that can be displayed in the banner:

"I've read & consent to terms in IS user agreem't."

Satisfies: SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088

Checks

Verify the Ubuntu operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the Ubuntu operating system via a command line user logon.

Check that the Ubuntu operating system displays a banner at the command line login screen with the following command:

# cat /etc/issue

If the banner is set correctly it will return the following text:

“You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.

By using this IS (which includes any device attached to this IS), you consent to the following conditions:

-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

-At any time, the USG may inspect and seize data stored on this IS.

-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.

-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.”

If the banner text does not match the Standard Mandatory DoD Notice and Consent Banner exactly, this is a finding.

Fix

Configure the Ubuntu operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system via command line logon.

Edit the "/etc/issue" file to replace the default text with the Standard Mandatory 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."
V-75437 No Change
Findings ID: UBTU-16-010040 Rule ID: SV-90117r3_rule Severity: medium CCI: CCI-000056

Discussion

A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence.

The session lock is implemented at the point where session activity can be determined.

Regardless of where the session lock is determined and implemented, once invoked, the session lock shall remain in place until the user re-authenticates. No other activity aside from re-authentication shall unlock the system.

Checks

Verify the operating system allows a user to lock the current graphical user interface (GUI) session.

Note: If the Ubuntu operating system does not have GNOME installed, this requirement is Not Applicable.

Check to see if the Ubuntu operating system allows the user to lock the current GUI session with the following command:

# gsettings get org.gnome.desktop.lock-enabled

true

If "lock-enabled" is not set to "true", this is a finding.

Fix

Configure the Ubuntu operating system so that it allows a user to lock the current GUI session.

Note: If the Ubuntu operating system does not have GNOME installed, this requirement is Not Applicable.

Set the "lock-enabled" setting in GNOME to allow GUI session locks with the following command:

Note: The command must be performed from a terminal window inside the graphical user interface (GUI).

# sudo gsettings set org.gnome.desktop.lock-enabled true
V-75439 No Change
Findings ID: UBTU-16-010050 Rule ID: SV-90119r2_rule Severity: medium CCI: CCI-000056

Discussion

A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence.

The session lock is implemented at the point where session activity can be determined. Rather than be forced to wait for a period of time to expire before the user session can be locked, Ubuntu operating systems need to provide users with the ability to manually invoke a session lock so users may secure their session should the need arise for them to temporarily vacate the immediate physical vicinity.

Satisfies: SRG-OS-000028-GPOS-00009, SRG-OS-000030-GPOS-00011, SRG-OS-000031-GPOS-00012

Checks

Verify the Ubuntu operating system has the 'vlock' package installed, by running the following command:

# dpkg -l | grep vlock

vlock_2.2.2-7

If "vlock" is not installed, this is a finding.

Fix

Install the "vlock" (if it is not already installed) package by running the following command:

# sudo apt-get install vlock
V-75441 No Change
Findings ID: UBTU-16-010060 Rule ID: SV-90121r2_rule Severity: medium CCI: CCI-000057

Discussion

An Ubuntu operating system needs to be able to identify when a user's sessions has idled for longer than 15 minutes. The Ubuntu operating system must logout a users' session after 15 minutes to prevent anyone from gaining access to the machine while the user is away.

Checks

Verify the Ubuntu operating system initiates a session logout after a "15" minutes of inactivity.

Check that the proper auto logout script exists with the following command:

# cat /etc/profile.d/autologout.sh
TMOUT=900
readonly TMOUT
export TMOUT

If the file "/etc/profile.d/autologout.sh" does not exist, the timeout values are commented out, the output from the function call are not the same, this is a finding.

Fix

Configure the Ubuntu operating system to initiate a session logout after a "15" minutes of inactivity.

Create a file to contain the system-wide session auto logout script (if it does not already exist) with the following command:

# sudo touch /etc/profile.d/autologout.sh

Add the following lines to the "/etc/profile.d/autologout.sh" script:

TMOUT=900
readonly TMOUT
export TMOUT
V-75443 No Change
Findings ID: UBTU-16-010070 Rule ID: SV-90123r2_rule Severity: low CCI: CCI-000054

Discussion

Ubuntu operating system management includes the ability to control the number of users and user sessions that utilize an Ubuntu operating system. Limiting the number of allowed users and sessions per user is helpful in reducing the risks related to DoS attacks.

This requirement addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions should be defined based upon mission needs and the operational environment for each system.

Checks

Verify that 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

The result must contain the following line:

* hard maxlogins 10

If the "maxlogins" item is missing or the value is not set to "10" or less, or is commented out, this is a finding.

Fix

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

Add the following line to the top of the /etc/security/limits.conf:

* hard maxlogins 10
V-75445 No Change
Findings ID: UBTU-16-010080 Rule ID: SV-90125r3_rule Severity: medium CCI: CCI-000770

Discussion

To assure individual accountability and prevent unauthorized access, organizational users must be individually identified and authenticated.

A group authenticator is a generic account used by multiple individuals. Use of a group authenticator alone does not uniquely identify individual users. Examples of the group authenticator is the UNIX OS "root" user account, the Windows "Administrator" account, the "sa" account, or a "helpdesk" account.

For example, the UNIX and Windows operating systems offer a 'switch user' capability allowing users to authenticate with their individual credentials and, when needed, 'switch' to the administrator role. This method provides for unique individual authentication prior to using a group authenticator.

Users (and any processes acting on behalf of users) need to be uniquely identified and authenticated for all accesses other than those accesses explicitly identified and documented by the organization, which outlines specific user actions that can be performed on the Ubuntu operating system without identification or authentication.

Requiring individuals to be authenticated with an individual authenticator prior to using a group authenticator allows for traceability of actions, as well as adding an additional level of protection of the actions that can be taken with group account knowledge.

Checks

Verify the Ubuntu operating system prevents direct logins to the root account.

Check that the Ubuntu operating system prevents direct logins to the root account with the following command:

# grep root /etc/shadow

root L 11/11/2017 0 99999 7 -1

If any output is returned and the second field is not an "L", this is a finding.

Fix

Configure the Ubuntu operating system to prevent direct logins to the root account.

Run the following command to lock the root account:

# passwd -l root
V-75449 Updated
Findings ID: UBTU-16-010100 Rule ID: SV-90129r23_rule Severity: medium CCI: CCI-000192

Discussion

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Checks

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"
or "/etc/pwquality.conf.d/*.conf" files with the following command:

# grep -i "ucredit" /etc/security/pwquality.conf
/etc/pwquality.conf.d/*.conf
ucredit=-1

If the "ucredit" parameter is not equal to "-1", or is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to enforce password complexity by requiring that at least one upper-case character be used.

Add or update the following line in the "/etc/security/pwquality.conf" file
or a configuration file in the /etc/pwquality.conf.d/ directory to contain the "ucredit" parameter:

ucredit=-1
V-75451 Updated
Findings ID: UBTU-16-010110 Rule ID: SV-90131r23_rule Severity: medium CCI: CCI-000193

Discussion

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Checks

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"
or "/etc/pwquality.conf.d/*.conf" files with the following command:

# grep -i "lcredit" /etc/security/pwquality.conf
/etc/pwquality.conf.d/*.conf
lcredit=-1

If the "lcredit" parameter is not equal to "-1", or is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to enforce password complexity by requiring that at least one lower-case character be used.

Add or update the following line in the "/etc/security/pwquality.conf" file
or a configuration file in the /etc/pwquality.conf.d/ directory to contain the "lcredit" parameter:

lcredit=-1
V-75453 Updated
Findings ID: UBTU-16-010120 Rule ID: SV-90133r23_rule Severity: medium CCI: CCI-000194

Discussion

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Checks

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"
or "/etc/pwquality.conf.d/*.conf" files with the following command:

# grep -i "dcredit" /etc/security/pwquality.conf
etc/pwquality.conf.d/*.conf
dcredit=-1

If the "dcredit" parameter is not equal to "-1", or is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to enforce password complexity by requiring that at least one numeric character be used.

Add or update the following line in the "/etc/security/pwquality.conf" file
or a configuration file in the /etc/pwquality.conf.d/ directory to contain the "dcredit" parameter:

dcredit=-1
V-75455 Updated
Findings ID: UBTU-16-010130 Rule ID: SV-90135r23_rule Severity: medium CCI: CCI-001619

Discussion

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor in determining how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Special characters are those characters that are not alphanumeric. Examples include: ~ ! @ # $ % ^ *.

Checks

Verify the Ubuntu operating system enforces password complexity by requiring that at least one special character be used.

Determine if the field "ocredit" is set in the "/etc/security/pwquality.conf" file
or "/etc/pwquality.conf.d/*.conf" files with the following command:

# grep -i "ocredit" /etc/security/pwquality.conf
/etc/pwquality.conf.d/*.conf
ocredit=-1

If the "ocredit" parameter is not equal to "-1", or is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to enforce password complexity by requiring that at least one special character be used.

Add or update the following line in the "/etc/security/pwquality.conf" file
or a configuration file in the /etc/pwquality.conf.d/ directory to contain the "ocredit" parameter:

ocredit=-1
V-75457 Updated
Findings ID: UBTU-16-010140 Rule ID: SV-90137r23_rule Severity: medium CCI: CCI-000195

Discussion

If the Ubuntu operating system allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks.

The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different.

If the password length is an odd number then number of changed characters must be rounded up. For example, a password length of 15 characters must require the change of at least 8 characters.

Checks

Verify the Ubuntu operating system requires the change of at least "8" characters when passwords are changed.

Determine if the field "difok" is set in the "/etc/security/pwquality.conf"
or "/etc/pwquality.conf.d/*.conf" files with the following command:

# grep -i "difok" /etc/security/pwquality.conf
/etc/pwquality.conf.d/*.conf
difok=8

If the "difok" parameter is less than "8", or is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to require the change of at least "8" characters when passwords are changed.

Add or update the following line in the "/etc/security/pwquality.conf"
or "/etc/pwquality.conf.d/*.conf" files to include the "difok=8" parameter:

difok=8
V-75459 No Change
Findings ID: UBTU-16-010150 Rule ID: SV-90139r1_rule Severity: medium CCI: CCI-000196

Discussion

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised.

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised.

FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoD requirements.

Satisfies: SRG-OS-000073-GPOS-00041, SRG-OS-000120-GPOS-00061

Checks

Verify that the shadow password suite configuration is set to encrypt password 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 crypt

ENCRYPT_METHOD SHA512

If "ENCRYPT_METHOD" does not equal SHA512 or greater, this is a finding.

Fix

Configure the Ubuntu operating system to encrypt all stored passwords.

Edit/Modify the following line in the "/etc/login.defs" file and set "[ENCRYPT_METHOD]" to SHA512.

ENCRYPT_METHOD SHA512
V-75461 No Change
Findings ID: UBTU-16-010160 Rule ID: SV-90141r1_rule Severity: medium CCI: CCI-000196

Discussion

The system must use a strong hashing algorithm to store the password. The system must use a sufficient number of hashing rounds to ensure the required level of entropy.

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised.

Satisfies: SRG-OS-000073-GPOS-00041, SRG-OS-000120-GPOS-00061

Checks

Verify the shadow password suite configuration is set to encrypt interactive user passwords using a strong cryptographic hash with the following command:

Confirm that the interactive user account passwords are using a strong password hash with the following command:

# sudo cut -d: -f2 /etc/shadow

$6$kcOnRq/5$NUEYPuyL.wghQwWssXRcLRFiiru7f5JPV6GaJhNC2aK5F3PZpE/BCCtwrxRc/AInKMNX3CdMw11m9STiql12f/

Password hashes "!" or "*" indicate inactive accounts not available for logon and are not evaluated. If any interactive user password hash does not begin with "$6", this is a finding.

Fix

Configure the Ubuntu operating system to encrypt all stored passwords with a strong cryptographic hash.

Lock all interactive user accounts not using SHA-512 hashing until the passwords can be regenerated.
V-75463 No Change
Findings ID: UBTU-16-010170 Rule ID: SV-90143r2_rule Severity: medium CCI: CCI-000196

Discussion

The system must use a strong hashing algorithm to store the password. The system must use a sufficient number of hashing rounds to ensure the required level of entropy.

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised.

Satisfies: SRG-OS-000073-GPOS-00041, SRG-OS-000120-GPOS-00061

Checks

Verify the shadow password suite configuration is set to create passwords using a strong cryptographic hash with the following command:

Check that a minimum number of hash rounds is configured by running the following command:

# grep rounds /etc/pam.d/common-password

password [success=1 default=ignore] pam_unix.so obscure sha512 rounds=5000

If "rounds" has a value below "5000", or is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to encrypt all stored passwords with a strong cryptographic hash.

Edit/modify the following line in the "/etc/pam.d/common-password" file and set "rounds" to a value no lower than "5000":

password [success=1 default=ignore] pam_unix.so obscure sha512 rounds=5000
V-75465 No Change
Findings ID: UBTU-16-010180 Rule ID: SV-90145r2_rule Severity: medium CCI: CCI-000803

Discussion

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore cannot be relied upon to provide confidentiality or integrity, and DoD data may be compromised.

Ubuntu operating systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules.

FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets DoD requirements. This allows for Security Levels 1, 2, 3, or 4 for use on a general purpose computing system.

Checks

Verify that pam_unix.so auth is configured to use sha512.

Check that pam_unix.so auth is configured to use sha512 with the following command:

# grep password /etc/pam.d/common-password | grep pam_unix

password [success=1 default=ignore] pam_unix.so obscure sha512

If "sha512" is not an option of the output, or is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to use a FIPS 140-2 approved cryptographic hashing algorithm for system authentication.

Edit/modify the following line in the file "/etc/pam.d/common-password" file to include the sha512 option for pam_unix.so:

password [success=1 default=ignore] pam_unix.so obscure sha512 shadow remember=5
V-75469 No Change
Findings ID: UBTU-16-010200 Rule ID: SV-90149r1_rule Severity: medium CCI: CCI-001682

Discussion

Emergency accounts are privileged accounts that are established in response to crisis situations where the need for rapid account activation is required. Therefore, emergency account activation may bypass normal account authorization processes. If these accounts are automatically disabled, system maintenance during emergencies may not be possible, thus adversely affecting system availability.

Emergency accounts are different from infrequently used accounts (i.e., local logon accounts used by the organization's system administrators when network or normal logon/access is not available). Infrequently used accounts are not subject to automatic termination dates. Emergency accounts are accounts created in response to crisis situations, usually for use by maintenance personnel. The automatic expiration or disabling time period may be extended as needed until the crisis is resolved; however, it must not be extended indefinitely. A permanent account should be established for privileged users who need long-term maintenance accounts.

To address access requirements, many Ubuntu operating systems can be integrated with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements.

Checks

Verify the Ubuntu operating system is configured such that the emergency administrator account is never automatically removed or disabled.

Check to see if the root account password or account expires with the following command:

# sudo chage -l root

Password expires :never

If "Password expires" or "Account expires" is set to anything other than "never", this is a finding.

Fix

Replace "[Emergency_Administrator]" in the following command with the correct emergency administrator account. Run the following command as an administrator:

# sudo chage -I -1 -M 99999 [Emergency_Administrator]
V-75471 No Change
Findings ID: UBTU-16-010210 Rule ID: SV-90151r2_rule Severity: medium CCI: CCI-000198

Discussion

Enforcing a minimum password lifetime helps to prevent repeated password changes to defeat the password reuse or history enforcement requirement. If users are allowed to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.

Checks

Verify that 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 or equal to "1", or commented out, this is a finding.

Fix

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
V-75473 No Change
Findings ID: UBTU-16-010220 Rule ID: SV-90153r2_rule Severity: medium CCI: CCI-000199

Discussion

Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If the Ubuntu operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the Ubuntu operating system passwords could be compromised.

Checks

Verify that 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 less than "60", or commented out, this is a finding.

Fix

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
V-75475 No Change
Findings ID: UBTU-16-010230 Rule ID: SV-90155r2_rule Severity: medium CCI: CCI-000200

Discussion

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

Checks

Verify that 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 remember=5 rounds=5000

If the "remember" parameter value is not greater than or equal to "5", is commented out, or is not set at all this is a finding.

Fix

Configure the Ubuntu operating system prevents 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 remember=5 rounds=5000
V-75477 Updated
Findings ID: UBTU-16-010240 Rule ID: SV-90157r23_rule Severity: medium CCI: CCI-000205

Discussion

The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.

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

Checks

Verify that the Ubuntu operating system enforces a minimum "15" character password length, by running.

Determine if the field "minlen" is set in the "/etc/security/pwquality.conf" or "/etc/pwquality.conf.d/*.conf" files with
the following command:

# grep -i minlen /etc/security/pwquality.conf
/etc/pwquality.conf.d/*.conf
minlen=15

If "minlen" parameter value is not "15" or higher, or is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to enforce a minimum 15-character password length.

Add
, or modify the "minlen" parameter value to the following line in "/etc/security/pwquality.conf" fileupdate the following line in the "/etc/security/pwquality.conf" file or a configuration file in the /etc/pwquality.conf.d/ directory to contain the "minlen" parameter:

minlen=15
V-75479 No Change
Findings ID: UBTU-16-010250 Rule ID: SV-90159r1_rule Severity: high CCI: CCI-000366

Discussion

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

Checks

To verify that null passwords cannot be used, run the following command:

# grep pam_unix.so /etc/pam.d/* | grep nullok
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.

Fix

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 files under "/etc/pam.d/" to prevent logons with empty passwords.
V-75481 Updated
Findings ID: UBTU-16-010260 Rule ID: SV-90161r34_rule Severity: medium CCI: CCI-000366

Discussion

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

Checks

Verify the Ubuntu operating system prevents the use of dictionary words for passwords.

Check that the Ubuntu operating system uses the cracklib library to prevent the use of dictionary wordDetermine if the field "dictcheck" is set in the "/etc/security/pwquality.conf" or "/etc/pwquality.conf.d/*.conf" files with the following command:

# grep dictcheck /etc/security/pwquality.conf
/etc/pwquality.conf.d/*.conf

dictcheck=1

If the "dictcheck" parameter is not set to "1", or is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to prevent the use of dictionary words for passwords.

Edit the file "/etc/security/pwquality.conf" by adding a line such as: Add or update the following line in the "/etc/security/pwquality.conf" file or a configuration file in the /etc/pwquality.conf.d/ directory to contain the "dictcheck" parameter:

dictcheck=1
V-75483 No Change
Findings ID: UBTU-16-010270 Rule ID: SV-90163r1_rule Severity: medium CCI: CCI-000366

Discussion

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

Checks

Verify the "passwd" command uses the common-password settings.

Check that the "passwd" command uses the common-password option with the following command:

# grep common-password /etc/pam.d/passwd

@ include common-password

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to prevent the use of dictionary words for passwords.

Edit the file "/etc/pam.d/passwd" and add the following line:

@ include common-password
V-75485 No Change
Findings ID: UBTU-16-010280 Rule ID: SV-90165r3_rule Severity: medium CCI: CCI-000795

Discussion

Inactive identifiers pose a risk to systems and applications because attackers may exploit an inactive identifier and potentially obtain undetected access to the system. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained.

Ubuntu operating systems need to track periods of inactivity and disable application identifiers after 35 days of inactivity.

Checks

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 -i inactive /etc/default/useradd

INACTIVE=35

If "INACTIVE" is not set to a value "0<[VALUE]<=35", or is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to disable account identifiers after 35 days of inactivity after the password expiration.

Run the following command to change the configuration for useradd:

# sudo useradd -D -f 35

DoD recommendation is 35 days, but a lower value is acceptable. The value "-1" will disable this feature, and "0" will disable the account immediately after the password expires.
V-75487 Updated
Findings ID: UBTU-16-010290 Rule ID: SV-90167r23_rule Severity: medium CCI: CCI-000044

Discussion

By limiting the number of failed logon attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account.

Satisfies: SRG-OS-000021-GPOS-00005, SRG-OS-000329-GPOS-00128

Checks

Verify the Ubuntu operating system automatically locks an account until the account lock is released by an administrator when three unsuccessful logon attempts are made.

Check that the Ubuntu operating system automatically locks an account after three unsuccessful attempts with the following command:

# grep pam_tally /etc/pam.d/common-auth

auth required pam_tally2.so onerr=fail deny=3

If "onerr=fail deny=3" is not used in "/etc/pam.d/common-auth" or is called with "unlock_time", this is a finding.

Fix

Configure the Ubuntu operating system to automatically lock an account until the locked account is released by an administrator when three unsuccessful logon attempts are made by appending the following line to the "/etc/pam.d/common-auth file":

"auth required pam_tally2.so onerr=fail deny=3"
V-75489 No Change
Findings ID: UBTU-16-010300 Rule ID: SV-90169r2_rule Severity: medium CCI: CCI-002038

Discussion

Without re-authentication, users may access resources or perform tasks for which they do not have authorization.

When Ubuntu operating systems provide the capability to escalate a functional capability or change security roles, it is critical the user re-authenticate.

Satisfies: SRG-OS-000373-GPOS-00156, SRG-OS-000373-GPOS-00157

Checks

Verify that "/etc/sudoers" has no occurrences of "NOPASSWD" or "!authenticate".

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

%wheel ALL=(ALL) NOPASSWD: ALL

If any occurrences of "NOPASSWD" or "!authenticate" return from the command, this is a finding.

Fix

Remove any occurrence of "NOPASSWD" or "!authenticate" found in "/etc/sudoers" file or files in the "/etc/sudoers.d" directory.
V-75491 No Change
Findings ID: UBTU-16-010310 Rule ID: SV-90171r1_rule Severity: medium CCI: CCI-000016

Discussion

If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary accounts must be set upon account creation.

Temporary accounts are established as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation.

If temporary accounts are used, the Ubuntu operating system must be configured to automatically terminate these types of accounts after a DoD-defined time period of 72 hours.

To address access requirements, many Ubuntu operating systems may be integrated with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements.

Checks

Verify that temporary accounts have been provisioned with an expiration date for 72 hours.

For every existing temporary account, run the following command to obtain its account expiration information.

# sudo chage -l system_account_name

Verify each of these accounts has an expiration date set within 72 hours.
If any temporary accounts have no expiration date set or do not expire within 72 hours, this is a finding.

Fix

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" +%Y-%m-%d` system_account_name
V-75493 No Change
Findings ID: UBTU-16-010320 Rule ID: SV-90173r1_rule Severity: medium CCI: CCI-000366

Discussion

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

Checks

Verify the Ubuntu operating system enforces a delay of at least 4 seconds between logon prompts following a failed logon attempt.

Check that the Ubuntu operating system enforces a delay of at least 4 seconds between logon prompts with the following command:

# grep pam_faildelay /etc/pam.d/common-auth*

auth required pam_faildelay.so delay=4000000

If the line is not present, or is commented out, this is a finding.

Fix

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
V-75495 Updated
Findings ID: UBTU-16-010330 Rule ID: SV-90175r23_rule Severity: high CCI: CCI-000366

Discussion

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

Checks

Verify that unattended or automatic login via the GUI is disabled.

Check that unattended or automatic login is disabled with the following command:

# sudo grep -i auto
maticloginenable /etc/gdm3/custologin-user /etc/lightdm/lightdm.conf

AautomaticLoginEnable=falselogin-user=<username>
autologin-user-timeout=0


If the "
AautomaticLoginEnable" parameter is not set to "false"login-user" parameter is blank, or is commented out, this is a finding.
If the "autologin-user-timeout" parameter is not 0
, or is commented out, this is a finding.

Fix

Configure the GUI to not allow unattended or automatic login to the system.

Add or ediComment the following lines in the "/etc/gdm3/custom.conf" file directly below the "[daemon]" tag:

AutomaticLoginEnable=false
lightdm/lightdm.conf" file:

#autologin-user=<username>
#autologin-user-timeout=0
V-75497 No Change
Findings ID: UBTU-16-010340 Rule ID: SV-90177r1_rule Severity: low CCI: CCI-000366

Discussion

Providing users with feedback on when account accesses last occurred facilitates user recognition and reporting of unauthorized account use.

Checks

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, or the "silent" option is present, this is a finding.

Fix

Configure the Ubuntu operating system to provide users with feedback on when account accesses last occurred by setting the required configuration options in "/etc/pam.d/postlogin-ac".

Add the following line to the top of "/etc/pam.d/login":

session required pam_lastlog.so showfailed
V-75499 No Change
Findings ID: UBTU-16-010350 Rule ID: SV-90179r1_rule Severity: high CCI: CCI-000366

Discussion

The .shosts files are used to configure host-based authentication for individual users or the system via SSH. Host-based authentication is not sufficient for preventing unauthorized access to the system, as it does not require interactive identification and authentication of a connection request, or for the use of two-factor authentication.

Checks

Verify there are no ".shosts" files on the Ubuntu operating system.

Check the system for the existence of these files with the following command:

# sudo find / -name '*.shosts'

If any ".shosts" files are found, this is a finding.

Fix

Remove any found ".shosts" files from the Ubuntu operating system.

# rm /[path]/[to]/[file]/.shosts
V-75501 No Change
Findings ID: UBTU-16-010360 Rule ID: SV-90181r2_rule Severity: high CCI: CCI-000366

Discussion

The shosts.equiv files are used to configure host-based authentication for the system via SSH. Host-based authentication is not sufficient for preventing unauthorized access to the system, as it does not require interactive identification and authentication of a connection request, or for the use of two-factor authentication.

Checks

Verify there are no "shosts.equiv" files on the Ubuntu operating system.

Check for the existence of these files with the following command:

# find / -name shosts.equiv

If a "shosts.equiv" file is found, this is a finding.

Fix

Remove any found "shosts.equiv" files from the Ubuntu operating system.

# rm /etc/ssh/shosts.equiv
V-75503 Updated
Findings ID: UBTU-16-010370 Rule ID: SV-90183r12_rule Severity: high CCI: CCI-002450

Discussion

Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The Ubuntu operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.

Satisfies: SRG-OS-000396-GPOS-00176, SRG-OS-000478-GPOS-00223

Checks

Verify the system is configured to run in FIPS mode.

Check that the system is configured to run in FIPS mode with the following command:

# grep -i 1 /proc/sys/crypto/fips_enabled
1

If a value of "1" is not returned, this is a finding.

Fix

Configure the system to run in FIPS mode. Add "fips=1" to the kernel parameter during the Ubuntu operating systems install.

Note: Enabling a FIPS mode on a pre-existing system involves a number of modifications to the Ubuntu operating system. Refer to the Ubuntu Server 16.04 FIPS 140-2 security policy document for instructions. A subscription to the "Ubuntu Advantage" plan is required in order to obtain the FIPS Kernel cryptographic modules and enable FIPS.
V-75505 Updated
Findings ID: UBTU-16-010380 Rule ID: SV-90185r23_rule Severity: high CCI: CCI-000213

Discussion

To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems (e.g., web servers and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement.

Access control policies include: identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include: access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system.

Checks

Verify that an encrypted root password is set. This is only applicable on systems that use a basic Input/Output System BIOS.

Run the following command to verify the encrypted password is set:

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

Fix

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/10_linux" file with the following command to add a boot password for the root entry:

# cat << EOF >

It will generate a long password encrypted like this:
grub.pbkdf2.sha512.10000.FC58373BCA15A797C418C1EA7FFB007BF5A5

Copy the complete generated code.
Edit the file /etc/grub.d/40_custom (or a custom configuration file in the /etc/grub.d/ directory):

At the end of the file add the following commands:

set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.VeryLongString > EOF

Generate an updated "grub.conf" file with the new password by using the following commands:

# grub2-mkconfig --output=/tmp/grub2.cfg
# mv /tmp/grub2.cfg /boot/grub2/grub.cfg
10000.LONGSTRING

Save the file and exit
Run: sudo update-grub
Reboot
V-75507 No Change
Findings ID: UBTU-16-010390 Rule ID: SV-90187r2_rule Severity: high CCI: CCI-000213

Discussion

To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DoD-approved PKIs, all DoD systems (e.g., web servers and web portals) must be properly configured to incorporate access control methods that do not rely solely on the possession of a certificate for access. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement.

Access control policies include: identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include: access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system.

Checks

Verify that an encrypted root password is set. This is only applicable on Ubuntu operating systems that use UEFI.

Run the following command to verify the encrypted password is set:

# grep –i password /boot/efi/EFI/grub.cfg
password_pbkdf2 root grub.pbkdf2.sha512.10000.VeryLongString

If the root password entry does not begin with “password_pbkdf2”, this is a finding.

Fix

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/10_linux" file with the following command to add a boot password for the root entry:

# cat << EOF > set superusers="root" password_pbkdf2 root grub.pbkdf2.sha512.VeryLongString > EOF

Generate an updated "grub.conf" file with the new password using the following commands:

# grub-mkconfig --output=/tmp/grub2.cfg
# mv /tmp/grub2.cfg /boot/efi/EFI/grub.cfg
V-75509 No Change
Findings ID: UBTU-16-010400 Rule ID: SV-90189r1_rule Severity: high CCI: CCI-001199

Discussion

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

Selection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields).

Satisfies: SRG-OS-000185-GPOS-00079, SRG-OS-000404-GPOS-00183, SRG-OS-000405-GPOS-00184

Checks

Verify the Ubuntu operating system prevents unauthorized disclosure or modification of all information requiring at rest protection by using disk encryption.

If there is a documented and approved reason for not having data-at-rest encryption, this requirement is Not Applicable.

Determine the partition layout for the system with the following command:

# fdisk –l

Verify that the system partitions are all encrypted with the following command:

# more /etc/crypttab

Every persistent disk partition present must have an entry in the file. If any partitions other than pseudo file systems (such as /proc or /sys) are not listed, this is a finding.

Fix

Configure the Ubuntu operating system to prevent unauthorized modification of all information at rest by using disk encryption.

Encrypting a partition in an already-installed system is more difficult, because you need to resize and change existing partitions. To encrypt an entire partition, dedicate a partition for encryption in the partition layout.
V-75511 No Change
Findings ID: UBTU-16-010410 Rule ID: SV-90191r1_rule Severity: medium CCI: CCI-001090

Discussion

Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection.

This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DoD or other government agencies.

There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components.

Checks

Verify that all public directories are owned by root to prevent unauthorized and unintended information transferred via shared system resources.

Check to see that all public directories have the public sticky bit set by running the following command:

# sudo find / -type d -perm -0002 -exec ls -lLd {} \;

drwxrwxrwxt 7 root root 4096 Jul 26 11:19 /tmp

If any of the returned directories are not owned by root, this is a finding.

Fix

Configure all public directories to be owned by root to prevent unauthorized and unintended information transferred via shared system resources.

Set the owner of all public directories as root using the command, replace "[Public Directory]" with any directory path not owned by root:

# sudo chown root [Public Directory]
V-75513 No Change
Findings ID: UBTU-16-010420 Rule ID: SV-90193r3_rule Severity: medium CCI: CCI-001090

Discussion

If a world-writable directory has the sticky bit set and is not group-owned by a privileged Group Identifier (GID), unauthorized users may be able to modify files created by others.

The only authorized public directories are those temporary directories supplied with the system or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system and by users for temporary file storage, (e.g., /tmp), and for directories requiring global read/write access.

Checks

Verify that all world-writable directories are group-owned by root to prevent unauthorized and unintended information transferred via shared system resources.

Check the system for world-writable directories with the following command:

# sudo find / -type d -perm -0002 -exec ls -lLd {} \;

drwxrwxrwxt 7 root root 4096 Jul 26 11:19 /tmp

If any world-writable directories are not owned by root, sys, bin, or an application group associated with the directory, this is a finding.

Fix

Change the group of the world-writable directories to root, sys, bin, or an application group with the following command, replacing "[world-writable Directory]":

# sudo chgrp root [world-writable Directory]
V-75515 No Change
Findings ID: UBTU-16-010500 Rule ID: SV-90195r3_rule Severity: medium CCI: CCI-002696

Discussion

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

This requirement applies to Ubuntu operating systems performing security function verification/testing and/or systems and environments that require this functionality.

Checks

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 apt list aide

aide/xenial,now 0.16~a2.git20130520-3 amd64 [installed]

If AIDE is not installed, ask the System Administrator how file integrity checks are performed on the system.

If there is no application installed to perform integrity checks, this is a finding.

Fix

Install the AIDE package by running the following command:

# sudo apt-get install aide
V-75517 No Change
Findings ID: UBTU-16-010510 Rule ID: SV-90197r2_rule Severity: medium CCI: CCI-002699

Discussion

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

Notifications provided by information systems include, for example, electronic alerts to system administrators, messages to local computer consoles, and/or hardware indications, such as lights.

This requirement applies to Ubuntu operating systems performing security function verification/testing and/or systems and environments that require this functionality.

Checks

Verify that Advanced Intrusion Detection Environment (AIDE) performs a verification of the operation of security functions every 30 days.

Note: A file integrity tool other than AIDE may be used, but the tool must be executed at least once per week.

Check that AIDE is being executed every 30 days or less with the following command:

# ls -al /etc/cron.daily/aide

-rwxr-xr-x 1 root root 26049 Oct 24 2014 /etc/cron.daily/aide

If the "/etc/cron.daily/aide" file does not exist or the cron job is not configured to run at least every 30 days, this is a finding.

Fix

The cron file for AIDE is fairly complex as it creates the report. The easiest way to create the file is to update the AIDE package with the following command:

# sudo apt-get install aide
V-75519 No Change
Findings ID: UBTU-16-010520 Rule ID: SV-90199r3_rule Severity: low CCI: CCI-000366

Discussion

ACLs can provide permissions beyond those permitted through the file mode and must be verified by file integrity tools.

Checks

Verify the file integrity tool is configured to verify Access Control Lists (ACLs).

Use the following command to determine if the file is in a location other than "/etc/aide/aide.conf":

# find / -name aide.conf

Check the "aide.conf" file to determine if the "acl" rule has been added to the rule list being applied to the files and directories selection lists with the following command:

# egrep "[+]?acl" /etc/aide/aide.conf

VarFile = OwnerMode+n+l+X+acl

If the "acl" rule is not being used on all selection lines in the "/etc/aide.conf" file, is commented out, or ACLs are not being checked by another file integrity tool, this is a finding.

Fix

Configure the file integrity tool to check file and directory ACLs.

If AIDE is installed, ensure the "acl" rule is present on all file and directory selection lists.
V-75521 No Change
Findings ID: UBTU-16-010530 Rule ID: SV-90201r1_rule Severity: low CCI: CCI-000366

Discussion

Extended attributes in file systems are used to contain arbitrary data and file metadata with security implications.

Checks

Verify the file integrity tool is configured to verify extended attributes.

Check to see if Advanced Intrusion Detection Environment (AIDE) is installed with the following command:

# dpkg -l |grep aide

ii aide 0.16~a2.git20130520-3
ii aide-common 0.16~a2.git20130520-3

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.

Note: AIDE is highly configurable at install time. These commands assume the "aide.conf" file is under the "/etc" directory.

Use the following command to determine if the file is in another location:

# find / -name aide.conf

Check the "aide.conf" file to determine if the "xattrs" rule has been added to the rule list being applied to the files and directories selection lists with the following command:

# egrep "[+]?xattrs" /etc/aide/aide.conf

VarFile = OwnerMode+n+l+X+xattrs

If the "xattrs" rule is not being used on all selection lines in the "/etc/aide.conf" file, or extended attributes are not being checked by another file integrity tool, this is a finding.

Fix

Configure the file integrity tool to check file and directory extended attributes.

If AIDE is installed, ensure the "xattrs" rule is present on all file and directory selection lists.
V-75523 No Change
Findings ID: UBTU-16-010540 Rule ID: SV-90203r3_rule Severity: medium CCI: CCI-001744

Discussion

Unauthorized changes to the baseline configuration could make the system vulnerable to various attacks or allow unauthorized access to the Ubuntu operating system. Changes to Ubuntu operating system configurations can have unintended side effects, some of which may be relevant to security.

Security function is defined as the hardware, software, and/or firmware of the information system responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.

Detecting such changes and providing an automated response can help avoid unintended, negative consequences that could ultimately affect the security state of the Ubuntu operating system. The Ubuntu operating system's IMO/ISSO and SAs must be notified via email and/or monitoring system trap when there is an unauthorized modification of a configuration item.

Notifications provided by information systems include messages to local computer consoles, and/or hardware indications, such as lights.

This capability must take into account operational requirements for availability for selecting an appropriate response. The organization may choose to shut down or restart the information system upon security function anomaly detection.

Satisfies: SRG-OS-000363-GPOS-00150, SRG-OS-000447-GPOS-00201

Checks

Verify that Advanced Intrusion Detection Environment (AIDE) notifies the system administrator when anomalies in the operation of any security functions are discovered.

Check that 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 the "/etc/cron.daily/aide" file does not exist, the cron job is configured with the "SILENTREPORTS=yes" option, or the line is commented out, this is a finding.

Fix

Modify the "SILENTREPORTS" parameter in "/etc/default/aide" file with a value "no" of if it does not already exist:

SILENTREPORTS=no
V-75525 No Change
Findings ID: UBTU-16-010550 Rule ID: SV-90205r2_rule Severity: medium CCI: CCI-001496

Discussion

Protecting the integrity of the tools used for auditing purposes is a critical step toward ensuring the integrity of audit information. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.

Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

It is not uncommon for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs.

To address this risk, audit tools must be cryptographically signed in order to provide the capability to identify when the audit tools have been modified, manipulated, or replaced. An example is a checksum hash of the file or files.

Checks

Verify that Advanced Intrusion Detection Environment (AIDE) to 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 '(\/usr\/sbin\/(audit|au))' /etc/aide/aide.conf

/usr/sbin/auditctl p+i+n+u+g+s+b+acl+xattr+sha512
/usr/sbin/auditd p+i+n+u+g+s+b+acl+xattr+sha512
/usr/sbin/ausearch p+i+n+u+g+s+b+acl+xattr+sha512
/usr/sbin/aureport p+i+n+u+g+s+b+acl+xattr+sha512
/usr/sbin/autrace p+i+n+u+g+s+b+acl+xattr+sha512
/usr/sbin/audispd p+i+n+u+g+s+b+acl+xattr+sha512
/usr/sbin/augenrules p+i+n+u+g+s+b+acl+xattr+sha512

If any of the seven audit tools does not have an appropriate selection line, this is a finding.

Fix

Add or update the following selection lines to "/etc/aide/aide.conf", in order to protect the integrity of the audit tools.

# Audit Tools
/usr/sbin/auditctl p+i+n+u+g+s+b+acl+xattr+sha512
/usr/sbin/auditd p+i+n+u+g+s+b+acl+xattr+sha512
/usr/sbin/ausearch p+i+n+u+g+s+b+acl+xattr+sha512
/usr/sbin/aureport p+i+n+u+g+s+b+acl+xattr+sha512
/usr/sbin/autrace p+i+n+u+g+s+b+acl+xattr+sha512
/usr/sbin/audispd p+i+n+u+g+s+b+acl+xattr+sha512
/usr/sbin/augenrules p+i+n+u+g+s+b+acl+xattr+sha512
V-75527 No Change
Findings ID: UBTU-16-010560 Rule ID: SV-90207r2_rule Severity: medium CCI: CCI-001749

Discussion

Changes to any software components can have significant effects on the overall security of the Ubuntu operating system. This requirement ensures the software has not been tampered with and that it has been provided by a trusted vendor.

Accordingly, patches, service packs, device drivers, or Ubuntu operating system components must be signed with a certificate recognized and approved by the organization.

Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. Setting the "Verify-Peer" Boolean will determine whether or not the server's host certificate should be verified against trusted certificates. This ensures the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. The Ubuntu operating system should not have to verify the software again. This requirement does not mandate DoD certificates for this purpose; however, the certificate used to verify the software must be from an approved CA.

Checks

Verify that Advance package Tool (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 set to "false" with the following command:

# grep -i allowunauth /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" set to "true", this is a finding.

Fix

Configure Advance package Tool (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 file 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";
V-75529 No Change
Findings ID: UBTU-16-010570 Rule ID: SV-90209r1_rule Severity: medium CCI: CCI-002617

Discussion

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

Checks

Verify Advance package Tool (APT) is configured to remove all software components after updated versions have been installed.

Check that APT is configured to remove all software components after updating with the following command:

# grep -i remove-unused /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Remove-Unused-Dependencies "true";

If the "Remove-Unused-Dependencies" parameter is not set to "true", or is missing, this is a finding.

Fix

Configure APT to remove all software components after updated versions have been installed.

Add or updated the following option to the "/etc/apt/apt.conf.d/50unattended-upgrades" file:

Unattended-Upgrade::Remove-Unused-Dependencies "true";
V-75531 No Change
Findings ID: UBTU-16-010580 Rule ID: SV-90211r2_rule Severity: medium CCI: CCI-001958

Discussion

Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity.

Peripherals include, but are not limited to, such devices as flash drives, external storage, and printers.

Checks

Verify that automatic mounting of the Universal Serial Bus (USB) mass storage driver has been disabled.

Check that the USB mass storage drive has not been loaded with the following command:

#lsmod | grep usb-storage

If a "usb-storage" line is returned, this is a finding.

Check that automatic mounting of the USB mass storage driver has been disabled with the following command:

#sudo modprobe -vn usb-storage

install /bin/true

If “install /bin/true” is not returned, this is a finding.

Fix

Disable the mounting of the Universal Serial Bus (USB) mass storage driver by running the following command:

# sudo echo “install usb-storage /bin/true” >> /etc/modprobe.d/DISASTIG.conf
V-75533 No Change
Findings ID: UBTU-16-010590 Rule ID: SV-90213r2_rule Severity: medium CCI: CCI-000366

Discussion

Automatically mounting file systems permits easy introduction of unknown devices, thereby facilitating malicious activity.

Satisfies: SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-00163, SRG-OS-000480-GPOS-00227

Checks

Verify the Ubuntu operating system disables the ability to automount devices.

Check to see if automounter service is active with the following command:

# systemctl status autofs
autofs.service - LSB: Automounts filesystems on demand
Loaded: loaded (/etc/init.d/autofs; bad; vendor preset: enabled)
Active: active (running) since Thu 2017-05-04 07:53:51 EDT; 6 days ago
Docs: man:systemd-sysv-generator(8)
CGroup: /system.slice/autofs.service
+-24206 /usr/sbin/automount --pid-file /var/run/autofs.pid

If the "autofs" status is set to "active" and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix

Configure the Ubuntu operating system to disable the ability to automount devices.

Turn off the automount service with the following command:

# sudo systemctl stop autofs

If "autofs" is required for Network File System (NFS), it must be documented with the Information System Security Officer (ISSO).
V-75535 No Change
Findings ID: UBTU-16-010600 Rule ID: SV-90215r2_rule Severity: medium CCI: CCI-002165

Discussion

Discretionary Access Control (DAC) is based on the notion that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user-controlled file permissions.

When discretionary access control policies are implemented, subjects are not constrained with regard to what actions they can take with information for which they have already been granted access. Thus, subjects that have been granted access to information are not prevented from passing (i.e., the subjects have the discretion to pass) the information to other subjects or objects. A subject that is constrained in its operation by Mandatory Access Control policies is still able to operate under the less rigorous constraints of this requirement. Thus, while Mandatory Access Control imposes constraints preventing a subject from passing information to another subject operating at a different sensitivity level, this requirement permits the subject to pass the information to any subject at the same sensitivity level. The policy is bounded by the information system boundary. Once the information is passed outside the control of the information system, additional means may be required to ensure the constraints remain in effect. While the older, more traditional definitions of discretionary access control require identity-based access control, that limitation is not required for this use of discretionary access control.

Satisfies: SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000312-GPOS-00124, SRG-OS-000324-GPOS-00125

Checks

Verify the Ubuntu operating system is configured to allow system administrators to pass information to any other Ubuntu operating system administrator or user.

Check that "Pam_Apparmor" is installed on the system with the following command:

# sudo apt list libpam-apparmor

libpam-apparmor/xenial-updates,now 2.10.95-0ubuntu2.7 amd64 [installed]

If the "Pam_Apparmor" package is not installed, this is a finding.

Check that Pam_Apparmor has properly configured profiles

# sudo apparmor_status

apparmor module is loaded.
13 profiles are loaded.
13 profiles are in enforce mode.
/sbin/dhclient
...
lxc-container-default-with-nesting
0 profiles are in complain mode.

If all loaded profiles are not in "enforce" mode, or there are any profiles in "complain" mode, this is a finding.

Fix

Configure the Ubuntu operating system to allow system administrators to pass information to any other Ubuntu operating system administrator or user.

Install "Pam_Apparmor" (if it is not installed) with the following command:

# sudo apt-get install libpam-apparmor

Enable/Activate "Apparmor" (if it is not already active) with the following command:

# sudo systemctl enable apparmor.service

Start "Apparmor" with the following command:

# sudo systemctl start apparmor.service

Note: Pam_Apparmor must have properly configured profiles. All configurations will be based on the actual system setup and organization. See the "Pam_Apparmor" documentation for more information on configuring profiles.
V-75537 No Change
Findings ID: UBTU-16-010610 Rule ID: SV-90217r2_rule Severity: medium CCI: CCI-001764

Discussion

The organization must identify authorized software programs and permit execution of authorized software. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as whitelisting.

Utilizing a whitelist provides a configuration management method for allowing the execution of only authorized software. Using only authorized software decreases risk by limiting the number of potential vulnerabilities. Verification of white-listed software occurs prior to execution or at system startup.

Users' home directories/folders may contain information of a sensitive nature. Non-privileged users should coordinate any sharing of information with an SA through shared resources.

Satisfies: SRG-OS-000368-GPOS-00154, SRG-OS-000370-GPOS-00155

Checks

Verify the Ubuntu operating system is configured to employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs and access to user home directories.

Check that "Apparmor" is configured to employ application whitelisting and home directory access control with the following command:

# sudo apparmor_status

apparmor module is loaded.
13 profiles are loaded.
13 profiles are in enforce mode.
/sbin/dhclient
...
lxc-container-default-with-nesting
0 profiles are in complain mode.

If the defined profiles do not match the organization’s list of authorized software, this is a finding.

Fix

Configure the Ubuntu operating system to employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs.

Install "Apparmor" (if it is not installed) with the following command:

# sudo apt-get install libpam-apparmor

Enable/Activate "Apparmor" (if it is not already active) with the following command:

# sudo systemctl enable apparmor.service

Start "Apparmor" with the following command:

# sudo systemctl start apparmor.service

Note: Apparmor must have properly configured profiles for applications and home directories. All configurations will be based on the actual system setup and organization and normally are on a per role basis. See the "Apparmor" documentation for more information on configuring profiles.
V-75541 No Change
Findings ID: UBTU-16-010630 Rule ID: SV-90221r2_rule Severity: high CCI: CCI-000366

Discussion

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

Checks

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:

# systemctl status ctrl-alt-del.target
reboot.target - Reboot
Loaded: loaded (/usr/lib/systemd/system/reboot.target; disabled)
Active: inactive (dead)
Docs: man:systemd.special(7)

If the "ctrl-alt-del.target" is active, this is a finding.

Fix

Configure the system to disable the Ctrl-Alt-Delete sequence for the command line with the following command:

# sudo systemctl mask ctrl-alt-del.target

And reload the daemon to take effect

# sudo systemctl daemon-reload

If GNOME is active on the system, create a database to contain the system-wide setting (if it does not already exist) with the following command:

# cat /etc/dconf/db/local.d/00-disable-CAD

Add the setting to disable the Ctrl-Alt-Delete sequence for GNOME:

[org/gnome/settings-daemon/plugins/media-keys]
logout=’’
V-75543 No Change
Findings ID: UBTU-16-010640 Rule ID: SV-90223r2_rule Severity: medium CCI: CCI-000366

Discussion

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

Checks

Verify the Ubuntu operating system defines default permissions for all authenticated users in such a way that the user can only read and modify their own files.

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

Fix

Configure the system to define the default permissions for all authenticated users in such a way that the user can only read and modify their own files.

Edit the "UMASK" parameter in the "/etc/login.defs" file to match the example below:

UMASK 077
V-75545 No Change
Findings ID: UBTU-16-010650 Rule ID: SV-90225r2_rule Severity: medium CCI: CCI-000366

Discussion

Accounts providing no operational purpose provide additional opportunities for system compromise. Unnecessary accounts include user accounts for individuals not requiring access to the system and application accounts for applications not installed on the system.

Checks

Verify all accounts on the system are assigned to an active system, application, or user account.

Obtain the list of authorized system accounts from the Information System Security Officer (ISSO).

Check the system accounts on the system with the following command:

# more /etc/passwd
root:x:0:0:root:/root:/bin/bash
...
games:x:5:60:games:/usr/games:/usr/sbin/nologin

Accounts such as "games" and "gopher" are not authorized accounts as they do not support authorized system functions.

If the accounts on the system do not match the provided documentation, or accounts that do not support an authorized system function are present, this is a finding.

Fix

Configure the system so all accounts on the system are assigned to an active system, application, or user account.

Remove accounts that do not support approved system activities or that allow for a normal user to perform administrative-level actions.

Document all authorized accounts on the system.
V-75547 No Change
Findings ID: UBTU-16-010660 Rule ID: SV-90227r2_rule Severity: medium CCI: CCI-000764

Discussion

To assure accountability and prevent unauthenticated access, interactive users must be identified and authenticated to prevent potential misuse and compromise of the system.

Interactive users include organizational employees or individuals the organization deems to have equivalent status of employees (e.g., contractors). Interactive users (and processes acting on behalf of users) must be uniquely identified and authenticated to all accesses, except for the following:

1) Accesses explicitly identified and documented by the organization. Organizations document specific user actions that can be performed on the information system without identification or authentication; and

2) Accesses that occur through authorized use of group authenticators without individual authentication. Organizations may require unique identification of individuals in group accounts (e.g., shared privilege accounts) or for detailed accountability of individual activity.

Satisfies: SRG-OS-000104-GPOS-00051, SRG-OS-000121-GPOS-00062, SRG-OS-000134-GPOS-00068

Checks

Verify that the Ubuntu operating system contains no duplicate User IDs (UIDs) for interactive users.

Check that the Ubuntu operating system contains no duplicate UIDs for interactive users with the following command:

# awk -F ":" 'list[$3]++{print $1, $3}' /etc/passwd

If output is produced, and the accounts listed are interactive user accounts, this is a finding.

Fix

Edit the file "/etc/passwd" and provide each interactive user account that has a duplicate User ID (UID) with a unique UID.
V-75549 No Change
Findings ID: UBTU-16-010670 Rule ID: SV-90229r1_rule Severity: high CCI: CCI-000366

Discussion

If an account other than root also has a User Identifier (UID) of "0", it has root authority, giving that account unrestricted access to the entire Ubuntu operating system. Multiple accounts with a UID of "0" afford an opportunity for potential intruders to guess a password for a privileged account.

Checks

Check the Ubuntu operating system for duplicate User ID (UID) "0" assignments with the following command:

# awk -F: '$3 == 0 {print $1}' /etc/passwd

root

If any accounts other than root have a UID of "0", this is a finding.

Fix

Change the User ID (UID) of any account on the system, other than root, that has a UID of "0".

If the account is associated with system commands or applications, the UID should be changed to one greater than "0" but less than "1000". Otherwise, assign a UID of greater than "1000" that has not already been assigned.
V-75551 No Change
Findings ID: UBTU-16-010680 Rule ID: SV-90231r1_rule Severity: medium CCI: CCI-002041

Discussion

Without providing this capability, an account may be created without a password. Non-repudiation cannot be guaranteed once an account is created if a user is not forced to change the temporary password upon initial logon.

Temporary passwords are typically used to allow access when new accounts are created or passwords are changed. It is common practice for administrators to create temporary passwords for user accounts which allow the users to log on, yet force them to change the password once they have successfully authenticated.

Checks

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

If a policy does not exist, this is a finding.

Fix

Create a policy that ensures when a user is created, it is created using a method that forces a user to change their password upon their next login.

Below are two examples of how to create a user account that requires the user to change their password upon their next login.

# chage -d 0 [UserName]

or

# passwd -e [UserName]
V-75553 No Change
Findings ID: UBTU-16-010690 Rule ID: SV-90233r2_rule Severity: medium CCI: CCI-002007

Discussion

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

Checks

Verify that Pluggable Authentication Module (PAM) prohibits the use of cached authentications after one day.

Note: If smart card authentication is not being used on the system this item is Not Applicable.

Check that PAM prohibits the use of cached authentications after one day with the following command:

# sudo grep -i "timestamp_timeout" /etc/pam.d/*

timestamp_timeout=86400

If "timestamp_timeout" is not set to a value of "86400" or less, or is commented out, this is a finding.

Fix

Configure Pluggable Authentication Module (PAM) to prohibit the use of cached authentications after one day.

Add or change the following line in "/etc/pam.d/common-auth" or "/etc/pam.d/common-session" just below the line "[pam]".

timestamp_timeout = 86400
V-75555 No Change
Findings ID: UBTU-16-010700 Rule ID: SV-90235r1_rule Severity: medium CCI: CCI-002165

Discussion

Unowned files and directories may be unintentionally inherited if a user is assigned the same User Identifier "UID" as the UID of the un-owned files.

Checks

Verify all files and directories on the Ubuntu operating system have a valid owner.

Check the owner of all files and directories with the following command:

# sudo find / -nouser

If any files on the system do not have an assigned owner, this is a finding.

Fix

Either remove all files and directories from the system that do not have a valid user, or assign a valid user to all unowned files and directories on the Ubuntu operating system with the "chown" command:

# sudo chown <user> <file>
V-75557 No Change
Findings ID: UBTU-16-010710 Rule ID: SV-90237r1_rule Severity: medium CCI: CCI-002165

Discussion

Files without a valid group owner may be unintentionally inherited if a group is assigned the same Group Identifier (GID) as the GID of the files without a valid group owner.

Checks

Verify all files and directories on the Ubuntu operating system have a valid group.

Check the owner of all files and directories with the following command:

# sudo find / -nogroup

If any files on the system do not have an assigned group, this is a finding.

Fix

Either remove all files and directories from the Ubuntu operating system that do not have a valid group, or assign a valid group to all files and directories on the system with the "chgrp" command:

# sudo chgrp <group> <file>
V-75559 No Change
Findings ID: UBTU-16-010720 Rule ID: SV-90239r1_rule Severity: medium CCI: CCI-000366

Discussion

If local interactive users are not assigned a valid home directory, there is no place for the storage and control of files they should own.

Checks

Verify local interactive users on the Ubuntu operating system have a home directory assigned.

Check for missing local interactive user home directories with the following command:

# sudo pwck -r
user 'lp': directory '/var/spool/lpd' does not exist
user 'news': directory '/var/spool/news' does not exist
user 'uucp': directory '/var/spool/uucp' does not exist
user 'www-data': directory '/var/www' does not exist

Ask the System Administrator (SA) if any users found without home directories are local interactive users. If the SA is unable to provide a response, check for users with a User Identifier (UID) of 1000 or greater with the following command:

# sudo cut -d: -f 1,3 /etc/passwd | egrep ":[1-4][0-9]{2}$|:[0-9]{1,2}$"

If any interactive users do not have a home directory assigned, this is a finding.

Fix

Assign home directories to all local interactive users on the Ubuntu operating system that currently do not have a home directory assigned.
V-75561 No Change
Findings ID: UBTU-16-010730 Rule ID: SV-90241r1_rule Severity: medium CCI: CCI-000366

Discussion

If local interactive users are not assigned a valid home directory, there is no place for the storage and control of files they should own.

Checks

Verify all local interactive users on the Ubuntu operating system are assigned a home directory upon creation.

Check to see if the system is configured to create home directories for local interactive users with the following command:

# grep -i create_home /etc/login.defs
CREATE_HOME yes

If the value for "CREATE_HOME" parameter is not set to "yes", the line is missing, or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to assign home directories to all new local interactive users by setting the "CREATE_HOME" parameter in "/etc/login.defs" to "yes" as follows.

CREATE_HOME yes
V-75563 No Change
Findings ID: UBTU-16-010740 Rule ID: SV-90243r1_rule Severity: medium CCI: CCI-000366

Discussion

If a local interactive user has a home directory defined that does not exist, the user may be given access to the / directory as the current working directory upon logon. This could create a Denial of Service because the user would not be able to access their logon configuration files, and it may give them visibility to system files they normally would not be able to access.

Checks

Verify the assigned home directory of all local interactive users on the Ubuntu operating system exists.

Check the home directory assignment for all local interactive non-privileged users with the following command:

# ls -ld $(awk -F: '($3>=1000)&&($1!="nobody"){print $6}' /etc/passwd)

drwxr-xr-x 2 smithj admin 4096 Jun 5 12:41 smithj

Note: This may miss interactive users that have been assigned a privileged User ID (UID). Evidence of interactive use may be obtained from a number of log files containing system logon information.

Check that all referenced home directories exist with the following command:

# pwck -r

user 'smithj': directory '/home/smithj' does not exist

If any home directories referenced in "/etc/passwd" are returned as not defined, this is a finding.

Fix

Create home directories to all local interactive users that currently do not have a home directory assigned. Use the following commands to create the user home directory assigned in "/etc/ passwd":

Note: The example will be for the user smithj, who has a home directory of "/home/smithj", a User ID (UID) of "smithj", and a Group Identifier (GID) of "users assigned" in "/etc/passwd".

# mkdir /home/smithj
# chown smithj /home/smithj
# chgrp users /home/smithj
# chmod 0750 /home/smithj
V-75565 No Change
Findings ID: UBTU-16-010750 Rule ID: SV-90245r1_rule Severity: medium CCI: CCI-000366

Discussion

Excessive permissions on local interactive user home directories may allow unauthorized access to user files by other users.

Checks

Verify the assigned home directory of all local interactive users has a mode of "0750" or less permissive.

Check the home directory assignment for all non-privileged users with the following command:

Note: This may miss interactive users that have been assigned a privileged User Identifier (UID). Evidence of interactive use may be obtained from a number of log files containing system logon information.

# ls -ld $(awk -F: '($3>=1000)&&($1!="nobody"){print $6}' /etc/passwd)

drwxr-x--- 2 smithj admin 4096 Jun 5 12:41 smithj

If home directories referenced in "/etc/passwd" do not have a mode of "0750" or less permissive, this is a finding.

Fix

Change the mode of interactive user’s home directories to "0750". To change the mode of a local interactive user’s home directory, use the following command:

Note: The example will be for the user "smithj".

# chmod 0750 /home/smithj
V-75567 No Change
Findings ID: UBTU-16-010760 Rule ID: SV-90247r1_rule Severity: medium CCI: CCI-000366

Discussion

If the Group Identifier (GID) of a local interactive user’s home directory is not the same as the primary GID of the user, this would allow unauthorized access to the user’s files, and users that share the same group may not be able to access files that they legitimately should.

Checks

Verify the assigned home directory of all local interactive users is group-owned by that user’s primary Group Identifier (GID).

Check the home directory assignment for all non-privileged users on the system with the following command:

Note: This may miss local interactive users that have been assigned a privileged UID. Evidence of interactive use may be obtained from a number of log files containing system logon information. The returned directory "/home/smithj" is used as an example.

# ls -ld $(awk -F: '($3>=1000)&&($1!="nobody"){print $6}' /etc/passwd)

drwxr-x--- 2 smithj admin 4096 Jun 5 12:41 smithj

Check the user's primary group with the following command:

# grep admin /etc/group
admin:x:250:smithj,jonesj,jacksons

If the user home directory referenced in "/etc/passwd" is not group-owned by that user’s primary GID, this is a finding.

Fix

Change the group owner of a local interactive user’s home directory to the group found in "/etc/passwd". To change the group owner of a local interactive user’s home directory, use the following command:

Note: The example will be for the user "smithj", who has a home directory of "/home/smithj", and has a primary group of users.

# chgrp users /home/smithj
V-75569 No Change
Findings ID: UBTU-16-010770 Rule ID: SV-90249r1_rule Severity: medium CCI: CCI-000366

Discussion

Local initialization files are used to configure the user's shell environment upon logon. Malicious modification of these files could compromise accounts upon logon.

Checks

Verify that all local initialization files have a mode of "0740" or less permissive.

Check the mode on all local initialization files with the following command:

Note: The example will be for the smithj user, who has a home directory of "/home/smithj".

# ls -al /home/smithj/.* | more
-rwxr-xr-x 1 smithj users 896 Mar 10 2011 .profile
-rwxr-xr-x 1 smithj users 497 Jan 6 2007 .login
-rwxr-xr-x 1 smithj users 886 Jan 6 2007 .something

If any local initialization files have a mode more permissive than "0740", this is a finding.

Fix

Set the mode of the local initialization files to "0740" with the following command:

Note: The example will be for the smithj user, who has a home directory of "/home/smithj".

# chmod 0740 /home/smithj/.<INIT_FILE>
V-75571 No Change
Findings ID: UBTU-16-010780 Rule ID: SV-90251r1_rule Severity: medium CCI: CCI-000366

Discussion

The executable search path (typically the PATH environment variable) contains a list of directories for the shell to search to find executables. If this path includes the current working directory executables in these directories may be executed instead of system commands. This variable is formatted as a colon-separated list of directories. If there is an empty entry, such as a leading or trailing colon or two consecutive colons, this is interpreted as the current working directory. If deviations from the default system search path for the local interactive user are required, they must be documented with the Information System Security Officer (ISSO).

Checks

Verify that all local interactive user initialization files' executable search path statements do not contain statements that will reference a working directory other than the users’ home directory or the system default.

Check the executable search path statement for all local interactive user initialization files in the users' home directory with the following commands:

Note: The example will be for the smithj user, which has a home directory of "/home/smithj".

# grep -i path /home/smithj/.*
/home/smithj/.bash_profile:PATH=$PATH:$HOME/.local/bin:$HOME/bin
/home/smithj/.bash_profile:export PATH

If any local interactive user initialization files have executable search path statements that include directories outside of their home directory, and the additional path statements are not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix

Edit the local interactive user initialization files to change any PATH variable statements for executables that reference directories other than their home directory or the system default. If a local interactive user requires path variables to reference a directory owned by the application, it must be documented with the Information System Security Officer (ISSO).
V-75573 No Change
Findings ID: UBTU-16-010790 Rule ID: SV-90253r1_rule Severity: medium CCI: CCI-000366

Discussion

If user start-up files execute world-writable programs, especially in unprotected directories, they could be maliciously modified to destroy user files or otherwise compromise the system at the user level. If the system is compromised at the user level, it is easier to elevate privileges to eventually compromise the system at the root and network level.

Checks

Verify that local initialization files do not execute world-writable programs.

Check the system for world-writable files with the following command:

# sudo find / -perm -002 -type f -exec ls -ld {} \; | more

For all files listed, check for their presence in the local initialization files with the following commands:

Note: The example will be for a system that is configured to create users’ home directories in the "/home" directory.

# grep <file> /home/*/.*

If any local initialization files are found to reference world-writable files, this is a finding.

Fix

Set the mode on files being executed by the local initialization files with the following command:

# chmod 0755 <file>
V-75575 No Change
Findings ID: UBTU-16-010800 Rule ID: SV-90255r2_rule Severity: medium CCI: CCI-000366

Discussion

The "nosuid" mount option causes the system to not execute setuid and setgid files with owner privileges. This option must be used for mounting any file system not containing approved setuid and setguid files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.

Checks

Verify file systems that contain user home directories are mounted with the "nosuid" option.

Note: If a separate file system has not been created for the user home directories (user home directories are mounted under "/"), this is not a finding as the "nosuid" option cannot be used on the "/" system.

Find the file system(s) that contain the user home directories with the following command:

# awk -F: '($3>=1000)&&($1!="nobody"){print $1,$3,$6}' /etc/passwd

smithj:1001: /home/smithj
robinst:1002: /home/robinst

Check the file systems that are mounted at boot time with the following command:

# more /etc/fstab

UUID=a411dc99-f2a1-4c87-9e05-184977be8539 /home ext4 rw,relatime,discard,data=ordered,nosuid 0 2

If a file system found in "/etc/fstab" refers to the user home directory file system and it does not have the "nosuid" option set, this is a finding.

Fix

Configure the "/etc/fstab" to use the "nosuid" option on file systems that contain user home directories for interactive users.
V-75577 No Change
Findings ID: UBTU-16-010810 Rule ID: SV-90257r3_rule Severity: medium CCI: CCI-000366

Discussion

The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.

Checks

Verify file systems that are used for removable media are mounted with the "nosuid" option.

Check the file systems that are mounted at boot time with the following command:

# more /etc/fstab

UUID=2bc871e4-e2a3-4f29-9ece-3be60c835222 /mnt/usbflash vfat noauto,owner,ro,nosuid 0 0

If a file system found in "/etc/fstab" refers to removable media and it does not have the "nosuid" option set, this is a finding.

Fix

Configure the "/etc/fstab" to use the "nosuid" option on file systems that are associated with removable media.
V-75579 No Change
Findings ID: UBTU-16-010820 Rule ID: SV-90259r3_rule Severity: medium CCI: CCI-000366

Discussion

The "nosuid" mount option causes the system to not execute "setuid" and "setgid" files with owner privileges. This option must be used for mounting any file system not containing approved "setuid" and "setguid" files. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.

Checks

Verify file systems that are being Network File System (NFS) imported are mounted with the "nosuid" option.

Find the file system(s) that contain the directories being exported with the following command:

# grep nfs /etc/fstab | grep nosuid

UUID=e06097bb-cfcd-437b-9e4d-a691f5662a7d /store nfs rw,nosuid 0 0

If a file system found in "/etc/fstab" refers to NFS and it does not have the "nosuid" option set, this is a finding.

Fix

Configure the "/etc/fstab" to use the "nosuid" option on file systems that are being imported via Network File System (NFS).
V-75581 No Change
Findings ID: UBTU-16-010830 Rule ID: SV-90261r2_rule Severity: medium CCI: CCI-000366

Discussion

The "noexec" mount option causes the system to not execute binary files. This option must be used for mounting any file system not containing approved binary files as they may be incompatible. Executing files from untrusted file systems increases the opportunity for unprivileged users to attain unauthorized administrative access.

Checks

Verify file systems that are being Network File System (NFS) imported are mounted with the "noexec" option.

Find the file system(s) that contain the directories being exported with the following command:

# grep nfs /etc/fstab | grep noexec

UUID=e06097bb-cfcd-437b-9e4d-a691f5662a7d /store nfs rw,noexec 0 0

If a file system found in "/etc/fstab" refers to NFS and it does not have the "noexec" option set, and use of NFS exported binaries is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix

Configure the "/etc/fstab" to use the "noexec" option on file systems that are being imported via Network File System (NFS).
V-75583 No Change
Findings ID: UBTU-16-010840 Rule ID: SV-90263r2_rule Severity: medium CCI: CCI-000366

Discussion

If a world-writable directory has the sticky bit set and is not group-owned by a privileged Group Identifier (GID), unauthorized users may be able to modify files created by others.

The only authorized public directories are those temporary directories supplied with the system or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system and by users for temporary file storage, (e.g., /tmp), and for directories requiring global read/write access.

Checks

Verify all world-writable directories are group-owned by root, sys, bin, or an application group.

Check the system for world-writable directories with the following command:

# sudo find / -perm -2 -type d ! -group sys ! -group root ! -group bin -exec ls -lLd {} \;
drwxrwsrwt 2 root whoops 4096 Jun 6 07:44 /var/crash
drwxrwsrwt 2 root whoops 4096 Jul 19 2016 /var/metrics

If any world-writable directories are not owned by root, sys, bin, or an application group associated with the directory, this is a finding.

Fix

Change the group of the world-writable directories to root with the following command:

# chgrp root <directory>
V-75585 No Change
Findings ID: UBTU-16-010900 Rule ID: SV-90265r1_rule Severity: medium CCI: CCI-000366

Discussion

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

Checks

Verify that kernel core dumps are disabled unless needed.

Check the status of the "kdump" service with the following command:

# systemctl status kdump.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)

If the "kdump" service is active, ask the System Administrator if the use of the service is required and documented with the Information System Security Officer (ISSO).

If the service is active and is not documented, this is a finding.

Fix

If kernel core dumps are not required, disable the "kdump" service with the following command:

# systemctl disable kdump.service

If kernel core dumps are required, document the need with the Information System Security Officer (ISSO).
V-75587 No Change
Findings ID: UBTU-16-010910 Rule ID: SV-90267r2_rule Severity: medium CCI: CCI-000366

Discussion

The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing.

Checks

Verify that a separate file system/partition has been created for non-privileged local interactive user home directories.

Check the home directory assignment for all non-privileged users, users with a User Identifier (UID) greater than 1000, on the system with the following command:

# awk -F: '($3>=1000)&&($1!="nobody"){print $1,$3,$6}' /etc/passwd

adamsj 1001 /home/adamsj
jacksonm 1002 /home/jacksonm
smithj 1003 /home/smithj

The output of the command will give the directory/partition that contains the home directories for the non-privileged users on the system (in this example, "/home") and users’ shell. All accounts with a valid shell (such as /bin/bash) are considered interactive users.

Check that a file system/partition has been created for the non-privileged interactive users with the following command:

Note: The partition of "/home" is used in the example.

# grep /home /etc/fstab
UUID=333ada18 /home ext4 noatime,nobarrier,nodev 1 2

If a separate entry for the file system/partition that contains the non-privileged interactive users' home directories does not exist, this is a finding.

Fix

Migrate the "/home" directory onto a separate file system/partition.
V-75589 No Change
Findings ID: UBTU-16-010920 Rule ID: SV-90269r1_rule Severity: low CCI: CCI-000366

Discussion

The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing.

Checks

Verify that a separate file system/partition has been created for "/var".

Check that a file system/partition has been created for "/var" with the following command:

# grep /var /etc/fstab
UUID=c274f65f /var ext4 noatime,nobarrier 1 2

If a separate entry for "/var" is not in use, this is a finding.

Fix

Migrate the "/var" path onto a separate file system.
V-75591 No Change
Findings ID: UBTU-16-010930 Rule ID: SV-90271r1_rule Severity: low CCI: CCI-000366

Discussion

The use of separate file systems for different paths can protect the system from failures resulting from a file system becoming full or failing.

Checks

Verify that a separate file system/partition has been created for the system audit data path.

Check that a file system/partition has been created for the system audit data path with the following command:

Note: /var/log/audit is used as the example as it is a common location.

#grep /var/log/audit /etc/fstab
UUID=3645951a /var/log/audit ext4 defaults 1 2

If a separate entry for "/var/log/audit" does not exist, ask the System Administrator if the system audit logs are being written to a different file system/partition on the system, then grep for that file system/partition.

If a separate file system/partition does not exist for the system audit data path, this is a finding.

Fix

Migrate the system audit data path onto a separate file system.
V-75593 No Change
Findings ID: UBTU-16-010940 Rule ID: SV-90273r2_rule Severity: medium CCI: CCI-001314

Discussion

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the Ubuntu operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.

The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Checks

Verify the "/var/log" directory is group-owned by syslog.

Check that the "/var/log" directory is group owned by syslog with the following command:

# ls -lad /var/log | cut -d' ' -f4

syslog

If "syslog" is not returned as a result, this is a finding.

Fix

Change the group of the directory "/var/log" to "syslog" by running the following command:

# sudo chgrp syslog /var/log
V-75595 No Change
Findings ID: UBTU-16-010950 Rule ID: SV-90275r2_rule Severity: medium CCI: CCI-001314

Discussion

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the Ubuntu operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.

The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Checks

Verify the /var/log directory is owned by root.

Check that the /var/log directory is owned by root with the following command:

# ls -lad /var/log | cut -d' ' -f3

root

If "root" is not returned as a result, this is a finding.

Fix

Change the owner of the directory /var/log to root by running the following command:

# sudo chown root /var/log
V-75597 No Change
Findings ID: UBTU-16-010960 Rule ID: SV-90277r3_rule Severity: medium CCI: CCI-001314

Discussion

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the Ubuntu operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.

The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Checks

Verify that the "/var/log" directory has a mode of "0770" or less.

Check the mode of the "/var/log" directory with the following command:

# stat -c "%a %n" /var/log

770

If a value of "0770" or less permissive is not returned, this is a finding.

Fix

Change the permissions of the directory "/var/log" to "0770" by running the following command:

# sudo chmod 0770 /var/log
V-75599 No Change
Findings ID: UBTU-16-010970 Rule ID: SV-90279r2_rule Severity: medium CCI: CCI-001314

Discussion

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the Ubuntu operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.

The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Checks

Verify the "/var/log/syslog" file is group-owned by "adm".

Check that "/var/log/syslog" is group-owned by "adm" with the following command:

# ls -la /var/log/syslog | cut -d' ' -f4

adm

If "adm" is not returned as a result, this is a finding.

Fix

Change the group of the file "/var/log/syslog" to "adm" by running the following command:

# sudo chgrp adm /var/log/syslog
V-75601 No Change
Findings ID: UBTU-16-010980 Rule ID: SV-90281r2_rule Severity: medium CCI: CCI-001314

Discussion

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the Ubuntu operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.

The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Checks

Verify that the /var/log/syslog file is owned by syslog.

Check that the /var/log/syslog file is owned by syslog with the following command:

# ls -la /var/log/syslog | cut -d' ' -f3

syslog

If "syslog" is not returned as a result, this is a finding.

Fix

Change the owner of the file /var/log/syslog to syslog by running the following command:

# sudo chown syslog /var/log/syslog
V-75603 No Change
Findings ID: UBTU-16-010990 Rule ID: SV-90283r3_rule Severity: medium CCI: CCI-001314

Discussion

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the Ubuntu operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.

The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Checks

Verify that the "/var/log/syslog" file has mode "0640" or less permissive.

Check that "/var/log/syslog" has mode "0640" or less permissive with the following command:

# stat -c "%a %n" /var/log/syslog

640 /var/log/syslog

If a value of "640" or less permissive is not returned, this is a finding.

Fix

Change the permissions of the file "/var/log/syslog" to "0640" by running the following command:

# sudo chmod 0640 /var/log
V-75605 No Change
Findings ID: UBTU-16-011000 Rule ID: SV-90285r2_rule Severity: medium CCI: CCI-001499

Discussion

If the Ubuntu operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.

This requirement applies to Ubuntu operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Checks

Verify the system-wide shared library files contained in the following directories have mode "0755" or less permissive.

Check that the system-wide shared library files contained in the following directories have mode "0755" or less permissive with the following command:

Note: Replace "[directory]" with one of the following paths:
/lib
/lib64
/usr/lib

# find /lib /lib64 /usr/lib -perm /022 -type f | xargs ls -la
/usr/lib64/pkcs11-spy.so

If any system-wide shared library file is found to be group-writable or world-writable, this is a finding.

Fix

Configure the library files to be protected from unauthorized access. Run the following command, replacing "[file]" with any library file with a mode more permissive than 0755.

# sudo chmod 0755 [file]
V-75607 No Change
Findings ID: UBTU-16-011010 Rule ID: SV-90287r2_rule Severity: medium CCI: CCI-001499

Discussion

If the Ubuntu operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.

This requirement applies to Ubuntu operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Checks

Verify the system-wide shared library files are owned by "root".

Check that the system-wide shared library files are owned by "root" with the following command:

# sudo find /lib /usr/lib /lib64 ! -user root | xargs ls -la

If any system wide shared library file is returned, this is a finding.

Fix

Configure the system-wide shared library files (/lib, /usr/lib, /lib64) to be protected from unauthorized access.

Run the following command, replacing "[FILE]" with any library file not owned by "root".

# sudo chown root [FILE]
V-75609 No Change
Findings ID: UBTU-16-011020 Rule ID: SV-90289r2_rule Severity: medium CCI: CCI-001499

Discussion

If the Ubuntu operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.

This requirement applies to Ubuntu operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Checks

Verify the system-wide shared library files contained in the following directories are group-owned by "root".

Check that the system-wide shared library files are group-owned by "root" with the following command:

# sudo find /lib /usr/lib /lib64 ! -group root | xargs ls -la

If any system wide shared library file is returned, this is a finding.

Fix

Configure the library files to be protected from unauthorized access.

Run the following command, replacing "[FILE]" with any library file not group-owned by root.

# sudo chgrp root [FILE]
V-75611 No Change
Findings ID: UBTU-16-011030 Rule ID: SV-90291r2_rule Severity: medium CCI: CCI-001499

Discussion

If the Ubuntu operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.

This requirement applies to Ubuntu operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Checks

Verify the system commands contained in the following directories have mode "0755" or less permissive.

Check that the system command files contained in the following directories have mode "0755" or less permissive with the following command:

# find -L /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin -perm /022 | xargs ls -la

If any system commands are found to be group-writable or world-writable, this is a finding.

Fix

Configure the system commands to be protected from unauthorized access.

Run the following command, replacing "[FILE]" with any system command with a mode more permissive than "0755".

# sudo chmod 0755 [FILE]
V-75613 No Change
Findings ID: UBTU-16-011040 Rule ID: SV-90293r2_rule Severity: medium CCI: CCI-001499

Discussion

If the Ubuntu operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.

This requirement applies to Ubuntu operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Checks

Verify the system commands contained in the following directories are owned by "root".

Check that the system command files contained in the following directories are owned by "root" with the following command:

# sudo find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -user root | xargs ls -la

If any system commands are returned, this is a finding.

Fix

Configure the system commands to be protected from unauthorized access.

Run the following command, replacing "[FILE]" with any system command file not owned by "root".

# sudo chown root [FILE]
V-75615 No Change
Findings ID: UBTU-16-011050 Rule ID: SV-90295r2_rule Severity: medium CCI: CCI-001499

Discussion

If the Ubuntu operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process.

This requirement applies to Ubuntu operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals shall be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.

Checks

Verify the system commands contained in the following directories are group-owned by "root".

Check that the system command files contained in the following directories are group-owned by "root" with the following command:

# sudo find /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin ! -group root | xargs ls -la

If the command returns any files that are not group-owned by "root", and if they are not SGID and owned by a privileged group, this is a finding.

Fix

Configure the system commands to be protected from unauthorized access.

Run the following command, replacing "[FILE]" with any system command file not group-owned by "root".

# sudo chgrp root [FILE]
V-75617 No Change
Findings ID: UBTU-16-020000 Rule ID: SV-90297r1_rule Severity: medium CCI: CCI-000130

Discussion

Without establishing what type of events occurred, the source of events, where events occurred, and the outcome of events, it would be difficult to establish, correlate, and investigate the events leading up to an outage or attack.

Audit record content that may be necessary to satisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.

Associating event types with detected events in the Ubuntu operating system audit logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured Ubuntu operating system.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000038-GPOS-00016, SRG-OS-000039-GPOS-00017, SRG-OS-000040-GPOS-00018, SRG-OS-000041-GPOS-00019, SRG-OS-000042-GPOS-00021, SRG-OS-000051-GPOS-00024, SRG-OS-000054-GPOS-00025, SRG-OS-000122-GPOS-00063, SRG-OS-000254-GPOS-00095, SRG-OS-000255-GPOS-00096, SRG-OS-000337-GPOS-00129, SRG-OS-000348-GPOS-00136, SRG-OS-000349-GPOS-00137, SRG-OS-000350-GPOS-00138, SRG-OS-000351-GPOS-00139, SRG-OS-000352-GPOS-00140, SRG-OS-000353-GPOS-00141, SRG-OS-000354-GPOS-00142, SRG-OS-000358-GPOS-00145, SRG-OS-000365-GPOS-00152, SRG-OS-000392-GPOS-00172, SRG-OS-000475-GPOS-00220

Checks

Verify the audit service is configured to produce audit records.

Check that the audit service is installed properly with the following command:

# dpkg -l | grep auditd

If the "auditd" package is not installed, this is a finding.

Check that the audit service is properly running and active on the system with the following command:

# systemctl is-active auditd.service
active

If the command above returns "inactive", this is a finding.

Fix

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

Restart the audit service with the following command:

# sudo systemctl restart auditd.service
V-75621 No Change
Findings ID: UBTU-16-020020 Rule ID: SV-90301r2_rule Severity: medium CCI: CCI-001849

Discussion

In order to ensure Ubuntu operating systems have a sufficient storage capacity in which to write the audit logs, Ubuntu operating systems need to be able to allocate audit record storage capacity.

The task of allocating audit record storage capacity is usually performed during initial installation of the Ubuntu operating system.

Checks

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:

# 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:

#du –sh [audit_partition]
1.8G /var/log/audit

Note: The partition size needed to capture a week's worth of audit records is based on the activity level of the system and the total storage capacity available. In normal circumstances, 10.0 GB of storage space for audit records will be sufficient.

If the audit record partition is not allocated for sufficient storage capacity, this is a finding.

Fix

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 "X" 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.
V-75623 No Change
Findings ID: UBTU-16-020030 Rule ID: SV-90303r2_rule Severity: medium CCI: CCI-001855

Discussion

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

Checks

Verify the Ubuntu operating system notifies the System Administrator (SA) and Information System Security Officer (ISSO) (at a minimum) via email when allocated audit record storage volume reaches 75% of the repository maximum audit record storage capacity.

Check that the Ubuntu operating system notifies the SA and ISSO (at a minimum) via email when allocated audit record storage volume reaches 75% of the repository maximum audit record storage capacity with the following commands:

#sudo grep space_left_action /etc/audit/auditd.conf

space_left_action email

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 parameter /etc/audit/auditd.conf

action_mail_acct parameter [email protected]

If the space_left_action or the action_mail_accnt parameters are set to blanks, this is a finding.

If the space_left_action is set to "syslog", the system logs the event, this is not 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.

The action_mail_acct parameter, if missing, defaults to "root". If the "action_mail_acct parameter" is not set to the e-mail address of the system administrator(s) and/or ISSO, this is a finding.

Note: If the email address of the system administrator is on a remote system a mail package must be available.

Fix

Configure the operating system to immediately notify the SA and ISSO (at a minimum) via email when allocated audit record storage volume reaches 75% of the repository maximum audit record storage capacity.

Edit "/etc/audit/auditd.conf" and set the "space_left_action" parameter to "exec", "email", or "syslog". If the "space_left_action" parameter is set to "email" set the "action_mail_acct" parameter to an e-mail address for the System Administrator (SA) and Information System Security Officer (ISSO).
V-75625 No Change
Findings ID: UBTU-16-020040 Rule ID: SV-90305r2_rule Severity: medium CCI: CCI-000139

Discussion

It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected.

Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.

This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.

Checks

Verify that the System Administrator (SA) and Information System Security Officer (ISSO) (at a minimum) are notified in the event of an audit processing failure.

Check that the Ubuntu operating system notifies the SA and ISSO (at a minimum) in the event of an audit processing failure with the following command:

#sudo grep space_left_action /etc/audit/auditd.conf

action_mail_acct = root

If the value of the "action_mail_acct" keyword is not set to "root" and/or other accounts for security personnel, the "action_mail_acct" keyword is missing, or the retuned line is commented out, this is a finding.

Fix

Configure "auditd" service to notify the System Administrator (SA) and Information System Security Officer (ISSO) in the event of an audit processing failure.

Edit the following line in "/etc/audit/auditd.conf" to ensure that administrators are notified via email for those situations:

action_mail_acct = root
V-75627 No Change
Findings ID: UBTU-16-020050 Rule ID: SV-90307r1_rule Severity: medium CCI: CCI-000140

Discussion

It is critical that when the Ubuntu operating system is at risk of failing to process audit logs as required, it takes action to mitigate the failure. Audit processing failures include: software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode.

When availability is an overriding concern, other approved actions in response to an audit failure are as follows:

1) If the failure was caused by the lack of audit record storage capacity, the Ubuntu operating system must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner.

2) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the Ubuntu operating system must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.

Checks

Verify that the System Administrator (SA) and Information System Security Officer (ISSO) (at a minimum) are notified when the audit storage volume is full.

Check which action the Ubuntu operating system takes when the audit storage volume is full with the following command:

# sudo grep max_log_file_action /etc/audit/auditd.conf

max_log_file_action=syslog

If the value of the "max_log_file_action" option is set to "ignore", "rotate", or "suspend", or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to notify the System Administrator (SA) and Information System Security Officer (ISSO) when the audit storage volume is full by configuring the "max_log_file_action" parameter in the "/etc/audit/auditd.conf" file with the a value of "syslog" or "keep_logs":

max_log_file_action=syslog
V-75629 No Change
Findings ID: UBTU-16-020060 Rule ID: SV-90309r2_rule Severity: medium CCI: CCI-000140

Discussion

It is critical that when the Ubuntu operating system is at risk of failing to process audit logs as required, it takes action to mitigate the failure. Audit processing failures include: software/hardware errors; failures in the audit capturing mechanisms; and audit storage capacity being reached or exceeded. Responses to audit failure depend upon the nature of the failure mode.

When availability is an overriding concern, other approved actions in response to an audit failure are as follows:

1) If the failure was caused by the lack of audit record storage capacity, the Ubuntu operating system must continue generating audit records if possible (automatically restarting the audit service if necessary), overwriting the oldest audit records in a first-in-first-out manner.

2) If audit records are sent to a centralized collection server and communication with this server is lost or the server fails, the Ubuntu operating system must queue audit records locally until communication is restored or until the audit records are retrieved manually. Upon restoration of the connection to the centralized collection server, action should be taken to synchronize the local audit data with the collection server.

Checks

Verify the Ubuntu operating system takes the appropriate action when the audit storage volume is full.

Check that the Ubuntu operating system takes the appropriate action when the audit storage volume is full with the following command:

# sudo grep disk_full_action /etc/audit/auditd.conf

disk_full_action = HALT

If the value of the "disk_full_action" option is not "SYSLOG", "SINGLE", or "HALT", or the line is commented out, this is a finding.

Fix

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" or "SINGLE" depending on configuration) in "/etc/audit/auditd.conf" file:

disk_full_action = HALT
V-75631 Updated
Findings ID: UBTU-16-020070 Rule ID: SV-90311r12_rule Severity: medium CCI: CCI-001851

Discussion

Information stored in one location is vulnerable to accidental or incidental deletion or alteration.

Off-loading is a common process in information systems with limited audit storage capacity.

Checks

Verify the action that the remote audit system takes when the storage volume becomes full.

Check the action that the
remote audit system takes when the storage volume becomes full with the following command:

# sudo grep disk_full /etc/audisp/audisp-remote.conf

disk_full_action = single

If the value of the "disk_full_action" option is not "syslog", "single", or "halt", or the line is commented out, this is a finding.

Fix

Configure the remote audit system to take an appropriate action when the audit storage is full.

Add, edit or uncomment the "disk_full_action" option in "/etc/audisp/audisp-remote.conf". Set it to "syslog", "single" or "halt" like the below example:

disk_full_action = single
V-75633 No Change
Findings ID: UBTU-16-020080 Rule ID: SV-90313r1_rule Severity: medium CCI: CCI-001851

Discussion

Information stored in one location is vulnerable to accidental or incidental deletion or alteration.

Off-loading is a common process in information systems with limited audit storage capacity.

Checks

Verify the audit system authenticates off-loading audit records to a different system.

Check that the off-loading of audit records to a different system is authenticated with the following command:

# sudo grep enable /etc/audisp/audisp-remote.conf

enable_krb5 = yes

If “enable_krb5” option is not set to "yes" or the line is commented out, this is a finding.

Fix

Configure the audit system to authenticate off-loading audit records to a different system.

Uncomment the "enable_krb5" option in "/etc/audisp/audisp-remote.conf" and set it to "yes". See the example below.

enable_krb5 = yes
V-75635 No Change
Findings ID: UBTU-16-020090 Rule ID: SV-90315r2_rule Severity: medium CCI: CCI-000162

Discussion

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality.

Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit Ubuntu operating system activity.

Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Checks

Verify the audit logs have a mode of "0600" or less permissive.

First 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 location of the audit log file, check if the audit log has a mode of "0600" or less permissive with the following command:

# sudo stat -c "%a %n" /var/log/audit/audit.log

600 /var/log/audit/audit.log

If the audit log has a mode more permissive than "0600", this is a finding.

Fix

Configure the audit log to be protected from unauthorized read access by setting the correct permissive mode with the following command:

# sudo chmod 0600 [audit_log_file]

Replace "[audit_log_file]" to the correct audit log path, by default this location is "/var/log/audit/audit.log".
V-75637 No Change
Findings ID: UBTU-16-020100 Rule ID: SV-90317r2_rule Severity: medium CCI: CCI-000162

Discussion

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality.

Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit Ubuntu operating system activity.

Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Checks

Verify the audit log directories have a mode of "0750" or less permissive by first determining 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 location of the audit log, determine the directory where the audit logs are stored (ex: "/var/log/audit"). Run the following command to determine the permissions for the audit log folder:

# sudo stat -c "%a %n" /var/log/audit
750 /var/log/audit

If the audit log directory has a mode more permissive than "0750", this is a finding.

Fix

Configure the audit log directory to be protected from unauthorized read access by setting the correct permissive mode with the following command:

# sudo chmod 0750 [audit_log_directory]

Replace "[audit_log_directory]" to the correct audit log directory path, by default this location is "/var/log/audit".
V-75639 No Change
Findings ID: UBTU-16-020110 Rule ID: SV-90319r2_rule Severity: medium CCI: CCI-000162

Discussion

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality.

Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit Ubuntu operating system activity.

Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Checks

Verify the audit logs are owned by "root". First 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 location of the audit log file, determine if the audit log is owned by "root" using the following command:

# sudo ls -la /var/log/audit/audit.log
rw------- 2 root root 8096 Jun 26 11:56 /var/log/audit/audit.log

If the audit log is not owned by "root", this is a finding.

Fix

Configure the audit log to be protected from unauthorized read access, by setting the correct owner as "root" with the following command:

# sudo chown root [audit_log_file]

Replace "[audit_log_file]" to the correct audit log path, by default this location is "/var/log/audit/audit.log".
V-75641 No Change
Findings ID: UBTU-16-020120 Rule ID: SV-90321r2_rule Severity: medium CCI: CCI-000162

Discussion

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality.

Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit Ubuntu operating system activity.

Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029, SRG-OS-000206-GPOS-00084

Checks

Verify the audit logs are group-owned by "root". First 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 location of the audit log file, determine if the audit log is group-owned by "root" using the following command:

# sudo ls -la /var/log/audit/audit.log
rw------- 2 root root 8096 Jun 26 11:56 /var/log/audit/audit.log

If the audit log is not group-owned by "root", this is a finding.

Fix

Configure the audit log to be protected from unauthorized read access, by setting the correct group-owner as "root" with the following command:

# sudo chgrp root [audit_log_file]

Replace "[audit_log_file]" to the correct audit log path, by default this location is "/var/log/audit/audit.log".
V-75643 No Change
Findings ID: UBTU-16-020130 Rule ID: SV-90323r2_rule Severity: medium CCI: CCI-000162

Discussion

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality.

Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit Ubuntu operating system activity.

Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Checks

Verify the audit log directory is owned by "root" to prevent unauthorized read access.

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

Determine the audit log directory by using the output of the above command (ex: "/var/log/audit/"). Run the following command with the correct audit log directory path:

# sudo ls -ld /var/log/audit
drwxr-x--- 2 root root 8096 Jun 26 11:56 /var/log/audit

If the audit log directory is not owned by "root", this is a finding.

Fix

Configure the audit log to be protected from unauthorized read access, by setting the correct owner as "root" with the following command:

# sudo chown root [audit_log_directory]

Replace "[audit_log_directory]" with the correct audit log directory path, by default this location is usually "/var/log/audit".
V-75645 No Change
Findings ID: UBTU-16-020140 Rule ID: SV-90325r2_rule Severity: medium CCI: CCI-000162

Discussion

Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality.

Audit information includes all information (e.g., audit records, audit settings, audit reports) needed to successfully audit Ubuntu operating system activity.

Satisfies: SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029

Checks

Verify the audit log directory is group-owned by "root" to prevent unauthorized read access.

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

Determine the audit log directory by using the output of the above command (ex: "/var/log/audit/"). Run the following command with the correct audit log directory path:

# sudo ls -ld /var/log/audit
drwxr-x--- 2 root root 8096 Jun 26 11:56 /var/log/audit

If the audit log directory is not group-owned by "root", this is a finding.

Fix

Configure the audit log to be protected from unauthorized read access, by setting the correct group-owner as "root" with the following command:

# sudo chgrp root [audit_log_directory]

Replace "[audit_log_directory]" with the correct audit log directory path, by default this location is usually "/var/log/audit".
V-75647 No Change
Findings ID: UBTU-16-020150 Rule ID: SV-90327r1_rule Severity: medium CCI: CCI-000171

Discussion

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

Checks

Verify that the /etc/audit/audit.rule and /etc/audit/auditd.conf file have a mode of 0640 or less permissive by using the following command:

# sudo ls -la /etc/audit/audit.rules

-rw-r----- 1 root root 1280 Feb 16 17:09 audit.rules
-rw-r----- 1 root root 621 Sep 22 2014 auditd.conf

If the "/etc/audit/audit.rule" or "/etc/audit/auditd.conf" file have a mode more permissive than "0640", this is a finding.

Fix

Configure the /etc/audit/audit.rule and /etc/audit/auditd.conf file to have a mode of 0640 with the following command:

# sudo chmod 0640 /etc/audit/audit.rule
# sudo chmod 0640 /etc/audit/audit.conf
V-75649 No Change
Findings ID: UBTU-16-020160 Rule ID: SV-90329r2_rule Severity: medium CCI: CCI-001314

Discussion

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the Ubuntu operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.

The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Checks

Verify the audit log files are owned by "root".

Check where the audit logs are stored on the system using the following command:

# sudo grep log_file /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log

Using the audit log path from the command above, replace "[log_path]" in the following command:

# sudo ls -la [log_path] | cut -d' ' -f3
root

If the audit logs are not group-owned by "root", this is a finding.

Fix

Change the owner of the audit log file by running the following command:

Use the following command to get the audit log path:

# sudo grep log_file /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log

Using the audit log path from the command above, replace "[log_path]" in the following command:

# sudo chown root [log_path]
V-75653 No Change
Findings ID: UBTU-16-020180 Rule ID: SV-90333r2_rule Severity: medium CCI: CCI-001493

Discussion

Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information.

Ubuntu operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools.

Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Satisfies: SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099

Checks

Verify the audit tools are protected from unauthorized access, deletion, or modification by checking the permissive mode.

Check the octal permission of each audit tool by running the following command:

#stat -c "%a %n" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules

755 /sbin/augenrules

If any of the audit tools has a mode more permissive than "0755", this is a finding.

Fix

Configure the audit tools 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 permissive mode.
V-75655 No Change
Findings ID: UBTU-16-020190 Rule ID: SV-90335r2_rule Severity: medium CCI: CCI-001493

Discussion

Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information.

Ubuntu operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools.

Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Satisfies: SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099

Checks

Verify the audit tools are owned by "root" to prevent any unauthorized access, deletion, or modification.

Check the owner of each audit tool by running the following command:

# ls -la /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules
-rwxr-xr-x 1 root root 97128 Jan 18 2016 /sbin/augenrules

If any of the audit tools are not owned by "root", this is a finding.

Fix

Configure the audit tools to be owned by "root", by running the following command:

# sudo chown root [audit_tool]

Replace "[audit_tool]" with each audit tool not owned by "root".
V-75657 No Change
Findings ID: UBTU-16-020200 Rule ID: SV-90337r2_rule Severity: medium CCI: CCI-001493

Discussion

Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit information.

Ubuntu operating systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools.

Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Satisfies: SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099

Checks

Verify the audit tools are group-owned by "root" to prevent any unauthorized access, deletion, or modification.

Check the owner of each audit tool by running the following commands:

# ls -la /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules
-rwxr-xr-x 1 root root 97128 Jan 18 2016 /sbin/augenrules

If any of the audit tools are not group-owned by "root", this is a finding.

Fix

Configure the audit tools to be group-owned by "root", by running the following command:

# sudo chgrp root [audit_tool]

Replace "[audit_tool]" with each audit tool not group-owned by "root".
V-75659 No Change
Findings ID: UBTU-16-020210 Rule ID: SV-90339r2_rule Severity: medium CCI: CCI-001851

Discussion

Information stored in one location is vulnerable to accidental or incidental deletion or alteration.

Off-loading is a common process in information systems with limited audit storage capacity.

Checks

Verify the audit event multiplexor is configured to off-load audit records to a different system or storage media from the system being audited.

Check that the records are being off-loaded 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.

Fix

Configure the audit event multiplexor to off-load audit records to a different system or storage media from the system being audited.

Set the "active" option in "/etc/audisp/plugins.d/au-remote.conf" to "yes":

active = yes

In order for the changes to take effect, the audit daemon must be restarted. The audit daemon can be restarted with the following command:

# sudo systemctl restart auditd.service
V-75661 Updated
Findings ID: UBTU-16-020300 Rule ID: SV-90341r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd".

Check the auditing rules in "/etc/audit/audit.rules" with the following command:

# sudo grep /etc/passwd /etc/audit/audit.rules

-w /etc/passwd -p wa -k audit_rules_usergroup_modification

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/passwd".

Add or update the following file system rule to "/etc/audit/audit.rules":

-w /etc/passwd -p wa -k identity

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75663 Updated
Findings ID: UBTU-16-020310 Rule ID: SV-90343r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group".

Check the auditing rules in "/etc/audit/audit.rules" with the following command:

# sudo grep /etc/group /etc/audit/audit.rules

-w /etc/group -p wa -k audit_rules_usergroup_modification

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/group".

Add or update the following file system rule to "/etc/audit/audit.rules":

-w /etc/group -p wa -k identity

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75665 Updated
Findings ID: UBTU-16-020320 Rule ID: SV-90345r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow".

Check the auditing rules in "/etc/audit/audit.rules" with the following command:

# sudo grep /etc/gshadow /etc/audit/audit.rules

-w /etc/gshadow -p wa -k audit_rules_usergroup_modification

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/gshadow".

Add or update the following file system rule to "/etc/audit/audit.rules":

-w /etc/gshadow -p wa -k identity

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75667 Updated
Findings ID: UBTU-16-020330 Rule ID: SV-90347r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/shadow".

Check the auditing rules in "/etc/audit/audit.rules" with the following command:

# sudo grep /etc/shadow /etc/audit/audit.rules

-w /etc/shadow -p wa -k audit_rules_usergroup_modification

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/shadow".

Add or update the following file system rule to "/etc/audit/audit.rules":

-w /etc/shadow -p wa -k identity

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75687 Updated
Findings ID: UBTU-16-020340 Rule ID: SV-90367r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd".

Check the auditing rules in "/etc/audit/audit.rules" with the following command:

# sudo grep /etc/security/opasswd /etc/audit/audit.rules

-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to generate audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd".

Add or update the following file system rule to "/etc/audit/audit.rules":

-w /etc/security/opasswd -p wa -k identity

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75691 Updated
Findings ID: UBTU-16-020360 Rule ID: SV-90371r34_rule Severity: medium CCI: CCI-000130

Discussion

Without establishing what type of events occurredgenerating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events leadrelating up to an outage or attack.

Audit record content that may be necessary to sa
incident or identisfy this requirement includes, for example, time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail indications, filenames involved, and access control or flow control rules invoked.

Associating event types with detected events in the Ubuntu operating system audit logs provides a means of investigating an attack; recognizing resource utilization or capacity thresholds; or identifying an improperly configured Ubuntu operating system
ose responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter)
.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000064-GPOS-0003, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates audit records when successful/unsuccessful attempts to use the "su" command occur.

Check for the following system call being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -iw /bin/su /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/bin/su -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-priv_change
-a always,exit -F arch=b64
path=/bin/su -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-priv_change

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to generate audit records when successful/unsuccessful attempts to use the "su" command occur.

Add or update the following rule in "/etc/audit/audit.rules":

-a always,exit -F
arch=b32 path=/bin/su -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-priv_change
-a always,exit -F arch=b64 path=/bin/su -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-priv_change


The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75693 Updated
Findings ID: UBTU-16-020370 Rule ID: SV-90373r34_rule Severity: medium CCI: CCI-000130

Discussion

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

At a minimum, the organization must audit the full-text recording of privileged password commands. The organization must maintain audit trails in suffi
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident detail to reconstruct events to determine the cause and impact of compromiseor identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter)
.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify that an audit event is generated for any successful/unsuccessful use of the "chfn" command.

Check for the following system call being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep chfn /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/usr/bin/chfn -F perm=x -F auid>=100500 -F auid!=4294967295 -k privileged-gpasswdchfn
-a always,exit -F arch=b64 path=/usr/bin/chfn -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-chfn


If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "passwd" command. Add or update the following rule in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/usr/bin/chfn -F perm=x -F auid>=100500 -F auid!=4294967295 -k privileged-passwdchfn
-a always,exit -F arch=b64 path=/usr/bin/chfn -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged-chfn


The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75695 Updated
Findings ID: UBTU-16-020380 Rule ID: SV-90375r34_rule Severity: low CCI: CCI-000130

Discussion

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in suffi
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident detail to reconstruct events to determine the cause and impact of compromiseor identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter)
.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify that an audit event is generated for any successful/unsuccessful use of the "mount" command.

Check for the following system call being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w mount /etc/audit/audit.rules

-a always,exit -F
path=/bin/mount -F perm=xarch=32 -S mount -F auid>=1000 -F auid!=4294967295 -k privileged-mount
-a always,exit -F arch=64 -S mount
-F auid>=1000 -F auid!=4294967295 -k privileged-mount

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "mount" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
path=/bin/mount -F perm=xarch=32 -S mount -F auid>=1000 -F auid!=4294967295 -k privileged-mount
-a always,exit -F arch=64 -S mount
-F auid>=1000 -F auid!=4294967295 -k privileged-mount

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75697 Updated
Findings ID: UBTU-16-020390 Rule ID: SV-90377r34_rule Severity: medium CCI: CCI-000135

Discussion

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in suffi
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident detail to reconstruct events to determine the cause and impact of compromiseor identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter)
.

Satisfies: SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000471-GPOS-00215

Checks

Verify that an audit event is generated for any successful/unsuccessful use of the "umount" command.

Check for the following system call being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep umount /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/bin/umount -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-mount
-a always,exit -F arch=b64
path=/bin/umount -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-mount

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "umount" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/bin/umount -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-mount
-a always,exit -F arch=b64
path=/bin/umount -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-mount

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75699 Updated
Findings ID: UBTU-16-020400 Rule ID: SV-90379r34_rule Severity: medium CCI: CCI-000130

Discussion

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

At a minimum, the organization must audit the full-text recording of privileged ssh commands. The organization must maintain audit trails in suffi
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident detail to reconstruct events to determine the cause and impact of compromiseor identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter)
.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "ssh-agent" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep ssh-agent /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-ssh
-a always,exit -F arch=b64
path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-ssh

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ssh-agent" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-ssh
-a always,exit -F arch=b64
path=/usr/bin/ssh-agent -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-ssh

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75707 Updated
Findings ID: UBTU-16-020410 Rule ID: SV-90387r34_rule Severity: medium CCI: CCI-000130

Discussion

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

At a minimum, the organization must audit the full-text recording of privileged ssh commands. The organization must maintain audit trails in suffi
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident detail to reconstruct events to determine the cause and impact of compromiseor identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter)
.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "ssh-keysign" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep ssh-keysign /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/usr/lib/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-ssh
-a always,exit -F arch=b64
path=/usr/lib/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-ssh

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ssh-keysign" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/usr/lib/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-ssh
-a always,exit -F arch=b64
path=/usr/lib/openssh/ssh-keysign -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-ssh

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75709 No Change
Findings ID: UBTU-16-020420 Rule ID: SV-90389r2_rule Severity: medium CCI: CCI-000130

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.

DoD has defined the list of events for which the Ubuntu operating system will provide an audit record generation capability as the following:

1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);

2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;

3) All account creations, modifications, disabling, and terminations; and

4) All kernel module load, unload, and restart actions.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222

Checks

Verify if the Ubuntu operating system is configured to audit the execution of the module management program "insmod", by running the following command:

# sudo grep "/sbin/insmod" /etc/audit/audit.rules

-w /sbin/insmod -p x -k modules

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to audit the execution of the module management program "insmod", by adding the following line to "/etc/audit/audit.rules":

-w /sbin/insmod -p x -k modules

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75711 No Change
Findings ID: UBTU-16-020430 Rule ID: SV-90391r2_rule Severity: medium CCI: CCI-000130

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.

DoD has defined the list of events for which the Ubuntu operating system will provide an audit record generation capability as the following:

1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);

2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;

3) All account creations, modifications, disabling, and terminations; and

4) All kernel module load, unload, and restart actions.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222

Checks

Verify if the Ubuntu operating system is configured to audit the execution of the module management program "rmmod", by running the following command:

# sudo grep "/sbin/rmmod" /etc/audit/audit.rules

-w /sbin/rmmod -p x -k modules

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to audit the execution of the module management program "rmmod", by adding the following line to "/etc/audit/audit.rules":

-w /sbin/rmmod -p x -k modules

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75713 No Change
Findings ID: UBTU-16-020440 Rule ID: SV-90393r2_rule Severity: medium CCI: CCI-000130

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.

DoD has defined the list of events for which the Ubuntu operating system will provide an audit record generation capability as the following:

1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);

2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;

3) All account creations, modifications, disabling, and terminations; and

4) All kernel module load, unload, and restart actions.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify if the Ubuntu operating system is configured to audit the execution of the module management program "modprobe", by running the following command:

# sudo grep "/sbin/modprobe" /etc/audit/audit.rules

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

Fix

Configure the Ubuntu operating system to audit the execution of the module management program "modprobe", by adding the following line to "/etc/audit/audit.rules":

-w /sbin/modprobe -p x -k modules

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75715 No Change
Findings ID: UBTU-16-020450 Rule ID: SV-90395r2_rule Severity: medium CCI: CCI-000130

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.

DoD has defined the list of events for which the Ubuntu operating system will provide an audit record generation capability as the following:

1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);

2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;

3) All account creations, modifications, disabling, and terminations; and

4) All kernel module load, unload, and restart actions.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify if the Ubuntu operating system is configured to audit the execution of the module management program "kmod", by running the following command:

# sudo grep "/bin/kmod" /etc/audit/audit.rules

-w /bin/kmod -p x -k modules

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to audit the execution of the module management program "kmod" by adding the following line to "/etc/audit/audit.rules":

-w /bin/kmod -p x -k modules

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75717 Updated
Findings ID: UBTU-16-020460 Rule ID: SV-90397r23_rule Severity: medium CCI: CCI-000130

Discussion

Without the capability to generateing audit records, it would be d that are specifficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.

DoD has defined the list of events for which the Ubu
the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incidentu operating system will provide an audit record generation capability as the following:

1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);

2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;

3) All account creations, modifications, disabling, and terminations; and

4) All kernel module load, unload, and restart actions
r identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter)
.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify if the Ubuntu operating system is configured to audit the execution of the "setxattr" system call, by running the following command:

# sudo grep -w setxattr /etc/audit/audit.rules

-
a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b32 -S setxattr -F auid=0 -k perm_mod
-a always,exit -F arch=b64 -S setxattr -F auid=0 -k perm_mod

If the command does not return a
ll lines, or the line iss are commented out, this is a finding.

Fix

Configure the Ubuntu operating system to audit the execution of the "setxattr" system call, by adding the following lines to "/etc/audit/audit.rules":

-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b32 -S setxattr -F auid=0 -k perm_mod
-a always,exit -F arch=b64 -S setxattr -F auid=0 -k perm_mod

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75719 Updated
Findings ID: UBTU-16-020470 Rule ID: SV-90399r23_rule Severity: medium CCI: CCI-000130

Discussion

Without the capability to generateing audit records, it would be d that are specifficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.

DoD has defined the list of events for which the Ubu
the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incidentu operating system will provide an audit record generation capability as the following:

1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);

2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;

3) All account creations, modifications, disabling, and terminations; and

4) All kernel module load, unload, and restart actions
r identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter)
.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219

Checks

Verify if the Ubuntu operating system is configured to audit the execution of the "lsetxattr" system call, by running the following command:

# sudo grep -w lsetxattr /etc/audit/audit.rules

-a always,exit -F arch=b
64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -k perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -k perm_mod


If the command does not return a
ll lines, or the line iss are commented out, this is a finding.

Fix

Configure the Ubuntu operating system to audit the execution of the "lsetxattr" system call, by adding the following lines to "/etc/audit/audit.rules":

-a always,exit -F arch=b
64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b32 -S lsetxattr -F auid=0 -k perm_mod

-a always,exit -F arch=b64 -S lsetxattr -F auid=0 -k perm_mod


The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75721 Updated
Findings ID: UBTU-16-020480 Rule ID: SV-90401r23_rule Severity: medium CCI: CCI-000130

Discussion

Without the capability to generateing audit records, it would be d that are specifficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.

DoD has defined the list of events for which the Ubu
the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incidentu operating system will provide an audit record generation capability as the following:

1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);

2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;

3) All account creations, modifications, disabling, and terminations; and

4) All kernel module load, unload, and restart actions
r identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter)
.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219

Checks

Verify if the Ubuntu operating system is configured to audit the execution of the "fsetxattr" system call, by running the following command:

# sudo grep -w fsetxattr /etc/audit/audit.rules

-a always,exit -F arch=b
6432 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0>=1000 -F auid!=4294967295 -k perm_mod

If the command does not return a line, or the line is-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -k perm_mod
-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -k perm_mod

If the command does not return all lines, or the lines are
commented out, this is a finding.

Fix

Configure the Ubuntu operating system to audit the execution of the "fsetxattr" system call, by adding the following lines to "/etc/audit/audit.rules":

-a always,exit -F arch=b
64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b32 -S fsetxattr -F auid=0 -k perm_mod

-a always,exit -F arch=b64 -S fsetxattr -F auid=0 -k perm_mod

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75723 Updated
Findings ID: UBTU-16-020490 Rule ID: SV-90403r23_rule Severity: medium CCI: CCI-000130

Discussion

Without the capability to generateing audit records, it would be d that are specifficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.

DoD has defined the list of events for which the Ubu
the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incidentu operating system will provide an audit record generation capability as the following:

1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);

2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;

3) All account creations, modifications, disabling, and terminations; and

4) All kernel module load, unload, and restart actions
r identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter)
.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219

Checks

Verify if the Ubuntu operating system is configured to audit the execution of the "removexattr" system call, by running the following command:

# sudo grep -w removexattr /etc/audit/audit.rules

-a always,exit -F arch=b
6432 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0>=1000 -F auid!=4294967295 -k perm_mod

If the command does not return a line, or the line is-a always,exit -F arch=b32 -S removexattr -F auid=0 -k perm_mod
-a always,exit -F arch=b64 -S removexattr -F auid=0 -k perm_mod

If the command does not return all lines, or the lines are
commented out, this is a finding.

Fix

Configure the Ubuntu operating system to audit the execution of the "removexattr" system call, by adding the following lines to "/etc/audit/audit.rules":

-a always,exit -F arch=b
64 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
32 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b32 -S removexattr -F auid=0 -k perm_mod

-a always,exit -F arch=b64 -S removexattr -F auid=0 -k perm_mod


The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75725 Updated
Findings ID: UBTU-16-020500 Rule ID: SV-90405r23_rule Severity: medium CCI: CCI-000130

Discussion

Without the capability to generateing audit records, it would be d that are specifficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.

DoD has defined the list of events for which the Ubu
the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incidentu operating system will provide an audit record generation capability as the following:

1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);

2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;

3) All account creations, modifications, disabling, and terminations; and

4) All kernel module load, unload, and restart actions
r identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter)
.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219

Checks

Verify if the Ubuntu operating system is configured to audit the execution of the "lremovexattr" system call, by running the following command:

# sudo grep -w lremovexattr /etc/audit/audit.rules

-a always,exit -F arch=b
64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -k perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -k perm_mod


If the command does not return a
ll lines, or the line iss are commented out, this is a finding.

Fix

Configure the Ubuntu operating system to audit the execution of the "lremovexattr" system call, by adding the following lines to "/etc/audit/audit.rules":

-a always,exit -F arch=b
64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b32 -S lremovexattr -F auid=0 -k perm_mod

-a always,exit -F arch=b64 -S lremovexattr -F auid=0 -k perm_mod

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75727 Updated
Findings ID: UBTU-16-020510 Rule ID: SV-90407r34_rule Severity: medium CCI: CCI-000130

Discussion

Without the capability to generateing audit records, it would be d that are specifficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.

DoD has defined the list of events for which the Ubu
the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incidentu operating system will provide an audit record generation capability as the following:

1) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels);

2) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system;

3) All account creations, modifications, disabling, and terminations; and

4) All kernel module load, unload, and restart actions
r identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter)
.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219

Checks

Verify if the Ubuntu operating system is configured to audit the execution of the "fremovexattr" system call, by running the following command:

# sudo grep -w fremovexattr /etc/audit/audit.rules

-a always,exit -F arch=b
64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -k perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -k perm_mod

If the command does not return a
ll lines, or the line iss are commented out, this is a finding.

Fix

Configure the Ubuntu operating system to audit the execution of the "fremovexattr" system call by adding the following lines to "/etc/audit/audit.rules":

-a always,exit -F arch=b
64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod

-a always,exit -F arch=b32 -S fremovexattr -F auid=0 -k perm_mod

-a always,exit -F arch=b64 -S fremovexattr -F auid=0 -k perm_mod


The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75729 Updated
Findings ID: UBTU-16-020520 Rule ID: SV-90409r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "chown" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w chown /etc/audit/audit.rules

-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_chng
-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_chng

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chown" command by adding the following line to "/etc/audit/audit.rules":

-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_chng
-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_chng

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75731 Updated
Findings ID: UBTU-16-020530 Rule ID: SV-90411r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "fchown" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w fchown /etc/audit/audit.rules

-a always,exit -F arch=b
6432 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_chngmod
-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod


If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchown" command by adding the following line to "/etc/audit/audit.rules":

-a always,exit -F arch=b
6432 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_chngmod
-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod


The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75733 Updated
Findings ID: UBTU-16-020540 Rule ID: SV-90413r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "fchownat" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w fchownat /etc/audit/audit.rules

-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_chng
-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_chng

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchownat" command by adding the following lines to "/etc/audit/audit.rules":

-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_chng
-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_chng

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75735 Updated
Findings ID: UBTU-16-020550 Rule ID: SV-90415r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "lchown" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w lchown /etc/audit/audit.rules

-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_chng
-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_chng

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "lchown" command by adding the following lines to "/etc/audit/audit.rules":

-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_chng
-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_chng

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75737 No Change
Findings ID: UBTU-16-020560 Rule ID: SV-90417r3_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "chmod" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w chmod /etc/audit/audit.rules

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_chng

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chmod" command by adding the following line to "/etc/audit/audit.rules":

-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_chng

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75739 No Change
Findings ID: UBTU-16-020570 Rule ID: SV-90419r3_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "fchmod" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w fchmod /etc/audit/audit.rules

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_chng

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchmod" command by adding the following line to "/etc/audit/audit.rules":

-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_chng

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75741 Updated
Findings ID: UBTU-16-020580 Rule ID: SV-90421r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "fchmodat" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w fchmodat /etc/audit/audit.rules

-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_chng
-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_chng

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchmodat" command by adding the following lines to "/etc/audit/audit.rules":

-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_chng
-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_chng

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75743 Updated
Findings ID: UBTU-16-020590 Rule ID: SV-90423r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "open" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -iw open /etc/audit/audit.rules

-a always,exit -F arch=b
64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

If the command does not return a
ll lines, or the line iss are commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "open" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F arch=b
64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75745 Updated
Findings ID: UBTU-16-020600 Rule ID: SV-90425r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "truncate" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -iw truncate /etc/audit/audit.rules

-a always,exit -F arch=b
6432 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b64 -S truncate -F exit=-EACCESPERM -F auid>=1000 -F auid!=4294967295 -k perm_access

If the command does not return a line, or the line is-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

If the command does not return all lines, or the lines are
commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "truncate" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F arch=b
64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75747 Updated
Findings ID: UBTU-16-020610 Rule ID: SV-90427r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "ftruncate" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -iw ftruncate /etc/audit/audit.rules

-a always,exit -F arch=b
6432 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCESPERM -F auid>=1000 -F auid!=4294967295 -k perm_access

If the command does not return a line, or the line is-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

If the command does not return all lines, or the lines are
commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "ftruncate" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F arch=b
64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75749 Updated
Findings ID: UBTU-16-020620 Rule ID: SV-90429r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "creat" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -iw creat /etc/audit/audit.rules

-a always,exit -F arch=b
6432 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b64 -S creat -F exit=-EACCESPERM -F auid>=1000 -F auid!=4294967295 -k perm_access

If the command does not return a line, or the line is-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

If the command does not return all lines, or the lines are
commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "creat" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F arch=b
64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75751 Updated
Findings ID: UBTU-16-020630 Rule ID: SV-90431r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "openat" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -iw openat /etc/audit/audit.rules

-a always,exit -F arch=b
64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

If the command does not return a
ll lines, or the line iss are commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "openat" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F arch=b
64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75753 Updated
Findings ID: UBTU-16-020640 Rule ID: SV-90433r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "open_by_handle_at" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -iw open_by_handle_at /etc/audit/audit.rules

-a always,exit -F arch=b
64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

If the command does not return a
ll lines, or the line iss are commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "open_by_handle_at" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F arch=b
64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
32 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access
-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

-a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k perm_access

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75755 Updated
Findings ID: UBTU-16-020650 Rule ID: SV-90435r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify that an audit event is generated for any successful/unsuccessful use of the "sudo" command.

Check for the following system call being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w sudo /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd
-a always,exit -F arch=b64
path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "sudo" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd
-a always,exit -F arch=b64
path=/usr/bin/sudo -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75757 Updated
Findings ID: UBTU-16-020660 Rule ID: SV-90437r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "sudoedit" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w sudoedit /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd
-a always,exit -F arch=b64
path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "sudoedit" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
-arch=b32 path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd
-a always,exit -F -arch=b64
path=/usr/bin/sudoedit -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75759 Updated
Findings ID: UBTU-16-020670 Rule ID: SV-90439r34_rule Severity: medium CCI: CCI-000130

Discussion

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in suffi
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident detail to reconstruct events to determine the cause and impact of compromiseor identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter)
.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "chsh" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w chsh /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd
-a always,exit -F arch=b64
path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chsh" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd
-a always,exit -F arch=b64
path=/usr/bin/chsh -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75761 Updated
Findings ID: UBTU-16-020680 Rule ID: SV-90441r45_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "newgrp" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w newgrp /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd
-a always,exit -F arch=b64
path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd

If the command does not return a line, or the line is commented out, this is a finding.


Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "newgrp" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd
-a always,exit -F arch=b64
path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=4294967295 -k priv_cmd

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75765 Updated
Findings ID: UBTU-16-020700 Rule ID: SV-90445r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "apparmor_parser" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w apparmor_parser /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/sbin/apparmor_parser -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng
-a always,exit -F arch=b64
path=/sbin/apparmor_parser -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "apparmor_parser" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/sbin/apparmor_parser -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng
-a always,exit -F arch=b64
path=/sbin/apparmor_parser -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75767 Updated
Findings ID: UBTU-16-020710 Rule ID: SV-90447r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "setfacl" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w setfacl /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng
-a always,exit -F arch=b64 path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng


If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "setfacl" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng
-a always,exit -F arch=b64 path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng


The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75769 Updated
Findings ID: UBTU-16-020720 Rule ID: SV-90449r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "chacl" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w chacl /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng
-a always,exit -F arch=b64
path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chacl" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng
-a always,exit -F arch=b64
path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75771 No Change
Findings ID: UBTU-16-020730 Rule ID: SV-90451r3_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000473-GPOS-00218

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful modifications to the "tallylog" file occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w tallylog /etc/audit/audit.rules

-w /var/log/tallylog -p wa -k logins

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful modifications to the "tallylog" file occur.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-w /var/log/tallylog -p wa -k logins

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75773 No Change
Findings ID: UBTU-16-020740 Rule ID: SV-90453r3_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000473-GPOS-00218

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful modifications to the "faillog" file occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w faillog /etc/audit/audit.rules

-w /var/log/faillog -p wa -k logins

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful modifications to the "faillog" file occur.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-w /var/log/faillog -p wa -k logins

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75775 No Change
Findings ID: UBTU-16-020750 Rule ID: SV-90455r3_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000473-GPOS-00218

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful modifications to the "lastlog" file occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w lastlog /etc/audit/audit.rules

-w /var/log/lastlog -p wa -k logins

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful modifications to the "lastlog" file occur.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-w /var/log/lastlog -p wa -k logins

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75777 Updated
Findings ID: UBTU-16-020760 Rule ID: SV-90457r34_rule Severity: medium CCI: CCI-000130

Discussion

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in suffi
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident detail to reconstruct events to determine the cause and impact of compromiseor identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter)
.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify that an audit event is generated for any successful/unsuccessful use of the "passwd" command.

Check for the following system call being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w passwd /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-passwd
-a always,exit -F arch=b64
path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-passwd

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "passwd" command. Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-passwd
-a always,exit -F arch=b64
path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-passwd

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75779 No Change
Findings ID: UBTU-16-020770 Rule ID: SV-90459r3_rule Severity: medium CCI: CCI-000130

Discussion

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in sufficient detail to reconstruct events to determine the cause and impact of compromise.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify that an audit event is generated for any successful/unsuccessful use of the "unix_update" command.

Check for the following system call being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w "unix_update" /etc/audit/audit.rules

-a always,exit -F path=/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-unix-update

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "unix_update" command. Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F path=/sbin/unix_update -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-unix-update

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75781 Updated
Findings ID: UBTU-16-020780 Rule ID: SV-90461r34_rule Severity: medium CCI: CCI-000130

Discussion

Reconstruction of harmful events or forensic analysis is not possible if audit records do not contain enough information.

At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in suffi
Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident detail to reconstruct events to determine the cause and impact of compromiseor identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter)
.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify that an audit event is generated for any successful/unsuccessful use of the "gpasswd" command.

Check for the following system call being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w gpasswd /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-gpasswd
-a always,exit -F arch=b64
path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-gpasswd

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "gpasswd" command. Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-gpasswd
-a always,exit -F arch=b64
path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-gpasswd

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75783 Updated
Findings ID: UBTU-16-020790 Rule ID: SV-90463r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify that an audit event is generated for any successful/unsuccessful use of the "chage" command.

Check for the following system call being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w chage /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-chage
-a always,exit -F arch=b64
path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-chage

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "chage" command. Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-chage
-a always,exit -F arch=b64
path=/usr/bin/chage -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-chage

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75785 Updated
Findings ID: UBTU-16-020800 Rule ID: SV-90465r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify that an audit event is generated for any successful/unsuccessful use of the "usermod" command.

Check for the following system call being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w usermod /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-usermod
-a always,exit -F arch=b64
path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-usermod

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "usermod" command. Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-usermod
-a always,exit -F arch=b64
path=/usr/sbin/usermod -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-usermod

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75787 Updated
Findings ID: UBTU-16-020810 Rule ID: SV-90467r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify that an audit event is generated for any successful/unsuccessful use of the "crontab" command.

Check for the following system call being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w crontab /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-crontab
-a always,exit -F arch=b64
path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-crontab

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "crontab" command. Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-crontab
-a always,exit -F arch=b64
path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-crontab

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75789 Updated
Findings ID: UBTU-16-020820 Rule ID: SV-90469r34_rule Severity: medium CCI: CCI-000130

Discussion

At a minimum, the organization must audit the full-text recording of privileged commands. The organization must maintain audit trails in suffiWithout generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident detail to reconstruct events to determine the cause and impact of compromiseor identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter)
.

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify that an audit event is generated for any successful/unsuccessful use of the "pam_timestamp_check" command.

Check for the following system call being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w pam_timestamp_check /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-pam_timestamp_check
-a always,exit -F arch=b64
path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-pam_timestamp_check

If the above command does not return the exact same output displayed in the example, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "pam_timestamp_check" command. Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-pam_timestamp_check
-a always,exit -F arch=b64
path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-pam_timestamp_check

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75791 Updated
Findings ID: UBTU-16-020830 Rule ID: SV-90471r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "init_module" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w "init_module" /etc/audit/audit.rules

-a always,exit -F arch=b32 -S init_module -F auid>=1000 -F auid!=4294967295 -k module_chng
-a always,exit -F arch=b64 -S init_module -F auid>=1000 -F auid!=4294967295 -k module_chng

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "init_module" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F arch=b32 -S init_module -F auid>=1000 -F auid!=4294967295 -k module_chng
-a always,exit -F arch=b64 -S init_module -F auid>=1000 -F auid!=4294967295 -k module_chng

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75793 Updated
Findings ID: UBTU-16-020840 Rule ID: SV-90473r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "finit_module" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w "finit_module" /etc/audit/audit.rules
-a always,exit -F arch=b32 -S finit_module -F auid>=1000 -F auid!=4294967295 -k module_chng
-a always,exit -F arch=b64 -S finit_module -F auid>=1000 -F auid!=4294967295 -k module_chng

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "finit_module" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F arch=b32 -S finit_module -F auid>=1000 -F auid!=4294967295 -k module_chng
-a always,exit -F arch=b64 -S finit_module -F auid>=1000 -F auid!=4294967295 -k module_chng

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75795 Updated
Findings ID: UBTU-16-020850 Rule ID: SV-90475r34_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "delete_module" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w "delete_module" /etc/audit/audit.rules

-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

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "delete_module" command.

Add or update the following rules in the "/etc/audit/audit.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

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-75797 No Change
Findings ID: UBTU-16-030000 Rule ID: SV-90477r2_rule Severity: high CCI: CCI-000197

Discussion

It is detrimental for Ubuntu operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.

Ubuntu operating systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions).

Examples of non-essential capabilities include, but are not limited to, games, software packages, tools, and demonstration software, not related to requirements or providing a wide array of functionality not required for every mission, but which cannot be disabled.

Satisfies: SRG-OS-000074-GPOS-00042, SRG-OS-000095-GPOS-00049

Checks

Verify that the telnet package is not installed on the Ubuntu operating system.

Check that the telnet daemon is not installed on the Ubuntu operating system by running the following command:

# sudo apt list telnetd

If the package is installed, this is a finding.

Fix

Remove the telnet package from the Ubuntu operating system by running the following command:

# sudo apt-get remove telnetd
V-75799 No Change
Findings ID: UBTU-16-030010 Rule ID: SV-90479r2_rule Severity: high CCI: CCI-000381

Discussion

Removing the Network Information Service (NIS) package decreases the risk of the accidental (or intentional) activation of NIS or NIS+ services.

Checks

Verify that the Network Information Service (NIS) package is not installed on the Ubuntu operating system.

Check to see if the NIS package is installed with the following command:

# sudo apt list nis

If the NIS package is installed, this is a finding.

Fix

Configure the Ubuntu operating system to disable non-essential capabilities by removing the Network Information Service (NIS) package from the system with the following command:

# sudo apt-get remove nis
V-75801 No Change
Findings ID: UBTU-16-030020 Rule ID: SV-90481r2_rule Severity: high CCI: CCI-000381

Discussion

It is detrimental for Ubuntu operating systems to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary capabilities or services are often overlooked and therefore may remain unsecured. They increase the risk to the platform by providing additional attack vectors.

Ubuntu operating systems are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions).

The rsh-server service provides an unencrypted remote access service that does not provide for the confidentiality and integrity of user passwords or the remote session and has very weak authentication.

If a privileged user were to log on using this service, the privileged user password could be compromised.

Checks

Verify that the rsh-server package is not installed on the Ubuntu operating system.

Check to see if the rsh-server package is installed with the following command:

# sudo apt list rsh-server

If the rsh-server package is installed, this is a finding.

Fix

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

# sudo apt-get remove rsh-server
V-75803 No Change
Findings ID: UBTU-16-030030 Rule ID: SV-90483r2_rule Severity: medium CCI: CCI-002314

Discussion

Uncomplicated Firewall provides a easy and effective way to block/limit remote access to the system, via ports, services and protocols.

Remote access services, such as those providing remote access to network devices and information systems, which lack automated control capabilities, increase risk and make remote user access management difficult at best.

Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.

Ubuntu operating system functionality (e.g., RDP) must be capable of taking enforcement action if the audit reveals unauthorized activity. Automated control of remote access sessions allows organizations to ensure ongoing compliance with remote access policies by enforcing connection rules of remote access applications on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).

Checks

Verify that the Uncomplicated Firewall is installed.

Check that the Uncomplicated Firewall is installed with the following command:

# sudo apt list ufw

ii ufw 0.35-0Ubuntu2 [installed]

If the "ufw" package is not installed, ask the System Administrator if another application firewall is installed. If no application firewall is installed this is a finding.

Fix

Install Uncomplicated Firewall with the following command:

# sudo apt-get install ufw
V-75805 No Change
Findings ID: UBTU-16-030040 Rule ID: SV-90485r2_rule Severity: medium CCI: CCI-000366

Discussion

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

Checks

Verify the Uncomplicated Firewall is enabled on the system by running the following command:

# sudo systemctl is-enabled ufw

enabled

If the above command returns the status as "disabled", this is a finding.

If the Uncomplicated Firewall is not installed, ask the System Administrator if another application firewall is installed. If no application firewall is installed this is a finding.

Fix

Enable the Uncomplicated Firewall by using the following commands:

# sudo systemctl start ufw

# sudo systemctl enable ufw
V-75807 No Change
Findings ID: UBTU-16-030050 Rule ID: SV-90487r2_rule Severity: medium CCI: CCI-000366

Discussion

Failure to restrict network connectivity only to authorized systems permits inbound connections from malicious systems. It also permits outbound connections that may facilitate exfiltration of DoD data.

Satisfies: SRG-OS-000297-GPOS-00115, SRG-OS-000480-GPOS-00231

Checks

Verify the Uncomplicated Firewall is configured to employ a deny-all, allow-by-exception policy for allowing connections to other systems.

Check the Uncomplicated Firewall configuration with the following command:
# sudo ufw status
Status: active

To Action From
-- ------ ----
[ 1] 22 LIMIT IN Anywhere

If any services, ports, or applications are "allowed" and are not documented with the organization, this is a finding.

Fix

Configure the Uncomplicated Firewall to employ a deny-all, allow-by-exception policy for allowing connections to other systems.

Remove any service that is not needed or documented by the organization with the following command (replace [NUMBER] with the rule number):

# sudo ufw delete [NUMBER]

Another option would be to set the Uncomplicated Firewall back to default with the following commands:

# sudo ufw default deny incoming
# sudo ufw default allow outgoing

Note: UFW’s defaults are to deny all incoming connections and allow all outgoing connections.
V-75809 No Change
Findings ID: UBTU-16-030060 Rule ID: SV-90489r2_rule Severity: medium CCI: CCI-000382

Discussion

In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems.

Ubuntu operating systems are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. Additionally, it is sometimes convenient to provide multiple services from a single component (e.g., VPN and IPS); however, doing so increases risk over limiting the services provided by any one component.

To support the requirements and principles of least functionality, the Ubuntu operating system must support the organizational requirements, providing only essential capabilities and limiting the use of ports, protocols, and/or services to only those required, authorized, and approved to conduct official business or to address authorized quality of life issues.

Checks

Verify the Uncomplicated Firewall is configured to employ a deny-all, allow-by-exception policy for allowing connections to other systems.

Check the Uncomplicated Firewall configuration with the following command:
# sudo ufw status
Status: active

To Action From
-- ------ ----
[ 1] 22 LIMIT IN Anywhere

If any services, ports, or applications are "allowed" and are not documented with the organization, this is a finding.

Fix

Add/Modify the Ubuntu operating system's firewall settings and/or running services to comply with the Ports, Protocols, and Services Management (PPSM) Category Assignments List (CAL).
V-75811 No Change
Findings ID: UBTU-16-030070 Rule ID: SV-90491r4_rule Severity: medium CCI: CCI-001090

Discussion

Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection.

This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DoD or other government agencies.

There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components.

Checks

Verify that all world writable directories have the sticky bit set.

Check to see that all world writable directories have the sticky bit set by running the following command:

# sudo find / -type d \( -perm -0002 -a ! -perm -1000 \) -print 2>/dev/null

drwxrwxrwxt 7 root root 4096 Jul 26 11:19 /tmp

If any of the returned directories are world writable and do not have the sticky bit set, this is a finding.

Fix

Configure all world writable directories have the sticky bit set to prevent unauthorized and unintended information transferred via shared system resources.

Set the sticky bit on all world writable directories using the command, replace "[World-Writable Directory]" with any directory path missing the sticky bit:

# sudo chmod 1777 [World-Writable Directory]
V-75813 No Change
Findings ID: UBTU-16-030100 Rule ID: SV-90493r2_rule Severity: medium CCI: CCI-001891

Discussion

Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate.

Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network.

Organizations should consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints).

Checks

The system clock must be configured to compare the system clock at least every 24 hours to the authoritative time source.

Note: If the system is not networked this item is Not Applicable.

Check the value of "maxpoll" in the "/etc/ntp.conf" file with the following command:

# sudo grep -i maxpoll /etc/ntp.conf
maxpoll = 17

If "maxpoll" is not set to "17" or does not exist, this is a finding.

Verify that the "ntp.conf" file is configured to an authoritative DoD time source by running the following command:

# grep -i server /etc/ntp.conf
server 0.us.pool.ntp.org iburst

If the parameter "server" is not set, is not set to an authoritative DoD time source, or is commented out, this is a finding.

Fix

Note: If the system is not networked this item 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/ntp.conf" file. Add or correct the following lines, by replacing "[source]" in the following line with an authoritative DoD time source.

maxpoll = 17
server [source] iburst

If the "NTP" service was running and the value of "maxpoll" or "server" was updated then the service must be restarted using the following command:

# sudo systemctl restart ntp.service

If the "NTP" service was not running then it must be started.
V-75815 No Change
Findings ID: UBTU-16-030110 Rule ID: SV-90495r2_rule Severity: medium CCI: CCI-002046

Discussion

Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events.

Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network. Organizations should consider setting time periods for different types of systems (e.g., financial, legal, or mission-critical systems).

Organizations should also consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints). This requirement is related to the comparison done every 24 hours in SRG-OS-000355 because a comparison must be done in order to determine the time difference.

Checks

Verify that Network Time Protocol (NTP) is running in continuous mode.

Check that NTP is running in continuous mode with the following command:

# grep ntpdate /etc/init.d/ntpd

if ntpdate -u -s -b -p 4 -t 5 $NTPSERVER ; then

If the option "-q" is present, this is a finding.

Fix

The Network Time Protocol (NTP) will run in continuous mode by default. If the query only option (-q) has been added to the ntpdate command in /etc/init.d/ntpd it must be removed.
V-75817 No Change
Findings ID: UBTU-16-030120 Rule ID: SV-90497r2_rule Severity: medium CCI: CCI-001890

Discussion

If time stamps are not consistently applied and there is no common time reference, it is difficult to perform forensic analysis.

Time stamps generated by the Ubuntu operating system include date and time. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC.

Checks

The time zone must be configured to use Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT). To verify run the following command.

# sudo timedatectl status | grep -i "time zone"
Time zone: UTC (UTC, +0000)

If "Time zone" is not set to UTC or GMT, this is a finding.

Fix

To configure the system time zone to use Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT), run the following command replacing [ZONE] with UTC or GMT.

# sudo timedatectl set-timezone [ZONE]
V-75819 No Change
Findings ID: UBTU-16-030130 Rule ID: SV-90499r2_rule Severity: medium CCI: CCI-002824

Discussion

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

Examples of attacks are buffer overflow attacks.

Checks

Verify the NX (no-execution) bit flag is set on the system.

Check that the no-execution bit flag is set with the following commands:

# dmesg | grep NX

[ 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:

# less /proc/cpuinfo | grep -i flags
flags : fpu vme de pse tsc ms nx rdtscp lm constant_tsc

If "flags" does not contain the "nx" flag, this is a finding.

Fix

The NX bit execute protection must be enabled in the system BIOS.
V-75821 No Change
Findings ID: UBTU-16-030140 Rule ID: SV-90501r2_rule Severity: medium CCI: CCI-002824

Discussion

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

Examples of attacks are buffer overflow attacks.

Checks

Verify the Ubuntu operating system implements address space layout randomization (ASLR).

Check that ASLR is configured on the system with the following command:

# sudo sysctl kernel.randomize_va_space

kernel.randomize_va_space = 2

If nothing is returned; we must verify the kernel parameter "randomize_va_space" is set to "2" with the following command:

# kernel.randomize_va_space" /etc/sysctl.conf /etc/sysctl.d/*

kernel.randomize_va_space = 2

If "kernel.randomize_va_space" is not set to "2", this is a finding.

Fix

Configure the operating system implement virtual address space randomization.

Set the system to the required kernel parameter by adding the following line to "/etc/sysctl.conf" (or modify the line to have the required value):

kernel.randomize_va_space=2
V-75823 No Change
Findings ID: UBTU-16-030200 Rule ID: SV-90503r1_rule Severity: high CCI: CCI-001941

Discussion

A replay attack may enable an unauthorized user to gain access to the Ubuntu operating system. Authentication sessions between the authenticator and the Ubuntu operating system validating the user credentials must not be vulnerable to a replay attack.

An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message.

A privileged account is any information system account with authorizations of a privileged user.

Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators.

Satisfies: SRG-OS-000112-GPOS-00057, SRG-OS-000113-GPOS-00058

Checks

Verify that the Ubuntu operating system enforces SSH protocol 2 for network access.

Check the protocol versions that SSH allows with the following command:

#grep -i protocol /etc/ssh/sshd_config

Protocol 2

If the returned line allows for use of protocol "1", is commented out, or the line is missing, this is a finding.

Fix

Configure the Ubuntu operating system to enforce SSHv2 for network access to all accounts.

Add or update the following line in the "/etc/ssh/sshd_config" file:

Protocol 2

Restart the ssh service.

# systemctl restart sshd.service
V-75825 Updated
Findings ID: UBTU-16-030210 Rule ID: SV-90505r34_rule Severity: medium CCI: CCI-000048

Discussion

Display of a standardized and approved use notification before granting access to the Ubuntu operating system ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist.

The banner must be formatted in accordance with applicable DoD policy. Use the following verbiage for Ubuntu operating systems
that can accommodate banners of 1300 characters:

"You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.

By using this IS (which includes any device attached to this IS), you consent to the following conditions:

-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

-At any time, the USG may inspect and seize data stored on this IS.

-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.

-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details."


Use the following verbiage for Ubuntu operating systems that have severe limitations on the number of characters that can be displayed in the banner:

"I've read & consent to terms in IS user agreem't."

Checks

Verify the Ubuntu operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the Ubuntu operating system via a ssh logon.

Check that the Ubuntu operating system displays the Standard Mandatory DoD Notice and Consent Banner before granting access to the Ubuntu operating system via a ssh logon with the following command:

# grep -i 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.

Check the specified banner file to check that it matches the Standard Mandatory DoD Notice and Consent Banner exactly:

“You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only.

By using this IS (which includes any device attached to this IS), you consent to the following conditions:

-The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations.

-At any time, the USG may inspect and seize data stored on this IS.

-Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose.

-This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy.

-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details.”

If the banner text does not match the Standard Mandatory DoD Notice and Consent Banner exactly, this is a finding.

Fix

Configure the Ubuntu operating system to display the Standard Mandatory DoD Notice and Consent Banner before granting access to the system via SSH logon.

Edit the SSH daemon configuration "/etc/ssh/sshd_config" file. Uncomment the banner keyword and configure it to point to the file that contains the correct banner. An example of this configure is below:

Banner=/etc/issue.net

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

The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:

# sudo systemctl restart sshd.service
V-75827 No Change
Findings ID: UBTU-16-030220 Rule ID: SV-90507r2_rule Severity: medium CCI: CCI-000366

Discussion

Even though the communications channel may be encrypted, an additional layer of security is gained by extending the policy of not logging on directly as root. In addition, logging on with a user-specific account provides individual accountability of actions performed on the system.

Checks

Verify remote access using SSH prevents users from logging on directly as "root".

Check that SSH prevents users from logging on directly as "root" with the following command:

# grep PermitRootLogin /etc/ssh/sshd_config
PermitRootLogin no

If the "PermitRootLogin" keyword is set to "yes", is missing, or is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to stop users from logging on remotely as the "root" user via SSH.

Edit the appropriate "/etc/ssh/sshd_config" file to uncomment or add the line for the "PermitRootLogin" keyword and set its value to "no":

PermitRootLogin no

The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:

# sudo systemctl restart sshd.service
V-75829 Updated
Findings ID: UBTU-16-030230 Rule ID: SV-90509r23_rule Severity: medium CCI: CCI-000068

Discussion

Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session.

Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.

Encryption provides a means to secure the remote connection to prevent unauthorized access to the data traversing the remote access connection (e.g., RDP), thereby providing a degree of confidentiality. The encryption strength of a mechanism is selected based on the security categorization of the information.

Checks

Verify the SSH daemon is configured to only implement DoD-approved encryption.

Check the SSH daemon's current configured ciphers by running the following command:

# sudo grep -i ciphers /etc/ssh/sshd_config | grep -v '^#'

Ciphers aes128-ctr
,aes192-ctr, aes256-ctr

If any ciphers other than "aes128-ctr", "aes192-ctr", or "aes256-ctr" are listed, the "Ciphers" keyword is missing, or the retuned line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to allow the SSH daemon to only implement DoD-approved encryption.

Edit the SSH daemon configuration "/etc/ssh/sshd_config" and remove any ciphers not starting with "aes" and remove any ciphers ending with "cbc". If necessary, append the "Ciphers" line to the "/etc/ssh/sshd_config" document.

Ciphers aes128-ctr,aes192-ctr,aes256-ctr

The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:

# sudo systemctl restart sshd.service
V-75831 No Change
Findings ID: UBTU-16-030240 Rule ID: SV-90511r2_rule Severity: medium CCI: CCI-001453

Discussion

Without cryptographic integrity protections, information can be altered by unauthorized users without detection.

Remote access (e.g., RDP) is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.

Cryptographic mechanisms used for protecting the integrity of information include, for example, signed hash functions using asymmetric cryptography enabling distribution of the public key to verify the hash information while maintaining the confidentiality of the secret key used to generate the hash.

Satisfies: SRG-OS-000250-GPOS-00093, SRG-OS-000393-GPOS-00173, SRG-OS-000394-GPOS-00174

Checks

Verify the SSH daemon is configured to only use Message Authentication Codes (MACs) that employ FIPS 140-2 approved ciphers.

Check that the SSH daemon is configured to only use MACs that employ FIPS 140-2 approved ciphers with the following command:

# sudo grep -i macs /etc/ssh/sshd_config
MACs hmac-sha2-256,hmac-sha2-512

If any ciphers other than "hmac-sha2-256" or "hmac-sha2-512" are listed, or the retuned line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to allow the SSH daemon to only use Message Authentication Codes (MACs) that employ FIPS 140-2 approved ciphers.

Edit the "/etc/ssh/sshd_config" file to uncomment or add the line for the "MACs" keyword and set its value to "hmac-sha2-256" and/or "hmac-sha2-512":

MACs hmac-sha2-256,hmac-sha2-512

The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:

# sudo systemctl restart sshd.service
V-75833 No Change
Findings ID: UBTU-16-030250 Rule ID: SV-90513r2_rule Severity: high CCI: CCI-000366

Discussion

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

Checks

Verify that unattended or automatic login via ssh is disabled.

Check that unattended or automatic login via ssh is disabled with the following command:

# egrep '(Permit(.*?)(Passwords|Environment))' /etc/ssh/sshd_config

PermitEmptyPasswords no
PermitUserEnvironment no

If "PermitEmptyPasswords" or "PermitUserEnvironment" keywords are not set to "no", is missing completely, or they are commented out, this is a finding.

Fix

Configure the Ubuntu operating system to allow the SSH daemon to not allow unattended or automatic login to the system.

Add or edit the following lines in the "/etc/ssh/sshd_config" file:

PermitEmptyPasswords no
PermitUserEnvironment no

The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:

# sudo systemctl restart sshd.service
V-75835 No Change
Findings ID: UBTU-16-030260 Rule ID: SV-90515r2_rule Severity: medium CCI: CCI-000366

Discussion

Providing users with feedback on when account accesses via SSH last occurred facilitates user recognition and reporting of unauthorized account use.

Checks

Verify SSH provides users with feedback on when account accesses last occurred.

Check that "PrintLastLog" keyword in the sshd daemon configuration file is used and set to "yes" with the following command:

# grep PrintLastLog /etc/ssh/sshd_config
PrintLastLog yes

If the "PrintLastLog" keyword is set to "no", is missing, or is commented out, this is a finding.

Fix

Add or edit the following lines in the "/etc/ssh/sshd_config" file:

PrintLastLog yes

The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:

# sudo systemctl restart sshd.service
V-75837 Updated
Findings ID: UBTU-16-030270 Rule ID: SV-90517r23_rule Severity: medium CCI: CCI-000879

Discussion

Automatic session termination addresses the termination of user-initiated logical sessions in contrast to the termination of network connections that are associated with communications sessions (i.e., network disconnect). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational information system. Such user sessions can be terminated (and thus terminate user access) without terminating network sessions.

Session termination terminates all processes associated with a user's logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated.

Conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use.

This capability is typically reserved for specific Ubuntu operating system functionality where the system owner, data owner, or organization requires additional assurance.

Checks

Verify that all network connections associated with SSH traffic are automatically terminated at the end of the session or after "10" minutes of inactivity.

Check that the "ClientAliveInterval" variable is set to a value of "600" or less by performing the following command:

# sudo grep -i clientalive /etc/ssh/sshd_config

ClientAliveInterval 600

ClientAliveCountMax 1

If "ClientAliveInterval" or "ClientAliveCountMax" does not exist, "ClientAliveInterval" is not set to a value of "600" or less and "ClientAliveCountMax" is not set to a value of "1" or greater in "/etc/ssh/sshd_config", or either linehas a value that is greater than "600" and is not documented with the Information System Security Officer (ISSO) as an operational requirement, or is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to automatically terminate all network connections associated with SSH traffic at the end of a session or after a "10" minute period of inactivity.

Modify or append the following lines in the "/etc/ssh/sshd_config" file replacing "[Interval]" with a value of "600" or less
and "[CountMax] with a value of "1" or greater:

ClientAliveInterval 600

ClientAliveCountMax 1

In order for the changes to take effect, the SSH daemon must be restarted.

# sudo systemctl restart sshd.service
V-75841 No Change
Findings ID: UBTU-16-030300 Rule ID: SV-90521r2_rule Severity: medium CCI: CCI-000366

Discussion

Configuring this setting for the SSH daemon provides additional assurance that remote logon via SSH will require a password, even in the event of misconfiguration elsewhere.

Checks

Verify the SSH daemon does not allow authentication using known hosts authentication.

To determine how the SSH daemon's "IgnoreUserKnownHosts" option is set, run the following command:

# grep IgnoreUserKnownHosts /etc/ssh/sshd_config

IgnoreUserKnownHosts yes

If the value is returned as "no", the returned line is commented out, or no output is returned, this is a finding.

Fix

Configure the SSH daemon to not allow authentication using known hosts authentication.

Add the following line in "/etc/ssh/sshd_config", or uncomment the line and set the value to "yes":

IgnoreUserKnownHosts yes

The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:

# sudo systemctl restart sshd.service
V-75843 No Change
Findings ID: UBTU-16-030310 Rule ID: SV-90523r2_rule Severity: medium CCI: CCI-000366

Discussion

If a public host key file is modified by an unauthorized user, the SSH service may be compromised.

Checks

Verify the SSH public host key files have mode "0644" or less permissive.

Note: SSH public key files may be found in other directories on the system depending on the installation.

The following command will find all SSH public key files on the system:

# ls -l /etc/ssh/*.pub

-rw-r--r-- 1 root wheel 618 Nov 28 06:43 ssh_host_dsa_key.pub
-rw-r--r-- 1 root wheel 347 Nov 28 06:43 ssh_host_key.pub
-rw-r--r-- 1 root wheel 238 Nov 28 06:43 ssh_host_rsa_key.pub

If any key.pub file has a mode more permissive than "0644", this is a finding.

Fix

Note: SSH public key files may be found in other directories on the system depending on the installation.

Change the mode of public host key files under "/etc/ssh" to "0644" with the following command:

# sudo chmod 0644 /etc/ssh/*key.pub

The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:

# sudo systemctl restart sshd.service
V-75845 No Change
Findings ID: UBTU-16-030320 Rule ID: SV-90525r2_rule Severity: medium CCI: CCI-000366

Discussion

If an unauthorized user obtains the private SSH host key file, the host could be impersonated.

Checks

Verify the SSH private host key files have mode "0600" or less permissive.

Check the mode of the private host key files under "/etc/ssh" file with the following command:

# ls -alL /etc/ssh/ssh_host*key

-rw------- 1 root wheel 668 Nov 28 06:43 ssh_host_dsa_key
-rw------- 1 root wheel 582 Nov 28 06:43 ssh_host_key
-rw------- 1 root wheel 887 Nov 28 06:43 ssh_host_rsa_key

If any private host key file has a mode more permissive than "0600", this is a finding.

Fix

Configure the mode of SSH private host key files under "/etc/ssh" to "0600" with the following command:

#sudo chmod 0600 /etc/ssh/ssh_host*key

The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:

# sudo systemctl restart sshd.service
V-75847 No Change
Findings ID: UBTU-16-030330 Rule ID: SV-90527r2_rule Severity: medium CCI: CCI-000366

Discussion

If other users have access to modify user-specific SSH configuration files, they may be able to log on to the system as another user.

Checks

Verify the SSH daemon performs strict mode checking of home directory configuration files.

Check that the SSH daemon performs strict mode checking of home directory configuration files with the following command:

# grep StrictModes /etc/ssh/sshd_config

StrictModes yes

If "StrictModes" is set to "no", is missing, or the returned line is commented out, this is a finding.

Fix

Configure SSH to perform strict mode checking of home directory configuration files. Uncomment the "StrictModes" keyword in "/etc/ssh/sshd_config" and set the value to "yes":

StrictModes yes

The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:

# sudo systemctl restart sshd.service
V-75849 No Change
Findings ID: UBTU-16-030340 Rule ID: SV-90529r2_rule Severity: medium CCI: CCI-000366

Discussion

SSH daemon privilege separation causes the SSH process to drop root privileges when not needed, which would decrease the impact of software vulnerabilities in the unprivileged section.

Checks

Check that the SSH daemon performs privilege separation with the following command:

# grep UsePrivilegeSeparation /etc/ssh/sshd_config

UsePrivilegeSeparation yes

If the "UsePrivilegeSeparation" keyword is set to "no", is missing, or the returned line is commented out, this is a finding.

Fix

Configure SSH to use privilege separation. Uncomment the "UsePrivilegeSeparation" keyword in "/etc/ssh/sshd_config" and set the value to "yes":

UsePrivilegeSeparation yes

The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:

# sudo systemctl restart sshd.service
V-75851 No Change
Findings ID: UBTU-16-030350 Rule ID: SV-90531r2_rule Severity: medium CCI: CCI-000366

Discussion

If compression is allowed in an SSH connection prior to authentication, vulnerabilities in the compression software could result in compromise of the system from an unauthenticated connection, potentially with root privileges.

Checks

Verify the SSH daemon performs compression after a user successfully authenticates.

Check that the SSH daemon performs compression after a user successfully authenticates with the following command:

# grep Compression /etc/ssh/sshd_config
Compression delayed

If the "Compression" keyword is set to "yes", is missing, or the returned line is commented out, this is a finding.

Fix

Configure SSH to use compression. Uncomment the "Compression" keyword in "/etc/ssh/sshd_config" on the system and set the value to "delayed" or "no":

Compression no

The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:

# sudo systemctl restart sshd.service
V-75853 No Change
Findings ID: UBTU-16-030400 Rule ID: SV-90533r2_rule Severity: high CCI: CCI-000366

Discussion

Open X displays allow an attacker to capture keystrokes and execute commands remotely.

Checks

Verify remote X connections for interactive users are encrypted.

Check that remote X connections are encrypted with the following command:

# grep -i x11forwarding /etc/ssh/sshd_config
X11Forwarding yes

If the "X11Forwarding" keyword is set to "no", is missing, or is commented out, this is a finding.

Fix

Configure SSH to encrypt connections for interactive users.

Edit the "/etc/ssh/sshd_config" file to uncomment or add the line for the "X11Forwarding" keyword and set its value to "yes":

X11Forwarding yes

The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:

# sudo systemctl restart sshd.service
V-75855 No Change
Findings ID: UBTU-16-030410 Rule ID: SV-90535r1_rule Severity: medium CCI: CCI-002385

Discussion

DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.

This requirement addresses the configuration of the Ubuntu operating system to mitigate the impact of DoS attacks that have occurred or are ongoing on system availability. For each system, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting processes or establishing memory partitions). Employing increased capacity and bandwidth, combined with service redundancy, may reduce the susceptibility to some DoS attacks.

Checks

Verify an application firewall is configured to rate limit any connection to the system.

Check that the Uncomplicated Firewall is configured to rate limit any connection to the system with the following command:

# sudo ufw show raw

Chain ufw-user-input (1 references)
pkts bytes target prot opt in out source destination
0 0 ufw-user-limit all -- eth0 * 0.0.0.0/0 0.0.0.0/0
ctstate NEW recent: UPDATE seconds: 30 hit_count: 6 name: DEFAULT side:
source mask: 255.255.255.255

0 0 ufw-user-limit-accept all -- eth0 * 0.0.0.0/0 0.0.0.0/0


If any service is not rate limited by the Uncomplicated Firewall, this is a finding.

Fix

Configure the application firewall to protect against or limit the effects of Denial of Service (DoS) attacks by ensuring the Ubuntu operating system is implementing rate-limiting measures on impacted network interfaces.

Run the following command replacing "[service]" with the service that needs to be rate limited.

# sudo ufw limit [service]

Or rate-limiting can be done on an interface. An example of adding a rate-limit on the eth0 interface:

# sudo ufw limit in on eth0
V-75857 No Change
Findings ID: UBTU-16-030420 Rule ID: SV-90537r1_rule Severity: high CCI: CCI-002418

Discussion

Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered.

This requirement applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification.

Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, logical means (cryptography) do not have to be employed, and vice versa.

Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188, SRG-OS-000425-GPOS-00189, SRG-OS-000426-GPOS-00190

Checks

Verify the "ssh" meta-package is installed.

Check that the ssh package is installed with the following command:

$ dpkg -l | grep openssh

ii openssh-client 1:7.2p2-4Ubuntu2.1
amd64 secure shell (SSH) client, for secure access to
remote machines
ii openssh-server 1:7.2p2-4Ubuntu2.1
amd64 secure shell (SSH) server, for secure access
from remote machines
ii openssh-sftp-server 1:7.2p2-4Ubuntu2.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.

Check that the "sshd.service" is loaded and active with the following command:

# systemctl status sshd.service | egrep -i "(active|loaded)"

Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: active (running) since Sun 2016-06-05 23:46:29 CDT; 1h 4min ago

If "sshd.service" is not active or loaded, this is a finding.

Fix

Install the "ssh" meta-package on the system with the following command:

# sudo apt install ssh

Enable the "ssh" service to start automatically on reboot with the following command:

# sudo systemctl enable sshd.service
V-75859 No Change
Findings ID: UBTU-16-030430 Rule ID: SV-90539r2_rule Severity: medium CCI: CCI-001851

Discussion

Information stored in one location is vulnerable to accidental or incidental deletion or alteration.

Off-loading is a common process in information systems with limited audit storage capacity.

Checks

Verify that the audit system takes appropriate action if the network cannot be used to off-load audit records.

Check what action will take place if the network connection fails with the following command:

# sudo grep -iw "network_failure" /etc/audisp/audisp-remote.conf

network_failure_action = stop

If the value of the “network_failure_action” option is not "syslog", "single", or "halt", or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to take appropriate action when the network cannot be used to off-load audit records.

Add, edit or uncomment the "network_failure_action" option in "/etc/audisp/audisp-remote.conf". Set it to "syslog", "single" or "halt" like the below example:

network_failure_action = single
V-75863 No Change
Findings ID: UBTU-16-030450 Rule ID: SV-90543r2_rule Severity: medium CCI: CCI-000067

Discussion

Remote access services, such as those providing remote access to network devices and information systems, which lack automated monitoring capabilities, increase risk and make remote user access management difficult at best.

Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.

Automated monitoring of remote access sessions allows organizations to detect cyber attacks and also ensure ongoing compliance with remote access policies by auditing connection activities of remote access capabilities, such as Remote Desktop Protocol (RDP), on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets).

Checks

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 '(auth.*|authpriv.*|daemon.*)' /etc/rsyslog.d/50-default.conf

auth,authpriv.* /var/log/auth.log
daemon.notice /var/log/messages

If "auth.*", "authpriv.*" or "daemon.*" are not configured to be logged, this is a finding.

Fix

Configure the Ubuntu operating system to monitor all remote access methods by adding the following lines to the "/etc/rsyslog.d/50-default.conf" file:

auth.*,authpriv.* /var/log/secure
daemon.notice /var/log/messages

The "rsyslog" service must be restarted for the changes to take effect. To restart the "rsyslog" service, run the following command:

# sudo systemctl restart rsyslog.service
V-75865 No Change
Findings ID: UBTU-16-030460 Rule ID: SV-90545r2_rule Severity: medium CCI: CCI-000366

Discussion

Cron logging can be used to trace the successful or unsuccessful execution of cron jobs. It can also be used to spot intrusions into the use of the cron facility by unauthorized and malicious users.

Checks

Verify that "rsyslog" is configured to log cron events.

Check the configuration of "/etc/rsyslog.d/50-default.conf" for the cron facility with the following commands:

Note: If another logging package is used, substitute the utility configuration file for "/etc/rsyslog.d/50-default.conf".

# grep cron /etc/rsyslog.d/50-default.conf

cron.* /var/log/cron.log

If the commands do not return a response, check for cron logging all facilities by inspecting the "/etc/rsyslog.d/50-default.con" file:

# more /etc/rsyslog.conf

Look for the following entry:

*.* /var/log/messages

If "rsyslog" is not logging messages for the cron facility or all facilities, this is a finding.

Fix

Configure "rsyslog" to log all cron messages by adding or updating the following line to "/etc/rsyslog.d/50-default.conf":

cron.* /var/log/cron.log

Note: The line must be added before the following entry if it exists in "/etc/rsyslog.d/50-default.conf":

*.* ~ # discards everything
V-75867 No Change
Findings ID: UBTU-16-030500 Rule ID: SV-90547r1_rule Severity: medium CCI: CCI-001443

Discussion

Without protection of communications with wireless peripherals, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read, altered, or used to compromise the Ubuntu operating system.

This requirement applies to wireless peripheral technologies (e.g., wireless mice, keyboards, displays, etc.) used with an Ubuntu operating system. Wireless peripherals (e.g., Wi-Fi/Bluetooth/IR Keyboards, Mice, and Pointing Devices and Near Field Communications [NFC]) present a unique challenge by creating an open, unsecured port on a computer. Wireless peripherals must meet DoD requirements for wireless data transmission and be approved for use by the AO. Even though some wireless peripherals, such as mice and pointing devices, do not ordinarily carry information that need to be protected, modification of communications with these wireless peripherals may be used to compromise the Ubuntu operating system. Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification.

Protecting the confidentiality and integrity of communications with wireless peripherals can be accomplished by physical means (e.g., employing physical barriers to wireless radio frequencies) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa. If the wireless peripheral is only passing telemetry data, encryption of the data may not be required.

Satisfies: SRG-OS-000299-GPOS-00117, SRG-OS-000300-GPOS-00118, SRG-OS-000481-GPOS-000481

Checks

Verify that there are no wireless interfaces configured on the system.

Check that the system does not have active wireless interfaces with the following command:

Note: This requirement is Not Applicable for systems that do not have physical wireless network radios.

# ifconfig -a | more

eth0 Link encap:Ethernet HWaddr ff:ff:ff:ff:ff:ff
inet addr:192.168.2.100 Bcast:192.168.2.255 Mask:255.255.255.0
...

eth1 IEEE 802.11b ESSID:"tacnet"
Mode:Managed Frequency:2.412 GHz Access Point: 00:40:E7:22:45:CD
...

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
...

If a wireless interface is configured and has not been documented and approved by the Information System Security Officer (ISSO), this is a finding.

Fix

Configure the system to disable all wireless network interfaces with the following command:

# sudo ifdown [ADAPTER_NAME]
V-75869 No Change
Findings ID: UBTU-16-030510 Rule ID: SV-90549r2_rule Severity: medium CCI: CCI-001095

Discussion

DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.

Managing excess capacity ensures that sufficient capacity is available to counter flooding attacks. Employing increased capacity and service redundancy may reduce the susceptibility to some DoS attacks. Managing excess capacity may include, for example, establishing selected usage priorities, quotas, or partitioning.

Checks

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.

Fix

Configure the Ubuntu operating system to use TCP syncookies, by running the following command:

# sudo sysctl -w net.ipv4.tcp_syncookies=1

If "1" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":

net.ipv4.tcp_syncookies = 1
V-75871 No Change
Findings ID: UBTU-16-030520 Rule ID: SV-90551r2_rule Severity: low CCI: CCI-000366

Discussion

To provide availability for name resolution services, multiple redundant name servers are mandated. A failure in name resolution could lead to the failure of security functions requiring name resolution, which may include time synchronization, centralized authentication, and remote system logging.

Checks

Determine whether the Ubuntu operating system is using local or Domain Name Server (DNS) name resolution with the following command:

# grep hosts /etc/nsswitch.conf
hosts: files dns

If the DNS entry is missing from the host’s line in the "/etc/nsswitch.conf" file, the "/etc/resolv.conf" file must be empty.

If the "/etc/resolv.conf" file is not empty, this is a finding.

If the DNS entry is found on the host’s line of the "/etc/nsswitch.conf" file, verify the Ubuntu operating system is configured to use two or more name servers for DNS resolution.

Determine the name servers used by the system with the following command:

# sudo grep nameserver /etc/resolv.conf

nameserver 192.168.1.2

nameserver 192.168.1.3

If less than two lines are returned that are not commented out, this is a finding.

Fix

Configure the Ubuntu operating system to use two or more name servers for Domain Name Server (DNS) resolution.

Edit the "/etc/resolv.conf" file to uncomment or add the two or more "nameserver" option lines with the IP address of local authoritative name servers. If local host resolution is being performed, the "/etc/resolv.conf" file must be empty. An empty "/etc/resolv.conf" file can be created as follows:

# echo -n > /etc/resolv.conf
V-75873 No Change
Findings ID: UBTU-16-030530 Rule ID: SV-90553r3_rule Severity: medium CCI: CCI-000366

Discussion

Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router.

Checks

Verify the Ubuntu operating system does not accept IPv4 source-routed packets.

Check the value of the accept source route variable with the following command:

# sudo sysctl net.ipv4.conf.all.accept_source_route

net.ipv4.conf.all.accept_source_route=0

If the returned line does not have a value of "0", a line is not returned, or the returned line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to not forward Internet Protocol version 4 (IPv4) source-routed packets with the following command:

# sudo sysctl -w net.ipv4.conf.all.accept_source_route=0

If "0" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":

net.ipv4.conf.all.accept_source_route=0
V-75875 No Change
Findings ID: UBTU-16-030540 Rule ID: SV-90555r3_rule Severity: medium CCI: CCI-000366

Discussion

Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router.

Checks

Verify the Ubuntu operating system does not accept Internet Protocol version 4 (IPv4) source-routed packets by default.

Check the value of the accept source route variable with the following command:

# sudo sysctl net.ipv4.conf.default.accept_source_route
net.ipv4.conf.default.accept_source_route=0

If the returned line does not have a value of "0", a line is not returned, or the returned line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to not forward Internet Protocol version 4 (IPv4) source-routed packets by default with the following command:

# sudo sysctl -w net.ipv4.conf.default.accept_source_route=0

If "0" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":

net.ipv4.conf.default.accept_source_route=0
V-75877 No Change
Findings ID: UBTU-16-030550 Rule ID: SV-90557r2_rule Severity: medium CCI: CCI-000366

Discussion

Responding to broadcast Internet Control Message Protocol (ICMP) echoes facilitates network mapping and provides a vector for amplification attacks.

Checks

Verify the Ubuntu operating system does not respond to IPv4 Internet Control Message Protocol (ICMP) echoes sent to a broadcast address.

Check the value of the "icmp_echo_ignore_broadcasts" variable with the following command:

# sudo sysctl net.ipv4.icmp_echo_ignore_broadcasts
net.ipv4.icmp_echo_ignore_broadcasts=1

If the returned line does not have a value of "1", a line is not returned, or the retuned line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to not respond to Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) echoes sent to a broadcast address with the following command:

# sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1

If "1" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":

net.ipv4.icmp_echo_ignore_broadcasts=1
V-75879 No Change
Findings ID: UBTU-16-030560 Rule ID: SV-90559r3_rule Severity: medium CCI: CCI-000366

Discussion

Internet Control Message Protocol (ICMP) redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.

Checks

Verify the Ubuntu operating system will not accept IPv4 Internet Control Message Protocol (ICMP) redirect messages.

Check the value of the default "accept_redirects" variables with the following command:

# sudo sysctl net.ipv4.conf.default.accept_redirects

net.ipv4.conf.default.accept_redirects=0

If the returned line does not have a value of "0", or a line is not returned, this is a finding.

Fix

Configure the Ubuntu operating system to prevent Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages from being acceptedr with the following command:

# sudo sysctl -w net.ipv4.conf.default.accept_redirects=0

If "0" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":

net.ipv4.conf.default.accept_redirects=0
V-75881 No Change
Findings ID: UBTU-16-030570 Rule ID: SV-90561r2_rule Severity: medium CCI: CCI-000366

Discussion

Internet Control Message Protocol (ICMP) redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.

Checks

Verify the Ubuntu operating system ignores Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages.

Check the value of the "accept_redirects" variables with the following command:

# sudo sysctl net.ipv4.conf.all.accept_redirects

net.ipv4.conf.all.accept_redirects=0

If both of the returned lines do not have a value of "0", or a line is not returned, this is a finding.

Fix

Configure the Ubuntu operating system to ignore Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages with the following command:

# sudo sysctl -w net.ipv4.conf.all.accept_redirects=0

If "0" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":

net.ipv4.conf.all.accept_redirects=0
V-75883 No Change
Findings ID: UBTU-16-030580 Rule ID: SV-90563r2_rule Severity: medium CCI: CCI-000366

Discussion

Internet Control Message Protocol (ICMP) redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table, possibly revealing portions of the network topology.

Checks

Verify the Ubuntu operating system does not allow interfaces to perform Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirects by default.

Check the value of the "default send_redirects" variables with the following command:

# sudo sysctl net.ipv4.conf.default.send_redirects

net.ipv4.conf.default.send_redirects=0

If the returned line does not have a value of "0", or a line is not returned, this is a finding.

Fix

Configure the Ubuntu operating system to not allow interfaces to perform Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirects by default with the following command:

# sudo sysctl -w net.ipv4.conf.default.send_redirects=0

If "0" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":

net.ipv4.conf.default.send_redirects=0
V-75885 No Change
Findings ID: UBTU-16-030590 Rule ID: SV-90565r2_rule Severity: medium CCI: CCI-000366

Discussion

Internet Control Message Protocol (ICMP) redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table, possibly revealing portions of the network topology.

Checks

Verify the Ubuntu operating system does not send Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages.

Check the value of the "all send_redirects" variables with the following command:

# sudo sysctl net.ipv4.conf.all.send_redirects

net.ipv4.conf.all.send_redirects=0

If the returned line does not have a value of "0", or a line is not returned, this is a finding.

Fix

Configure the Ubuntu operating system to not allow interfaces to perform Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirects with the following command:

# sudo sysctl -w net.ipv4.conf.all.send_redirects=0

If "0" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":

net.ipv4.conf.all.send_redirects=0
V-75887 No Change
Findings ID: UBTU-16-030600 Rule ID: SV-90567r2_rule Severity: medium CCI: CCI-000366

Discussion

Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this software is used when not required, system network information may be unnecessarily transmitted across the network.

Checks

Verify the Ubuntu operating system is not performing packet forwarding, unless the system is a router.

Check to see if IP forwarding is enabled using the following command:

# /sbin/sysctl -a | grep net.ipv4.ip_forward
net.ipv4.ip_forward=0

If IP forwarding value is "1" and is not documented with the Information System Security Officer (ISSO) as an operational requirement , this is a finding.

Fix

Configure the Ubuntu operating system to not allow packet forwarding, unless the system is a router with the following command:

# sudo sysctl -w net.ipv4.ip_forward=0

If "0" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":

net.ipv4.ip_forward=0
V-75889 No Change
Findings ID: UBTU-16-030610 Rule ID: SV-90569r2_rule Severity: medium CCI: CCI-000366

Discussion

Network interfaces in promiscuous mode allow for the capture of all network traffic visible to the system. If unauthorized individuals can access these applications, it may allow then to collect information such as logon IDs, passwords, and key exchanges between systems.

If the system is being used to perform a network troubleshooting function, the use of these tools must be documented with the Information System Security Officer (ISSO) and restricted to only authorized personnel.

Checks

Verify network interfaces are not in promiscuous mode unless approved by the Information System Security Officer (ISSO) and documented.

Check for the status with the following command:

# ip link | grep -i promisc

If network interfaces are found on the system in promiscuous mode and their use has not been approved by the ISSO and documented, this is a finding.

Fix

Configure network interfaces to turn off promiscuous mode unless approved by the Information System Security Officer (ISSO) and documented.

Set the promiscuous mode of an interface to "off" with the following command:

# sudo ip link set dev <devicename> promisc off
V-75891 No Change
Findings ID: UBTU-16-030620 Rule ID: SV-90571r2_rule Severity: medium CCI: CCI-000366

Discussion

If unrestricted mail relaying is permitted, unauthorized senders could use this host as a mail relay for the purpose of sending spam or other unauthorized activity.

Checks

Determine if "postfix" is installed with the following commands:

Note: If postfix is not installed, this is Not Applicable.

# dpkg -l | grep postfix
ii postfix 3.1.0-3

Verify the Ubuntu operating system is configured to prevent unrestricted mail relaying.

If postfix is installed, determine if it is configured to reject connections from unknown or untrusted networks with the following command:

# postconf -n smtpd_client_restrictions

smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject

If the "smtpd_relay_restrictions" parameter contains any entries other than "permit_mynetworks", "permit_sasl_authenticated" and "reject", is missing, or is commented out, this is a finding.

Fix

If "postfix" is installed, modify the "/etc/postfix/main.cf" file to restrict client connections to the local network with the following command:

# sudo postconf -e 'smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject'
V-75893 No Change
Findings ID: UBTU-16-030700 Rule ID: SV-90573r2_rule Severity: medium CCI: CCI-000139

Discussion

It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected.

Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded.

This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.

Checks

Verify that the administrators are notified in the event of an audit processing failure.

Note: If postfix is not installed, this is Not Applicable.

Check that the "/etc/aliases" file has a defined value for "root".

# sudo grep "postmaster: *root$" /etc/aliases

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to notify administrators in the event of an audit processing failure.

Add/update the following line in "/etc/aliases":

postmaster: root
V-75895 No Change
Findings ID: UBTU-16-030710 Rule ID: SV-90575r1_rule Severity: high CCI: CCI-000366

Discussion

The FTP service provides an unencrypted remote access that does not provide for the confidentiality and integrity of user passwords or the remote session. If a privileged user were to log on using this service, the privileged user password could be compromised. SSH or other encrypted file transfer methods must be used in place of this service.

Checks

Verify a File Transfer Protocol (FTP) server has not been installed on the system.

Check to see if a FTP server has been installed with the following commands:

# dpkg -l | grep vsftpd
ii vsftpd 3.0.3-3Ubuntu2

If "vsftpd" is installed and is not documented with the Information System Security Officer (ISSO) as an operational requirement, this is a finding.

Fix

Document the "vsftpd" package with the Information System Security Officer (ISSO) as an operational requirement or remove it from the system with the following command:

# sudo apt-get remove vsftpd
V-75897 No Change
Findings ID: UBTU-16-030720 Rule ID: SV-90577r2_rule Severity: high CCI: CCI-000318

Discussion

If TFTP is required for operational support (such as the transmission of router configurations) its use must be documented with the Information System Security Officer (ISSO), restricted to only authorized personnel, and have access control rules established.

Checks

Verify a Trivial File Transfer Protocol (TFTP) server has not been installed.

Check to see if a TFTP server has been installed with the following command:

# dpkg -l | grep tftpd-hpa
ii tftpd-hpa 5.2+20150808-1Ubuntu1.16.04.1

If TFTP is installed and the requirement for TFTP is not documented with the Information System Security Officer (ISSO), this is a finding.

Fix

Remove the Trivial File Transfer Protocol (TFTP) package from the system with the following command:

# sudo apt-get remove tftpd-hpa
V-75899 No Change
Findings ID: UBTU-16-030730 Rule ID: SV-90579r1_rule Severity: medium CCI: CCI-000366

Discussion

Restricting TFTP to a specific directory prevents remote users from copying, transferring, or overwriting system files.

Checks

Verify the Trivial File Transfer Protocol (TFTP) daemon is configured to operate in secure mode.

Check to see if a TFTP server has been installed with the following commands:

# dpkg -l | grep tftpd-hpa
ii tftpd-hpa 5.2+20150808-1Ubuntu1.16.04.1
If a TFTP server is not installed, this is Not Applicable.

If a TFTP server is installed, check for the server arguments with the following command:

# grep TFTP_OPTIONS /etc/default/tftpd-hpa
TFTP_OPTIONS="--secure"

If "--secure" is not listed in the TFTP_OPTIONS, this is a finding.

Fix

Configure the Trivial File Transfer Protocol (TFTP) daemon to operate in the secure mode by adding the "--secure" option to TFTP_OPTIONS in /etc/default/tftpd-hpa and restart the tftpd daemon.
V-75901 No Change
Findings ID: UBTU-16-030740 Rule ID: SV-90581r1_rule Severity: medium CCI: CCI-000366

Discussion

Internet services that are not required for system or application processes must not be active to decrease the attack surface of the system. X Windows has a long history of security vulnerabilities and will not be used unless approved and documented.

Checks

Verify that if X Windows is installed it is authorized.

Check for the X11 package with the following command:

# dpkg -l | grep lightdm

Ask the System Administrator if use of the X Windows system is an operational requirement.

If the use of X Windows on the system is not documented with the Information System Security Officer (ISSO), this is a finding.

Fix

Document the requirement for an X Windows server with the Information System Security Officer (ISSO) or remove the related packages with the following commands:

# sudo apt-get purge lightdm
V-75903 No Change
Findings ID: UBTU-16-030800 Rule ID: SV-90583r1_rule Severity: medium CCI: CCI-001948

Discussion

Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.

Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD Common Access Card.

A privileged account is defined as an information system account with authorizations of a privileged user.

Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.

This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management).

Requires further clarification from NIST.

Satisfies: SRG-OS-000375-GPOS-00160, SRG-OS-000375-GPOS-00161, SRG-OS-000375-GPOS-00162

Checks

Verify the Ubuntu operating system has the packages required for multifactor authentication installed.

Check for the presence of the packages required to support multifactor authentication with the following commands:

# dpkg -l | grep libpam-pkcs11

ii libpam-pkcs11 0.6.8-4 amd64 Fully featured PAM module for using PKCS#11 smart cards

If the "libpam-pkcs11" package is not installed, this is a finding.

Fix

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
V-75905 No Change
Findings ID: UBTU-16-030810 Rule ID: SV-90585r1_rule Severity: medium CCI: CCI-001953

Discussion

The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access.

DoD has mandated the use of the CAC to support identity management and personal authentication for systems covered under Homeland Security Presidential Directive (HSPD) 12, as well as making the CAC a primary component of layered protection for national security systems.

Checks

Verify the Ubuntu operating system accepts Personal Identity Verification (PIV) credentials.

Check that the "opensc-pcks11" package is installed on the system with the following command:

# dpkg -l | grep opensc-pkcs11

ii opensc-pkcs11:amd64 0.15.0-1Ubuntu1 amd64 Smart card utilities with support for PKCS#15 compatible cards

If the "opensc-pcks11" package is not installed, this is a finding.

Fix

Configure the Ubuntu operating system to accept Personal Identity Verification (PIV) credentials.

Install the "opensc-pkcs11" package using the following command:

# sudo apt-get install opensc-pkcs11
V-75907 No Change
Findings ID: UBTU-16-030820 Rule ID: SV-90587r2_rule Severity: medium CCI: CCI-001948

Discussion

Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.

Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD Common Access Card.

A privileged account is defined as an information system account with authorizations of a privileged user.

Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.

This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management).

Requires further clarification from NIST.

Satisfies: SRG-OS-000375-GPOS-00160, SRG-OS-000375-GPOS-00161, SRG-OS-000375-GPOS-00162

Checks

Verify the Ubuntu operating system implements certificate status checking for multifactor authentication.

Check that certificate status checking for multifactor authentication is implemented with the following command:

# sudo grep cert_policy /etc/pam_pkcs11/pam_pkcs11.conf | grep ocsp_on

cert_policy = ca,signature,ocsp_on;

If "cert_policy" is not set to "ocsp_on", has a value of "none", or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to certificate status checking for multifactor authentication.

Modify all of the cert_policy lines in "/etc/pam_pkcs11/pam_pkcs11.conf" to include "ocsp_on".
V-75909 No Change
Findings ID: UBTU-16-030830 Rule ID: SV-90589r2_rule Severity: medium CCI: CCI-000185

Discussion

Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted.

A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC.

When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA.

This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement.

Satisfies: SRG-OS-000066-GPOS-00034, SRG-OS-000384-GPOS-00167

Checks

Verify the Ubuntu operating system, for PKI-based authentication, had valid certificates by constructing a certification path (which includes status information) to an accepted trust anchor.

Check 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 cert_policy /etc/pam_pkcs11/pam_pkcs11.conf

cert_policy = ca,signature,ocsp_on;

If "cert_policy" is not set to "ca", has a value of "none", or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system, for PKI-based authentication, to validate certificates by constructing a certification path (which includes status information) 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;
V-75911 No Change
Findings ID: UBTU-16-030840 Rule ID: SV-90591r1_rule Severity: medium CCI: CCI-000765

Discussion

Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.

Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD Common Access Card.

Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.

This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management).

Requires further clarification from NIST.

Satisfies: SRG-OS-000105-GPOS-00052, SRG-OS-000106-GPOS-00053, SRG-OS-000107-GPOS-00054, SRG-OS-000108-GPOS-00055, SRG-OS-000375-GPOS-00162, SRG-OS-000376-GPOS-00161, SRG-OS-000377-GPOS-00162

Checks

Verify the Ubuntu operating system uses multifactor authentication for local access to accounts.

Check that the "pam_pkcs11.so" option is configured in the "/etc/pam.d/common-auth" file with the following command:

# grep pam_pkcs11.so /etc/pam.d/common-auth
auth [success=2 default=ignore] pam_pkcs11.so

If "pam_pkcs11.so" is not set in "/etc/pam.d/common-auth", this is a finding.

Fix

Configure the Ubuntu operating system to use multifactor authentication for local access to accounts.

Add or update "pam_pkcs11.so" in "/etc/pam.d/common-auth" to match the following line:

auth [success=2 default=ignore] pam_pkcs11.so
V-78005 No Change
Findings ID: UBTU-16-030900 Rule ID: SV-92701r1_rule Severity: high CCI: CCI-001668

Discussion

Virus scanning software can be used to protect a system from penetration from computer viruses and to limit their spread through intermediate systems.

The virus scanning software should be configured to perform scans dynamically on accessed files. If this capability is not available, the system must be configured to scan, at a minimum, all altered files on the system on a daily basis.

If the system processes inbound SMTP mail, the virus scanner must be configured to scan all received mail.

Checks

Verify the system is using a DoD-approved virus scan program.


Check for the presence of "McAfee VirusScan Enterprise for Linux" with the following command:


# systemctl status nails

nails - service for McAfee VirusScan Enterprise for Linux

> Loaded: loaded /opt/NAI/package/McAfeeVSEForLinux/McAfeeVSEForLinux-2.0.2.<build_number>; enabled)

> Active: active (running) since Mon 2015-09-27 04:11:22 UTC;21 min ago


If the "nails" service is not active, check for the presence of "clamav" on the system with the following command:


# systemctl status clamav-daemon.socket

systemctl status clamav-daemon.socket

clamav-daemon.socket - Socket for Clam AntiVirus userspace daemon

Loaded: loaded (/lib/systemd/system/clamav-daemon.socket; enabled)

Active: active (running) since Mon 2015-01-12 09:32:59 UTC; 7min ago


If neither of these applications are loaded and active, ask the System Administrator if there is an antivirus package installed and active on the system.


If no antivirus scan program is active on the system, this is a finding.

Fix

Install an approved DoD antivirus solution on the system.
V-78007 No Change
Findings ID: UBTU-16-030910 Rule ID: SV-92703r1_rule Severity: medium CCI: CCI-001668

Discussion

Virus scanning software can be used to protect a system from penetration from computer viruses and to limit their spread through intermediate systems.

The virus scanning software should be configured to check for software and virus definition updates with a frequency no longer than seven days. If a manual process is required to update the virus scan software or definitions, it must be documented with the Information System Security Officer (ISSO).

Checks

Verify the system is using a DoD-approved virus scan program and the virus definition file is less than seven days old.

Check for the presence of "McAfee VirusScan Enterprise for Linux" with the following command:

# systemctl status nails

nails - service for McAfee VirusScan Enterprise for Linux

> Loaded: loaded /opt/NAI/package/McAfeeVSEForLinux/McAfeeVSEForLinux-2.0.2.<build_number>; enabled)

> Active: active (running) since Mon 2015-09-27 04:11:22 UTC;21 min ago

If the "nails" service is not active, check for the presence of "clamav" on the system with the following command:

# systemctl status clamav-daemon.socket

systemctl status clamav-daemon.socket

clamav-daemon.socket - Socket for Clam AntiVirus userspace daemon

Loaded: loaded (/lib/systemd/system/clamav-daemon.socket; enabled)

Active: active (running) since Mon 2015-01-12 09:32:59 UTC; 7min ago

If "McAfee VirusScan Enterprise for Linux" is active on the system, check the dates of the virus definition files with the following command:

# ls -al /opt/NAI/LinuxShield/engine/dat/*.dat

-rwxr-xr-x 1 root root 243217 Mar 5 2017 avvclean.dat
-rwxr-xr-x 1 root root 16995 Mar 5 2017 avvnames.dat
-rwxr-xr-x 1 root root 4713245 Mar 5 2017 avvscan.dat

If the virus definition files have dates older than seven days from the current date, this is a finding.

If "clamav" is active on the system, check the dates of the virus database with the following commands:

# grep -I databasedirectory /etc/clamav.conf

DatabaseDirectory /var/lib/clamav

# ls -al /var/lib/clamav/*.cvd

-rwxr-xr-x 1 root root 149156 Mar 5 2011 daily.cvd

If the database file has a date older than seven days from the current date, this is a finding.

Fix

Update the approved DoD virus scan software and virus definition files.
V-80957 No Change
Findings ID: UBTU-16-010631 Rule ID: SV-95669r1_rule Severity: high CCI: CCI-000366

Discussion

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

Checks

Verify the Ubuntu operating system is not configured to reboot the system when Ctrl-Alt-Delete is pressed when using GNOME.

Check that the "logout" target is not bound to an action with the following command:

# grep logout /etc/dconf/db/local.d/*

logout=''

If the "logout" key is bound to an action, is commented out, or is missing, this is a finding.

Fix

Configure the system to disable the Ctrl-Alt-Delete sequence when using GNOME 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 GNOME:

[org/gnome/settings-daemon/plugins/media-keys]
logout=’’

Then update the dconf settings:

# dconf update
V-80959 No Change
Findings ID: UBTU-16-020010 Rule ID: SV-95671r1_rule Severity: medium CCI: CCI-000366

Discussion

Configuring the Ubuntu operating system to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DoD that reflects the most restrictive security posture consistent with operational requirements.

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

Checks

Verify the audit service is active.

Check that the audit service is active with the following command:

# service auditd status
Active: active (running)

If the service is not active this is a finding.

Fix

Start the auditd service, and enable the auditd service with the following commands:

Start the audit service.
# systemctl start auditd.service

Enable auditd in the targets of the system.
# systemctl enable auditd.service
V-80961 No Change
Findings ID: UBTU-16-020021 Rule ID: SV-95673r1_rule Severity: medium CCI: CCI-001855

Discussion

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

Checks

Verify the Ubuntu operating system notifies the System Administrator (SA) and Information System Security Officer (ISSO) (at a minimum) when allocated audit record storage volume reaches 75% of the repository maximum audit record storage capacity.

Check the system configuration to determine the 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/"):

# df -h /var/log/audit/
1.0G /var/log/audit

If the audit records are not being written to a partition specifically created for audit records (in this example "/var/log/audit" is a separate partition), determine the amount of space other files in the partition are currently occupying with the following command:

# du -sh <partition>
1.0G /var

Determine what the threshold is for the system to take action when 75% of the repository maximum audit record storage capacity is reached:

# grep -i space_left /etc/audit/auditd.conf
space_left = 250

If the value of the "space_left" keyword is not set to 25% of the total partition size, this is a finding.

Fix

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

Check the system configuration to determine the partition the audit records are being written to:

# grep log_file /etc/audit/auditd.conf

Determine the size of the partition that audit records are written to (with the example being "/var/log/audit/"):

# df -h /var/log/audit/

Set the value of the "space_left" keyword in "/etc/audit/auditd.conf" to 25% of the partition size.
V-80963 No Change
Findings ID: UBTU-16-020170 Rule ID: SV-95675r1_rule Severity: medium CCI: CCI-001314

Discussion

Only authorized personnel should be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the Ubuntu operating system or platform. Additionally, Personally Identifiable Information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives.

The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements.

Checks

Verify that the audit log files have a mode of "0640" or less permissive.

Check where the audit logs are stored on the system using the following command:

# sudo grep log_file /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log

Using the audit log path from the command above, replace "[log_path]" in the following command:

# sudo ls -lad [log_file] | cut -d' ' -f1
ls -lad /var/log/audit/audit.log | cut -d' ' -f1
-rw-r-----

If the audit log file does not have a mode of "0640" or less permissive, this is a finding.

Fix

Configure the octal permission value of the audit log to "0640" or less permissive.

Use the following command to find where the audit log files are stored on the system:

# sudo grep log_file /etc/audit/auditd.conf
log_file = /var/log/audit/audit.log

Using the audit log path from the command above, replace "[log_path]" in the following command:

# sudo chmod 0640 [log_path]
V-80965 No Change
Findings ID: UBTU-16-020220 Rule ID: SV-95677r1_rule Severity: medium CCI: CCI-001851

Discussion

Information stored in one location is vulnerable to accidental or incidental deletion or alteration.

Off-loading is a common process in information systems with limited audit storage capacity.

Checks

Verify the audit system off-loads audit records to a different system or storage media from the system being audited.

Check that the records are being off-loaded to a remote server with the following command:

# sudo grep -i remote_server /etc/audisp/audisp-remote.conf

remote_server = 10.0.1.2

If "remote_server" is not configured, or the line is commented out, this is a finding.

Fix

Configure the audit system to off-load audit records to a different system or storage media from the system being audited.

Set the "remote_server" option in "/etc/audisp/audisp-remote.conf" with the IP address of the log server. See the example below.

remote_server = 10.0.1.2

In order for the changes to take effect, the audit daemon must be restarted. The audit daemon can be restarted with the following command:

# sudo systemctl restart auditd.service
V-80969 Updated
Findings ID: UBTU-16-020690 Rule ID: SV-95681r12_rule Severity: medium CCI: CCI-000130

Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).


Satisfies: SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215

Checks

Verify the Ubuntu operating system generates an audit record when successful/unsuccessful attempts to use the "chcon" command occur.

Check that the following calls are being audited by performing the following command to check the file system rules in "/etc/audit/audit.rules":

# sudo grep -w chcon /etc/audit/audit.rules

-a always,exit -F
arch=b32 path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng
-a always,exit -F arch=b64
path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng

If the command does not return a line, or the line is commented out, this is a finding.

Fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chcon" command.

Add or update the following rules in the "/etc/audit/audit.rules" file:

-a always,exit -F
arch=b32 path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng
-a always,exit -F arch=b64
path=/usr/bin/chcon -F perm=x -F auid>=1000 -F auid!=4294967295 -k perm_chng

The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:

# sudo systemctl restart auditd.service
V-90365 Added
Findings ID: UBTU-16-020350 Rule ID: SV-101015r1_rule Severity: medium CCI: CCI-002233

Discussion

Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider threats and the advanced persistent threat. Satisfies: SRG-OS-000326-GPOS-00126, SRG-OS-000327-GPOS-00127

Checks

Verify the Ubuntu operating system audits the execution of privilege functions. Check if the Ubuntu operating system is configured to audit the execution of the "execve" system call, by running the following command: # sudo grep execve /etc/audit/audit.rules -a always,exit -F arch=b32 -S execve -C uid!=euid -F key=execpriv -a always,exit -F arch=b64 -S execve -C uid!=euid -F key=execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F key=execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F key=execpriv If the command does not return all lines, or the lines are commented out, this is a finding.

Fix

Configure the Ubuntu operating system to audit the execution of the "execve" system call. Add or update the following file system rules to "/etc/audit/audit.rules": -a always,exit -F arch=b32 -S execve -C uid!=euid -F key=execpriv -a always,exit -F arch=b64 -S execve -C uid!=euid -F key=execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F key=execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F key=execpriv The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command: # sudo systemctl restart auditd.service
V-75689 Removed
Findings ID: UBTU-16-020350 Rule ID: SV-90369r2_rule Severity: medium CCI: CCI-002233

Discussion

Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised information system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations. Auditing the use of privileged functions is one way to detect such misuse and identify the risk from insider threats and the advanced persistent threat. Satisfies: SRG-OS-000326-GPOS-00126, SRG-OS-000327-GPOS-00127

Checks

Verify the Ubuntu operating system audits the execution of privilege functions. Verify if the Ubuntu operating system is configured to audit the execution of the "execve" system call, by running the following command: # sudo grep execve /etc/audit/audit.rules -a always,exit -F arch=b64 -S execve -C uid!=euid -F key=execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F key=execpriv If the command does not return both lines, or the line is commented out, this is a finding.

Fix

Configure the Ubuntu operating system to audit the execution of the "execve" system call. Add or update the following file system rules to "/etc/audit/audit.rules": -a always,exit -F arch=b64 -S execve -C uid!=euid -F key=execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F key=execpriv The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command: # sudo systemctl restart auditd.service