Group
Guide to the Secure Configuration of Red Hat Enterprise Linux 7
Group contains 100 groups and 377 rules |
Group
System Settings
Group contains 72 groups and 313 rules |
[ref]
Contains rules that check correct system settings. |
Group
Installing and Maintaining Software
Group contains 11 groups and 30 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 6 groups and 16 rules |
[ref]
System and software integrity can be gained by installing antivirus, increasing
system encryption strength with FIPS, verifying installed software, enabling SELinux,
installing an Intrusion Prevention System, etc. However, installing or enabling integrity
checking tools cannot prevent intrusions, but they can detect that an intrusion
may have occurred. Requirements for integrity checking may be highly dependent on
the environment in which the system will be used. Snapshot-based approaches such
as AIDE may induce considerable overhead in the presence of frequent software updates. |
Group
Software Integrity Checking
Group contains 2 groups and 10 rules |
[ref]
Both the AIDE (Advanced Intrusion Detection Environment)
software and the RPM package management system provide
mechanisms for verifying the integrity of installed software.
AIDE uses snapshots of file metadata (such as hashes) and compares these
to current system files in order to detect changes.
The RPM package management system can conduct integrity
checks by comparing information in its metadata database with
files installed on the system. |
Group
Verify Integrity with RPM
Group contains 3 rules |
[ref]
The RPM package management system includes the ability
to verify the integrity of installed packages by comparing the
installed files with information about the files taken from the
package metadata stored in the RPM database. Although an attacker
could corrupt the RPM database (analogous to attacking the AIDE
database as described above), this check can still reveal
modification of important files. To list which files on the system differ from what is expected by the RPM database:
$ rpm -qVa
See the man page for rpm to see a complete explanation of each column. |
Rule
Verify File Hashes with RPM
[ref] | Without cryptographic integrity protections, system
executables and files can be altered by unauthorized users without
detection.
The RPM package management system can check the hashes of
installed software packages, including many that are important to system
security.
To verify that the cryptographic hash of system files and commands matches vendor
values, run the following command to list which files on the system
have hashes that differ from what is expected by the RPM database:
$ rpm -Va --noconfig | grep '^..5'
A "c" in the second column indicates that a file is a configuration file, which
may appropriately be expected to change. If the file was not expected to
change, investigate the cause of the change using audit logs or other means.
The package can then be reinstalled to restore the file.
Run the following command to determine which package owns the file:
$ rpm -qf FILENAME
The package can be reinstalled from a yum repository using the command:
$ sudo yum reinstall PACKAGENAME
Alternatively, the package can be reinstalled from trusted media using the command:
$ sudo rpm -Uvh PACKAGENAME | Rationale: | The hashes of important files like system executables should match the
information given by the RPM database. Executables with erroneous hashes could
be a sign of nefarious activity on the system. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_rpm_verify_hashes | Identifiers and References | Identifiers:
CCE-27157-7 References:
11, 2, 3, 9, 5.10.4.1, APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02, 3.3.8, 3.4.1, CCI-000366, CCI-001749, 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i), 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6, 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, CM-6(d), CM-6(c), SI-7, SI-7(1), SI-7(6), AU-9(3), PR.DS-6, PR.DS-8, PR.IP-1, Req-11.5, 11.5.2, SRG-OS-000480-GPOS-00227, RHEL-07-010020, 6.1.1, SV-214799r854001_rule | |
|
Rule
Verify and Correct Ownership with RPM
[ref] | The RPM package management system can check file ownership
permissions of installed software packages, including many that are
important to system security. After locating a file with incorrect
permissions, which can be found with
rpm -Va | awk '{ if (substr($0,6,1)=="U" || substr($0,7,1)=="G") print $NF }'
run the following command to determine which package owns it:
$ rpm -qf FILENAME
Next, run the following command to reset its permissions to
the correct values:
$ sudo rpm --setugids PACKAGENAME Warning:
Profiles may require that specific files be owned by root while the default owner defined
by the vendor is different.
Such files will be reported as a finding and need to be evaluated according to your policy
and deployment environment. | Rationale: | Ownership of binaries and configuration files that is incorrect
could allow an unauthorized user to gain privileges that they should
not have. The ownership set by the vendor should be maintained. Any
deviations from this baseline should be investigated. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_rpm_verify_ownership | Identifiers and References | Identifiers:
CCE-80545-7 References:
1, 11, 12, 13, 14, 15, 16, 18, 3, 5, 6, 9, 5.10.4.1, APO01.06, APO11.04, BAI03.05, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.04, DSS05.07, DSS06.02, MEA02.01, 3.3.8, 3.4.1, CCI-001494, CCI-001496, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.7.3, 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 5.2, SR 7.6, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.2, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.5.1, A.12.6.2, A.12.7.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-003-8 R4.2, CIP-003-8 R6, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CM-6(d), CM-6(c), SI-7, SI-7(1), SI-7(6), AU-9(3), PR.AC-4, PR.DS-5, PR.IP-1, PR.PT-1, Req-11.5, 11.5.2, SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000278-GPOS-00108, RHEL-07-010010, 1.7.1.4, 1.7.1.5, 1.7.1.6, 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, SV-204392r880752_rule | |
|
Rule
Verify and Correct File Permissions with RPM
[ref] | The RPM package management system can check file access permissions
of installed software packages, including many that are important
to system security.
Verify that the file permissions of system files
and commands match vendor values. Check the file permissions
with the following command:
$ sudo rpm -Va | awk '{ if (substr($0,2,1)=="M") print $NF }'
Output indicates files that do not match vendor defaults.
After locating a file with incorrect permissions,
run the following command to determine which package owns it:
$ rpm -qf FILENAME
Next, run the following command to reset its permissions to
the correct values:
$ sudo rpm --setperms PACKAGENAME Warning:
Profiles may require that specific files have stricter file permissions than defined by the
vendor.
Such files will be reported as a finding and need to be evaluated according to your policy
and deployment environment. | Rationale: | Permissions on system binaries and configuration files that are too generous
could allow an unauthorized user to gain privileges that they should not have.
The permissions set by the vendor should be maintained. Any deviations from
this baseline should be investigated. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_rpm_verify_permissions | Identifiers and References | Identifiers:
CCE-27209-6 References:
1, 11, 12, 13, 14, 15, 16, 18, 3, 5, 6, 9, 5.10.4.1, APO01.06, APO11.04, BAI03.05, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.04, DSS05.07, DSS06.02, MEA02.01, 3.3.8, 3.4.1, CCI-001493, CCI-001494, CCI-001495, CCI-001496, 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i), 4.3.3.3.9, 4.3.3.5.8, 4.3.3.7.3, 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 5.2, SR 7.6, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.2, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.5.1, A.12.6.2, A.12.7.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-003-8 R4.2, CIP-003-8 R6, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CM-6(d), CM-6(c), SI-7, SI-7(1), SI-7(6), AU-9(3), CM-6(a), PR.AC-4, PR.DS-5, PR.IP-1, PR.PT-1, Req-11.5, 11.5.2, SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099, SRG-OS-000278-GPOS-00108, RHEL-07-010010, 1.7.1.4, 1.7.1.5, 1.7.1.6, 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, SV-204392r880752_rule | |
|
Group
Verify Integrity with AIDE
Group contains 7 rules |
[ref]
AIDE conducts integrity checks by comparing information about
files with previously-gathered information. Ideally, the AIDE database is
created immediately after initial system configuration, and then again after any
software update. AIDE is highly configurable, with further configuration
information located in /usr/share/doc/aide-VERSION . |
Rule
Install AIDE
[ref] | The aide package can be installed with the following command:
$ sudo yum install aide | Rationale: | The AIDE package must be installed if it is to be available for integrity checking. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_aide_installed | Identifiers and References | Identifiers:
CCE-27096-7 References:
BP28(R51), 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9, 5.10.1.3, 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, CCI-002696, CCI-002699, CCI-001744, 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6, 1034, 1288, 1341, 1417, 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, CM-6(a), DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3, Req-11.5, 11.5.2, SRG-OS-000445-GPOS-00199, RHEL-07-020029, 1.3.1, SV-251705r880854_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 and References | Identifiers:
CCE-27220-3 References:
BP28(R51), 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9, 5.10.1.3, 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, 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6, 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, CM-6(a), DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3, Req-11.5, 11.5.2, SRG-OS-000445-GPOS-00199, RHEL-07-020029, 1.3.1, SV-251705r880854_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 and References | Identifiers:
CCE-26952-2 References:
BP28(R51), 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9, 5.10.1.3, 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, CCI-001744, CCI-002699, CCI-002702, 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6, 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, SI-7, SI-7(1), CM-6(a), DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3, Req-11.5, 11.5.2, SRG-OS-000363-GPOS-00150, SRG-OS-000446-GPOS-00200, SRG-OS-000447-GPOS-00201, RHEL-07-020030, 1.3.2, SV-204445r902698_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 and References | Identifiers:
CCE-80374-2 References:
BP28(R51), 1, 11, 12, 13, 15, 16, 2, 3, 5, 7, 8, 9, BAI01.06, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, CCI-001744, CCI-002699, CCI-002702, 4.3.4.3.2, 4.3.4.3.3, SR 6.2, SR 7.6, 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, CM-6(a), CM-3(5), DE.CM-1, DE.CM-7, PR.IP-1, PR.IP-3, SRG-OS-000363-GPOS-00150, SRG-OS-000446-GPOS-00200, SRG-OS-000447-GPOS-00201, RHEL-07-020040, SV-204446r902701_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 and References | Identifiers:
CCE-80377-5 References:
2, 3, APO01.06, BAI03.05, BAI06.01, DSS06.02, 3.13.11, CCI-000366, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, A.11.2.4, A.12.2.1, A.12.5.1, A.14.1.2, A.14.1.3, A.14.2.4, SI-7, SI-7(1), CM-6(a), PR.DS-6, PR.DS-8, SRG-OS-000480-GPOS-00227, RHEL-07-021620, SV-204500r880860_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 and References | Identifiers:
CCE-80375-9 References:
BP28(R51), 2, 3, APO01.06, BAI03.05, BAI06.01, DSS06.02, CCI-000366, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, A.11.2.4, A.12.2.1, A.12.5.1, A.14.1.2, A.14.1.3, A.14.2.4, SI-7, SI-7(1), CM-6(a), PR.DS-6, PR.DS-8, SRG-OS-000480-GPOS-00227, RHEL-07-021600, SV-204498r880856_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 and References | Identifiers:
CCE-80376-7 References:
BP28(R51), 2, 3, APO01.06, BAI03.05, BAI06.01, DSS06.02, CCI-000366, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, A.11.2.4, A.12.2.1, A.12.5.1, A.14.1.2, A.14.1.3, A.14.2.4, SI-7, SI-7(1), CM-6(a), PR.DS-6, PR.DS-8, SRG-OS-000480-GPOS-00227, RHEL-07-021610, SV-204499r880858_rule | |
|
Group
Federal Information Processing Standard (FIPS)
Group contains 2 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 7.
See http://csrc.nist.gov/publications/PubsFIPS.html for more information. |
Rule
Install the dracut-fips Package
[ref] | To enable FIPS, the system requires that the dracut-fips
package be installed.
The dracut-fips package can be installed with the following command:
$ sudo yum install dracut-fips 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: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_dracut-fips_installed | Identifiers and References | Identifiers:
CCE-80358-5 References:
12, 15, 8, 5.10.1.2, APO13.01, DSS01.04, DSS05.02, DSS05.03, 3.13.11, 3.13.8, CCI-000068, CCI-000803, CCI-002450, 4.3.3.6.6, SR 1.13, SR 2.6, 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, A.11.2.6, A.13.1.1, A.13.2.1, A.14.1.3, A.6.2.1, A.6.2.2, CIP-003-8 R4.2, CIP-007-3 R5.1, SC-12(2), SC-12(3), IA-7, SC-13, CM-6(a), SC-12, PR.AC-3, PR.PT-4, SRG-OS-000033-GPOS-00014, SRG-OS-000396-GPOS-00176, SRG-OS-000478-GPOS-00223 | |
|
Rule
Enable FIPS Mode in GRUB2
[ref] | To ensure FIPS mode is enabled, install package dracut-fips , and rebuild initramfs by running the following commands:
$ sudo yum install dracut-fips
dracut -f
After the dracut command has been run, add the argument fips=1 to the default
GRUB 2 command line for the Linux operating system in
/etc/default/grub , in the manner below:
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 fips=1"
Finally, rebuild the grub.cfg file by using the
grub2-mkconfig -o command as follows:
Warning:
Running dracut -f will overwrite the existing initramfs file. 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_grub2_enable_fips_mode | Identifiers and References | Identifiers:
CCE-80359-3 References:
12, 15, 8, 5.10.1.2, APO13.01, DSS01.04, DSS05.02, DSS05.03, 3.13.8, 3.13.11, CCI-000068, CCI-000803, CCI-001199, CCI-002450, CCI-002476, 4.3.3.6.6, SR 1.13, SR 2.6, 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, A.11.2.6, A.13.1.1, A.13.2.1, A.14.1.3, A.6.2.1, A.6.2.2, CIP-003-8 R4.2, CIP-007-3 R5.1, SC-12(2), SC-12(3), IA-7, SC-13, CM-6(a), SC-12, PR.AC-3, PR.PT-4, SRG-OS-000033-GPOS-00014, SRG-OS-000185-GPOS-00079, SRG-OS-000396-GPOS-00176, SRG-OS-000405-GPOS-00184, SRG-OS-000478-GPOS-00223, RHEL-07-021350, SV-204497r877398_rule | Remediation Ansible snippet ⇲Complexity: | high |
---|
Disruption: | medium |
---|
Reboot: | true |
---|
Strategy: | restrict |
---|
- name: Gather the package facts
package_facts:
manager: auto
tags:
- CCE-80359-3
- CJIS-5.10.1.2
- DISA-STIG-RHEL-07-021350
- NIST-800-171-3.13.11
- NIST-800-171-3.13.8
- NIST-800-53-CM-6(a)
- NIST-800-53-IA-7
- NIST-800-53-SC-12
- NIST-800-53-SC-12(2)
- NIST-800-53-SC-12(3)
- NIST-800-53-SC-13
- grub2_enable_fips_mode
- high_complexity
- high_severity
- medium_disruption
- reboot_required
- restrict_strategy
- name: Check prelink binary installed
stat:
path: /usr/sbin/prelink
register: prelink_exists
when:
- ( ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
and not ( lookup("env", "container") == "bwrap-osbuild" ) )
- '"grub2-common" in ansible_facts.packages'
tags:
- CCE-80359-3
- CJIS-5.10.1.2
- DISA-STIG-RHEL-07-021350
- NIST-800-171-3.13.11
- NIST-800-171-3.13.8
- NIST-800-53-CM-6(a)
- NIST-800-53-IA-7
- NIST-800-53-SC-12
- NIST-800-53-SC-12(2)
- NIST-800-53-SC-12(3)
- NIST-800-53-SC-13
- grub2_enable_fips_mode
- high_complexity
- high_severity
- medium_disruption
- reboot_required
- restrict_strategy
- name: Disable prelink
lineinfile:
dest: /etc/sysconfig/prelink
regexp: ^#?PRELINKING
line: PRELINKING=no
when:
- ( ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
and not ( lookup("env", "container") == "bwrap-osbuild" ) )
- '"grub2-common" in ansible_facts.packages'
- prelink_exists.stat.exists
tags:
- CCE-80359-3
- CJIS-5.10.1.2
- DISA-STIG-RHEL-07-021350
- NIST-800-171-3.13.11
- NIST-800-171-3.13.8
- NIST-800-53-CM-6(a)
- NIST-800-53-IA-7
- NIST-800-53-SC-12
- NIST-800-53-SC-12(2)
- NIST-800-53-SC-12(3)
- NIST-800-53-SC-13
- grub2_enable_fips_mode
- high_complexity
- high_severity
- medium_disruption
- reboot_required
- restrict_strategy
- name: Revert prelinking binaries
command: /usr/sbin/prelink -ua
when:
- ( ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
and not ( lookup("env", "container") == "bwrap-osbuild" ) )
- '"grub2-common" in ansible_facts.packages'
- prelink_exists.stat.exists
tags:
- CCE-80359-3
- CJIS-5.10.1.2
- DISA-STIG-RHEL-07-021350
- NIST-800-171-3.13.11
- NIST-800-171-3.13.8
- NIST-800-53-CM-6(a)
- NIST-800-53-IA-7
- NIST-800-53-SC-12
- NIST-800-53-SC-12(2)
- NIST-800-53-SC-12(3)
- NIST-800-53-SC-13
- grub2_enable_fips_mode
- high_complexity
- high_severity
- medium_disruption
- reboot_required
- restrict_strategy
- name: Check if system supports AES-NI
command: grep -q -m1 -o aes /proc/cpuinfo
failed_when: aesni_supported.rc > 1
register: aesni_supported
check_mode: false
when:
- ( ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
and not ( lookup("env", "container") == "bwrap-osbuild" ) )
- '"grub2-common" in ansible_facts.packages'
tags:
- CCE-80359-3
- CJIS-5.10.1.2
- DISA-STIG-RHEL-07-021350
- NIST-800-171-3.13.11
- NIST-800-171-3.13.8
- NIST-800-53-CM-6(a)
- NIST-800-53-IA-7
- NIST-800-53-SC-12
- NIST-800-53-SC-12(2)
- NIST-800-53-SC-12(3)
- NIST-800-53-SC-13
- grub2_enable_fips_mode
- high_complexity
- high_severity
- medium_disruption
- reboot_required
- restrict_strategy
- name: Ensure dracut-fips-aesni is installed
package:
name: dracut-fips-aesni
state: present
when:
- ( ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
and not ( lookup("env", "container") == "bwrap-osbuild" ) )
- '"grub2-common" in ansible_facts.packages'
- aesni_supported.rc == 0
tags:
- CCE-80359-3
- CJIS-5.10.1.2
- DISA-STIG-RHEL-07-021350
- NIST-800-171-3.13.11
- NIST-800-171-3.13.8
- NIST-800-53-CM-6(a)
- NIST-800-53-IA-7
- NIST-800-53-SC-12
- NIST-800-53-SC-12(2)
- NIST-800-53-SC-12(3)
- NIST-800-53-SC-13
- grub2_enable_fips_mode
- high_complexity
- high_severity
- medium_disruption
- reboot_required
- restrict_strategy
- name: Install dracut-fips
package:
name: dracut-fips
state: present
when:
- ( ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
and not ( lookup("env", "container") == "bwrap-osbuild" ) )
- '"grub2-common" in ansible_facts.packages'
tags:
- CCE-80359-3
- CJIS-5.10.1.2
- DISA-STIG-RHEL-07-021350
- NIST-800-171-3.13.11
- NIST-800-171-3.13.8
- NIST-800-53-CM-6(a)
- NIST-800-53-IA-7
- NIST-800-53-SC-12
- NIST-800-53-SC-12(2)
- NIST-800-53-SC-12(3)
- NIST-800-53-SC-13
- grub2_enable_fips_mode
- high_complexity
- high_severity
- medium_disruption
- reboot_required
- restrict_strategy
- name: Rebuild initramfs
command: dracut -f
when:
- ( ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
and not ( lookup("env", "container") == "bwrap-osbuild" ) )
- '"grub2-common" in ansible_facts.packages'
tags:
- CCE-80359-3
- CJIS-5.10.1.2
- DISA-STIG-RHEL-07-021350
- NIST-800-171-3.13.11
- NIST-800-171-3.13.8
- NIST-800-53-CM-6(a)
- NIST-800-53-IA-7
- NIST-800-53-SC-12
- NIST-800-53-SC-12(2)
- NIST-800-53-SC-12(3)
- NIST-800-53-SC-13
- grub2_enable_fips_mode
- high_complexity
- high_severity
- medium_disruption
- reboot_required
- restrict_strategy
- name: Check fips argument exists
command: grep 'GRUB_CMDLINE_LINUX.*fips=' /etc/default/grub
failed_when: false
register: fipsargcheck
check_mode: false
when:
- ( ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
and not ( lookup("env", "container") == "bwrap-osbuild" ) )
- '"grub2-common" in ansible_facts.packages'
tags:
- CCE-80359-3
- CJIS-5.10.1.2
- DISA-STIG-RHEL-07-021350
- NIST-800-171-3.13.11
- NIST-800-171-3.13.8
- NIST-800-53-CM-6(a)
- NIST-800-53-IA-7
- NIST-800-53-SC-12
- NIST-800-53-SC-12(2)
- NIST-800-53-SC-12(3)
- NIST-800-53-SC-13
- grub2_enable_fips_mode
- high_complexity
- high_severity
- medium_disruption
- reboot_required
- restrict_strategy
- name: Replace existing fips argument
replace:
path: /etc/default/grub
regexp: fips=.
replace: fips=1
when:
- ( ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
and not ( lookup("env", "container") == "bwrap-osbuild" ) )
- '"grub2-common" in ansible_facts.packages'
- fipsargcheck.rc == 0
tags:
- CCE-80359-3
- CJIS-5.10.1.2
- DISA-STIG-RHEL-07-021350
- NIST-800-171-3.13.11
- NIST-800-171-3.13.8
- NIST-800-53-CM-6(a)
- NIST-800-53-IA-7
- NIST-800-53-SC-12
- NIST-800-53-SC-12(2)
- NIST-800-53-SC-12(3)
- NIST-800-53-SC-13
- grub2_enable_fips_mode
- high_complexity
- high_severity
- medium_disruption
- reboot_required
- restrict_strategy
- name: Add fips argument
replace:
path: /etc/default/grub
regexp: (GRUB_CMDLINE_LINUX=.*)"
replace: \1 fips=1"
when:
- ( ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
and not ( lookup("env", "container") == "bwrap-osbuild" ) )
- '"grub2-common" in ansible_facts.packages'
- fipsargcheck.rc != 0
tags:
- CCE-80359-3
- CJIS-5.10.1.2
- DISA-STIG-RHEL-07-021350
- NIST-800-171-3.13.11
- NIST-800-171-3.13.8
- NIST-800-53-CM-6(a)
- NIST-800-53-IA-7
- NIST-800-53-SC-12
- NIST-800-53-SC-12(2)
- NIST-800-53-SC-12(3)
- NIST-800-53-SC-13
- grub2_enable_fips_mode
- high_complexity
- high_severity
- medium_disruption
- reboot_required
- restrict_strategy
- name: Get boot device uuid
command: findmnt --noheadings --output uuid --target /boot
register: bootuuid
check_mode: false
when:
- ( ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
and not ( lookup("env", "container") == "bwrap-osbuild" ) )
- '"grub2-common" in ansible_facts.packages'
tags:
- CCE-80359-3
- CJIS-5.10.1.2
- DISA-STIG-RHEL-07-021350
- NIST-800-171-3.13.11
- NIST-800-171-3.13.8
- NIST-800-53-CM-6(a)
- NIST-800-53-IA-7
- NIST-800-53-SC-12
- NIST-800-53-SC-12(2)
- NIST-800-53-SC-12(3)
- NIST-800-53-SC-13
- grub2_enable_fips_mode
- high_complexity
- high_severity
- medium_disruption
- reboot_required
- restrict_strategy
- name: Check boot argument exists
command: grep 'GRUB_CMDLINE_LINUX.*boot=' /etc/default/grub
failed_when: false
register: bootargcheck
check_mode: false
when:
- ( ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
and not ( lookup("env", "container") == "bwrap-osbuild" ) )
- '"grub2-common" in ansible_facts.packages'
tags:
- CCE-80359-3
- CJIS-5.10.1.2
- DISA-STIG-RHEL-07-021350
- NIST-800-171-3.13.11
- NIST-800-171-3.13.8
- NIST-800-53-CM-6(a)
- NIST-800-53-IA-7
- NIST-800-53-SC-12
- NIST-800-53-SC-12(2)
- NIST-800-53-SC-12(3)
- NIST-800-53-SC-13
- grub2_enable_fips_mode
- high_complexity
- high_severity
- medium_disruption
- reboot_required
- restrict_strategy
- name: Replace existing boot argument
replace:
path: /etc/default/grub
regexp: boot=\w*-\w*-\w*-\w*-\w*
replace: boot={{ bootuuid.stdout }}
when:
- ( ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
and not ( lookup("env", "container") == "bwrap-osbuild" ) )
- '"grub2-common" in ansible_facts.packages'
- bootargcheck.rc == 0
tags:
- CCE-80359-3
- CJIS-5.10.1.2
- DISA-STIG-RHEL-07-021350
- NIST-800-171-3.13.11
- NIST-800-171-3.13.8
- NIST-800-53-CM-6(a)
- NIST-800-53-IA-7
- NIST-800-53-SC-12
- NIST-800-53-SC-12(2)
- NIST-800-53-SC-12(3)
- NIST-800-53-SC-13
- grub2_enable_fips_mode
- high_complexity
- high_severity
- medium_disruption
- reboot_required
- restrict_strategy
- name: Add boot argument
replace:
path: /etc/default/grub
regexp: (GRUB_CMDLINE_LINUX=.*)"
replace: \1 boot=UUID={{ bootuuid.stdout }}"
when:
- ( ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
and not ( lookup("env", "container") == "bwrap-osbuild" ) )
- '"grub2-common" in ansible_facts.packages'
- bootargcheck.rc != 0
tags:
- CCE-80359-3
- CJIS-5.10.1.2
- DISA-STIG-RHEL-07-021350
- NIST-800-171-3.13.11
- NIST-800-171-3.13.8
- NIST-800-53-CM-6(a)
- NIST-800-53-IA-7
- NIST-800-53-SC-12
- NIST-800-53-SC-12(2)
- NIST-800-53-SC-12(3)
- NIST-800-53-SC-13
- grub2_enable_fips_mode
- high_complexity
- high_severity
- medium_disruption
- reboot_required
- restrict_strategy
- name: Update bootloader menu
command: /sbin/grubby --update-kernel=ALL --args="fips=1 boot=UUID={{ bootuuid.stdout
}}"
when:
- ( ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
and not ( lookup("env", "container") == "bwrap-osbuild" ) )
- '"grub2-common" in ansible_facts.packages'
tags:
- CCE-80359-3
- CJIS-5.10.1.2
- DISA-STIG-RHEL-07-021350
- NIST-800-171-3.13.11
- NIST-800-171-3.13.8
- NIST-800-53-CM-6(a)
- NIST-800-53-IA-7
- NIST-800-53-SC-12
- NIST-800-53-SC-12(2)
- NIST-800-53-SC-12(3)
- NIST-800-53-SC-13
- grub2_enable_fips_mode
- high_complexity
- high_severity
- medium_disruption
- reboot_required
- restrict_strategy
Remediation Shell script ⇲# Remediation is applicable only in certain platforms
if ( [ ! -f /.dockerenv ] && [ ! -f /run/.containerenv ] && ! ( [ "${container:-}" == "bwrap-osbuild" ] ) ) && { rpm --quiet -q grub2-common; }; then
# prelink not installed
if test -e /etc/sysconfig/prelink -o -e /usr/sbin/prelink; then
if grep -q ^PRELINKING /etc/sysconfig/prelink
then
sed -i 's/^PRELINKING[:blank:]*=[:blank:]*[:alpha:]*/PRELINKING=no/' /etc/sysconfig/prelink
else
printf '\n' >> /etc/sysconfig/prelink
printf '%s\n' '# Set PRELINKING=no per security requirements' 'PRELINKING=no' >> /etc/sysconfig/prelink
fi
# Undo previous prelink changes to binaries if prelink is available.
if test -x /usr/sbin/prelink; then
/usr/sbin/prelink -ua
fi
fi
if grep -q -m1 -o aes /proc/cpuinfo; then
if ! rpm -q --quiet "dracut-fips-aesni" ; then
yum install -y "dracut-fips-aesni"
fi
fi
if ! rpm -q --quiet "dracut-fips" ; then
yum install -y "dracut-fips"
fi
dracut -f
# Correct the form of default kernel command line in grub
if grep -q '^GRUB_CMDLINE_LINUX=.*fips=.*"' /etc/default/grub; then
# modify the GRUB command-line if a fips= arg already exists
sed -i 's/\(^GRUB_CMDLINE_LINUX=".*\)fips=[^[:space:]]*\(.*"\)/\1 fips=1 \2/' /etc/default/grub
else
# no existing fips=arg is present, append it
sed -i 's/\(^GRUB_CMDLINE_LINUX=".*\)"/\1 fips=1"/' /etc/default/grub
fi
# Get the UUID of the device mounted at root (/).
ROOT_UUID=$(findmnt --noheadings --output uuid --target /)
# Get the UUID of the device mounted at /boot.
BOOT_UUID=$(findmnt --noheadings --output uuid --target /boot)
if [ "${ROOT_UUID}" == "${BOOT_UUID}" ]; then
# root UUID same as boot UUID, so do not modify the GRUB command-line or add boot arg to kernel command line
# Correct the form of kernel command line for each installed kernel in the bootloader
/sbin/grubby --update-kernel=ALL --args="fips=1"
else
# root UUID different from boot UUID, so modify the GRUB command-line and add boot arg to kernel command line
if grep -q '^GRUB_CMDLINE_LINUX=".*boot=.*"' /etc/default/grub; then
# modify the GRUB command-line if a boot= arg already exists
sed -i 's/\(^GRUB_CMDLINE_LINUX=".*\)boot=[^[:space:]]*\(.*"\)/\1 boot=UUID='"${BOOT_UUID} \2/" /etc/default/grub
else
# no existing boot=arg is present, append it
sed -i 's/\(^GRUB_CMDLINE_LINUX=".*\)"/\1 boot=UUID='${BOOT_UUID}'"/' /etc/default/grub
fi
# Correct the form of kernel command line for each installed kernel in the bootloader
/sbin/grubby --update-kernel=ALL --args="fips=1 boot=UUID=${BOOT_UUID}"
fi
else
>&2 echo 'Remediation is not applicable, nothing was done'
fi
Remediation Anaconda snippet ⇲
package --add=dracut-fips --add=dracut-fips-aesni
|
|
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 FIPS 140-2 Certified
[ref] | To enable processing of sensitive information the operating system must
provide certified cryptographic modules compliant with FIPS 140-2
standard.
Red Hat Enterprise Linux is supported by Red Hat, Inc. As the Red Hat Enterprise
Linux vendor, Red Hat, Inc. is responsible for maintaining government certifications and standards. Warning:
There is no remediation besides switching to a different operating system. 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: | The Federal Information Processing Standard (FIPS) Publication 140-2, (FIPS
PUB 140-2) is a computer security standard. The standard specifies security
requirements for cryptographic modules used to protect sensitive
unclassified information. Refer to the full FIPS 140-2 standard at
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
for further details on the requirements.
FIPS 140-2 validation is required by U.S. law when information systems use
cryptography to protect sensitive government information. In order to
achieve FIPS 140-2 certification, cryptographic modules are subject to
extensive testing by independent laboratories, accredited by National
Institute of Standards and Technology (NIST). | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_installed_OS_is_FIPS_certified | Identifiers and References | Identifiers:
CCE-80657-0 References:
CCI-000803, CCI-002450, CIP-003-8 R4.2, CIP-007-3 R5.1, SC-12(2), SC-12(3), IA-7, SC-13, CM-6(a), SC-12 | |
|
Group
Endpoint Protection Software
Group contains 2 rules |
[ref]
Endpoint protection security software that is not provided or supported
by Red Hat can be installed to provide complementary or duplicative
security capabilities to those provided by the base platform. Add-on
software may not be appropriate for some specialized systems. |
Rule
Install Virus Scanning Software
[ref] | Virus scanning software can be used to protect a system from penetration from
computer viruses and to limit their spread through intermediate systems.
The virus scanning software should be configured to perform scans dynamically
on accessed files. If this capability is not available, the system must be
configured to scan, at a minimum, all altered files on the system on a daily
basis.
If the system processes inbound SMTP mail, the virus scanner must be configured
to scan all received mail. | Rationale: | Virus scanning software can be used to detect if a system has been compromised by
computer viruses, as well as to limit their spread to other systems. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_install_antivirus | Identifiers and References | Identifiers:
CCE-27140-3 References:
12, 13, 14, 4, 7, 8, APO01.06, APO13.02, BAI02.01, BAI06.01, DSS04.07, DSS05.01, DSS05.02, DSS05.03, DSS06.06, CCI-000366, CCI-001239, CCI-001668, 4.3.4.3.8, 4.4.3.2, SR 3.2, SR 3.3, SR 3.4, SR 4.1, A.12.2.1, A.14.2.8, A.8.2.3, CM-6(a), DE.CM-4, DE.DP-3, PR.DS-1, SRG-OS-000480-GPOS-00227, RHEL-07-032000, SV-214801r854324_rule | |
|
Rule
Install Intrusion Detection Software
[ref] | The base Red Hat Enterprise Linux 7 platform already includes a sophisticated auditing system that
can detect intruder activity, as well as SELinux, which provides host-based
intrusion prevention capabilities by confining privileged programs and user
sessions which may become compromised. Warning:
In DoD environments, supplemental intrusion detection and antivirus tools,
such as the McAfee Host-based Security System, are available to integrate with
existing infrastructure. Per DISA guidance, when these supplemental tools interfere
with proper functioning of SELinux, SELinux takes precedence. Should further
clarification be required, DISA contact information is published publicly at
https://public.cyber.mil/stigs/ | Rationale: | Host-based intrusion detection tools provide a system-level defense when an
intruder gains access to a system or network. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_install_hids | Identifiers and References | Identifiers:
CCE-26818-5 References:
1, 12, 13, 14, 15, 16, 18, 7, 8, 9, APO01.06, APO13.01, DSS01.03, DSS01.05, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02, CCI-001263, 4.3.3.4, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.6, 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, CM-6(a), DE.CM-1, PR.AC-5, PR.DS-5, PR.PT-4, Req-11.4, 11.5.1.1 | |
|
Rule
Disable Prelinking
[ref] | The prelinking feature changes binaries in an attempt to decrease their startup
time. In order to disable it, change or add the following line inside the file
/etc/sysconfig/prelink :
PRELINKING=no
Next, run the following command to return binaries to a normal, non-prelinked state:
$ sudo /usr/sbin/prelink -ua | Rationale: | Because the prelinking feature changes binaries, it can interfere with the
operation of certain software and/or modes such as AIDE, FIPS, etc. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_disable_prelink | Identifiers and References | Identifiers:
CCE-27078-5 References:
11, 13, 14, 2, 3, 9, 5.10.1.3, APO01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS04.07, DSS05.03, DSS06.02, DSS06.06, 3.13.11, CCI-000803, CCI-002450, 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 7.6, 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, A.8.2.3, CIP-003-8 R4.2, CIP-007-3 R5.1, SC-13, CM-6(a), PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, Req-11.5, 11.5.2, 1.5.4 | |
|
Group
Disk Partitioning
Group contains 5 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.
See the LVM HOWTO at
http://tldp.org/HOWTO/LVM-HOWTO/
for more detailed information on LVM. |
Rule
Encrypt Partitions
[ref] | Red Hat Enterprise Linux 7 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 7 Documentation web site:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-encryption
. | 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 and References | Identifiers:
CCE-27128-8 References:
13, 14, APO01.06, BAI02.01, BAI06.01, DSS04.07, DSS05.03, DSS05.04, DSS05.07, DSS06.02, DSS06.06, 3.13.16, CCI-001199, CCI-002475, CCI-002476, 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), SR 3.4, SR 4.1, SR 5.2, 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, CIP-003-8 R4.2, CIP-007-3 R5.1, CM-6(a), SC-28, SC-28(1), SC-13, AU-9(3), PR.DS-1, PR.DS-5, SRG-OS-000405-GPOS-00184, SRG-OS-000185-GPOS-00079, SRG-OS-000404-GPOS-00183 | |
|
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 and References | Identifiers:
CCE-80144-9 References:
BP28(R12), 12, 15, 8, APO13.01, DSS05.02, CCI-000366, CCI-001208, 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, A.13.1.1, A.13.2.1, A.14.1.3, CM-6(a), SC-5(2), PR.PT-4, SRG-OS-000480-GPOS-00227, RHEL-07-021310, 1.1.17, SV-204493r603840_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 and References | Identifiers:
CCE-82053-0 References:
BP28(R12), 12, 15, 8, APO13.01, DSS05.02, CCI-000366, 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, A.13.1.1, A.13.2.1, A.14.1.3, CM-6(a), SC-5(2), PR.PT-4, SRG-OS-000480-GPOS-00227, RHEL-07-021340, 1.1.2, SV-204496r603261_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 and References | Identifiers:
CCE-82014-2 References:
BP28(R12), 12, 15, 8, APO13.01, DSS05.02, CCI-000366, 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, A.13.1.1, A.13.2.1, A.14.1.3, CM-6(a), SC-5(2), PR.PT-4, SRG-OS-000480-GPOS-00227, RHEL-07-021320, 1.1.10, SV-204494r603261_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 and References | Identifiers:
CCE-82035-7 References:
BP28(R43), 1, 12, 13, 14, 15, 16, 2, 3, 5, 6, 8, APO11.04, APO13.01, BAI03.05, BAI04.04, DSS05.02, DSS05.04, DSS05.07, MEA02.01, CCI-000366, CCI-001849, 164.312(a)(2)(ii), 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, 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, 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, CIP-007-3 R6.5, CM-6(a), AU-4, SC-5(2), PR.DS-4, PR.PT-1, PR.PT-4, FMT_SMF_EXT.1, SRG-OS-000341-GPOS-00132, SRG-OS-000480-GPOS-00227, SRG-APP-000357-CTR-000800, RHEL-07-021330, 1.1.16, SV-204495r603261_rule | |
|
Group
GNOME Desktop Environment
Group contains 1 rule |
[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. |
Rule
Remove the GDM Package Group
[ref] |
By removing the gdm package, the system no longer has GNOME installed
installed. If X Windows is not installed then the system cannot boot into graphical user mode.
This prevents the system from being accidentally or maliciously booted into a graphical.target
mode. To do so, run the following command:
$ sudo yum remove gdm | Rationale: | Unnecessary service packages must not be installed to decrease the attack surface of the system.
A graphical environment is unnecessary for certain types of systems including a virtualization
hypervisor. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_gdm_removed | Identifiers and References | Identifiers:
CCE-82348-4 References:
CM-7(a), CM-7(b), CM-6(a), SRG-OS-000480-GPOS-00227, 1.8.1 | |
|
Group
Sudo
Group contains 2 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
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 and References | Identifiers:
CCE-80350-2 References:
BP28(R5), BP28(R59), 1, 12, 15, 16, 5, DSS05.04, DSS05.10, DSS06.03, DSS06.10, CCI-002038, 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, 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, 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, IA-11, CM-6(a), PR.AC-1, PR.AC-7, SRG-OS-000373-GPOS-00156, SRG-OS-000373-GPOS-00157, SRG-OS-000373-GPOS-00158, RHEL-07-010350, SV-204430r853885_rule | |
|
Rule
Only the VDSM User Can Use sudo NOPASSWD
[ref] | The sudo NOPASSWD tag, when specified, allows a user to execute commands using sudo without having to authenticate. Only the vdsm user should have this capability in 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_vdsm_nopasswd | Identifiers and References | Identifiers:
CCE-82349-2 | |
|
Group
Updating Software
Group contains 6 rules |
[ref]
The yum command line tool is used to install and
update software packages. The system also provides a graphical
software update tool in the System menu, in the Administration submenu,
called Software Update.
Red Hat Enterprise Linux 7 systems contain an installed software catalog called
the RPM database, which records metadata of installed packages. Consistently using
yum or the graphical Software Update for all software installation
allows for insight into the current inventory of installed software on the system.
|
Rule
Ensure yum Removes Previous Package Versions
[ref] | yum should be configured to remove previous software components after
new versions have been installed. To configure yum to remove the
previous software components after updating, set the clean_requirements_on_remove
to 1 in /etc/yum.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 and References | Identifiers:
CCE-80346-0 References:
18, 20, 4, APO12.01, APO12.02, APO12.03, APO12.04, BAI03.10, DSS05.01, DSS05.02, 3.4.8, CCI-002617, 4.2.3, 4.2.3.12, 4.2.3.7, 4.2.3.9, A.12.6.1, A.14.2.3, A.16.1.3, A.18.2.2, A.18.2.3, SI-2(6), CM-11(a), CM-11(b), CM-6(a), ID.RA-1, PR.IP-12, SRG-OS-000437-GPOS-00194, RHEL-07-020200, SV-204452r853894_rule | |
|
Rule
Ensure gpgcheck Enabled In Main yum Configuration
[ref] | The gpgcheck option controls whether
RPM packages' signatures are always checked prior to installation.
To configure yum to check package signatures before installing
them, ensure the following line appears in /etc/yum.conf in
the [main] section:
gpgcheck=1 | Rationale: | Changes to any software components can have significant effects on the
overall security of the operating system. This requirement ensures the
software has not been tampered with and that it has been provided by a
trusted vendor.
Accordingly, patches, service packs, device drivers, or operating system
components must be signed with a certificate recognized and approved by the
organization.
Verifying the authenticity of the software prior to installation
validates the integrity of the patch or upgrade received from a vendor.
This ensures the software has not been tampered with and that it has been
provided by a trusted vendor. Self-signed certificates are disallowed by
this requirement. Certificates used to verify the software must be from an
approved Certificate Authority (CA). | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_globally_activated | Identifiers and References | Identifiers:
CCE-26989-4 References:
BP28(R15), 11, 2, 3, 9, 5.10.4.1, APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02, 3.4.8, CCI-001749, 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i), 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6, 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, CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), SA-12, SA-12(10), CM-11(a), CM-11(b), PR.DS-6, PR.DS-8, PR.IP-1, FPT_TUD_EXT.1, FPT_TUD_EXT.2, Req-6.2, 6.3.3, SRG-OS-000366-GPOS-00153, RHEL-07-020050, 1.2.3, SV-204447r877463_rule | |
|
Rule
Ensure gpgcheck Enabled for Local Packages
[ref] | yum should be configured to verify the signature(s) of local packages
prior to installation. To configure yum to verify signatures of local
packages, set the localpkg_gpgcheck to 1 in /etc/yum.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 and References | Identifiers:
CCE-80347-8 References:
BP28(R15), 11, 3, 9, BAI10.01, BAI10.02, BAI10.03, BAI10.05, 3.4.8, CCI-001749, 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i), 4.3.4.3.2, 4.3.4.3.3, SR 7.6, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, CM-11(a), CM-11(b), CM-6(a), CM-5(3), SA-12, SA-12(10), PR.IP-1, FPT_TUD_EXT.1, FPT_TUD_EXT.2, SRG-OS-000366-GPOS-00153, RHEL-07-020060, SV-204448r877463_rule | |
|
Rule
Ensure gpgcheck Enabled for All yum Package Repositories
[ref] | To ensure signature checking is not disabled for
any repos, remove any lines from files in /etc/yum.repos.d of the form:
gpgcheck=0 | Rationale: | Verifying the authenticity of the software prior to installation validates
the integrity of the patch or upgrade received from a vendor. This ensures
the software has not been tampered with and that it has been provided by a
trusted vendor. Self-signed certificates are disallowed by this
requirement. Certificates used to verify the software must be from an
approved Certificate Authority (CA)." | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_never_disabled | Identifiers and References | Identifiers:
CCE-26876-3 References:
BP28(R15), 11, 2, 3, 9, 5.10.4.1, APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02, 3.4.8, CCI-001749, 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i), 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6, 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, CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), SA-12, SA-12(10), CM-11(a), CM-11(b), PR.DS-6, PR.DS-8, PR.IP-1, FPT_TUD_EXT.1, FPT_TUD_EXT.2, Req-6.2, 6.3.3, SRG-OS-000366-GPOS-00153, 1.2.3 | |
|
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 and References | Identifiers:
CCE-26957-1 References:
BP28(R15), 11, 2, 3, 9, 5.10.4.1, APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02, 3.4.8, CCI-001749, 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i), 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6, 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, 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, CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), PR.DS-6, PR.DS-8, PR.IP-1, FPT_TUD_EXT.1, FPT_TUD_EXT.2, Req-6.2, SRG-OS-000366-GPOS-00153, RHEL-07-010019, 1.2.3, SV-256968r902687_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:
The OVAL feed of Red Hat Enterprise Linux 7 is not a XML file, which may not be understood by all scanners. | Rationale: | Installing software updates is a fundamental mitigation against
the exploitation of publicly-known vulnerabilities. If the most
recent security patches and updates are not installed, unauthorized
users may take advantage of weaknesses in the unpatched software. The
lack of prompt attention to patching could result in a system compromise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_security_patches_up_to_date | Identifiers and References | Identifiers:
CCE-26895-3 References:
BP28(R08), 18, 20, 4, 5.10.4.1, APO12.01, APO12.02, APO12.03, APO12.04, BAI03.10, DSS05.01, DSS05.02, CCI-000366, CCI-001227, 4.2.3, 4.2.3.12, 4.2.3.7, 4.2.3.9, A.12.6.1, A.14.2.3, A.16.1.3, A.18.2.2, A.18.2.3, SI-2(5), SI-2(c), CM-6(a), ID.RA-1, PR.IP-12, FMT_MOF_EXT.1, Req-6.2, 6.3.3, SRG-OS-000480-GPOS-00227, RHEL-07-020260, 1.8, SV-204459r603261_rule | |
|
Group
Account and Access Control
Group contains 17 groups and 64 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 7. |
Group
Warning Banners for System Accesses
Group contains 1 rule |
[ref]
Each system should expose as little information about
itself as possible.
System banners, which are typically displayed just before a
login prompt, give out information about the service or the host's
operating system. This might include the distribution name and the
system kernel version, and the particular version of a network
service. This information can assist intruders in gaining access to
the system as it can reveal whether the system is running
vulnerable software. Most network services can be configured to
limit what information is displayed.
Many organizations implement security policies that require a
system banner provide notice of the system's ownership, provide
warning to unauthorized users, and remind authorized users of their
consent to monitoring. |
Rule
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 and References | Identifiers:
CCE-27303-7 References:
1, 12, 15, 16, DSS05.04, DSS05.10, DSS06.10, 3.1.9, CCI-000048, CCI-000050, CCI-001384, CCI-001385, CCI-001386, CCI-001387, CCI-001388, 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, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, AC-8(a), AC-8(c), PR.AC-7, FMT_MOF_EXT.1, SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088, RHEL-07-010050, 1.7.2, SV-204395r603261_rule | |
|
Group
Protect Accounts by Configuring PAM
Group contains 4 groups and 19 rules |
[ref]
PAM, or Pluggable Authentication Modules, is a system
which implements modular authentication for Linux programs. PAM provides
a flexible and configurable architecture for authentication, and it should be configured
to minimize exposure to unnecessary risk. This section contains
guidance on how to accomplish that.
PAM is implemented as a set of shared objects which are
loaded and invoked whenever an application wishes to authenticate a
user. Typically, the application must be running as root in order
to take advantage of PAM, because PAM's modules often need to be able
to access sensitive stores of account information, such as /etc/shadow.
Traditional privileged network listeners
(e.g. sshd) or SUID programs (e.g. sudo) already meet this
requirement. An SUID root application, userhelper, is provided so
that programs which are not SUID or privileged themselves can still
take advantage of PAM.
PAM looks in the directory /etc/pam.d for
application-specific configuration information. For instance, if
the program login attempts to authenticate a user, then PAM's
libraries follow the instructions in the file /etc/pam.d/login
to determine what actions should be taken.
One very important file in /etc/pam.d is
/etc/pam.d/system-auth . This file, which is included by
many other PAM configuration files, defines 'default' system authentication
measures. Modifying this file is a good way to make far-reaching
authentication changes, for instance when implementing a
centralized authentication service. Warning:
Be careful when making changes to PAM's configuration files.
The syntax for these files is complex, and modifications can
have unexpected consequences. The default configurations shipped
with applications should be sufficient for most users. |
Group
Set Lockouts for Failed Password Attempts
Group contains 5 rules |
[ref]
The pam_faillock PAM module provides the capability to
lock out user accounts after a number of failed login attempts. Its
documentation is available in
/usr/share/doc/pam-VERSION/txts/README.pam_faillock .
Warning:
Locking out user accounts presents the
risk of a denial-of-service attack. The lockout policy
must weigh whether the risk of such a
denial-of-service attack outweighs the benefits of thwarting
password guessing attacks. |
Rule
Limit Password Reuse
[ref] | Do not allow users to reuse recent passwords. This can be accomplished by using the
remember option for the pam_unix or pam_pwhistory PAM modules. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report. Warning:
Newer versions of authselect contain an authselect feature to easily and properly
enable pam_pwhistory.so module. If this feature is not yet available in your
system, an authselect custom profile must be used to avoid integrity issues in PAM files. | Rationale: | Preventing re-use of previous passwords helps ensure that a compromised password is not
re-used by a user. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_unix_remember | Identifiers and References | Identifiers:
CCE-82030-8 References:
BP28(R18), 1, 12, 15, 16, 5, 5.6.2.1.1, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, 3.5.8, CCI-000200, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(f), IA-5(1)(e), PR.AC-1, PR.AC-6, PR.AC-7, Req-8.2.5, 8.3.7, SRG-OS-000077-GPOS-00045, 5.4.4 | |
|
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 pam_faillock.so module entries in
/etc/pam.d/password-auth and /etc/pam.d/system-auth are
followed by the assignment 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 and References | Identifiers:
CCE-27350-8 References:
BP28(R18), 1, 12, 15, 16, 5.5.3, DSS05.04, DSS05.10, DSS06.10, 3.1.8, CCI-000044, CCI-002236, CCI-002237, CCI-002238, 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, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, CM-6(a), AC-7(a), PR.AC-7, FIA_AFL.1, Req-8.1.6, 8.3.4, SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005, RHEL-07-010320, 5.4.2, SV-204427r880842_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 and References | Identifiers:
CCE-80353-6 References:
BP28(R18), 1, 12, 15, 16, DSS05.04, DSS05.10, DSS06.10, CCI-002238, CCI-000044, 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, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, CM-6(a), AC-7(b), IA-5(c), PR.AC-7, FMT_MOF_EXT.1, SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005, RHEL-07-010330, SV-204428r880845_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 pam_faillock.so module entries in
/etc/pam.d/password-auth and /etc/pam.d/system-auth are
followed by the assignment
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 and References | Identifiers:
CCE-27297-1 References:
BP28(R18), 1, 12, 15, 16, DSS05.04, DSS05.10, DSS06.10, CCI-000044, CCI-002236, CCI-002237, CCI-002238, 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, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, CM-6(a), AC-7(a), PR.AC-7, FIA_AFL.1, SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005, RHEL-07-010320, SV-204427r880842_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 pam_faillock.so module entries in
/etc/pam.d/password-auth and /etc/pam.d/system-auth are
followed by the assignment
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 and References | Identifiers:
CCE-26884-7 References:
BP28(R18), 1, 12, 15, 16, 5.5.3, DSS05.04, DSS05.10, DSS06.10, 3.1.8, CCI-000044, CCI-002236, CCI-002237, CCI-002238, 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, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, CM-6(a), AC-7(b), PR.AC-7, FIA_AFL.1, Req-8.1.7, 8.3.4, SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005, RHEL-07-010320, 5.4.2, SV-204427r880842_rule | |
|
Group
Set Password Quality Requirements
Group contains 1 group and 10 rules |
[ref]
The default pam_pwquality PAM module provides strength
checking for passwords. It performs a number of checks, such as
making sure passwords are not similar to dictionary words, are of
at least a certain length, are not the previous password reversed,
and are not simply a change of case from the previous password. It
can also require passwords to be in certain character classes. The
pam_pwquality module is the preferred way of configuring
password requirements.
The man pages pam_pwquality(8)
provide information on the capabilities and configuration of
each. |
Group
Set Password Quality Requirements with pam_pwquality
Group contains 10 rules |
[ref]
The pam_pwquality PAM module can be configured to meet
requirements for a variety of policies.
For example, to configure pam_pwquality to require at least one uppercase
character, lowercase character, digit, and other (special)
character, make sure that pam_pwquality exists in /etc/pam.d/system-auth :
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth .
Next, modify the settings in /etc/security/pwquality.conf to match the following:
difok = 4
minlen = 14
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
maxrepeat = 3
The arguments can be modified to ensure compliance with
your organization's security policy. Discussion of each parameter follows. |
Rule
Ensure PAM Enforces Password Requirements - Minimum Digit Characters
[ref] | The pam_pwquality module's dcredit parameter controls requirements for
usage of digits in a password. When set to a negative number, any password will be required to
contain that many digits. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each digit. Modify the dcredit setting in
/etc/security/pwquality.conf to require the use of a digit in passwords. | Rationale: | Use of a complex password helps to increase the time and resources required
to compromise the password. Password complexity, or strength, is a measure of
the effectiveness of a password in resisting attempts at guessing and brute-force
attacks.
Password complexity is one factor of several that determines how long it takes
to crack a password. The more complex the password, the greater the number of
possible combinations that need to be tested before the password is compromised.
Requiring digits makes password guessing attacks more difficult by ensuring a larger
search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_dcredit | Identifiers and References | Identifiers:
CCE-27214-6 References:
BP28(R18), 1, 12, 15, 16, 5, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000194, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, FMT_SMF_EXT.1, Req-8.2.3, 8.3.6, 8.3.9, SRG-OS-000071-GPOS-00039, RHEL-07-010140, 5.4.1, SV-204409r603261_rule | |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Different Characters
[ref] | The pam_pwquality module's difok parameter sets the number of characters
in a password that must not be present in and old password during a password change.
Modify the difok setting in /etc/security/pwquality.conf
to equal 8 to require differing characters
when changing passwords. | Rationale: | Use of a complex password helps to increase the time and resources
required to compromise the password. Password complexity, or strength,
is a measure of the effectiveness of a password in resisting attempts
at guessing and brute–force attacks.
Password complexity is one factor of several that determines how long
it takes to crack a password. The more complex the password, the
greater the number of possible combinations that need to be tested
before the password is compromised.
Requiring a minimum number of different characters during password changes ensures that
newly changed passwords should not resemble previously compromised ones.
Note that passwords which are changed on compromised systems will still be compromised, however. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_difok | Identifiers and References | Identifiers:
CCE-82020-9 References:
1, 12, 15, 16, 5, 5.6.2.1.1, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000195, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(b), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, SRG-OS-000072-GPOS-00040, RHEL-07-010160, SV-204411r603261_rule | |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Lowercase Characters
[ref] | The pam_pwquality module's lcredit parameter controls requirements for
usage of lowercase letters in a password. When set to a negative number, any password will be required to
contain that many lowercase characters. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each lowercase character. Modify the lcredit setting in
/etc/security/pwquality.conf to require the use of a lowercase character in passwords. | Rationale: | Use of a complex password helps to increase the time and resources required
to compromise the password. Password complexity, or strength, is a measure of
the effectiveness of a password in resisting attempts at guessing and brute-force
attacks.
Password complexity is one factor of several that determines how long it takes
to crack a password. The more complex the password, the greater the number of
possble combinations that need to be tested before the password is compromised.
Requiring a minimum number of lowercase characters makes password guessing attacks
more difficult by ensuring a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_lcredit | Identifiers and References | Identifiers:
CCE-27345-8 References:
BP28(R18), 1, 12, 15, 16, 5, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000193, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, FMT_SMF_EXT.1, Req-8.2.3, 8.3.6, 8.3.9, SRG-OS-000070-GPOS-00038, RHEL-07-010130, 5.4.1, SV-204408r603261_rule | |
|
Rule
Ensure PAM Enforces Password Requirements - Maximum Consecutive Repeating Characters from Same Character Class
[ref] | The pam_pwquality module's maxclassrepeat parameter controls requirements for
consecutive repeating characters from the same character class. When set to a positive number, it will reject passwords
which contain more than that number of consecutive characters from the same character class. Modify the
maxclassrepeat setting in /etc/security/pwquality.conf to equal 4
to prevent a run of ( 4 + 1) or more identical characters. | Rationale: | Use of a complex password helps to increase the time and resources required to compromise the password.
Password complexity, or strength, is a measure of the effectiveness of a password in resisting
attempts at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The
more complex a password, the greater the number of possible combinations that need to be tested before the
password is compromised. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_maxclassrepeat | Identifiers and References | Identifiers:
CCE-27512-3 References:
1, 12, 15, 16, 5, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000195, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, SRG-OS-000072-GPOS-00040, RHEL-07-010190, SV-204414r809186_rule | |
|
Rule
Set Password Maximum Consecutive Repeating Characters
[ref] | The pam_pwquality module's maxrepeat parameter controls requirements for
consecutive repeating characters. When set to a positive number, it will reject passwords
which contain more than that number of consecutive characters. Modify the maxrepeat setting
in /etc/security/pwquality.conf to equal 3 to prevent a
run of ( 3 + 1) or more identical characters. | Rationale: | Use of a complex password helps to increase the time and resources required to compromise the password.
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at
guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The more
complex the password, the greater the number of possible combinations that need to be tested before the
password is compromised.
Passwords with excessive repeating characters may be more vulnerable to password-guessing attacks. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_maxrepeat | Identifiers and References | Identifiers:
CCE-82055-5 References:
1, 12, 15, 16, 5, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000195, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, SRG-OS-000072-GPOS-00040, RHEL-07-010180, SV-204413r603261_rule | |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Different Categories
[ref] | The pam_pwquality module's minclass parameter controls
requirements for usage of different character classes, or types, of character
that must exist in a password before it is considered valid. For example,
setting this value to three (3) requires that any password must have characters
from at least three different categories in order to be approved. The default
value is zero (0), meaning there are no required classes. There are four
categories available:
* Upper-case characters
* Lower-case characters
* Digits
* Special characters (for example, punctuation)
Modify the minclass setting in /etc/security/pwquality.conf entry
to require 4
differing categories of characters when changing passwords. | Rationale: | Use of a complex password helps to increase the time and resources required to compromise the password.
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts
at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The
more complex the password, the greater the number of possible combinations that need to be tested before
the password is compromised.
Requiring a minimum number of character categories makes password guessing attacks more difficult
by ensuring a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_minclass | Identifiers and References | Identifiers:
CCE-82045-6 References:
1, 12, 15, 16, 5, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000195, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, SRG-OS-000072-GPOS-00040, RHEL-07-010170, 5.4.1, SV-204412r603261_rule | |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Length
[ref] | The pam_pwquality module's minlen parameter controls requirements for
minimum characters required in a password. Add minlen=15
after pam_pwquality to set minimum password length requirements. | Rationale: | The shorter the password, the lower the number of possible combinations
that need to be tested before the password is compromised.
Password complexity, or strength, is a measure of the effectiveness of a
password in resisting attempts at guessing and brute-force attacks.
Password length is one factor of several that helps to determine strength
and how long it takes to crack a password. Use of more characters in a password
helps to exponentially increase the time and/or resources required to
compromise the password. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_minlen | Identifiers and References | Identifiers:
CCE-27293-0 References:
BP28(R18), 1, 12, 15, 16, 5, 5.6.2.1.1, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000205, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, FMT_SMF_EXT.1, Req-8.2.3, 8.3.6, 8.3.9, SRG-OS-000078-GPOS-00046, RHEL-07-010280, 5.4.1, SV-204423r603261_rule | |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Special Characters
[ref] | The pam_pwquality module's ocredit= parameter controls requirements for
usage of special (or "other") characters in a password. When set to a negative number,
any password will be required to contain that many special characters.
When set to a positive number, pam_pwquality will grant +1
additional length credit for each special character. Modify the ocredit setting
in /etc/security/pwquality.conf to equal -1
to require use of a special character in passwords. | Rationale: | Use of a complex password helps to increase the time and resources required
to compromise the password. Password complexity, or strength, is a measure of
the effectiveness of a password in resisting attempts at guessing and brute-force
attacks.
Password complexity is one factor of several that determines how long it takes
to crack a password. The more complex the password, the greater the number of
possible combinations that need to be tested before the password is compromised.
Requiring a minimum number of special characters makes password guessing attacks
more difficult by ensuring a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_ocredit | Identifiers and References | Identifiers:
CCE-27360-7 References:
BP28(R18), 1, 12, 15, 16, 5, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-001619, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, FMT_SMF_EXT.1, SRG-OS-000266-GPOS-00101, RHEL-07-010150, 5.4.1, SV-204410r603261_rule | |
|
Rule
Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session
[ref] | To configure the number of retry prompts that are permitted per-session:
Edit the pam_pwquality.so statement in
/etc/pam.d/system-auth to show
retry=3 , or a lower value if site
policy is more restrictive. The DoD requirement is a maximum of 3 prompts
per session. | Rationale: | Setting the password retry prompts that are permitted on a per-session basis to a low value
requires some software, such as SSH, to re-connect. This can slow down and
draw additional attention to some types of password-guessing attacks. Note that this
is different from account lockout, which is provided by the pam_faillock module. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_retry | Identifiers and References | Identifiers:
CCE-27160-1 References:
1, 11, 12, 15, 16, 3, 5, 9, 5.5.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000192, CCI-000366, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 7.6, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, CM-6(a), AC-7(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, PR.IP-1, FMT_MOF_EXT.1, SRG-OS-000069-GPOS-00037, SRG-OS-000480-GPOS-00227, RHEL-07-010119, 5.4.1, SV-204406r902704_rule | |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Uppercase Characters
[ref] | The pam_pwquality module's ucredit= parameter controls requirements for
usage of uppercase letters in a password. When set to a negative number, any password will be required to
contain that many uppercase characters. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each uppercase character. Modify the ucredit setting in
/etc/security/pwquality.conf to require the use of an uppercase character in passwords. | Rationale: | Use of a complex password helps to increase the time and resources required to compromise the password.
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts
at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The more
complex the password, the greater the number of possible combinations that need to be tested before
the password is compromised. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_ucredit | Identifiers and References | Identifiers:
CCE-27200-5 References:
BP28(R18), 1, 12, 15, 16, 5, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000192, CCI-000193, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, FMT_SMF_EXT.1, Req-8.2.3, 8.3.6, 8.3.9, SRG-OS-000069-GPOS-00037, SRG-OS-000070-GPOS-00038, RHEL-07-010120, 5.4.1, SV-204407r603261_rule | |
|
Group
Set Password Hashing Algorithm
Group contains 3 rules |
[ref]
The system's default algorithm for storing password hashes in
/etc/shadow is SHA-512. This can be configured in several
locations. |
Rule
Set Password Hashing Algorithm in /etc/libuser.conf
[ref] | In /etc/libuser.conf , add or correct the following line in its
[defaults] section to ensure the system will use the SHA-512
algorithm for password hashing:
crypt_style = sha512 | Rationale: | Passwords need to be protected at all times, and encryption is the standard
method for protecting passwords. If passwords are not encrypted, they can
be plainly read (i.e., clear text) and easily compromised. Passwords that
are encrypted with a weak algorithm are no more protected than if they are
kepy in plain text.
This setting ensures user and group account administration utilities are
configured to store only encrypted representations of passwords.
Additionally, the crypt_style configuration option ensures the use
of a strong hashing algorithm that makes password cracking attacks more
difficult. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_libuserconf | Identifiers and References | Identifiers:
CCE-82038-1 References:
1, 12, 15, 16, 5, 5.6.2.2, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, 3.13.11, CCI-000196, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0418, 1055, 1402, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(c), CM-6(a), PR.AC-1, PR.AC-6, PR.AC-7, Req-8.2.1, 8.3.2, SRG-OS-000073-GPOS-00041, RHEL-07-010220, SV-204417r877397_rule | |
|
Rule
Set Password Hashing Algorithm in /etc/login.defs
[ref] | In /etc/login.defs , add or correct the following line to ensure
the system will use SHA512 as the hashing algorithm:
ENCRYPT_METHOD SHA512 | Rationale: | Passwords need to be protected at all times, and encryption is the standard method for protecting passwords.
If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords
that are encrypted with a weak algorithm are no more protected than if they are kept in plain text.
Using a stronger hashing algorithm makes password cracking attacks more difficult. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_logindefs | Identifiers and References | Identifiers:
CCE-82050-6 References:
BP28(R32), 1, 12, 15, 16, 5, 5.6.2.2, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, 3.13.11, CCI-000196, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0418, 1055, 1402, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(c), CM-6(a), PR.AC-1, PR.AC-6, PR.AC-7, Req-8.2.1, 8.3.2, SRG-OS-000073-GPOS-00041, RHEL-07-010210, 5.4.3, SV-204416r877397_rule | |
|
Rule
Set PAM''s Password Hashing Algorithm
[ref] | The PAM system service can be configured to only store encrypted
representations of passwords. In "/etc/pam.d/system-auth", the
password section of the file controls which PAM modules execute
during a password change. Set the pam_unix.so module in the
password section to include the argument sha512 , as shown
below:
password sufficient pam_unix.so sha512 other arguments...
This will help ensure when local users change their passwords, hashes for
the new passwords will be generated using the SHA-512 algorithm. This is
the default. | Rationale: | Passwords need to be protected at all times, and encryption is the standard
method for protecting passwords. If passwords are not encrypted, they can
be plainly read (i.e., clear text) and easily compromised. Passwords that
are encrypted with a weak algorithm are no more protected than if they are
kepy in plain text.
This setting ensures user and group account administration utilities are
configured to store only encrypted representations of passwords.
Additionally, the crypt_style configuration option ensures the use
of a strong hashing algorithm that makes password cracking attacks more
difficult. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_systemauth | Identifiers and References | Identifiers:
CCE-82043-1 References:
BP28(R32), 1, 12, 15, 16, 5, 5.6.2.2, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, 3.13.11, CCI-000196, CCI-000803, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0418, 1055, 1402, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(c), CM-6(a), PR.AC-1, PR.AC-6, PR.AC-7, Req-8.2.1, 8.3.2, SRG-OS-000073-GPOS-00041, SRG-OS-000120-GPOS-00061, RHEL-07-010200, 5.4.3, SV-204415r917816_rule | |
|
Rule
Ensure PAM Displays Last Logon/Access Notification
[ref] | To configure the system to notify users of last logon/access using pam_lastlog ,
add or correct the pam_lastlog settings in /etc/pam.d/postlogin
to include showfailed option, such as:
session [default=1] pam_lastlog.so showfailed
And make sure that the silent option is not set for this specific line. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report. Warning:
authselect contains an authselect feature to easily and properly enable Last Logon
notifications with pam_lastlog.so module. If a custom profile was created and used
in the system before this authselect feature was available, the new feature can't be used
with this custom profile and the remediation will fail. In this case, the custom profile
should be recreated or manually updated. | Rationale: | Users need to be aware of activity that occurs regarding their account. Providing users with
information regarding the number of unsuccessful attempts that were made to login to their
account allows the user to determine if any unauthorized activity has occurred and gives them
an opportunity to notify administrators. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_display_login_attempts | Identifiers and References | Identifiers:
CCE-27275-7 References:
1, 12, 15, 16, 5.5.2, DSS05.04, DSS05.10, DSS06.10, CCI-000052, 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, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, 0582, 0584, 05885, 0586, 0846, 0957, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, AC-9, AC-9(1), PR.AC-7, Req-10.2.4, 10.2.1.4, SRG-OS-000480-GPOS-00227, RHEL-07-040530, SV-204605r858478_rule | |
|
Group
Protect Physical Console Access
Group contains 3 groups and 12 rules |
[ref]
It is impossible to fully protect a system from an
attacker with physical access, so securing the space in which the
system is located should be considered a necessary step. However,
there are some steps which, if taken, make it more difficult for an
attacker to quickly or undetectably modify a system from its
console. |
Group
Configure Screen Locking
Group contains 2 groups and 7 rules |
[ref]
When a user must temporarily leave an account
logged-in, screen locking should be employed to prevent passersby
from abusing the account. User education and training is
particularly important for screen locking to be effective, and policies
can be implemented to reinforce this.
Automatic screen locking is only meant as a safeguard for
those cases where a user forgot to lock the screen. |
Group
Configure Console Screen Locking
Group contains 1 rule |
[ref]
A console screen locking mechanism is a temporary action taken when a user
stops work and moves away from the immediate physical vicinity of the
information system but does not logout because of the temporary nature of
the absence. Rather than relying on the user to manually lock their
operation system session prior to vacating the vicinity, operating systems
need to be able to identify when a user's session has idled and take action
to initiate the session lock. |
Rule
Install the screen Package
[ref] | To enable console screen locking, install the screen package.
The screen package can be installed with the following command:
$ sudo yum install screen
Instruct users to begin new terminal sessions with the following command:
$ screen
The console can now be locked with the following key combination:
ctrl+a x | 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 operation system session prior to vacating the vicinity,
operating systems need to be able to identify when a user's session has idled and take action to initiate the
session lock.
The screen package allows for a session lock to be implemented and configured. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_screen_installed | Identifiers and References | Identifiers:
CCE-27351-6 References:
1, 12, 15, 16, DSS05.04, DSS05.10, DSS06.10, 3.1.10, CCI-000057, CCI-000058, 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, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, CM-6(a), PR.AC-7, FMT_MOF_EXT.1, SRG-OS-000029-GPOS-00010, RHEL-07-010090, SV-255926r880779_rule | |
|
Group
Hardware Tokens for Authentication
Group contains 6 rules |
[ref]
The use of hardware tokens such as smart cards for system login
provides stronger, two-factor authentication than using a username and password.
In Red Hat Enterprise Linux servers and workstations, hardware token login
is not enabled by default and must be enabled in the system settings. |
Rule
Install the opensc Package For Multifactor Authentication
[ref] |
The opensc package can be installed with the following command:
$ sudo yum install opensc | Rationale: | Using an authentication device, such as a CAC or token that is separate from
the information system, ensures that even if the information system is
compromised, that compromise will not affect credentials stored on the
authentication device.
Multifactor solutions that require devices separate from
information systems gaining access include, for example, hardware tokens
providing time-based or challenge-response authenticators and smart cards such
as the U.S. Government Personal Identity Verification card and the DoD Common
Access Card. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_opensc_installed | Identifiers and References | Identifiers:
CCE-80568-9 References:
CCI-001954, CCI-001953, 1382, 1384, 1386, CM-6(a), SRG-OS-000375-GPOS-00160, SRG-OS-000376-GPOS-00161 | |
|
Rule
Install the pcsc-lite package
[ref] | The pcsc-lite package can be installed with the following command:
$ sudo yum install pcsc-lite | Rationale: | The pcsc-lite package must be installed if it is to be available for
multifactor authentication using smartcards. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_pcsc-lite_installed | Identifiers and References | Identifiers:
CCE-82347-6 References:
CCI-001954, 1382, 1384, 1386, CM-6(a), SRG-OS-000375-GPOS-00160 | |
|
Rule
Enable the pcscd Service
[ref] |
The pcscd service can be enabled with the following command:
$ sudo systemctl enable pcscd.service | Rationale: | Using an authentication device, such as a CAC or token that is separate from
the information system, ensures that even if the information system is
compromised, that compromise will not affect credentials stored on the
authentication device.
Multifactor solutions that require devices separate from
information systems gaining access include, for example, hardware tokens
providing time-based or challenge-response authenticators and smart cards such
as the U.S. Government Personal Identity Verification card and the DoD Common
Access Card. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_service_pcscd_enabled | Identifiers and References | Identifiers:
CCE-80569-7 References:
CCI-001954, 1382, 1384, 1386, IA-2(1), IA-2(2), IA-2(3), IA-2(4), IA-2(6), IA-2(7), IA-2(11), CM-6(a), Req-8.3, 8.4, SRG-OS-000375-GPOS-00160 | |
|
Rule
Configure opensc Smart Card Drivers
[ref] | The OpenSC smart card tool can auto-detect smart card drivers; however,
setting the smart card drivers in use by your organization helps to prevent
users from using unauthorized smart cards. The default smart card driver for this
profile is cac .
To configure the OpenSC driver, edit the /etc/opensc.conf
and add the following line into the file in the app default block,
so it will look like:
app default {
...
card_drivers = cac;
}
| Rationale: | Smart card login provides two-factor authentication stronger than
that provided by a username and password combination. Smart cards leverage PKI
(public key infrastructure) in order to provide and verify credentials.
Configuring the smart card driver in use by your organization helps to prevent
users from using unauthorized smart cards. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_configure_opensc_card_drivers | Identifiers and References | Identifiers:
CCE-80565-5 References:
1, 12, 15, 16, 5, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000765, CCI-000766, CCI-000767, CCI-000768, CCI-000771, CCI-000772, CCI-000884, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 1382, 1384, 1386, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-2(1), IA-2(2), IA-2(3), IA-2(4), IA-2(6), IA-2(7), IA-2(11), CM-6(a), PR.AC-1, PR.AC-6, PR.AC-7, Req-8.3, 8.4, SRG-OS-000104-GPOS-00051, SRG-OS-000106-GPOS-00053, SRG-OS-000107-GPOS-00054, SRG-OS-000109-GPOS-00056, SRG-OS-000108-GPOS-00055, SRG-OS-000108-GPOS-00057, SRG-OS-000108-GPOS-00058 | |
|
Rule
Configure NSS DB To Use opensc
[ref] | The opensc module should be configured for use over the
Coolkey PKCS#11 module in the NSS database. To configure the
NSS database to use the opensc module, run the following
command:
$ sudo pkcs11-switch opensc Warning:
NSS modules information are stored in NSS database which is in binary format. Currently
it is not possible to check NSS database using OVAL. This is the reason there is no OVAL
check for this rule. | Rationale: | Smart card login provides two-factor authentication stronger than
that provided by a username and password combination. Smart cards leverage PKI
(public key infrastructure) in order to provide and verify credentials. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_configure_opensc_nss_db | Identifiers and References | Identifiers:
CCE-80567-1 References:
1, 12, 15, 16, 5, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000765, CCI-000766, CCI-000767, CCI-000768, CCI-000771, CCI-000772, |
|