Group
Guide to the Secure Configuration of SUSE Linux Enterprise 12
Group contains 61 groups and 151 rules |
Group
System Settings
Group contains 45 groups and 73 rules |
[ref]
Contains rules that check correct system settings. |
Group
Installing and Maintaining Software
Group contains 11 groups and 23 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 7 groups and 13 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 7 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'
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 zypper repository using the command:
$ sudo zypper reinstall PACKAGENAME
Alternatively, the package can be reinstalled from trusted media using the command:
$ sudo rpm -Uvh PACKAGENAME
Warning:
This rule can take a long time to perform the check and might consume a considerable
amount of resources depending on the number of packages present on the system. It is not a
problem in most cases, but especially systems with a large number of installed packages
can be affected. | Rationale: | The hashes of important files like system executables should match the
information given by the RPM database. Executables with erroneous hashes could
be a sign of nefarious activity on the system. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_rpm_verify_hashes | Identifiers: | CCE-91632-0 | References: | cis-csc | 11, 2, 3, 9 | cjis | 5.10.4.1 | cobit5 | APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02 | cui | 3.3.8, 3.4.1 | disa | CCI-000366, CCI-001749 | hipaa | 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i) | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4 | nist | CM-6(d), CM-6(c), SI-7, SI-7(1), SI-7(6), AU-9(3) | nist-csf | PR.DS-6, PR.DS-8, PR.IP-1 | pcidss | Req-11.5 | os-srg | SRG-OS-000480-GPOS-00227 | pcidss4 | 11.5.2 |
| |
|
Rule
Verify and Correct Ownership with RPM
[ref] | The RPM package management system can check file ownership permissions of installed software
packages, including many that are important to system security. After locating a file with
incorrect permissions, which can be found with:
rpm -Va | awk '{ if (substr($0,6,1)=="U" || substr($0,7,1)=="G") print $NF }'
run the following command to determine which package owns it:
$ rpm -qf FILENAME
Next, run the following command to reset its permissions to the correct values:
$ sudo rpm --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. Warning:
This rule can take a long time to perform the check and might consume a considerable
amount of resources depending on the number of packages present on the system. It is not a
problem in most cases, but especially systems with a large number of installed packages
can be affected. | Rationale: | Ownership of binaries and configuration files that is incorrect could allow an unauthorized
user to gain privileges that they should not have. The ownership set by the vendor should be
maintained. Any deviations from this baseline should be investigated. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_rpm_verify_ownership | Identifiers: | CCE-91649-4 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 3, 5, 6, 9 | cjis | 5.10.4.1 | cobit5 | APO01.06, APO11.04, BAI03.05, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.04, DSS05.07, DSS06.02, MEA02.01 | cui | 3.3.8, 3.4.1 | disa | CCI-001494, CCI-001496 | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.3.7.3, 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 5.2, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.2, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.5.1, A.12.6.2, A.12.7.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R4.2, CIP-003-8 R6, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2 | nist | CM-6(d), CM-6(c), SI-7, SI-7(1), SI-7(6), AU-9(3) | nist-csf | PR.AC-4, PR.DS-5, PR.IP-1, PR.PT-1 | pcidss | Req-11.5 | os-srg | SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000278-GPOS-00108 | cis | 6.1.1 | pcidss4 | 11.5.2 |
| |
|
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. Warning:
This rule can take a long time to perform the check and might consume a considerable
amount of resources depending on the number of packages present on the system. It is not a
problem in most cases, but especially systems with a large number of installed packages
can be affected. | Rationale: | 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: | CCE-91634-6 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 3, 5, 6, 9 | cjis | 5.10.4.1 | cobit5 | APO01.06, APO11.04, BAI03.05, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.04, DSS05.07, DSS06.02, MEA02.01 | cui | 3.3.8, 3.4.1 | disa | CCI-001493, CCI-001494, CCI-001495, CCI-001496 | hipaa | 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i) | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.3.7.3, 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 5.2, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.2, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.5.1, A.12.6.2, A.12.7.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R4.2, CIP-003-8 R6, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2 | nist | CM-6(d), CM-6(c), SI-7, SI-7(1), SI-7(6), AU-9(3), CM-6(a) | nist-csf | PR.AC-4, PR.DS-5, PR.IP-1, PR.PT-1 | pcidss | Req-11.5 | os-srg | SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098, SRG-OS-000258-GPOS-00099, SRG-OS-000278-GPOS-00108 | cis | 6.1.1 | pcidss4 | 11.5.2 |
| |
|
Group
Verify Integrity with AIDE
Group contains 4 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 zypper install aide
| Rationale: | The AIDE package must be installed if it is to be available for integrity checking. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_aide_installed | Identifiers: | CCE-83067-9 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | disa | CCI-002696, CCI-002699, CCI-001744 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | ism | 1034, 1288, 1341, 1417 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | nist | CM-6(a) | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | pcidss | Req-11.5 | os-srg | SRG-OS-000445-GPOS-00199 | stigid | SLES-12-010499 | cis | 1.4.1 | anssi | R76, R79 | pcidss4 | 11.5.2 | stigref | SV-255916r880937_rule |
| |
|
Rule
Build and Test AIDE Database
[ref] | Run the following command to generate a new database:
$ sudo /usr/bin/aide --init
By default, the database will be written to the file
/var/lib/aide/aide.db.new .
Storing the database, the configuration file /etc/aide.conf , and the binary
/usr/bin/aide
(or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity.
The newly-generated database can be installed as follows:
$ sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db
To initiate a manual check, run the following command:
$ sudo /usr/bin/aide --check
If this check produces any unexpected output, investigate. | Rationale: | For AIDE to be effective, an initial database of "known-good" information about files
must be captured and it should be able to be verified against the installed files. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_aide_build_database | Identifiers: | CCE-91483-8 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | nist | CM-6(a) | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | pcidss | Req-11.5 | os-srg | SRG-OS-000445-GPOS-00199 | stigid | SLES-12-010499 | cis | 1.4.1 | anssi | R76, R79 | pcidss4 | 11.5.2 | stigref | SV-255916r880937_rule |
| |
|
Rule
Configure Systemd Timer Execution of AIDE
[ref] | At a minimum, AIDE should be configured to run a weekly scan.
To implement a systemd service and a timer unit to run the service periodically:
For example, if a systemd timer is expected to be started every day at 5AM
OnCalendar=*-*-* 05:00:0
[Timer] section in the timer unit and
a Unit section starting the AIDE check service unit should be referred. | Rationale: | AIDE provides a means to check if unauthorized changes are made to the system.
AIDE itself does not setup a periodic execution, so in order to detect unauthorized
changes a systemd service to run the check and a systemd timer to take care
of periodical execution of that systemd service should be defined. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_aide_periodic_checking_systemd_timer | Identifiers: | CCE-92366-4 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | disa | CCI-001744, CCI-002699, CCI-002702 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | nist | SI-7, SI-7(1), CM-6(a) | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | pcidss | Req-11.5 | os-srg | SRG-OS-000363-GPOS-00150, SRG-OS-000446-GPOS-00200, SRG-OS-000447-GPOS-00201 | cis | 1.4.2 | anssi | R76 | pcidss4 | 11.5.2 |
| |
|
Rule
Configure Periodic Execution of AIDE
[ref] | At a minimum, AIDE should be configured to run a weekly scan.
To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab :
05 4 * * * root /usr/bin/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/bin/aide --check
AIDE can be executed periodically through other means; this is merely one example.
The usage of cron's special time codes, such as @daily and
@weekly is acceptable. | Rationale: | By default, AIDE does not install itself for periodic execution. Periodically
running AIDE is necessary to reveal unexpected changes in installed files.
Unauthorized changes to the baseline configuration could make the system vulnerable
to various attacks or allow unauthorized access to the operating system. Changes to
operating system configurations can have unintended side effects, some of which may
be relevant to security.
Detecting such changes and providing an automated response can help avoid unintended,
negative consequences that could ultimately affect the security state of the operating
system. The operating system's Information Management Officer (IMO)/Information System
Security Officer (ISSO) and System Administrators (SAs) must be notified via email and/or
monitoring system trap when there is an unauthorized modification of a configuration item. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_aide_periodic_cron_checking | Identifiers: | CCE-91529-8 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | disa | CCI-001744, CCI-002699, CCI-002702 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | nist | SI-7, SI-7(1), CM-6(a) | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | pcidss | Req-11.5 | os-srg | SRG-OS-000363-GPOS-00150, SRG-OS-000446-GPOS-00200, SRG-OS-000447-GPOS-00201 | stigid | SLES-12-010500 | cis | 1.4.2 | anssi | R76 | pcidss4 | 11.5.2 | stigref | SV-217148r902840_rule |
| |
|
Group
System Cryptographic Policies
Group contains 3 rules |
[ref]
Linux has the capability to centrally configure cryptographic polices. The command
update-crypto-policies is used to set the policy applicable for the various
cryptographic back-ends, such as SSL/TLS libraries. The configured cryptographic
policies will be the default policy used by these backends unless the application
user configures them otherwise. When the system has been configured to use the
centralized cryptographic policies, the administrator is assured that any application
that utilizes the supported backends will follow a policy that adheres to the
configured profile.
Currently the supported backends are:
- GnuTLS library
- OpenSSL library
- NSS library
- OpenJDK
- Libkrb5
- BIND
- OpenSSH
Applications and languages which rely on any of these backends will follow the
system policies as well. Examples are apache httpd, nginx, php, and others. |
Rule
Configure Libreswan to use System Crypto Policy
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
Libreswan is supported by system crypto policy, but the Libreswan configuration may be
set up to ignore it.
To check that Crypto Policies settings are configured correctly, ensure that the /etc/ipsec.conf
includes the appropriate configuration file.
In /etc/ipsec.conf , make sure that the following line
is not commented out or superseded by later includes:
include /etc/crypto-policies/back-ends/libreswan.config
| Rationale: | Overriding the system crypto policy makes the behavior of the Libreswan
service violate expectations, and makes system configuration more
fragmented. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_configure_libreswan_crypto_policy | Identifiers: | CCE-91637-9 | References: | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1 | nist | CM-6(a), MA-4(6), SC-13, SC-12(2), SC-12(3) | ospp | FCS_IPSEC_EXT.1.4, FCS_IPSEC_EXT.1.6 | pcidss | Req-2.2 | os-srg | SRG-OS-000033-GPOS-00014 |
| |
|
Rule
Configure OpenSSL library to use System Crypto Policy
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
OpenSSL is supported by crypto policy, but the OpenSSL configuration may be
set up to ignore it.
To check that Crypto Policies settings are configured correctly, you have to examine the OpenSSL config file
available under /etc/ssl/openssl.cnf .
This file has the ini format, and it enables crypto policy support
if there is a [ crypto_policy ] section that contains the .include /etc/crypto-policies/back-ends/opensslcnf.config directive. | Rationale: | Overriding the system crypto policy makes the behavior of the Java runtime violates expectations,
and makes system configuration more fragmented. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_configure_openssl_crypto_policy | Identifiers: | CCE-91638-7 | References: | disa | CCI-001453 | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1, CIP-007-3 R7.1 | nist | AC-17(a), AC-17(2), CM-6(a), MA-4(6), SC-13, SC-12(2), SC-12(3) | pcidss | Req-2.2 | os-srg | SRG-OS-000250-GPOS-00093 |
| |
|
Rule
Configure SSH to use System Crypto Policy
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
SSH is supported by crypto policy, but the SSH configuration may be
set up to ignore it.
To check that Crypto Policies settings are configured correctly, ensure that
the CRYPTO_POLICY variable is either commented or not set at all
in the /etc/sysconfig/sshd . | Rationale: | Overriding the system crypto policy makes the behavior of the SSH service violate expectations,
and makes system configuration more fragmented. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_configure_ssh_crypto_policy | Identifiers: | CCE-91639-5 | References: | disa | CCI-001453 | hipaa | 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.312(e)(1), 164.312(e)(2)(ii) | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1, CIP-007-3 R7.1 | nist | AC-17(a), AC-17(2), CM-6(a), MA-4(6), SC-13 | ospp | FCS_SSH_EXT.1, FCS_SSHS_EXT.1, FCS_SSHC_EXT.1 | pcidss | Req-2.2 | os-srg | SRG-OS-000250-GPOS-00093 | pcidss4 | 2.2.7, 2.2 |
| |
|
Group
Endpoint Protection Software
Group contains 2 groups and 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. |
Group
McAfee Endpoint Security Software
Group contains 1 group and 1 rule |
[ref]
In DoD environments, McAfee Host-based Security System (HBSS) and
VirusScan Enterprise for Linux (VSEL) is required to be installed on all systems. |
Group
McAfee Host-Based Intrusion Detection Software (HBSS)
Group contains 1 rule |
[ref]
McAfee Host-based Security System (HBSS) is a suite of software applications
used to monitor, detect, and defend computer networks and systems. |
Rule
Install the Host Intrusion Prevention System (HIPS) Module
[ref] | Install the McAfee Host Intrusion Prevention System (HIPS) Module if it is absolutely
necessary. If SELinux is enabled, do not install or enable this module. Warning:
Installing and enabling this module conflicts with SELinux.
Per DoD/DISA guidance, SELinux takes precedence over this module. Warning:
Due to McAfee HIPS being 3rd party software, automated
remediation is not available for this configuration check. | Rationale: | Without a host-based intrusion detection tool, there is no system-level defense
when an intruder gains access to a system or network. Additionally, a host-based
intrusion prevention tool can provide methods to immediately lock out detected
intrusion attempts. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_MFEhiplsm_installed | Identifiers: | CCE-91650-2 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cobit5 | APO01.06, APO07.06, APO08.04, APO10.05, APO11.06, APO12.01, APO12.02, APO12.03, APO12.04, APO12.06, APO13.01, APO13.02, BAI08.02, BAI08.04, DSS01.03, DSS01.05, DSS02.04, DSS02.05, DSS02.07, DSS03.01, DSS03.04, DSS03.05, DSS04.05, DSS05.01, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.01, DSS06.02, MEA03.03, MEA03.04 | disa | CCI-000366, CCI-001233, CCI-001263 | isa-62443-2009 | 4.2.3, 4.2.3.12, 4.2.3.7, 4.2.3.9, 4.3.3.4, 4.3.4.5.2, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.3.4.5.9, 4.4.3.2, 4.4.3.3, 4.4.3.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.4, SR 2.8, SR 2.9, SR 3.1, SR 3.3, SR 3.5, SR 3.8, SR 3.9, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.4.1, A.12.4.3, A.12.5.1, A.12.6.1, A.12.6.2, A.13.1.1, A.13.1.2, 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.7, A.14.2.8, A.15.2.1, A.16.1.1, A.16.1.2, A.16.1.3, A.16.1.4, A.16.1.5, A.16.1.6, A.16.1.7, A.18.1.4, A.18.2.2, A.18.2.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, Clause 16.1.2, Clause 7.4 | nist | CM-6(a) | nist-csf | DE.AE-1, DE.AE-2, DE.AE-3, DE.AE-4, DE.CM-1, DE.CM-5, DE.CM-6, DE.CM-7, DE.DP-2, DE.DP-3, DE.DP-4, DE.DP-5, ID.RA-1, PR.AC-5, PR.DS-5, PR.IP-8, PR.PT-4, RS.AN-1, RS.CO-3 | pcidss | Req-11.4 | os-srg | SRG-OS-000191-GPOS-00080, SRG-OS-000196, SRG-OS-000480-GPOS-00227 |
| |
|
Rule
Install Intrusion Detection Software
[ref] | The base SUSE Linux Enterprise 12 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: | CCE-92218-7 | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 7, 8, 9 | cobit5 | APO01.06, APO13.01, DSS01.03, DSS01.05, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02 | disa | CCI-001263 | isa-62443-2009 | 4.3.3.4 | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a) | nist-csf | DE.CM-1, PR.AC-5, PR.DS-5, PR.PT-4 | pcidss | Req-11.4 |
| |
|
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: | CCE-92211-2 | References: | cis-csc | 11, 13, 14, 2, 3, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS04.07, DSS05.03, DSS06.02, DSS06.06 | cui | 3.13.11 | disa | CCI-000803, CCI-002450 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.8.2.3 | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1 | nist | SC-13, CM-6(a) | nist-csf | PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1 | pcidss | Req-11.5 | cis | 1.6.4 |
| |
|
Group
GNOME Desktop Environment
Group contains 1 group and 6 rules |
[ref]
GNOME is a graphical desktop environment bundled with many Linux distributions that
allow users to easily interact with the operating system graphically rather than
textually. The GNOME Graphical Display Manager (GDM) provides login, logout, and user
switching contexts as well as display server management.
GNOME is developed by the GNOME Project and is considered the default
Red Hat Graphical environment.
For more information on GNOME and the GNOME Project, see https://www.gnome.org. |
Group
Configure GNOME Screen Locking
Group contains 5 rules |
[ref]
In the default GNOME3 desktop, the screen can be locked
by selecting the user name in the far right corner of the main panel and
selecting Lock.
The following sections detail commands to enforce idle activation of the screensaver,
screen locking, a blank-screen screensaver, and an idle activation time.
Because users should be trained to lock the screen when they
step away from the computer, the automatic locking feature is only
meant as a backup.
The root account can be screen-locked; however, the root account should
never be used to log into an X Windows environment and should only
be used to for direct login via console in emergency circumstances.
For more information about enforcing preferences in the GNOME3 environment using the DConf
configuration system, see http://wiki.gnome.org/dconf and
the man page dconf(1) . |
Rule
Enable GNOME3 Screensaver Idle Activation
[ref] | To activate the screensaver in the GNOME3 desktop after a period of inactivity,
add or set idle-activation-enabled to true in
/etc/dconf/db/local.d/00-security-settings . For example:
[org/gnome/desktop/screensaver]
idle-activation-enabled=true
Once the setting has been added, add a lock to
/etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification.
For example:
/org/gnome/desktop/screensaver/idle-activation-enabled
After the settings have been set, run dconf update . | Rationale: | A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate
physical vicinity of the information system but does not logout because of the temporary nature of the absence.
Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity,
GNOME desktops can be configured to identify when a user's session has idled and take action to initiate the
session lock.
Enabling idle activation of the screensaver ensures the screensaver will
be activated after the idle delay. Applications requiring continuous,
real-time screen display (such as network management products) require the
login session does not have administrator rights and the display station is located in a
controlled-access area. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_screensaver_idle_activation_enabled | Identifiers: | CCE-92219-5 | References: | cis-csc | 1, 12, 15, 16 | cjis | 5.5.5 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.10 | disa | CCI-000057 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a), AC-11(a) | nist-csf | PR.AC-7 | ospp | FMT_MOF_EXT.1 | pcidss | Req-8.1.8 | os-srg | SRG-OS-000029-GPOS-00010 | pcidss4 | 8.2.8, 8.2 |
| |
|
Rule
Set GNOME3 Screensaver Inactivity Timeout
[ref] | The idle time-out value for inactivity in the GNOME3 desktop is configured via the idle-delay
setting must be set under an appropriate configuration file(s) in the /etc/dconf/db/local.d directory
and locked in /etc/dconf/db/local.d/locks directory to prevent user modification.
For example, to configure the system for a 15 minute delay, add the following to
/etc/dconf/db/local.d/00-security-settings :
[org/gnome/desktop/session]
idle-delay=uint32 900
| Rationale: | A session time-out lock is a temporary action taken when a user stops work and moves away from
the immediate physical vicinity of the information system but does not logout because of the
temporary nature of the absence. Rather than relying on the user to manually lock their operating
system session prior to vacating the vicinity, GNOME3 can be configured to identify when
a user's session has idled and take action to initiate a session lock. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_screensaver_idle_delay | Identifiers: | CCE-83010-9 | References: | cis-csc | 1, 12, 15, 16 | cjis | 5.5.5 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.10 | disa | CCI-000057, CCI-000060 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | AC-11(a), AC-11.1 (ii) | nist-csf | PR.AC-7 | ospp | FMT_MOF_EXT.1 | pcidss | Req-8.1.8 | os-srg | SRG-OS-000029-GPOS-00010, SRG-OS-000031-GPOS-00012 | stigid | SLES-12-010080 | pcidss4 | 8.2.8, 8.2 | stigref | SV-217109r646684_rule |
| |
|
Rule
Enable GNOME3 Screensaver Lock After Idle Period
[ref] |
To activate locking of the screensaver in the GNOME3 desktop when it is activated,
run the following command to configure the SUSE operating system to allow the user to lock the GUI:
gsettings set org.gnome.desktop.lockdown disable-lock-screen false
Validate that disable-lock-screen has been set to false with the command:
gsettings get org.gnome.desktop.lockdown disable-lock-screen
| Rationale: | A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity
of the information system but does not want to logout because of the temporary nature of the absense. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_screensaver_lock_enabled | Identifiers: | CCE-83222-0 | References: | cis-csc | 1, 12, 15, 16 | cjis | 5.5.5 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.10 | disa | CCI-000056, CCI-000058, CCI-000060 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | AC-11(b), AC-11(a), AC-11(1), AC-11(1).1, AC-11.1(iii), AC-11 | nist-csf | PR.AC-7 | ospp | FMT_MOF_EXT.1 | pcidss | Req-8.1.8 | os-srg | SRG-OS-000028-GPOS-00009, SRG-OS-000030-GPOS-00011 | stigid | SLES-12-010060 | pcidss4 | 8.2.8, 8.2 | stigref | SV-217107r603262_rule |
| |
|
Rule
Implement Blank Screensaver
[ref] |
On SUSE users should set the screensaver to use publicly viewable images or blank screen
by doing the following:
Find the Settings menu and then navigate to the Background selection section
- Click "Applications" on the bottom left.
- Hover over "System Tools" with the mouse.
- Click the "Settings" icon under System Tools.
- Click "Background" and then "Lock Screen".
- Select image and set the Lock Screen image to the user's choice.
- Click "Select".
- Exit Settings Dialog.
To set the screensaver mode in the GNOME3 desktop to a blank screen,
add or set picture-uri to string '' in
/etc/dconf/db/local.d/00-security-settings . For example:
[org/gnome/desktop/screensaver]
picture-uri=string ''
Once the settings have been added, add a lock to
/etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification.
For example:
/org/gnome/desktop/screensaver/picture-uri
After the settings have been set, run dconf update . | Rationale: | Setting the screensaver mode to blank-only conceals the
contents of the display from passersby. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_screensaver_mode_blank | Identifiers: | CCE-83221-2 | References: | cis-csc | 1, 12, 15, 16 | cjis | 5.5.5 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.10 | disa | CCI-000060 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | AC-11(1), CM-6(a), AC-11(1).1 | nist-csf | PR.AC-7 | ospp | FMT_MOF_EXT.1 | pcidss | Req-8.1.8 | os-srg | SRG-OS-000031-GPOS-00012 | stigid | SLES-12-010100 | pcidss4 | 8.2.8, 8.2 | stigref | SV-217111r918489_rule |
| |
|
Rule
Ensure Users Cannot Change GNOME3 Session Idle Settings
[ref] | If not already configured, ensure that users cannot change GNOME3 session idle settings
by adding /org/gnome/desktop/session/idle-delay
to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification.
For example:
/org/gnome/desktop/session/idle-delay
After the settings have been set, run dconf update . | Rationale: | A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate
physical vicinity of the information system but does not logout because of the temporary nature of the absence.
Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity,
GNOME desktops can be configured to identify when a user's session has idled and take action to initiate the
session lock. As such, users should not be allowed to change session settings. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_gnome_session_idle_user_locks | Identifiers: | CCE-91636-1 | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.10 | disa | CCI-000057, CCI-000060 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a) | nist-csf | PR.AC-7 | ospp | FMT_MOF_EXT.1 | pcidss | Req-8.1.8 | os-srg | SRG-OS-000029-GPOS-00010, SRG-OS-000031-GPOS-00012 | stigid | SLES-12-010080 | pcidss4 | 8.2.8, 8.2 | stigref | SV-217109r646684_rule |
| |
|
Rule
Make sure that the dconf databases are up-to-date with regards to respective keyfiles
[ref] | By default, DConf uses a binary database as a data backend.
The system-level database is compiled from keyfiles in the /etc/dconf/db/
directory by the dconf update command. More specifically, content present
in the following directories:
/etc/dconf/db/gdm.d
/etc/dconf/db/local.d
| Rationale: | Unlike text-based keyfiles, the binary database is impossible to check by OVAL.
Therefore, in order to evaluate dconf configuration, both have to be true at the same time -
configuration files have to be compliant, and the database needs to be more recent than those keyfiles,
which gives confidence that it reflects them. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_dconf_db_up_to_date | Identifiers: | CCE-83182-6 | References: | | |
|
Group
Updating Software
Group contains 4 rules |
[ref]
The zypper 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.
SUSE Linux Enterprise 12 systems contain an installed software catalog called
the RPM database, which records metadata of installed packages. Consistently using
zypper or the graphical Software Update for all software installation
allows for insight into the current inventory of installed software on the system.
|
Rule
Ensure gpgcheck Enabled In Main zypper Configuration
[ref] | The gpgcheck option controls whether
RPM packages' signatures are always checked prior to installation.
To configure zypper to check package signatures before installing
them, ensure the following line appears in /etc/zypp/zypp.conf in
the [main] section:
gpgcheck=1
| Rationale: | Changes to any software components can have significant effects on the
overall security of the operating system. This requirement ensures the
software has not been tampered with and that it has been provided by a
trusted vendor.
Accordingly, patches, service packs, device drivers, or operating system
components must be signed with a certificate recognized and approved by the
organization.
Verifying the authenticity of the software prior to installation
validates the integrity of the patch or upgrade received from a vendor.
This ensures the software has not been tampered with and that it has been
provided by a trusted vendor. Self-signed certificates are disallowed by
this requirement. Certificates used to verify the software must be from an
approved Certificate Authority (CA). | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_globally_activated | Identifiers: | CCE-83068-7 | References: | cis-csc | 11, 2, 3, 9 | cjis | 5.10.4.1 | cobit5 | APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02 | cui | 3.4.8 | disa | CCI-001749 | hipaa | 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i) | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4 | nist | CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), SA-12, SA-12(10), CM-11(a), CM-11(b) | nist-csf | PR.DS-6, PR.DS-8, PR.IP-1 | ospp | FPT_TUD_EXT.1, FPT_TUD_EXT.2 | pcidss | Req-6.2 | os-srg | SRG-OS-000366-GPOS-00153 | stigid | SLES-12-010550 | cis | 1.2.3 | anssi | R59 | pcidss4 | 6.3.3, 6.3 | stigref | SV-217153r877463_rule |
| |
|
Rule
Ensure gpgcheck Enabled for All zypper Package Repositories
[ref] | To ensure signature checking is not disabled for
any repos, remove any lines from files in /etc/yum.repos.d of the form:
gpgcheck=0
| Rationale: | Verifying the authenticity of the software prior to installation validates
the integrity of the patch or upgrade received from a vendor. This ensures
the software has not been tampered with and that it has been provided by a
trusted vendor. Self-signed certificates are disallowed by this
requirement. Certificates used to verify the software must be from an
approved Certificate Authority (CA)." | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_never_disabled | Identifiers: | CCE-83258-4 | References: | cis-csc | 11, 2, 3, 9 | cjis | 5.10.4.1 | cobit5 | APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02 | cui | 3.4.8 | disa | CCI-001749 | hipaa | 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i) | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4 | nist | CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), SA-12, SA-12(10), CM-11(a), CM-11(b) | nist-csf | PR.DS-6, PR.DS-8, PR.IP-1 | ospp | FPT_TUD_EXT.1, FPT_TUD_EXT.2 | pcidss | Req-6.2 | os-srg | SRG-OS-000366-GPOS-00153 | cis | 1.2.3 | anssi | R59 | pcidss4 | 6.3.3, 6.3 |
| |
|
Rule
Ensure SUSE GPG Key Installed
[ref] | To ensure the system can cryptographically verify base software packages
come from SUSE (and to connect to the SUSE to receive them),
the SUSE GPG key must properly be installed. To install the SUSE GPG
key, run:
$ sudo zypper install suse-build-key
If the system is not connected to the Internet or an RHN Satellite, then
install the SUSE GPG key from trusted media such as the SUSE
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/content.key or
$ sudo rpm --import /media/cdrom/repodata/repomd.xml.key
Alternatively, the key may be pre-loaded during the SUSE installation. In
such cases, one can use the repository cache files to install the key,
for example by running the following command:
sudo rpm --import /var/cache/zypp/raw/Basesystem_Module_15_SP2_x86_64:SLE-Module-Basesystem15-SP2-Pool/repodata/repomd.xml.key
| 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 SUSE GPG key is necessary to cryptographically verify packages are
from SUSE. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_suse_gpgkey_installed | Identifiers: | CCE-91482-0 | References: | cis-csc | 11, 2, 3, 9 | cjis | 5.10.4.1 | cobit5 | APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02 | cui | 3.4.8 | disa | CCI-001749 | hipaa | 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i) | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4 | nerc-cip | CIP-003-8 R4.2, CIP-003-8 R6, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | nist | CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a) | nist-csf | PR.DS-6, PR.DS-8, PR.IP-1 | ospp | FPT_TUD_EXT.1, FPT_TUD_EXT.2 | pcidss | Req-6.2 | os-srg | SRG-OS-000366-GPOS-00153 | pcidss4 | 6.3.3, 6.3 |
| |
|
Rule
Ensure Software Patches Installed
[ref] |
If the system is configured for online updates, invoking the following command will list available
security updates:
$ sudo zypper refresh && sudo zypper list-patches -g security
NOTE: U.S. Defense systems are required to be patched within 30 days or sooner as local policy
dictates. Warning:
The OVAL feed of SUSE Linux Enterprise 12 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: | CCE-83002-6 | References: | cis-csc | 18, 20, 4 | cjis | 5.10.4.1 | cobit5 | APO12.01, APO12.02, APO12.03, APO12.04, BAI03.10, DSS05.01, DSS05.02 | disa | CCI-000366, CCI-001227 | isa-62443-2009 | 4.2.3, 4.2.3.12, 4.2.3.7, 4.2.3.9 | iso27001-2013 | A.12.6.1, A.14.2.3, A.16.1.3, A.18.2.2, A.18.2.3 | nist | SI-2(5), SI-2(c), CM-6(a) | nist-csf | ID.RA-1, PR.IP-12 | ospp | FMT_MOF_EXT.1 | pcidss | Req-6.2 | os-srg | SRG-OS-000480-GPOS-00227 | stigid | SLES-12-010010 | cis | 1.9 | anssi | R61 | pcidss4 | 6.3.3, 6.3 | stigref | SV-217102r603262_rule |
| |
|
Group
Account and Access Control
Group contains 10 groups and 18 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
SUSE Linux Enterprise 12. |
Group
Protect Accounts by Configuring PAM
Group contains 2 groups and 8 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 3 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: | CCE-92217-9 | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.1.1 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.8 | disa | CCI-000200 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(f), IA-5(1)(e) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.5 | os-srg | SRG-OS-000077-GPOS-00045 | anssi | R31 | pcidss4 | 8.3.7, 8.3 |
| |
|
Rule
Set Deny For Failed Password Attempts
[ref] | The SUSE Linux Enterprise 12 operating system must lock an account after - at most - 3
consecutive invalid access attempts. | Rationale: | By limiting the number of failed logon attempts, the risk of unauthorized
system access via user password guessing, otherwise known as brute-force
attacks, is reduced. Limits are imposed by locking the account.
To configure the operating system to lock an account after three
unsuccessful consecutive access attempts using pam_tally2.so ,
modify the content of both /etc/pam.d/login and
/etc/pam.d/common-account as follows:
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_tally2 | Identifiers: | CCE-83055-4 | References: | | |
|
Rule
Set Lockout Time for Failed Password Attempts using pam_tally2
[ref] | This rule configures the system to lock out accounts during a specified time period after a
number of incorrect login attempts using pam_tally2.so . | 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_tally2_unlock_time | Identifiers: | CCE-91598-3 | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | disa | CCI-002238, CCI-000044 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a), AC-7(b), IA-5(c) | nist-csf | PR.AC-7 | ospp | FMT_MOF_EXT.1 | pcidss | Req-8.1.7 | os-srg | SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | cis | 5.3.2 | anssi | R31 | pcidss4 | 8.3.4, 8.3 |
| |
|
Group
Set Password Hashing Algorithm
Group contains 4 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 PAM's Common Authentication Hashing Algorithm
[ref] | The PAM system service can be configured to only store encrypted
representations of passwords. In
/etc/pam.d/common-auth ,
the
auth section of the file controls which PAM modules execute
during a password change. Set the pam_unix.so module in the
auth section to include the argument sha512 , as shown
below:
auth required pam_unix.so sha512 other arguments...
This will help ensure when local users change their authentication method,
hashes for the new authentications will be generated using the SHA-512
algorithm. This is the default. | Rationale: | Unapproved mechanisms used for authentication to the cryptographic module
are not verified and therefore cannot be relied on to provide
confidentiality or integrity, and data may be compromised.
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_commonauth | Identifiers: | CCE-91647-8 | References: | | |
|
Rule
Set Password Hashing Algorithm in /etc/libuser.conf
[ref] | In /etc/libuser.conf , add or correct the following line in its [defaults]
section to ensure the system will use the sha512
algorithm for password hashing:
crypt_style = sha512
| Rationale: | Passwords need to be protected at all times, and encryption is the standard method for
protecting passwords. If passwords are not encrypted, they can be plainly read
(i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm
are no more protected than if they are kept in plain text.
This setting ensures user and group account administration utilities are configured to store
only encrypted representations of passwords. Additionally, the crypt_style
configuration option in /etc/libuser.conf ensures the use of a strong hashing
algorithm that makes password cracking attacks more difficult. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_libuserconf | Identifiers: | CCE-92220-3 | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.2 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.13.11 | disa | CCI-000196 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0418, 1055, 1402 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(c), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.1 | os-srg | SRG-OS-000073-GPOS-00041 | pcidss4 | 8.3.2, 8.3 |
| |
|
Rule
Set Password Hashing Algorithm in /etc/login.defs
[ref] | In /etc/login.defs , add or update the following line to ensure the system will use
SHA512 as the hashing algorithm:
ENCRYPT_METHOD SHA512
| Rationale: | Passwords need to be protected at all times, and encryption is the standard method for
protecting passwords. If passwords are not encrypted, they can be plainly read
(i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm
are no more protected than if they are kept in plain text.
Using a stronger hashing algorithm makes password cracking attacks more difficult. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_logindefs | Identifiers: | CCE-83029-9 | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.2 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.13.11 | disa | CCI-000196 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0418, 1055, 1402 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(c), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.1 | os-srg | SRG-OS-000073-GPOS-00041 | stigid | SLES-12-010210 | cis | 5.4.1.1 | pcidss4 | 8.3.2, 8.3 | stigref | SV-217122r646689_rule |
| |
|
Rule
Set PAM''s Password Hashing Algorithm
[ref] | The PAM system service can be configured to only store encrypted representations of passwords.
In "/etc/pam.d/common-password", the password section of the file controls which
PAM modules to execute during a password change.
Set the pam_unix.so module in the password section to include the option
sha512 and no other hashing
algorithms as shown below:
password required pam_unix.so sha512
other arguments...
This will help ensure that new passwords for local users will be stored using the
sha512 algorithm. Warning:
The hashing algorithms to be used with pam_unix.so are defined with independent module
options. There are at least 7 possible algorithms and likely more algorithms will be
introduced along the time. Due the the number of options and its possible combinations,
the use of multiple hashing algorithm options may bring unexpected behaviors to the
system. For this reason the check will pass only when one hashing algorithm option is
defined and is aligned to the "var_password_hashing_algorithm_pam" variable. The
remediation will ensure the correct option and remove any other extra hashing algorithm
option. | Rationale: | Passwords need to be protected at all times, and encryption is the standard method for
protecting passwords. If passwords are not encrypted, they can be plainly read
(i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm
are no more protected than if they are kept in plain text.
This setting ensures user and group account administration utilities are configured to store
only encrypted representations of passwords. Additionally, the crypt_style
configuration option in /etc/libuser.conf ensures the use of a strong hashing
algorithm that makes password cracking attacks more difficult. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_systemauth | Identifiers: | CCE-83184-2 | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.2 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.13.11 | disa | CCI-000196, CCI-000803, CCI-004062 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0418, 1055, 1402 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(c), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.1 | os-srg | SRG-OS-000073-GPOS-00041, SRG-OS-000120-GPOS-00061 | stigid | SLES-12-010230 | anssi | R68 | pcidss4 | 8.3.2, 8.3 | stigref | SV-217124r877397_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/login
to include showfailed option, such as:
session optional 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: | CCE-83149-5 | References: | cis-csc | 1, 12, 15, 16 | cjis | 5.5.2 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | disa | CCI-000052 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | ism | 0582, 0584, 05885, 0586, 0846, 0957 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | AC-9, AC-9(1) | nist-csf | PR.AC-7 | pcidss | Req-10.2.4 | os-srg | SRG-OS-000480-GPOS-00227 | stigid | SLES-12-010390 | pcidss4 | 10.2.1.4, 10.2.1, 10.2 | stigref | SV-217140r858540_rule |
| |
|
Group
Protect Physical Console Access
Group contains 2 groups and 4 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 1 group and 4 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
Hardware Tokens for Authentication
Group contains 4 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 Smart Card Packages For Multifactor Authentication
[ref] | Configure the operating system to implement multifactor authentication by
installing the required package with the following command:
The pam_pkcs11 package can be installed with the following command:
$ sudo zypper install pam_pkcs11
The mozilla-nss package can be installed with the following command:
$ sudo zypper install mozilla-nss
The mozilla-nss-tools package can be installed with the following command:
$ sudo zypper install mozilla-nss-tools
The pcsc-ccid package can be installed with the following command:
$ sudo zypper install pcsc-ccid
The pcsc-lite package can be installed with the following command:
$ sudo zypper install pcsc-lite
The pcsc-tools package can be installed with the following command:
$ sudo zypper install pcsc-tools
The opensc package can be installed with the following command:
$ sudo zypper install opensc
The coolkey package can be installed with the following command:
$ sudo zypper install coolkey
| Rationale: | Using an authentication device, such as a CAC or token that is separate from
the information system, ensures that even if the information system is
compromised, that compromise will not affect credentials stored on the
authentication device.
Multifactor solutions that require devices separate from
information systems gaining access include, for example, hardware tokens
providing time-based or challenge-response authenticators and smart cards such
as the U.S. Government Personal Identity Verification card and the DoD Common
Access Card. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_install_smartcard_packages | Identifiers: | CCE-83177-6 | References: | disa | CCI-000765, CCI-000766, CCI-001948, CCI-001953, CCI-001954, CCI-004046, CCI-004047 | nist | CM-6(a) | pcidss | Req-8.3 | os-srg | SRG-OS-000105-GPOS-00052, SRG-OS-000375-GPOS-00160, SRG-OS-000375-GPOS-00161, SRG-OS-000377-GPOS-00162 | stigid | SLES-12-030500 | stigref | SV-217299r854165_rule |
| |
|
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: | CCE-91646-0 | References: | disa | CCI-001954 | ism | 1382, 1384, 1386 | nist | IA-2(1), IA-2(2), IA-2(3), IA-2(4), IA-2(6), IA-2(7), IA-2(11), CM-6(a) | pcidss | Req-8.3 | os-srg | 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: | CCE-92221-1 | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-000765, CCI-000766, CCI-000767, CCI-000768, CCI-000771, CCI-000772, CCI-000884 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 1382, 1384, 1386 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-2(1), IA-2(2), IA-2(3), IA-2(4), IA-2(6), IA-2(7), IA-2(11), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.3 | os-srg | 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
Force opensc To Use Defined Smart Card Driver
[ref] | The OpenSC smart card middleware can auto-detect smart card drivers; however by
forcing the smart card driver in use by your organization, opensc will no longer
autodetect or use other drivers unless specified. This helps to prevent
users from using unauthorized smart cards. The default smart card driver for this
profile is cac .
To force the OpenSC driver, edit the /etc/opensc.conf .
Look for a line similar to:
# force_card_driver = customcos;
and change it to:
force_card_driver = 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.
Forcing 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_force_opensc_card_drivers | Identifiers: | CCE-92222-9 | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-000765, CCI-000766, CCI-000767, CCI-000768, CCI-000771, CCI-000772, CCI-000884 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 1382, 1384, 1386 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-2(1), IA-2(2), IA-2(3), IA-2(4), IA-2(6), IA-2(7), IA-2(11), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.3 | os-srg | 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 |
| |
|
Group
Protect Accounts by Restricting Password-Based Login
Group contains 3 groups and 6 rules |
[ref]
Conventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the /etc/passwd and
/etc/shadow files. Password-based login is vulnerable to
guessing of weak passwords, and to sniffing and man-in-the-middle
attacks against passwords entered over a network or at an insecure
console. Therefore, mechanisms for accessing accounts by entering
usernames and passwords should be restricted to those which are
operationally necessary. |
Group
Set Account Expiration Parameters
Group contains 2 rules |
[ref]
Accounts can be configured to be automatically disabled
after a certain time period,
meaning that they will require administrator interaction to become usable again.
Expiration of accounts after inactivity can be set for all accounts by default
and also on a per-account basis, such as for accounts that are known to be temporary.
To configure automatic expiration of an account following
the expiration of its password (that is, after the password has expired and not been changed),
run the following command, substituting NUM_DAYS and USER appropriately:
$ sudo chage -I NUM_DAYS USER
Accounts, such as temporary accounts, can also be configured to expire on an explicitly-set date with the
-E option.
The file /etc/default/useradd controls
default settings for all newly-created accounts created with the system's
normal command line utilities. Warning:
This will only apply to newly created accounts |
Rule
Set Account Expiration Following Inactivity
[ref] | To specify the number of days after a password expires (which
signifies inactivity) until an account is permanently disabled, add or correct
the following line in /etc/default/useradd :
INACTIVE=90
If a password is currently on the verge of expiration, then
90
day(s) remain(s) until the account is automatically
disabled. However, if the password will not expire for another 60 days, then 60
days plus 90 day(s) could
elapse until the account would be automatically disabled. See the
useradd man page for more information. | Rationale: | Inactive identifiers pose a risk to systems and applications because attackers may exploit an inactive identifier and potentially obtain undetected access to the system.
Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials.
Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_account_disable_post_pw_expiration | Identifiers: | CCE-83051-3 | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 3, 5, 7, 8 | cjis | 5.6.2.1.1 | cobit5 | DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.6 | disa | CCI-000017, CCI-000795 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 6.2 | iso27001-2013 | A.12.4.1, A.12.4.3, A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | nist | IA-4(e), AC-2(3), CM-6(a) | nist-csf | DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7 | pcidss | Req-8.1.4 | os-srg | SRG-OS-000118-GPOS-00060 | stigid | SLES-12-010340 | cis | 5.4.1.5 | pcidss4 | 8.2.6, 8.2 | stigref | SV-217136r928528_rule |
| |
|
Rule
Ensure All Accounts on the System Have Unique Names
[ref] | Ensure accounts on the system have unique names.
To ensure all accounts have unique names, run the following command:
$ sudo getent passwd | awk -F: '{ print $1}' | uniq -d
If a username is returned, change or delete the username. | Rationale: | Unique usernames allow for accountability on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_account_unique_name | Identifiers: | CCE-91550-4 | References: | | |
|
Group
Set Password Expiration Parameters
Group contains 1 rule |
[ref]
The file /etc/login.defs controls several
password-related settings. Programs such as passwd ,
su , and
login consult /etc/login.defs to determine
behavior with regard to password aging, expiration warnings,
and length. See the man page login.defs(5) for more information.
Users should be forced to change their passwords, in order to
decrease the utility of compromised passwords. However, the need to
change passwords often should be balanced against the risk that
users will reuse or write down passwords if forced to change them
too often. Forcing password changes every 90-360 days, depending on
the environment, is recommended. Set the appropriate value as
PASS_MAX_DAYS and apply it to existing accounts with the
-M flag.
The PASS_MIN_DAYS ( -m ) setting prevents password
changes for 7 days after the first change, to discourage password
cycling. If you use this setting, train users to contact an administrator
for an emergency password change in case a new password becomes
compromised. The PASS_WARN_AGE ( -W ) setting gives
users 7 days of warnings at login time that their passwords are about to expire.
For example, for each existing human user USER, expiration parameters
could be adjusted to a 180 day maximum password age, 7 day minimum password
age, and 7 day warning period with the following command:
$ sudo chage -M 180 -m 7 -W 7 USER
|
Rule
Set Password Maximum Age
[ref] | To specify password maximum age for new accounts,
edit the file /etc/login.defs
and add or correct the following line:
PASS_MAX_DAYS 90
A value of 180 days is sufficient for many environments.
The DoD requirement is 60.
The profile requirement is 90 . | Rationale: | Any password, no matter how complex, can eventually be cracked. Therefore, passwords
need to be changed periodically. If the operating system does not limit the lifetime
of passwords and force users to change their passwords, there is the risk that the
operating system passwords could be compromised.
Setting the password maximum age ensures users are required to
periodically change their passwords. Requiring shorter password lifetimes
increases the risk of users writing down the password in a convenient
location subject to physical compromise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_maximum_age_login_defs | Identifiers: | CCE-83050-5 | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.1 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.6 | disa | CCI-000199, CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0418, 1055, 1402 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(f), IA-5(1)(d), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.4 | os-srg | SRG-OS-000076-GPOS-00044 | stigid | SLES-12-010280 | cis | 5.4.1.2 | pcidss4 | 8.3.9, 8.3 | stigref | SV-217130r646701_rule |
| |
|
Group
Verify Proper Storage and Existence of Password
Hashes
Group contains 3 rules |
[ref]
By default, password hashes for local accounts are stored
in the second field (colon-separated) in
/etc/shadow . This file should be readable only by
processes running with root credentials, preventing users from
casually accessing others' password hashes and attempting
to crack them.
However, it remains possible to misconfigure the system
and store password hashes
in world-readable files such as /etc/passwd , or
to even store passwords themselves in plaintext on the system.
Using system-provided tools for password change/creation
should allow administrators to avoid such misconfiguration. |
Rule
Verify All Account Password Hashes are Shadowed
[ref] | If any password hashes are stored in /etc/passwd (in the second field,
instead of an x or * ), the cause of this misconfiguration should be
investigated. The account should have its password reset and the hash should be
properly stored, or the account should be deleted entirely. | Rationale: | The hashes for all user account passwords should be stored in
the file /etc/shadow and never in /etc/passwd ,
which is readable by all users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_all_shadowed | Identifiers: | CCE-91551-2 | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.5.2 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.10 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 1410 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(h), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.1 | cis | 6.2.1 | pcidss4 | 8.3.2, 8.3 |
| |
|
Rule
All GIDs referenced in /etc/passwd must be defined in /etc/group
[ref] | Add a group to the system for each GID referenced without a corresponding group. | Rationale: | If a user is assigned the Group Identifier (GID) of a group not existing on the system, and a group
with the Group Identifier (GID) is subsequently created, the user may have unintended rights to
any files associated with the group. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_gid_passwd_group_same | Identifiers: | CCE-91552-0 | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.5.2 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-000764 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | nist | IA-2, CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.5.a | os-srg | SRG-OS-000104-GPOS-00051 | cis | 6.2.13 | pcidss4 | 8.2.2, 8.2 |
| |
|
Rule
Prevent Login to Accounts With Empty Password
[ref] | If an account is configured for password authentication
but does not have an assigned password, it may be possible to log
into the account without authentication. Remove any instances of the
nullok in
password authentication configurations in /etc/pam.d/
to prevent logins with empty passwords. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
Note that this rule is not applicable for systems running within a
container. Having user with empty password within a container is not
considered a risk, because it should not be possible to directly login into
a container anyway. | Rationale: | If an account has an empty password, anyone could log in and
run commands with the privileges of that account. Accounts with
empty passwords should never be used in operational environments. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_no_empty_passwords | Identifiers: | CCE-83039-8 | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2 | cobit5 | APO01.06, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.02, DSS06.03, DSS06.10 | cui | 3.1.1, 3.1.5 | disa | CCI-000366 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.18.1.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nist | IA-5(1)(a), IA-5(c), CM-6(a) | nist-csf | PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.DS-5 | ospp | FIA_UAU.1 | pcidss | Req-8.2.3 | os-srg | SRG-OS-000480-GPOS-00227 | stigid | SLES-12-010231 | pcidss4 | 8.3.1, 8.3 | stigref | SV-217125r603262_rule |
| |
|
Group
GRUB2 bootloader configuration
Group contains 1 group and 2 rules |
[ref]
During the boot process, the boot loader is
responsible for starting the execution of the kernel and passing
options to it. The boot loader allows for the selection of
different kernels - possibly on different partitions or media.
The default SUSE Linux Enterprise 12 boot loader for x86 systems is called GRUB2.
Options it can pass to the kernel include single-user mode, which
provides root access without any authentication, and the ability to
disable SELinux. To prevent local users from modifying the boot
parameters and endangering security, protect the boot loader configuration
with a password and ensure its configuration file's permissions
are set properly. |
Group
Non-UEFI GRUB2 bootloader configuration
Group contains 2 rules |
[ref]
Non-UEFI GRUB2 bootloader configuration |
Rule
Verify /boot/grub2/grub.cfg Group Ownership
[ref] | The file /boot/grub2/grub.cfg should
be group-owned by the root group to prevent
destruction or modification of the file.
To properly set the group owner of /boot/grub2/grub.cfg , run the command:
$ sudo chgrp root /boot/grub2/grub.cfg
| Rationale: | The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_grub2_cfg | Identifiers: | CCE-91623-9 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 1.5.2 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/grub.cfg User Ownership
[ref] | The file /boot/grub2/grub.cfg should
be owned by the root user to prevent destruction
or modification of the file.
To properly set the owner of /boot/grub2/grub.cfg , run the command:
$ sudo chown root /boot/grub2/grub.cfg
| Rationale: | Only root should be able to modify important boot parameters. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_grub2_cfg | Identifiers: | CCE-91624-7 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 1.5.2 | anssi | R29 | pcidss4 | 2.2.6, 2.2 |
| |
|
Group
Configure Syslog
Group contains 2 groups and 6 rules |
[ref]
The syslog service has been the default Unix logging mechanism for
many years. It has a number of downsides, including inconsistent log format,
lack of authentication for received messages, and lack of authentication,
encryption, or reliable transport for messages sent over a network. However,
due to its long history, syslog is a de facto standard which is supported by
almost all Unix applications.
In SUSE Linux Enterprise 12, rsyslog has replaced ksyslogd as the
syslog daemon of choice, and it includes some additional security features
such as reliable, connection-oriented (i.e. TCP) transmission of logs, the
option to log to database formats, and the encryption of log data en route to
a central logging server.
This section discusses how to configure rsyslog for
best effect, and how to use tools provided with the system to maintain and
monitor logs. |
Group
Ensure Proper Configuration of Log Files
Group contains 3 rules |
[ref]
The file /etc/rsyslog.conf controls where log message are written.
These are controlled by lines called rules, which consist of a
selector and an action.
These rules are often customized depending on the role of the system, the
requirements of the environment, and whatever may enable
the administrator to most effectively make use of log data.
The default rules in SUSE Linux Enterprise 12 are:
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* -/var/log/maillog
cron.* /var/log/cron
*.emerg *
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log
See the man page rsyslog.conf(5) for more information.
Note that the rsyslog daemon can be configured to use a timestamp format that
some log processing programs may not understand. If this occurs,
edit the file /etc/rsyslog.conf and add or edit the following line:
$ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
|
Rule
Ensure Log Files Are Owned By Appropriate Group
[ref] | The group-owner of all log files written by
rsyslog should be root .
These log files are determined by the second part of each Rule line in
/etc/rsyslog.conf and typically all appear in /var/log .
For each log file LOGFILE referenced in /etc/rsyslog.conf ,
run the following command to inspect the file's group owner:
$ ls -l LOGFILE
If the owner is not root ,
run the following command to
correct this:
$ sudo chgrp root LOGFILE
| Rationale: | The log files generated by rsyslog contain valuable information regarding system
configuration, user authentication, and other such information. Log files should be
protected from unauthorized access. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_files_groupownership | Identifiers: | CCE-91508-2 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | disa | CCI-001314 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | ism | 0988, 1405 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-10.5.1, Req-10.5.2 | cis | 4.2.1.3 | anssi | R71 | pcidss4 | 10.3.2, 10.3 |
| |
|
Rule
Ensure Log Files Are Owned By Appropriate User
[ref] | The owner of all log files written by
rsyslog should be
root .
These log files are determined by the second part of each Rule line in
/etc/rsyslog.conf and typically all appear in /var/log .
For each log file LOGFILE referenced in /etc/rsyslog.conf ,
run the following command to inspect the file's owner:
$ ls -l LOGFILE
If the owner is not
root ,
run the following command to
correct this:
$ sudo chown root LOGFILE
| Rationale: | The log files generated by rsyslog contain valuable information regarding system
configuration, user authentication, and other such information. Log files should be
protected from unauthorized access. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_files_ownership | Identifiers: | CCE-91509-0 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | disa | CCI-001314 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | ism | 0988, 1405 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-10.5.1, Req-10.5.2 | cis | 4.2.1.3 | anssi | R71 | pcidss4 | 10.3.2, 10.3 |
| |
|
Rule
Ensure System Log Files Have Correct Permissions
[ref] | The file permissions for all log files written by rsyslog should
be set to 640, or more restrictive. These log files are determined by the
second part of each Rule line in /etc/rsyslog.conf and typically
all appear in /var/log . For each log file LOGFILE
referenced in /etc/rsyslog.conf , run the following command to
inspect the file's permissions:
$ ls -l LOGFILE
If the permissions are not 640 or more restrictive, run the following
command to correct this:
$ sudo chmod 640 LOGFILE
" | Rationale: | Log files can contain valuable information regarding system
configuration. If the system log files are not protected unauthorized
users could change the logged data, eliminating their forensic value. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_files_permissions | Identifiers: | CCE-91510-8 | References: | disa | CCI-001314 | ism | 0988, 1405 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | pcidss | Req-10.5.1, Req-10.5.2 | cis | 4.2.1.3 | anssi | R71 | pcidss4 | 10.3.1, 10.3 |
| |
|
Group
Ensure All Logs are Rotated by logrotate
Group contains 3 rules |
[ref]
Edit the file /etc/logrotate.d/syslog . Find the first
line, which should look like this (wrapped for clarity):
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler \
/var/log/boot.log /var/log/cron {
Edit this line so that it contains a one-space-separated
listing of each log file referenced in /etc/rsyslog.conf .
All logs in use on a system must be rotated regularly, or the
log files will consume disk space over time, eventually interfering
with system operation. The file /etc/logrotate.d/syslog is the
configuration file used by the logrotate program to maintain all
log files written by syslog . By default, it rotates logs weekly and
stores four archival copies of each log. These settings can be
modified by editing /etc/logrotate.conf , but the defaults are
sufficient for purposes of this guide.
Note that logrotate is run nightly by the cron job
/etc/cron.daily/logrotate . If particularly active logs need to be
rotated more often than once a day, some other mechanism must be
used. |
Rule
Ensure logrotate is Installed
[ref] | logrotate is installed by default. The logrotate package can be installed with the following command: $ sudo zypper install logrotate
| Rationale: | The logrotate package provides the logrotate services. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_logrotate_installed | Identifiers: | CCE-92386-2 | References: | cis-csc | 1, 14, 15, 16, 3, 5, 6 | cobit5 | APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9 | iso27001-2013 | A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1 | nist | CM-6(a) | nist-csf | PR.PT-1 | pcidss | Req-10.7 | cis | 4.2.4 | anssi | R71 | pcidss4 | 10.5.1, 10.5 |
| |
|
Rule
Ensure Logrotate Runs Periodically
[ref] | The logrotate utility allows for the automatic rotation of
log files. The frequency of rotation is specified in /etc/logrotate.conf ,
which triggers a cron task or a timer. To configure logrotate to run daily, add or correct
the following line in /etc/logrotate.conf :
# rotate log files frequency
daily
| Rationale: | Log files that are not properly rotated run the risk of growing so large
that they fill up the /var/log partition. Valuable logging information could be lost
if the /var/log partition becomes full. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_logrotate_activated | Identifiers: | CCE-91511-6 | References: | cis-csc | 1, 14, 15, 16, 3, 5, 6 | cobit5 | APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9 | iso27001-2013 | A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1 | nist | CM-6(a) | nist-csf | PR.PT-1 | pcidss | Req-10.7 | cis | 4.2.4 | anssi | R71 |
| |
|
Rule
Enable logrotate Timer
[ref] |
The logrotate timer can be enabled with the following command:
$ sudo systemctl enable logrotate.timer
| Rationale: | Log files that are not properly rotated run the risk of growing so large
that they fill up the /var/log partition. Valuable logging information could be lost
if the /var/log partition becomes full. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_timer_logrotate_enabled | Identifiers: | CCE-92401-9 | References: | cis-csc | 1, 14, 15, 16, 3, 5, 6 | cobit5 | APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9 | iso27001-2013 | A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1 | nist | CM-6(a) | nist-csf | PR.PT-1 | pcidss | Req-10.7 | cis | 4.2.4 | anssi | R71 | pcidss4 | 10.5.1, 10.5 |
| |
|
Group
Network Configuration and Firewalls
Group contains 11 groups and 14 rules |
[ref]
Most systems must be connected to a network of some
sort, and this brings with it the substantial risk of network
attack. This section discusses the security impact of decisions
about networking which must be made when configuring a system.
This section also discusses firewalls, network access
controls, and other network security frameworks, which allow
system-level rules to be written that can limit an attackers' ability
to connect to your system. These rules can specify that network
traffic should be allowed or denied from certain IP addresses,
hosts, and networks. The rules can also specify which of the
system's network services are available to particular hosts or
networks. |
Group
IPSec Support
Group contains 1 rule |
[ref]
Support for Internet Protocol Security (IPsec)
is provided with Libreswan. |
Rule
Install strongswan Package
[ref] | The Strongswan package provides an implementation of IPsec
and IKE, which permits the creation of secure tunnels over
untrusted networks. The strongswan package can be installed with the following command:
$ sudo zypper install strongswan
| Rationale: | Providing the ability for remote users or systems
to initiate a secure VPN connection protects information when it is
transmitted over a wide area network. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_strongswan_installed | Identifiers: | CCE-91625-4 | References: | cis-csc | 12, 15, 3, 5, 8 | cobit5 | APO13.01, DSS01.04, DSS05.02, DSS05.03, DSS05.04 | disa | CCI-001130, CCI-001131 | isa-62443-2009 | 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8 | isa-62443-2013 | 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 | iso27001-2013 | A.11.2.4, A.11.2.6, A.13.1.1, A.13.2.1, A.14.1.3, A.15.1.1, A.15.2.1, A.6.2.1, A.6.2.2 | nist | CM-6(a) | nist-csf | PR.AC-3, PR.MA-2, PR.PT-4 | pcidss | Req-4.1 | os-srg | SRG-OS-000480-GPOS-00227, SRG-OS-000120-GPOS-00061 |
| |
|
Group
iptables and ip6tables
Group contains 1 rule |
[ref]
A host-based firewall called netfilter is included as
part of the Linux kernel distributed with the system. It is
activated by default. This firewall is controlled by the program
iptables , and the entire capability is frequently referred to by
this name. An analogous program called ip6tables handles filtering
for IPv6.
Unlike TCP Wrappers, which depends on the network server
program to support and respect the rules written, netfilter
filtering occurs at the kernel level, before a program can even
process the data from the network packet. As such, any program on
the system is affected by the rules written.
This section provides basic information about strengthening
the iptables and ip6tables configurations included with the system.
For more complete information that may allow the construction of a
sophisticated ruleset tailored to your environment, please consult
the references at the end of this section. |
Rule
Install iptables Package
[ref] | The iptables package can be installed with the following command:
$ sudo zypper install iptables
| Rationale: | iptables controls the Linux kernel network packet filtering
code. iptables allows system operators to set up firewalls and IP
masquerading, etc.
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_iptables_installed | Identifiers: | CCE-91549-6 | References: | | |
|
Group
IPv6
Group contains 2 groups and 2 rules |
[ref]
The system includes support for Internet Protocol
version 6. A major and often-mentioned improvement over IPv4 is its
enormous increase in the number of available addresses. Another
important feature is its support for automatic configuration of
many network settings. |
Group
Disable Support for IPv6 Unless Needed
Group contains 1 rule |
[ref]
Despite configuration that suggests support for IPv6 has
been disabled, link-local IPv6 address auto-configuration occurs
even when only an IPv4 address is assigned. The only way to
effectively prevent execution of the IPv6 networking stack is to
instruct the system not to activate the IPv6 kernel module. |
Rule
Ensure IPv6 is disabled through kernel boot parameter
[ref] | To disable IPv6 protocol support in the Linux kernel,
add the argument ipv6.disable=1 to the default
GRUB2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain ipv6.disable=1 as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) ipv6.disable=1"
| Rationale: | Any unnecessary network stacks, including IPv6, should be disabled to reduce
the vulnerability to exploitation. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_ipv6_disable_argument | Identifiers: | CCE-91548-8 | References: | | |
|
Group
Configure IPv6 Settings if Necessary
Group contains 1 rule |
[ref]
A major feature of IPv6 is the extent to which systems
implementing it can automatically configure their networking
devices using information from the network. From a security
perspective, manually configuring important configuration
information is preferable to accepting it from the network
in an unauthenticated fashion. |
Rule
Disable Kernel Parameter for Accepting Source-Routed Packets on IPv6 Interfaces by Default
[ref] | To set the runtime status of the net.ipv6.conf.default.accept_source_route kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.default.accept_source_route=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv6.conf.default.accept_source_route = 0
| Rationale: | Source-routed packets allow the source of the packet to suggest routers
forward the packet along a different path than configured on the router, which can
be used to bypass network security measures. This requirement applies only to the
forwarding of source-routerd traffic, such as when IPv6 forwarding is enabled and
the system is functioning as a router.
Accepting source-routed packets in the IPv6 protocol has few legitimate
uses. It should be disabled unless it is absolutely required. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_source_route | Identifiers: | CCE-83227-9 | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 4, 6, 8, 9 | cobit5 | APO01.06, APO13.01, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.07, DSS06.02 | cui | 3.1.20 | disa | CCI-000366 | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.4.3.3 | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-7(a), CM-7(b), CM-6(a), CM-6(b), CM-6.1(iv) | nist-csf | DE.AE-1, ID.AM-3, PR.AC-5, PR.DS-5, PR.PT-4 | pcidss | Req-1.4.3 | os-srg | SRG-OS-000480-GPOS-00227 | stigid | SLES-12-030362 | cis | 3.3.1 | anssi | R13 | pcidss4 | 1.4.2, 1.4 | stigref | SV-237620r646823_rule |
| |
|
Group
Kernel Parameters Which Affect Networking
Group contains 2 groups and 7 rules |
[ref]
The sysctl utility is used to set
parameters which affect the operation of the Linux kernel. Kernel parameters
which affect networking and have security implications are described here. |
Group
Network Related Kernel Runtime Parameters for Hosts and Routers
Group contains 6 rules |
[ref]
Certain kernel parameters should be set for systems which are
acting as either hosts or routers to improve the system's ability defend
against certain types of IPv4 protocol attacks. |
Rule
Enable Kernel Parameter to Use Reverse Path Filtering on all IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.rp_filter kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.rp_filter=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv4.conf.all.rp_filter = 1
| Rationale: | Enabling reverse path filtering drops packets with source addresses
that should not have been able to be received on the interface they were
received on. It should not be used on systems which are routers for
complicated networks, but is helpful for end hosts and routers serving small
networks. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_rp_filter | Identifiers: | CCE-91533-0 | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9 | cobit5 | APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02 | cui | 3.1.20 | disa | CCI-000366, CCI-001551 | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.4.3.3 | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-7(a), CM-7(b), CM-6(a), SC-7(a) | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.PT-4 | pcidss | Req-1.4.3 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 3.3.7 | anssi | R12 | pcidss4 | 1.4.3, 1.4 |
| |
|
Rule
Disable Kernel Parameter for Accepting Secure ICMP Redirects on all IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.secure_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.secure_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv4.conf.all.secure_redirects = 0
| Rationale: | Accepting "secure" ICMP redirects (from those gateways listed as
default gateways) has few legitimate uses. It should be disabled unless it is
absolutely required. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_secure_redirects | Identifiers: | CCE-91535-5 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | cui | 3.1.20 | disa | CCI-001503, CCI-001551 | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-7(a), CM-7(b), CM-6(a), SC-7(a) | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4 | pcidss | Req-1.4.3 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 3.3.3 | anssi | R12 | pcidss4 | 1.4.3, 1.4 |
| |
|
Rule
Disable Kernel Parameter for Accepting ICMP Redirects by Default on IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.default.accept_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.accept_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv4.conf.default.accept_redirects = 0
| Rationale: | ICMP redirect messages are used by routers to inform hosts that a more
direct route exists for a particular destination. These messages modify the
host's route table and are unauthenticated. An illicit ICMP redirect
message could result in a man-in-the-middle attack.
This feature of the IPv4 protocol has few legitimate uses. It should
be disabled unless absolutely required. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_accept_redirects | Identifiers: | CCE-83081-0 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | cjis | 5.10.1.1 | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | cui | 3.1.20 | disa | CCI-000366, CCI-001551 | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-7(a), CM-7(b), CM-6(a), SC-7(a) | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4 | pcidss | Req-1.4.3 | os-srg | SRG-OS-000480-GPOS-00227 | stigid | SLES-12-030400 | cis | 3.3.3 | anssi | R12 | pcidss4 | 1.4.3, 1.4 | stigref | SV-217292r603262_rule |
| |
|
Rule
Enable Kernel Parameter to Ignore ICMP Broadcast Echo Requests on IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.icmp_echo_ignore_broadcasts kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv4.icmp_echo_ignore_broadcasts = 1
| Rationale: | Responding to broadcast (ICMP) echoes facilitates network mapping
and provides a vector for amplification attacks.
Ignoring ICMP echo requests (pings) sent to broadcast or multicast
addresses makes the system slightly more difficult to enumerate on the network. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_icmp_echo_ignore_broadcasts | Identifiers: | CCE-83080-2 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | cjis | 5.10.1.1 | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | cui | 3.1.20 | disa | CCI-000366 | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | nist | CM-7(a), CM-7(b), SC-5 | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4 | pcidss | Req-1.4.3 | os-srg | SRG-OS-000480-GPOS-00227 | stigid | SLES-12-030380 | cis | 3.3.5 | pcidss4 | 1.4.2, 1.4 | stigref | SV-217290r603262_rule |
| |
|
Rule
Enable Kernel Parameter to Ignore Bogus ICMP Error Responses on IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.icmp_ignore_bogus_error_responses kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv4.icmp_ignore_bogus_error_responses = 1
| Rationale: | Ignoring bogus ICMP error responses reduces
log size, although some activity would not be logged. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_icmp_ignore_bogus_error_responses | Identifiers: | CCE-91539-7 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9 | cobit5 | APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06 | cui | 3.1.20 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.9.1.2 | nerc-cip | CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | nist | CM-7(a), CM-7(b), SC-5 | nist-csf | DE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3 | pcidss | Req-1.4.3 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 3.3.6 | anssi | R12 | pcidss4 | 1.4.2, 1.4 |
| |
|
Rule
Enable Kernel Parameter to Use TCP Syncookies on Network Interfaces
[ref] | To set the runtime status of the net.ipv4.tcp_syncookies kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.tcp_syncookies=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv4.tcp_syncookies = 1
| Rationale: | A TCP SYN flood attack can cause a denial of service by filling a
system's TCP connection table with connections in the SYN_RCVD state.
Syncookies can be used to track a connection when a subsequent ACK is received,
verifying the initiator is attempting a valid connection and is not a flood
source. This feature is activated when a flood condition is detected, and
enables the system to continue servicing valid connection requests. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_tcp_syncookies | Identifiers: | CCE-83179-2 | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9 | cjis | 5.10.1.1 | cobit5 | APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02 | cui | 3.1.20 | disa | CCI-000366, CCI-001095 | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.4.3.3 | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-7(a), CM-7(b), SC-5(1), SC-5(2), SC-5(3)(a), CM-6(a) | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.PT-4 | pcidss | Req-1.4.1 | os-srg | SRG-OS-000480-GPOS-00227, SRG-OS-000420-GPOS-00186, SRG-OS-000142-GPOS-00071 | stigid | SLES-12-030350 | cis | 3.3.8 | anssi | R12 | pcidss4 | 1.4.3, 1.4 | stigref | SV-217286r603262_rule |
| |
|
Group
Network Parameters for Hosts Only
Group contains 1 rule |
[ref]
If the system is not going to be used as a router, then setting certain
kernel parameters ensure that the host will not perform routing
of network traffic. |
Rule
Disable Kernel Parameter for IP Forwarding on IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.ip_forward kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.ip_forward=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv4.ip_forward = 0
Warning:
Certain technologies such as virtual machines, containers, etc. rely on IPv4 forwarding to enable and use networking.
Disabling IPv4 forwarding would cause those technologies to stop working. Therefore, this rule should not be used in
profiles or benchmarks that target usage of IPv4 forwarding. | Rationale: | Routing protocol daemons are typically used on routers to exchange
network topology information with other routers. If this capability is used when
not required, system network information may be unnecessarily transmitted across
the network. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_ip_forward | Identifiers: | CCE-83088-5 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9 | cobit5 | APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06 | cui | 3.1.20 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.9.1.2 | nerc-cip | CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | nist | CM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a) | nist-csf | DE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3, PR.PT-4 | pcidss | Req-1.3.1, Req-1.3.2 | os-srg | SRG-OS-000480-GPOS-00227 | stigid | SLES-12-030430 | cis | 3.2.1 | anssi | R12 | pcidss4 | 1.4.3, 1.4 | stigref | SV-217296r646767_rule |
| |
|
Group
Uncommon Network Protocols
Group contains 2 rules |
[ref]
The system includes support for several network protocols which are not commonly used.
Although security vulnerabilities in kernel networking code are not frequently discovered,
the consequences can be dramatic. Ensuring uncommon network protocols are disabled
reduces the system's risk to attacks targeted at its implementation of those protocols. Warning:
Although these protocols are not commonly used, avoid disruption
in your network environment by ensuring they are not needed
prior to disabling them. |
Rule
Disable DCCP Support
[ref] | The Datagram Congestion Control Protocol (DCCP) is a
relatively new transport layer protocol, designed to support
streaming media and telephony.
To configure the system to prevent the dccp
kernel module from being loaded, add the following line to the file /etc/modprobe.d/dccp.conf :
install dccp /bin/false
| Rationale: | Disabling DCCP protects
the system against exploitation of any flaws in its implementation. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_dccp_disabled | Identifiers: | CCE-91599-1 | References: | cis-csc | 11, 14, 3, 9 | cjis | 5.10.1 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | cui | 3.4.6 | disa | CCI-001958 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6 | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2 | nist | CM-7(a), CM-7(b), CM-6(a) | nist-csf | PR.IP-1, PR.PT-3 | pcidss | Req-1.4.2 | os-srg | SRG-OS-000096-GPOS-00050, SRG-OS-000378-GPOS-00163 | cis | 3.4.1 | pcidss4 | 1.4.2, 1.4 |
| |
|
Rule
Disable SCTP Support
[ref] | The Stream Control Transmission Protocol (SCTP) is a
transport layer protocol, designed to support the idea of
message-oriented communication, with several streams of messages
within one connection.
To configure the system to prevent the sctp
kernel module from being loaded, add the following line to the file /etc/modprobe.d/sctp.conf :
install sctp /bin/false
| Rationale: | Disabling SCTP protects
the system against exploitation of any flaws in its implementation. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_sctp_disabled | Identifiers: | CCE-91600-7 | References: | cis-csc | 11, 14, 3, 9 | cjis | 5.10.1 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | cui | 3.4.6 | disa | CCI-000381, CCI-000366 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6 | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2 | nist | CM-7(a), CM-7(b), CM-6(a) | nist-csf | PR.IP-1, PR.PT-3 | pcidss | Req-1.4.2 | os-srg | SRG-OS-000095-GPOS-00049, SRG-OS-000480-GPOS-00227 | cis | 3.4.2 | pcidss4 | 1.4.2, 1.4 |
| |
|
Group
Wireless Networking
Group contains 1 group and 1 rule |
[ref]
Wireless networking, such as 802.11
(WiFi) and Bluetooth, can present a security risk to sensitive or
classified systems and networks. Wireless networking hardware is
much more likely to be included in laptop or portable systems than
in desktops or servers.
Removal of hardware provides the greatest assurance that the wireless
capability remains disabled. Acquisition policies often include provisions to
prevent the purchase of equipment that will be used in sensitive spaces and
includes wireless capabilities. If it is impractical to remove the wireless
hardware, and policy permits the device to enter sensitive spaces as long
as wireless is disabled, efforts should instead focus on disabling wireless capability
via software. |
Group
Disable Wireless Through Software Configuration
Group contains 1 rule |
[ref]
If it is impossible to remove the wireless hardware
from the device in question, disable as much of it as possible
through software. The following methods can disable software
support for wireless networking, but note that these methods do not
prevent malicious software or careless users from re-activating the
devices. |
Rule
Deactivate Wireless Network Interfaces
[ref] | Deactivating wireless network interfaces should prevent normal usage of the wireless
capability.
Configure the system to disable wireless network interfaces by issuing the following
command for every active <WIFI-INTERFACE> in the system:
$ sudo wicked ifdown <WIFI-INTERFACE>
Also remove the configuration files for every wifi adapter from
/etc/wicked/ifconfig/<WIFI-INTERFACE>.xml to prevent future
connections. | Rationale: | The use of wireless networking can introduce many different attack vectors into
the organization's network. Common attack vectors such as malicious association
and ad hoc networks will allow an attacker to spoof a wireless access point
(AP), allowing validated systems to connect to the malicious AP and enabling the
attacker to monitor and record network traffic. These malicious APs can also
serve to create a man-in-the-middle attack or be used to create a denial of
service to valid network resources. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_wireless_disable_interfaces | Identifiers: | CCE-83148-7 | References: | cis-csc | 11, 12, 14, 15, 3, 8, 9 | cobit5 | APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.04, DSS05.02, DSS05.03, DSS05.05, DSS06.06 | cui | 3.1.16 | disa | CCI-000085, CCI-002418, CCI-002421, CCI-001443, CCI-001444 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | ism | 1315, 1319 | iso27001-2013 | A.11.2.6, A.12.1.2, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.2.1, A.6.2.2, A.9.1.2 | nist | AC-18(1), SC-8 | nist-csf | PR.AC-3, PR.IP-1, PR.PT-3, PR.PT-4 | pcidss | Req-1.3.3 | os-srg | SRG-OS-000299-GPOS-00117, SRG-OS-000300-GPOS-00118, SRG-OS-000424-GPOS-00188, SRG-OS-000481-GPOS-000481 | stigid | SLES-12-030450 | cis | 3.1.2 | pcidss4 | 1.3.3, 1.3 | stigref | SV-217298r854164_rule |
| |
|
Group
File Permissions and Masks
Group contains 4 groups and 10 rules |
[ref]
Traditional Unix security relies heavily on file and
directory permissions to prevent unauthorized users from reading or
modifying files to which they should not have access.
Several of the commands in this section search filesystems
for files or directories with certain characteristics, and are
intended to be run on every local partition on a given system.
When the variable PART appears in one of the commands below,
it means that the command is intended to be run repeatedly, with the
name of each local partition substituted for PART in turn.
The following command prints a list of all xfs partitions on the local
system, which is the default filesystem for SUSE Linux Enterprise 12
installations:
$ mount -t xfs | awk '{print $3}'
For any systems that use a different
local filesystem type, modify this command as appropriate. |
Group
Verify Permissions on Important Files and
Directories
Group contains 1 group and 9 rules |
[ref]
Permissions for many files on a system must be set
restrictively to ensure sensitive information is properly protected.
This section discusses important
permission restrictions which can be verified
to ensure that no harmful discrepancies have
arisen. |
Group
Verify Permissions on Files with Local Account Information and Credentials
Group contains 9 rules |
[ref]
The default restrictive permissions for files which act as
important security databases such as passwd , shadow ,
group , and gshadow files must be maintained. Many utilities
need read access to the passwd file in order to function properly, but
read access to the shadow file allows malicious attacks against system
passwords, and should never be enabled. |
Rule
Verify Group Who Owns group File
[ref] | To properly set the group owner of /etc/group , run the command: $ sudo chgrp root /etc/group
| Rationale: | The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_group | Identifiers: | CCE-91626-2 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-8.7.c | os-srg | SRG-OS-000480-GPOS-00227 | cis | 6.1.4 | anssi | R50 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Group Who Owns passwd File
[ref] | To properly set the group owner of /etc/passwd , run the command: $ sudo chgrp root /etc/passwd
| Rationale: | The /etc/passwd file contains information about the users that are configured on
the system. Protection of this file is critical for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_passwd | Identifiers: | CCE-91627-0 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-8.7.c | os-srg | SRG-OS-000480-GPOS-00227 | cis | 6.1.2 | anssi | R50 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Group Who Owns shadow File
[ref] | To properly set the group owner of /etc/shadow , run the command: $ sudo chgrp shadow /etc/shadow
| Rationale: | The /etc/shadow file stores password hashes. Protection of this file is
critical for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_shadow | Identifiers: | CCE-91628-8 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-8.7.c | os-srg | SRG-OS-000480-GPOS-00227 | cis | 6.1.3 | anssi | R50 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify User Who Owns group File
[ref] | To properly set the owner of /etc/group , run the command: $ sudo chown root /etc/group
| Rationale: | The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_group | Identifiers: | CCE-91665-0 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | disa | CCI-002223 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-8.7.c | os-srg | SRG-OS-000480-GPOS-00227 | cis | 6.1.4 | anssi | R50 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify User Who Owns passwd File
[ref] | To properly set the owner of /etc/passwd , run the command: $ sudo chown root /etc/passwd
| Rationale: | The /etc/passwd file contains information about the users that are configured on
the system. Protection of this file is critical for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_passwd | Identifiers: | CCE-91666-8 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | disa | CCI-002223 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-8.7.c | os-srg | SRG-OS-000480-GPOS-00227 | cis | 6.1.2 | anssi | R50 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify User Who Owns shadow File
[ref] | To properly set the owner of /etc/shadow , run the command: $ sudo chown root /etc/shadow
| Rationale: | The /etc/shadow file contains the list of local
system accounts and stores password hashes. Protection of this file is
critical for system security. Failure to give ownership of this file
to root provides the designated owner with access to sensitive information
which could weaken the system security posture. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_shadow | Identifiers: | CCE-83259-2 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | disa | CCI-002223 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-8.7.c | os-srg | SRG-OS-000480-GPOS-00227 | cis | 6.1.3 | anssi | R50 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Permissions on group File
[ref] |
To properly set the permissions of /etc/group , run the command:
$ sudo chmod 0644 /etc/group
| Rationale: | The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_group | Identifiers: | CCE-91451-5 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | disa | CCI-002223 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-8.7.c | os-srg | SRG-OS-000480-GPOS-00227 | cis | 6.1.4 | anssi | R50 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Permissions on passwd File
[ref] |
To properly set the permissions of /etc/passwd , run the command:
$ sudo chmod 0644 /etc/passwd
| Rationale: | If the /etc/passwd file is writable by a group-owner or the
world the risk of its compromise is increased. The file contains the list of
accounts on the system and associated information, and protection of this file
is critical for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_passwd | Identifiers: | CCE-91452-3 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | disa | CCI-002223 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-8.7.c | os-srg | SRG-OS-000480-GPOS-00227 | cis | 6.1.2 | anssi | R50 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Permissions on shadow File
[ref] |
To properly set the permissions of /etc/shadow , run the command:
$ sudo chmod 0640 /etc/shadow
| Rationale: | The /etc/shadow file contains the list of local
system accounts and stores password hashes. Protection of this file is
critical for system security. Failure to give ownership of this file
to root provides the designated owner with access to sensitive information
which could weaken the system security posture. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_shadow | Identifiers: | CCE-91479-6 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | disa | CCI-002223 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-8.7.c | os-srg | SRG-OS-000480-GPOS-00227 | cis | 6.1.3 | anssi | R50 | pcidss4 | 2.2.6, 2.2 |
| |
|
Group
Restrict Programs from Dangerous Execution Patterns
Group contains 1 group and 1 rule |
[ref]
The recommendations in this section are designed to
ensure that the system's features to protect against potentially
dangerous program execution are activated.
These protections are applied at the system initialization or
kernel level, and defend against certain types of badly-configured
or compromised programs. |
Group
Enable ExecShield
Group contains 1 rule |
[ref]
ExecShield describes kernel features that provide
protection against exploitation of memory corruption errors such as buffer
overflows. These features include random placement of the stack and other
memory regions, prevention of execution in memory that should only hold data,
and special handling of text buffers. These protections are enabled by default
on 32-bit systems and controlled through sysctl variables
kernel.exec-shield and kernel.randomize_va_space . On the latest
64-bit systems, kernel.exec-shield cannot be enabled or disabled with
sysctl . |
|