Canonical Ubuntu 16.04 LTS Security Technical Implementation Guide

  • Version/Release: V2R3
  • Published: 2021-03-10
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

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: disa.stig_spt@mail.mil.
c
The Ubuntu operating system must be a vendor supported release.
SI-2 - High - CCI-001230 - V-214939 - SV-214939r648696_rule
RMF Control
SI-2
Severity
High
CCI
CCI-001230
Version
UBTU-16-010000
Vuln IDs
  • V-214939
  • V-75389
Rule IDs
  • SV-214939r648696_rule
  • SV-90069
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: C-16138r648695_chk

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" Validate that "Extended Security Maintenance" support has been purchased from the vendor. If the operating system does not have a documented "Extended Security Maintenance" agreement in place, this is a finding.

Fix: F-16136r284686_fix

Upgrade to a supported version of the Ubuntu operating system.

b
Ubuntu vendor packaged system security patches and updates must be installed and up to date.
CM-6 - Medium - CCI-000366 - V-214940 - SV-214940r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010010
Vuln IDs
  • V-214940
  • V-75391
Rule IDs
  • SV-214940r610931_rule
  • SV-90071
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: C-16139r284688_chk

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: F-16137r284689_fix

Install the Ubuntu operating system patches or updated packages available from Canonical within 30 days or sooner as local policy dictates.

b
The Ubuntu operating system must display the Standard Mandatory DoD Notice and Consent Banner before granting local or remote access to the system via a graphical user logon.
AC-8 - Medium - CCI-000048 - V-214941 - SV-214941r610931_rule
RMF Control
AC-8
Severity
Medium
CCI
CCI-000048
Version
UBTU-16-010020
Vuln IDs
  • V-214941
  • V-75393
Rule IDs
  • SV-214941r610931_rule
  • SV-90073
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: C-16140r284691_chk

Verify the Ubuntu operating system 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: F-16138r284692_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

b
The Ubuntu operating system must display the Standard Mandatory DoD Notice and Consent Banner before granting local or remote access to the system via a command line user logon.
AC-8 - Medium - CCI-000048 - V-214942 - SV-214942r610931_rule
RMF Control
AC-8
Severity
Medium
CCI
CCI-000048
Version
UBTU-16-010030
Vuln IDs
  • V-214942
  • V-75435
Rule IDs
  • SV-214942r610931_rule
  • SV-90115
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: "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."
Checks: C-16141r284694_chk

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: F-16139r284695_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."

b
The Ubuntu operating system must enable a user session lock until that user re-establishes access using established identification and authentication procedures.
AC-11 - Medium - CCI-000056 - V-214943 - SV-214943r610931_rule
RMF Control
AC-11
Severity
Medium
CCI
CCI-000056
Version
UBTU-16-010040
Vuln IDs
  • V-214943
  • V-75437
Rule IDs
  • SV-214943r610931_rule
  • SV-90117
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: C-16142r364830_chk

Verify the operating system allows a user to lock the current graphical user interface session. Note: If the Ubuntu operating system does not have a graphical user interface installed, this requirement is Not Applicable. Check to see if the Ubuntu operating system allows the user to lock the current graphical user interface 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: F-16140r364831_fix

Configure the Ubuntu operating system so that it allows a user to lock the current Graphical User Interface session. Set the "lock-enabled" setting in the graphical user interface to allow session locks with the following command: Note: The command must be performed from a terminal window inside the graphical user interface. # sudo gsettings set org.gnome.desktop.lock-enabled true

b
All users must be able to directly initiate a session lock for all connection types.
AC-11 - Medium - CCI-000056 - V-214944 - SV-214944r610931_rule
RMF Control
AC-11
Severity
Medium
CCI
CCI-000056
Version
UBTU-16-010050
Vuln IDs
  • V-214944
  • V-75439
Rule IDs
  • SV-214944r610931_rule
  • SV-90119
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: C-16143r284700_chk

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: F-16141r284701_fix

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

b
Ubuntu operating system sessions must be automatically logged out after 15 minutes of inactivity.
AC-11 - Medium - CCI-000057 - V-214945 - SV-214945r610931_rule
RMF Control
AC-11
Severity
Medium
CCI
CCI-000057
Version
UBTU-16-010060
Vuln IDs
  • V-214945
  • V-75441
Rule IDs
  • SV-214945r610931_rule
  • SV-90121
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: C-16144r284703_chk

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: F-16142r284704_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

a
The Ubuntu operating system must limit the number of concurrent sessions to ten for all accounts and/or account types.
AC-10 - Low - CCI-000054 - V-214946 - SV-214946r610931_rule
RMF Control
AC-10
Severity
Low
CCI
CCI-000054
Version
UBTU-16-010070
Vuln IDs
  • V-214946
  • V-75443
Rule IDs
  • SV-214946r610931_rule
  • SV-90123
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: C-16145r284706_chk

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: F-16143r284707_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

b
The Ubuntu operating system must prevent direct login into the root account.
IA-2 - Medium - CCI-000770 - V-214947 - SV-214947r610931_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000770
Version
UBTU-16-010080
Vuln IDs
  • V-214947
  • V-75445
Rule IDs
  • SV-214947r610931_rule
  • SV-90125
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: C-16146r284709_chk

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: F-16144r284710_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

b
The Ubuntu operating system must be configured so that when passwords are changed or new passwords are established, pwquality must be used.
IA-5 - Medium - CCI-000193 - V-214948 - SV-214948r610931_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000193
Version
UBTU-16-010099
Vuln IDs
  • V-214948
  • V-99009
Rule IDs
  • SV-214948r610931_rule
  • SV-108113
Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. "pwquality" enforces complex password construction configuration and has the ability to limit brute-force attacks on the system.
Checks: C-16147r284712_chk

Verify that the "libpam-pwquality" module is installed: # dpkg -l | grep libpam-pwquality ii libpam-pwquality:amd64 1.3.0-0ubuntu1 If the "libpam-pwquality" package is not installed, this is a finding. Verify the operating system uses "pwquality" to enforce the password complexity rules. Check for the use of "pwquality" with the following command: # cat /etc/pam.d/common-password | grep pam_pwquality password required pam_pwquality.so retry=3 If the command does not return an uncommented line containing the value "pam_pwquality.so", this is a finding. If the value of "retry" is set to "0" or greater than "3", this is a finding.

Fix: F-16145r284713_fix

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

b
The Ubuntu operating system must enforce password complexity by requiring that at least one upper-case character be used.
IA-5 - Medium - CCI-000192 - V-214949 - SV-214949r610931_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000192
Version
UBTU-16-010100
Vuln IDs
  • V-214949
  • V-75449
Rule IDs
  • SV-214949r610931_rule
  • SV-90129
Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.
Checks: C-16148r284715_chk

Verify the Ubuntu operating system enforces password complexity by requiring that at least one upper-case character be used. Determine if the field "ucredit" is set in the "/etc/security/pwquality.conf" 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: F-16146r284716_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

b
The Ubuntu operating system must enforce password complexity by requiring that at least one lower-case character be used.
IA-5 - Medium - CCI-000193 - V-214950 - SV-214950r610931_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000193
Version
UBTU-16-010110
Vuln IDs
  • V-214950
  • V-75451
Rule IDs
  • SV-214950r610931_rule
  • SV-90131
Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.
Checks: C-16149r284718_chk

Verify the Ubuntu operating system enforces password complexity by requiring that at least one lower-case character be used. Determine if the field "lcredit" is set in the "/etc/security/pwquality.conf" 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: F-16147r284719_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

b
The Ubuntu operating system must enforce password complexity by requiring that at least one numeric character be used.
IA-5 - Medium - CCI-000194 - V-214951 - SV-214951r610931_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000194
Version
UBTU-16-010120
Vuln IDs
  • V-214951
  • V-75453
Rule IDs
  • SV-214951r610931_rule
  • SV-90133
Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.
Checks: C-16150r284721_chk

Verify the Ubuntu operating system enforces password complexity by requiring that at least one numeric character be used. Determine if the field "dcredit" is set in the "/etc/security/pwquality.conf" 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: F-16148r284722_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

b
All passwords must contain at least one special character.
IA-5 - Medium - CCI-001619 - V-214952 - SV-214952r610931_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-001619
Version
UBTU-16-010130
Vuln IDs
  • V-214952
  • V-75455
Rule IDs
  • SV-214952r610931_rule
  • SV-90135
Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity or strength is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password complexity is one factor in determining how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised. Special characters are those characters that are not alphanumeric. Examples include: ~ ! @ # $ % ^ *.
Checks: C-16151r284724_chk

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: F-16149r284725_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

b
The Ubuntu operating system must require the change of at least 8 characters when passwords are changed.
IA-5 - Medium - CCI-000195 - V-214953 - SV-214953r610931_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000195
Version
UBTU-16-010140
Vuln IDs
  • V-214953
  • V-75457
Rule IDs
  • SV-214953r610931_rule
  • SV-90137
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: C-16152r284727_chk

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: F-16150r284728_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

b
The Ubuntu operating system must encrypt all stored passwords with a FIPS 140-2 approved cryptographic hashing algorithm.
IA-5 - Medium - CCI-000196 - V-214954 - SV-214954r610931_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000196
Version
UBTU-16-010150
Vuln IDs
  • V-214954
  • V-75459
Rule IDs
  • SV-214954r610931_rule
  • SV-90139
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: C-16153r284730_chk

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: F-16151r284731_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

b
The Ubuntu operating system must employ a FIPS 140-2 approved cryptographic hashing algorithms for all stored passwords.
IA-5 - Medium - CCI-000196 - V-214955 - SV-214955r610931_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000196
Version
UBTU-16-010160
Vuln IDs
  • V-214955
  • V-75461
Rule IDs
  • SV-214955r610931_rule
  • SV-90141
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: C-16154r284733_chk

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: F-16152r284734_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.

b
The Ubuntu operating system must employ FIPS 140-2 approved cryptographic hashing algorithms for all created passwords.
IA-5 - Medium - CCI-000196 - V-214956 - SV-214956r610931_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000196
Version
UBTU-16-010170
Vuln IDs
  • V-214956
  • V-75463
Rule IDs
  • SV-214956r610931_rule
  • SV-90143
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: C-16155r284736_chk

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: F-16153r284737_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

b
The pam_unix.so module must use a FIPS 140-2 approved cryptographic hashing algorithm for system authentication.
IA-7 - Medium - CCI-000803 - V-214957 - SV-214957r610931_rule
RMF Control
IA-7
Severity
Medium
CCI
CCI-000803
Version
UBTU-16-010180
Vuln IDs
  • V-214957
  • V-75465
Rule IDs
  • SV-214957r610931_rule
  • SV-90145
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: C-16156r284739_chk

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: F-16154r284740_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

b
Emergency administrator accounts must never be automatically removed or disabled.
AC-2 - Medium - CCI-001682 - V-214958 - SV-214958r610931_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-001682
Version
UBTU-16-010200
Vuln IDs
  • V-214958
  • V-75469
Rule IDs
  • SV-214958r610931_rule
  • SV-90149
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: C-16157r284742_chk

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: F-16155r284743_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]

b
Passwords for new users must have a 24 hours/1 day minimum password lifetime restriction.
IA-5 - Medium - CCI-000198 - V-214959 - SV-214959r610931_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000198
Version
UBTU-16-010210
Vuln IDs
  • V-214959
  • V-75471
Rule IDs
  • SV-214959r610931_rule
  • SV-90151
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: C-16158r284745_chk

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

Fix: F-16156r284746_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

b
Passwords for new users must have a 60-day maximum password lifetime restriction.
IA-5 - Medium - CCI-000199 - V-214960 - SV-214960r610931_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000199
Version
UBTU-16-010220
Vuln IDs
  • V-214960
  • V-75473
Rule IDs
  • SV-214960r610931_rule
  • SV-90153
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: C-16159r284748_chk

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: F-16157r284749_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

b
Passwords must be prohibited from reuse for a minimum of five generations.
IA-5 - Medium - CCI-000200 - V-214961 - SV-214961r610931_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000200
Version
UBTU-16-010230
Vuln IDs
  • V-214961
  • V-75475
Rule IDs
  • SV-214961r610931_rule
  • SV-90155
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: C-16160r284751_chk

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: F-16158r284752_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

b
Passwords must have a minimum of 15-characters.
IA-5 - Medium - CCI-000205 - V-214962 - SV-214962r610931_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-000205
Version
UBTU-16-010240
Vuln IDs
  • V-214962
  • V-75477
Rule IDs
  • SV-214962r610931_rule
  • SV-90157
The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.
Checks: C-16161r284754_chk

Verify that the Ubuntu operating system enforces a minimum "15" character password length. 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: F-16159r284755_fix

Configure the Ubuntu operating system to enforce a minimum 15-character password length. 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 "minlen" parameter: minlen=15

