Group
Guide to the Secure Configuration of Ubuntu 22.04
Group contains 74 groups and 216 rules |
Group
System Settings
Group contains 52 groups and 109 rules |
[ref]
Contains rules that check correct system settings. |
Group
Installing and Maintaining Software
Group contains 10 groups and 13 rules |
[ref]
The following sections contain information on
security-relevant choices during the initial operating system
installation process and the setup of software
updates. |
Group
System and Software Integrity
Group contains 3 groups and 6 rules |
[ref]
System and software integrity can be gained by installing antivirus, increasing
system encryption strength with FIPS, verifying installed software, enabling SELinux,
installing an Intrusion Prevention System, etc. However, installing or enabling integrity
checking tools cannot prevent intrusions, but they can detect that an intrusion
may have occurred. Requirements for integrity checking may be highly dependent on
the environment in which the system will be used. Snapshot-based approaches such
as AIDE may induce considerable overhead in the presence of frequent software updates. |
Group
Software Integrity Checking
Group contains 1 group and 5 rules |
[ref]
Both the AIDE (Advanced Intrusion Detection Environment)
software and the RPM package management system provide
mechanisms for verifying the integrity of installed software.
AIDE uses snapshots of file metadata (such as hashes) and compares these
to current system files in order to detect changes.
The RPM package management system can conduct integrity
checks by comparing information in its metadata database with
files installed on the system. |
Group
Verify Integrity with AIDE
Group contains 5 rules |
[ref]
AIDE conducts integrity checks by comparing information about
files with previously-gathered information. Ideally, the AIDE database is
created immediately after initial system configuration, and then again after any
software update. AIDE is highly configurable, with further configuration
information located in /usr/share/doc/aide-VERSION
. |
Rule
Install AIDE
[ref] | The aide package can be installed with the following command:
$ apt-get install aide
| Rationale: | The AIDE package must be installed if it is to be available for integrity checking. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_aide_installed | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | disa | CCI-002696, CCI-001744 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | ism | 1034, 1288, 1341, 1417 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | nist | CM-6(a) | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | pcidss | Req-11.5 | os-srg | SRG-OS-000445-GPOS-00199 | stigid | UBTU-22-651010 | cis | 1.3.1 | anssi | R76, R79 | pcidss4 | 11.5.2 | stigref | SV-260582r958944_rule |
| |
|
Rule
Build and Test AIDE Database
[ref] | Run the following command to generate a new database:
$ sudo aideinit
By default, the database will be written to the file
/var/lib/aide/aide.db.new .
Storing the database, the configuration file /etc/aide.conf , and the binary
/usr/bin/aide
(or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity.
The newly-generated database can be installed as follows:
$ sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
To initiate a manual check, run the following command:
$ sudo /usr/bin/aide --check
If this check produces any unexpected output, investigate. | Rationale: | For AIDE to be effective, an initial database of "known-good" information about files
must be captured and it should be able to be verified against the installed files. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_aide_build_database | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | disa | CCI-002696, CCI-001744 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | nist | CM-6(a) | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | pcidss | Req-11.5 | os-srg | SRG-OS-000445-GPOS-00199 | stigid | UBTU-22-651015 | cis | 1.3.1 | anssi | R76, R79 | pcidss4 | 11.5.2 | stigref | SV-260583r958944_rule |
| |
|
Rule
Configure AIDE to Verify the Audit Tools
[ref] | The operating system file integrity tool must be configured to protect the integrity of the audit tools. | Rationale: | Protecting the integrity of the tools used for auditing purposes is a
critical step toward ensuring the integrity of audit information. Audit
information includes all information (e.g., audit records, audit settings,
and audit reports) needed to successfully audit information system
activity.
Audit tools include but are not limited to vendor-provided and open-source
audit tools needed to successfully view and manipulate audit information
system activity and records. Audit tools include custom queries and report
generators.
It is not uncommon for attackers to replace the audit tools or inject code
into the existing tools to provide the capability to hide or erase system
activity from the audit logs.
To address this risk, audit tools must be cryptographically signed to
provide the capability to identify when the audit tools have been modified,
manipulated, or replaced. An example is a checksum hash of the file or
files. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_aide_check_audit_tools | References: | disa | CCI-001496, CCI-001494, CCI-001495, CCI-001493 | nist | AU-9(3), AU-9(3).1 | os-srg | SRG-OS-000278-GPOS-00108 | stigid | UBTU-22-651030 | cis | 4.1.4.11 | stigref | SV-260586r991567_rule |
| |
|
Rule
Configure AIDE To Notify Personnel if Baseline Configurations Are Altered
[ref] | The operating system file integrity tool must be configured to notify designated personnel of any changes to configurations. | Rationale: | Detecting changes in the system can help avoid unintended, and negative consequences
that could affect the security state of the operating system | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_aide_disable_silentreports | References: | disa | CCI-001744, CCI-002702 | os-srg | SRG-OS-000447-GPOS-00201, SRG-OS-000363-GPOS-00150 | stigid | UBTU-22-651020 | stigref | SV-260584r958794_rule |
| |
|
Rule
Configure Periodic Execution of AIDE
[ref] | At a minimum, AIDE should be configured to run a weekly scan.
To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab :
05 4 * * * root /usr/bin/aide --config /etc/aide/aide.conf --check
To implement a weekly execution of AIDE at 4:05am using cron, add the following line to /etc/crontab :
05 4 * * 0 root /usr/bin/aide --config /etc/aide/aide.conf --check
AIDE can be executed periodically through other means; this is merely one example.
The usage of cron's special time codes, such as @daily and
@weekly is acceptable. | Rationale: | By default, AIDE does not install itself for periodic execution. Periodically
running AIDE is necessary to reveal unexpected changes in installed files.
Unauthorized changes to the baseline configuration could make the system vulnerable
to various attacks or allow unauthorized access to the operating system. Changes to
operating system configurations can have unintended side effects, some of which may
be relevant to security.
Detecting such changes and providing an automated response can help avoid unintended,
negative consequences that could ultimately affect the security state of the operating
system. The operating system's Information Management Officer (IMO)/Information System
Security Officer (ISSO) and System Administrators (SAs) must be notified via email and/or
monitoring system trap when there is an unauthorized modification of a configuration item. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_aide_periodic_cron_checking | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | disa | CCI-002702, CCI-001744, CCI-002699 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | nist | SI-7, SI-7(1), CM-6(a) | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | pcidss | Req-11.5 | os-srg | SRG-OS-000363-GPOS-00150, SRG-OS-000446-GPOS-00200, SRG-OS-000447-GPOS-00201 | stigid | UBTU-22-651025 | cis | 1.3.2 | anssi | R76 | pcidss4 | 11.5.2 | stigref | SV-260585r958946_rule |
| |
|
Group
Federal Information Processing Standard (FIPS)
Group contains 1 rule |
[ref]
The Federal Information Processing Standard (FIPS) is a computer security standard which
is developed by the U.S. Government and industry working groups to validate the quality
of cryptographic modules. The FIPS standard provides four security levels to ensure
adequate coverage of different industries, implementation of cryptographic modules, and
organizational sizes and requirements.
FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules
utilize authentication that meets industry and government requirements. For government systems, this allows
Security Levels 1, 2, 3, or 4 for use on Ubuntu 22.04.
See http://csrc.nist.gov/publications/PubsFIPS.html for more information. |
Rule
Verify '/proc/sys/crypto/fips_enabled' exists
[ref] | On a system where FIPS 140-2 mode is enabled, /proc/sys/crypto/fips_enabled must exist.
To verify FIPS mode, run the following command:
cat /proc/sys/crypto/fips_enabled
Warning:
To configure the OS to run in FIPS 140-2 mode, the kernel parameter "fips=1" needs to be added during its installation.
Enabling FIPS mode on a preexisting system involves a number of modifications to it. Refer to the vendor installation
guidances. Warning:
System Crypto Modules must be provided by a vendor that undergoes
FIPS-140 certifications.
FIPS-140 is applicable to all Federal agencies that use
cryptographic-based security systems to protect sensitive information
in computer and telecommunication systems (including voice systems) as
defined in Section 5131 of the Information Technology Management Reform
Act of 1996, Public Law 104-106. This standard shall be used in
designing and implementing cryptographic modules that Federal
departments and agencies operate or are operated for them under
contract. See https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf
To meet this, the system has to have cryptographic software provided by
a vendor that has undergone this certification. This means providing
documentation, test results, design information, and independent third
party review by an accredited lab. While open source software is
capable of meeting this, it does not meet FIPS-140 unless the vendor
submits to this process. | Rationale: | Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to
protect data. The 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. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_is_fips_mode_enabled | References: | disa | CCI-002450 | nist | SC-12(2), SC-12(3), SC-13 | os-srg | SRG-OS-000396-GPOS-00176, SRG-OS-000478-GPOS-00223 | stigid | UBTU-22-671010 | stigref | SV-260650r987791_rule |
| |
|
Group
Disk Partitioning
Group contains 1 rule |
[ref]
To ensure separation and protection of data, there
are top-level system directories which should be placed on their
own physical partition or logical volume. The installer's default
partitioning scheme creates separate logical volumes for
/ , /boot , and swap .
- If starting with any of the default layouts, check the box to
\"Review and modify partitioning.\" This allows for the easy creation
of additional logical volumes inside the volume group already
created, though it may require making
/ 's logical volume smaller to
create space. In general, using logical volumes is preferable to
using partitions because they can be more easily adjusted
later. - If creating a custom layout, create the partitions mentioned in
the previous paragraph (which the installer will require anyway),
as well as separate ones described in the following sections.
If a system has already been installed, and the default
partitioning
scheme was used, it is possible but nontrivial to
modify it to create separate logical volumes for the directories
listed above. The Logical Volume Manager (LVM) makes this possible. |
Rule
Encrypt Partitions
[ref] | Ubuntu 22.04 natively supports partition encryption through the
Linux Unified Key Setup-on-disk-format (LUKS) technology. The easiest way to
encrypt a partition is during installation time.
For manual installations, select the Encrypt checkbox during
partition creation to encrypt the partition. When this
option is selected the system will prompt for a passphrase to use in
decrypting the partition. The passphrase will subsequently need to be entered manually
every time the system boots.
Detailed information on encrypting partitions using LUKS or LUKS ciphers can be found on
the Ubuntu 22.04 Documentation web site:
https://help.ubuntu.com/community/Full_Disk_Encryption_Howto_2019
. | Rationale: | The risk of a system's physical compromise, particularly mobile systems such as
laptops, places its data at risk of compromise. Encrypting this data mitigates
the risk of its loss if the system is lost. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_encrypt_partitions | References: | cis-csc | 13, 14 | cobit5 | APO01.06, BAI02.01, BAI06.01, DSS04.07, DSS05.03, DSS05.04, DSS05.07, DSS06.02, DSS06.06 | cui | 3.13.16 | disa | CCI-002476, CCI-001199, CCI-002475 | hipaa | 164.308(a)(1)(ii)(D), 164.308(b)(1), 164.310(d), 164.312(a)(1), 164.312(a)(2)(iii), 164.312(a)(2)(iv), 164.312(b), 164.312(c), 164.314(b)(2)(i), 164.312(d) | isa-62443-2013 | SR 3.4, SR 4.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1 | nist | CM-6(a), SC-28, SC-28(1), SC-13, AU-9(3) | nist-csf | PR.DS-1, PR.DS-5 | os-srg | SRG-OS-000405-GPOS-00184, SRG-OS-000185-GPOS-00079, SRG-OS-000404-GPOS-00183 | stigid | UBTU-22-231010 | stigref | SV-260484r958552_rule |
| |
|
Group
GNOME Desktop Environment
Group contains 2 groups and 4 rules |
[ref]
GNOME is a graphical desktop environment bundled with many Linux distributions that
allow users to easily interact with the operating system graphically rather than
textually. The GNOME Graphical Display Manager (GDM) provides login, logout, and user
switching contexts as well as display server management.
GNOME is developed by the GNOME Project and is considered the default
Red Hat Graphical environment.
For more information on GNOME and the GNOME Project, see https://www.gnome.org. |
Group
Configure GNOME Screen Locking
Group contains 3 rules |
[ref]
In the default GNOME3 desktop, the screen can be locked
by selecting the user name in the far right corner of the main panel and
selecting Lock.
The following sections detail commands to enforce idle activation of the screensaver,
screen locking, a blank-screen screensaver, and an idle activation time.
Because users should be trained to lock the screen when they
step away from the computer, the automatic locking feature is only
meant as a backup.
The root account can be screen-locked; however, the root account should
never be used to log into an X Windows environment and should only
be used to for direct login via console in emergency circumstances.
For more information about enforcing preferences in the GNOME3 environment using the DConf
configuration system, see http://wiki.gnome.org/dconf and
the man page dconf(1) . |
Rule
Set GNOME3 Screensaver Inactivity Timeout
[ref] | The idle time-out value for inactivity in the GNOME3 desktop is configured via the idle-delay
setting must be set under an appropriate configuration file(s) in the /etc/dconf/db/local.d directory
and locked in /etc/dconf/db/local.d/locks directory to prevent user modification.
For example, to configure the system for a 15 minute delay, add the following to
/etc/dconf/db/local.d/00-security-settings :
[org/gnome/desktop/session]
idle-delay=uint32 900
| Rationale: | A session time-out 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 logout because of the
temporary nature of the absence. Rather than relying on the user to manually lock their operating
system session prior to vacating the vicinity, GNOME3 can be configured to identify when
a user's session has idled and take action to initiate a session lock. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_screensaver_idle_delay | References: | cis-csc | 1, 12, 15, 16 | cjis | 5.5.5 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.10 | disa | CCI-000057, CCI-000060 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | AC-11(a), CM-6(a) | nist-csf | PR.AC-7 | pcidss | Req-8.1.8 | os-srg | SRG-OS-000029-GPOS-00010, SRG-OS-000031-GPOS-00012 | stigid | UBTU-22-271025 | pcidss4 | 8.2.8, 8.2 | stigref | SV-260538r958402_rule |
| |
|
Rule
Set GNOME3 Screensaver Lock Delay After Activation Period
[ref] | To activate the locking delay of the screensaver in the GNOME3 desktop when
the screensaver is activated, add or set lock-delay to uint32 0
in
/etc/dconf/db/local.d/00-security-settings . For example:
[org/gnome/desktop/screensaver]
lock-delay=uint32 0
After the settings have been set, run dconf update . | Rationale: | 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 logout because of the temporary nature of the absense. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_screensaver_lock_delay | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.10 | disa | CCI-000057 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | AC-11(a), CM-6(a) | nist-csf | PR.AC-7 | pcidss | Req-8.1.8 | os-srg | SRG-OS-000029-GPOS-00010, SRG-OS-000031-GPOS-00012 | stigid | UBTU-22-271025 | cis | 1.8.5 | pcidss4 | 8.2.8, 8.2 | stigref | SV-260538r958402_rule |
| |
|
Rule
Enable GNOME3 Screensaver Lock After Idle Period
[ref] |
To activate locking of the screensaver in the GNOME3 desktop when it is activated,
add or set lock-enabled to true in
/etc/dconf/db/local.d/00-security-settings . For example:
[org/gnome/desktop/screensaver]
lock-enabled=true
Once the settings have been added, add a lock to
/etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification.
For example:
/org/gnome/desktop/screensaver/lock-enabled
After the settings have been set, run dconf update . | Rationale: | 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 logout because of the temporary nature of the absense. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_screensaver_lock_enabled | References: | cis-csc | 1, 12, 15, 16 | cjis | 5.5.5 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.10 | disa | CCI-000057, CCI-000056 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a) | nist-csf | PR.AC-7 | pcidss | Req-8.1.8 | os-srg | SRG-OS-000028-GPOS-00009, SRG-OS-000030-GPOS-00011 | stigid | UBTU-22-271020 | cis | 1.8.4 | pcidss4 | 8.2.8, 8.2 | stigref | SV-260537r958400_rule |
| |
|
Group
GNOME System Settings
Group contains 1 rule |
[ref]
GNOME provides configuration and functionality to a graphical desktop environment
that changes grahical configurations or allow a user to perform
actions that users normally would not be able to do in non-graphical mode such as
remote access configuration, power policies, Geo-location, etc.
Configuring such settings in GNOME will prevent accidential graphical configuration
changes by users from taking place. |
Rule
Disable Ctrl-Alt-Del Reboot Key Sequence in GNOME3
[ref] | By default, GNOME will reboot the system if the
Ctrl-Alt-Del key sequence is pressed.
To configure the system to ignore the Ctrl-Alt-Del key sequence
from the Graphical User Interface (GUI) instead of rebooting the system,
add or set logout to [''] in
/etc/dconf/db/local.d/00-security-settings . For example:
[org/gnome/settings-daemon/plugins/media-keys]
logout=['']
Once the settings have been added, add a lock to
/etc/dconf/db/local.d/locks/00-security-settings-lock to prevent
user modification. For example:
/org/gnome/settings-daemon/plugins/media-keys/logout
After the settings have been set, run dconf update . | Rationale: | A locally logged-in user who presses Ctrl-Alt-Del, when at the console,
can reboot the system. If accidentally pressed, as could happen in
the case of mixed OS environment, this can create the risk of short-term
loss of availability of systems due to unintentional reboot. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_disable_ctrlaltdel_reboot | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.1.2 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1), CM-7(b) | nist-csf | PR.AC-4, PR.DS-5 | os-srg | SRG-OS-000480-GPOS-00227 | stigid | UBTU-22-271030 | stigref | SV-260539r991589_rule |
| |
|
Group
Sudo
Group contains 1 rule |
[ref]
Sudo , which stands for "su 'do'", provides the ability to delegate authority
to certain users, groups of users, or system administrators. When configured for system
users and/or groups, Sudo can allow a user or group to execute privileged commands
that normally only root is allowed to execute.
For more information on Sudo and addition Sudo configuration options, see
https://www.sudo.ws. |
Rule
Ensure Users Re-Authenticate for Privilege Escalation - sudo
[ref] | The sudo NOPASSWD and !authenticate option, when
specified, allows a user to execute commands using sudo without having to
authenticate. This should be disabled by making sure that
NOPASSWD and/or !authenticate do not exist in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/ ." | Rationale: | Without re-authentication, users may access resources or perform tasks for which they
do not have authorization.
When operating systems provide the capability to escalate a functional capability, it
is critical that the user re-authenticate. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_require_authentication | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-002038, CCI-004895 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-11, CM-6(a) | nist-csf | PR.AC-1, PR.AC-7 | os-srg | SRG-OS-000373-GPOS-00156 | stigid | UBTU-22-432010 | cis | 5.3.4 | pcidss4 | 2.2.6, 2.2 | stigref | SV-260558r987879_rule |
| |
|
Group
Updating Software
Group contains 1 rule |
[ref]
The apt_get command line tool is used to install and
update software packages. The system also provides a graphical
software update tool in the System menu, in the Administration submenu,
called Software Update.
Ubuntu 22.04 systems contain an installed software catalog called
the RPM database, which records metadata of installed packages. Consistently using
apt_get or the graphical Software Update for all software installation
allows for insight into the current inventory of installed software on the system.
|
Rule
Ensure apt_get Removes Previous Package Versions
[ref] | apt_get should be configured to remove previous software components after
new versions have been installed. To configure apt_get to remove the
previous software components after updating, set the ::Remove-Unused-Dependencies and
::Remove-Unused-Kernel-Packages
to true in /etc/apt/apt.conf .
| Rationale: | Previous versions of software components that are not removed from the information
system after updates have been installed may be exploited by some adversaries. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_clean_components_post_updating | References: | cis-csc | 18, 20, 4 | cobit5 | APO12.01, APO12.02, APO12.03, APO12.04, BAI03.10, DSS05.01, DSS05.02 | cui | 3.4.8 | disa | CCI-002617 | isa-62443-2009 | 4.2.3, 4.2.3.12, 4.2.3.7, 4.2.3.9 | iso27001-2013 | A.12.6.1, A.14.2.3, A.16.1.3, A.18.2.2, A.18.2.3 | nist | SI-2(6), CM-11(a), CM-11(b), CM-6(a) | nist-csf | ID.RA-1, PR.IP-12 | os-srg | SRG-OS-000437-GPOS-00194 | stigid | UBTU-22-214015 | stigref | SV-260477r958936_rule |
| |
|
Group
Account and Access Control
Group contains 18 groups and 44 rules |
[ref]
In traditional Unix security, if an attacker gains
shell access to a certain login account, they can perform any action
or access any file to which that account has access. Therefore,
making it more difficult for unauthorized people to gain shell
access to accounts, particularly to privileged accounts, is a
necessary part of securing a system. This section introduces
mechanisms for restricting access to accounts under
Ubuntu 22.04. |
Group
Warning Banners for System Accesses
Group contains 1 group and 3 rules |
[ref]
Each system should expose as little information about
itself as possible.
System banners, which are typically displayed just before a
login prompt, give out information about the service or the host's
operating system. This might include the distribution name and the
system kernel version, and the particular version of a network
service. This information can assist intruders in gaining access to
the system as it can reveal whether the system is running
vulnerable software. Most network services can be configured to
limit what information is displayed.
Many organizations implement security policies that require a
system banner provide notice of the system's ownership, provide
warning to unauthorized users, and remind authorized users of their
consent to monitoring. |
Group
Implement a GUI Warning Banner
Group contains 2 rules |
[ref]
In the default graphical environment, users logging
directly into the system are greeted with a login screen provided
by the GNOME Display Manager (GDM). The warning banner should be
displayed in this graphical environment for these users.
The following sections describe how to configure the GDM login
banner. |
Rule
Enable GNOME3 Login Warning Banner
[ref] | In the default graphical environment, displaying a login warning banner
in the GNOME Display Manager's login screen can be enabled on the login
screen by setting banner-message-enable to true .
To enable, add or edit banner-message-enable to
/etc/dconf/db/gdm.d/00-security-settings . For example:
[org/gnome/login-screen]
banner-message-enable=true
Once the setting has been added, add a lock to
/etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification.
For example:
/org/gnome/login-screen/banner-message-enable
After the settings have been set, run dconf update .
The banner text must also be set. | Rationale: | Display of a standardized and approved use notification before granting access to the operating system
ensures privacy and security notification verbiage used is consistent with applicable federal laws,
Executive Orders, directives, policies, regulations, standards, and guidance.
For U.S. Government systems, system use notifications are required only for access via login interfaces
with human users and are not required when such human interfaces do not exist. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_banner_enabled | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.9 | disa | CCI-001387, CCI-001384, CCI-000048, CCI-001386, CCI-001388, CCI-001385 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | AC-8(a), AC-8(b), AC-8(c) | nist-csf | PR.AC-7 | os-srg | SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 | stigid | UBTU-22-271010 | cis | 1.8.2 | stigref | SV-260535r958390_rule |
| |
|
Rule
Set the GNOME3 Login Warning Banner Text
[ref] | In the default graphical environment, configuring the login warning banner text
in the GNOME Display Manager's login screen can be configured on the login
screen by setting banner-message-text to 'APPROVED_BANNER'
where APPROVED_BANNER is the approved banner for your environment.
To enable, add or edit banner-message-text to
/etc/gdm3/greeter.dconf-defaults . For example:
[org/gnome/login-screen]
banner-message-text='APPROVED_BANNER'
After the settings have been set, run dconf update .
When entering a warning banner that spans several lines, remember
to begin and end the string with ' and use \n for new lines. | Rationale: | An appropriate warning message reinforces policy awareness during the logon
process and facilitates possible legal action against attackers. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_login_banner_text | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.9 | disa | CCI-000048, CCI-001384, CCI-001385, CCI-001386, CCI-001387, CCI-001388 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | AC-8(a), AC-8(c) | nist-csf | PR.AC-7 | os-srg | SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 | stigid | UBTU-22-271015 | cis | 1.8.2 | stigref | SV-260536r958390_rule |
| |
|
Rule
Modify the System Login Banner for Remote Connections
[ref] | To configure the system login banner edit /etc/issue.net . Replace the
default text with a message compliant with the local site policy or a legal
disclaimer.
The DoD required text is either:
You are accessing a U.S. Government (USG) Information System (IS) that
is provided for USG-authorized use only. By using this IS (which includes
any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS
for purposes including, but not limited to, penetration testing, COMSEC
monitoring, network operations and defense, personnel misconduct (PM), law
enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private,
are subject to routine monitoring, interception, and search, and may be
disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access
controls) to protect USG interests -- not for your personal benefit or
privacy.
-Notwithstanding the above, using this IS does not constitute consent
to PM, LE or CI investigative searching or monitoring of the content of
privileged communications, or work product, related to personal
representation or services by attorneys, psychotherapists, or clergy, and
their assistants. Such communications and work product are private and
confidential. See User Agreement for details.
OR:
I've read & consent to terms in IS user agreem't.
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
System use notifications are required only for access via login interfaces
with human users and are not required when such human interfaces do not
exist. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_banner_etc_issue_net | References: | disa | CCI-000048, CCI-001384, CCI-001385, CCI-001386, CCI-001387, CCI-001388 | os-srg | SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 | stigid | UBTU-22-255020 | cis | 1.7.3 | stigref | SV-260525r958390_rule |
| |
|
Group
Protect Accounts by Configuring PAM
Group contains 4 groups and 19 rules |
[ref]
PAM, or Pluggable Authentication Modules, is a system
which implements modular authentication for Linux programs. PAM provides
a flexible and configurable architecture for authentication, and it should be configured
to minimize exposure to unnecessary risk. This section contains
guidance on how to accomplish that.
PAM is implemented as a set of shared objects which are
loaded and invoked whenever an application wishes to authenticate a
user. Typically, the application must be running as root in order
to take advantage of PAM, because PAM's modules often need to be able
to access sensitive stores of account information, such as /etc/shadow.
Traditional privileged network listeners
(e.g. sshd) or SUID programs (e.g. sudo) already meet this
requirement. An SUID root application, userhelper, is provided so
that programs which are not SUID or privileged themselves can still
take advantage of PAM.
PAM looks in the directory /etc/pam.d for
application-specific configuration information. For instance, if
the program login attempts to authenticate a user, then PAM's
libraries follow the instructions in the file /etc/pam.d/login
to determine what actions should be taken.
One very important file in /etc/pam.d is
/etc/pam.d/system-auth . This file, which is included by
many other PAM configuration files, defines 'default' system authentication
measures. Modifying this file is a good way to make far-reaching
authentication changes, for instance when implementing a
centralized authentication service. Warning:
Be careful when making changes to PAM's configuration files.
The syntax for these files is complex, and modifications can
have unexpected consequences. The default configurations shipped
with applications should be sufficient for most users. |
Group
Set Lockouts for Failed Password Attempts
Group contains 6 rules |
[ref]
The pam_faillock PAM module provides the capability to
lock out user accounts after a number of failed login attempts. Its
documentation is available in
/usr/share/doc/pam-VERSION/txts/README.pam_faillock .
Warning:
Locking out user accounts presents the
risk of a denial-of-service attack. The lockout policy
must weigh whether the risk of such a
denial-of-service attack outweighs the benefits of thwarting
password guessing attacks. |
Rule
Enforce Delay After Failed Logon Attempts
[ref] | To configure the system to introduce a delay after failed logon attempts,
add or correct the pam_faildelay settings in
/etc/pam.d/common-auth to make sure its delay parameter
is at least 4000000 or greater. For example:
auth required pam_faildelay.so delay=4000000
| Rationale: | Limiting the number of logon attempts over a certain time interval reduces
the chances that an unauthorized user may gain access to an account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faildelay_delay | References: | | |
|
Rule
Account Lockouts Must Be Logged
[ref] | PAM faillock locks an account due to excessive password failures, this event must be logged. | Rationale: | Without auditing of these events it may be harder or impossible to identify what an attacker did after an attack. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_audit | References: | | |
|
Rule
Lock Accounts After Failed Password Attempts
[ref] | This rule configures the system to lock out accounts after a number of incorrect login attempts
using pam_faillock.so .
pam_faillock.so module requires multiple entries in pam files. These entries must be carefully
defined to work as expected.
Ensure that the file /etc/security/faillock.conf contains the following entry:
deny = <count>
Where count should be less than or equal to
3 and greater than 0. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
If the system supports the /etc/security/faillock.conf file, the pam_faillock
parameters should be defined in faillock.conf file. | Rationale: | By limiting the number of failed logon attempts, the risk of unauthorized system access via
user password guessing, also known as brute-forcing, is reduced. Limits are imposed by locking
the account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny | References: | cis-csc | 1, 12, 15, 16 | cjis | 5.5.3 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.8 | disa | CCI-000044, CCI-002238 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a), AC-7(a) | nist-csf | PR.AC-7 | ospp | FIA_AFL.1 | pcidss | Req-8.1.6 | os-srg | SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | stigid | UBTU-22-411045 | cis | 5.4.2 | anssi | R31 | pcidss4 | 8.3.4, 8.3 | stigref | SV-260549r958388_rule |
| |
|
Rule
Set Interval For Counting Failed Password Attempts
[ref] | Utilizing pam_faillock.so , the fail_interval directive configures the system
to lock out an account after a number of incorrect login attempts within a specified time
period.
Ensure that the file /etc/security/faillock.conf contains the following entry:
fail_interval = <interval-in-seconds> where interval-in-seconds is 900 or greater. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
If the system supports the /etc/security/faillock.conf file, the pam_faillock
parameters should be defined in faillock.conf file. | Rationale: | By limiting the number of failed logon attempts the risk of unauthorized system
access via user password guessing, otherwise known as brute-forcing, is reduced.
Limits are imposed by locking the account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_interval | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | disa | CCI-000044, CCI-002238 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a), AC-7(a) | nist-csf | PR.AC-7 | ospp | FIA_AFL.1 | os-srg | SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | stigid | UBTU-22-411045 | cis | 5.4.2 | anssi | R31 | stigref | SV-260549r958388_rule |
| |
|
Rule
Do Not Show System Messages When Unsuccessful Logon Attempts Occur
[ref] | This rule ensures the system prevents informative messages from being presented to the user
pertaining to logon information after a number of incorrect login attempts using
pam_faillock.so .
pam_faillock.so module requires multiple entries in pam files. These entries must be carefully
defined to work as expected. In order to avoid errors when manually editing these files, it is
recommended to use the appropriate tools, such as authselect or authconfig ,
depending on the OS version. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
If the system supports the /etc/security/faillock.conf file, the pam_faillock
parameters should be defined in faillock.conf file. | Rationale: | The pam_faillock module without the silent option will leak information about the existence or
non-existence of a user account in the system because the failures are not recorded for unknown
users. The message about the user account being locked is never displayed for non-existing user
accounts allowing the adversary to infer that a particular account exists or not on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_silent | References: | disa | CCI-002238, CCI-000044 | os-srg | SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | stigid | UBTU-22-411045 | stigref | SV-260549r958388_rule |
| |
|
Rule
Set Lockout Time for Failed Password Attempts
[ref] | This rule configures the system to lock out accounts during a specified time period after a
number of incorrect login attempts using pam_faillock.so .
Ensure that the file /etc/security/faillock.conf contains the following entry:
unlock_time=<interval-in-seconds> where
interval-in-seconds is 0 or greater.
pam_faillock.so module requires multiple entries in pam files. These entries must be carefully
defined to work as expected. In order to avoid any errors when manually editing these files,
it is recommended to use the appropriate tools, such as authselect or authconfig ,
depending on the OS version.
If unlock_time is set to 0 , manual intervention by an administrator is required
to unlock a user. This should be done using the faillock tool. Warning:
If the system supports the new /etc/security/faillock.conf file but the
pam_faillock.so parameters are defined directly in /etc/pam.d/system-auth and
/etc/pam.d/password-auth , the remediation will migrate the unlock_time parameter
to /etc/security/faillock.conf to ensure compatibility with authselect tool.
The parameters deny and fail_interval , if used, also have to be migrated
by their respective remediation. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
If the system supports the /etc/security/faillock.conf file, the pam_faillock
parameters should be defined in faillock.conf file. | Rationale: | By limiting the number of failed logon attempts the risk of unauthorized system
access via user password guessing, otherwise known as brute-forcing, is reduced.
Limits are imposed by locking the account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_unlock_time | References: | cis-csc | 1, 12, 15, 16 | cjis | 5.5.3 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.8 | disa | CCI-000044, CCI-002238 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a), AC-7(b) | nist-csf | PR.AC-7 | ospp | FIA_AFL.1 | pcidss | Req-8.1.7 | os-srg | SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | stigid | UBTU-22-411045 | cis | 5.4.2 | anssi | R31 | pcidss4 | 8.3.4, 8.3 | stigref | SV-260549r958388_rule |
| |
|
Group
Set Password Quality Requirements
Group contains 1 group and 9 rules |
[ref]
The default pam_pwquality PAM module provides strength
checking for passwords. It performs a number of checks, such as
making sure passwords are not similar to dictionary words, are of
at least a certain length, are not the previous password reversed,
and are not simply a change of case from the previous password. It
can also require passwords to be in certain character classes. The
pam_pwquality module is the preferred way of configuring
password requirements.
The man pages pam_pwquality(8)
provide information on the capabilities and configuration of
each. |
Group
Set Password Quality Requirements with pam_pwquality
Group contains 9 rules |
[ref]
The pam_pwquality PAM module can be configured to meet
requirements for a variety of policies.
For example, to configure pam_pwquality to require at least one uppercase
character, lowercase character, digit, and other (special)
character, make sure that pam_pwquality exists in /etc/pam.d/system-auth :
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth .
Next, modify the settings in /etc/security/pwquality.conf to match the following:
difok = 4
minlen = 14
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
maxrepeat = 3
The arguments can be modified to ensure compliance with
your organization's security policy. Discussion of each parameter follows. |
Rule
Ensure PAM Enforces Password Requirements - Minimum Digit Characters
[ref] | The pam_pwquality module's dcredit parameter controls requirements for
usage of digits in a password. When set to a negative number, any password will be required to
contain that many digits. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each digit. Modify the dcredit setting in
/etc/security/pwquality.conf to require the use of a digit in passwords. | Rationale: | 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.
Requiring digits makes password guessing attacks more difficult by ensuring a larger
search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_dcredit | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | ospp | FMT_SMF_EXT.1 | pcidss | Req-8.2.3 | os-srg | SRG-OS-000071-GPOS-00039 | stigid | UBTU-22-611020 | cis | 5.4.1 | anssi | R31 | pcidss4 | 8.3.6, 8.3 | stigref | SV-260562r986287_rule |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Prevent the Use of Dictionary Words
[ref] | The pam_pwquality module's dictcheck check if passwords contains dictionary words. When
dictcheck is set to 1 passwords will be checked for dictionary words. | Rationale: | 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.
Passwords with dictionary words may be more vulnerable to password-guessing attacks. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_dictcheck | References: | disa | CCI-000366 | nist | IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4) | os-srg | SRG-OS-000480-GPOS-00225, SRG-OS-000072-GPOS-00040 | stigid | UBTU-22-611030 | stigref | SV-260564r991587_rule |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Different Characters
[ref] | The pam_pwquality module's difok parameter sets the number of characters
in a password that must not be present in and old password during a password change.
Modify the difok setting in /etc/security/pwquality.conf
to equal 8 to require differing characters
when changing passwords. | Rationale: | 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.
Requiring a minimum number of different characters during password changes ensures that
newly changed passwords should not resemble previously compromised ones.
Note that passwords which are changed on compromised systems will still be compromised, however. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_difok | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.1.1 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(b), CM-6(a), IA-5(4) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | os-srg | SRG-OS-000072-GPOS-00040 | stigid | UBTU-22-611040 | stigref | SV-260566r986290_rule |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Enforcing
[ref] | Verify that the operating system uses "pwquality" to enforce the
password complexity rules.
Verify the pwquality module is being enforced by operating system by
running the following command:
$ grep -i enforcing /etc/security/pwquality.conf
enforcing = 1
If the value of "enforcing" is not "1" or the line is commented out,
this is a finding. | Rationale: | 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. Using enforcing=1 ensures "pwquality"
enforces complex password construction configuration and has the ability
to limit brute-force attacks on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_enforcing | References: | | |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Lowercase Characters
[ref] | The pam_pwquality module's lcredit parameter controls requirements for
usage of lowercase letters in a password. When set to a negative number, any password will be required to
contain that many lowercase characters. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each lowercase character. Modify the lcredit setting in
/etc/security/pwquality.conf to require the use of a lowercase character in passwords. | Rationale: | 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
possble combinations that need to be tested before the password is compromised.
Requiring a minimum number of lowercase characters makes password guessing attacks
more difficult by ensuring a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_lcredit | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | ospp | FMT_SMF_EXT.1 | pcidss | Req-8.2.3 | os-srg | SRG-OS-000070-GPOS-00038 | stigid | UBTU-22-611015 | cis | 5.4.1 | anssi | R31 | pcidss4 | 8.3.6, 8.3 | stigref | SV-260561r986286_rule |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Length
[ref] | The pam_pwquality module's minlen parameter controls requirements for
minimum characters required in a password. Add minlen=15
after pam_pwquality to set minimum password length requirements. | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_minlen | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.1.1 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | ospp | FMT_SMF_EXT.1 | pcidss | Req-8.2.3 | os-srg | SRG-OS-000078-GPOS-00046 | stigid | UBTU-22-611035 | cis | 5.4.1 | anssi | R31, R68 | pcidss4 | 8.3.6, 8.3 | stigref | SV-260565r986289_rule |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Special Characters
[ref] | The pam_pwquality module's ocredit= parameter controls requirements for
usage of special (or "other") characters in a password. When set to a negative number,
any password will be required to contain that many special characters.
When set to a positive number, pam_pwquality will grant +1
additional length credit for each special character. Modify the ocredit setting
in /etc/security/pwquality.conf to equal -1
to require use of a special character in passwords. | Rationale: | 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.
Requiring a minimum number of special characters makes password guessing attacks
more difficult by ensuring a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_ocredit | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | ospp | FMT_SMF_EXT.1 | os-srg | SRG-OS-000266-GPOS-00101 | stigid | UBTU-22-611025 | cis | 5.4.1 | anssi | R31 | stigref | SV-260563r991561_rule |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session
[ref] | To configure the number of retry prompts that are permitted per-session:
Edit the pam_pwquality.so statement in
/etc/pam.d/common-password to show
retry=3
, or a lower value if site
policy is more restrictive. The DoD requirement is a maximum of 3 prompts
per session. | Rationale: | Setting the password retry prompts that are permitted on a per-session basis to a low value
requires some software, such as SSH, to re-connect. This can slow down and
draw additional attention to some types of password-guessing attacks. Note that this
is different from account lockout, which is provided by the pam_faillock module. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_retry | References: | cis-csc | 1, 11, 12, 15, 16, 3, 5, 9 | cjis | 5.5.3 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 7.6 | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a), AC-7(a), IA-5(4) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7, PR.IP-1 | os-srg | SRG-OS-000069-GPOS-00037, SRG-OS-000480-GPOS-00227 | stigid | UBTU-22-611045 | cis | 5.4.1 | anssi | R68 | stigref | SV-260567r991587_rule |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Uppercase Characters
[ref] | The pam_pwquality module's ucredit= parameter controls requirements for
usage of uppercase letters in a password. When set to a negative number, any password will be required to
contain that many uppercase characters. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each uppercase character. Modify the ucredit setting in
/etc/security/pwquality.conf to require the use of an uppercase character in passwords. | Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_ucredit | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | ospp | FMT_SMF_EXT.1 | pcidss | Req-8.2.3 | os-srg | SRG-OS-000069-GPOS-00037, SRG-OS-000070-GPOS-00038 | stigid | UBTU-22-611010 | cis | 5.4.1 | anssi | R31 | stigref | SV-260560r986285_rule |
| |
|
Group
Set Password Hashing Algorithm
Group contains 2 rules |
[ref]
The system's default algorithm for storing password hashes in
/etc/shadow is SHA-512. This can be configured in several
locations. |
Rule
Set Password Hashing Algorithm in /etc/login.defs
[ref] | In /etc/login.defs , add or update the following line to ensure the system will use
SHA512 as the hashing algorithm:
ENCRYPT_METHOD SHA512
| Rationale: | 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. Passwords that are encrypted with a weak algorithm
are no more protected than if they are kept in plain text.
Using a stronger hashing algorithm makes password cracking attacks more difficult. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_logindefs | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.2 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.13.11 | disa | CCI-004062 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0418, 1055, 1402 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(c), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.1 | os-srg | SRG-OS-000073-GPOS-00041 | stigid | UBTU-22-611070 | cis | 5.4.4 | pcidss4 | 8.3.2, 8.3 | stigref | SV-260572r971535_rule |
| |
|
Rule
Set PAM''s Password Hashing Algorithm
[ref] | The PAM system service can be configured to only store encrypted representations of passwords.
In "/etc/pam.d/common-password", the password section of the file controls which
PAM modules to execute during a password change.
Set the pam_unix.so module in the password section to include the option
sha512 and no other hashing
algorithms as shown below:
password [success=1 default=ignore] pam_unix.so sha512
other arguments...
This will help ensure that new passwords for local users will be stored using the
sha512 algorithm. Warning:
The hashing algorithms to be used with pam_unix.so are defined with independent module
options. There are at least 7 possible algorithms and likely more algorithms will be
introduced along the time. Due the the number of options and its possible combinations,
the use of multiple hashing algorithm options may bring unexpected behaviors to the
system. For this reason the check will pass only when one hashing algorithm option is
defined and is aligned to the "var_password_hashing_algorithm_pam" variable. The
remediation will ensure the correct option and remove any other extra hashing algorithm
option. | Rationale: | 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. Passwords that are encrypted with a weak algorithm
are no more protected than if they are kept in plain text.
This setting ensures user and group account administration utilities are configured to store
only encrypted representations of passwords. Additionally, the crypt_style
configuration option in /etc/libuser.conf ensures the use of a strong hashing
algorithm that makes password cracking attacks more difficult. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_systemauth | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.2 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.13.11 | disa | CCI-000196, CCI-000803, CCI-004062 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0418, 1055, 1402 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(c), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.1 | os-srg | SRG-OS-000073-GPOS-00041, SRG-OS-000120-GPOS-00061 | stigid | UBTU-22-611055 | anssi | R68 | pcidss4 | 8.3.2, 8.3 | stigref | SV-260569r986291_rule |
| |
|
Rule
Install pam_pwquality Package
[ref] |
The libpam-pwquality package can be installed with the following command:
$ apt-get install libpam-pwquality
| Rationale: | Use of a complex password helps to increase the time and resources required
to compromise the password. Password complexity, or strength, is a measure
of the effectiveness of a password in resisting attempts at guessing and
brute-force attacks. "pwquality" enforces complex password construction
configuration and has the ability to limit brute-force attacks on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_pam_pwquality_installed | References: | | |
|
Rule
Ensure PAM Displays Last Logon/Access Notification
[ref] | To configure the system to notify users of last logon/access using pam_lastlog ,
add or correct the pam_lastlog settings in /etc/pam.d/login
to include showfailed option, such as:
session required pam_lastlog.so showfailed
And make sure that the silent option is not set for this specific line. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report. Warning:
authselect contains an authselect feature to easily and properly enable Last Logon
notifications with pam_lastlog.so module. If a custom profile was created and used
in the system before this authselect feature was available, the new feature can't be used
with this custom profile and the remediation will fail. In this case, the custom profile
should be recreated or manually updated. | Rationale: | Users need to be aware of activity that occurs regarding their account. Providing users with
information regarding the number of unsuccessful attempts that were made to login to their
account allows the user to determine if any unauthorized activity has occurred and gives them
an opportunity to notify administrators. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_display_login_attempts | References: | cis-csc | 1, 12, 15, 16 | cjis | 5.5.2 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | ism | 0582, 0584, 05885, 0586, 0846, 0957 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | AC-9, AC-9(1) | nist-csf | PR.AC-7 | pcidss | Req-10.2.4 | os-srg | SRG-OS-000480-GPOS-00227 | stigid | UBTU-22-412015 | pcidss4 | 10.2.1.4, 10.2.1, 10.2 | stigref | SV-260551r991589_rule |
| |
|
Group
Protect Physical Console Access
Group contains 3 groups and 10 rules |
[ref]
It is impossible to fully protect a system from an
attacker with physical access, so securing the space in which the
system is located should be considered a necessary step. However,
there are some steps which, if taken, make it more difficult for an
attacker to quickly or undetectably modify a system from its
console. |
Group
Configure Screen Locking
Group contains 2 groups and 8 rules |
[ref]
When a user must temporarily leave an account
logged-in, screen locking should be employed to prevent passersby
from abusing the account. User education and training is
particularly important for screen locking to be effective, and policies
can be implemented to reinforce this.
Automatic screen locking is only meant as a safeguard for
those cases where a user forgot to lock the screen. |
Group
Configure Console Screen Locking
Group contains 1 rule |
[ref]
A console screen locking mechanism 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 logout because of the temporary nature of
the absence. Rather than relying on the user to manually lock their
operation system session prior to vacating the vicinity, operating systems
need to be able to identify when a user's session has idled and take action
to initiate the session lock. |
Rule
Check that vlock is installed to allow session locking
[ref] | The Ubuntu 22.04 operating system must have vlock installed to allow for session locking.
The vlock package can be installed with the following command:
$ apt-get install vlock
| Rationale: | A session lock is a temporary action taken when a user stops work and
moves away from the immediate physical vicinity of the information
system but does not want to log out because of the temporary nature of
the absence.
The session lock is implemented at the point where session activity can
be determined.
Regardless of where the session lock is determined and implemented,
once invoked, the session lock must remain in place until the user
reauthenticates. No other activity aside from reauthentication must
unlock the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_vlock_installed | References: | disa | CCI-000056, CCI-000057, CCI-000058, CCI-000060 | os-srg | SRG-OS-000028-GPOS-00009, SRG-OS-000030-GPOS-00011 | stigid | UBTU-22-412025 | stigref | SV-260553r986283_rule |
| |
|
Group
Hardware Tokens for Authentication
Group contains 7 rules |
[ref]
The use of hardware tokens such as smart cards for system login
provides stronger, two-factor authentication than using a username and password.
In Red Hat Enterprise Linux servers and workstations, hardware token login
is not enabled by default and must be enabled in the system settings. |
Rule
Install the opensc Package For Multifactor Authentication
[ref] |
The opensc-pkcs11 package can be installed with the following command:
$ apt-get install opensc-pkcs11
| Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_opensc_installed | References: | disa | CCI-001953, CCI-004046 | ism | 1382, 1384, 1386 | nist | CM-6(a) | os-srg | SRG-OS-000375-GPOS-00160, SRG-OS-000376-GPOS-00161 | stigid | UBTU-22-612015 | stigref | SV-260574r958816_rule |
| |
|
Rule
Install Smart Card Packages For Multifactor Authentication
[ref] | Configure the operating system to implement multifactor authentication by
installing the required package with the following command:
The libpam-pkcs11 package can be installed with the following command:
$ apt-get install libpam-pkcs11
| Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_install_smartcard_packages | References: | disa | CCI-000765, CCI-001953, CCI-001954, CCI-004046 | nist | CM-6(a) | pcidss | Req-8.3 | os-srg | SRG-OS-000105-GPOS-00052, SRG-OS-000375-GPOS-00160, SRG-OS-000375-GPOS-00161, SRG-OS-000377-GPOS-00162 | stigid | UBTU-22-612010 | stigref | SV-260573r986292_rule |
| |
|
Rule
Configure Smart Card Certificate Authority Validation
[ref] | Configure the operating system to do certificate status checking for PKI
authentication. Modify all of the cert_policy lines in
/etc/pam_pkcs11/pam_pkcs11.conf to include ca like so:
cert_policy = ca, ocsp_on, signature;
| Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_smartcard_configure_ca | References: | disa | CCI-000185, CCI-004068 | os-srg | SRG-OS-000066-GPOS-00034, SRG-OS-000384-GPOS-00167 | stigid | UBTU-22-612030 | stigref | SV-260577r986294_rule |
| |
|
Rule
Configure Smart Card Certificate Status Checking
[ref] | Configure the operating system to do certificate status checking for PKI
authentication. Modify all of the cert_policy lines in
/etc/pam_pkcs11/pam_pkcs11.conf to include ocsp_on like so:
cert_policy = ca, ocsp_on, signature;
| Rationale: | 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_smartcard_configure_cert_checking | References: | disa | CCI-004046, CCI-001953, CCI-001954 | os-srg | SRG-OS-000375-GPOS-00160, SRG-OS-000376-GPOS-00161, SRG-OS-000377-GPOS-00162, SRG-OS-000384-GPOS-00167 | stigid | UBTU-22-612025 | stigref | SV-260576r958818_rule |
| |
|
Rule
Configure Smart Card Local Cache of Revocation Data
[ref] | Configure the operating system for PKI-based authentication to use
local revocation data when unable to access the network to obtain it
remotely. Modify all of the cert_policy lines in
/etc/pam_pkcs11/pam_pkcs11.conf to include crl_auto
or crl_offline like so:
cert_policy = ca,signature,ocsp_on,crl_auto;
| Rationale: | Without configuring a local cache of revocation data, there is the
potential to allow access to users who are no longer authorized
(users with revoked certificates). | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_smartcard_configure_crl | References: | | |
|
Rule
Enable Smart Card Logins in PAM
[ref] | 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).
Check that the pam_pkcs11.so option is configured in the
etc/pam.d/common-auth file with the following command:
# grep pam_pkcs11.so /etc/pam.d/common-auth
auth [success=2 default=ignore] pam_pkcs11.so
For general information about enabling smart card authentication, consult
the documentation at:
| Rationale: | Smart card login provides two-factor authentication stronger than
that provided by a username and password combination. Smart cards leverage PKI
(public key infrastructure) in order to provide and verify credentials.
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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_smartcard_pam_enabled | References: | disa | CCI-000765, CCI-000766, CCI-000767, CCI-000768, CCI-000187, CCI-004046, CCI-001953, CCI-001954, CCI-004047 | os-srg | SRG-OS-000068-GPOS-00036, SRG-OS-000105-GPOS-00052, SRG-OS-000106-GPOS-00053, SRG-OS-000107-GPOS-00054, SRG-OS-000108-GPOS-00055, SRG-OS-000375-GPOS-00160, SRG-OS-000375-GPOS-00161, SRG-OS-000375-GPOS-00162 | stigid | UBTU-22-612020 | stigref | SV-260575r986293_rule |
| |
|
Rule
Verify that 'use_mappers' is set to 'pwent' in PAM
[ref] | The operating system must map the authenticated identity to the user or
group account for PKI-based authentication.
Verify that use_mappers is set to pwent in
/etc/pam_pkcs11/pam_pkcs11.conf file with the following command:
$ grep ^use_mappers /etc/pam_pkcs11/pam_pkcs11.conf
use_mappers = pwent
| Rationale: | Without mapping the certificate used to authenticate to the user account,
the ability to determine the identity of the individual user or group will
not be available for forensic analysis. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_verify_use_mappers | References: | | |
|
Rule
Disable Ctrl-Alt-Del Burst Action
[ref] | By default, SystemD will reboot the system if the Ctrl-Alt-Del
key sequence is pressed Ctrl-Alt-Delete more than 7 times in 2 seconds.
To configure the system to ignore the CtrlAltDelBurstAction
setting, add or modify the following to /etc/systemd/system.conf :
CtrlAltDelBurstAction=none
| Rationale: | A locally logged-in user who presses Ctrl-Alt-Del, when at the console,
can reboot the system. If accidentally pressed, as could happen in
the case of mixed OS environment, this can create the risk of short-term
loss of availability of systems due to unintentional reboot. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_disable_ctrlaltdel_burstaction | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000366, CCI-002235 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1), CM-6(a) | nist-csf | PR.AC-4, PR.DS-5 | ospp | FAU_GEN.1.2 | os-srg | SRG-OS-000324-GPOS-00125, SRG-OS-000480-GPOS-00227 | stigid | UBTU-22-211015 | stigref | SV-260469r991589_rule |
| |
|
Rule
Disable Ctrl-Alt-Del Reboot Activation
[ref] | By default, SystemD will reboot the system if the Ctrl-Alt-Del
key sequence is pressed.
To configure the system to ignore the Ctrl-Alt-Del key sequence from the
command line instead of rebooting the system, do either of the following:
ln -sf /dev/null /etc/systemd/system/ctrl-alt-del.target
or
systemctl mask ctrl-alt-del.target
Do not simply delete the /usr/lib/systemd/system/ctrl-alt-del.service file,
as this file may be restored during future system updates. | Rationale: | A locally logged-in user who presses Ctrl-Alt-Del, when at the console,
can reboot the system. If accidentally pressed, as could happen in
the case of mixed OS environment, this can create the risk of short-term
loss of availability of systems due to unintentional reboot. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_disable_ctrlaltdel_reboot | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000366, CCI-002235 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | ospp | FAU_GEN.1.2 | os-srg | SRG-OS-000324-GPOS-00125, SRG-OS-000480-GPOS-00227 | stigid | UBTU-22-211015 | stigref | SV-260469r991589_rule |
| |
|
Group
Protect Accounts by Restricting Password-Based Login
Group contains 4 groups and 9 rules |
[ref]
Conventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the /etc/passwd and
/etc/shadow files. Password-based login is vulnerable to
guessing of weak passwords, and to sniffing and man-in-the-middle
attacks against passwords entered over a network or at an insecure
console. Therefore, mechanisms for accessing accounts by entering
usernames and passwords should be restricted to those which are
operationally necessary. |
Group
Set Account Expiration Parameters
Group contains 2 rules |
[ref]
Accounts can be configured to be automatically disabled
after a certain time period,
meaning that they will require administrator interaction to become usable again.
Expiration of accounts after inactivity can be set for all accounts by default
and also on a per-account basis, such as for accounts that are known to be temporary.
To configure automatic expiration of an account following
the expiration of its password (that is, after the password has expired and not been changed),
run the following command, substituting NUM_DAYS and USER appropriately:
$ sudo chage -I NUM_DAYS USER
Accounts, such as temporary accounts, can also be configured to expire on an explicitly-set date with the
-E option.
The file /etc/default/useradd controls
default settings for all newly-created accounts created with the system's
normal command line utilities. Warning:
This will only apply to newly created accounts |
Rule
Set Account Expiration Following Inactivity
[ref] | To specify the number of days after a password expires (which
signifies inactivity) until an account is permanently disabled, add or correct
the following line in /etc/default/useradd :
INACTIVE=35
If a password is currently on the verge of expiration, then
35
day(s) remain(s) until the account is automatically
disabled. However, if the password will not expire for another 60 days, then 60
days plus 35 day(s) could
elapse until the account would be automatically disabled. See the
useradd man page for more information. | Rationale: | Inactive identifiers pose a risk to systems and applications because attackers may exploit an inactive identifier and potentially obtain undetected access to the system.
Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials.
Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_account_disable_post_pw_expiration | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 3, 5, 7, 8 | cjis | 5.6.2.1.1 | cobit5 | DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.6 | disa | CCI-003628, CCI-003627 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 6.2 | iso27001-2013 | A.12.4.1, A.12.4.3, A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | nist | IA-4(e), AC-2(3), CM-6(a) | nist-csf | DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7 | pcidss | Req-8.1.4 | os-srg | SRG-OS-000118-GPOS-00060 | stigid | UBTU-22-411035 | cis | 5.5.1.4 | pcidss4 | 8.2.6, 8.2 | stigref | SV-260547r986282_rule |
| |
|
Rule
Assign Expiration Date to Temporary Accounts
[ref] | Temporary accounts are established as part of normal account activation
procedures when there is a need for short-term accounts. In the event
temporary accounts are required, configure the system to
terminate them after a documented time period. For every temporary account, run the following command to set an expiration date on
it, substituting USER and YYYY-MM-DD
appropriately:
$ sudo chage -E YYYY-MM-DD USER
YYYY-MM-DD indicates the documented expiration date for the
account. For U.S. Government systems, the operating system must be
configured to automatically terminate these types of accounts after a
period of 72 hours. | Rationale: | If temporary user accounts remain active when no longer needed or for
an excessive period, these accounts may be used to gain unauthorized access.
To mitigate this risk, automated termination of all temporary accounts
must be set upon account creation.
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_account_temp_expire_date | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 3, 5, 7, 8 | cobit5 | DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS06.03 | disa | CCI-000016, CCI-001682 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 6.2 | iso27001-2013 | A.12.4.1, A.12.4.3, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nist | AC-2(2), AC-2(3), CM-6(a) | nist-csf | DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6 | os-srg | SRG-OS-000123-GPOS-00064, SRG-OS-000002-GPOS-00002 | stigid | UBTU-22-411040 | stigref | SV-260548r958364_rule |
| |
|
Group
Set Password Expiration Parameters
Group contains 2 rules |
[ref]
The file /etc/login.defs controls several
password-related settings. Programs such as passwd ,
su , and
login consult /etc/login.defs to determine
behavior with regard to password aging, expiration warnings,
and length. See the man page login.defs(5) for more information.
Users should be forced to change their passwords, in order to
decrease the utility of compromised passwords. However, the need to
change passwords often should be balanced against the risk that
users will reuse or write down passwords if forced to change them
too often. Forcing password changes every 90-360 days, depending on
the environment, is recommended. Set the appropriate value as
PASS_MAX_DAYS and apply it to existing accounts with the
-M flag.
The PASS_MIN_DAYS ( -m ) setting prevents password
changes for 7 days after the first change, to discourage password
cycling. If you use this setting, train users to contact an administrator
for an emergency password change in case a new password becomes
compromised. The PASS_WARN_AGE ( -W ) setting gives
users 7 days of warnings at login time that their passwords are about to expire.
For example, for each existing human user USER, expiration parameters
could be adjusted to a 180 day maximum password age, 7 day minimum password
age, and 7 day warning period with the following command:
$ sudo chage -M 180 -m 7 -W 7 USER
|
Rule
Set Password Maximum Age
[ref] | To specify password maximum age for new accounts,
edit the file /etc/login.defs
and add or correct the following line:
PASS_MAX_DAYS 60
A value of 180 days is sufficient for many environments.
The DoD requirement is 60.
The profile requirement is 60 . | Rationale: | Any password, no matter how complex, can eventually be cracked. Therefore, passwords
need to be changed periodically. If the operating system does not limit the lifetime
of passwords and force users to change their passwords, there is the risk that the
operating system passwords could be compromised.
Setting the password maximum age ensures users are required to
periodically change their passwords. Requiring shorter password lifetimes
increases the risk of users writing down the password in a convenient
location subject to physical compromise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_maximum_age_login_defs | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.1 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.6 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0418, 1055, 1402 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(f), IA-5(1)(d), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.4 | os-srg | SRG-OS-000076-GPOS-00044 | stigid | UBTU-22-411030 | cis | 5.5.1.2 | pcidss4 | 8.3.9, 8.3 | stigref | SV-260546r986281_rule |
| |
|
Rule
Set Password Minimum Age
[ref] | To specify password minimum age for new accounts,
edit the file /etc/login.defs
and add or correct the following line:
PASS_MIN_DAYS 1
A value of 1 day is considered sufficient for many
environments. The DoD requirement is 1.
The profile requirement is 1 . | Rationale: | 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.
Setting the minimum password age protects against users cycling back to a
favorite password after satisfying the password reuse requirement. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_minimum_age_login_defs | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.1.1 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.8 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0418, 1055, 1402 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(f), IA-5(1)(d), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | os-srg | SRG-OS-000075-GPOS-00043 | stigid | UBTU-22-411025 | cis | 5.5.1.1 | stigref | SV-260545r986280_rule |
| |
|
Group
Verify Proper Storage and Existence of Password
Hashes
Group contains 4 rules |
[ref]
By default, password hashes for local accounts are stored
in the second field (colon-separated) in
/etc/shadow . This file should be readable only by
processes running with root credentials, preventing users from
casually accessing others' password hashes and attempting
to crack them.
However, it remains possible to misconfigure the system
and store password hashes
in world-readable files such as /etc/passwd , or
to even store passwords themselves in plaintext on the system.
Using system-provided tools for password change/creation
should allow administrators to avoid such misconfiguration. |
Rule
Ensure sudo group has only necessary members
[ref] | Developers and implementers can increase the assurance in security
functions by employing well-defined security policy models; structured,
disciplined, and rigorous hardware and software development techniques;
and sound system/security engineering principles. Implementation may
include isolation of memory space and libraries.
The Ubuntu operating system restricts access to security functions
through the use of access control mechanisms and by implementing least
privilege capabilities. Warning:
Due to the risk of removing user rights, automated remediation is
not available for this configuration check. | Rationale: | Any users assigned to the sudo group would be granted administrator
access to the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_sudo_group_restricted | References: | | |
|
Rule
Ensure no duplicate UIDs exist
[ref] | Although the useradd program will not let you create a duplicate User ID (UID),
it is possible for an administrator to manually edit the /etc/passwd file
and change the UID field. Users must be assigned unique UIDs for
accountability and to ensure appropriate access protections. Warning:
Due to the risk of removing user accounts or changing user's UIDS,
automated remediation is not available for this configuration check. | Rationale: | Users must be assigned unique UIDs for accountability and to ensure
appropriate access protections. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_no_duplicate_uids | References: | disa | CCI-000764, CCI-000804 | os-srg | SRG-OS-000104-GPOS-00051, SRG-OS-000121-GPOS-00062 | stigid | UBTU-22-411015 | stigref | SV-260543r958482_rule |
| |
|
Rule
Prevent Login to Accounts With Empty Password
[ref] | If an account is configured for password authentication
but does not have an assigned password, it may be possible to log
into the account without authentication. Remove any instances of the
nullok in
/etc/pam.d/common-password
to prevent logins with empty passwords. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
Note that this rule is not applicable for systems running within a
container. Having user with empty password within a container is not
considered a risk, because it should not be possible to directly login into
a container anyway. | Rationale: | If an account has an empty password, anyone could log in and
run commands with the privileges of that account. Accounts with
empty passwords should never be used in operational environments. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_no_empty_passwords | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2 | cobit5 | APO01.06, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.02, DSS06.03, DSS06.10 | cui | 3.1.1, 3.1.5 | disa | CCI-000366 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.18.1.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nist | IA-5(1)(a), IA-5(c), CM-6(a) | nist-csf | PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.DS-5 | ospp | FIA_UAU.1 | pcidss | Req-8.2.3 | os-srg | SRG-OS-000480-GPOS-00227 | stigid | UBTU-22-611060 | pcidss4 | 8.3.1, 8.3 | stigref | SV-260570r991589_rule |
| |
|
Rule
Ensure There Are No Accounts With Blank or Null Passwords
[ref] | Check the "/etc/shadow" file for blank passwords with the
following command:
$ sudo awk -F: '!$2 {print $1}' /etc/shadow
If the command returns any results, this is a finding.
Configure all accounts on the system to have a password or lock
the account with the following commands:
Perform a password reset:
$ sudo passwd [username]
Lock an account:
$ sudo passwd -l [username]
Warning:
Note that this rule is not applicable for systems running within a container. Having user with empty password within a container is not considered a risk, because it should not be possible to directly login into a container anyway. | Rationale: | If an account has an empty password, anyone could log in and
run commands with the privileges of that account. Accounts with
empty passwords should never be used in operational environments. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_no_empty_passwords_etc_shadow | References: | | |
|
Group
Restrict Root Logins
Group contains 1 rule |
[ref]
Direct root logins should be allowed only for emergency use.
In normal situations, the administrator should access the system
via a unique unprivileged account, and then use su or sudo to execute
privileged commands. Discouraging administrators from accessing the
root account directly ensures an audit trail in organizations with
multiple administrators. Locking down the channels through which
root can connect directly also reduces opportunities for
password-guessing against the root account. The login program
uses the file /etc/securetty to determine which interfaces
should allow root logins.
The virtual devices /dev/console
and /dev/tty* represent the system consoles (accessible via
the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default
installation). The default securetty file also contains /dev/vc/* .
These are likely to be deprecated in most environments, but may be retained
for compatibility. Root should also be prohibited from connecting
via network protocols. Other sections of this document
include guidance describing how to prevent root from logging in via SSH. |
Rule
Direct root Logins Are Not Allowed
[ref] | Configure the operating system to prevent direct logins to the
root account by performing the following operations:
$ sudo passwd -l root
| Rationale: | Disabling direct root logins ensures proper accountability and
multifactor authentication to privileged accounts. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_prevent_direct_root_logins | References: | | |
|
Group
Secure Session Configuration Files for Login Accounts
Group contains 1 group and 3 rules |
[ref]
When a user logs into a Unix account, the system
configures the user's session by reading a number of files. Many of
these files are located in the user's home directory, and may have
weak permissions as a result of user error or misconfiguration. If
an attacker can modify or even read certain types of account
configuration information, they can often gain full access to the
affected user's account. Therefore, it is important to test and
correct configuration file permissions for interactive accounts,
particularly those of privileged users such as root or system
administrators. |
Group
Ensure that Users Have Sensible Umask Values
Group contains 1 rule |
[ref]
The umask setting controls the default permissions
for the creation of new files.
With a default umask setting of 077, files and directories
created by users will not be readable by any other user on the
system. Users who wish to make specific files group- or
world-readable can accomplish this by using the chmod command.
Additionally, users can make all their files readable to their
group by default by setting a umask of 027 in their shell
configuration files. If default per-user groups exist (that is, if
every user has a default group whose name is the same as that
user's username and whose only member is the user), then it may
even be safe for users to select a umask of 007, making it very
easy to intentionally share files with groups of which the user is
a member.
|
Rule
Ensure the Default Umask is Set Correctly in login.defs
[ref] | To ensure the default umask controlled by /etc/login.defs is set properly,
add or correct the UMASK setting in /etc/login.defs to read as follows:
UMASK 077
| Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read and
written to by unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_umask_etc_login_defs | References: | cis-csc | 11, 18, 3, 9 | cobit5 | APO13.01, BAI03.01, BAI03.02, BAI03.03, BAI10.01, BAI10.02, BAI10.03, BAI10.05 | disa | CCI-000366 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 7.6 | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.1.1, A.14.2.1, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.5, A.6.1.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | AC-6(1), CM-6(a) | nist-csf | PR.IP-1, PR.IP-2 | os-srg | SRG-OS-000480-GPOS-00228 | stigid | UBTU-22-412035 | cis | 5.5.4 | anssi | R36 | stigref | SV-260555r991590_rule |
| |
|
Rule
Limit the Number of Concurrent Login Sessions Allowed Per User
[ref] | Limiting the number of allowed users and sessions per user can limit risks related to Denial of
Service attacks. This addresses concurrent sessions for a single account and does not address
concurrent sessions by a single user via multiple accounts. To set the number of concurrent
sessions per user add the following line in /etc/security/limits.conf or
a file under /etc/security/limits.d/ :
* hard maxlogins 10
| Rationale: | Limiting simultaneous user logins can insulate the system from denial of service
problems caused by excessive logins. Automated login processes operating improperly or
maliciously may result in an exceptional number of simultaneous login sessions. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_max_concurrent_login_sessions | References: | cis-csc | 14, 15, 18, 9 | cjis | 5.5.2.2 | cobit5 | DSS01.05, DSS05.02 | disa | CCI-000054 | isa-62443-2009 | 4.3.3.4 | isa-62443-2013 | SR 3.1, SR 3.8 | iso27001-2013 | A.13.1.1, A.13.1.3, A.13.2.1, A.14.1.2, A.14.1.3 | nerc-cip | CIP-007-3 R5.1, CIP-007-3 R5.1.2 | nist | AC-10, CM-6(a) | nist-csf | PR.AC-5 | os-srg | SRG-OS-000027-GPOS-00008 | stigid | UBTU-22-412020 | stigref | SV-260552r958398_rule |
| |
|
Rule
Set Interactive Session Timeout
[ref] | Setting the TMOUT option in /etc/profile ensures that
all user sessions will terminate based on inactivity.
The value of TMOUT should be exported and read only.
The TMOUT
setting in a file loaded by /etc/profile , e.g.
/etc/profile.d/tmout.sh should read as follows:
TMOUT=900
readonly TMOUT
export TMOUT | Rationale: | Terminating an idle session within a short time period reduces
the window of opportunity for unauthorized personnel to take control of a
management session enabled on the console or console port that has been
left unattended. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_tmout | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.11 | disa | CCI-000057, CCI-001133 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nerc-cip | CIP-004-6 R2.2.3, CIP-007-3 R5.1, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | nist | AC-12, SC-10, AC-2(5), CM-6(a) | nist-csf | PR.AC-7 | os-srg | SRG-OS-000163-GPOS-00072, SRG-OS-000029-GPOS-00010 | stigid | UBTU-22-412030 | cis | 5.5.5 | anssi | R32 | pcidss4 | 8.6.1, 8.6 | stigref | SV-260554r958636_rule |
| |
|
Group
AppArmor
Group contains 2 rules |
[ref]
Many security vulnerabilities result from bugs in trusted programs. A trusted
program runs with privileges that attackers want to possess. The program fails
to keep that trust if there is a bug in the program that allows the attacker to
acquire said privilege.
AppArmor® is an application security solution designed specifically to apply
privilege confinement to suspect programs. AppArmor allows the administrator to
specify the domain of activities the program can perform by developing a
security profile. A security profile is a listing of files that the program may
access and the operations the program may perform. AppArmor secures
applications by enforcing good application behavior without relying on attack
signatures, so it can prevent attacks even if previously unknown
vulnerabilities are being exploited. |
Rule
Ensure AppArmor is installed
[ref] | AppArmor provide Mandatory Access Controls. | Rationale: | Without a Mandatory Access Control system installed only the default
Discretionary Access Control system will be available. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_apparmor_installed | References: | disa | CCI-001764, CCI-001774, CCI-002165, CCI-002235 | os-srg | SRG-OS-000368-GPOS-00154, SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000312-GPOS-00124, SRG-OS-000324-GPOS-00125, SRG-OS-000370-GPOS-00155 | stigid | UBTU-22-431010 | cis | 1.6.1.1 | anssi | R45 | stigref | SV-260556r958702_rule |
| |
|
Rule
Ensure AppArmor is Active and Configured
[ref] | Verify that the Apparmor tool is configured to
control whitelisted applications and user home directory access
control.
The apparmor service can be enabled with the following command:
$ sudo systemctl enable apparmor.service
| Rationale: | Using a whitelist provides a configuration management method for allowing
the execution of only authorized software. Using only authorized software
decreases risk by limiting the number of potential vulnerabilities.
The organization must identify authorized software programs and permit
execution of authorized software by adding each authorized program to the
"pam_apparmor" exception policy. The process used to identify software
programs that are authorized to execute on organizational information
systems is commonly referred to as whitelisting.
Verification of whitelisted software occurs prior to execution or at system
startup.
Users' home directories/folders may contain information of a sensitive
nature. Nonprivileged users should coordinate any sharing of information
with a System Administrator (SA) through shared resources.
Apparmor can confine users to their home directory, not allowing them to
make any changes outside of their own home directories. Confining users to
their home directory will minimize the risk of sharing information. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_apparmor_configured | References: | disa | CCI-001764, CCI-001774, CCI-002165, CCI-002233, CCI-002235 | nist | AC-3(4), AC-6(8), AC-6(10), CM-7(5)(b), CM-7(2), SC-7(21), CM-6(a) | os-srg | SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000312-GPOS-00124, SRG-OS-000324-GPOS-00125, SRG-OS-000326-GPOS-00126, SRG-OS-000370-GPOS-00155, SRG-OS-000480-GPOS-00230, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00231, SRG-OS-000480-GPOS-00232 | stigid | UBTU-22-431015 | anssi | R45 | stigref | SV-260557r958804_rule |
| |
|
Group
GRUB2 bootloader configuration
Group contains 2 groups and 2 rules |
[ref]
During the boot process, the boot loader is
responsible for starting the execution of the kernel and passing
options to it. The boot loader allows for the selection of
different kernels - possibly on different partitions or media.
The default Ubuntu 22.04 boot loader for x86 systems is called GRUB2.
Options it can pass to the kernel include single-user mode, which
provides root access without any authentication, and the ability to
disable SELinux. To prevent local users from modifying the boot
parameters and endangering security, protect the boot loader configuration
with a password and ensure its configuration file's permissions
are set properly. |
Group
Non-UEFI GRUB2 bootloader configuration
Group contains 1 rule |
[ref]
Non-UEFI GRUB2 bootloader configuration |
Rule
Set Boot Loader Password in grub2
[ref] | The grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
Since plaintext passwords are a security risk, generate a hash for the password
by running the following command:
# grub2-mkpasswd-pbkdf2
When prompted, enter the password that was selected.
Using the hash from the output, modify the /etc/grub.d/40_custom
file with the following content:
set superusers="boot"
password_pbkdf2 boot grub.pbkdf2.sha512.VeryLongString
NOTE: the bootloader superuser account and password MUST differ from the
root account and password.
Once the superuser password has been added,
update the
grub.cfg file by running:
update-grub
Warning:
To prevent hard-coded passwords, automatic remediation of this control is not available. Remediation
must be automated as a component of machine provisioning, or followed manually as outlined above.
Also, do NOT manually add the superuser account and password to the
grub.cfg file as the grub2-mkconfig command overwrites this file. | Rationale: | Password protection on the boot loader configuration ensures
users with physical access cannot trivially alter
important bootloader settings. These include which kernel to use,
and whether to enter single-user mode. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_password | References: | cis-csc | 1, 11, 12, 14, 15, 16, 18, 3, 5 | cobit5 | DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.06, DSS06.10 | cui | 3.4.5 | disa | CCI-000213 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7 | iso27001-2013 | A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nist | CM-6(a) | nist-csf | PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.PT-3 | os-srg | SRG-OS-000080-GPOS-00048 | stigid | UBTU-22-212010 | cis | 1.4.1 | anssi | R5 | stigref | SV-260470r958472_rule |
| |
|
Group
UEFI GRUB2 bootloader configuration
Group contains 1 rule |
[ref]
UEFI GRUB2 bootloader configuration Warning:
UEFI generally uses vfat file systems, which does not support Unix-style permissions
managed by chmod command. In this case, in order to change file permissions for files
within /boot/efi it is necessary to update the mount options in /etc/fstab file and
reboot the system. |
Rule
Set the UEFI Boot Loader Password
[ref] | The grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
Since plaintext passwords are a security risk, generate a hash for the password
by running the following command:
# grub2-mkpasswd-pbkdf2
When prompted, enter the password that was selected.
Using the hash from the output, modify the /etc/grub.d/40_custom
file with the following content:
set superusers="boot"
password_pbkdf2 boot grub.pbkdf2.sha512.VeryLongString
NOTE: the bootloader superuser account and password MUST differ from the
root account and password.
Once the superuser password has been added,
update the
grub.cfg file by running:
update-grub
Warning:
To prevent hard-coded passwords, automatic remediation of this control is not available. Remediation
must be automated as a component of machine provisioning, or followed manually as outlined above.
Also, do NOT manually add the superuser account and password to the
grub.cfg file as the grub2-mkconfig command overwrites this file. | Rationale: | Password protection on the boot loader configuration ensures
users with physical access cannot trivially alter
important bootloader settings. These include which kernel to use,
and whether to enter single-user mode. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_uefi_password | References: | cis-csc | 11, 12, 14, 15, 16, 18, 3, 5 | cobit5 | DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.03, DSS06.06 | cui | 3.4.5 | disa | CCI-000213 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7 | iso27001-2013 | A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a) | nist-csf | PR.AC-4, PR.AC-6, PR.PT-3 | ospp | FIA_UAU.1 | os-srg | SRG-OS-000080-GPOS-00048 | stigid | UBTU-22-212010 | cis | 1.4.1 | anssi | R5 | stigref | SV-260470r958472_rule |
| |
|
Group
Configure Syslog
Group contains 2 groups and 12 rules |
[ref]
The syslog service has been the default Unix logging mechanism for
many years. It has a number of downsides, including inconsistent log format,
lack of authentication for received messages, and lack of authentication,
encryption, or reliable transport for messages sent over a network. However,
due to its long history, syslog is a de facto standard which is supported by
almost all Unix applications.
In Ubuntu 22.04, rsyslog has replaced ksyslogd as the
syslog daemon of choice, and it includes some additional security features
such as reliable, connection-oriented (i.e. TCP) transmission of logs, the
option to log to database formats, and the encryption of log data en route to
a central logging server.
This section discusses how to configure rsyslog for
best effect, and how to use tools provided with the system to maintain and
monitor logs. |
Group
Ensure Proper Configuration of Log Files
Group contains 1 rule |
[ref]
The file /etc/rsyslog.conf controls where log message are written.
These are controlled by lines called rules, which consist of a
selector and an action.
These rules are often customized depending on the role of the system, the
requirements of the environment, and whatever may enable
the administrator to most effectively make use of log data.
The default rules in Ubuntu 22.04 are:
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* -/var/log/maillog
cron.* /var/log/cron
*.emerg *
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log
See the man page rsyslog.conf(5) for more information.
Note that the rsyslog daemon can be configured to use a timestamp format that
some log processing programs may not understand. If this occurs,
edit the file /etc/rsyslog.conf and add or edit the following line:
$ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
|
Rule
Ensure remote access methods are monitored in Rsyslog
[ref] | Logging of remote access methods must be implemented to help identify cyber
attacks and ensure ongoing compliance with remote access policies are being
audited and upheld. An examples of a remote access method is the use of the
Remote Desktop Protocol (RDP) from an external, non-organization controlled
network. The /etc/rsyslog.conf or
/etc/rsyslog.d/*.conf file should contain a match for the following
selectors: auth.* , authpriv.* , and daemon.* . If
not, use the following as an example configuration:
auth.*;authpriv.* /var/log/secure
daemon.* /var/log/messages
| Rationale: | Logging remote access methods can be used to trace the decrease the risks
associated with remote user access management. It can also be used to spot
cyber attacks and ensure ongoing compliance with organizational policies
surrounding the use of remote access methods. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_remote_access_monitoring | References: | | |
|
Group
systemd-journald
Group contains 9 rules |
[ref]
systemd-journald is a system service that collects and stores
logging data. It creates and maintains structured, indexed
journals based on logging information that is received from a
variety of sources.
For more information on systemd-journald and additional systemd-journald configuration options, see
https://systemd.io/. |
Rule
Verify group-owner of system journal directories
[ref] | Verify the /run/log/journal and /var/log/journal directories are group-owned by
"systemd-journal" by using the following command:
$ sudo find /run/log/journal /var/log/journal -type d -exec stat -c "%n %G" {} \;
If any output returned is not owned by "systemd-journal", this is a finding. | Rationale: | Only authorized personnel should be aware of errors and the details of the errors.
Error messages are an indicator of an organization's operational state or can identify
the operating system or platform. Additionally, personally identifiable information
(PII) and operational information must not be revealed through error messages to
unauthorized personnel or their designated representatives. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dir_groupowner_system_journal | References: | | |
|
Rule
Verify owner of system journal directories
[ref] | Verify the /run/log/journal and /var/log/journal directories are owned by
"root" by using the following command:
$ sudo find /run/log/journal /var/log/journal -type d -exec stat -c "%n %U" {} \;
If any output returned is not owned by "root", this is a finding. | Rationale: | Only authorized personnel should be aware of errors and the details of the errors.
Error messages are an indicator of an organization's operational state or can identify
the operating system or platform. Additionally, personally identifiable information
(PII) and operational information must not be revealed through error messages to
unauthorized personnel or their designated representatives. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dir_owner_system_journal | References: | | |
|
Rule
Verify Permissions on the system journal directories
[ref] | Verify the /run/log/journal and /var/log/journal directories have
permissions set to "2750" or less permissive by using the following command:
$ sudo find /run/log/journal /var/log/journal -type d -exec stat -c "%n %a" {} \;
If any output returned has a permission set greater than "2750", this is a finding. | Rationale: | Any operating system providing too much information in error messages risks
compromising the data and security of the structure, and content of error messages
needs to be carefully considered by the organization. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dir_permissions_system_journal | References: | | |
|
Rule
Verify Groupowner on the journalctl command
[ref] | Verify that the "journalctl" command is group-owned by "root" by
using the following command:
$ sudo find /usr/bin/journalctl -exec stat -c "%n %G" {} \;
If any output returned is not owned by "root", this is a finding. | Rationale: | Only authorized personnel should be aware of errors and the details of the errors.
Error messages are an indicator of an organization's operational state or can
identify the operating system or platform. Additionally, personally identifiable
information (PII) and operational information must not be revealed through error
messages to unauthorized personnel or their designated representatives. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_journalctl | References: | | |
|
Rule
Verify Group Who Owns the system journal
[ref] | Verify the /run/log/journal and /var/log/journal files are group-owned by
"systemd-journal" by using the following command:
$ sudo find /run/log/journal /var/log/journal -type f -exec stat -c "%n %G" {} \;
If any output returned is not group-owned by "systemd-journal", this is a finding. | Rationale: | Only authorized personnel should be aware of errors and the details of the errors.
Error messages are an indicator of an organization's operational state or can
identify the operating system or platform. Additionally, personally identifiable
information (PII) and operational information must not be revealed through error
messages to unauthorized personnel or their designated representatives. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_system_journal | References: | | |
|
Rule
Verify Owner on the journalctl Command
[ref] | Verify that the "journalctl" command is owned by "root" by
using the following command:
$ sudo find /usr/bin/journalctl -exec stat -c "%n %U" {} \;
If any output returned is not owned by "root", this is a finding. | Rationale: | Only authorized personnel should be aware of errors and the details of the errors.
Error messages are an indicator of an organization's operational state or can
identify the operating system or platform. Additionally, personally identifiable
information (PII) and operational information must not be revealed through error
messages to unauthorized personnel or their designated representatives. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_journalctl | References: | | |
|
Rule
Verify Owner on the system journal
[ref] | Verify the /run/log/journal and /var/log/journal files are owned by
"root" by using the following command:
$ sudo find /run/log/journal /var/log/journal -type f -exec stat -c "%n %U" {} \;
If any output returned is not owned by "root", this is a finding. | Rationale: | Only authorized personnel should be aware of errors and the details of the errors.
Error messages are an indicator of an organization's operational state or can
identify the operating system or platform. Additionally, personally identifiable
information (PII) and operational information must not be revealed through error
messages to unauthorized personnel or their designated representatives. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_system_journal | References: | | |
|
Rule
Verify Permissions on the journal command
[ref] | Verify that the "journalctl" command has a permission set of "740" by
using the following command:
$ sudo find /usr/bin/journalctl -exec stat -c "%n %a" {} \;
If "journalctl" is not set to "740", this is a finding. | Rationale: | Any operating system providing too much information in error messages risks
compromising the data and security of the structure, and content of error messages
needs to be carefully considered by the organization. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_journalctl | References: | | |
|
Rule
Verify Permissions on the system journal
[ref] | Verify all files in the /run/log/journal and /var/log/journal directories have
permissions set to "640" or less permissive by using the following command:
$ sudo find /run/log/journal /var/log/journal -type f -exec stat -c "%n %a" {} \;
If any output returned has a permission set greater than "640", this is a finding. | Rationale: | Any operating system providing too much information in error messages risks
compromising the data and security of the structure, and content of error messages
needs to be carefully considered by the organization. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_system_journal | References: | | |
|
Rule
Enable rsyslog Service
[ref] | The rsyslog service provides syslog-style logging by default on Ubuntu 22.04.
The rsyslog service can be enabled with the following command:
$ sudo systemctl enable rsyslog.service
| Rationale: | The rsyslog service must be running in order to provide
logging services, which are essential to system administration. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_service_rsyslog_enabled | References: | cis-csc | 1, 12, 13, 14, 15, 16, 2, 3, 5, 6, 7, 8, 9 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO13.01, BAI03.05, BAI04.04, DSS01.03, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | disa | CCI-000366 | hipaa | 164.312(a)(2)(ii) | isa-62443-2009 | 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, SR 6.2, SR 7.1, SR 7.2 | iso27001-2013 | A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.14.2.7, A.15.2.1, A.15.2.2, A.17.2.1 | nist | CM-6(a), AU-4(1) | nist-csf | DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.DS-4, PR.PT-1 | os-srg | SRG-OS-000480-GPOS-00227 | stigid | UBTU-22-652010 | cis | 4.2.2.2 | stigref | SV-260588r991562_rule |
| |
|
Rule
Ensure real-time clock is set to UTC
[ref] | Ensure that the system real-time clock (RTC) is set to Coordinated Universal Time (UTC). | Rationale: | If time stamps are not consistently applied and there is no common
time reference, it is difficult to perform forensic analysis.
Time stamps generated by the operating system include date and time.
Time is commonly expressed in UTC, a modern continuation of GMT, or
local time with an offset from UTC. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_rtc_utc_configuration | References: | | |
|
Group
Network Configuration and Firewalls
Group contains 6 groups and 8 rules |
[ref]
Most systems must be connected to a network of some
sort, and this brings with it the substantial risk of network
attack. This section discusses the security impact of decisions
about networking which must be made when configuring a system.
This section also discusses firewalls, network access
controls, and other network security frameworks, which allow
system-level rules to be written that can limit an attackers' ability
to connect to your system. These rules can specify that network
traffic should be allowed or denied from certain IP addresses,
hosts, and networks. The rules can also specify which of the
system's network services are available to particular hosts or
networks. |
Group
Kernel Parameters Which Affect Networking
Group contains 1 group and 1 rule |
[ref]
The sysctl utility is used to set
parameters which affect the operation of the Linux kernel. Kernel parameters
which affect networking and have security implications are described here. |
Group
Network Related Kernel Runtime Parameters for Hosts and Routers
Group contains 1 rule |
[ref]
Certain kernel parameters should be set for systems which are
acting as either hosts or routers to improve the system's ability defend
against certain types of IPv4 protocol attacks. |
Rule
Enable Kernel Parameter to Use TCP Syncookies on Network Interfaces
[ref] | To set the runtime status of the net.ipv4.tcp_syncookies kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.tcp_syncookies=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv4.tcp_syncookies = 1
| Rationale: | A TCP SYN flood attack can cause a denial of service by filling a
system's TCP connection table with connections in the SYN_RCVD state.
Syncookies can be used to track a connection when a subsequent ACK is received,
verifying the initiator is attempting a valid connection and is not a flood
source. This feature is activated when a flood condition is detected, and
enables the system to continue servicing valid connection requests. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_tcp_syncookies | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9 | cjis | 5.10.1.1 | cobit5 | APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02 | cui | 3.1.20 | disa | CCI-001095, CCI-000366, CCI-002385 | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.4.3.3 | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-7(a), CM-7(b), SC-5(1), SC-5(2), SC-5(3)(a), CM-6(a) | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.PT-4 | pcidss | Req-1.4.1 | os-srg | SRG-OS-000480-GPOS-00227, SRG-OS-000420-GPOS-00186, SRG-OS-000142-GPOS-00071 | stigid | UBTU-22-253010 | cis | 3.3.8 | anssi | R12 | pcidss4 | 1.4.3, 1.4 | stigref | SV-260522r958528_rule |
| |
|
Group
Uncomplicated Firewall (ufw)
Group contains 5 rules |
[ref]
The Linux kernel in Ubuntu provides a packet filtering system called
netfilter, and the traditional interface for manipulating netfilter are
the iptables suite of commands. iptables provide a complete firewall
solution that is both highly configurable and highly flexible.
Becoming proficient in iptables takes time, and getting started with
netfilter firewalling using only iptables can be a daunting task. As a
result, many frontends for iptables have been created over the years,
each trying to achieve a different result and targeting a different
audience.
The Uncomplicated Firewall (ufw) is a frontend for iptables and is
particularly well-suited for host-based firewalls. ufw provides a
framework for managing netfilter, as well as a command-line interface
for manipulating the firewall. ufw aims to provide an easy to use
interface for people unfamiliar with firewall concepts, while at the
same time simplifies complicated iptables commands to help an
administrator who knows what he or she is doing. ufw is an upstream
for other distributions and graphical frontends. |
Rule
Install ufw Package
[ref] | The ufw package can be installed with the following command:
$ apt-get install ufw
| Rationale: | ufw controls the Linux kernel network packet filtering
code. ufw allows system operators to set up firewalls and IP
masquerading, etc.
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_ufw_installed | References: | | |
|
Rule
Verify ufw Enabled
[ref] |
The ufw service can be enabled with the following command:
$ sudo systemctl enable ufw.service
| Rationale: | The ufw service must be enabled and running in order for ufw to protect the system | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_service_ufw_enabled | References: | | |
|
Rule
Verify ufw Active
[ref] | Verify the ufw is enabled on the system with the following command:
# sudo ufw status
If the above command returns the status as "inactive" or any type of error, this is a finding. | Rationale: | 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, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
Ubuntu 22.04 LTS 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_check_ufw_active | References: | | |
|
Rule
Only Allow Authorized Network Services in ufw
[ref] | Check the firewall configuration for any unnecessary or prohibited
functions, ports, protocols, and/or services by running the following
command:
$ sudo ufw show raw
Chain OUTPUT (policy ACCEPT)
target prot opt sources destination
Chain INPUT (policy ACCEPT 1 packets, 40 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Ask the System Administrator for the site or program PPSM CLSA. Verify
the services allowed by the firewall match the PPSM CLSA. | Rationale: | To prevent unauthorized connection of devices, unauthorized transfer of
information, or unauthorized tunneling (i.e., embedding of data types
within data types), organizations must disable or restrict unused or
unnecessary physical and logical ports/protocols on information systems.
Operating systems are capable of providing a wide variety of functions
and services. Some of the functions and services provided by default
may not be necessary to support essential organizational operations.
Additionally, it is sometimes convenient to provide multiple services
from a single component (e.g., VPN and IPS); however, doing so
increases risk over limiting the services provided by any one component.
To support the requirements and principles of least functionality, the
operating system must support the organizational requirements, providing
only essential capabilities and limiting the use of ports, protocols,
and/or services to only those required, authorized, and approved to
conduct official business or to address authorized quality of life
issues. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_ufw_only_required_services | References: | | |
|
Rule
ufw Must rate-limit network interfaces
[ref] | The operating system must configure the uncomplicated firewall to
rate-limit impacted network interfaces.
Check all the services listening to the ports with the following
command:
$ sudo ss -l46ut
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
tcp LISTEN 0 128 [::]:ssh [::]:*
For each entry, verify that the ufw is configured to rate limit the
service ports with the following command:
$ sudo ufw status
If any port with a state of "LISTEN" is not marked with the "LIMIT"
action, run the following command, replacing "service" with the
service that needs to be rate limited:
$ sudo ufw limit "service"
Rate-limiting can also be done on an interface. An example of adding
a rate-limit on the eth0 interface follows:
$ sudo ufw limit in on eth0
| Rationale: | This requirement addresses the configuration of the operating system to
mitigate the impact of DoS attacks that have occurred or are ongoing on
system availability. For each system, known and potential DoS attacks
must be identified and solutions for each type implemented. A variety
of technologies exist to limit or, in some cases, eliminate the effects
of DoS attacks (e.g., limiting processes or establishing memory
partitions). Employing increased capacity and bandwidth, combined with
service redundancy, may reduce the susceptibility to some DoS attacks. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_ufw_rate_limit | References: | | |
|
Group
Wireless Networking
Group contains 1 group and 1 rule |
[ref]
Wireless networking, such as 802.11
(WiFi) and Bluetooth, can present a security risk to sensitive or
classified systems and networks. Wireless networking hardware is
much more likely to be included in laptop or portable systems than
in desktops or servers.
Removal of hardware provides the greatest assurance that the wireless
capability remains disabled. Acquisition policies often include provisions to
prevent the purchase of equipment that will be used in sensitive spaces and
includes wireless capabilities. If it is impractical to remove the wireless
hardware, and policy permits the device to enter sensitive spaces as long
as wireless is disabled, efforts should instead focus on disabling wireless capability
via software. |
Group
Disable Wireless Through Software Configuration
Group contains 1 rule |
[ref]
If it is impossible to remove the wireless hardware
from the device in question, disable as much of it as possible
through software. The following methods can disable software
support for wireless networking, but note that these methods do not
prevent malicious software or careless users from re-activating the
devices. |
Rule
Deactivate Wireless Network Interfaces
[ref] | Deactivating wireless network interfaces should prevent normal usage of the wireless
capability.
Verify that there are no wireless interfaces configured on the system
with the following command:
$ ls -L -d /sys/class/net/*/wireless | xargs dirname | xargs basename -a
| Rationale: | The use of wireless networking can introduce many different attack vectors into
the organization's network. Common attack vectors such as malicious association
and ad hoc networks will allow an attacker to spoof a wireless access point
(AP), allowing validated systems to connect to the malicious AP and enabling the
attacker to monitor and record network traffic. These malicious APs can also
serve to create a man-in-the-middle attack or be used to create a denial of
service to valid network resources. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_wireless_disable_interfaces | References: | cis-csc | 11, 12, 14, 15, 3, 8, 9 | cobit5 | APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.04, DSS05.02, DSS05.03, DSS05.05, DSS06.06 | cui | 3.1.16 | disa | CCI-001443, CCI-001444, CCI-002421, CCI-002418 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | ism | 1315, 1319 | iso27001-2013 | A.11.2.6, A.12.1.2, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.2.1, A.6.2.2, A.9.1.2 | nist | AC-18(a), AC-18(3), CM-7(a), CM-7(b), CM-6(a), MP-7 | nist-csf | PR.AC-3, PR.IP-1, PR.PT-3, PR.PT-4 | pcidss | Req-1.3.3 | os-srg | SRG-OS-000299-GPOS-00117, SRG-OS-000300-GPOS-00118, SRG-OS-000424-GPOS-00188, SRG-OS-000481-GPOS-000481 | stigid | UBTU-22-291015 | cis | 3.1.2 | pcidss4 | 1.3.3, 1.3 | stigref | SV-260541r958358_rule |
| |
|
Group
Transport Layer Security Support
Group contains 1 rule |
|
Rule
Only Allow DoD PKI-established CAs
[ref] | The operating system must only allow the use of DoD PKI-established
certificate authorities for verification of the establishment of
protected sessions. | Rationale: | Untrusted Certificate Authorities (CA) can issue certificates, but they
may be issued by organizations or individuals that seek to compromise
DoD systems or by organizations with insufficient security controls. If
the CA used for verifying the certificate is not a DoD-approved CA,
trust of this CA has not been established.
The DoD will only accept PKI-certificates obtained from a DoD-approved
internal or external certificate authority. Reliance on CAs for the
establishment of secure sessions includes, for example, the use of
SSL/TLS certificates. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_only_allow_dod_certs | References: | | |
|
Group
File Permissions and Masks
Group contains 7 groups and 28 rules |
[ref]
Traditional Unix security relies heavily on file and
directory permissions to prevent unauthorized users from reading or
modifying files to which they should not have access.
Several of the commands in this section search filesystems
for files or directories with certain characteristics, and are
intended to be run on every local partition on a given system.
When the variable PART appears in one of the commands below,
it means that the command is intended to be run repeatedly, with the
name of each local partition substituted for PART in turn.
The following command prints a list of all xfs partitions on the local
system, which is the default filesystem for Ubuntu 22.04
installations:
$ mount -t xfs | awk '{print $3}'
For any systems that use a different
local filesystem type, modify this command as appropriate. |
Group
Verify Permissions on Important Files and
Directories
Group contains 2 groups and 24 rules |
[ref]
Permissions for many files on a system must be set
restrictively to ensure sensitive information is properly protected.
This section discusses important
permission restrictions which can be verified
to ensure that no harmful discrepancies have
arisen. |
Group
Verify Permissions on Files within /var/log Directory
Group contains 6 rules |
[ref]
The /var/log directory contains files with logs of error
messages in the system and should only be accessed by authorized
personnel. |
Rule
Verify Group Who Owns /var/log Directory
[ref] | To properly set the group owner of /var/log , run the command: $ sudo chgrp syslog /var/log
| Rationale: | The /var/log directory contains files with logs of error
messages in the system and should only be accessed by authorized
personnel. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_var_log | References: | | |
|
Rule
Verify Group Who Owns /var/log/syslog File
[ref] | To properly set the group owner of /var/log/syslog , run the command: $ sudo chgrp adm /var/log/syslog
| Rationale: | The /var/log/syslog file contains logs of error messages in
the system and should only be accessed by authorized personnel. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_var_log_syslog | References: | | |
|
Rule
Verify User Who Owns /var/log Directory
[ref] | To properly set the owner of /var/log , run the command: $ sudo chown root /var/log
| Rationale: | The /var/log directory contains files with logs of error
messages in the system and should only be accessed by authorized
personnel. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_var_log | References: | | |
|
Rule
Verify User Who Owns /var/log/syslog File
[ref] | To properly set the owner of /var/log/syslog , run the command: $ sudo chown syslog /var/log/syslog
| Rationale: | The /var/log/syslog file contains logs of error messages in
the system and should only be accessed by authorized personnel. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_var_log_syslog | References: | | |
|
Rule
Verify Permissions on /var/log Directory
[ref] |
To properly set the permissions of /var/log , run the command:
$ sudo chmod 0755 /var/log
| Rationale: | The /var/log directory contains files with logs of error
messages in the system and should only be accessed by authorized
personnel. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_var_log | References: | | |
|
Rule
Verify Permissions on /var/log/syslog File
[ref] |
To properly set the permissions of /var/log/syslog , run the command:
$ sudo chmod 0640 /var/log/syslog
| Rationale: | The /var/log/syslog file contains logs of error messages in
the system and should only be accessed by authorized personnel. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_var_log_syslog | References: | | |
|
Group
Verify File Permissions Within Some Important Directories
Group contains 13 rules |
[ref]
Some directories contain files whose confidentiality or integrity
is notably important and may also be susceptible to misconfiguration over time, particularly if
unpackaged software is installed. As such,
an argument exists to verify that files' permissions within these directories remain
configured correctly and restrictively. |
Rule
Verify that Shared Library Directories Have Root Group Ownership
[ref] | System-wide shared library files, which are linked to executables
during process load time or run time, are stored in the following directories
by default:
/lib
/lib64
/usr/lib
/usr/lib64
Kernel modules, which can be added to the kernel during runtime, are also
stored in /lib/modules . All files in these directories should be
group-owned by the root user. If the directories, is found to be owned
by a user other than root correct its
ownership with the following command:
$ sudo chgrp root DIR
| Rationale: | Files from shared library directories are loaded into the address
space of processes (including privileged ones) or of the kernel itself at
runtime. Proper ownership of library directories is necessary to protect
the integrity of the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dir_group_ownership_library_dirs | References: | | |
|
Rule
Verify that system commands directories are group owned by root
[ref] | System commands files are stored in the following directories by default:
/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
All these directories should be owned by the root group.
If the directory is found to be owned by a group other than root correct
its ownership with the following command:
$ sudo chgrp root DIR
| Rationale: | If the operating system allows any user to make changes to software
libraries, then those changes might be implemented without undergoing the
appropriate testing and approvals that are part of a robust change management
process.
This requirement applies to operating systems with software libraries
that are accessible and configurable, as in the case of interpreted languages.
Software libraries also include privileged programs which execute with
escalated privileges. Only qualified and authorized individuals must be
allowed to obtain access to information system components for purposes
of initiating changes, including upgrades and modifications. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dir_groupownership_binary_dirs | References: | | |
|
Rule
Verify that System Executable Have Root Ownership
[ref] | /bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
All these directories should be owned by the root user.
If any directory DIR in these directories is found
to be owned by a user other than root, correct its ownership with the
following command:
$ sudo chown root DIR
| Rationale: | System binaries are executed by privileged users as well as system services,
and restrictive permissions are necessary to ensure that their
execution of these programs cannot be co-opted. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dir_ownership_binary_dirs | References: | | |
|
Rule
Verify that Shared Library Directories Have Root Ownership
[ref] | System-wide shared library files, which are linked to executables
during process load time or run time, are stored in the following directories
by default:
/lib
/lib64
/usr/lib
/usr/lib64
Kernel modules, which can be added to the kernel during runtime, are also
stored in /lib/modules . All files in these directories should be
owned by the root user. If the directories, is found to be owned
by a user other than root correct its
ownership with the following command:
$ sudo chown root DIR
| Rationale: | Files from shared library directories are loaded into the address
space of processes (including privileged ones) or of the kernel itself at
runtime. Proper ownership of library directories is necessary to protect
the integrity of the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dir_ownership_library_dirs | References: | | |
|
Rule
Verify that System Executable Directories Have Restrictive Permissions
[ref] | System executables are stored in the following directories by default:
/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
These directories should not be group-writable or world-writable.
If any directory DIR in these directories is found to be
group-writable or world-writable, correct its permission with the
following command:
$ sudo chmod go-w DIR
| Rationale: | System binaries are executed by privileged users, as well as system services,
and restrictive permissions are necessary to ensure execution of these programs
cannot be co-opted. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dir_permissions_binary_dirs | References: | | |
|