Group
Guide to the Secure Configuration of Oracle Linux 9
Group contains 78 groups and 245 rules |
Group
System Settings
Group contains 54 groups and 136 rules |
[ref]
Contains rules that check correct system settings. |
Group
Installing and Maintaining Software
Group contains 11 groups and 26 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 4 groups and 7 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 2 groups 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 RPM
Group contains 2 rules |
[ref]
The RPM package management system includes the ability
to verify the integrity of installed packages by comparing the
installed files with information about the files taken from the
package metadata stored in the RPM database. Although an attacker
could corrupt the RPM database (analogous to attacking the AIDE
database as described above), this check can still reveal
modification of important files. To list which files on the system differ from what is expected by the RPM database:
$ rpm -qVa
See the man page for rpm to see a complete explanation of each column. |
Rule
Verify File Hashes with RPM
[ref] | Without cryptographic integrity protections, system executables and files can be altered by
unauthorized users without detection. The RPM package management system can check the hashes
of installed software packages, including many that are important to system security.
To verify that the cryptographic hash of system files and commands matches vendor values, run
the following command to list which files on the system have hashes that differ from what is
expected by the RPM database:
$ rpm -Va --noconfig | grep '^..5'
If the file was not expected to change, investigate the cause of the change using audit logs
or other means. The package can then be reinstalled to restore the file. Run the following
command to determine which package owns the file:
$ rpm -qf FILENAME
The package can be reinstalled from a yum repository using the command:
$ sudo yum reinstall PACKAGENAME
Alternatively, the package can be reinstalled from trusted media using the command:
$ sudo rpm -Uvh PACKAGENAME
Warning:
This rule can take a long time to perform the check and might consume a considerable
amount of resources depending on the number of packages present on the system. It is not a
problem in most cases, but especially systems with a large number of installed packages
can be affected. | Rationale: | The hashes of important files like system executables should match the
information given by the RPM database. Executables with erroneous hashes could
be a sign of nefarious activity on the system. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_rpm_verify_hashes | References: | cis-csc | 11, 2, 3, 9 | cjis | 5.10.4.1 | cobit5 | APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02 | cui | 3.3.8, 3.4.1 | disa | CCI-000366, CCI-001749 | hipaa | 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i) | 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 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.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 | nist | CM-6(d), CM-6(c), SI-7, SI-7(1), SI-7(6), AU-9(3) | nist-csf | PR.DS-6, PR.DS-8, PR.IP-1 | pcidss | Req-11.5 | os-srg | SRG-OS-000480-GPOS-00227 | pcidss4 | 11.5.2 |
| |
|
Rule
Verify and Correct Ownership with RPM
[ref] | The RPM package management system can check file ownership permissions of installed software
packages, including many that are important to system security. After locating a file with
incorrect permissions, which can be found with:
rpm -Va | awk '{ if (substr($0,6,1)=="U" || substr($0,7,1)=="G") print $NF }'
run the following command to determine which package owns it:
$ rpm -qf FILENAME
Next, run the following command to reset its permissions to the correct values:
$ sudo rpm --restore PACKAGENAME
Warning:
Profiles may require that specific files be owned by root while the default owner defined
by the vendor is different. Such files will be reported as a finding and need to be
evaluated according to your policy and deployment environment. Warning:
This rule can take a long time to perform the check and might consume a considerable
amount of resources depending on the number of packages present on the system. It is not a
problem in most cases, but especially systems with a large number of installed packages
can be affected. | Rationale: | Ownership of binaries and configuration files that is incorrect could allow an unauthorized
user to gain privileges that they should not have. The ownership set by the vendor should be
maintained. Any deviations from this baseline should be investigated. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_rpm_verify_ownership | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 3, 5, 6, 9 | cjis | 5.10.4.1 | cobit5 | APO01.06, APO11.04, BAI03.05, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.04, DSS05.07, DSS06.02, MEA02.01 | cui | 3.3.8, 3.4.1 | disa | CCI-001494, CCI-001496 | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.3.7.3, 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 5.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.2, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.5.1, A.12.6.2, A.12.7.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.14.2.2, A.14.2.3, A.14.2.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.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R4.2, CIP-003-8 R6, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2 | nist | CM-6(d), CM-6(c), SI-7, SI-7(1), SI-7(6), AU-9(3) | nist-csf | PR.AC-4, PR.DS-5, PR.IP-1, PR.PT-1 | pcidss | Req-11.5 | os-srg | SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000278-GPOS-00108 | pcidss4 | 11.5.2 |
| |
|
Group
Verify Integrity with AIDE
Group contains 3 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:
$ sudo yum 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 | anssi | R76, R79 | pcidss4 | 11.5.2 |
| |
|
Rule
Build and Test AIDE Database
[ref] | Run the following command to generate a new database:
$ sudo /usr/sbin/aide --init
By default, the database will be written to the file
/var/lib/aide/aide.db.new.gz .
Storing the database, the configuration file /etc/aide.conf , and the binary
/usr/sbin/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.gz /var/lib/aide/aide.db.gz
To initiate a manual check, run the following command:
$ sudo /usr/sbin/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 | anssi | R76, R79 | pcidss4 | 11.5.2 |
| |
|
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/sbin/aide --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/sbin/aide --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 | anssi | R76 | pcidss4 | 11.5.2 |
| |
|
Group
System Cryptographic Policies
Group contains 2 rules |
[ref]
Linux has the capability to centrally configure cryptographic polices. The command
update-crypto-policies is used to set the policy applicable for the various
cryptographic back-ends, such as SSL/TLS libraries. The configured cryptographic
policies will be the default policy used by these backends unless the application
user configures them otherwise. When the system has been configured to use the
centralized cryptographic policies, the administrator is assured that any application
that utilizes the supported backends will follow a policy that adheres to the
configured profile.
Currently the supported backends are:
- GnuTLS library
- OpenSSL library
- NSS library
- OpenJDK
- Libkrb5
- BIND
- OpenSSH
Applications and languages which rely on any of these backends will follow the
system policies as well. Examples are apache httpd, nginx, php, and others. |
Rule
Configure System Cryptography Policy
[ref] | To configure the system cryptography policy to use ciphers only from the DEFAULT
policy, run the following command:
$ sudo update-crypto-policies --set DEFAULT
The rule checks if settings for selected crypto policy are configured as expected. Configuration files in the /etc/crypto-policies/back-ends are either symlinks to correct files provided by Crypto-policies package or they are regular files in case crypto policy customizations are applied.
Crypto policies may be customized by crypto policy modules, in which case it is delimited from the base policy using a colon. Warning:
The system needs to be rebooted for these changes to take effect. 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: | Centralized cryptographic policies simplify applying secure ciphers across an operating system and
the applications that run on that operating system. Use of weak or untested encryption algorithms
undermines the purposes of utilizing encryption to protect data. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_configure_crypto_policy | References: | disa | CCI-000068, CCI-003123, CCI-002450, CCI-000877, CCI-002418, CCI-001453, CCI-002890 | hipaa | 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.312(e)(1), 164.312(e)(2)(ii) | ism | 1446 | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1, CIP-007-3 R7.1 | nist | AC-17(a), AC-17(2), CM-6(a), MA-4(6), SC-13, SC-12(2), SC-12(3) | ospp | FCS_COP.1(1), FCS_COP.1(2), FCS_COP.1(3), FCS_COP.1(4), FCS_CKM.1, FCS_CKM.2, FCS_TLSC_EXT.1 | os-srg | SRG-OS-000396-GPOS-00176, SRG-OS-000393-GPOS-00173, SRG-OS-000394-GPOS-00174 | pcidss4 | 2.2.7, 2.2 |
| |
|
Rule
Configure SSH to use System Crypto Policy
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
SSH is supported by crypto policy, but the SSH configuration may be
set up to ignore it.
To check that Crypto Policies settings are configured correctly, ensure that
the CRYPTO_POLICY variable is either commented or not set at all
in the /etc/sysconfig/sshd . | Rationale: | Overriding the system crypto policy makes the behavior of the SSH service violate expectations,
and makes system configuration more fragmented. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_configure_ssh_crypto_policy | References: | disa | CCI-001453 | hipaa | 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.312(e)(1), 164.312(e)(2)(ii) | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1, CIP-007-3 R7.1 | nist | AC-17(a), AC-17(2), CM-6(a), MA-4(6), SC-13 | ospp | FCS_SSH_EXT.1, FCS_SSHS_EXT.1, FCS_SSHC_EXT.1 | pcidss | Req-2.2 | os-srg | SRG-OS-000250-GPOS-00093 | pcidss4 | 2.2.7, 2.2 |
| |
|
Group
GNOME Desktop Environment
Group contains 3 groups and 10 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
Oracle Linux Graphical environment.
For more information on GNOME and the GNOME Project, see https://www.gnome.org. |
Group
Configure GNOME Login Screen
Group contains 1 rule |
[ref]
In the default GNOME desktop, the login is displayed after system boot
and can display user accounts, allow users to reboot the system, and allow users to
login automatically and/or with a guest account. The login screen should be configured
to prevent such behavior.
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
Disable GDM Automatic Login
[ref] | The GNOME Display Manager (GDM) can allow users to automatically login without
user interaction or credentials. User should always be required to authenticate themselves
to the system that they are authorized to use. To disable user ability to automatically
login to the system, set the AutomaticLoginEnable to false in the
[daemon] section in /etc/gdm/custom.conf . For example:
[daemon]
AutomaticLoginEnable=false
| Rationale: | Failure to restrict system access to authenticated users negatively impacts operating
system security. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_gnome_gdm_disable_automatic_login | References: | cis-csc | 11, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05 | cui | 3.1.1 | 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.2.2, A.14.2.3, A.14.2.4 | nist | CM-6(a), AC-6(1), CM-7(b) | nist-csf | PR.IP-1 | os-srg | SRG-OS-000480-GPOS-00229 | pcidss4 | 8.3.1, 8.3 |
| |
|
Group
GNOME Media Settings
Group contains 2 rules |
[ref]
GNOME media settings that apply to the graphical interface. |
Rule
Disable GNOME3 Automounting
[ref] | The system's default desktop environment, GNOME3, will mount
devices and removable media (such as DVDs, CDs and USB flash drives) whenever
they are inserted into the system. To disable automount within GNOME3, add or set
automount to false in /etc/dconf/db/local.d/00-security-settings .
For example:
[org/gnome/desktop/media-handling]
automount=false
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/media-handling/automount
After the settings have been set, run dconf update . | Rationale: | Disabling automatic mounting in GNOME3 can prevent
the introduction of malware via removable media.
It will, however, also prevent desktop users from legitimate use
of removable media. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_disable_automount | References: | cis-csc | 12, 16 | cobit5 | APO13.01, DSS01.04, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS06.03 | cui | 3.1.7 | disa | CCI-000366, CCI-000778, CCI-001958 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.2, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.13, SR 1.2, SR 1.4, SR 1.5, SR 1.9, SR 2.1, SR 2.6 | iso27001-2013 | A.11.2.6, A.13.1.1, A.13.2.1, A.6.2.1, A.6.2.2, A.7.1.1, A.9.2.1 | nist | CM-7(a), CM-7(b), CM-6(a) | nist-csf | PR.AC-3, PR.AC-6 | os-srg | SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-00163, SRG-OS-000480-GPOS-00227 | pcidss4 | 3.4.2, 3.4 |
| |
|
Rule
Disable GNOME3 Automount Opening
[ref] | The system's default desktop environment, GNOME3, will mount
devices and removable media (such as DVDs, CDs and USB flash drives) whenever
they are inserted into the system. To disable automount-open within GNOME3, add or set
automount-open to false in /etc/dconf/db/local.d/00-security-settings .
For example:
[org/gnome/desktop/media-handling]
automount-open=false
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/media-handling/automount-open
After the settings have been set, run dconf update . | Rationale: | Automatically mounting file systems permits easy introduction of unknown devices, thereby facilitating malicious activity.
Disabling automatic mounting in GNOME3 can prevent
the introduction of malware via removable media.
It will, however, also prevent desktop users from legitimate use
of removable media. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_disable_automount_open | References: | cis-csc | 12, 16 | cobit5 | APO13.01, DSS01.04, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS06.03 | cui | 3.1.7 | disa | CCI-000778, CCI-000366, CCI-001958 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.2, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.13, SR 1.2, SR 1.4, SR 1.5, SR 1.9, SR 2.1, SR 2.6 | iso27001-2013 | A.11.2.6, A.13.1.1, A.13.2.1, A.6.2.1, A.6.2.2, A.7.1.1, A.9.2.1 | nist | CM-7(a), CM-7(b), CM-6(a) | nist-csf | PR.AC-3, PR.AC-6 | os-srg | SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-00163, SRG-OS-000480-GPOS-00227 | pcidss4 | 3.4.2, 3.4 |
| |
|
Group
Configure GNOME Screen Locking
Group contains 6 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
Enable GNOME3 Screensaver Idle Activation
[ref] | To activate the screensaver in the GNOME3 desktop after a period of inactivity,
add or set idle-activation-enabled to true in
/etc/dconf/db/local.d/00-security-settings . For example:
[org/gnome/desktop/screensaver]
idle-activation-enabled=true
Once the setting has 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/idle-activation-enabled
After the settings have been set, run dconf update . | 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,
GNOME desktops can be configured to identify when a user's session has idled and take action to initiate the
session lock.
Enabling idle activation of the screensaver ensures the screensaver will
be activated after the idle delay. Applications requiring continuous,
real-time screen display (such as network management products) require the
login session does not have administrator rights and the display station is located in a
controlled-access area. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_screensaver_idle_activation_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 | 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), AC-11(a) | nist-csf | PR.AC-7 | pcidss | Req-8.1.8 | os-srg | SRG-OS-000029-GPOS-00010 | pcidss4 | 8.2.8, 8.2 |
| |
|
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 | pcidss4 | 8.2.8, 8.2 |
| |
|
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 10
in
/etc/dconf/db/local.d/00-security-settings . For example:
[org/gnome/desktop/screensaver]
lock-delay=uint32 10
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 | pcidss4 | 8.2.8, 8.2 |
| |
|
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 | pcidss4 | 8.2.8, 8.2 |
| |
|
Rule
Implement Blank Screensaver
[ref] |
To set the screensaver mode in the GNOME3 desktop to a blank screen,
add or set picture-uri to string '' in
/etc/dconf/db/local.d/00-security-settings . For example:
[org/gnome/desktop/screensaver]
picture-uri=string ''
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/picture-uri
After the settings have been set, run dconf update . | Rationale: | Setting the screensaver mode to blank-only conceals the
contents of the display from passersby. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_screensaver_mode_blank | References: | cis-csc | 1, 12, 15, 16 | cjis | 5.5.5 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.10 | disa | 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(1), CM-6(a), AC-11(1).1 | nist-csf | PR.AC-7 | pcidss | Req-8.1.8 | os-srg | SRG-OS-000031-GPOS-00012 | pcidss4 | 8.2.8, 8.2 |
| |
|
Rule
Ensure Users Cannot Change GNOME3 Session Idle Settings
[ref] | If not already configured, ensure that users cannot change GNOME3 session idle settings
by adding /org/gnome/desktop/session/idle-delay
to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification.
For example:
/org/gnome/desktop/session/idle-delay
After the settings have been set, run dconf update . | 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,
GNOME desktops can be configured to identify when a user's session has idled and take action to initiate the
session lock. As such, users should not be allowed to change session settings. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_session_idle_user_locks | References: | cis-csc | 1, 12, 15, 16 | 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 | 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 | pcidss4 | 8.2.8, 8.2 |
| |
|
Rule
Make sure that the dconf databases are up-to-date with regards to respective keyfiles
[ref] | By default, DConf uses a binary database as a data backend.
The system-level database is compiled from keyfiles in the /etc/dconf/db/
directory by the dconf update command. More specifically, content present
in the following directories:
/etc/dconf/db/local.d
/etc/dconf/db/local.d
| Rationale: | Unlike text-based keyfiles, the binary database is impossible to check by OVAL.
Therefore, in order to evaluate dconf configuration, both have to be true at the same time -
configuration files have to be compliant, and the database needs to be more recent than those keyfiles,
which gives confidence that it reflects them. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_db_up_to_date | References: | | |
|
Group
Sudo
Group contains 5 rules |
[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
Install sudo Package
[ref] | The sudo package can be installed with the following command:
$ sudo yum install sudo
| Rationale: | sudo is a program designed to allow a system administrator to give
limited root privileges to users and log root activity. The basic philosophy
is to give as few privileges as possible but still allow system users to
get their work done.
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_sudo_installed | References: | | |
|
Rule
Ensure Only Users Logged In To Real tty Can Execute Sudo - sudo use_pty
[ref] | The sudo use_pty tag, when specified, will only execute sudo
commands from users logged in to a real tty.
This should be enabled by making sure that the use_pty tag exists in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/ . | Rationale: | Requiring that sudo commands be run in a pseudo-terminal can prevent an attacker from retaining
access to the user's terminal after the main program has finished executing. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_add_use_pty | References: | | |
|
Rule
Ensure Sudo Logfile Exists - sudo logfile
[ref] | A custom log sudo file can be configured with the 'logfile' tag. This rule configures
a sudo custom logfile at the default location suggested by CIS, which uses
/var/log/sudo.log. | Rationale: | A sudo log file simplifies auditing of sudo commands. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_custom_logfile | References: | | |
|
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 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Require Re-Authentication When Using the sudo Command
[ref] | The sudo timestamp_timeout tag sets the amount of time sudo password prompt waits.
The default timestamp_timeout value is 5 minutes.
The timestamp_timeout should be configured by making sure that the
timestamp_timeout tag exists in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/ .
If the value is set to an integer less than 0, the user's time stamp will not expire
and the user will not have to re-authenticate for privileged actions until the user's session is terminated. | 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_reauthentication | References: | disa | CCI-004895 | nist | IA-11 | os-srg | SRG-OS-000373-GPOS-00156, SRG-OS-000373-GPOS-00157, SRG-OS-000373-GPOS-00158 | pcidss4 | 2.2.6, 2.2 |
| |
|
Group
Updating Software
Group contains 4 rules |
[ref]
The yum 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.
Oracle Linux 9 systems contain an installed software catalog called
the RPM database, which records metadata of installed packages. Consistently using
yum or the graphical Software Update for all software installation
allows for insight into the current inventory of installed software on the system.
|
Rule
Ensure gpgcheck Enabled In Main yum Configuration
[ref] | The gpgcheck option controls whether
RPM packages' signatures are always checked prior to installation.
To configure yum to check package signatures before installing
them, ensure the following line appears in /etc/yum.conf in
the [main] section:
gpgcheck=1
| Rationale: | Changes to any software components can have significant effects on the
overall security of the operating system. This requirement ensures the
software has not been tampered with and that it has been provided by a
trusted vendor.
Accordingly, patches, service packs, device drivers, or operating system
components must be signed with a certificate recognized and approved by the
organization.
Verifying the authenticity of the software prior to installation
validates the integrity of the patch or upgrade received from a vendor.
This ensures the software has not been tampered with and that it has been
provided by a trusted vendor. Self-signed certificates are disallowed by
this requirement. Certificates used to verify the software must be from an
approved Certificate Authority (CA). | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_globally_activated | References: | cis-csc | 11, 2, 3, 9 | cjis | 5.10.4.1 | cobit5 | APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02 | cui | 3.4.8 | disa | CCI-003992 | hipaa | 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i) | 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 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.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 | nist | CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), SA-12, SA-12(10), CM-11(a), CM-11(b) | nist-csf | PR.DS-6, PR.DS-8, PR.IP-1 | ospp | FPT_TUD_EXT.1, FPT_TUD_EXT.2 | pcidss | Req-6.2 | os-srg | SRG-OS-000366-GPOS-00153 | anssi | R59 | pcidss4 | 6.3.3, 6.3 |
| |
|
Rule
Ensure gpgcheck Enabled for All yum Package Repositories
[ref] | To ensure signature checking is not disabled for
any repos, remove any lines from files in /etc/yum.repos.d of the form:
gpgcheck=0
| Rationale: | Verifying the authenticity of the software prior to installation validates
the integrity of the patch or upgrade received from a vendor. This ensures
the software has not been tampered with and that it has been provided by a
trusted vendor. Self-signed certificates are disallowed by this
requirement. Certificates used to verify the software must be from an
approved Certificate Authority (CA)." | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_never_disabled | References: | cis-csc | 11, 2, 3, 9 | cjis | 5.10.4.1 | cobit5 | APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02 | cui | 3.4.8 | disa | CCI-003992 | hipaa | 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i) | 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 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.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 | nist | CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), SA-12, SA-12(10), CM-11(a), CM-11(b) | nist-csf | PR.DS-6, PR.DS-8, PR.IP-1 | ospp | FPT_TUD_EXT.1, FPT_TUD_EXT.2 | pcidss | Req-6.2 | os-srg | SRG-OS-000366-GPOS-00153 | anssi | R59 | pcidss4 | 6.3.3, 6.3 |
| |
|
Rule
Ensure Oracle Linux GPG Key Installed
[ref] | To ensure the system can cryptographically verify base software
packages come from Oracle (and to connect to the Unbreakable Linux Network to
receive them), the Oracle GPG key must properly be installed.
To install the Oracle GPG key, run:
$ sudo uln_register
If the system is not connected to the Internet,
then install the Oracle GPG key from trusted media such as
the Oracle installation CD-ROM or DVD. Assuming the disc is mounted
in /media/cdrom , use the following command as the root user to import
it into the keyring:
$ sudo rpm --import /media/cdrom/RPM-GPG-KEY-oracle
Alternatively, the key may be pre-loaded during the Oracle installation. In
such cases, the key can be installed by running the following command:
sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
| Rationale: | Changes to software components can have significant effects on the
overall security of the operating system. This requirement ensures
the software has not been tampered with and that it has been provided
by a trusted vendor. The Oracle GPG key is necessary to
cryptographically verify packages are from Oracle. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_oracle_gpgkey_installed | References: | cis-csc | 11, 2, 3, 9 | cobit5 | APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02 | disa | CCI-001749 | 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 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.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 | nist | CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), CM-11(a), CM-11(b) | nist-csf | PR.DS-6, PR.DS-8, PR.IP-1 | pcidss | Req-6.2 | anssi | R59 |
| |
|
Rule
Ensure Software Patches Installed
[ref] |
If the system is joined to the ULN
or a yum server, run the following command to install updates:
$ sudo yum update
If the system is not configured to use one of these sources, updates (in the form of RPM packages)
can be manually downloaded from the ULN and installed using rpm .
NOTE: U.S. Defense systems are required to be patched within 30 days or sooner as local policy
dictates. Warning:
The OVAL feed of Oracle Linux 9 is not a XML file, which may not be understood by all scanners. | Rationale: | Installing software updates is a fundamental mitigation against
the exploitation of publicly-known vulnerabilities. If the most
recent security patches and updates are not installed, unauthorized
users may take advantage of weaknesses in the unpatched software. The
lack of prompt attention to patching could result in a system compromise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_security_patches_up_to_date | References: | cis-csc | 18, 20, 4 | cjis | 5.10.4.1 | cobit5 | APO12.01, APO12.02, APO12.03, APO12.04, BAI03.10, DSS05.01, DSS05.02 | disa | CCI-000366 | 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(5), SI-2(c), CM-6(a) | nist-csf | ID.RA-1, PR.IP-12 | ospp | FMT_MOF_EXT.1 | pcidss | Req-6.2 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R61 | pcidss4 | 6.3.3, 6.3 |
| |
|
Group
Account and Access Control
Group contains 12 groups and 40 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
Oracle Linux 9. |
Group
Warning Banners for System Accesses
Group contains 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. |
Rule
Verify Group Ownership of System Login Banner for Remote Connections
[ref] |
To properly set the group owner of /etc/issue.net , run the command:
$ sudo chgrp root /etc/issue.net
| 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.
Proper group ownership will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_issue_net | References: | | |
|
Rule
Verify ownership of System Login Banner for Remote Connections
[ref] |
To properly set the owner of /etc/issue.net , run the command:
$ sudo chown root /etc/issue.net
| 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.
Proper ownership will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_issue_net | References: | | |
|
Rule
Verify permissions on System Login Banner for Remote Connections
[ref] |
To properly set the permissions of /etc/issue.net , run the command:
$ sudo chmod 0644 /etc/issue.net
| 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.
Proper permissions will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_issue_net | References: | | |
|
Group
Protect Accounts by Configuring PAM
Group contains 4 groups and 12 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 5 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
Limit Password Reuse: password-auth
[ref] | Do not allow users to reuse recent passwords. This can be accomplished by using the
remember option for the pam_pwhistory PAM module.
On systems with newer versions of authselect , the pam_pwhistory PAM module
can be enabled via authselect feature:
authselect enable-feature with-pwhistory
Otherwise, it should be enabled using an authselect custom profile.
Newer systems also have the /etc/security/pwhistory.conf file for setting
pam_pwhistory module options. This file should be used whenever available.
Otherwise, the pam_pwhistory module options can be set in PAM files.
The value for remember option must be equal or greater than
4
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:
Newer versions of authselect contain an authselect feature to easily and properly
enable pam_pwhistory.so module. If this feature is not yet available in your
system, an authselect custom profile must be used to avoid integrity issues in PAM files.
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: | Preventing re-use of previous passwords helps ensure that a compromised password is not
re-used by a user. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_pwhistory_remember_password_auth | 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-000200 | 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(f), IA-5(1)(e) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.5 | os-srg | SRG-OS-000077-GPOS-00045 | pcidss4 | 8.3.7, 8.3 |
| |
|
Rule
Limit Password Reuse: system-auth
[ref] | Do not allow users to reuse recent passwords. This can be accomplished by using the
remember option for the pam_pwhistory PAM module.
On systems with newer versions of authselect , the pam_pwhistory PAM module
can be enabled via authselect feature:
authselect enable-feature with-pwhistory
Otherwise, it should be enabled using an authselect custom profile.
Newer systems also have the /etc/security/pwhistory.conf file for setting
pam_pwhistory module options. This file should be used whenever available.
Otherwise, the pam_pwhistory module options can be set in PAM files.
The value for remember option must be equal or greater than
4
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:
Newer versions of authselect contain an authselect feature to easily and properly
enable pam_pwhistory.so module. If this feature is not yet available in your
system, an authselect custom profile must be used to avoid integrity issues in PAM files. | Rationale: | Preventing re-use of previous passwords helps ensure that a compromised password is not
re-used by a user. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_pwhistory_remember_system_auth | 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-000200 | 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(f), IA-5(1)(e) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.5 | os-srg | SRG-OS-000077-GPOS-00045 | pcidss4 | 8.3.7, 8.3 |
| |
|
Rule
Limit Password Reuse
[ref] | Do not allow users to reuse recent passwords. This can be accomplished by using the
remember option for the pam_unix or pam_pwhistory PAM modules. 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:
Newer versions of authselect contain an authselect feature to easily and properly
enable pam_pwhistory.so module. If this feature is not yet available in your
system, an authselect custom profile must be used to avoid integrity issues in PAM files. | Rationale: | Preventing re-use of previous passwords helps ensure that a compromised password is not
re-used by a user. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_unix_remember | 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-000200 | 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(f), IA-5(1)(e) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.5 | os-srg | SRG-OS-000077-GPOS-00045 | anssi | R31 | pcidss4 | 8.3.7, 8.3 |
| |
|
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
10 and greater than 0.
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: | 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 | anssi | R31 | pcidss4 | 8.3.4, 8.3 |
| |
|
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 1800 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 | anssi | R31 | pcidss4 | 8.3.4, 8.3 |
| |
|
Group
Set Password Quality Requirements
Group contains 1 group and 3 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 3 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 | anssi | R31 | pcidss4 | 8.3.6, 8.3 |
| |
|
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 | anssi | R31 | pcidss4 | 8.3.6, 8.3 |
| |
|
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=12
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 | anssi | R31, R68 | pcidss4 | 8.3.6, 8.3 |
| |
|
Group
Set Password Hashing Algorithm
Group contains 3 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/libuser.conf
[ref] | In /etc/libuser.conf , add or correct the following line in its [defaults]
section to ensure the system will use the sha512
algorithm for password hashing:
crypt_style = 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.
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_libuserconf | 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 | pcidss4 | 8.3.2, 8.3 |
| |
|
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 | pcidss4 | 8.3.2, 8.3 |
| |
|
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/system-auth", 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 sufficient 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 | anssi | R68 | pcidss4 | 8.3.2, 8.3 |
| |
|
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/postlogin
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 | pcidss4 | 10.2.1.4, 10.2.1, 10.2 |
| |
|
Group
Protect Accounts by Restricting Password-Based Login
Group contains 4 groups and 23 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=90
If a password is currently on the verge of expiration, then
90
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 90 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 | pcidss4 | 8.2.6, 8.2 |
| |
|
Rule
Ensure All Accounts on the System Have Unique Names
[ref] | Ensure accounts on the system have unique names.
To ensure all accounts have unique names, run the following command:
$ sudo getent passwd | awk -F: '{ print $1}' | uniq -d
If a username is returned, change or delete the username. | Rationale: | Unique usernames allow for accountability on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_account_unique_name | References: | | |
|
Group
Set Password Expiration Parameters
Group contains 5 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 90
A value of 180 days is sufficient for many environments.
The DoD requirement is 60.
The profile requirement is 90 . | 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 | pcidss4 | 8.3.9, 8.3 |
| |
|
Rule
Set Existing Passwords Maximum Age
[ref] | Configure non-compliant accounts to enforce a 90-day maximum password lifetime
restriction by running the following command:
$ sudo chage -M 90
USER
| 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_set_max_life_existing | References: | | |
|
Rule
Set Existing Passwords Warning Age
[ref] | To configure how many days prior to password expiration that a warning will be issued to
users, run the command:
$ sudo chage --warndays 7
USER
The DoD requirement is 7, and CIS recommendation is no less than 7 days.
This profile requirement is 7 . | Rationale: | Providing an advance warning that a password will be expiring gives users
time to think of a secure password. Users caught unaware may choose a simple
password or write it down where it may be discovered. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_set_warn_age_existing | References: | | |
|
Rule
Set Password Warning Age
[ref] | To specify how many days prior to password
expiration that a warning will be issued to users,
edit the file /etc/login.defs and add or correct
the following line:
PASS_WARN_AGE 7
The DoD requirement is 7.
The profile requirement is 7 . | Rationale: | Setting the password warning age enables users to
make the change at a practical time. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_warn_age_login_defs | 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, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.8 | 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 | ism | 0418, 1055, 1402 | 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 | nist | IA-5(f), IA-5(1)(d), 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.2.4 | pcidss4 | 8.3.9, 8.3 |
| |
|
Rule
Set existing passwords a period of inactivity before they been locked
[ref] | Configure user accounts that have been inactive for over a given period of time
to be automatically disabled by running the following command:
$ sudo chage --inactive 30USER
| Rationale: | Inactive accounts pose a threat to system security since the users are not logging in to
notice failed login attempts or other anomalies. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_set_post_pw_existing | References: | cobit5 | DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.6 | disa | CCI-000017, CCI-000795, CCI-003627, CCI-003628 | 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 | pcidss4 | 8.2.6, 8.2 |
| |
|
Group
Verify Proper Storage and Existence of Password
Hashes
Group contains 5 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
Verify All Account Password Hashes are Shadowed
[ref] | If any password hashes are stored in /etc/passwd (in the second field,
instead of an x or * ), the cause of this misconfiguration should be
investigated. The account should have its password reset and the hash should be
properly stored, or the account should be deleted entirely. | Rationale: | The hashes for all user account passwords should be stored in
the file /etc/shadow and never in /etc/passwd ,
which is readable by all users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_all_shadowed | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.5.2 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.10 | 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 | 1410 | 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(h), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.1 | pcidss4 | 8.3.2, 8.3 |
| |
|
Rule
Ensure all users last password change date is in the past
[ref] | All users should have a password change date in the past. Warning:
Automatic remediation is not available, in order to avoid any system disruption. | Rationale: | If a user recorded password change date is in the future then they could
bypass any set password expiration. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_last_change_is_in_past | References: | | |
|
Rule
All GIDs referenced in /etc/passwd must be defined in /etc/group
[ref] | Add a group to the system for each GID referenced without a corresponding group. | Rationale: | If a user is assigned the Group Identifier (GID) of a group not existing on the system, and a group
with the Group Identifier (GID) is subsequently created, the user may have unintended rights to
any files associated with the group. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_gid_passwd_group_same | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.5.2 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-000764 | 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 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | nist | IA-2, CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.5.a | os-srg | SRG-OS-000104-GPOS-00051 | pcidss4 | 8.2.2, 8.2 |
| |
|
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/system-auth and
/etc/pam.d/password-auth
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 | pcidss4 | 8.3.1, 8.3 |
| |
|
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 9 rules |
[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
Verify Only Root Has UID 0
[ref] | If any account other than root has a UID of 0, this misconfiguration should
be investigated and the accounts other than root should be removed or have
their UID changed.
If the account is associated with system commands or applications the UID
should be changed to one greater than "0" but less than "1000."
Otherwise assign a UID greater than "1000" that has not already been
assigned. | Rationale: | An account has root authority if it has a UID of 0. Multiple accounts
with a UID of 0 afford more opportunity for potential intruders to
guess a password for a privileged account. Proper configuration of
sudo is recommended to afford multiple system administrators
access to root privileges in an accountable manner. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_no_uid_except_zero | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 3, 5 | 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 | 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 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | nist | IA-2, AC-6(5), IA-4(b) | nist-csf | PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.DS-5 | pcidss | Req-8.5 | os-srg | SRG-OS-000480-GPOS-00227 | pcidss4 | 8.2.1, 8.2 |
| |
|
Rule
Verify Root Has A Primary GID 0
[ref] | The root user should have a primary group of 0. | Rationale: | To help ensure that root-owned files are not inadvertently exposed to other users. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_root_gid_zero | References: | | |
|
Rule
Ensure the Group Used by pam_wheel.so Module Exists on System and is Empty
[ref] | Ensure that the group sugroup referenced by
var_pam_wheel_group_for_su variable and used as value for the pam_wheel.so
group option exists and has no members. This empty group used by
pam_wheel.so in /etc/pam.d/su ensures that no user can run commands with
altered privileges through the su command. Warning:
Note that this rule just ensures the group exists and has no members. This rule does not
configure pam_wheel.so module. The pam_wheel.so module configuration is
accomplished by use_pam_wheel_group_for_su rule. | Rationale: | The su program allows to run commands with a substitute user and group ID.
It is commonly used to run commands as the root user.
Limiting access to such command is considered a good security practice. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_pam_wheel_group_empty | References: | | |
|
Rule
Ensure Authentication Required for Single User Mode
[ref] | Single user mode is used for recovery when the system detects an
issue during boot or by manual selection from the bootloader. | Rationale: | Requiring authentication in single user mode prevents an unauthorized
user from rebooting the system into single user to gain root privileges
without credentials. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_root_password_configured | References: | | |
|
Rule
Direct root Logins Not Allowed
[ref] | To further limit access to the root account, administrators
can disable root logins at the console by editing the /etc/securetty file.
This file lists all devices the root user is allowed to login to. If the file does
not exist at all, the root user can login through any communication device on the
system, whether via the console or via a raw network interface. This is dangerous
as user can login to the system as root via Telnet, which sends the password in
plain text over the network. By default, Oracle Linux 9's
/etc/securetty file only allows the root user to login at the console
physically attached to the system. To prevent root from logging in, remove the
contents of this file. To prevent direct root logins, remove the contents of this
file by typing the following command:
$ sudo echo > /etc/securetty
Warning:
This rule only checks the /etc/securetty file existence and its content.
If you need to restrict user access using the /etc/securetty file, make sure
the pam_securetty.so PAM module is properly enabled in relevant PAM files. | Rationale: | Disabling direct root logins ensures proper accountability and multifactor
authentication to privileged accounts. Users will first login, then escalate
to privileged (root) access via su / sudo. This is required for FISMA Low
and FISMA Moderate systems. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_no_direct_root_logins | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.1.1, 3.1.6 | 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.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 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | nist | IA-2, CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | anssi | R33 | pcidss4 | 8.6.1, 8.6 |
| |
|
Rule
Ensure that System Accounts Are Locked
[ref] | Some accounts are not associated with a human user of the system, and exist to perform some
administrative functions. An attacker should not be able to log into these accounts.
System accounts are those user accounts with a user ID less than 1000 .
If any system account other than root , halt , sync , shutdown
and nfsnobody has an unlocked password, disable it with the command:
$ sudo usermod -L account
| Rationale: | Disabling authentication for default system accounts makes it more difficult for attackers
to make use of them to compromise a system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_no_password_auth_for_systemaccounts | References: | 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, CM-6(a) | pcidss4 | 8.2.2, 8.2 |
| |
|
Rule
Ensure that System Accounts Do Not Run a Shell Upon Login
[ref] | Some accounts are not associated with a human user of the system, and exist to perform some
administrative functions. Should an attacker be able to log into these accounts, they should
not be granted access to a shell.
The login shell for each local account is stored in the last field of each line in
/etc/passwd . System accounts are those user accounts with a user ID less than
1000 . The user ID is stored in the third field. If any system account
other than root has a login shell, disable it with the command:
$ sudo usermod -s /sbin/nologin account
Warning:
Do not perform the steps in this section on the root account. Doing so might cause the
system to become inaccessible. | Rationale: | Ensuring shells are not given to system accounts upon login makes it more difficult for
attackers to make use of system accounts. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_no_shelllogin_for_systemaccounts | 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-000366 | 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 | ism | 1491 | 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-6, CM-6(a), CM-6(b), CM-6.1(iv) | nist-csf | DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6 | os-srg | SRG-OS-000480-GPOS-00227 | pcidss4 | 8.2.2, 8.2 |
| |
|
Rule
Restrict Virtual Console Root Logins
[ref] | To restrict root logins through the (deprecated) virtual console devices,
ensure lines of this form do not appear in /etc/securetty :
vc/1
vc/2
vc/3
vc/4
| Rationale: | Preventing direct root login to virtual console devices
helps ensure accountability for actions taken on the system
using the root account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_securetty_root_login_console_only | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.1.1, 3.1.5 | disa | CCI-000770 | 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 | AC-6, CM-6(a) | nist-csf | PR.AC-4, PR.DS-5 | os-srg | SRG-OS-000324-GPOS-00125 | pcidss4 | 8.6.1, 8.6 |
| |
|
Rule
Enforce Usage of pam_wheel with Group Parameter for su Authentication
[ref] | To ensure that only users who are members of the group set in the group option of
pam_wheel.so module can run commands with altered privileges through the su
command, make sure that the following line exists in the file /etc/pam.d/su :
auth required pam_wheel.so use_uid group=sugroup
Warning:
Note that ensure_pam_wheel_group_empty rule complements this requirement by
ensuring the referenced group exists and has no members. | Rationale: | The su program allows to run commands with a substitute user and group ID.
It is commonly used to run commands as the root user.
Limiting access to such command is considered a good security practice. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_use_pam_wheel_group_for_su | References: | | |
|
Rule
Ensure All Accounts on the System Have Unique User IDs
[ref] | Change user IDs (UIDs), or delete accounts, so each has a unique name. Warning:
Automatic remediation of this control is not available due to unique requirements of each
system. | Rationale: | To assure accountability and prevent unauthenticated access, interactive users must be identified and authenticated to prevent potential misuse and compromise of the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_account_unique_id | References: | disa | CCI-000135, CCI-000764, CCI-000804 | pcidss | Req-8.1.1 | os-srg | SRG-OS-000104-GPOS-00051, SRG-OS-000121-GPOS-00062 | pcidss4 | 8.2.1, 8.2 |
| |
|
Rule
Ensure All Groups on the System Have Unique Group ID
[ref] | Change the group name or delete groups, so each has a unique id. Warning:
Automatic remediation of this control is not available due to the unique requirements of each system. | Rationale: | To assure accountability and prevent unauthenticated access, groups must be identified uniquely to prevent potential misuse and compromise of the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_group_unique_id | References: | | |
|
Group
Secure Session Configuration Files for Login Accounts
Group contains 1 rule |
[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. |
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:
typeset -xr TMOUT=600
or
declare -xr TMOUT=600
Using the typeset keyword is preferred for wider compatibility with ksh and other shells. | 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 | anssi | R32 | pcidss4 | 8.6.1, 8.6 |
| |
|
Rule
Enable authselect
[ref] | Configure user authentication setup to use the authselect tool.
If authselect profile is selected, the rule will enable the sssd profile. Warning:
If the sudo authselect select command returns an error informing that the chosen
profile cannot be selected, it is probably because PAM files have already been modified by
the administrator. If this is the case, in order to not overwrite the desired changes made
by the administrator, the current PAM settings should be investigated before forcing the
selection of the chosen authselect profile. | Rationale: | Authselect is a successor to authconfig.
It is a tool to select system authentication and identity sources from a list of supported
profiles instead of letting the administrator manually build the PAM stack.
That way, it avoids potential breakage of configuration, as it ships several tested profiles
that are well tested and supported to solve different use-cases. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_enable_authselect | References: | 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) | nist | AC-3 | ospp | FIA_UAU.1, FIA_AFL.1 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R31 | pcidss4 | 8.3.4, 8.3 |
| |
|
Group
GRUB2 bootloader configuration
Group contains 1 group and 6 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 Oracle Linux 9 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 6 rules |
[ref]
Non-UEFI GRUB2 bootloader configuration |
Rule
Verify /boot/grub2/grub.cfg Group Ownership
[ref] | The file /boot/grub2/grub.cfg should
be group-owned by the root group to prevent
destruction or modification of the file.
To properly set the group owner of /boot/grub2/grub.cfg , run the command:
$ sudo chgrp root /boot/grub2/grub.cfg
| Rationale: | The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_grub2_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.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.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) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/user.cfg Group Ownership
[ref] | The file /boot/grub2/user.cfg should be group-owned by the root
group to prevent reading or modification of the file.
To properly set the group owner of /boot/grub2/user.cfg , run the command:
$ sudo chgrp root /boot/grub2/user.cfg
| Rationale: | The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway. Non-root users who read the boot parameters
may be able to identify weaknesses in security upon boot and be able to exploit them. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_user_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | 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 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/grub.cfg User Ownership
[ref] | The file /boot/grub2/grub.cfg should
be owned by the root user to prevent destruction
or modification of the file.
To properly set the owner of /boot/grub2/grub.cfg , run the command:
$ sudo chown root /boot/grub2/grub.cfg
| Rationale: | Only root should be able to modify important boot parameters. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_grub2_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.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.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) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/user.cfg User Ownership
[ref] | The file /boot/grub2/user.cfg should be owned by the root
user to prevent reading or modification of the file.
To properly set the owner of /boot/grub2/user.cfg , run the command:
$ sudo chown root /boot/grub2/user.cfg
| Rationale: | Only root should be able to modify important boot parameters. Also, non-root users who read
the boot parameters may be able to identify weaknesses in security upon boot and be able to
exploit them. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_user_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | 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 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/grub.cfg Permissions
[ref] | File permissions for /boot/grub2/grub.cfg should be set to 600.
To properly set the permissions of /boot/grub2/grub.cfg , run the command:
$ sudo chmod 600 /boot/grub2/grub.cfg
| Rationale: | Proper permissions ensure that only the root user can modify important boot
parameters. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_grub2_cfg | 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-000225 | 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 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/user.cfg Permissions
[ref] | File permissions for /boot/grub2/user.cfg should be set to 600.
To properly set the permissions of /boot/grub2/user.cfg , run the command:
$ sudo chmod 600 /boot/grub2/user.cfg
| Rationale: | Proper permissions ensure that only the root user can read or modify important boot
parameters. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_user_cfg | 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-000225 | 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 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Group
Configure Syslog
Group contains 2 groups and 5 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 Oracle Linux 9, 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 3 rules |
[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 Oracle Linux 9 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
|
|