c
The Ubuntu operating system must not be configured to allow blank or null passwords.
CM-6 - High - CCI-000366 - V-214963 - SV-214963r610931_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
UBTU-16-010250
Vuln IDs
  • V-214963
  • V-75479
Rule IDs
  • SV-214963r610931_rule
  • SV-90159
If the operating system allows empty passwords, anyone could log on and run commands with the privileges. Empty passwords should never be used in operational environments.
Checks: C-16162r284757_chk

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: F-16160r284758_fix

Remove any instances of the "nullok" option in files under "/etc/pam.d/" to prevent logons with empty passwords.

b
The Ubuntu operating system must prevent the use of dictionary words for passwords.
CM-6 - Medium - CCI-000366 - V-214964 - SV-214964r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010260
Vuln IDs
  • V-214964
  • V-75481
Rule IDs
  • SV-214964r610931_rule
  • SV-90161
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: C-16163r284760_chk

Verify the Ubuntu operating system prevents the use of dictionary words for passwords. Determine 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: F-16161r284761_fix

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

b
The passwd command must be configured to prevent the use of dictionary words as passwords.
CM-6 - Medium - CCI-000366 - V-214965 - SV-214965r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010270
Vuln IDs
  • V-214965
  • V-75483
Rule IDs
  • SV-214965r610931_rule
  • SV-90163
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: C-16164r284763_chk

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: F-16162r284764_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

b
Account identifiers (individuals, groups, roles, and devices) must disabled after 35 days of inactivity.
IA-4 - Medium - CCI-000795 - V-214966 - SV-214966r610931_rule
RMF Control
IA-4
Severity
Medium
CCI
CCI-000795
Version
UBTU-16-010280
Vuln IDs
  • V-214966
  • V-75485
Rule IDs
  • SV-214966r610931_rule
  • SV-90165
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: C-16165r284766_chk

Verify the account identifiers (individuals, groups, roles, and devices) are disabled after "35" days of inactivity with the following command: Check the account inactivity value by performing the following command: # sudo grep -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: F-16163r284767_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.

b
The Ubuntu operating system must automatically lock an account until the locked account is released by an administrator when three unsuccessful logon attempts.
AC-7 - Medium - CCI-000044 - V-214967 - SV-214967r610931_rule
RMF Control
AC-7
Severity
Medium
CCI
CCI-000044
Version
UBTU-16-010290
Vuln IDs
  • V-214967
  • V-75487
Rule IDs
  • SV-214967r610931_rule
  • SV-90167
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: C-16166r284769_chk

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: F-16164r284770_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"

b
Accounts on the Ubuntu operating system that are subject to three unsuccessful logon attempts within 15 minutes must be locked for the maximum configurable period.
AC-7 - Medium - CCI-002238 - V-214968 - SV-214968r610931_rule
RMF Control
AC-7
Severity
Medium
CCI
CCI-002238
Version
UBTU-16-010291
Vuln IDs
  • V-214968
  • V-90351
Rule IDs
  • SV-214968r610931_rule
  • SV-101001
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.
Checks: C-16167r284772_chk

Verify the operating system automatically locks an account for the maximum period for which the system can be configured. Check that the system locks an account for the maximum period after three unsuccessful logon attempts within a period of 15 minutes with the following command: # grep pam_faillock.so /etc/pam.d/password-auth /etc/pam.d/system-auth auth required pam_faillock.so preauth silent audit deny=3 even_deny_root fail_interval=900 unlock_time=900 auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root fail_interval=900 unlock_time=900 account required pam_faillock.so If the "unlock_time" parameter is not set to "0", "never", or is set to a value less than "900" on both "auth" lines with the "pam_faillock.so" module, or is missing from these lines, this is a finding. Note: The maximum configurable value for "unlock_time" is "604800". If any line referencing the "pam_faillock.so" module is commented out, this is a finding.

Fix: F-16165r284773_fix

Configure the Ubuntu operating system to automatically lock an account for the maximum configurable period when three unsuccessful logon attempts are made by appending the following lines to the "etc/pam.d/password-auth" or "/etc/pam.d/system-auth" files" auth required pam_faillock.so preauth silent audit deny=3 even_deny_root fail_interval=900 unlock_time=900 auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root fail_interval=900 unlock_time=900 account required pam_faillock.so

b
The Ubuntu operating system must require users to re-authenticate for privilege escalation and changing roles.
IA-11 - Medium - CCI-002038 - V-214969 - SV-214969r610931_rule
RMF Control
IA-11
Severity
Medium
CCI
CCI-002038
Version
UBTU-16-010300
Vuln IDs
  • V-214969
  • V-75489
Rule IDs
  • SV-214969r610931_rule
  • SV-90169
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: C-16168r284775_chk

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: F-16166r284776_fix

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

b
Temporary user accounts must be provisioned with an expiration time of 72 hours or less.
AC-2 - Medium - CCI-000016 - V-214970 - SV-214970r610931_rule
RMF Control
AC-2
Severity
Medium
CCI
CCI-000016
Version
UBTU-16-010310
Vuln IDs
  • V-214970
  • V-75491
Rule IDs
  • SV-214970r610931_rule
  • SV-90171
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: C-16169r284778_chk

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: F-16167r284779_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

b
The Ubuntu operating system must enforce a delay of at least 4 seconds between logon prompts following a failed logon attempt.
CM-6 - Medium - CCI-000366 - V-214971 - SV-214971r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010320
Vuln IDs
  • V-214971
  • V-75493
Rule IDs
  • SV-214971r610931_rule
  • SV-90173
Limiting the number of logon attempts over a certain time interval reduces the chances that an unauthorized user may gain access to an account.
Checks: C-16170r284781_chk

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: F-16168r284782_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

c
Unattended or automatic login via the Graphical User Interface must not be allowed.
CM-6 - High - CCI-000366 - V-214972 - SV-214972r610931_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
UBTU-16-010330
Vuln IDs
  • V-214972
  • V-75495
Rule IDs
  • SV-214972r610931_rule
  • SV-90175
Failure to restrict system access to authenticated users negatively impacts Ubuntu operating system security.
Checks: C-16171r284784_chk

Verify that unattended or automatic login via the Graphical User Interface is disabled. Check that unattended or automatic login is disabled with the following command: # sudo grep -i autologin /etc/lightdm/lightdm.conf /etc/lightdm.d/*.conf | grep -v '#' If any results are returned, this is a finding.

Fix: F-16169r284785_fix

Configure the Graphical User Interface to not allow unattended or automatic login to the system. Comment or remove the following lines in "/etc/lightdm/lightdm.conf" file: #autologin-user=<username> #autologin-user-timeout=0

a
The Ubuntu operating system must display the date and time of the last successful account logon upon logon.
CM-6 - Low - CCI-000366 - V-214973 - SV-214973r610931_rule
RMF Control
CM-6
Severity
Low
CCI
CCI-000366
Version
UBTU-16-010340
Vuln IDs
  • V-214973
  • V-75497
Rule IDs
  • SV-214973r610931_rule
  • SV-90177
Providing users with feedback on when account accesses last occurred facilitates user recognition and reporting of unauthorized account use.
Checks: C-16172r284787_chk

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

Fix: F-16170r284788_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

c
There must be no .shosts files on the Ubuntu operating system.
CM-6 - High - CCI-000366 - V-214974 - SV-214974r610931_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
UBTU-16-010350
Vuln IDs
  • V-214974
  • V-75499
Rule IDs
  • SV-214974r610931_rule
  • SV-90179
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: C-16173r284790_chk

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: F-16171r284791_fix

Remove any found ".shosts" files from the Ubuntu operating system. # rm /[path]/[to]/[file]/.shosts

c
There must be no shosts.equiv files on the Ubuntu operating system.
CM-6 - High - CCI-000366 - V-214975 - SV-214975r610931_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
UBTU-16-010360
Vuln IDs
  • V-214975
  • V-75501
Rule IDs
  • SV-214975r610931_rule
  • SV-90181
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: C-16174r284793_chk

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: F-16172r284794_fix

Remove any found "shosts.equiv" files from the Ubuntu operating system. # rm /etc/ssh/shosts.equiv

c
The Ubuntu operating system must implement NSA-approved cryptography to protect classified information in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.
SC-13 - High - CCI-002450 - V-214976 - SV-214976r610931_rule
RMF Control
SC-13
Severity
High
CCI
CCI-002450
Version
UBTU-16-010370
Vuln IDs
  • V-214976
  • V-75503
Rule IDs
  • SV-214976r610931_rule
  • SV-90183
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: C-16175r284796_chk

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: F-16173r284797_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.

c
Ubuntu operating systems booted with a BIOS must require authentication upon booting into single-user and maintenance modes.
AC-3 - High - CCI-000213 - V-214977 - SV-214977r610931_rule
RMF Control
AC-3
Severity
High
CCI
CCI-000213
Version
UBTU-16-010380
Vuln IDs
  • V-214977
  • V-75505
Rule IDs
  • SV-214977r610931_rule
  • SV-90185
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: C-16176r284799_chk

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: F-16174r284800_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 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.10000.LONGSTRING Save the file and exit Run: sudo update-grub Reboot

c
Ubuntu operating systems booted with United Extensible Firmware Interface (UEFI) implemented must require authentication upon booting into single-user mode and maintenance.
AC-3 - High - CCI-000213 - V-214978 - SV-214978r610931_rule
RMF Control
AC-3
Severity
High
CCI
CCI-000213
Version
UBTU-16-010390
Vuln IDs
  • V-214978
  • V-75507
Rule IDs
  • SV-214978r610931_rule
  • SV-90187
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: C-16177r284802_chk

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/ubuntu/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: F-16175r284803_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/ubuntu/grub.cfg

c
All persistent disk partitions must implement cryptographic mechanisms to prevent unauthorized disclosure or modification of all information that requires at rest protection.
SC-28 - High - CCI-002475 - V-214979 - SV-214979r610931_rule
RMF Control
SC-28
Severity
High
CCI
CCI-002475
Version
UBTU-16-010400
Vuln IDs
  • V-214979
  • V-75509
Rule IDs
  • SV-214979r610931_rule
  • SV-90189
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: C-16178r284805_chk

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: F-16176r284806_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.

b
All public directories must be owned by root to prevent unauthorized and unintended information transferred via shared system resources.
SC-4 - Medium - CCI-001090 - V-214980 - SV-214980r610931_rule
RMF Control
SC-4
Severity
Medium
CCI
CCI-001090
Version
UBTU-16-010410
Vuln IDs
  • V-214980
  • V-75511
Rule IDs
  • SV-214980r610931_rule
  • SV-90191
Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DoD or other government agencies. There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components.
Checks: C-16179r284808_chk

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: F-16177r284809_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]

b
All world-writable directories must be group-owned by root, sys, bin, or an application group.
SC-4 - Medium - CCI-001090 - V-214981 - SV-214981r610931_rule
RMF Control
SC-4
Severity
Medium
CCI
CCI-001090
Version
UBTU-16-010420
Vuln IDs
  • V-214981
  • V-75513
Rule IDs
  • SV-214981r610931_rule
  • SV-90193
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: C-16180r284811_chk

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: F-16178r284812_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]

b
A file integrity tool must be installed to verify correct operation of all security functions in the Ubuntu operating system.
SI-6 - Medium - CCI-002696 - V-214982 - SV-214982r610931_rule
RMF Control
SI-6
Severity
Medium
CCI
CCI-002696
Version
UBTU-16-010500
Vuln IDs
  • V-214982
  • V-75515
Rule IDs
  • SV-214982r610931_rule
  • SV-90195
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: C-16181r284814_chk

Verify that Advanced Intrusion Detection Environment (AIDE) is installed and verifies the correct operation of all security functions. Check that the AIDE package is installed with the following command: # sudo 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: F-16179r284815_fix

Install the AIDE package by running the following command: # sudo apt-get install aide

b
The file integrity tool must perform verification of the correct operation of security functions: upon system start-up and/or restart; upon command by a user with privileged access; and/or every 30 days.
SI-6 - Medium - CCI-002699 - V-214983 - SV-214983r610931_rule
RMF Control
SI-6
Severity
Medium
CCI
CCI-002699
Version
UBTU-16-010510
Vuln IDs
  • V-214983
  • V-75517
Rule IDs
  • SV-214983r610931_rule
  • SV-90197
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: C-16182r284817_chk

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: F-16180r284818_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

a
The file integrity tool must be configured to verify Access Control Lists (ACLs).
CM-6 - Low - CCI-000366 - V-214984 - SV-214984r610931_rule
RMF Control
CM-6
Severity
Low
CCI
CCI-000366
Version
UBTU-16-010520
Vuln IDs
  • V-214984
  • V-75519
Rule IDs
  • SV-214984r610931_rule
  • SV-90199
