| Group
Guide to the Secure Configuration of Red Hat Enterprise Linux 9
Group contains 109 groups and 481 rules |
| Group
System Settings
Group contains 67 groups and 293 rules |
[ref]
Contains rules that check correct system settings. |
| Group
Installing and Maintaining Software
Group contains 15 groups and 64 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 5 groups and 24 rules |
[ref]
System and software integrity can be gained by installing antivirus, increasing
system encryption strength with FIPS, verifying installed software, enabling SELinux,
installing an Intrusion Prevention System, etc. However, installing or enabling integrity
checking tools cannot prevent intrusions, but they can detect that an intrusion
may have occurred. Requirements for integrity checking may be highly dependent on
the environment in which the system will be used. Snapshot-based approaches such
as AIDE may induce considerable overhead in the presence of frequent software updates. |
| Group
Software Integrity Checking
Group contains 1 group and 11 rules |
[ref]
Both the AIDE (Advanced Intrusion Detection Environment)
software and the RPM package management system provide
mechanisms for verifying the integrity of installed software.
AIDE uses snapshots of file metadata (such as hashes) and compares these
to current system files in order to detect changes.
The RPM package management system can conduct integrity
checks by comparing information in its metadata database with
files installed on the system. |
| Group
Verify Integrity with AIDE
Group contains 11 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 dnf 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 | | Identifiers: | CCE-90843-4 | | 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 | | cis | 6.1.1 | | pcidss4 | 11.5.2 | | stigid | RHEL-09-651010 | | stigref | SV-258134r958794_rule |
| |
|
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 | | Identifiers: | CCE-83438-2 | | 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 | | cis | 6.1.1 | | pcidss4 | 11.5.2 | | stigid | RHEL-09-651010 | | stigref | SV-258134r958794_rule |
| |
|
Rule
Configure AIDE to Verify the Audit Tools
[ref] | The operating system file integrity tool must be configured to protect the integrity of the audit tools. | | Rationale: | Protecting the integrity of the tools used for auditing purposes is a
critical step toward ensuring the integrity of audit information. Audit
information includes all information (e.g., audit records, audit settings,
and audit reports) needed to successfully audit information system
activity.
Audit tools include but are not limited to vendor-provided and open-source
audit tools needed to successfully view and manipulate audit information
system activity and records. Audit tools include custom queries and report
generators.
It is not uncommon for attackers to replace the audit tools or inject code
into the existing tools to provide the capability to hide or erase system
activity from the audit logs.
To address this risk, audit tools must be cryptographically signed to
provide the capability to identify when the audit tools have been modified,
manipulated, or replaced. An example is a checksum hash of the file or
files. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_aide_check_audit_tools | | Identifiers: | CCE-87757-1 | | References: | | disa | CCI-001496, CCI-001494, CCI-001495, CCI-001493 | | nist | AU-9(3), AU-9(3).1 | | os-srg | SRG-OS-000278-GPOS-00108 | | cis | 6.1.3 | | stigid | RHEL-09-651025 | | stigref | SV-258137r991557_rule |
| |
|
Rule
Configure Periodic Execution of AIDE
[ref] | At a minimum, AIDE should be configured to run a weekly scan.
To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab:
05 4 * * * root /usr/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 | | Identifiers: | CCE-83437-4 | | 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 | | cis | 6.1.2 | | pcidss4 | 11.5.2 | | stigid | RHEL-09-651015 | | stigref | SV-258135r958794_rule |
| |
|
Rule
Configure Notification of Post-AIDE Scan Details
[ref] | AIDE should notify appropriate personnel of the details of a scan after the scan has been run.
If AIDE has already been configured for periodic execution in /etc/crontab, append the
following line to the existing AIDE line:
| /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost
Otherwise, add the following line to /etc/crontab:
05 4 * * * root /usr/sbin/aide --check | /bin/mail -s "$(hostname) - AIDE Integrity Check" root@localhost
AIDE can be executed periodically through other means; this is merely one example. | | Rationale: | 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_scan_notification | | Identifiers: | CCE-90844-2 | | References: | | cis-csc | 1, 11, 12, 13, 15, 16, 2, 3, 5, 7, 8, 9 | | cobit5 | BAI01.06, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07 | | disa | CCI-002702, CCI-001744, CCI-002699 | | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3 | | isa-62443-2013 | SR 6.2, SR 7.6 | | iso27001-2013 | A.12.1.2, A.12.4.1, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1 | | nist | CM-6(a), CM-3(5) | | nist-csf | DE.CM-1, DE.CM-7, PR.IP-1, PR.IP-3 | | os-srg | SRG-OS-000363-GPOS-00150, SRG-OS-000446-GPOS-00200, SRG-OS-000447-GPOS-00201 | | anssi | R76 | | stigid | RHEL-09-651015 | | stigref | SV-258135r958794_rule |
| |
|
Rule
Configure AIDE to Use FIPS 140-2 for Validating Hashes
[ref] | By default, the sha512 option is added to the NORMAL ruleset in AIDE.
If using a custom ruleset or the sha512 option is missing, add sha512
to the appropriate ruleset.
For example, add sha512 to the following line in /etc/aide.conf:
NORMAL = FIPSR+sha512
AIDE rules can be configured in multiple ways; this is merely one example that is already
configured by default. 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: | File integrity tools use cryptographic hashes for verifying file contents and directories
have not been altered. These hashes must be FIPS 140-2 approved cryptographic hashes. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_aide_use_fips_hashes | | Identifiers: | CCE-88939-4 | | References: | | cis-csc | 2, 3 | | cobit5 | APO01.06, BAI03.05, BAI06.01, DSS06.02 | | cui | 3.13.11 | | disa | CCI-000366 | | isa-62443-2009 | 4.3.4.4.4 | | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8 | | iso27001-2013 | A.11.2.4, A.12.2.1, A.12.5.1, A.14.1.2, A.14.1.3, A.14.2.4 | | nist | SI-7, SI-7(1), CM-6(a) | | nist-csf | PR.DS-6, PR.DS-8 | | os-srg | SRG-OS-000480-GPOS-00227 | | stigid | RHEL-09-651020 | | stigref | SV-258136r991589_rule |
| |
|
Rule
Configure AIDE to Verify Access Control Lists (ACLs)
[ref] | By default, the acl option is added to the FIPSR ruleset in AIDE.
If using a custom ruleset or the acl option is missing, add acl
to the appropriate ruleset.
For example, add acl to the following line in /etc/aide.conf:
FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256
AIDE rules can be configured in multiple ways; this is merely one example that is already
configured by default.
The remediation provided with this rule adds acl to all rule sets available in
/etc/aide.conf
| | Rationale: | ACLs can provide permissions beyond those permitted through the file mode and must be
verified by the file integrity tools. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_aide_verify_acls | | Identifiers: | CCE-90837-6 | | References: | | cis-csc | 2, 3 | | cobit5 | APO01.06, BAI03.05, BAI06.01, DSS06.02 | | disa | CCI-000366 | | isa-62443-2009 | 4.3.4.4.4 | | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8 | | iso27001-2013 | A.11.2.4, A.12.2.1, A.12.5.1, A.14.1.2, A.14.1.3, A.14.2.4 | | nist | SI-7, SI-7(1), CM-6(a) | | nist-csf | PR.DS-6, PR.DS-8 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R76 | | stigid | RHEL-09-651030 | | stigref | SV-258138r991589_rule |
| |
|
Rule
Configure AIDE to Verify Extended Attributes
[ref] | By default, the xattrs option is added to the FIPSR ruleset in AIDE.
If using a custom ruleset or the xattrs option is missing, add xattrs
to the appropriate ruleset.
For example, add xattrs to the following line in /etc/aide.conf:
FIPSR = p+i+n+u+g+s+m+c+acl+selinux+xattrs+sha256
AIDE rules can be configured in multiple ways; this is merely one example that is already
configured by default.
The remediation provided with this rule adds xattrs to all rule sets available in
/etc/aide.conf
| | Rationale: | Extended attributes in file systems are used to contain arbitrary data and file metadata
with security implications. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_aide_verify_ext_attributes | | Identifiers: | CCE-83439-0 | | References: | | cis-csc | 2, 3 | | cobit5 | APO01.06, BAI03.05, BAI06.01, DSS06.02 | | disa | CCI-000366 | | isa-62443-2009 | 4.3.4.4.4 | | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8 | | iso27001-2013 | A.11.2.4, A.12.2.1, A.12.5.1, A.14.1.2, A.14.1.3, A.14.2.4 | | nist | SI-7, SI-7(1), CM-6(a) | | nist-csf | PR.DS-6, PR.DS-8 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R76 | | stigid | RHEL-09-651035 | | stigref | SV-258139r991589_rule |
| |
|
Rule
Audit Tools Must Be Group-owned by Root
[ref] | Red Hat Enterprise Linux 9 systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools, and the corresponding rights the user enjoys, to make access decisions regarding the access to audit tools.
Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
Audit tools must have the correct group owner. | | Rationale: | Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data.
Therefore, protecting audit tools is necessary to prevent unauthorized operations on audit information. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_audit_tools_group_ownership | | Identifiers: | CCE-86240-9 | | References: | | disa | CCI-001493 | | nist | AU-9 | | os-srg | SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099 | | stigid | RHEL-09-232225 | | stigref | SV-257925r991557_rule |
| |
|
Rule
Audit Tools Must Be Owned by Root
[ref] | Red Hat Enterprise Linux 9 systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools, and the corresponding rights the user enjoys, to make access decisions regarding the access to audit tools.
Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
Audit tools must have the correct owner. | | Rationale: | Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data.
Therefore, protecting audit tools is necessary to prevent unauthorized operations on audit information. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_audit_tools_ownership | | Identifiers: | CCE-86263-1 | | References: | | disa | CCI-001493 | | nist | AU-9 | | os-srg | SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099 | | stigid | RHEL-09-232220 | | stigref | SV-257924r991557_rule |
| |
|
Rule
Audit Tools Must Have a Mode of 0755 or Less Permissive
[ref] | Red Hat Enterprise Linux 9 systems providing tools to interface with audit information will leverage user permissions and roles identifying the user accessing the tools, and the corresponding rights the user enjoys, to make access decisions regarding the access to audit tools.
Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.
Audit tools must have a mode of 0755 or less permissive. | | Rationale: | Protecting audit information also includes identifying and protecting the tools used to view and manipulate log data.
Therefore, protecting audit tools is necessary to prevent unauthorized operations on audit information. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_audit_tools_permissions | | Identifiers: | CCE-86228-4 | | References: | | disa | CCI-001493 | | nist | AU-9 | | os-srg | SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099 | | stigid | RHEL-09-232035 | | stigref | SV-257887r991557_rule |
| |
|
| Group
Federal Information Processing Standard (FIPS)
Group contains 3 rules |
[ref]
The Federal Information Processing Standard (FIPS) is a computer security standard which
is developed by the U.S. Government and industry working groups to validate the quality
of cryptographic modules. The FIPS standard provides four security levels to ensure
adequate coverage of different industries, implementation of cryptographic modules, and
organizational sizes and requirements.
FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules
utilize authentication that meets industry and government requirements. For government systems, this allows
Security Levels 1, 2, 3, or 4 for use on Red Hat Enterprise Linux 9.
See http://csrc.nist.gov/publications/PubsFIPS.html for more information. |
Rule
Enable Dracut FIPS Module
[ref] | To enable FIPS mode, run the following command:
fips-mode-setup --enable
To enable FIPS, the system requires that the fips module is added in dracut configuration.
Check if /etc/dracut.conf.d/40-fips.conf contain add_dracutmodules+=" fips "
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: | Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to
protect data. The operating system must implement cryptographic modules adhering to the higher
standards approved by the federal government since this provides assurance they have been tested
and validated. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_enable_dracut_fips_module | | Identifiers: | CCE-86547-7 | | References: | | disa | CCI-002450, CCI-000068, CCI-002418, CCI-000877 | | ism | 1446 | | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1 | | nist | SC-12(2), SC-12(3), IA-7, SC-13, CM-6(a), SC-12 | | ospp | FCS_RBG_EXT.1 | | os-srg | SRG-OS-000478-GPOS-00223 | | stigid | RHEL-09-671010 | | stigref | SV-258230r958408_rule |
| |
|
Rule
Enable FIPS Mode
[ref] |
To enable FIPS mode, run the following command:
fips-mode-setup --enable
The fips-mode-setup command will configure the system in
FIPS mode by automatically configuring the following:
- Setting the kernel FIPS mode flag (
/proc/sys/crypto/fips_enabled) to 1
- Creating
/etc/system-fips
- Setting the system crypto policy in
/etc/crypto-policies/config to FIPS
- Loading the Dracut
fips module
Warning:
The system needs to be rebooted for these changes to take effect. | | Rationale: | Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to
protect data. The operating system must implement cryptographic modules adhering to the higher
standards approved by the federal government since this provides assurance they have been tested
and validated. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_enable_fips_mode | | Identifiers: | CCE-88742-2 | | References: | | disa | CCI-002450, CCI-000068, CCI-002418, CCI-000877 | | ism | 1446 | | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1 | | nist | CM-3(6), SC-12(2), SC-12(3), IA-7, SC-13, CM-6(a), SC-12 | | 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, FCS_RBG_EXT.1 | | os-srg | SRG-OS-000478-GPOS-00223, SRG-OS-000396-GPOS-00176 | | stigid | RHEL-09-671010 | | stigref | SV-258230r958408_rule |
| |
|
Rule
Set kernel parameter 'crypto.fips_enabled' to 1
[ref] | System running in FIPS mode is indicated by kernel parameter
'crypto.fips_enabled'. This parameter should be set to 1 in FIPS mode.
To enable FIPS mode, run the following command:
fips-mode-setup --enable
To enable strict FIPS compliance, the fips=1 kernel option needs to be added to the kernel boot
parameters during system installation so key generation is done with FIPS-approved algorithms
and continuous monitoring tests in place. 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: | Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to
protect data. The operating system must implement cryptographic modules adhering to the higher
standards approved by the federal government since this provides assurance they have been tested
and validated. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_crypto_fips_enabled | | Identifiers: | CCE-83441-6 | | References: | | disa | CCI-002450, CCI-000068, CCI-002418, CCI-000877 | | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1 | | nist | SC-12(2), SC-12(3), IA-7, SC-13, CM-6(a), SC-12 | | os-srg | SRG-OS-000033-GPOS-00014, SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093, SRG-OS-000393-GPOS-00173, SRG-OS-000394-GPOS-00174, SRG-OS-000396-GPOS-00176, SRG-OS-000423-GPOS-00187, SRG-OS-000478-GPOS-00223 | | stigid | RHEL-09-671010 | | stigref | SV-258230r958408_rule |
| |
|
| Group
System Cryptographic Policies
Group contains 9 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
Install crypto-policies package
[ref] | The crypto-policies package can be installed with the following command:
$ sudo dnf install crypto-policies
| | 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: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_crypto-policies_installed | | Identifiers: | CCE-83442-4 | | References: | | disa | CCI-002890, CCI-002450, CCI-003123 | | 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 | | stigid | RHEL-09-672010 | | stigref | SV-258234r987791_rule |
| |
|
Rule
Configure BIND to use System Crypto Policy
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
BIND is supported by crypto policy, but the BIND configuration may be
set up to ignore it.
To check that Crypto Policies settings are configured correctly, ensure that the /etc/named.conf
includes the appropriate configuration:
In the options section of /etc/named.conf, make sure that the following line
is not commented out or superseded by later includes:
include "/etc/crypto-policies/back-ends/bind.config";
| | Rationale: | Overriding the system crypto policy makes the behavior of the BIND service violate expectations,
and makes system configuration more fragmented. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_bind_crypto_policy | | Identifiers: | CCE-83451-5 | | References: | | disa | CCI-002418, CCI-002422 | | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1 | | nist | SC-13, SC-12(2), SC-12(3) | | os-srg | SRG-OS-000423-GPOS-00187, SRG-OS-000426-GPOS-00190 | | stigid | RHEL-09-672050 | | stigref | SV-258242r958908_rule |
| |
|
Rule
Configure System Cryptography Policy
[ref] | To configure the system cryptography policy to use ciphers only from the FIPS
policy, run the following command:
$ sudo update-crypto-policies --set FIPS
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 | | Identifiers: | CCE-83450-7 | | 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 | | ccn | A.5.SEC-RHEL4 | | cis | 1.6.1 | | pcidss4 | 2.2.7, 2.2 | | stigid | RHEL-09-671010, RHEL-09-672030, RHEL-09-672045 | | stigref | SV-258230r958408_rule, SV-258238r991554_rule, SV-258241r1017572_rule |
| |
|
Rule
Configure Kerberos to use System Crypto Policy
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
Kerberos is supported by crypto policy, but it's configuration may be
set up to ignore it.
To check that Crypto Policies settings for Kerberos are configured correctly, examine that there is a symlink at
/etc/krb5.conf.d/crypto-policies targeting /etc/cypto-policies/back-ends/krb5.config.
If the symlink exists, Kerberos is configured to use the system-wide crypto policy settings. | | Rationale: | Overriding the system crypto policy makes the behavior of Kerberos violate expectations,
and makes system configuration more fragmented. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_kerberos_crypto_policy | | Identifiers: | CCE-83449-9 | | References: | | |
|
Rule
Configure Libreswan to use System Crypto Policy
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
Libreswan is supported by system crypto policy, but the Libreswan configuration may be
set up to ignore it.
To check that Crypto Policies settings are configured correctly, ensure that the /etc/ipsec.conf
includes the appropriate configuration file.
In /etc/ipsec.conf, make sure that the following line
is not commented out or superseded by later includes:
include /etc/crypto-policies/back-ends/libreswan.config
| | Rationale: | Overriding the system crypto policy makes the behavior of the Libreswan
service violate expectations, and makes system configuration more
fragmented. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_libreswan_crypto_policy | | Identifiers: | CCE-83446-5 | | References: | | |
|
Rule
Configure OpenSSL library to use System Crypto Policy
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
OpenSSL is supported by crypto policy, but the OpenSSL configuration may be
set up to ignore it.
To check that Crypto Policies settings are configured correctly, you have to examine the OpenSSL config file
available under /etc/pki/tls/openssl.cnf.
This file has the ini format, and it enables crypto policy support
if there is a [ crypto_policy ] section that contains the .include = /etc/crypto-policies/back-ends/opensslcnf.config directive. | | Rationale: | Overriding the system crypto policy makes the behavior of the Java runtime violates expectations,
and makes system configuration more fragmented. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_openssl_crypto_policy | | Identifiers: | CCE-83452-3 | | References: | | disa | CCI-001453 | | 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) | | pcidss | Req-2.2 | | os-srg | SRG-OS-000250-GPOS-00093 | | stigid | RHEL-09-672035 | | stigref | SV-258239r991554_rule |
| |
|
Rule
Configure OpenSSL library to use TLS Encryption
[ref] | Crypto Policies are means of enforcing certain cryptographic settings for
selected applications including OpenSSL. OpenSSL is by default configured to
modify its configuration based on currently configured Crypto Policy.
Editing the Crypto Policy back-end is not recommended.
Check the crypto-policies(7) man page and choose a policy that configures TLS
protocol to version 1.2 or higher, for example DEFAULT, FUTURE or FIPS policy.
Or create and apply a custom policy that restricts minimum TLS version to 1.2.
For example for versions prior to crypto-policies-20210617-1.gitc776d3e.el8.noarch
this is expected:
$ sudo grep -i MinProtocol /etc/crypto-policies/back-ends/opensslcnf.config
MinProtocol = TLSv1.2
Or for version crypto-policies-20210617-1.gitc776d3e.el8.noarch and newer this is
expected:
$ sudo grep -i MinProtocol /etc/crypto-policies/back-ends/opensslcnf.config
TLS.MinProtocol = TLSv1.2
DTLS.MinProtocol = DTLSv1.2
Warning:
This rule doesn't come with a remediation, automatically changing the crypto-policies may be too disruptive.
Ensure the variable xccdf_org.ssgproject.content_value_var_system_crypto_policy is set to a
Crypto Policy that satisfies OpenSSL minimum TLS protocol version 1.2. Custom policies may be applied too. | | Rationale: | Without cryptographic integrity protections, information can be altered by
unauthorized users without detection. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_openssl_tls_crypto_policy | | Identifiers: | CCE-83448-1 | | References: | | disa | CCI-001453 | | nist | AC-17(2) | | os-srg | SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093, SRG-OS-000393-GPOS-00173, SRG-OS-000394-GPOS-00174 | | stigid | RHEL-09-672040 | | stigref | SV-258240r991554_rule |
| |
|
Rule
Configure SSH Client to Use FIPS 140-2 Validated Ciphers: openssh.config
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
OpenSSH is supported by system crypto policy, but the OpenSSH configuration may be
set up incorrectly.
To check that Crypto Policies settings for ciphers are configured correctly, ensure that
/etc/crypto-policies/back-ends/openssh.config contains the following
line and is not commented out:
Ciphers aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr
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: | Overriding the system crypto policy makes the behavior of the OpenSSH client
violate expectations, and makes system configuration more fragmented. By
specifying a cipher list with the order of ciphers being in a “strongest to
weakest” orientation, the system will automatically attempt to use the
strongest cipher for securing SSH connections. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_harden_sshd_ciphers_openssh_conf_crypto_policy | | Identifiers: | CCE-90125-6 | | References: | | disa | CCI-001453 | | nist | AC-17(2) | | os-srg | SRG-OS-000033-GPOS-00014, SRG-OS-000125-GPOS-00065, SRG-OS-000250-GPOS-00093, SRG-OS-000393-GPOS-00173, SRG-OS-000394-GPOS-00174, SRG-OS-000423-GPOS-00187 | | stigid | RHEL-09-255060 | | stigref | SV-257988r991554_rule |
| |
|
Rule
Configure SSH Server to Use FIPS 140-2 Validated Ciphers: opensshserver.config
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
OpenSSH is supported by system crypto policy, but the OpenSSH configuration may be
set up incorrectly.
To check that Crypto Policies settings for ciphers are configured correctly, ensure that
/etc/crypto-policies/back-ends/opensshserver.config contains the following
text and is not commented out:
-oCiphers=aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr
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: | Overriding the system crypto policy makes the behavior of the OpenSSH server
violate expectations, and makes system configuration more fragmented. By
specifying a cipher list with the order of ciphers being in a “strongest to
weakest” orientation, the system will automatically attempt to use the
strongest cipher for securing SSH connections. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_harden_sshd_ciphers_opensshserver_conf_crypto_policy | | Identifiers: | CCE-87332-3 | | References: | | |
|
| Group
Operating System Vendor Support and Certification
Group contains 1 rule |
[ref]
The assurance of a vendor to provide operating system support and maintenance
for their product is an important criterion to ensure product stability and
security over the life of the product. A certified product that follows the
necessary standards and government certification requirements guarantees that
known software vulnerabilities will be remediated, and proper guidance for
protecting and securing the operating system will be given. |
Rule
The Installed Operating System Is Vendor Supported
[ref] | The installed operating system must be maintained by a vendor.
Red Hat Enterprise Linux is supported by Red Hat, Inc. As the Red Hat Enterprise
Linux vendor, Red Hat, Inc. is responsible for providing security patches. Warning:
There is no remediation besides switching to a different operating system. | | Rationale: | An operating system is considered "supported" if the vendor continues to
provide security patches for the product. With an unsupported release, it
will not be possible to resolve any security issue discovered in the system
software. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_installed_OS_is_vendor_supported | | Identifiers: | CCE-83453-1 | | References: | | cis-csc | 18, 20, 4 | | 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 | CM-6(a), MA-6, SA-13(a) | | nist-csf | ID.RA-1, PR.IP-12 | | os-srg | SRG-OS-000480-GPOS-00227 | | stigid | RHEL-09-211010 | | stigref | SV-257777r991589_rule |
| |
|
| Group
Disk Partitioning
Group contains 7 rules |
[ref]
To ensure separation and protection of data, there
are top-level system directories which should be placed on their
own physical partition or logical volume. The installer's default
partitioning scheme creates separate logical volumes for
/, /boot, and swap.
- If starting with any of the default layouts, check the box to
\"Review and modify partitioning.\" This allows for the easy creation
of additional logical volumes inside the volume group already
created, though it may require making
/'s logical volume smaller to
create space. In general, using logical volumes is preferable to
using partitions because they can be more easily adjusted
later. - If creating a custom layout, create the partitions mentioned in
the previous paragraph (which the installer will require anyway),
as well as separate ones described in the following sections.
If a system has already been installed, and the default
partitioning
scheme was used, it is possible but nontrivial to
modify it to create separate logical volumes for the directories
listed above. The Logical Volume Manager (LVM) makes this possible. |
Rule
Encrypt Partitions
[ref] | Red Hat Enterprise Linux 9 natively supports partition encryption through the
Linux Unified Key Setup-on-disk-format (LUKS) technology. The easiest way to
encrypt a partition is during installation time.
For manual installations, select the Encrypt checkbox during
partition creation to encrypt the partition. When this
option is selected the system will prompt for a passphrase to use in
decrypting the partition. The passphrase will subsequently need to be entered manually
every time the system boots.
For automated/unattended installations, it is possible to use Kickstart by adding
the --encrypted and --passphrase= options to the definition of each partition to be
encrypted. For example, the following line would encrypt the root partition:
part / --fstype=ext4 --size=100 --onpart=hda1 --encrypted --passphrase=PASSPHRASE
Any PASSPHRASE is stored in the Kickstart in plaintext, and the Kickstart
must then be protected accordingly.
Omitting the --passphrase= option from the partition definition will cause the
installer to pause and interactively ask for the passphrase during installation.
By default, the Anaconda installer uses aes-xts-plain64 cipher
with a minimum 512 bit key size which should be compatible with FIPS enabled.
Detailed information on encrypting partitions using LUKS or LUKS ciphers can be found on
the Red Hat Enterprise Linux 9 Documentation web site:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/encrypting-block-devices-using-luks_security-hardening
. | | Rationale: | The risk of a system's physical compromise, particularly mobile systems such as
laptops, places its data at risk of compromise. Encrypting this data mitigates
the risk of its loss if the system is lost. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_encrypt_partitions | | Identifiers: | CCE-90849-1 | | References: | | cis-csc | 13, 14 | | cobit5 | APO01.06, BAI02.01, BAI06.01, DSS04.07, DSS05.03, DSS05.04, DSS05.07, DSS06.02, DSS06.06 | | cui | 3.13.16 | | disa | CCI-002476, CCI-001199, CCI-002475 | | hipaa | 164.308(a)(1)(ii)(D), 164.308(b)(1), 164.310(d), 164.312(a)(1), 164.312(a)(2)(iii), 164.312(a)(2)(iv), 164.312(b), 164.312(c), 164.314(b)(2)(i), 164.312(d) | | isa-62443-2013 | SR 3.4, SR 4.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1 | | nist | CM-6(a), SC-28, SC-28(1), SC-13, AU-9(3) | | nist-csf | PR.DS-1, PR.DS-5 | | os-srg | SRG-OS-000405-GPOS-00184, SRG-OS-000185-GPOS-00079, SRG-OS-000404-GPOS-00183 | | ccn | A.25.SEC-RHEL1 | | stigid | RHEL-09-231190 | | stigref | SV-257879r1014836_rule |
| |
|
Rule
Ensure /home Located On Separate Partition
[ref] | If user home directories will be stored locally, create a separate partition
for /home at installation time (or migrate it later using LVM). If
/home will be mounted from another system such as an NFS server, then
creating a separate partition is not necessary at installation time, and the
mountpoint can instead be configured later. | | Rationale: | Ensuring that /home is mounted on its own partition enables the
setting of more restrictive mount options, and also helps ensure that
users cannot trivially fill partitions used for log or audit data storage. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_home | | Identifiers: | CCE-83468-9 | | References: | | cis-csc | 12, 15, 8 | | cobit5 | APO13.01, DSS05.02 | | disa | CCI-000366 | | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | | iso27001-2013 | A.13.1.1, A.13.2.1, A.14.1.3 | | nist | CM-6(a), SC-5(2) | | nist-csf | PR.PT-4 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R28 | | cis | 1.1.2.3.1 | | stigid | RHEL-09-231010 | | stigref | SV-257843r991589_rule |
| |
|
Rule
Ensure /tmp Located On Separate Partition
[ref] | The /tmp directory is a world-writable directory used
for temporary file storage. Ensure it has its own partition or
logical volume at installation time, or migrate it using LVM. | | Rationale: | The /tmp partition is used as temporary storage by many programs.
Placing /tmp in its own partition enables the setting of more
restrictive mount options, which can help protect programs which use it. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_tmp | | Identifiers: | CCE-90845-9 | | References: | | cis-csc | 12, 15, 8 | | cobit5 | APO13.01, DSS05.02 | | disa | CCI-000366 | | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | | iso27001-2013 | A.13.1.1, A.13.2.1, A.14.1.3 | | nist | CM-6(a), SC-5(2) | | nist-csf | PR.PT-4 | | os-srg | SRG-OS-000480-GPOS-00227 | | cis | 1.1.2.1.1 | | stigid | RHEL-09-231015 | | stigref | SV-257844r991589_rule |
| |
|
Rule
Ensure /var Located On Separate Partition
[ref] | The /var directory is used by daemons and other system
services to store frequently-changing data. Ensure that /var has its own partition
or logical volume at installation time, or migrate it using LVM. | | Rationale: | Ensuring that /var is mounted on its own partition enables the
setting of more restrictive mount options. This helps protect
system services such as daemons or other programs which use it.
It is not uncommon for the /var directory to contain
world-writable directories installed by other software packages. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var | | Identifiers: | CCE-83466-3 | | References: | | cis-csc | 12, 15, 8 | | cobit5 | APO13.01, DSS05.02 | | disa | CCI-000366 | | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | | iso27001-2013 | A.13.1.1, A.13.2.1, A.14.1.3 | | nist | CM-6(a), SC-5(2) | | nist-csf | PR.PT-4 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R28 | | cis | 1.1.2.4.1 | | stigid | RHEL-09-231020 | | stigref | SV-257845r991589_rule |
| |
|
Rule
Ensure /var/log Located On Separate Partition
[ref] | System logs are stored in the /var/log directory.
Ensure that /var/log has its own partition or logical
volume at installation time, or migrate it using LVM. | | Rationale: | Placing /var/log in its own partition
enables better separation between log files
and other files in /var/. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var_log | | Identifiers: | CCE-90848-3 | | References: | | cis-csc | 1, 12, 14, 15, 16, 3, 5, 6, 8 | | cobit5 | APO11.04, APO13.01, BAI03.05, DSS05.02, DSS05.04, DSS05.07, MEA02.01 | | disa | CCI-000366 | | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | | iso27001-2013 | A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3 | | nerc-cip | CIP-007-3 R6.5 | | nist | CM-6(a), AU-4, SC-5(2) | | nist-csf | PR.PT-1, PR.PT-4 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R28 | | cis | 1.1.2.6.1 | | stigid | RHEL-09-231025 | | stigref | SV-257846r991589_rule |
| |
|
Rule
Ensure /var/log/audit Located On Separate Partition
[ref] | Audit logs are stored in the /var/log/audit directory.
Ensure that /var/log/audit has its own partition or logical
volume at installation time, or migrate it using LVM.
Make absolutely certain that it is large enough to store all
audit logs that will be created by the auditing daemon. | | Rationale: | Placing /var/log/audit in its own partition
enables better separation between audit files
and other files, and helps ensure that
auditing cannot be halted due to the partition running out
of space. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var_log_audit | | Identifiers: | CCE-90847-5 | | References: | | cis-csc | 1, 12, 13, 14, 15, 16, 2, 3, 5, 6, 8 | | cobit5 | APO11.04, APO13.01, BAI03.05, BAI04.04, DSS05.02, DSS05.04, DSS05.07, MEA02.01 | | disa | CCI-000366, CCI-001849 | | hipaa | 164.312(a)(2)(ii) | | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.2, SR 7.6 | | iso27001-2013 | A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.17.2.1 | | nerc-cip | CIP-007-3 R6.5 | | nist | CM-6(a), AU-4, SC-5(2) | | nist-csf | PR.DS-4, PR.PT-1, PR.PT-4 | | ospp | FMT_SMF_EXT.1 | | os-srg | SRG-OS-000341-GPOS-00132, SRG-OS-000480-GPOS-00227 | | app-srg-ctr | SRG-APP-000357-CTR-000800 | | anssi | R71 | | cis | 1.1.2.7.1 | | stigid | RHEL-09-231030 | | stigref | SV-257847r958752_rule |
| |
|
Rule
Ensure /var/tmp Located On Separate Partition
[ref] | The /var/tmp directory is a world-writable directory used
for temporary file storage. Ensure it has its own partition or
logical volume at installation time, or migrate it using LVM. | | Rationale: | The /var/tmp partition is used as temporary storage by many programs.
Placing /var/tmp in its own partition enables the setting of more
restrictive mount options, which can help protect programs which use it. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var_tmp | | Identifiers: | CCE-83487-9 | | References: | | |
|
| Group
GNOME Desktop Environment
Group contains 4 groups and 14 rules |
[ref]
GNOME is a graphical desktop environment bundled with many Linux distributions that
allow users to easily interact with the operating system graphically rather than
textually. The GNOME Graphical Display Manager (GDM) provides login, logout, and user
switching contexts as well as display server management.
GNOME is developed by the GNOME Project and is considered the default
Red Hat Graphical environment.
For more information on GNOME and the GNOME Project, see https://www.gnome.org. |
| Group
Configure GNOME Login Screen
Group contains 4 rules |
|
Rule
Disable the GNOME3 Login Restart and Shutdown Buttons
[ref] | In the default graphical environment, users logging directly into the
system are greeted with a login screen that allows any user, known or
unknown, the ability the ability to shutdown or restart the system. This
functionality should be disabled by setting
disable-restart-buttons to true.
To disable, add or edit disable-restart-buttons to
/etc/dconf/db/distro.d/00-security-settings. For example:
[org/gnome/login-screen]
disable-restart-buttons=true
Once the setting has been added, add a lock to
/etc/dconf/db/distro.d/locks/00-security-settings-lock to prevent
user modification. For example:
/org/gnome/login-screen/disable-restart-buttons
After the settings have been set, run dconf update. | | Rationale: | A user who is at the console can reboot the system at the login screen. If restart or shutdown buttons
are pressed at the login screen, this can create the risk of short-term loss of availability of systems
due to reboot. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_disable_restart_shutdown | | Identifiers: | CCE-86315-9 | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.1.2 | | disa | CCI-000366 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-6(a), AC-6(1), CM-7(b) | | nist-csf | PR.AC-4, PR.DS-5 | | os-srg | SRG-OS-000480-GPOS-00227 | | stigid | RHEL-09-271095, RHEL-09-271100 | | stigref | SV-258029r1014857_rule, SV-258030r991589_rule |
| |
|
Rule
Disable the GNOME3 Login User List
[ref] | In the default graphical environment, users logging directly into the
system are greeted with a login screen that displays all known users.
This functionality should be disabled by setting disable-user-list
to true.
To disable, add or edit disable-user-list to
/etc/dconf/db/distro.d/00-security-settings. For example:
[org/gnome/login-screen]
disable-user-list=true
Once the setting has been added, add a lock to
/etc/dconf/db/distro.d/locks/00-security-settings-lock to prevent
user modification. For example:
/org/gnome/login-screen/disable-user-list
After the settings have been set, run dconf update. | | Rationale: | Leaving the user list enabled is a security risk since it allows anyone
with physical access to the system to quickly enumerate known user accounts
without logging in. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_disable_user_list | | Identifiers: | CCE-88285-2 | | References: | | |
|
Rule
Enable the GNOME3 Screen Locking On Smartcard Removal
[ref] | In the default graphical environment, screen locking on smartcard removal
can be enabled by setting removal-action
to 'lock-screen'.
To enable, add or edit removal-action to
/etc/dconf/db/local.d/00-security-settings. For example:
[org/gnome/settings-daemon/peripherals/smartcard]
removal-action='lock-screen'
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/settings-daemon/peripherals/smartcard/removal-action
After the settings have been set, run dconf update. | | Rationale: | Locking the screen automatically when removing the smartcard can
prevent undesired access to system. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_lock_screen_on_smartcard_removal | | Identifiers: | CCE-86452-0 | | References: | | disa | CCI-000057, CCI-000056 | | os-srg | SRG-OS-000028-GPOS-00009, SRG-OS-000030-GPOS-00011 | | stigid | RHEL-09-271045, RHEL-09-271050 | | stigref | SV-258019r1015086_rule, SV-258020r1015087_rule |
| |
|
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 | | Identifiers: | CCE-89663-9 | | 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 | | stigid | RHEL-09-271040 | | stigref | SV-258018r991591_rule |
| |
|
| Group
GNOME Media Settings
Group contains 2 rules |
[ref]
GNOME media settings that apply to the graphical interface. |
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 | | Identifiers: | CCE-90128-0 | | 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 | | ccn | A.11.SEC-RHEL12 | | cis | 1.8.6, 1.8.7 | | pcidss4 | 3.4.2, 3.4 | | stigid | RHEL-09-271020, RHEL-09-271025 | | stigref | SV-258014r958498_rule, SV-258015r958498_rule |
| |
|
Rule
Disable GNOME3 Automount running
[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 autorun-never within GNOME3, add or set
autorun-never to true in /etc/dconf/db/local.d/00-security-settings.
For example:
[org/gnome/desktop/media-handling]
autorun-never=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/media-handling/autorun-never
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 mount running 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: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_disable_autorun | | Identifiers: | CCE-90257-7 | | 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-001764, CCI-001958, CCI-000778 | | 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 | | ccn | A.11.SEC-RHEL12 | | cis | 1.8.8, 1.8.9 | | stigid | RHEL-09-271030, RHEL-09-271035 | | stigref | SV-258016r958804_rule, SV-258017r958498_rule |
| |
|
| 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
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 | | Identifiers: | CCE-86510-5 | | 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 | | ccn | A.11.SEC-RHEL7 | | cis | 1.8.4 | | pcidss4 | 8.2.8, 8.2 | | stigid | RHEL-09-271065 | | stigref | SV-258023r958402_rule |
| |
|
Rule
Set GNOME3 Screensaver Lock Delay After Activation Period
[ref] | To activate the locking delay of the screensaver in the GNOME3 desktop when
the screensaver is activated, add or set lock-delay to uint32 0
in
/etc/dconf/db/local.d/00-security-settings. For example:
[org/gnome/desktop/screensaver]
lock-delay=uint32 0
After the settings have been set, run dconf update. | | Rationale: | A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity
of the information system but does not want to logout because of the temporary nature of the absense. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_screensaver_lock_delay | | Identifiers: | CCE-86954-5 | | 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 | | ccn | A.11.SEC-RHEL7 | | cis | 1.8.4 | | pcidss4 | 8.2.8, 8.2 | | stigid | RHEL-09-271075 | | stigref | SV-258025r958402_rule |
| |
|
Rule
Enable GNOME3 Screensaver Lock After Idle Period
[ref] |
To activate locking of the screensaver in the GNOME3 desktop when it is activated,
add or set lock-enabled to true in
/etc/dconf/db/local.d/00-security-settings. For example:
[org/gnome/desktop/screensaver]
lock-enabled=true
Once the settings have been added, add a lock to
/etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification.
For example:
/org/gnome/desktop/screensaver/lock-enabled
After the settings have been set, run dconf update. | | Rationale: | A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity
of the information system but does not want to logout because of the temporary nature of the absense. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_screensaver_lock_enabled | | Identifiers: | CCE-89302-4 | | 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 | | stigid | RHEL-09-271055, RHEL-09-271060 | | stigref | SV-258021r1015088_rule, SV-258022r1015089_rule |
| |
|
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 | | Identifiers: | CCE-88733-1 | | 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 | | stigid | RHEL-09-271085 | | stigref | SV-258027r958404_rule |
| |
|
Rule
Ensure Users Cannot Change GNOME3 Screensaver Settings
[ref] | If not already configured, ensure that users cannot change GNOME3 screensaver lock settings
by adding /org/gnome/desktop/screensaver/lock-delay
to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification.
For example:
/org/gnome/desktop/screensaver/lock-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_screensaver_user_locks | | Identifiers: | CCE-87491-7 | | 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 | CM-6(a) | | nist-csf | PR.AC-7 | | os-srg | SRG-OS-000029-GPOS-00010, SRG-OS-000031-GPOS-00012 | | cis | 1.8.5 | | stigid | RHEL-09-271080 | | stigref | SV-258026r958402_rule |
| |
|
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 | | Identifiers: | CCE-85971-0 | | 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 | | cis | 1.8.5 | | pcidss4 | 8.2.8, 8.2 | | stigid | RHEL-09-271070 | | stigref | SV-258024r958402_rule |
| |
|
| Group
GNOME System Settings
Group contains 1 rule |
[ref]
GNOME provides configuration and functionality to a graphical desktop environment
that changes grahical configurations or allow a user to perform
actions that users normally would not be able to do in non-graphical mode such as
remote access configuration, power policies, Geo-location, etc.
Configuring such settings in GNOME will prevent accidential graphical configuration
changes by users from taking place. |
Rule
Disable Ctrl-Alt-Del Reboot Key Sequence in GNOME3
[ref] | By default, GNOME will reboot the system if the
Ctrl-Alt-Del key sequence is pressed.
To configure the system to ignore the Ctrl-Alt-Del key sequence
from the Graphical User Interface (GUI) instead of rebooting the system,
add or set logout to [''] in
/etc/dconf/db/local.d/00-security-settings. For example:
[org/gnome/settings-daemon/plugins/media-keys]
logout=['']
Once the settings have been added, add a lock to
/etc/dconf/db/local.d/locks/00-security-settings-lock to prevent
user modification. For example:
/org/gnome/settings-daemon/plugins/media-keys/logout
After the settings have been set, run dconf update. | | Rationale: | A locally logged-in user who presses Ctrl-Alt-Del, when at the console,
can reboot the system. If accidentally pressed, as could happen in
the case of mixed OS environment, this can create the risk of short-term
loss of availability of systems due to unintentional reboot. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_disable_ctrlaltdel_reboot | | Identifiers: | CCE-88653-1 | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.1.2 | | disa | CCI-000366 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-6(a), AC-6(1), CM-7(b) | | nist-csf | PR.AC-4, PR.DS-5 | | os-srg | SRG-OS-000480-GPOS-00227 | | stigid | RHEL-09-271105, RHEL-09-271110 | | stigref | SV-258031r991589_rule, SV-258032r991589_rule |
| |
|
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/distro.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 | | Identifiers: | CCE-87295-2 | | References: | | |
|
| Group
Sudo
Group contains 6 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 dnf 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 | | Identifiers: | CCE-83523-1 | | References: | | |
|
Rule
Ensure Users Re-Authenticate for Privilege Escalation - sudo !authenticate
[ref] | The sudo !authenticate option, when specified, allows a user to execute commands using
sudo without having to authenticate. This should be disabled by making sure that the
!authenticate option does 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_remove_no_authenticate | | Identifiers: | CCE-83544-7 | | References: | | cis-csc | 1, 12, 15, 16, 5 | | cobit5 | DSS05.04, DSS05.10, DSS06.03, DSS06.10 | | disa | 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, SRG-OS-000373-GPOS-00157, SRG-OS-000373-GPOS-00158 | | stigid | RHEL-09-432025 | | stigref | SV-258086r1015095_rule |
| |
|
Rule
Ensure Users Re-Authenticate for Privilege Escalation - sudo NOPASSWD
[ref] | The sudo NOPASSWD tag, when specified, allows a user to execute
commands using sudo without having to authenticate. This should be disabled
by making sure that the NOPASSWD tag does 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_remove_nopasswd | | Identifiers: | CCE-83536-3 | | References: | | cis-csc | 1, 12, 15, 16, 5 | | cobit5 | DSS05.04, DSS05.10, DSS06.03, DSS06.10 | | disa | 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, SRG-OS-000373-GPOS-00157, SRG-OS-000373-GPOS-00158 | | stigid | RHEL-09-611085 | | stigref | SV-258106r1015106_rule |
| |
|
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 | | Identifiers: | CCE-90029-0 | | References: | | disa | CCI-004895 | | nist | IA-11 | | os-srg | SRG-OS-000373-GPOS-00156, SRG-OS-000373-GPOS-00157, SRG-OS-000373-GPOS-00158 | | ccn | A.5.SEC-RHEL2 | | cis | 5.2.5, 5.2.6 | | pcidss4 | 2.2.6, 2.2 | | stigid | RHEL-09-432015 | | stigref | SV-258084r1015094_rule |
| |
|
Rule
The operating system must restrict privilege elevation to authorized personnel
[ref] | The sudo command allows a user to execute programs with elevated
(administrator) privileges. It prompts the user for their password
and confirms your request to execute a command by checking a file,
called sudoers.
Restrict privileged actions by removing the following entries from the sudoers file:
ALL ALL=(ALL) ALL
ALL ALL=(ALL:ALL) ALL
Warning:
This rule doesn't come with a remediation, as the exact requirement allows exceptions,
and removing lines from the sudoers file can make the system non-administrable. | | Rationale: | If the "sudoers" file is not configured correctly, any user defined
on the system can initiate privileged actions on the target system. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_restrict_privilege_elevation_to_authorized | | Identifiers: | CCE-83525-6 | | References: | | |
|
Rule
Ensure invoking users password for privilege escalation when using sudo
[ref] | The sudoers security policy requires that users authenticate themselves before they can use sudo.
When sudoers requires authentication, it validates the invoking user's credentials.
The expected output for:
sudo cvtsudoers -f sudoers /etc/sudoers | grep -E '^Defaults !?(rootpw|targetpw|runaspw)$'
Defaults !targetpw
Defaults !rootpw
Defaults !runaspw
or if cvtsudoers not supported:
sudo find /etc/sudoers /etc/sudoers.d \( \! -name '*~' -a \! -name '*.*' \) -exec grep -E --with-filename '^[[:blank:]]*Defaults[[:blank:]](.*[[:blank:]])?!?\b(rootpw|targetpw|runaspw)' -- {} \;
/etc/sudoers:Defaults !targetpw
/etc/sudoers:Defaults !rootpw
/etc/sudoers:Defaults !runaspw
| | Rationale: | If the rootpw, targetpw, or runaspw flags are defined and not disabled, by default the operating system will prompt
the invoking user for the "root" user password. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sudoers_validate_passwd | | Identifiers: | CCE-83529-8 | | References: | | |
|
| Group
System Tooling / Utilities
Group contains 7 rules |
[ref]
The following checks evaluate the system for recommended base packages -- both for installation
and removal. |
Rule
Ensure gnutls-utils is installed
[ref] | The gnutls-utils package can be installed with the following command:
$ sudo dnf install gnutls-utils
| | Rationale: | GnuTLS is a secure communications library implementing the SSL, TLS and DTLS
protocols and technologies around them. It provides a simple C language
application programming interface (API) to access the secure communications
protocols as well as APIs to parse and write X.509, PKCS #12, OpenPGP and
other required structures.
This package contains command line TLS client and server and certificate
manipulation tools. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_gnutls-utils_installed | | Identifiers: | CCE-83494-5 | | References: | | disa | CCI-000366 | | ospp | FIA_X509_EXT.1, FIA_X509_EXT.1.1, FIA_X509_EXT.2 | | os-srg | SRG-OS-000480-GPOS-00227 | | stigid | RHEL-09-215080 | | stigref | SV-257839r991589_rule |
| |
|
Rule
Ensure nss-tools is installed
[ref] | The nss-tools package can be installed with the following command:
$ sudo dnf install nss-tools
| | Rationale: | Network Security Services (NSS) is a set of libraries designed to
support cross-platform development of security-enabled client and
server applications. Install the nss-tools package
to install command-line tools to manipulate the NSS certificate
and key database. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_nss-tools_installed | | Identifiers: | CCE-89706-6 | | References: | | |
|
Rule
Install rng-tools Package
[ref] | The rng-tools package can be installed with the following command:
$ sudo dnf install rng-tools
| | Rationale: | rng-tools provides hardware random number generator tools,
such as those used in the formation of x509/PKI certificates.
| | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_package_rng-tools_installed | | Identifiers: | CCE-83504-1 | | References: | | |
|
Rule
Install subscription-manager Package
[ref] | The subscription-manager package can be installed with the following command:
$ sudo dnf install subscription-manager
| | Rationale: | Red Hat Subscription Manager is a local service which tracks installed products
and subscriptions on a local system to help manage subscription assignments.
It communicates with the backend subscription service (the Customer Portal
or an on-premise server such as Subscription Asset Manager) and works with
content management tools such as .
The package provides, among other things, plugins
to interact with repositories and subscriptions
from the Red Hat entitlement platform - the subscription-manager and
product-id plugins. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_subscription-manager_installed | | Identifiers: | CCE-83506-6 | | References: | | disa | CCI-003992 | | ism | 0940, 1144, 1467, 1472, 1483, 1493, 1494, 1495 | | ospp | FPT_TUD_EXT.1, FPT_TUD_EXT.2 | | os-srg | SRG-OS-000366-GPOS-00153 | | stigid | RHEL-09-215010 | | stigref | SV-257825r1015079_rule |
| |
|
Rule
Uninstall gssproxy Package
[ref] | The gssproxy package can be removed with the following command:
$ sudo dnf remove gssproxy
| | Rationale: | gssproxy is a proxy for GSS API credential handling.
| | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_gssproxy_removed | | Identifiers: | CCE-83516-5 | | References: | | disa | CCI-000366, CCI-000381 | | os-srg | SRG-OS-000095-GPOS-00049, SRG-OS-000480-GPOS-00227 | | stigid | RHEL-09-215045 | | stigref | SV-257832r958478_rule |
| |
|
Rule
Uninstall iprutils Package
[ref] | The iprutils package can be removed with the following command:
$ sudo dnf remove iprutils
| | Rationale: | iprutils provides a suite of utlilities to manage and configure SCSI devices
supported by the ipr SCSI storage device driver.
| | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_iprutils_removed | | Identifiers: | CCE-83519-9 | | References: | | disa | CCI-000366, CCI-000381 | | os-srg | SRG-OS-000095-GPOS-00049, SRG-OS-000480-GPOS-00227 | | stigid | RHEL-09-215050 | | stigref | SV-257833r958478_rule |
| |
|
Rule
Uninstall tuned Package
[ref] | The tuned package can be removed with the following command:
$ sudo dnf remove tuned
| | Rationale: | tuned contains a daemon that tunes the system settings dynamically.
It does so by monitoring the usage of several system components periodically. Based
on that information, components will then be put into lower or higher power savings
modes to adapt to the current usage.
| | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_tuned_removed | | Identifiers: | CCE-83521-5 | | References: | | disa | CCI-000366, CCI-000381 | | os-srg | SRG-OS-000095-GPOS-00049, SRG-OS-000480-GPOS-00227 | | stigid | RHEL-09-215055 | | stigref | SV-257834r958478_rule |
| |
|
| Group
Updating Software
Group contains 6 rules |
[ref]
The dnf 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.
Red Hat Enterprise Linux 9 systems contain an installed software catalog called
the RPM database, which records metadata of installed packages. Consistently using
dnf or the graphical Software Update for all software installation
allows for insight into the current inventory of installed software on the system.
|
Rule
Ensure dnf Removes Previous Package Versions
[ref] | dnf should be configured to remove previous software components after
new versions have been installed. To configure dnf to remove the
previous software components after updating, set the clean_requirements_on_remove
to 1 in /etc/dnf/dnf.conf.
| | Rationale: | Previous versions of software components that are not removed from the information
system after updates have been installed may be exploited by some adversaries. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_clean_components_post_updating | | Identifiers: | CCE-83458-0 | | References: | | cis-csc | 18, 20, 4 | | cobit5 | APO12.01, APO12.02, APO12.03, APO12.04, BAI03.10, DSS05.01, DSS05.02 | | cui | 3.4.8 | | disa | CCI-002617 | | isa-62443-2009 | 4.2.3, 4.2.3.12, 4.2.3.7, 4.2.3.9 | | iso27001-2013 | A.12.6.1, A.14.2.3, A.16.1.3, A.18.2.2, A.18.2.3 | | nist | SI-2(6), CM-11(a), CM-11(b), CM-6(a) | | nist-csf | ID.RA-1, PR.IP-12 | | os-srg | SRG-OS-000437-GPOS-00194 | | stigid | RHEL-09-214035 | | stigref | SV-257824r958936_rule |
| |
|
Rule
Ensure gpgcheck Enabled In Main dnf Configuration
[ref] | The gpgcheck option controls whether
RPM packages' signatures are always checked prior to installation.
To configure dnf to check package signatures before installing
them, ensure the following line appears in /etc/dnf/dnf.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 | | Identifiers: | CCE-83457-2 | | 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 | | cis | 1.2.1.2 | | pcidss4 | 6.3.3, 6.3 | | stigid | RHEL-09-214015 | | stigref | SV-257820r1015076_rule |
| |
|
Rule
Ensure gpgcheck Enabled for Local Packages
[ref] | dnf should be configured to verify the signature(s) of local packages
prior to installation. To configure dnf to verify signatures of local
packages, set the localpkg_gpgcheck to 1 in /etc/dnf/dnf.conf.
| | Rationale: | Changes to any software components can have significant effects to the overall security
of the operating system. This requirement ensures the software has not been tampered and
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. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_local_packages | | Identifiers: | CCE-83463-0 | | References: | | cis-csc | 11, 3, 9 | | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05 | | 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 | | 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-11(a), CM-11(b), CM-6(a), CM-5(3), SA-12, SA-12(10) | | nist-csf | PR.IP-1 | | ospp | FPT_TUD_EXT.1, FPT_TUD_EXT.2 | | os-srg | SRG-OS-000366-GPOS-00153 | | anssi | R59 | | stigid | RHEL-09-214020 | | stigref | SV-257821r1015077_rule |
| |
|
Rule
Ensure gpgcheck Enabled for All dnf 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 | | Identifiers: | CCE-83464-8 | | 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 | | stigid | RHEL-09-214025 | | stigref | SV-257822r1015078_rule |
| |
|
Rule
Ensure Red Hat GPG Key Installed
[ref] | To ensure the system can cryptographically verify base software packages
come from Red Hat (and to connect to the Red Hat Network to receive them),
the Red Hat GPG key must properly be installed. To install the Red Hat GPG
key, run:
$ sudo subscription-manager register
If the system is not connected to the Internet or an RHN Satellite, then
install the Red Hat GPG key from trusted media such as the Red Hat
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
Alternatively, the key may be pre-loaded during the RHEL installation. In
such cases, the key can be installed by running the following command:
sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
| | 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 Red Hat GPG key is necessary to cryptographically verify packages are
from Red Hat. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_redhat_gpgkey_installed | | Identifiers: | CCE-84180-9 | | 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 | | 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, CIP-007-3 R5.1 | | nist | CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a) | | 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 | | stigid | RHEL-09-214010 | | stigref | SV-257819r1015075_rule |
| |
|
Rule
Ensure Software Patches Installed
[ref] |
If the system is joined to the Red Hat Network, a Red Hat Satellite Server,
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 Red Hat Network and installed using rpm.
NOTE: U.S. Defense systems are required to be patched within 30 days or sooner as local policy
dictates. Warning:
Red Hat Enterprise Linux 9 does not have a corresponding OVAL CVE Feed. Therefore, this will result in a "not checked" result during a scan. | | 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 | | Identifiers: | CCE-84185-8 | | 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 | | stigid | RHEL-09-211015 | | stigref | SV-257778r991589_rule |
| |
|
| Group
Account and Access Control
Group contains 17 groups and 77 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
Red Hat Enterprise Linux 9. |
| Group
Warning Banners for System Accesses
Group contains 1 group and 2 rules |
[ref]
Each system should expose as little information about
itself as possible.
System banners, which are typically displayed just before a
login prompt, give out information about the service or the host's
operating system. This might include the distribution name and the
system kernel version, and the particular version of a network
service. This information can assist intruders in gaining access to
the system as it can reveal whether the system is running
vulnerable software. Most network services can be configured to
limit what information is displayed.
Many organizations implement security policies that require a
system banner provide notice of the system's ownership, provide
warning to unauthorized users, and remind authorized users of their
consent to monitoring. |
| Group
Implement a GUI Warning Banner
Group contains 1 rule |
[ref]
In the default graphical environment, users logging
directly into the system are greeted with a login screen provided
by the GNOME Display Manager (GDM). The warning banner should be
displayed in this graphical environment for these users.
The following sections describe how to configure the GDM login
banner. |
Rule
Enable GNOME3 Login Warning Banner
[ref] | In the default graphical environment, displaying a login warning banner
in the GNOME Display Manager's login screen can be enabled on the login
screen by setting banner-message-enable to true.
To enable, add or edit banner-message-enable to
/etc/dconf/db/distro.d/00-security-settings. For example:
[org/gnome/login-screen]
banner-message-enable=true
Once the setting has been added, add a lock to
/etc/dconf/db/distro.d/locks/00-security-settings-lock to prevent user modification.
For example:
/org/gnome/login-screen/banner-message-enable
After the settings have been set, run dconf update.
The banner text must also be set. | | Rationale: | Display of a standardized and approved use notification before granting access to the operating system
ensures privacy and security notification verbiage used is consistent with applicable federal laws,
Executive Orders, directives, policies, regulations, standards, and guidance.
For U.S. Government systems, system use notifications are required only for access via login interfaces
with human users and are not required when such human interfaces do not exist. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_banner_enabled | | Identifiers: | CCE-87599-7 | | References: | | cis-csc | 1, 12, 15, 16 | | cobit5 | DSS05.04, DSS05.10, DSS06.10 | | cui | 3.1.9 | | disa | CCI-001387, CCI-001384, CCI-000048, CCI-001386, CCI-001388, CCI-001385 | | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | | nist | AC-8(a), AC-8(b), AC-8(c) | | nist-csf | PR.AC-7 | | os-srg | SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 | | ccn | A.11.SEC-RHEL4 | | cis | 1.8.2 | | stigid | RHEL-09-271010, RHEL-09-271015 | | stigref | SV-258012r1014855_rule, SV-258013r958390_rule |
| |
|
Rule
Modify the System Login Banner
[ref] |
To configure the system login banner edit /etc/issue. Replace the
default text with a message compliant with the local site policy or a legal
disclaimer.
The DoD required text is either:
You are accessing a U.S. Government (USG) Information System (IS) that
is provided for USG-authorized use only. By using this IS (which includes
any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS
for purposes including, but not limited to, penetration testing, COMSEC
monitoring, network operations and defense, personnel misconduct (PM), law
enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private,
are subject to routine monitoring, interception, and search, and may be
disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access
controls) to protect USG interests -- not for your personal benefit or
privacy.
-Notwithstanding the above, using this IS does not constitute consent
to PM, LE or CI investigative searching or monitoring of the content of
privileged communications, or work product, related to personal
representation or services by attorneys, psychotherapists, or clergy, and
their assistants. Such communications and work product are private and
confidential. See User Agreement for details.
OR:
I've read & consent to terms in IS user agreem't.
| | Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
System use notifications are required only for access via login interfaces
with human users and are not required when such human interfaces do not
exist. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_banner_etc_issue | | Identifiers: | CCE-83557-9 | | References: | | cis-csc | 1, 12, 15, 16 | | cobit5 | DSS05.04, DSS05.10, DSS06.10 | | cui | 3.1.9 | | disa | CCI-001387, CCI-001384, CCI-000048, CCI-001386, CCI-001388, CCI-001385 | | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | | nist | AC-8(a), AC-8(c) | | nist-csf | PR.AC-7 | | os-srg | SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 | | ccn | A.11.SEC-RHEL4 | | stigid | RHEL-09-211020 | | stigref | SV-257779r958390_rule |
| |
|
| Group
Protect Accounts by Configuring PAM
Group contains 4 groups and 28 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 9 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
Configure the Use of the pam_faillock.so Module in the /etc/pam.d/password-auth File.
[ref] | The pam_faillock.so module must be loaded in preauth in /etc/pam.d/password-auth. | | Rationale: | If the pam_faillock.so module is not loaded the system will not correctly lockout accounts to prevent
password guessing attacks. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_account_password_pam_faillock_password_auth | | Identifiers: | CCE-86932-1 | | References: | | |
|
Rule
Configure the Use of the pam_faillock.so Module in the /etc/pam.d/system-auth File.
[ref] | The pam_faillock.so module must be loaded in preauth in /etc/pam.d/system-auth. | | Rationale: | If the pam_faillock.so module is not loaded the system will not correctly lockout accounts to prevent
password guessing attacks. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_account_password_pam_faillock_system_auth | | Identifiers: | CCE-86917-2 | | References: | | |
|
Rule
An SELinux Context must be configured for the pam_faillock.so records directory
[ref] | The dir configuration option in PAM pam_faillock.so module defines where the lockout
records is stored. The configured directory must have the correct SELinux context. | | Rationale: | Not having the correct SELinux context on the pam_faillock.so records directory may lead to
unauthorized access to the directory. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_account_password_selinux_faillock_dir | | Identifiers: | CCE-86249-0 | | References: | | |
|
Rule
Account Lockouts Must Be Logged
[ref] | PAM faillock locks an account due to excessive password failures, this event must be logged. | | Rationale: | Without auditing of these events it may be harder or impossible to identify what an attacker did after an attack. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_audit | | Identifiers: | CCE-86100-5 | | References: | | |
|
Rule
Lock Accounts After Failed Password Attempts
[ref] | This rule configures the system to lock out accounts after a number of incorrect login attempts
using pam_faillock.so.
pam_faillock.so module requires multiple entries in pam files. These entries must be carefully
defined to work as expected.
Ensure that the file /etc/security/faillock.conf contains the following entry:
deny = <count>
Where count should be less than or equal to
3 and greater than 0.
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 | | Identifiers: | CCE-83587-6 | | 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 | | ccn | A.30.SEC-RHEL1 | | cis | 5.3.3.1.1 | | pcidss4 | 8.3.4, 8.3 | | stigid | RHEL-09-411075 | | stigref | SV-258054r958736_rule |
| |
|
Rule
Configure the root Account for Failed Password Attempts
[ref] | This rule configures the system to lock out the root account after a number of
incorrect login attempts using pam_faillock.so.
pam_faillock.so module requires multiple entries in pam files. These entries must be carefully
defined to work as expected. In order to avoid errors when manually editing these files, it is
recommended to use the appropriate tools, such as authselect or authconfig,
depending on the OS version. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
If the system supports the /etc/security/faillock.conf file, the pam_faillock
parameters should be defined in faillock.conf file. | | Rationale: | 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_root | | Identifiers: | CCE-83589-2 | | References: | | cis-csc | 1, 12, 15, 16 | | cobit5 | DSS05.04, DSS05.10, DSS06.10 | | disa | CCI-000044, CCI-002238 | | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | | nist | CM-6(a), AC-7(b), IA-5(c) | | nist-csf | PR.AC-7 | | os-srg | SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | | anssi | R31 | | cis | 5.3.3.1.3 | | stigid | RHEL-09-411080 | | stigref | SV-258055r958736_rule |
| |
|
Rule
Lock Accounts Must Persist
[ref] | This rule ensures that the system lock out accounts using pam_faillock.so persist
after system reboot. From "pam_faillock" man pages:
Note that the default directory that "pam_faillock" uses is usually cleared on system
boot so the access will be reenabled after system reboot. If that is undesirable, a different
tally directory must be set with the "dir" option.
pam_faillock.so module requires multiple entries in pam files. These entries must be carefully
defined to work as expected. In order to avoid errors when manually editing these files, it is
recommended to use the appropriate tools, such as authselect or authconfig,
depending on the OS version.
The chosen profile expects the directory to be /var/log/faillock. 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: | Locking out user accounts after a number of incorrect attempts prevents direct password
guessing attacks. In combination with the silent option, user enumeration attacks
are also mitigated. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_dir | | Identifiers: | CCE-86068-4 | | References: | | disa | CCI-000044 | | nist | AC-7(b), AC-7(a), AC-7.1(ii) | | os-srg | SRG-OS-000021-GPOS-00005, SRG-OS-000329-GPOS-00128 | | stigid | RHEL-09-411105 | | stigref | SV-258060r958388_rule |
| |
|
Rule
Set Interval For Counting Failed Password Attempts
[ref] | Utilizing pam_faillock.so, the fail_interval directive configures the system
to lock out an account after a number of incorrect login attempts within a specified time
period.
Ensure that the file /etc/security/faillock.conf contains the following entry:
fail_interval = <interval-in-seconds> where interval-in-seconds is 900 or greater.
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, otherwise known as brute-forcing, is reduced.
Limits are imposed by locking the account. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_interval | | Identifiers: | CCE-83583-5 | | References: | | cis-csc | 1, 12, 15, 16 | | cobit5 | DSS05.04, DSS05.10, DSS06.10 | | disa | CCI-000044, CCI-002238 | | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | | nist | CM-6(a), AC-7(a) | | nist-csf | PR.AC-7 | | ospp | FIA_AFL.1 | | os-srg | SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | | anssi | R31 | | stigid | RHEL-09-411085 | | stigref | SV-258056r958736_rule |
| |
|
Rule
Set Lockout Time for Failed Password Attempts
[ref] | This rule configures the system to lock out accounts during a specified time period after a
number of incorrect login attempts using pam_faillock.so.
Ensure that the file /etc/security/faillock.conf contains the following entry:
unlock_time=<interval-in-seconds> where
interval-in-seconds is 0 or greater.
pam_faillock.so module requires multiple entries in pam files. These entries must be carefully
defined to work as expected. In order to avoid any errors when manually editing these files,
it is recommended to use the appropriate tools, such as authselect or authconfig,
depending on the OS version.
If unlock_time is set to 0, manual intervention by an administrator is required
to unlock a user. This should be done using the faillock tool. Warning:
If the system supports the new /etc/security/faillock.conf file but the
pam_faillock.so parameters are defined directly in /etc/pam.d/system-auth and
/etc/pam.d/password-auth, the remediation will migrate the unlock_time parameter
to /etc/security/faillock.conf to ensure compatibility with authselect tool.
The parameters deny and fail_interval, if used, also have to be migrated
by their respective remediation. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
If the system supports the /etc/security/faillock.conf file, the pam_faillock
parameters should be defined in faillock.conf file. | | Rationale: | By limiting the number of failed logon attempts the risk of unauthorized system
access via user password guessing, otherwise known as brute-forcing, is reduced.
Limits are imposed by locking the account. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_unlock_time | | Identifiers: | CCE-83588-4 | | 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 | | ccn | A.30.SEC-RHEL1 | | cis | 5.3.3.1.2 | | pcidss4 | 8.3.4, 8.3 | | stigid | RHEL-09-411090 | | stigref | SV-258057r958736_rule |
| |
|