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.
Sort by
c
The Ubuntu operating system must be a vendor supported release.
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.
Fix: F-16136r284686_fix
Upgrade to a supported version of the Ubuntu operating system.
b
All users must be able to directly initiate a session lock for all connection types.
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
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
The Ubuntu operating system must enforce password complexity by requiring that at least one upper-case character be used.
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.
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.
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.
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.
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.
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.
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: ~ ! @ # $ % ^ *.
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.
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.
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.
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
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
Passwords for new users must have a 24 hours/1 day minimum password lifetime restriction.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
c
Unattended or automatic login via the Graphical User Interface must not be allowed.
Failure to restrict system access to authenticated users negatively impacts Ubuntu operating system security.
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
c
There must be no .shosts files on the Ubuntu operating system.
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.
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.
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.
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.
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
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.
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.
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.
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.
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
b
A file integrity tool must be installed to verify correct operation of all security functions in the Ubuntu operating system.
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.
Fix: F-16179r284815_fix
Install the AIDE package by running the following command:
# sudo apt-get install aide
c
The x86 Ctrl-Alt-Delete key sequence in the Ubuntu operating system must be disabled if a Graphical User Interface is installed.
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.
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.
Setting the most restrictive default permissions ensures that when new accounts are created they do not have unnecessary access.
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
c
The root account must be the only account having unrestricted access to the system.
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.
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
All local interactive users must have a home directory assigned in the /etc/passwd file.
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.
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
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.
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.
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.
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.
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
Audit records must contain information to establish what type of events occurred, the source of events, where events occurred, and the outcome of events.
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
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.
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.
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
Audit tools must have a mode of 0755 or less permissive.
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
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.
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
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".
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
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 Ubuntu operating system must generate audit records for all account creations, modifications, disabling, and termination events that affect /etc/passwd.
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
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.
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
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.
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
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.
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
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.
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
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.
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
Fix: F-16257r285049_fix
Configure the Ubuntu operating system to audit the execution of the "execve" system call.
Add or update the following file system rules to "/etc/audit/audit.rules":
-a always,exit -F arch=b32 -S execve -C uid!=euid -F key=execpriv
-a always,exit -F arch=b64 -S execve -C uid!=euid -F key=execpriv
-a always,exit -F arch=b32 -S execve -C gid!=egid -F key=execpriv
-a always,exit -F arch=b64 -S execve -C gid!=egid -F key=execpriv
The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:
# sudo systemctl restart auditd.service
a
Successful/unsuccessful uses of the mount command must generate an audit record.
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
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
The audit system must be configured to audit any usage of the setxattr system call.
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
Fix: F-16265r285073_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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
Fix: F-16275r285103_fix
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "chmod" command by adding the following line to "/etc/audit/audit.rules":
-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_chng
The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:
# sudo systemctl restart auditd.service
b
Successful/unsuccessful uses of the fchmod command must generate an audit record.
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
Fix: F-16276r285106_fix
Configure the audit system to generate an audit event for any successful/unsuccessful use of the "fchmod" command by adding the following line to "/etc/audit/audit.rules":
-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_chng
The audit daemon must be restarted for the changes to take effect. To restart the audit daemon, run the following command:
# sudo systemctl restart auditd.service
b
Successful/unsuccessful uses of the fchmodat command must generate an audit record.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
Fix: F-16289r285145_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 arch=b32 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 modifications to the tallylog file must generate an audit record.
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
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.
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
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.
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
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.
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
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 gpasswd command must generate an audit record.
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
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.
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
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 crontab command must generate an audit record.
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
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.
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
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.
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
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.
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
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.
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
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
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
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.
Removing the Network Information Service (NIS) package decreases the risk of the accidental (or intentional) activation of NIS or NIS+ services.
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
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.
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
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).
Fix: F-16308r285202_fix
Install Uncomplicated Firewall with the following command:
# sudo apt-get install ufw
b
The Ubuntu operating system must implement address space layout randomization to protect its memory from unauthorized code execution.
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.
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.
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
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 not permit direct logons to the root account using remote access via SSH.
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.
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.
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.
Fix: F-16321r285241_fix
Configure the Ubuntu operating system to allow the SSH daemon to only implement DoD-approved encryption.
Edit the SSH daemon configuration "/etc/ssh/sshd_config" and remove any ciphers not starting with "aes" and remove any ciphers ending with "cbc". If necessary, append the "Ciphers" line to the "/etc/ssh/sshd_config" document.
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:
# sudo systemctl restart sshd.service
b
The SSH daemon must be configured to only use Message Authentication Codes (MACs) employing FIPS 140-2 approved cryptographic hash algorithms.
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
Fix: F-16322r285244_fix
Configure the Ubuntu operating system to allow the SSH daemon to only use Message Authentication Codes (MACs) that employ FIPS 140-2 approved ciphers.
Edit the "/etc/ssh/sshd_config" file to uncomment or add the line for the "MACs" keyword and set its value to "hmac-sha2-256" and/or "hmac-sha2-512":
MACs hmac-sha2-256,hmac-sha2-512
The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:
# sudo systemctl restart sshd.service
b
The system must display the date and time of the last successful account logon upon an SSH logon.
Providing users with feedback on when account accesses via SSH last occurred facilitates user recognition and reporting of unauthorized account use.
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.
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.
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 SSH daemon must not allow authentication using known hosts authentication.
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.
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
The SSH public host key files must have mode 0644 or less permissive.
If a public host key file is modified by an unauthorized user, the SSH service may be compromised.
Fix: F-16329r285265_fix
Note: SSH public key files may be found in other directories on the system depending on the installation.
Change the mode of public host key files under "/etc/ssh" to "0644" with the following command:
# sudo chmod 0644 /etc/ssh/*key.pub
The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:
# sudo systemctl restart sshd.service
b
The SSH private host key files must have mode 0600 or less permissive.
If an unauthorized user obtains the private SSH host key file, the host could be impersonated.
Fix: F-16330r285268_fix
Configure the mode of SSH private host key files under "/etc/ssh" to "0600" with the following command:
#sudo chmod 0600 /etc/ssh/ssh_host*key
The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:
# sudo systemctl restart sshd.service
b
The SSH daemon must perform strict mode checking of home directory configuration files.
If other users have access to modify user-specific SSH configuration files, they may be able to log on to the system as another user.
Fix: F-16331r285271_fix
Configure SSH to perform strict mode checking of home directory configuration files. Uncomment the "StrictModes" keyword in "/etc/ssh/sshd_config" and set the value to "yes":
StrictModes yes
The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:
# sudo systemctl restart sshd.service
SSH daemon privilege separation causes the SSH process to drop root privileges when not needed, which would decrease the impact of software vulnerabilities in the unprivileged section.
Fix: F-16332r285274_fix
Configure SSH to use privilege separation. Uncomment the "UsePrivilegeSeparation" keyword in "/etc/ssh/sshd_config" and set the value to "yes":
UsePrivilegeSeparation yes
The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:
# sudo systemctl restart sshd.service
b
The SSH daemon must not allow compression or must only allow compression after successful authentication.
If compression is allowed in an SSH connection prior to authentication, vulnerabilities in the compression software could result in compromise of the system from an unauthenticated connection, potentially with root privileges.
Fix: F-16333r285277_fix
Configure SSH to use compression. Uncomment the "Compression" keyword in "/etc/ssh/sshd_config" on the system and set the value to "delayed" or "no":
Compression no
The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:
# sudo systemctl restart sshd.service
c
Remote X connections for interactive users must be encrypted.
Open X displays allow an attacker to capture keystrokes and execute commands remotely.
Fix: F-16334r285280_fix
Configure SSH to encrypt connections for interactive users.
Edit the "/etc/ssh/sshd_config" file to uncomment or add the line for the "X11Forwarding" keyword and set its value to "yes":
X11Forwarding yes
The SSH daemon must be restarted for the changes to take effect. To restart the SSH daemon, run the following command:
# sudo systemctl restart sshd.service
c
All networked systems must have and implement SSH to protect the confidentiality and integrity of transmitted and received information, as well as information during preparation for transmission.
Without protection of the transmitted information, confidentiality and integrity may be compromised because unprotected communications can be intercepted and either read or altered.
This requirement applies to both internal and external networks and all types of information system components from which information can be transmitted (e.g., servers, mobile devices, notebook computers, printers, copiers, scanners, and facsimile machines). Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification.
Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, logical means (cryptography) do not have to be employed, and vice versa.
Satisfies: SRG-OS-000423-GPOS-00187, SRG-OS-000424-GPOS-00188, SRG-OS-000425-GPOS-00189, SRG-OS-000426-GPOS-00190
Fix: F-16336r285286_fix
Install the "ssh" meta-package on the system with the following command:
# sudo apt install ssh
Enable the "ssh" service to start automatically on reboot with the following command:
# sudo systemctl enable sshd.service
b
The audit system must take appropriate action when the network cannot be used to off-load audit records.
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.
Fix: F-16337r285289_fix
Configure the Ubuntu operating system to take appropriate action when the network cannot be used to off-load audit records.
Add, edit or uncomment the "network_failure_action" option in "/etc/audisp/audisp-remote.conf". Set it to "syslog", "single" or "halt" like the below example:
network_failure_action = single
b
The Ubuntu operating system must be configured to use TCP syncookies.
DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.
Managing excess capacity ensures that sufficient capacity is available to counter flooding attacks. Employing increased capacity and service redundancy may reduce the susceptibility to some DoS attacks. Managing excess capacity may include, for example, establishing selected usage priorities, quotas, or partitioning.
Fix: F-16341r285301_fix
Configure the Ubuntu operating system to use TCP syncookies, by running the following command:
# sudo sysctl -w net.ipv4.tcp_syncookies=1
If "1" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":
net.ipv4.tcp_syncookies = 1
b
The Ubuntu operating system must not forward Internet Protocol version 4 (IPv4) source-routed packets.
Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router.
Fix: F-16343r285307_fix
Configure the Ubuntu operating system to not forward Internet Protocol version 4 (IPv4) source-routed packets with the following command:
# sudo sysctl -w net.ipv4.conf.all.accept_source_route=0
If "0" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":
net.ipv4.conf.all.accept_source_route=0
b
The Ubuntu operating system must not forward Internet Protocol version 4 (IPv4) source-routed packets by default.
Source-routed packets allow the source of the packet to suggest that routers forward the packet along a different path than configured on the router, which can be used to bypass network security measures. This requirement applies only to the forwarding of source-routed traffic, such as when IPv4 forwarding is enabled and the system is functioning as a router.
Fix: F-16344r285310_fix
Configure the Ubuntu operating system to not forward Internet Protocol version 4 (IPv4) source-routed packets by default with the following command:
# sudo sysctl -w net.ipv4.conf.default.accept_source_route=0
If "0" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":
net.ipv4.conf.default.accept_source_route=0
b
The Ubuntu operating system must not respond to Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) echoes sent to a broadcast address.
Responding to broadcast Internet Control Message Protocol (ICMP) echoes facilitates network mapping and provides a vector for amplification attacks.
Fix: F-16345r285313_fix
Configure the Ubuntu operating system to not respond to Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) echoes sent to a broadcast address with the following command:
# sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
If "1" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":
net.ipv4.icmp_echo_ignore_broadcasts=1
b
The Ubuntu operating system must prevent Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages from being accepted.
Internet Control Message Protocol (ICMP) redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.
Fix: F-16346r285316_fix
Configure the Ubuntu operating system to prevent Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages from being acceptedr with the following command:
# sudo sysctl -w net.ipv4.conf.default.accept_redirects=0
If "0" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":
net.ipv4.conf.default.accept_redirects=0
b
The Ubuntu operating system must ignore Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages.
Internet Control Message Protocol (ICMP) redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages modify the host's route table and are unauthenticated. An illicit ICMP redirect message could result in a man-in-the-middle attack.
Fix: F-16347r285319_fix
Configure the Ubuntu operating system to ignore Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirect messages with the following command:
# sudo sysctl -w net.ipv4.conf.all.accept_redirects=0
If "0" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":
net.ipv4.conf.all.accept_redirects=0
b
The Ubuntu operating system must not allow interfaces to perform Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirects by default.
Internet Control Message Protocol (ICMP) redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table, possibly revealing portions of the network topology.
Fix: F-16348r285322_fix
Configure the Ubuntu operating system to not allow interfaces to perform Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirects by default with the following command:
# sudo sysctl -w net.ipv4.conf.default.send_redirects=0
If "0" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":
net.ipv4.conf.default.send_redirects=0
b
The Ubuntu operating system must not send Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirects.
Internet Control Message Protocol (ICMP) redirect messages are used by routers to inform hosts that a more direct route exists for a particular destination. These messages contain information from the system's route table, possibly revealing portions of the network topology.
Fix: F-16349r285325_fix
Configure the Ubuntu operating system to not allow interfaces to perform Internet Protocol version 4 (IPv4) Internet Control Message Protocol (ICMP) redirects with the following command:
# sudo sysctl -w net.ipv4.conf.all.send_redirects=0
If "0" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":
net.ipv4.conf.all.send_redirects=0
b
The Ubuntu operating system must not be performing packet forwarding unless the system is a router.
Routing protocol daemons are typically used on routers to exchange network topology information with other routers. If this software is used when not required, system network information may be unnecessarily transmitted across the network.
Fix: F-16350r285328_fix
Configure the Ubuntu operating system to not allow packet forwarding, unless the system is a router with the following command:
# sudo sysctl -w net.ipv4.ip_forward=0
If "0" is not the system's default value then add or update the following line in "/etc/sysctl.conf" or in the appropriate file under "/etc/sysctl.d":
net.ipv4.ip_forward=0
c
A File Transfer Protocol (FTP) server package must not be installed unless needed.
The FTP service provides an unencrypted remote access that does not provide for the confidentiality and integrity of user passwords or the remote session. If a privileged user were to log on using this service, the privileged user password could be compromised. SSH or other encrypted file transfer methods must be used in place of this service.
Fix: F-16354r285340_fix
Document the ftp daemon package with the Information System Security Officer (ISSO) as an operational requirement or remove it from the system with the following command:
# sudo apt-get remove <ftp package>
c
The Trivial File Transfer Protocol (TFTP) server package must not be installed if not required for operational support.
If TFTP is required for operational support (such as the transmission of router configurations) its use must be documented with the Information System Security Officer (ISSO), restricted to only authorized personnel, and have access control rules established.
Fix: F-16355r285343_fix
Remove the Trivial File Transfer Protocol (TFTP) package from the system with the following command:
# sudo apt-get remove *tftpd*
b
The Ubuntu operating system must have the packages required for multifactor authentication to be installed.
Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.
Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD Common Access Card.
A privileged account is defined as an information system account with authorizations of a privileged user.
Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management).
Requires further clarification from NIST.
Satisfies: SRG-OS-000375-GPOS-00160, SRG-OS-000375-GPOS-00161, SRG-OS-000375-GPOS-00162
Fix: F-16358r285352_fix
Configure the Ubuntu operating system to implement multifactor authentication by installing the required packages.
Install the "libpam-pkcs11" package on the system with the following command:
# sudo apt install libpam-pkcs11
b
The Ubuntu operating system must accept Personal Identity Verification (PIV) credentials.
The use of PIV credentials facilitates standardization and reduces the risk of unauthorized access.
DoD has mandated the use of the CAC to support identity management and personal authentication for systems covered under Homeland Security Presidential Directive (HSPD) 12, as well as making the CAC a primary component of layered protection for national security systems.
Fix: F-16359r285355_fix
Configure the Ubuntu operating system to accept Personal Identity Verification (PIV) credentials.
Install the "opensc-pkcs11" package using the following command:
# sudo apt-get install opensc-pkcs11
b
The Ubuntu operating system must implement certificate status checking for multifactor authentication.
Using an authentication device, such as a CAC or token that is separate from the information system, ensures that even if the information system is compromised, that compromise will not affect credentials stored on the authentication device.
Multifactor solutions that require devices separate from information systems gaining access include, for example, hardware tokens providing time-based or challenge-response authenticators and smart cards such as the U.S. Government Personal Identity Verification card and the DoD Common Access Card.
A privileged account is defined as an information system account with authorizations of a privileged user.
Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
This requirement only applies to components where this is specific to the function of the device or has the concept of an organizational user (e.g., VPN, proxy capability). This does not apply to authentication for the purpose of configuring the device itself (management).
Requires further clarification from NIST.
Satisfies: SRG-OS-000375-GPOS-00160, SRG-OS-000375-GPOS-00161, SRG-OS-000375-GPOS-00162
Fix: F-16360r285358_fix
Configure the Ubuntu operating system to certificate status checking for multifactor authentication.
Modify all of the cert_policy lines in "/etc/pam_pkcs11/pam_pkcs11.conf" to include "ocsp_on".
b
The Ubuntu operating system, for PKI-based authentication, must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.
Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted.
A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC.
When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a Certification Authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA.
This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement.
Satisfies: SRG-OS-000066-GPOS-00034, SRG-OS-000384-GPOS-00167
Fix: F-16361r285361_fix
Configure the Ubuntu operating system, for PKI-based authentication, to validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor.
Determine which pkcs11 module is being used via the "use_pkcs11_module" in "/etc/pam_pkcs11/pam_pkcs11.conf" and ensure "ca" is enabled in "cert_policy".
Add or update the "cert_policy" to ensure "ca" is enabled:
cert_policy = ca,signature,ocsp_on;