ACLs can provide permissions beyond those permitted through the file mode and must be verified by file integrity tools.
Checks: C-16183r284820_chk

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: F-16181r284821_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.

a
The file integrity tool must be configured to verify extended attributes.
CM-6 - Low - CCI-000366 - V-214985 - SV-214985r610931_rule
RMF Control
CM-6
Severity
Low
CCI
CCI-000366
Version
UBTU-16-010530
Vuln IDs
  • V-214985
  • V-75521
Rule IDs
  • SV-214985r610931_rule
  • SV-90201
Extended attributes in file systems are used to contain arbitrary data and file metadata with security implications.
Checks: C-16184r284823_chk

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: F-16182r284824_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.

b
The file integrity tool must notify the system administrator when changes to the baseline configuration or anomalies in the operation of any security functions are discovered.
SI-6 - Medium - CCI-002702 - V-214986 - SV-214986r610931_rule
RMF Control
SI-6
Severity
Medium
CCI
CCI-002702
Version
UBTU-16-010540
Vuln IDs
  • V-214986
  • V-75523
Rule IDs
  • SV-214986r610931_rule
  • SV-90203
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: C-16185r284826_chk

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/default/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: F-16183r284827_fix

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

b
The Ubuntu operating system must use cryptographic mechanisms to protect the integrity of audit tools.
AU-9 - Medium - CCI-001496 - V-214987 - SV-214987r610931_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001496
Version
UBTU-16-010550
Vuln IDs
  • V-214987
  • V-75525
Rule IDs
  • SV-214987r610931_rule
  • SV-90205
Protecting the integrity of the tools used for auditing purposes is a critical step toward ensuring the integrity of audit information. Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators. It is not uncommon for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs. To address this risk, audit tools must be cryptographically signed in order to provide the capability to identify when the audit tools have been modified, manipulated, or replaced. An example is a checksum hash of the file or files.
Checks: C-16186r284829_chk

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: F-16184r284830_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

b
Advance package Tool (APT) must be configured to prevent the installation of patches, service packs, device drivers, or Ubuntu operating system components without verification they have been digitally signed using a certificate that is recognized and approved by the organization.
CM-5 - Medium - CCI-001749 - V-214988 - SV-214988r610931_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001749
Version
UBTU-16-010560
Vuln IDs
  • V-214988
  • V-75527
Rule IDs
  • SV-214988r610931_rule
  • SV-90207
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: C-16187r466249_chk

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: F-16185r466250_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";

b
Advance package Tool (APT) must remove all software components after updated versions have been installed.
SI-2 - Medium - CCI-002617 - V-214989 - SV-214989r610931_rule
RMF Control
SI-2
Severity
Medium
CCI
CCI-002617
Version
UBTU-16-010570
Vuln IDs
  • V-214989
  • V-75529
Rule IDs
  • SV-214989r610931_rule
  • SV-90209
Previous versions of software components that are not removed from the information system after updates have been installed may be exploited by adversaries. Some information technology products may remove older versions of software automatically from the information system.
Checks: C-16188r284835_chk

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: F-16186r284836_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";

b
Automatic mounting of Universal Serial Bus (USB) mass storage driver must be disabled.
IA-3 - Medium - CCI-001958 - V-214990 - SV-214990r610931_rule
RMF Control
IA-3
Severity
Medium
CCI
CCI-001958
Version
UBTU-16-010580
Vuln IDs
  • V-214990
  • V-75531
Rule IDs
  • SV-214990r610931_rule
  • SV-90211
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: C-16189r284838_chk

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: F-16187r284839_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

b
File system automounter must be disabled unless required.
IA-3 - Medium - CCI-001958 - V-214991 - SV-214991r610931_rule
RMF Control
IA-3
Severity
Medium
CCI
CCI-001958
Version
UBTU-16-010590
Vuln IDs
  • V-214991
  • V-75533
Rule IDs
  • SV-214991r610931_rule
  • SV-90213
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: C-16190r284841_chk

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: F-16188r284842_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).

b
Pam_Apparmor must be configured to allow system administrators to pass information to any other Ubuntu operating system administrator or user, change security attributes, and to confine all non-privileged users from executing functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures.
AC-6 - Medium - CCI-002235 - V-214992 - SV-214992r610931_rule
RMF Control
AC-6
Severity
Medium
CCI
CCI-002235
Version
UBTU-16-010600
Vuln IDs
  • V-214992
  • V-75535
Rule IDs
  • SV-214992r610931_rule
  • SV-90215
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: C-16191r466237_chk

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: F-16189r466238_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.

b
The Apparmor module must be configured to employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs and limit the ability of non-privileged users to grant other users direct access to the contents of their home directories/folders.
CM-7 - Medium - CCI-001764 - V-214993 - SV-214993r610931_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-001764
Version
UBTU-16-010610
Vuln IDs
  • V-214993
  • V-75537
Rule IDs
  • SV-214993r610931_rule
  • SV-90217
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: C-16192r466243_chk

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: F-16190r466244_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.

c
The x86 Ctrl-Alt-Delete key sequence must be disabled.
CM-6 - High - CCI-000366 - V-214994 - SV-214994r610931_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
UBTU-16-010630
Vuln IDs
  • V-214994
  • V-75541
Rule IDs
  • SV-214994r610931_rule
  • SV-90221
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: C-16193r284850_chk

Verify the Ubuntu operating system is not configured to reboot the system when Ctrl-Alt-Delete is pressed. Check that the "ctrl-alt-del.target" (otherwise also known as reboot.target) is not active with the following command: # 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: F-16191r284851_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

c
The x86 Ctrl-Alt-Delete key sequence in the Ubuntu operating system must be disabled if a Graphical User Interface is installed.
CM-6 - High - CCI-000366 - V-214995 - SV-214995r610931_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
UBTU-16-010631
Vuln IDs
  • V-214995
  • V-80957
Rule IDs
  • SV-214995r610931_rule
  • SV-95669
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 a graphical environment, risk of unintentional reboot from the Ctrl-Alt-Delete sequence is reduced because the user will be prompted before any action is taken.
Checks: C-16194r284853_chk

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

Fix: F-16192r284854_fix

Configure the system to disable the Ctrl-Alt-Delete sequence when using a graphical user interface. Note: These settings are examples using the operating system's default (GNOME) graphical user interface. Create or edit the /etc/dconf/db/local.d/00-disable-CAD file. Add the setting to disable the Ctrl-Alt-Delete sequence: [org/gnome/settings-daemon/plugins/media-keys] logout=’’ Then update the dconf settings: # dconf update

b
Default permissions must be defined in such a way that all authenticated users can only read and modify their own files.
CM-6 - Medium - CCI-000366 - V-214996 - SV-214996r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010640
Vuln IDs
  • V-214996
  • V-75543
Rule IDs
  • SV-214996r610931_rule
  • SV-90223
Setting the most restrictive default permissions ensures that when new accounts are created they do not have unnecessary access.
Checks: C-16195r284856_chk

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: F-16193r284857_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

b
The Ubuntu operating system must not have unnecessary accounts.
CM-6 - Medium - CCI-000366 - V-214997 - SV-214997r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010650
Vuln IDs
  • V-214997
  • V-75545
Rule IDs
  • SV-214997r610931_rule
  • SV-90225
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: C-16196r284859_chk

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: F-16194r284860_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.

b
Duplicate User IDs (UIDs) must not exist for interactive users.
IA-2 - Medium - CCI-000764 - V-214998 - SV-214998r610931_rule
RMF Control
IA-2
Severity
Medium
CCI
CCI-000764
Version
UBTU-16-010660
Vuln IDs
  • V-214998
  • V-75547
Rule IDs
  • SV-214998r610931_rule
  • SV-90227
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: C-16197r284862_chk

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: F-16195r284863_fix

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

c
The root account must be the only account having unrestricted access to the system.
CM-6 - High - CCI-000366 - V-214999 - SV-214999r610931_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
UBTU-16-010670
Vuln IDs
  • V-214999
  • V-75549
Rule IDs
  • SV-214999r610931_rule
  • SV-90229
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: C-16198r284865_chk

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: F-16196r284866_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.

b
User accounts with temporary passwords, must require an immediate change to a permanent password after login.
IA-5 - Medium - CCI-002041 - V-215000 - SV-215000r610931_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-002041
Version
UBTU-16-010680
Vuln IDs
  • V-215000
  • V-75551
Rule IDs
  • SV-215000r610931_rule
  • SV-90231
Without providing this capability, an account may be created without a password. Non-repudiation cannot be guaranteed once an account is created if a user is not forced to change the temporary password upon initial logon. Temporary passwords are typically used to allow access when new accounts are created or passwords are changed. It is common practice for administrators to create temporary passwords for user accounts which allow the users to log on, yet force them to change the password once they have successfully authenticated.
Checks: C-16199r284868_chk

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

Fix: F-16197r284869_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]

b
Pluggable Authentication Module (PAM) must prohibit the use of cached authentications after one day.
IA-5 - Medium - CCI-002007 - V-215001 - SV-215001r610931_rule
RMF Control
IA-5
Severity
Medium
CCI
CCI-002007
Version
UBTU-16-010690
Vuln IDs
  • V-215001
  • V-75553
Rule IDs
  • SV-215001r610931_rule
  • SV-90233
If cached authentication information is out-of-date, the validity of the authentication information may be questionable.
Checks: C-16200r284871_chk

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: F-16198r284872_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

b
All files and directories must have a valid owner.
AC-3 - Medium - CCI-002165 - V-215002 - SV-215002r610931_rule
RMF Control
AC-3
Severity
Medium
CCI
CCI-002165
Version
UBTU-16-010700
Vuln IDs
  • V-215002
  • V-75555
Rule IDs
  • SV-215002r610931_rule
  • SV-90235
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: C-16201r284874_chk

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: F-16199r284875_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>

b
All files and directories must have a valid group owner.
AC-3 - Medium - CCI-002165 - V-215003 - SV-215003r610931_rule
RMF Control
AC-3
Severity
Medium
CCI
CCI-002165
Version
UBTU-16-010710
Vuln IDs
  • V-215003
  • V-75557
Rule IDs
  • SV-215003r610931_rule
  • SV-90237
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: C-16202r284877_chk

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: F-16200r284878_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>

b
All local interactive users must have a home directory assigned in the /etc/passwd file.
CM-6 - Medium - CCI-000366 - V-215004 - SV-215004r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010720
Vuln IDs
  • V-215004
  • V-75559
Rule IDs
  • SV-215004r610931_rule
  • SV-90239
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: C-16203r284880_chk

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: F-16201r284881_fix

Assign home directories to all local interactive users on the Ubuntu operating system that currently do not have a home directory assigned.

b
All local interactive user accounts, upon creation, must be assigned a home directory.
CM-6 - Medium - CCI-000366 - V-215005 - SV-215005r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010730
Vuln IDs
  • V-215005
  • V-75561
Rule IDs
  • SV-215005r610931_rule
  • SV-90241
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: C-16204r284883_chk

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: F-16202r284884_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

b
All local interactive user home directories defined in the /etc/passwd file must exist.
CM-6 - Medium - CCI-000366 - V-215006 - SV-215006r648699_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010740
Vuln IDs
  • V-215006
  • V-75563
Rule IDs
  • SV-215006r648699_rule
  • SV-90243
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: C-16205r648697_chk

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: $ sudo awk -F: '($3&gt;=1000)&amp;&amp;($7 !~ /nologin/){print $1, $3, $6}' /etc/passwd smithj 1001 /home/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: $ sudo 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: F-16203r648698_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". $ sudo mkdir /home/smithj $ sudo chown smithj /home/smithj $ sudo chgrp users /home/smithj $ sudo chmod 0750 /home/smithj

b
All local interactive user home directories must have mode 0750 or less permissive.
CM-6 - Medium - CCI-000366 - V-215007 - SV-215007r648702_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010750
Vuln IDs
  • V-215007
  • V-75565
Rule IDs
  • SV-215007r648702_rule
  • SV-90245
Excessive permissions on local interactive user home directories may allow unauthorized access to user files by other users.
Checks: C-16206r648700_chk

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. $ sudo ls -ld $(awk -F: '($3&gt;=1000)&amp;&amp;($7 !~ /nologin/){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: F-16204r648701_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". $ sudo chmod 0750 /home/smithj

b
All local interactive user home directories must be group-owned by the home directory owners primary group.
CM-6 - Medium - CCI-000366 - V-215008 - SV-215008r648705_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010760
Vuln IDs
  • V-215008
  • V-75567
Rule IDs
  • SV-215008r648705_rule
  • SV-90247
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: C-16207r648703_chk

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. $ sudo ls -ld $(awk -F: '($3&gt;=1000)&amp;&amp;($7 !~ /nologin/){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: $ sudo 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: F-16205r648704_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. $ sudo chgrp users /home/smithj

b
All local initialization files must have mode 0740 or less permissive.
CM-6 - Medium - CCI-000366 - V-215009 - SV-215009r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010770
Vuln IDs
  • V-215009
  • V-75569
Rule IDs
  • SV-215009r610931_rule
  • SV-90249
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: C-16208r284895_chk

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: F-16206r284896_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>

b
All local interactive user initialization files executable search paths must contain only paths that resolve to the system default or the users home directory.
CM-6 - Medium - CCI-000366 - V-215010 - SV-215010r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010780
Vuln IDs
  • V-215010
  • V-75571
Rule IDs
  • SV-215010r610931_rule
  • SV-90251
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: C-16209r284898_chk

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: F-16207r284899_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).

b
Local initialization files must not execute world-writable programs.
CM-6 - Medium - CCI-000366 - V-215011 - SV-215011r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010790
Vuln IDs
  • V-215011
  • V-75573
Rule IDs
  • SV-215011r610931_rule
  • SV-90253
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: C-16210r284901_chk

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 &lt;file&gt; /home/*/.* If any local initialization files are found to reference world-writable files, this is a finding.

Fix: F-16208r284902_fix

Set the mode on files being executed by the local initialization files with the following command: # chmod 0755 <file>

b
File systems that contain user home directories must be mounted to prevent files with the setuid and setguid bit set from being executed.
CM-6 - Medium - CCI-000366 - V-215012 - SV-215012r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010800
Vuln IDs
  • V-215012
  • V-75575
Rule IDs
  • SV-215012r610931_rule
  • SV-90255
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: C-16211r284904_chk

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&gt;=1000)&amp;&amp;($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: F-16209r284905_fix

Configure the "/etc/fstab" to use the "nosuid" option on file systems that contain user home directories for interactive users.

b
File systems that are used with removable media must be mounted to prevent files with the setuid and setguid bit set from being executed.
CM-6 - Medium - CCI-000366 - V-215013 - SV-215013r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010810
Vuln IDs
  • V-215013
  • V-75577
Rule IDs
  • SV-215013r610931_rule
  • SV-90257
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: C-16212r284907_chk

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: F-16210r284908_fix

Configure the "/etc/fstab" to use the "nosuid" option on file systems that are associated with removable media.

b
File systems that are being imported via Network File System (NFS) must be mounted to prevent files with the setuid and setguid bit set from being executed.
CM-6 - Medium - CCI-000366 - V-215014 - SV-215014r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010820
Vuln IDs
  • V-215014
  • V-75579
Rule IDs
  • SV-215014r610931_rule
  • SV-90259
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: C-16213r284910_chk

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: F-16211r284911_fix

Configure the "/etc/fstab" to use the "nosuid" option on file systems that are being imported via Network File System (NFS).

b
File systems that are being imported via Network File System (NFS) must be mounted to prevent binary files from being executed.
CM-6 - Medium - CCI-000366 - V-215015 - SV-215015r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010830
Vuln IDs
  • V-215015
  • V-75581
Rule IDs
  • SV-215015r610931_rule
  • SV-90261
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: C-16214r284913_chk

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: F-16212r284914_fix

Configure the "/etc/fstab" to use the "noexec" option on file systems that are being imported via Network File System (NFS).

b
Kernel core dumps must be disabled unless needed.
CM-6 - Medium - CCI-000366 - V-215016 - SV-215016r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010900
Vuln IDs
  • V-215016
  • V-75585
Rule IDs
  • SV-215016r610931_rule
  • SV-90265
Kernel core dumps may contain the full contents of system memory at the time of the crash. Kernel core dumps may consume a considerable amount of disk space and may result in denial of service by exhausting the available space on the target file system partition.
Checks: C-16215r284916_chk

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: F-16213r284917_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).

b
A separate file system must be used for user home directories (such as /home or an equivalent).
CM-6 - Medium - CCI-000366 - V-215017 - SV-215017r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-010910
Vuln IDs
  • V-215017
  • V-75587
Rule IDs
  • SV-215017r610931_rule
  • SV-90267
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: C-16216r284919_chk

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&gt;=1000)&amp;&amp;($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: F-16214r284920_fix

Migrate the "/home" directory onto a separate file system/partition.

a
The Ubuntu operating system must use a separate file system for /var.
CM-6 - Low - CCI-000366 - V-215018 - SV-215018r610931_rule
RMF Control
CM-6
Severity
Low
CCI
CCI-000366
Version
UBTU-16-010920
Vuln IDs
  • V-215018
  • V-75589
Rule IDs
  • SV-215018r610931_rule
  • SV-90269
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: C-16217r284922_chk

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: F-16215r284923_fix

Migrate the "/var" path onto a separate file system.

a
The Ubuntu operating system must use a separate file system for the system audit data path.
CM-6 - Low - CCI-000366 - V-215019 - SV-215019r610931_rule
RMF Control
CM-6
Severity
Low
CCI
CCI-000366
Version
UBTU-16-010930
Vuln IDs
  • V-215019
  • V-75591
Rule IDs
  • SV-215019r610931_rule
  • SV-90271
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: C-16218r284925_chk

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: F-16216r284926_fix

Migrate the system audit data path onto a separate file system.

b
The /var/log directory must be group-owned by syslog.
SI-11 - Medium - CCI-001314 - V-215020 - SV-215020r610931_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
UBTU-16-010940
Vuln IDs
  • V-215020
  • V-75593
Rule IDs
  • SV-215020r610931_rule
  • SV-90273
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: C-16219r284928_chk

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: F-16217r284929_fix

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

b
The /var/log directory must be owned by root.
SI-11 - Medium - CCI-001314 - V-215021 - SV-215021r610931_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
UBTU-16-010950
Vuln IDs
  • V-215021
  • V-75595
Rule IDs
  • SV-215021r610931_rule
  • SV-90275
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: C-16220r284931_chk

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: F-16218r284932_fix

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

b
The /var/log directory must have mode 0770 or less permissive.
SI-11 - Medium - CCI-001314 - V-215022 - SV-215022r610931_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
UBTU-16-010960
Vuln IDs
  • V-215022
  • V-75597
Rule IDs
  • SV-215022r610931_rule
  • SV-90277
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: C-16221r284934_chk

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: F-16219r284935_fix

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

b
The /var/log/syslog file must be group-owned by adm.
SI-11 - Medium - CCI-001314 - V-215023 - SV-215023r610931_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
UBTU-16-010970
Vuln IDs
  • V-215023
  • V-75599
Rule IDs
  • SV-215023r610931_rule
  • SV-90279
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: C-16222r284937_chk

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: F-16220r284938_fix

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

b
The /var/log/syslog file must be owned by syslog.
SI-11 - Medium - CCI-001314 - V-215024 - SV-215024r610931_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
UBTU-16-010980
Vuln IDs
  • V-215024
  • V-75601
Rule IDs
  • SV-215024r610931_rule
  • SV-90281
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: C-16223r284940_chk

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: F-16221r284941_fix

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

b
The /var/log/syslog file must have mode 0640 or less permissive.
SI-11 - Medium - CCI-001314 - V-215025 - SV-215025r610931_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
UBTU-16-010990
Vuln IDs
  • V-215025
  • V-75603
Rule IDs
  • SV-215025r610931_rule
  • SV-90283
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: C-16224r284943_chk

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: F-16222r364833_fix

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

b
Library files must have mode 0755 or less permissive.
CM-5 - Medium - CCI-001499 - V-215026 - SV-215026r610931_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001499
Version
UBTU-16-011000
Vuln IDs
  • V-215026
  • V-75605
Rule IDs
  • SV-215026r610931_rule
  • SV-90285
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: C-16225r284946_chk

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: F-16223r284947_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]

b
Library files must be owned by root.
CM-5 - Medium - CCI-001499 - V-215027 - SV-215027r610931_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001499
Version
UBTU-16-011010
Vuln IDs
  • V-215027
  • V-75607
Rule IDs
  • SV-215027r610931_rule
  • SV-90287
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: C-16226r284949_chk

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: F-16224r284950_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]

b
Library files must be group-owned by root.
CM-5 - Medium - CCI-001499 - V-215028 - SV-215028r610931_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001499
Version
UBTU-16-011020
Vuln IDs
  • V-215028
  • V-75609
Rule IDs
  • SV-215028r610931_rule
  • SV-90289
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: C-16227r284952_chk

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: F-16225r284953_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]

b
System commands must have mode 0755 or less permissive.
CM-5 - Medium - CCI-001499 - V-215029 - SV-215029r610931_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001499
Version
UBTU-16-011030
Vuln IDs
  • V-215029
  • V-75611
Rule IDs
  • SV-215029r610931_rule
  • SV-90291
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: C-16228r284955_chk

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: F-16226r284956_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]

b
System commands must be owned by root.
CM-5 - Medium - CCI-001499 - V-215030 - SV-215030r610931_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001499
Version
UBTU-16-011040
Vuln IDs
  • V-215030
  • V-75613
Rule IDs
  • SV-215030r610931_rule
  • SV-90293
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: C-16229r284958_chk

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: F-16227r284959_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]

b
System commands must be group-owned by root.
CM-5 - Medium - CCI-001499 - V-215031 - SV-215031r610931_rule
RMF Control
CM-5
Severity
Medium
CCI
CCI-001499
Version
UBTU-16-011050
Vuln IDs
  • V-215031
  • V-75615
Rule IDs
  • SV-215031r610931_rule
  • SV-90295
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: C-16230r284961_chk

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: F-16228r284962_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]

b
Audit records must contain information to establish what type of events occurred, the source of events, where events occurred, and the outcome of events.
AU-12 - Medium - CCI-000172 - V-215032 - SV-215032r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020000
Vuln IDs
  • V-215032
  • V-75617
Rule IDs
  • SV-215032r610931_rule
  • SV-90297
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: C-16231r284964_chk

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: F-16229r284965_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

b
The auditd service must be running in the Ubuntu operating system.
CM-6 - Medium - CCI-000366 - V-215033 - SV-215033r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-020010
Vuln IDs
  • V-215033
  • V-80959
Rule IDs
  • SV-215033r610931_rule
  • SV-95671
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: C-16232r284967_chk

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: F-16230r284968_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

b
The Ubuntu operating system must allocate audit record storage capacity to store at least one weeks worth of audit records, when audit records are not immediately sent to a central audit record storage facility.
AU-4 - Medium - CCI-001849 - V-215034 - SV-215034r610931_rule
RMF Control
AU-4
Severity
Medium
CCI
CCI-001849
Version
UBTU-16-020020
Vuln IDs
  • V-215034
  • V-75621
Rule IDs
  • SV-215034r610931_rule
  • SV-90301
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: C-16233r284970_chk

Verify the Ubuntu operating system allocates audit record storage capacity to store at least one week's worth of audit records when audit records are not immediately sent to a central audit record storage facility. Determine which partition the audit records are being written to with the following command: # sudo grep log_file /etc/audit/auditd.conf log_file = /var/log/audit/audit.log Check the size of the partition that audit records are written to (with the example being /var/log/audit/) with the following command: # 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: F-16231r284971_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.

b
The Ubuntu operating system must notify 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.
AU-5 - Medium - CCI-001855 - V-215035 - SV-215035r610931_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-001855
Version
UBTU-16-020021
Vuln IDs
  • V-215035
  • V-80961
Rule IDs
  • SV-215035r610931_rule
  • SV-95673
If security personnel are not notified immediately when storage volume reaches 75% utilization, they are unable to plan for audit record storage capacity expansion.
Checks: C-16234r284973_chk

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 &lt;partition&gt; 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: F-16232r284974_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.

b
The Ubuntu operating system must notify 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.
AU-5 - Medium - CCI-001855 - V-215036 - SV-215036r610931_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-001855
Version
UBTU-16-020030
Vuln IDs
  • V-215036
  • V-75623
Rule IDs
  • SV-215036r610931_rule
  • SV-90303
If security personnel are not notified immediately when storage volume reaches 75% utilization, they are unable to plan for audit record storage capacity expansion.
Checks: C-16235r284976_chk

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 root@localhost 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: F-16233r284977_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).

b
The System Administrator (SA) and Information System Security Officer (ISSO) (at a minimum) must be alerted of an audit processing failure event.
AU-5 - Medium - CCI-000139 - V-215037 - SV-215037r610931_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-000139
Version
UBTU-16-020040
Vuln IDs
  • V-215037
  • V-75625
Rule IDs
  • SV-215037r610931_rule
  • SV-90305
It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without this notification, the security personnel may be unaware of an impending failure of the audit capability, and system operation may be adversely affected. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both.
Checks: C-16236r284979_chk

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: F-16234r284980_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

b
The System Administrator (SA) and Information System Security Officer (ISSO) (at a minimum) must be alerted when the audit storage volume is full.
AU-5 - Medium - CCI-000140 - V-215038 - SV-215038r610931_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-000140
Version
UBTU-16-020050
Vuln IDs
  • V-215038
  • V-75627
Rule IDs
  • SV-215038r610931_rule
  • SV-90307
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: C-16237r284982_chk

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: F-16235r284983_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

b
The audit system must take appropriate action when the audit storage volume is full.
AU-5 - Medium - CCI-000140 - V-215039 - SV-215039r610931_rule
RMF Control
AU-5
Severity
Medium
CCI
CCI-000140
Version
UBTU-16-020060
Vuln IDs
  • V-215039
  • V-75629
Rule IDs
  • SV-215039r610931_rule
  • SV-90309
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: C-16238r284985_chk

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: F-16236r284986_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

b
The remote audit system must take appropriate action when audit storage is full.
AU-4 - Medium - CCI-001851 - V-215040 - SV-215040r610931_rule
RMF Control
AU-4
Severity
Medium
CCI
CCI-001851
Version
UBTU-16-020070
Vuln IDs
  • V-215040
  • V-75631
Rule IDs
  • SV-215040r610931_rule
  • SV-90311
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: C-16239r284988_chk

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: F-16237r284989_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

b
Off-loading audit records to another system must be authenticated.
AU-4 - Medium - CCI-001851 - V-215041 - SV-215041r610931_rule
RMF Control
AU-4
Severity
Medium
CCI
CCI-001851
Version
UBTU-16-020080
Vuln IDs
  • V-215041
  • V-75633
Rule IDs
  • SV-215041r610931_rule
  • SV-90313
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: C-16240r284991_chk

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: F-16238r284992_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

b
Audit logs must have a mode of 0600 or less permissive to prevent unauthorized read access.
AU-9 - Medium - CCI-000162 - V-215042 - SV-215042r610931_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000162
Version
UBTU-16-020090
Vuln IDs
  • V-215042
  • V-75635
Rule IDs
  • SV-215042r610931_rule
  • SV-90315
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: C-16241r284994_chk

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: F-16239r284995_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".

b
Audit log directories must have a mode of 0750 or less permissive to prevent unauthorized read access.
AU-9 - Medium - CCI-000164 - V-215043 - SV-215043r610931_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000164
Version
UBTU-16-020100
Vuln IDs
  • V-215043
  • V-75637
Rule IDs
  • SV-215043r610931_rule
  • SV-90317
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: C-16242r284997_chk

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: F-16240r284998_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".

b
Audit logs must be owned by root to prevent unauthorized read access.
AU-9 - Medium - CCI-000162 - V-215044 - SV-215044r610931_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000162
Version
UBTU-16-020110
Vuln IDs
  • V-215044
  • V-75639
Rule IDs
  • SV-215044r610931_rule
  • SV-90319
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: C-16243r285000_chk

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: F-16241r285001_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".

b
Audit logs must be group-owned by root to prevent unauthorized read access.
AU-9 - Medium - CCI-000164 - V-215045 - SV-215045r610931_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000164
Version
UBTU-16-020120
Vuln IDs
  • V-215045
  • V-75641
Rule IDs
  • SV-215045r610931_rule
  • SV-90321
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: C-16244r285003_chk

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: F-16242r285004_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".

b
Audit log directory must be owned by root to prevent unauthorized read access.
AU-9 - Medium - CCI-000162 - V-215046 - SV-215046r610931_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000162
Version
UBTU-16-020130
Vuln IDs
  • V-215046
  • V-75643
Rule IDs
  • SV-215046r610931_rule
  • SV-90323
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: C-16245r285006_chk

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: F-16243r285007_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".

b
Audit log directory must be group-owned by root to prevent unauthorized read access.
AU-9 - Medium - CCI-000163 - V-215047 - SV-215047r610931_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-000163
Version
UBTU-16-020140
Vuln IDs
  • V-215047
  • V-75645
Rule IDs
  • SV-215047r610931_rule
  • SV-90325
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: C-16246r285009_chk

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: F-16244r285010_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".

b
The Ubuntu operating system must allow only the Information System Security Manager (ISSM) (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.
AU-12 - Medium - CCI-000171 - V-215048 - SV-215048r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000171
Version
UBTU-16-020150
Vuln IDs
  • V-215048
  • V-75647
Rule IDs
  • SV-215048r610931_rule
  • SV-90327
Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident or identify those responsible for one.
Checks: C-16247r285012_chk

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: F-16245r285013_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

b
The audit log files must be owned by root.
SI-11 - Medium - CCI-001314 - V-215049 - SV-215049r610931_rule
RMF Control
SI-11
Severity
Medium
CCI
CCI-001314
Version
UBTU-16-020160
Vuln IDs
  • V-215049
  • V-75649
Rule IDs
  • SV-215049r610931_rule
  • SV-90329
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: C-16248r285015_chk

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: F-16246r285016_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]

b
Audit tools must have a mode of 0755 or less permissive.
AU-9 - Medium - CCI-001493 - V-215050 - SV-215050r610931_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001493
Version
UBTU-16-020180
Vuln IDs
  • V-215050
  • V-75653
Rule IDs
  • SV-215050r610931_rule
  • SV-90333
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: C-16249r285018_chk

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: F-16247r285019_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.

b
Audit tools must be owned by root.
AU-9 - Medium - CCI-001495 - V-215051 - SV-215051r610931_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001495
Version
UBTU-16-020190
Vuln IDs
  • V-215051
  • V-75655
Rule IDs
  • SV-215051r610931_rule
  • SV-90335
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: C-16250r285021_chk

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: F-16248r285022_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".

b
Audit tools must be group-owned by root.
AU-9 - Medium - CCI-001493 - V-215052 - SV-215052r610931_rule
RMF Control
AU-9
Severity
Medium
CCI
CCI-001493
Version
UBTU-16-020200
Vuln IDs
  • V-215052
  • V-75657
Rule IDs
  • SV-215052r610931_rule
  • SV-90337
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: C-16251r285024_chk

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: F-16249r285025_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".

b
The audit event multiplexor must be configured to off-load audit logs onto a different system or storage media from the system being audited.
AU-4 - Medium - CCI-001851 - V-215053 - SV-215053r610931_rule
RMF Control
AU-4
Severity
Medium
CCI
CCI-001851
Version
UBTU-16-020210
Vuln IDs
  • V-215053
  • V-75659
Rule IDs
  • SV-215053r610931_rule
  • SV-90339
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: C-16252r466246_chk

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, ask the System Administrator to indicate how the audit logs are off-loaded to a different system or storage media. If there is no evidence that the system is configured to off-load audit logs to a different system or storage media, this is a finding.

Fix: F-16250r466247_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

b
The audit records must be off-loaded onto a different system or storage media from the system being audited.
AU-4 - Medium - CCI-001851 - V-215054 - SV-215054r610931_rule
RMF Control
AU-4
Severity
Medium
CCI
CCI-001851
Version
UBTU-16-020220
Vuln IDs
  • V-215054
  • V-80965
Rule IDs
  • SV-215054r610931_rule
  • SV-95677
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: C-16253r285030_chk

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: F-16251r285031_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

b
The Ubuntu operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/passwd.
AU-12 - Medium - CCI-000172 - V-215055 - SV-215055r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020300
Vuln IDs
  • V-215055
  • V-75661
Rule IDs
  • SV-215055r610931_rule
  • SV-90341
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: C-16254r285033_chk

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: F-16252r285034_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

b
The Ubuntu operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/group.
AU-3 - Medium - CCI-000130 - V-215056 - SV-215056r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020310
Vuln IDs
  • V-215056
  • V-75663
Rule IDs
  • SV-215056r610931_rule
  • SV-90343
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: C-16255r285036_chk

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: F-16253r285037_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

b
The Ubuntu operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/gshadow.
AU-12 - Medium - CCI-000172 - V-215057 - SV-215057r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020320
Vuln IDs
  • V-215057
  • V-75665
Rule IDs
  • SV-215057r610931_rule
  • SV-90345
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: C-16256r285039_chk

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: F-16254r285040_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

b
The Ubuntu operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/shadow.
AU-3 - Medium - CCI-000130 - V-215058 - SV-215058r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020330
Vuln IDs
  • V-215058
  • V-75667
Rule IDs
  • SV-215058r610931_rule
  • SV-90347
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: C-16257r285042_chk

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: F-16255r285043_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

b
The Ubuntu operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/security/opasswd.
AU-12 - Medium - CCI-000172 - V-215059 - SV-215059r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020340
Vuln IDs
  • V-215059
  • V-75687
Rule IDs
  • SV-215059r610931_rule
  • SV-90367
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: C-16258r285045_chk

Verify the Ubuntu operating system generates audit records for all account creations, modifications, disabling, and termination events that affect "/etc/security/opasswd". Check the 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: F-16256r285046_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

b
The audit system must be configured to audit the execution of privileged functions and prevent all software from executing at higher privilege levels than users executing the software.
AC-6 - Medium - CCI-002233 - V-215060 - SV-215060r610931_rule
RMF Control
AC-6
Severity
Medium
CCI
CCI-002233
Version
UBTU-16-020350
Vuln IDs
  • V-215060
  • V-90365
Rule IDs
  • SV-215060r610931_rule
  • SV-101015
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: C-16259r621624_chk

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 euid=0 -F key=execpriv -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -F key=execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -F key=execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -F key=execpriv If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-16257r621625_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 euid=0 -F key=execpriv -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -F key=execpriv -a always,exit -F arch=b32 -S execve -C gid!=egid -F egid=0 -F key=execpriv -a always,exit -F arch=b64 -S execve -C gid!=egid -F egid=0 -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

b
Successful/unsuccessful uses of the su command must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215061 - SV-215061r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020360
Vuln IDs
  • V-215061
  • V-75691
Rule IDs
  • SV-215061r610931_rule
  • SV-90371
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-000064-GPOS-0003, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215
Checks: C-16260r285051_chk

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 path=/bin/su -F perm=x -F auid&gt;=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: F-16258r285052_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 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

b
Successful/unsuccessful uses of the chfn command must generate an audit record.
AU-12 - Medium - CCI-000172 - V-215062 - SV-215062r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020370
Vuln IDs
  • V-215062
  • V-75693
Rule IDs
  • SV-215062r610931_rule
  • SV-90373
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: C-16261r285054_chk

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 path=/usr/bin/chfn -F perm=x -F auid&gt;=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: F-16259r285055_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 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

a
Successful/unsuccessful uses of the mount command must generate an audit record.
AU-3 - Low - CCI-000130 - V-215063 - SV-215063r610931_rule
RMF Control
AU-3
Severity
Low
CCI
CCI-000130
Version
UBTU-16-020380
Vuln IDs
  • V-215063
  • V-75695
Rule IDs
  • SV-215063r610931_rule
  • SV-90375
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: C-16262r285057_chk

Verify the operating system generates audit records when successful/unsuccessful attempts to use the "mount" command and syscall occur. Check that the following system call is being audited by performing the following series of commands to check the file system rules in "/etc/audit/audit.rules": # grep -iw "mount" /etc/audit/audit.rules -a always,exit -F arch=b32 -S mount -F auid&gt;=1000 -F auid!=4294967295 -k privileged-mount -a always,exit -F arch=b64 -S mount -F auid&gt;=1000 -F auid!=4294967295 -k privileged-mount -a always,exit -F path=/bin/mount -F auid&gt;=1000 -F auid!=4294967295 -k privileged-mount If both the "b32" and "b64" audit rules are not defined for the "mount" syscall, this is a finding. If all uses of the "mount" command are not being audited, this is a finding.

Fix: F-16260r285058_fix

Configure the operating system to generate audit records when successful/unsuccessful attempts to use the "mount" command and syscall occur. Add or update the following rules in "/etc/audit/rules.d/audit.rules": -a always,exit -F arch=b32 -S mount -F auid>=1000 -F auid!=4294967295 -k privileged-mount -a always,exit -F arch=b64 -S mount -F auid>=1000 -F auid!=4294967295 -k privileged-mount -a always,exit -F path=/bin/mount -F auid>=1000 -F auid!=4294967295 -k privileged-mount The audit daemon must be restarted for the changes to take effect: # sudo systemctl restart auditd.service

b
Successful/unsuccessful uses of the umount command must generate an audit record.
AU-12 - Medium - CCI-000172 - V-215064 - SV-215064r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020390
Vuln IDs
  • V-215064
  • V-75697
Rule IDs
  • SV-215064r610931_rule
  • SV-90377
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-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000471-GPOS-00215
Checks: C-16263r285060_chk

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 path=/bin/umount -F perm=x -F auid&gt;=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: F-16261r285061_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "umount" command. Add or update the following rule in the "/etc/audit/audit.rules" file: -a always,exit -F 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

b
Successful/unsuccessful uses of the ssh-agent command must generate an audit record.
AU-3 - Medium - CCI-000135 - V-215065 - SV-215065r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000135
Version
UBTU-16-020400
Vuln IDs
  • V-215065
  • V-75699
Rule IDs
  • SV-215065r610931_rule
  • SV-90379
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: C-16264r285063_chk

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 path=/usr/bin/ssh-agent -F perm=x -F auid&gt;=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: F-16262r285064_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 rule in the "/etc/audit/audit.rules" file: -a always,exit -F 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

b
Successful/unsuccessful uses of the ssh-keysign command must generate an audit record.
AU-12 - Medium - CCI-000172 - V-215066 - SV-215066r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020410
Vuln IDs
  • V-215066
  • V-75707
Rule IDs
  • SV-215066r610931_rule
  • SV-90387
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: C-16265r285066_chk

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 path=/usr/lib/openssh/ssh-keysign -F perm=x -F auid&gt;=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: F-16263r285067_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 rule in the "/etc/audit/audit.rules" file: -a always,exit -F 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

b
The audit system must be configured to audit any usage of the kmod command.
AU-3 - Medium - CCI-000130 - V-215067 - SV-215067r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020450
Vuln IDs
  • V-215067
  • V-75715
Rule IDs
  • SV-215067r610931_rule
  • SV-90395
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: C-16266r285069_chk

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: F-16264r285070_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

b
The audit system must be configured to audit any usage of the setxattr system call.
AU-12 - Medium - CCI-000172 - V-215068 - SV-215068r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020460
Vuln IDs
  • V-215068
  • V-75717
Rule IDs
  • SV-215068r610931_rule
  • SV-90397
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: C-16267r621627_chk

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&gt;=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S setxattr -F auid&gt;=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 all lines, or the lines are commented out, this is a finding.

Fix: F-16265r621628_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

b
The audit system must be configured to audit any usage of the lsetxattr system call.
AU-3 - Medium - CCI-000130 - V-215069 - SV-215069r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020470
Vuln IDs
  • V-215069
  • V-75719
Rule IDs
  • SV-215069r610931_rule
  • SV-90399
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-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219
Checks: C-16268r285075_chk

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=b32 -S lsetxattr -F auid&gt;=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S lsetxattr -F auid&gt;=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 all lines, or the lines are commented out, this is a finding.

Fix: F-16266r285076_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=b32 -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

b
The audit system must be configured to audit any usage of the fsetxattr system call.
AU-12 - Medium - CCI-000172 - V-215070 - SV-215070r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020480
Vuln IDs
  • V-215070
  • V-75721
Rule IDs
  • SV-215070r610931_rule
  • SV-90401
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-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219
Checks: C-16269r285078_chk

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=b32 -S fsetxattr -F auid&gt;=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S fsetxattr -F auid&gt;=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 If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-16267r285079_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=b32 -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

b
The audit system must be configured to audit any usage of the removexattr system call.
AU-3 - Medium - CCI-000130 - V-215071 - SV-215071r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020490
Vuln IDs
  • V-215071
  • V-75723
Rule IDs
  • SV-215071r610931_rule
  • SV-90403
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-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219
Checks: C-16270r285081_chk

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=b32 -S removexattr -F auid&gt;=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S removexattr -F auid&gt;=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 If the command does not return all lines, or the lines are commented out, this is a finding.

Fix: F-16268r285082_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=b32 -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

b
The audit system must be configured to audit any usage of the lremovexattr system call.
AU-12 - Medium - CCI-000172 - V-215072 - SV-215072r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020500
Vuln IDs
  • V-215072
  • V-75725
Rule IDs
  • SV-215072r610931_rule
  • SV-90405
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-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219
Checks: C-16271r285084_chk

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=b32 -S lremovexattr -F auid&gt;=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S lremovexattr -F auid&gt;=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 all lines, or the lines are commented out, this is a finding.

Fix: F-16269r285085_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=b32 -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

b
The audit system must be configured to audit any usage of the fremovexattr system call.
AU-3 - Medium - CCI-000130 - V-215073 - SV-215073r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020510
Vuln IDs
  • V-215073
  • V-75727
Rule IDs
  • SV-215073r610931_rule
  • SV-90407
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-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219
Checks: C-16272r285087_chk

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=b32 -S fremovexattr -F auid&gt;=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S fremovexattr -F auid&gt;=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 all lines, or the lines are commented out, this is a finding.

Fix: F-16270r285088_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=b32 -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

b
Successful/unsuccessful uses of the chown command must generate an audit record.
AU-12 - Medium - CCI-000172 - V-215074 - SV-215074r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020520
Vuln IDs
  • V-215074
  • V-75729
Rule IDs
  • SV-215074r610931_rule
  • SV-90409
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: C-16273r285090_chk

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&gt;=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S chown -F auid&gt;=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: F-16271r285091_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

b
Successful/unsuccessful uses of the fchown command must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215075 - SV-215075r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020530
Vuln IDs
  • V-215075
  • V-75731
Rule IDs
  • SV-215075r610931_rule
  • SV-90411
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: C-16274r285093_chk

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=b32 -S fchown -F auid&gt;=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S fchown -F auid&gt;=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: F-16272r285094_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=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod -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

b
Successful/unsuccessful uses of the fchownat command must generate an audit record.
AU-12 - Medium - CCI-000172 - V-215076 - SV-215076r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020540
Vuln IDs
  • V-215076
  • V-75733
Rule IDs
  • SV-215076r610931_rule
  • SV-90413
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: C-16275r285096_chk

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&gt;=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S fchownat -F auid&gt;=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: F-16273r285097_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

b
Successful/unsuccessful uses of the lchown command must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215077 - SV-215077r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020550
Vuln IDs
  • V-215077
  • V-75735
Rule IDs
  • SV-215077r610931_rule
  • SV-90415
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: C-16276r285099_chk

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&gt;=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S lchown -F auid&gt;=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: F-16274r285100_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

b
Successful/unsuccessful uses of the chmod command must generate an audit record.
AU-12 - Medium - CCI-000172 - V-215078 - SV-215078r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020560
Vuln IDs
  • V-215078
  • V-75737
Rule IDs
  • SV-215078r610931_rule
  • SV-90417
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: C-16277r621630_chk

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=b32 -S chmod -F auid&gt;=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S chmod -F auid&gt;=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: F-16275r621631_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=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_chng -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

b
Successful/unsuccessful uses of the fchmod command must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215079 - SV-215079r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020570
Vuln IDs
  • V-215079
  • V-75739
Rule IDs
  • SV-215079r610931_rule
  • SV-90419
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: C-16278r621633_chk

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=b32 -S fchmod -F auid&gt;=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S fchmod -F auid&gt;=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: F-16276r621634_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=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_chng -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

b
Successful/unsuccessful uses of the fchmodat command must generate an audit record.
AU-12 - Medium - CCI-000169 - V-215080 - SV-215080r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
UBTU-16-020580
Vuln IDs
  • V-215080
  • V-75741
Rule IDs
  • SV-215080r610931_rule
  • SV-90421
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: C-16279r285108_chk

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&gt;=1000 -F auid!=4294967295 -k perm_chng -a always,exit -F arch=b64 -S fchmodat -F auid&gt;=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: F-16277r285109_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

b
Successful/unsuccessful uses of the open command must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215081 - SV-215081r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020590
Vuln IDs
  • V-215081
  • V-75743
Rule IDs
  • SV-215081r610931_rule
  • SV-90423
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: C-16280r285111_chk

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=b32 -S open -F exit=-EPERM -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid&gt;=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: F-16278r285112_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=b32 -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

b
Successful/unsuccessful uses of the truncate command must generate an audit record.
AU-12 - Medium - CCI-000172 - V-215082 - SV-215082r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020600
Vuln IDs
  • V-215082
  • V-75745
Rule IDs
  • SV-215082r610931_rule
  • SV-90425
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: C-16281r285114_chk

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=b32 -S truncate -F exit=-EPERM -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid&gt;=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: F-16279r285115_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=b32 -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

b
Successful/unsuccessful uses of the ftruncate command must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215083 - SV-215083r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020610
Vuln IDs
  • V-215083
  • V-75747
Rule IDs
  • SV-215083r610931_rule
  • SV-90427
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: C-16282r285117_chk

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=b32 -S ftruncate -F exit=-EPERM -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid&gt;=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: F-16280r285118_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=b32 -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

b
Successful/unsuccessful uses of the creat command must generate an audit record.
AU-12 - Medium - CCI-000172 - V-215084 - SV-215084r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020620
Vuln IDs
  • V-215084
  • V-75749
Rule IDs
  • SV-215084r610931_rule
  • SV-90429
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: C-16283r285120_chk

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=b32 -S creat -F exit=-EPERM -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid&gt;=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: F-16281r285121_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=b32 -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

b
Successful/unsuccessful uses of the openat command must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215085 - SV-215085r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020630
Vuln IDs
  • V-215085
  • V-75751
Rule IDs
  • SV-215085r610931_rule
  • SV-90431
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: C-16284r285123_chk

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=b32 -S openat -F exit=-EPERM -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid&gt;=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: F-16282r285124_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=b32 -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

b
Successful/unsuccessful uses of the open_by_handle_at command must generate an audit record.
AU-12 - Medium - CCI-000172 - V-215086 - SV-215086r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020640
Vuln IDs
  • V-215086
  • V-75753
Rule IDs
  • SV-215086r610931_rule
  • SV-90433
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: C-16285r285126_chk

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=b32 -S open_by_handle_at -F exit=-EPERM -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EPERM -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b32 -S open_by_handle_at -F exit=-EACCES -F auid&gt;=1000 -F auid!=4294967295 -k perm_access -a always,exit -F arch=b64 -S open_by_handle_at -F exit=-EACCES -F auid&gt;=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: F-16283r285127_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=b32 -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

b
Successful/unsuccessful uses of the sudo command must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215087 - SV-215087r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020650
Vuln IDs
  • V-215087
  • V-75755
Rule IDs
  • SV-215087r610931_rule
  • SV-90435
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: C-16286r285129_chk

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 path=/usr/bin/sudo -F perm=x -F auid&gt;=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: F-16284r285130_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "sudo" command. Add or update the following rule in the "/etc/audit/audit.rules" file: -a always,exit -F 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

b
Successful/unsuccessful uses of the chsh command must generate an audit record.
AU-12 - Medium - CCI-000172 - V-215089 - SV-215089r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020670
Vuln IDs
  • V-215089
  • V-75759
Rule IDs
  • SV-215089r610931_rule
  • SV-90439
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: C-16288r285135_chk

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 path=/usr/bin/chsh -F perm=x -F auid&gt;=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: F-16286r285136_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chsh" command. Add or update the following rule in the "/etc/audit/audit.rules" file: -a always,exit -F 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

b
Successful/unsuccessful uses of the newgrp command must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215090 - SV-215090r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020680
Vuln IDs
  • V-215090
  • V-75761
Rule IDs
  • SV-215090r610931_rule
  • SV-90441
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: C-16289r285138_chk

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 path=/usr/bin/newgrp -F perm=x -F auid&gt;=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: F-16287r285139_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "newgrp" command. Add or update the following rule in the "/etc/audit/audit.rules" file: -a always,exit -F 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

b
Successful/unsuccessful uses of the chcon command must generate an audit record.
AU-12 - Medium - CCI-000172 - V-215091 - SV-215091r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020690
Vuln IDs
  • V-215091
  • V-80969
Rule IDs
  • SV-215091r610931_rule
  • SV-95681
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: C-16290r285141_chk

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 path=/usr/bin/chcon -F perm=x -F auid&gt;=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: F-16288r285142_fix

Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chcon" command. Add or update the following rule in the "/etc/audit/audit.rules" file: -a always,exit -F 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

b
Successful/unsuccessful uses of the apparmor_parser command must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215092 - SV-215092r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020700
Vuln IDs
  • V-215092
  • V-75765
Rule IDs
  • SV-215092r610931_rule
  • SV-90445
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: C-16291r285144_chk

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 path=/sbin/apparmor_parser -F perm=x -F auid&gt;=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: F-16289r621636_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 rule in the "/etc/audit/audit.rules" file: -a always,exit -F 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

b
Successful/unsuccessful uses of the setfacl command must generate an audit record.
AU-12 - Medium - CCI-000172 - V-215093 - SV-215093r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020710
Vuln IDs
  • V-215093
  • V-75767
Rule IDs
  • SV-215093r610931_rule
  • SV-90447
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: C-16292r285147_chk

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 path=/bin/setfacl -F perm=x -F auid&gt;=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: F-16290r285148_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 path=/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

b
Successful/unsuccessful uses of the chacl command must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215094 - SV-215094r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020720
Vuln IDs
  • V-215094
  • V-75769
Rule IDs
  • SV-215094r610931_rule
  • SV-90449
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: C-16293r285150_chk

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 path=/bin/chacl -F perm=x -F auid&gt;=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: F-16291r285151_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 path=/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

b
Successful/unsuccessful modifications to the tallylog file must generate an audit record.
AU-12 - Medium - CCI-000172 - V-215095 - SV-215095r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020730
Vuln IDs
  • V-215095
  • V-75771
Rule IDs
  • SV-215095r610931_rule
  • SV-90451
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: C-16294r285153_chk

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: F-16292r285154_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

b
Successful/unsuccessful modifications to the faillog file must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215096 - SV-215096r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020740
Vuln IDs
  • V-215096
  • V-75773
Rule IDs
  • SV-215096r610931_rule
  • SV-90453
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: C-16295r285156_chk

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: F-16293r285157_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

b
Successful/unsuccessful modifications to the lastlog file must generate an audit record.
AU-12 - Medium - CCI-000172 - V-215097 - SV-215097r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020750
Vuln IDs
  • V-215097
  • V-75775
Rule IDs
  • SV-215097r610931_rule
  • SV-90455
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: C-16296r285159_chk

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: F-16294r285160_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

b
Successful/unsuccessful uses of the passwd command must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215098 - SV-215098r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020760
Vuln IDs
  • V-215098
  • V-75777
Rule IDs
  • SV-215098r610931_rule
  • SV-90457
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: C-16297r285162_chk

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 path=/usr/bin/passwd -F perm=x -F auid&gt;=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: F-16295r285163_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 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

b
Successful/unsuccessful uses of the unix_update command must generate an audit record.
AU-12 - Medium - CCI-000169 - V-215099 - SV-215099r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
UBTU-16-020770
Vuln IDs
  • V-215099
  • V-75779
Rule IDs
  • SV-215099r610931_rule
  • SV-90459
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: C-16298r285165_chk

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&gt;=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: F-16296r285166_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

b
Successful/unsuccessful uses of the gpasswd command must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215100 - SV-215100r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020780
Vuln IDs
  • V-215100
  • V-75781
Rule IDs
  • SV-215100r610931_rule
  • SV-90461
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: C-16299r285168_chk

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 path=/usr/bin/gpasswd -F perm=x -F auid&gt;=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: F-16297r285169_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "gpasswd" command. Add or update the following rule in the "/etc/audit/audit.rules" file: -a always,exit -F 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

b
Successful/unsuccessful uses of the chage command must generate an audit record.
AU-12 - Medium - CCI-000169 - V-215101 - SV-215101r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
UBTU-16-020790
Vuln IDs
  • V-215101
  • V-75783
Rule IDs
  • SV-215101r610931_rule
  • SV-90463
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: C-16300r285171_chk

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 path=/usr/bin/chage -F perm=x -F auid&gt;=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: F-16298r285172_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 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

b
Successful/unsuccessful uses of the usermod command must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215102 - SV-215102r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020800
Vuln IDs
  • V-215102
  • V-75785
Rule IDs
  • SV-215102r610931_rule
  • SV-90465
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: C-16301r285174_chk

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 path=/usr/sbin/usermod -F perm=x -F auid&gt;=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: F-16299r285175_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "usermod" command. Add or update the following rule in the "/etc/audit/audit.rules" file: -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

b
Successful/unsuccessful uses of the crontab command must generate an audit record.
AU-12 - Medium - CCI-000172 - V-215103 - SV-215103r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020810
Vuln IDs
  • V-215103
  • V-75787
Rule IDs
  • SV-215103r610931_rule
  • SV-90467
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: C-16302r285177_chk

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 path=/usr/bin/crontab -F perm=x -F auid&gt;=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: F-16300r285178_fix

Configure the audit system to generate an audit event for any successful/unsuccessful uses of the "crontab" command. Add or update the following rule in the "/etc/audit/audit.rules" file: -a always,exit -F 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

b
Successful/unsuccessful uses of the pam_timestamp_check command must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215104 - SV-215104r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020820
Vuln IDs
  • V-215104
  • V-75789
Rule IDs
  • SV-215104r610931_rule
  • SV-90469
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: C-16303r285180_chk

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 path=/usr/sbin/pam_timestamp_check -F perm=x -F auid&gt;=1000 -F auid!=4294967295 -k privileged-pam_timestamp_check If the command does not return a line, or the line is commented out, this is a finding.

Fix: F-16301r285181_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 rule in the "/etc/audit/audit.rules" file: -a always,exit -F path=/usr/sbin/pam_timestamp_check -F perm=x -F auid>=1000 -F auid!=4294967295 -k privileged-pam_timestamp_check 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

b
Successful/unsuccessful uses of the init_module command must generate an audit record.
AU-12 - Medium - CCI-000169 - V-215105 - SV-215105r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000169
Version
UBTU-16-020830
Vuln IDs
  • V-215105
  • V-75791
Rule IDs
  • SV-215105r610931_rule
  • SV-90471
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: C-16304r285183_chk

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&gt;=1000 -F auid!=4294967295 -k module_chng -a always,exit -F arch=b64 -S init_module -F auid&gt;=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: F-16302r285184_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

b
Successful/unsuccessful uses of the finit_module command must generate an audit record.
AU-3 - Medium - CCI-000130 - V-215106 - SV-215106r610931_rule
RMF Control
AU-3
Severity
Medium
CCI
CCI-000130
Version
UBTU-16-020840
Vuln IDs
  • V-215106
  • V-75793
Rule IDs
  • SV-215106r610931_rule
  • SV-90473
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: C-16305r285186_chk

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&gt;=1000 -F auid!=4294967295 -k module_chng -a always,exit -F arch=b64 -S finit_module -F auid&gt;=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: F-16303r285187_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

b
Successful/unsuccessful uses of the delete_module command must generate an audit record.
AU-12 - Medium - CCI-000172 - V-215107 - SV-215107r610931_rule
RMF Control
AU-12
Severity
Medium
CCI
CCI-000172
Version
UBTU-16-020850
Vuln IDs
  • V-215107
  • V-75795
Rule IDs
  • SV-215107r610931_rule
  • SV-90475
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: C-16306r285189_chk

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&gt;=1000 -F auid!=4294967295 -k module_chng -a always,exit -F arch=b64 -S delete_module -F auid&gt;=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: F-16304r285190_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

c
The telnetd package must not be installed.
IA-5 - High - CCI-000197 - V-215108 - SV-215108r610931_rule
RMF Control
IA-5
Severity
High
CCI
CCI-000197
Version
UBTU-16-030000
Vuln IDs
  • V-215108
  • V-75797
Rule IDs
  • SV-215108r610931_rule
  • SV-90477
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: C-16307r285192_chk

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: F-16305r285193_fix

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

c
The Network Information Service (NIS) package must not be installed.
CM-7 - High - CCI-000381 - V-215109 - SV-215109r610931_rule
RMF Control
CM-7
Severity
High
CCI
CCI-000381
Version
UBTU-16-030010
Vuln IDs
  • V-215109
  • V-75799
Rule IDs
  • SV-215109r610931_rule
  • SV-90479
Removing the Network Information Service (NIS) package decreases the risk of the accidental (or intentional) activation of NIS or NIS+ services.
Checks: C-16308r285195_chk

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: F-16306r285196_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

c
The rsh-server package must not be installed.
CM-7 - High - CCI-000381 - V-215110 - SV-215110r610931_rule
RMF Control
CM-7
Severity
High
CCI
CCI-000381
Version
UBTU-16-030020
Vuln IDs
  • V-215110
  • V-75801
Rule IDs
  • SV-215110r610931_rule
  • SV-90481
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: C-16309r285198_chk

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: F-16307r285199_fix

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

b
An application firewall must be installed.
AC-17 - Medium - CCI-002314 - V-215111 - SV-215111r610931_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-002314
Version
UBTU-16-030030
Vuln IDs
  • V-215111
  • V-75803
Rule IDs
  • SV-215111r610931_rule
  • SV-90483
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: C-16310r285201_chk

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: F-16308r285202_fix

Install Uncomplicated Firewall with the following command: # sudo apt-get install ufw

b
An application firewall must be enabled on the system.
CM-6 - Medium - CCI-000366 - V-215112 - SV-215112r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-030040
Vuln IDs
  • V-215112
  • V-75805
Rule IDs
  • SV-215112r610931_rule
  • SV-90485
Firewalls protect computers from network attacks by blocking or limiting access to open network ports. Application firewalls limit which applications are allowed to communicate over the network.
Checks: C-16311r285204_chk

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: F-16309r285205_fix

Enable the Uncomplicated Firewall by using the following commands: # sudo systemctl start ufw # sudo systemctl enable ufw

b
An application firewall must employ a deny-all, allow-by-exception policy for allowing connections to other systems.
CM-6 - Medium - CCI-000366 - V-215113 - SV-215113r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-030050
Vuln IDs
  • V-215113
  • V-75807
Rule IDs
  • SV-215113r610931_rule
  • SV-90487
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: C-16312r285207_chk

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: F-16310r285208_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.

b
The Ubuntu operating system must be configured to prohibit or restrict the use of functions, ports, protocols, and/or services, as defined in the Ports, Protocols, and Services Management (PPSM) Category Assignments List (CAL) and vulnerability assessments.
CM-7 - Medium - CCI-000382 - V-215114 - SV-215114r610931_rule
RMF Control
CM-7
Severity
Medium
CCI
CCI-000382
Version
UBTU-16-030060
Vuln IDs
  • V-215114
  • V-75809
Rule IDs
  • SV-215114r610931_rule
  • SV-90489
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: C-16313r466234_chk

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: F-16311r466235_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).

b
A sticky bit must be set on all public directories to prevent unauthorized and unintended information transferred via shared system resources.
SC-4 - Medium - CCI-001090 - V-215115 - SV-215115r610931_rule
RMF Control
SC-4
Severity
Medium
CCI
CCI-001090
Version
UBTU-16-030070
Vuln IDs
  • V-215115
  • V-75811
Rule IDs
  • SV-215115r610931_rule
  • SV-90491
Preventing unauthorized information transfers mitigates the risk of information, including encrypted representations of information, produced by the actions of prior users/roles (or the actions of processes acting on behalf of prior users/roles) from being available to any current users/roles (or current processes) that obtain access to shared system resources (e.g., registers, main memory, hard disks) after those resources have been released back to information systems. The control of information in shared resources is also commonly referred to as object reuse and residual information protection. This requirement generally applies to the design of an information technology product, but it can also apply to the configuration of particular information system components that are, or use, such products. This can be verified by acceptance/validation processes in DoD or other government agencies. There may be shared resources with configurable protections (e.g., files in storage) that may be assessed on specific information system components.
Checks: C-16314r285213_chk

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&gt;/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: F-16312r285214_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]

b
The Ubuntu operating system must compare internal information system clocks at least every 24 hours with a server which is synchronized to an authoritative time source, such as the United States Naval Observatory (USNO) time servers, or a time server designated for the appropriate DoD network (NIPRNet/SIPRNet), and/or the Global Positioning System (GPS).
AU-8 - Medium - CCI-001891 - V-215116 - SV-215116r610931_rule
RMF Control
AU-8
Severity
Medium
CCI
CCI-001891
Version
UBTU-16-030100
Vuln IDs
  • V-215116
  • V-75813
Rule IDs
  • SV-215116r610931_rule
  • SV-90493
Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Sources outside the configured acceptable allowance (drift) may be inaccurate. Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network. Organizations should consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints).
Checks: C-16315r466240_chk

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. The value of [source] should be an authoritative DoD time source. Verify that "Chrony" is active and enabled by running the following command: # sudo systemctl status chrony.service chrony.service - LSB: Controls chronyd NTP time daemon Loaded: loaded (/etc/init.d/chrony; bad; vendor preset: enabled) Active: active (running) since Wed 2020-01-08 14:01:47 EST; 50min ago Docs: man:systemd-sysv-generator(8) If "chrony.service" is not "loaded", this is a finding. If "chrony.service" is not "active (running)", this is a finding. Verify that the "chrony.conf" file is configured to an authoritative DoD time source by running the following command: # grep -i ^server /etc/chrony/chrony.conf server [source] iburst maxpoll 17 If the parameter "server" is not set, is not set to an authoritative DoD time source, or is commented out, this is a finding. Check the value of "maxpoll" in the "/etc/chrony/chrony.conf" file with the following command: # sudo grep -i maxpoll /etc/chrony/chrony.conf server [source] iburst maxpoll 17 If "maxpoll" is not set to "17" or does not exist, this is a finding.

Fix: F-16313r466241_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/chrony/chrony.conf" file. Add or correct the following lines, by replacing "[source]" in the following line with an authoritative DoD time source: server [source] iburst maxpoll 17 If the "chrony" 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 chrony.service If the "chrony" service was not running then it must be started: # sudo systemctl start chrony.service

b
The Ubuntu operating system must synchronize internal information system clocks to the authoritative time source when the time difference is greater than one second.
AU-8 - Medium - CCI-002046 - V-215117 - SV-215117r610931_rule
RMF Control
AU-8
Severity
Medium
CCI
CCI-002046
Version
UBTU-16-030110
Vuln IDs
  • V-215117
  • V-75815
Rule IDs
  • SV-215117r610931_rule
  • SV-90495
Inaccurate time stamps make it more difficult to correlate events and can lead to an inaccurate analysis. Determining the correct time a particular event occurred on a system is critical when conducting forensic analysis and investigating system events. Synchronizing internal information system clocks provides uniformity of time stamps for information systems with multiple system clocks and systems connected over a network. Organizations should consider setting time periods for different types of systems (e.g., financial, legal, or mission-critical systems). Organizations should also consider endpoints that may not have regular access to the authoritative time server (e.g., mobile, teleworking, and tactical endpoints). This requirement is related to the comparison done every 24 hours in SRG-OS-000355 because a comparison must be done in order to determine the time difference.
Checks: C-16316r285219_chk

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: F-16314r285220_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.

b
The Ubuntu operating system must record time stamps for audit records that can be mapped to Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT).
AU-8 - Medium - CCI-001890 - V-215118 - SV-215118r610931_rule
RMF Control
AU-8
Severity
Medium
CCI
CCI-001890
Version
UBTU-16-030120
Vuln IDs
  • V-215118
  • V-75817
Rule IDs
  • SV-215118r610931_rule
  • SV-90497
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: C-16317r285222_chk

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: F-16315r285223_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]

b
The Ubuntu operating system must implement non-executable data to protect its memory from unauthorized code execution.
SI-16 - Medium - CCI-002824 - V-215119 - SV-215119r610931_rule
RMF Control
SI-16
Severity
Medium
CCI
CCI-002824
Version
UBTU-16-030130
Vuln IDs
  • V-215119
  • V-75819
Rule IDs
  • SV-215119r610931_rule
  • SV-90499
Some adversaries launch attacks with the intent of executing code in non-executable regions of memory or in memory locations that are prohibited. Security safeguards employed to protect memory include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can either be hardware-enforced or software-enforced with hardware providing the greater strength of mechanism. Examples of attacks are buffer overflow attacks.
Checks: C-16318r285225_chk

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: F-16316r285226_fix

The NX bit execute protection must be enabled in the system BIOS.

b
The Ubuntu operating system must implement address space layout randomization to protect its memory from unauthorized code execution.
SI-16 - Medium - CCI-002824 - V-215120 - SV-215120r610931_rule
RMF Control
SI-16
Severity
Medium
CCI
CCI-002824
Version
UBTU-16-030140
Vuln IDs
  • V-215120
  • V-75821
Rule IDs
  • SV-215120r610931_rule
  • SV-90501
Some adversaries launch attacks with the intent of executing code in non-executable regions of memory or in memory locations that are prohibited. Security safeguards employed to protect memory include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can either be hardware-enforced or software-enforced with hardware providing the greater strength of mechanism. Examples of attacks are buffer overflow attacks.
Checks: C-16319r285228_chk

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: F-16317r285229_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

c
The Ubuntu operating system must enforce SSHv2 for network access to all accounts.
IA-2 - High - CCI-001941 - V-215121 - SV-215121r610931_rule
RMF Control
IA-2
Severity
High
CCI
CCI-001941
Version
UBTU-16-030200
Vuln IDs
  • V-215121
  • V-75823
Rule IDs
  • SV-215121r610931_rule
  • SV-90503
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: C-16320r285231_chk

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: F-16318r285232_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

b
The Ubuntu operating system must display the Standard Mandatory DoD Notice and Consent Banner before granting local or remote access to the system via a ssh logon and the user must acknowledge the usage conditions and take explicit actions to log on for further access.
AC-8 - Medium - CCI-000048 - V-215122 - SV-215122r610931_rule
RMF Control
AC-8
Severity
Medium
CCI
CCI-000048
Version
UBTU-16-030210
Vuln IDs
  • V-215122
  • V-75825
Rule IDs
  • SV-215122r610931_rule
  • SV-90505
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: "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."
Checks: C-16321r466231_chk

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 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: F-16319r466232_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 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

b
The Ubuntu operating system must not permit direct logons to the root account using remote access via SSH.
CM-6 - Medium - CCI-000366 - V-215123 - SV-215123r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-030220
Vuln IDs
  • V-215123
  • V-75827
Rule IDs
  • SV-215123r610931_rule
  • SV-90507
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: C-16322r285237_chk

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: F-16320r285238_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

b
The Ubuntu operating system must implement DoD-approved encryption to protect the confidentiality of SSH connections.
AC-17 - Medium - CCI-000068 - V-215124 - SV-215124r610931_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-000068
Version
UBTU-16-030230
Vuln IDs
  • V-215124
  • V-75829
Rule IDs
  • SV-215124r610931_rule
  • SV-90509
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. By specifying a cipher list with the order of ciphers being in a “strongest to weakest” orientation, the system will automatically attempt to use the strongest cipher for securing SSH connections.
Checks: C-16323r621638_chk

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 aes256-ctr,aes192-ctr,aes128-ctr If any ciphers other than "aes256-ctr", "aes192-ctr", or "aes128-ctr" are listed, the order differs from the example above, the "Ciphers" keyword is missing, or the returned line is commented out, this is a finding.

Fix: F-16321r621639_fix

Configure the Ubuntu operating system to allow the SSH daemon to only implement DoD-approved encryption. Add the following line (or modify the line to have the required value) to the "/etc/ssh/sshd_config" file (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor): Ciphers aes256-ctr,aes192-ctr,aes128-ctr 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

b
The SSH daemon must be configured to only use Message Authentication Codes (MACs) employing FIPS 140-2 approved cryptographic hash algorithms.
AC-17 - Medium - CCI-001453 - V-215125 - SV-215125r610931_rule
RMF Control
AC-17
Severity
Medium
CCI
CCI-001453
Version
UBTU-16-030240
Vuln IDs
  • V-215125
  • V-75831
Rule IDs
  • SV-215125r610931_rule
  • SV-90511
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: C-16324r621641_chk

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-512,hmac-sha2-256 If any ciphers other than "hmac-sha2-512" or "hmac-sha2-256" are listed, the order differs from the example above, or the returned line is commented out, this is a finding.

Fix: F-16322r621642_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. Add the following line (or modify the line to have the required value) to the "/etc/ssh/sshd_config" file (this file may be named differently or be in a different location if using a version of SSH that is provided by a third-party vendor): MACs hmac-sha2-512,hmac-sha2-256 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

c
The Ubuntu operating system must be configured so that the SSH daemon does not allow authentication using an empty password.
CM-6 - High - CCI-000366 - V-215126 - SV-215126r610931_rule
RMF Control
CM-6
Severity
High
CCI
CCI-000366
Version
UBTU-16-030250
Vuln IDs
  • V-215126
  • V-75833
Rule IDs
  • SV-215126r610931_rule
  • SV-90513
Failure to restrict system access to authenticated users negatively impacts Ubuntu operating system security.
Checks: C-16325r285246_chk

To determine how the SSH daemon's "PermitEmptyPasswords" option is set, run the following command: # grep -i PermitEmptyPasswords /etc/ssh/sshd_config PermitEmptyPasswords no If no line is returned, the line is commented out, or the value is set to "yes", this is a finding.

Fix: F-16323r285247_fix

To explicitly disallow remote logon from accounts with empty passwords, add or correct the following line in "/etc/ssh/sshd_config": PermitEmptyPasswords no Note: Any accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords. 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

b
The Ubuntu operating system must not allow users to override SSH environment variables.
CM-6 - Medium - CCI-000366 - V-215127 - SV-215127r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-030251
Vuln IDs
  • V-215127
  • V-98989
Rule IDs
  • SV-215127r610931_rule
  • SV-108093
Failure to restrict system access to authenticated users negatively impacts Ubuntu operating system security.
Checks: C-16326r285249_chk

Verify the operating system does not allow users to override environment variables to the SSH daemon. Check for the value of the "PermitUserEnvironment" keyword with the following command: # grep -i permituserenvironment /etc/ssh/sshd_config PermitUserEnvironment no If the "PermitUserEnvironment" keyword is not set to "no", is missing, or is commented out, this is a finding.

Fix: F-16324r285250_fix

Configure the operating system to not allow users to override environment variables to the SSH daemon. Edit the "/etc/ssh/sshd_config" file to uncomment or add the line for "PermitUserEnvironment" keyword and set the value to "no": PermitUserEnvironment no The SSH service must be restarted for changes to take effect: # sudo systemctl restart sshd.service

b
The system must display the date and time of the last successful account logon upon an SSH logon.
CM-6 - Medium - CCI-000366 - V-215128 - SV-215128r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-030260
Vuln IDs
  • V-215128
  • V-75835
Rule IDs
  • SV-215128r610931_rule
  • SV-90515
Providing users with feedback on when account accesses via SSH last occurred facilitates user recognition and reporting of unauthorized account use.
Checks: C-16327r285252_chk

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: F-16325r285253_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

b
The Ubuntu operating system must be configured so that all network connections associated with SSH traffic are terminated at the end of the session or after 10 minutes of inactivity, except to fulfill documented and validated mission requirements.
AC-12 - Medium - CCI-002361 - V-215129 - SV-215129r610931_rule
RMF Control
AC-12
Severity
Medium
CCI
CCI-002361
Version
UBTU-16-030270
Vuln IDs
  • V-215129
  • V-75837
Rule IDs
  • SV-215129r610931_rule
  • SV-90517
Automatic session termination addresses the termination of user-initiated logical sessions in contrast to the termination of network connections that are associated with communications sessions (i.e., network disconnect). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational information system. Such user sessions can be terminated (and thus terminate user access) without terminating network sessions. Session termination terminates all processes associated with a user's logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use. This capability is typically reserved for specific Ubuntu operating system functionality where the system owner, data owner, or organization requires additional assurance.
Checks: C-16328r285255_chk

Verify that all network connections associated with SSH traffic are automatically terminated at the end of the session or after "10" minutes of inactivity. 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 If "ClientAliveInterval" has 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: F-16326r285256_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: ClientAliveInterval 600 In order for the changes to take effect, the SSH daemon must be restarted. # sudo systemctl restart sshd.service

b
The Ubuntu operating system must be configured so that all network connections associated with SSH traffic terminate after a period of inactivity.
SC-10 - Medium - CCI-001133 - V-215130 - SV-215130r610931_rule
RMF Control
SC-10
Severity
Medium
CCI
CCI-001133
Version
UBTU-16-030271
Vuln IDs
  • V-215130
  • V-90353
Rule IDs
  • SV-215130r610931_rule
  • SV-101003
Automatic session termination addresses the termination of user-initiated logical sessions in contrast to the termination of network connections that are associated with communications sessions (i.e., network disconnect). A logical session (for local, network, and remote access) is initiated whenever a user (or process acting on behalf of a user) accesses an organizational information system. Such user sessions can be terminated (and thus terminate user access) without terminating network sessions. Session termination terminates all processes associated with a user's logical session except those processes that are specifically created by the user (i.e., session owner) to continue after the session is terminated. Conditions or trigger events requiring automatic session termination can include, for example, organization-defined periods of user inactivity, targeted responses to certain types of incidents, and time-of-day restrictions on information system use. This capability is typically reserved for specific Ubuntu operating system functionality where the system owner, data owner, or organization requires additional assurance.
Checks: C-16329r285258_chk

Verify the operating system automatically terminates a user session after inactivity time-outs have expired. Check for the value of the "ClientAliveCountMax" keyword with the following command: # grep -i clientalivecount /etc/ssh/sshd_config ClientAliveCountMax 0 If "ClientAliveCountMax" is not set to "0", or is commented out, this is a finding.

Fix: F-16327r285259_fix

Configure the Ubuntu operating system to automatically terminates a user session after inactivity time-outs have expired. Modify or append the following line in the "/etc/ssh/sshd_config" file replacing "[CountMax] with a value of "0": ClientAliveCountMax 0 In order for the changes to take effect, the SSH daemon must be restarted. # sudo systemctl restart sshd.service

b
The SSH daemon must not allow authentication using known hosts authentication.
CM-6 - Medium - CCI-000366 - V-215131 - SV-215131r610931_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
UBTU-16-030300
Vuln IDs
  • V-215131
  • V-75841
Rule IDs
  • SV-215131r610931_rule
  • SV-90521
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: C-16330r285261_chk

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: F-16328r285262_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

b