Guide to the Secure Configuration of Red Hat Enterprise Linux CoreOS 4

with profile DRAFT - ANSSI-BP-028 (high)
This profile contains configurations that align to ANSSI-BP-028 at the high hardening level. ANSSI is the French National Information Security Agency, and stands for Agence nationale de la sécurité des systèmes d'information. ANSSI-BP-028 is a configuration recommendation for GNU/Linux systems. A copy of the ANSSI-BP-028 can be found at the ANSSI website: https://www.ssi.gouv.fr/administration/guide/recommandations-de-securite-relatives-a-un-systeme-gnulinux/
This guide presents a catalog of security-relevant configuration settings for Red Hat Enterprise Linux CoreOS 4. It is a rendering of content structured in the eXtensible Configuration Checklist Description Format (XCCDF) in order to support security automation. The SCAP content is is available in the scap-security-guide package which is developed at https://www.open-scap.org/security-policies/scap-security-guide.

Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.
Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. The creators of this guidance assume no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.

Profile Information

Profile TitleDRAFT - ANSSI-BP-028 (high)
Profile IDxccdf_org.ssgproject.content_profile_anssi_bp28_high

CPE Platforms

  • cpe:/o:redhat:enterprise_linux_coreos:4

Revision History

Current version: 0.1.74

  • draft (as of 2024-07-17)

Table of Contents

  1. System Settings
    1. Installing and Maintaining Software
    2. Account and Access Control
    3. AppArmor
    4. GRUB2 bootloader configuration
    5. Kernel Configuration
    6. Configure Syslog
    7. Network Configuration and Firewalls
    8. File Permissions and Masks
    9. SELinux
  2. Services
    1. Mail Server Software
    2. Network Time Protocol
    3. SSH Server
  3. System Accounting with auditd
    1. Configure auditd Rules for Comprehensive Auditing

Checklist

Group   Guide to the Secure Configuration of Red Hat Enterprise Linux CoreOS 4   Group contains 61 groups and 285 rules
Group   System Settings   Group contains 45 groups and 219 rules
[ref]   Contains rules that check correct system settings.
Group   Installing and Maintaining Software   Group contains 7 groups and 26 rules
[ref]   The following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates.
Group   System and Software Integrity   Group contains 3 groups and 3 rules
[ref]   System and software integrity can be gained by installing antivirus, increasing system encryption strength with FIPS, verifying installed software, enabling SELinux, installing an Intrusion Prevention System, etc. However, installing or enabling integrity checking tools cannot prevent intrusions, but they can detect that an intrusion may have occurred. Requirements for integrity checking may be highly dependent on the environment in which the system will be used. Snapshot-based approaches such as AIDE may induce considerable overhead in the presence of frequent software updates.
Group   Software Integrity Checking   Group contains 1 group and 2 rules
[ref]   Both the AIDE (Advanced Intrusion Detection Environment) software and the RPM package management system provide mechanisms for verifying the integrity of installed software. AIDE uses snapshots of file metadata (such as hashes) and compares these to current system files in order to detect changes.

The RPM package management system can conduct integrity checks by comparing information in its metadata database with files installed on the system.
Group   Verify Integrity with AIDE   Group contains 2 rules
[ref]   AIDE conducts integrity checks by comparing information about files with previously-gathered information. Ideally, the AIDE database is created immediately after initial system configuration, and then again after any software update. AIDE is highly configurable, with further configuration information located in /usr/share/doc/aide-VERSION .

Rule   Install AIDE   [ref]

The aide package can be installed with the following command:
$ sudo dnf install aide
Rationale:
The AIDE package must be installed if it is to be available for integrity checking.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_aide_installed
References:
cis-csc1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9
cjis5.10.1.3
cobit5APO01.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
disaCCI-002696, CCI-002699, CCI-001744
isa-62443-20094.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4
isa-62443-2013SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6
ism1034, 1288, 1341, 1417
iso27001-2013A.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
nistCM-6(a)
nist-csfDE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3
pcidssReq-11.5
os-srgSRG-OS-000445-GPOS-00199
anssiR76, R79
pcidss411.5.2

Rule   Build and Test AIDE Database   [ref]

Run the following command to generate a new database:
$ sudo /usr/sbin/aide --init
By default, the database will be written to the file /var/lib/aide/aide.db.new.gz. Storing the database, the configuration file /etc/aide.conf, and the binary /usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity. The newly-generated database can be installed as follows:
$ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
To initiate a manual check, run the following command:
$ sudo /usr/sbin/aide --check
If this check produces any unexpected output, investigate.
Rationale:
For AIDE to be effective, an initial database of "known-good" information about files must be captured and it should be able to be verified against the installed files.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_aide_build_database
References:
cis-csc1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9
cjis5.10.1.3
cobit5APO01.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-20094.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4
isa-62443-2013SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6
iso27001-2013A.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
nistCM-6(a)
nist-csfDE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3
pcidssReq-11.5
os-srgSRG-OS-000445-GPOS-00199
anssiR76, R79
pcidss411.5.2
Group   Federal Information Processing Standard (FIPS)   Group contains 1 rule
[ref]   The Federal Information Processing Standard (FIPS) is a computer security standard which is developed by the U.S. Government and industry working groups to validate the quality of cryptographic modules. The FIPS standard provides four security levels to ensure adequate coverage of different industries, implementation of cryptographic modules, and organizational sizes and requirements.

FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets industry and government requirements. For government systems, this allows Security Levels 1, 2, 3, or 4 for use on Red Hat Enterprise Linux CoreOS 4.

See http://csrc.nist.gov/publications/PubsFIPS.html for more information.

Rule   Install the dracut-fips-aesni Package   [ref]

To enable FIPS on system that support the Advanced Encryption Standard (AES) or New Instructions (AES-NI) engine, the system requires that the dracut-fips-aesni package be installed. The dracut-fips-aesni package can be installed with the following command:
$ sudo dnf install dracut-fips-aesni
Warning:  The system needs to be rebooted for these changes to take effect.
Warning:  System Crypto Modules must be provided by a vendor that undergoes FIPS-140 certifications. FIPS-140 is applicable to all Federal agencies that use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems (including voice systems) as defined in Section 5131 of the Information Technology Management Reform Act of 1996, Public Law 104-106. This standard shall be used in designing and implementing cryptographic modules that Federal departments and agencies operate or are operated for them under contract. See https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf To meet this, the system has to have cryptographic software provided by a vendor that has undergone this certification. This means providing documentation, test results, design information, and independent third party review by an accredited lab. While open source software is capable of meeting this, it does not meet FIPS-140 unless the vendor submits to this process.
Rationale:
Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The operating system must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_dracut-fips-aesni_installed
References:
cis-csc12, 15, 8
cjis5.10.1.2
cobit5APO13.01, DSS01.04, DSS05.02, DSS05.03
cui3.13.11, 3.13.8
disaCCI-000068, CCI-000803, CCI-002450
isa-62443-20094.3.3.6.6
isa-62443-2013SR 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-2013A.11.2.6, A.13.1.1, A.13.2.1, A.14.1.3, A.6.2.1, A.6.2.2
nerc-cipCIP-003-8 R4.2, CIP-007-3 R5.1
nistSC-12(2), SC-12(3), IA-7, SC-13, CM-6(a), SC-12
nist-csfPR.AC-3, PR.PT-4
os-srgSRG-OS-000033-GPOS-00014, SRG-OS-000396-GPOS-00176, SRG-OS-000478-GPOS-00223
anssiR1
Group   Disk Partitioning   Group contains 7 rules
[ref]   To ensure separation and protection of data, there are top-level system directories which should be placed on their own physical partition or logical volume. The installer's default partitioning scheme creates separate logical volumes for /, /boot, and swap.
  • If starting with any of the default layouts, check the box to \"Review and modify partitioning.\" This allows for the easy creation of additional logical volumes inside the volume group already created, though it may require making /'s logical volume smaller to create space. In general, using logical volumes is preferable to using partitions because they can be more easily adjusted later.
  • If creating a custom layout, create the partitions mentioned in the previous paragraph (which the installer will require anyway), as well as separate ones described in the following sections.
If a system has already been installed, and the default partitioning scheme was used, it is possible but nontrivial to modify it to create separate logical volumes for the directories listed above. The Logical Volume Manager (LVM) makes this possible. See the LVM HOWTO at http://tldp.org/HOWTO/LVM-HOWTO/ for more detailed information on LVM.

Rule   Ensure /home Located On Separate Partition   [ref]

If user home directories will be stored locally, create a separate partition for /home at installation time (or migrate it later using LVM). If /home will be mounted from another system such as an NFS server, then creating a separate partition is not necessary at installation time, and the mountpoint can instead be configured later.
Rationale:
Ensuring that /home is mounted on its own partition enables the setting of more restrictive mount options, and also helps ensure that users cannot trivially fill partitions used for log or audit data storage.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_partition_for_home
Identifiers:

CCE-82739-4

References:
cis-csc12, 15, 8
cobit5APO13.01, DSS05.02
disaCCI-000366, CCI-001208
isa-62443-2013SR 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-2013A.13.1.1, A.13.2.1, A.14.1.3
nistCM-6(a), SC-5(2)
nist-csfPR.PT-4
os-srgSRG-OS-000480-GPOS-00227
anssiR28

Rule   Ensure /srv Located On Separate Partition   [ref]

If a file server (FTP, TFTP...) is hosted locally, create a separate partition for /srv at installation time (or migrate it later using LVM). If /srv will be mounted from another system such as an NFS server, then creating a separate partition is not necessary at installation time, and the mountpoint can instead be configured later.
Rationale:
Srv deserves files for local network file server such as FTP. Ensuring that /srv is mounted on its own partition enables the setting of more restrictive mount options, and also helps ensure that users cannot trivially fill partitions used for log or audit data storage.
Severity: 
unknown
Rule ID:xccdf_org.ssgproject.content_rule_partition_for_srv
References:
anssiR28

Rule   Ensure /var Located On Separate Partition   [ref]

The /var directory is used by daemons and other system services to store frequently-changing data. Ensure that /var has its own partition or logical volume at installation time, or migrate it using LVM.
Rationale:
Ensuring that /var is mounted on its own partition enables the setting of more restrictive mount options. This helps protect system services such as daemons or other programs which use it. It is not uncommon for the /var directory to contain world-writable directories installed by other software packages.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_partition_for_var
References:
cis-csc12, 15, 8
cobit5APO13.01, DSS05.02
disaCCI-000366
isa-62443-2013SR 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-2013A.13.1.1, A.13.2.1, A.14.1.3
nistCM-6(a), SC-5(2)
nist-csfPR.PT-4
os-srgSRG-OS-000480-GPOS-00227
anssiR28

Rule   Ensure /var/log Located On Separate Partition   [ref]

System logs are stored in the /var/log directory.

Partitioning Red Hat CoreOS is a Day 1 operation and cannot be changed afterwards. For documentation on how to add a MachineConfig manifest that specifies a separate /var/log partition, follow: https://docs.openshift.com/container-platform/latest/installing/installing_platform_agnostic/installing-platform-agnostic.html#installation-user-infra-machines-advanced_disk_installing-platform-agnostic

Note that the Red Hat OpenShift documentation often references a block device, such as /dev/vda. The name of the available block devices depends on the underlying infrastructure (bare metal vs cloud), and often the specific instance type. For example in AWS, some instance types have NVMe drives (/dev/nvme*), others use /dev/xvda*. You will need to look for relevant documentation for your infrastructure around this. In many cases, the simplest thing is to boot a single machine with an Ignition configuration that just gives you SSH access, and inspect the block devices via e.g. the lsblk command. For physical hardware, a good best practice is to reference devices via the /dev/disk/by-id/ or /dev/disk/by-path links.

Rationale:
Placing /var/log in its own partition enables better separation between log files and other files in /var/.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_partition_for_var_log
Identifiers:

CCE-82737-8

References:
cis-csc1, 12, 14, 15, 16, 3, 5, 6, 8
cobit5APO11.04, APO13.01, BAI03.05, DSS05.02, DSS05.04, DSS05.07, MEA02.01
disaCCI-000366
isa-62443-20094.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-2013SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6
iso27001-2013A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3
nerc-cipCIP-007-3 R6.5
nistCM-6(a), AU-4, SC-5(2)
nist-csfPR.PT-1, PR.PT-4
os-srgSRG-OS-000480-GPOS-00227
anssiR28

Rule   Ensure /var/log/audit Located On Separate Partition   [ref]

Audit logs are stored in the /var/log/audit directory.

Partitioning Red Hat CoreOS is a Day 1 operation and cannot be changed afterwards. For documentation on how to add a MachineConfig manifest that specifies a separate /var/log/audit partition, follow: https://docs.openshift.com/container-platform/latest/installing/installing_platform_agnostic/installing-platform-agnostic.html#installation-user-infra-machines-advanced_disk_installing-platform-agnostic

Note that the Red Hat OpenShift documentation often references a block device, such as /dev/vda. The name of the available block devices depends on the underlying infrastructure (bare metal vs cloud), and often the specific instance type. For example in AWS, some instance types have NVMe drives (/dev/nvme*), others use /dev/xvda*. You will need to look for relevant documentation for your infrastructure around this. In many cases, the simplest thing is to boot a single machine with an Ignition configuration that just gives you SSH access, and inspect the block devices via e.g. the lsblk command. For physical hardware, a good best practice is to reference devices via the /dev/disk/by-id/ or /dev/disk/by-path links.

Make absolutely certain that it is large enough to store all audit logs that will be created by the auditing daemon.
Rationale:
Placing /var/log/audit in its own partition enables better separation between audit files and other files, and helps ensure that auditing cannot be halted due to the partition running out of space.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_partition_for_var_log_audit
Identifiers:

CCE-82738-6

References:
cis-csc1, 12, 13, 14, 15, 16, 2, 3, 5, 6, 8
cobit5APO11.04, APO13.01, BAI03.05, BAI04.04, DSS05.02, DSS05.04, DSS05.07, MEA02.01
disaCCI-000366, CCI-001849
hipaa164.312(a)(2)(ii)
isa-62443-20094.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-2013SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.2, SR 7.6
iso27001-2013A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.17.2.1
nerc-cipCIP-007-3 R6.5
nistCM-6(a), AU-4, SC-5(2)
nist-csfPR.DS-4, PR.PT-1, PR.PT-4
osppFMT_SMF_EXT.1
os-srgSRG-OS-000341-GPOS-00132, SRG-OS-000480-GPOS-00227
app-srg-ctrSRG-APP-000357-CTR-000800, CNTR-OS-000200, CNTR-OS-000670
anssiR71

Rule   Ensure /var/tmp Located On Separate Partition   [ref]

The /var/tmp directory is a world-writable directory used for temporary file storage. Ensure it has its own partition or logical volume at installation time, or migrate it using LVM.
Rationale:
The /var/tmp partition is used as temporary storage by many programs. Placing /var/tmp in its own partition enables the setting of more restrictive mount options, which can help protect programs which use it.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_partition_for_var_tmp
Identifiers:

CCE-82734-5

References:
os-srgSRG-OS-000480-GPOS-00227
anssiR28

Rule   Ensure tmp.mount Unit Us Enabled   [ref]

The /tmp directory is a world-writable directory used for temporary file storage. This directory is managed by systemd-tmpfiles. Ensure that the tmp.mount systemd unit is enabled.
Rationale:
The /tmp directory is used as temporary storage by many programs. Placing /tmp in a tmpfs filesystem enables the setting of more restrictive mount options, which can help protect programs which use it. The tmp.mount unit configures the tmpfs filesystem and ensures the /tmp directory is wiped during reboot.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_systemd_tmp_mount_enabled
References:
anssiR28
Group   Sudo   Group contains 14 rules
[ref]   Sudo, which stands for "su 'do'", provides the ability to delegate authority to certain users, groups of users, or system administrators. When configured for system users and/or groups, Sudo can allow a user or group to execute privileged commands that normally only root is allowed to execute.

For more information on Sudo and addition Sudo configuration options, see https://www.sudo.ws.

Rule   Install sudo Package   [ref]

The sudo package can be installed with the following command:
$ sudo dnf install sudo
Rationale:
sudo is a program designed to allow a system administrator to give limited root privileges to users and log root activity. The basic philosophy is to give as few privileges as possible but still allow system users to get their work done.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_sudo_installed
Identifiers:

CCE-82523-2

References:
ism1382, 1384, 1386
nistCM-6(a)
osppFMT_MOF_EXT.1
os-srgSRG-OS-000324-GPOS-00125
anssiR33
pcidss42.2.6

Rule   Verify Group Who Owns /etc/sudoers.d Directory   [ref]

To properly set the group owner of /etc/sudoers.d, run the command:
$ sudo chgrp root /etc/sudoers.d
Rationale:
The ownership of the /etc/sudoers.d directory by the root group is important because this directory hosts sudo configuration. Protection of this directory is critical for system security. Assigning the ownership to root ensures exclusive control of the sudo configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_groupowner_etc_sudoersd
References:
anssiR50

Rule   Verify User Who Owns /etc/sudoers.d Directory   [ref]

To properly set the owner of /etc/sudoers.d, run the command:
$ sudo chown root /etc/sudoers.d 
Rationale:
The ownership of the /etc/sudoers.d directory by the root user is important because this directory hosts sudo configuration. Protection of this directory is critical for system security. Assigning the ownership to root ensures exclusive control of the sudo configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_owner_etc_sudoersd
References:
anssiR50

Rule   Verify Permissions On /etc/sudoers.d Directory   [ref]

To properly set the permissions of /etc/sudoers.d, run the command:
$ sudo chmod 0750 /etc/sudoers.d
Rationale:
Setting correct permissions on the /etc/sudoers.d directory is important because this directory hosts sudo configuration. Protection of this directory is critical for system security. Restricting the permissions ensures exclusive control of the sudo configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_permissions_etc_sudoersd
References:
anssiR50

Rule   Verify Group Who Owns /etc/sudoers File   [ref]

To properly set the group owner of /etc/sudoers, run the command:
$ sudo chgrp root /etc/sudoers
Rationale:
The ownership of the /etc/sudoers file by the root group is important because this file hosts sudo configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the sudo configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_etc_sudoers
References:
anssiR50

Rule   Verify User Who Owns /etc/sudoers File   [ref]

To properly set the owner of /etc/sudoers, run the command:
$ sudo chown root /etc/sudoers 
Rationale:
The ownership of the /etc/sudoers file by the root user is important because this file hosts sudo configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the sudo configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_etc_sudoers
References:
anssiR50

Rule   Verify Permissions On /etc/sudoers File   [ref]

To properly set the permissions of /etc/sudoers, run the command:
$ sudo chmod 0440 /etc/sudoers
Rationale:
Setting correct permissions on the /etc/sudoers file is important because this file hosts sudo configuration. Protection of this file is critical for system security. Restricting the permissions ensures exclusive control of the sudo configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_etc_sudoers
References:
anssiR50

Rule   Ensure That the sudo Binary Has the Correct Permissions   [ref]

To properly set the permissions of /usr/bin/sudo, run the command:
$ sudo chmod 4111 /usr/bin/sudo
Rationale:
The sudoers program should only be usable by people who have the correct permissions.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_sudo
References:
anssiR38

Rule   Ensure Privileged Escalated Commands Cannot Execute Other Commands - sudo NOEXEC   [ref]

The sudo NOEXEC tag, when specified, prevents user executed commands from executing other commands, like a shell for example. This should be enabled by making sure that the NOEXEC tag exists in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/.
Rationale:
Restricting the capability of sudo allowed commands to execute sub-commands prevents users from running programs with privileges they wouldn't have otherwise.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_sudo_add_noexec
References:
anssiR39

Rule   Ensure Only Users Logged In To Real tty Can Execute Sudo - sudo requiretty   [ref]

The sudo requiretty tag, when specified, will only execute sudo commands from users logged in to a real tty. This should be enabled by making sure that the requiretty tag exists in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/.
Rationale:
Restricting the use cases in which a user is allowed to execute sudo commands reduces the attack surface.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sudo_add_requiretty
References:
anssiR39

Rule   Ensure Only Users Logged In To Real tty Can Execute Sudo - sudo use_pty   [ref]

The sudo use_pty tag, when specified, will only execute sudo commands from users logged in to a real tty. This should be enabled by making sure that the use_pty tag exists in /etc/sudoers configuration file or any sudo configuration snippets in /etc/sudoers.d/.
Rationale:
Requiring that sudo commands be run in a pseudo-terminal can prevent an attacker from retaining access to the user's terminal after the main program has finished executing.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sudo_add_use_pty
References:
pcidssReq-10.2.5
anssiR39
pcidss42.2.6

Rule   Explicit arguments in sudo specifications   [ref]

All commands in the sudoers file must strictly specify the arguments allowed to be used for a given user. If the command is supposed to be executed only without arguments, pass "" as an argument in the corresponding user specification.
Warning:  This rule doesn't come with a remediation, as absence of arguments in the user spec doesn't mean that the command is intended to be executed with no arguments.
Warning:  The rule can produce false findings when an argument contains a comma - sudoers syntax allows comma escaping using backslash, but the check doesn't support that. For example, root ALL=(ALL) echo 1\,2 allows root to execute echo 1,2, but the check would interpret it as two commands echo 1\ and 2.
Rationale:
Any argument can modify quite significantly the behavior of a program, whether regarding the realized operation (read, write, delete, etc.) or accessed resources (path in a file system tree). To avoid any possibility of misuse of a command by a user, the ambiguities must be removed at the level of its specification. For example, on some systems, the kernel messages are only accessible by root. If a user nevertheless must have the privileges to read them, the argument of the dmesg command has to be restricted in order to prevent the user from flushing the buffer through the -c option:
user ALL = dmesg ""
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sudoers_explicit_command_args
References:
anssiR43

Rule   Don't define allowed commands in sudoers by means of exclusion   [ref]

Policies applied by sudo through the sudoers file should not involve negation. Each user specification in the sudoers file contains a comma-delimited list of command specifications. The definition can make use glob patterns, as well as of negations. Indirect definition of those commands by means of exclusion of a set of commands is trivial to bypass, so it is not allowed to use such constructs.
Warning:  This rule doesn't come with a remediation, as negations indicate design issues with the sudoers user specifications design. Just removing negations doesn't increase the security - you typically have to rethink the definition of allowed commands to fix the issue.
Rationale:
Specifying access right using negation is inefficient and can be easily circumvented. For example, it is expected that a specification like
# To avoid absolutely , this rule can be easily circumvented!
user ALL = ALL ,!/ bin/sh
prevents the execution of the shell but that’s not the case: just copy the binary /bin/sh to a different name to make it executable again through the rule keyword ALL.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sudoers_no_command_negation
References:
anssiR42

Rule   Don't target root user in the sudoers file   [ref]

The targeted users of a user specification should be, as much as possible, non privileged users (i.e.: non-root). User specifications have to explicitly list the runas spec (i.e. the list of target users that can be impersonated), and ALL or root should not be used.
Warning:  This rule doesn't come with a remediation, as the exact requirement allows exceptions, and removing lines from the sudoers file can make the system non-administrable.
Rationale:
It is common that the command to be executed does not require superuser rights (editing a file whose the owner is not root, sending a signal to an unprivileged process,etc.). In order to limit any attempt of privilege escalation through a command, it is better to apply normal user rights.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sudoers_no_root_target
References:
anssiR40
Group   Updating Software   Group contains 1 rule
[ref]   The dnf command line tool is used to install and update software packages. The system also provides a graphical software update tool in the System menu, in the Administration submenu, called Software Update.

Red Hat Enterprise Linux CoreOS 4 systems contain an installed software catalog called the RPM database, which records metadata of installed packages. Consistently using dnf or the graphical Software Update for all software installation allows for insight into the current inventory of installed software on the system.

Rule   Ensure Red Hat GPG Key Installed   [ref]

To ensure the system can cryptographically verify base software packages come from Red Hat (and to connect to the Red Hat Network to receive them), the Red Hat GPG key must properly be installed. To install the Red Hat GPG key, run:
$ sudo subscription-manager register
If the system is not connected to the Internet or an RHN Satellite, then install the Red Hat GPG key from trusted media such as the Red Hat installation CD-ROM or DVD. Assuming the disc is mounted in /media/cdrom, use the following command as the root user to import it into the keyring:
$ sudo rpm --import /media/cdrom/RPM-GPG-KEY
Alternatively, the key may be pre-loaded during the RHEL installation. In such cases, the key can be installed by running the following command:
sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
Rationale:
Changes to software components can have significant effects on the overall security of the operating system. This requirement ensures the software has not been tampered with and that it has been provided by a trusted vendor. The Red Hat GPG key is necessary to cryptographically verify packages are from Red Hat.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_ensure_redhat_gpgkey_installed
Identifiers:

CCE-82754-3

References:
cis-csc11, 2, 3, 9
cjis5.10.4.1
cobit5APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02
cui3.4.8
disaCCI-001749
hipaa164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i)
isa-62443-20094.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4
isa-62443-2013SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6
iso27001-2013A.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-cipCIP-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
nistCM-5(3), SI-7, SC-12, SC-12(3), CM-6(a)
nist-csfPR.DS-6, PR.DS-8, PR.IP-1
osppFPT_TUD_EXT.1, FPT_TUD_EXT.2
pcidssReq-6.2
os-srgSRG-OS-000366-GPOS-00153
anssiR59
pcidss46.3.3

Rule   Prefer to use a 64-bit Operating System when supported   [ref]

Prefer installation of 64-bit operating systems when the CPU supports it.
Warning:  There is no remediation besides installing a 64-bit operating system.
Rationale:
Use of a 64-bit operating system offers a few advantages, like a larger address space range for Address Space Layout Randomization (ASLR) and systematic presence of No eXecute and Execute Disable (NX/XD) protection bits.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_prefer_64bit_os
References:
anssiR1
Group   Account and Access Control   Group contains 9 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 Red Hat Enterprise Linux CoreOS 4.
Group   Protect Accounts by Configuring PAM   Group contains 2 groups and 2 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.
Warning:  Running authconfig or system-config-authentication will re-write the PAM configuration files, destroying any manually made changes and replacing them with a series of system defaults. One reference to the configuration file syntax can be found at https://fossies.org/linux/Linux-PAM-docs/doc/sag/Linux-PAM_SAG.pdf.
Group   Set Password Quality Requirements   Group contains 1 group and 2 rules
[ref]   The default pam_pwquality PAM module provides strength checking for passwords. It performs a number of checks, such as making sure passwords are not similar to dictionary words, are of at least a certain length, are not the previous password reversed, and are not simply a change of case from the previous password. It can also require passwords to be in certain character classes. The pam_pwquality module is the preferred way of configuring password requirements.

The man pages pam_pwquality(8) provide information on the capabilities and configuration of each.
Group   Set Password Quality Requirements with pam_pwquality   Group contains 2 rules
[ref]   The pam_pwquality PAM module can be configured to meet requirements for a variety of policies.

For example, to configure pam_pwquality to require at least one uppercase character, lowercase character, digit, and other (special) character, make sure that pam_pwquality exists in /etc/pam.d/system-auth:
password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth. Next, modify the settings in /etc/security/pwquality.conf to match the following:
difok = 4
minlen = 14
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
maxrepeat = 3
The arguments can be modified to ensure compliance with your organization's security policy. Discussion of each parameter follows.

Rule   Ensure PAM Enforces Password Requirements - Minimum Different Categories   [ref]

The pam_pwquality module's minclass parameter controls requirements for usage of different character classes, or types, of character that must exist in a password before it is considered valid. For example, setting this value to three (3) requires that any password must have characters from at least three different categories in order to be approved. The default value is zero (0), meaning there are no required classes. There are four categories available:
* Upper-case characters
* Lower-case characters
* Digits
* Special characters (for example, punctuation)
Modify the minclass setting in /etc/security/pwquality.conf entry to require 4 differing categories of characters when changing passwords.
Rationale:
Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determines how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Requiring a minimum number of character categories makes password guessing attacks more difficult by ensuring a larger search space.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_password_pam_minclass
References:
cis-csc1, 12, 15, 16, 5
cobit5DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10
disaCCI-000195
isa-62443-20094.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-2013SR 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
ism0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561
iso27001-2013A.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
nistIA-5(c), IA-5(1)(a), CM-6(a), IA-5(4)
nist-csfPR.AC-1, PR.AC-6, PR.AC-7
os-srgSRG-OS-000072-GPOS-00040
anssiR68

Rule   Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session   [ref]

To configure the number of retry prompts that are permitted per-session: Edit the pam_pwquality.so statement in /etc/pam.d/system-auth to show retry=3 , or a lower value if site policy is more restrictive. The DoD requirement is a maximum of 3 prompts per session.
Rationale:
Setting the password retry prompts that are permitted on a per-session basis to a low value requires some software, such as SSH, to re-connect. This can slow down and draw additional attention to some types of password-guessing attacks. Note that this is different from account lockout, which is provided by the pam_faillock module.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_password_pam_retry
References:
cis-csc1, 11, 12, 15, 16, 3, 5, 9
cjis5.5.3
cobit5BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10
disaCCI-000192, CCI-000366
isa-62443-20094.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3
isa-62443-2013SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 7.6
iso27001-2013A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3
nistCM-6(a), AC-7(a), IA-5(4)
nist-csfPR.AC-1, PR.AC-6, PR.AC-7, PR.IP-1
osppFMT_MOF_EXT.1
os-srgSRG-OS-000069-GPOS-00037, SRG-OS-000480-GPOS-00227
anssiR68
Group   Protect Physical Console Access   Group contains 1 rule
[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.

Rule   Configure Logind to terminate idle sessions after certain time of inactivity   [ref]

To configure logind service to terminate inactive user sessions after 600 seconds, edit the file /etc/systemd/logind.conf. Ensure that there is a section
[Login]
which contains the configuration
StopIdleSessionSec=600
        
.
Rationale:
Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been let unattended.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_logind_session_timeout
References:
cis-csc1, 12, 13, 14, 15, 16, 18, 3, 5, 7, 8
cjis5.5.6
cobit5APO13.01, BAI03.01, BAI03.02, BAI03.03, DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10
cui3.1.11
isa-62443-20094.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, 4.3.4.3.3
isa-62443-2013SR 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-2013A.12.4.1, A.12.4.3, A.14.1.1, A.14.2.1, A.14.2.5, A.18.1.4, A.6.1.2, A.6.1.5, 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-cipCIP-004-6 R2.2.3, CIP-007-3 R5.1, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3
nistCM-6(a), AC-17(a), AC-2(5), AC-12, AC-17(a), SC-10, CM-6(a)
nist-csfDE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.IP-2
osppFMT_SMF_EXT.1.1
pcidssReq-8.1.8
os-srgSRG-OS-000163-GPOS-00072
anssiR32
Group   Protect Accounts by Restricting Password-Based Login   Group contains 2 groups and 3 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 Password Expiration Parameters   Group contains 2 rules
[ref]   The file /etc/login.defs controls several password-related settings. Programs such as passwd, su, and login consult /etc/login.defs to determine behavior with regard to password aging, expiration warnings, and length. See the man page login.defs(5) for more information.

Users should be forced to change their passwords, in order to decrease the utility of compromised passwords. However, the need to change passwords often should be balanced against the risk that users will reuse or write down passwords if forced to change them too often. Forcing password changes every 90-360 days, depending on the environment, is recommended. Set the appropriate value as PASS_MAX_DAYS and apply it to existing accounts with the -M flag.

The PASS_MIN_DAYS (-m) setting prevents password changes for 7 days after the first change, to discourage password cycling. If you use this setting, train users to contact an administrator for an emergency password change in case a new password becomes compromised. The PASS_WARN_AGE (-W) setting gives users 7 days of warnings at login time that their passwords are about to expire.

For example, for each existing human user USER, expiration parameters could be adjusted to a 180 day maximum password age, 7 day minimum password age, and 7 day warning period with the following command:
$ sudo chage -M 180 -m 7 -W 7 USER

Rule   Set Root Account Password Maximum Age   [ref]

Configure the root account to enforce a 365-day maximum password lifetime restriction by running the following command:
$ sudo chage -M 365 root
Rationale:
Any password, no matter how complex, can eventually be cracked. Therefore, passwords need to be changed periodically. If the operating system does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the operating system passwords could be compromised.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_password_set_max_life_root
References:
anssiR31
Group   Restrict Root Logins   Group contains 1 rule
[ref]   Direct root logins should be allowed only for emergency use. In normal situations, the administrator should access the system via a unique unprivileged account, and then use su or sudo to execute privileged commands. Discouraging administrators from accessing the root account directly ensures an audit trail in organizations with multiple administrators. Locking down the channels through which root can connect directly also reduces opportunities for password-guessing against the root account. The login program uses the file /etc/securetty to determine which interfaces should allow root logins. The virtual devices /dev/console and /dev/tty* represent the system consoles (accessible via the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default installation). The default securetty file also contains /dev/vc/*. These are likely to be deprecated in most environments, but may be retained for compatibility. Root should also be prohibited from connecting via network protocols. Other sections of this document include guidance describing how to prevent root from logging in via SSH.

Rule   Direct root Logins Not Allowed   [ref]

To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to login to. If the file does not exist at all, the root user can login through any communication device on the system, whether via the console or via a raw network interface. This is dangerous as user can login to the system as root via Telnet, which sends the password in plain text over the network. By default, Red Hat Enterprise Linux CoreOS 4's /etc/securetty file only allows the root user to login at the console physically attached to the system. To prevent root from logging in, remove the contents of this file. To prevent direct root logins, remove the contents of this file by typing the following command:
$ sudo echo > /etc/securetty
Warning:  This rule only checks the /etc/securetty file existence and its content. If you need to restrict user access using the /etc/securetty file, make sure the pam_securetty.so PAM module is properly enabled in relevant PAM files.
Rationale:
Disabling direct root logins ensures proper accountability and multifactor authentication to privileged accounts. Users will first login, then escalate to privileged (root) access via su / sudo. This is required for FISMA Low and FISMA Moderate systems.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_no_direct_root_logins
Identifiers:

CCE-82698-2

References:
cis-csc1, 12, 15, 16, 5
cobit5DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10
cui3.1.1, 3.1.6
hipaa164.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-20094.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-2013SR 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-2013A.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-cipCIP-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
nistIA-2, CM-6(a)
nist-csfPR.AC-1, PR.AC-6, PR.AC-7
anssiR33
pcidss48.6.1

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,
        mode: 0600
        path: /etc/securetty
        overwrite: true
Group   Secure Session Configuration Files for Login Accounts   Group contains 1 group and 12 rules
[ref]   When a user logs into a Unix account, the system configures the user's session by reading a number of files. Many of these files are located in the user's home directory, and may have weak permissions as a result of user error or misconfiguration. If an attacker can modify or even read certain types of account configuration information, they can often gain full access to the affected user's account. Therefore, it is important to test and correct configuration file permissions for interactive accounts, particularly those of privileged users such as root or system administrators.
Group   Ensure that Users Have Sensible Umask Values   Group contains 3 rules
[ref]   The umask setting controls the default permissions for the creation of new files. With a default umask setting of 077, files and directories created by users will not be readable by any other user on the system. Users who wish to make specific files group- or world-readable can accomplish this by using the chmod command. Additionally, users can make all their files readable to their group by default by setting a umask of 027 in their shell configuration files. If default per-user groups exist (that is, if every user has a default group whose name is the same as that user's username and whose only member is the user), then it may even be safe for users to select a umask of 007, making it very easy to intentionally share files with groups of which the user is a member.

Rule   Ensure the Default Bash Umask is Set Correctly   [ref]

To ensure the default umask for users of the Bash shell is set properly, add or correct the umask setting in /etc/bashrc to read as follows:
umask 077
         
Rationale:
The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_umask_etc_bashrc
Identifiers:

CCE-84260-9

References:
cis-csc18
cobit5APO13.01, BAI03.01, BAI03.02, BAI03.03
disaCCI-000366
isa-62443-20094.3.4.3.3
iso27001-2013A.14.1.1, A.14.2.1, A.14.2.5, A.6.1.5
nerc-cipCIP-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
nistAC-6(1), CM-6(a)
nist-csfPR.IP-2
os-srgSRG-OS-000480-GPOS-00228, SRG-OS-000480-GPOS-00227
anssiR36

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,%23%20/etc/bashrc%0A%0A%23%20System%20wide%20functions%20and%20aliases%0A%23%20Environment%20stuff%20goes%20in%20/etc/profile%0A%0A%23%20It%27s%20NOT%20a%20good%20idea%20to%20change%20this%20file%20unless%20you%20know%20what%20you%0A%23%20are%20doing.%20It%27s%20much%20better%20to%20create%20a%20custom.sh%20shell%20script%20in%0A%23%20/etc/profile.d/%20to%20make%20custom%20changes%20to%20your%20environment%2C%20as%20this%0A%23%20will%20prevent%20the%20need%20for%20merging%20in%20future%20updates.%0A%0A%23%20Prevent%20doublesourcing%0Aif%20%5B%20-z%20%22%24BASHRCSOURCED%22%20%5D%3B%20then%0A%20%20BASHRCSOURCED%3D%22Y%22%0A%0A%20%20%23%20are%20we%20an%20interactive%20shell%3F%0A%20%20if%20%5B%20%22%24PS1%22%20%5D%3B%20then%0A%20%20%20%20if%20%5B%20-z%20%22%24PROMPT_COMMAND%22%20%5D%3B%20then%0A%20%20%20%20%20%20case%20%24TERM%20in%0A%20%20%20%20%20%20xterm%2A%7Cvte%2A%29%0A%20%20%20%20%20%20%20%20if%20%5B%20-e%20/etc/sysconfig/bash-prompt-xterm%20%5D%3B%20then%0A%20%20%20%20%20%20%20%20%20%20%20%20PROMPT_COMMAND%3D/etc/sysconfig/bash-prompt-xterm%0A%20%20%20%20%20%20%20%20elif%20%5B%20%22%24%7BVTE_VERSION%3A-0%7D%22%20-ge%203405%20%5D%3B%20then%0A%20%20%20%20%20%20%20%20%20%20%20%20PROMPT_COMMAND%3D%22__vte_prompt_command%22%0A%20%20%20%20%20%20%20%20else%0A%20%20%20%20%20%20%20%20%20%20%20%20PROMPT_COMMAND%3D%27printf%20%22%5C033%5D0%3B%25s%40%25s%3A%25s%5C007%22%20%22%24%7BUSER%7D%22%20%22%24%7BHOSTNAME%25%25.%2A%7D%22%20%22%24%7BPWD/%23%24HOME/%5C~%7D%22%27%0A%20%20%20%20%20%20%20%20fi%0A%20%20%20%20%20%20%20%20%3B%3B%0A%20%20%20%20%20%20screen%2A%29%0A%20%20%20%20%20%20%20%20if%20%5B%20-e%20/etc/sysconfig/bash-prompt-screen%20%5D%3B%20then%0A%20%20%20%20%20%20%20%20%20%20%20%20PROMPT_COMMAND%3D/etc/sysconfig/bash-prompt-screen%0A%20%20%20%20%20%20%20%20else%0A%20%20%20%20%20%20%20%20%20%20%20%20PROMPT_COMMAND%3D%27printf%20%22%5C033k%25s%40%25s%3A%25s%5C033%5C%5C%22%20%22%24%7BUSER%7D%22%20%22%24%7BHOSTNAME%25%25.%2A%7D%22%20%22%24%7BPWD/%23%24HOME/%5C~%7D%22%27%0A%20%20%20%20%20%20%20%20fi%0A%20%20%20%20%20%20%20%20%3B%3B%0A%20%20%20%20%20%20%2A%29%0A%20%20%20%20%20%20%20%20%5B%20-e%20/etc/sysconfig/bash-prompt-default%20%5D%20%26%26%20PROMPT_COMMAND%3D/etc/sysconfig/bash-prompt-default%0A%20%20%20%20%20%20%20%20%3B%3B%0A%20%20%20%20%20%20esac%0A%20%20%20%20fi%0A%20%20%20%20%23%20Turn%20on%20parallel%20history%0A%20%20%20%20shopt%20-s%20histappend%0A%20%20%20%20history%20-a%0A%20%20%20%20%23%20Turn%20on%20checkwinsize%0A%20%20%20%20shopt%20-s%20checkwinsize%0A%20%20%20%20%5B%20%22%24PS1%22%20%3D%20%22%5C%5Cs-%5C%5Cv%5C%5C%5C%24%20%22%20%5D%20%26%26%20PS1%3D%22%5B%5Cu%40%5Ch%20%5CW%5D%5C%5C%24%20%22%0A%20%20%20%20%23%20You%20might%20want%20to%20have%20e.g.%20tty%20in%20prompt%20%28e.g.%20more%20virtual%20machines%29%0A%20%20%20%20%23%20and%20console%20windows%0A%20%20%20%20%23%20If%20you%20want%20to%20do%20so%2C%20just%20add%20e.g.%0A%20%20%20%20%23%20if%20%5B%20%22%24PS1%22%20%5D%3B%20then%0A%20%20%20%20%23%20%20%20PS1%3D%22%5B%5Cu%40%5Ch%3A%5Cl%20%5CW%5D%5C%5C%24%20%22%0A%20%20%20%20%23%20fi%0A%20%20%20%20%23%20to%20your%20custom%20modification%20shell%20script%20in%20/etc/profile.d/%20directory%0A%20%20fi%0A%0A%20%20if%20%21%20shopt%20-q%20login_shell%20%3B%20then%20%23%20We%27re%20not%20a%20login%20shell%0A%20%20%20%20%23%20Need%20to%20redefine%20pathmunge%2C%20it%20gets%20undefined%20at%20the%20end%20of%20/etc/profile%0A%20%20%20%20pathmunge%20%28%29%20%7B%0A%20%20%20%20%20%20%20%20case%20%22%3A%24%7BPATH%7D%3A%22%20in%0A%20%20%20%20%20%20%20%20%20%20%20%20%2A%3A%22%241%22%3A%2A%29%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%3B%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%2A%29%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20if%20%5B%20%22%242%22%20%3D%20%22after%22%20%5D%20%3B%20then%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20PATH%3D%24PATH%3A%241%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20else%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20PATH%3D%241%3A%24PATH%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20fi%0A%20%20%20%20%20%20%20%20esac%0A%20%20%20%20%7D%0A%0A%20%20%20%20%23%20By%20default%2C%20we%20want%20umask%20to%20get%20set.%20This%20sets%20it%20for%20non-login%20shell.%0A%20%20%20%20%23%20Current%20threshold%20for%20system%20reserved%20uid/gids%20is%20200%0A%20%20%20%20%23%20You%20could%20check%20uidgid%20reservation%20validity%20in%0A%20%20%20%20%23%20/usr/share/doc/setup-%2A/uidgid%20file%0A%20%20%20%20if%20%5B%20%24UID%20-gt%20199%20%5D%20%26%26%20%5B%20%22%60id%20-gn%60%22%20%3D%20%22%60id%20-un%60%22%20%5D%3B%20then%0A%20%20%20%20%20%20%20umask%20027%0A%20%20%20%20else%0A%20%20%20%20%20%20%20umask%20027%0A%20%20%20%20fi%0A%0A%20%20%20%20SHELL%3D/bin/bash%0A%20%20%20%20%23%20Only%20display%20echos%20from%20profile.d%20scripts%20if%20we%20are%20no%20login%20shell%0A%20%20%20%20%23%20and%20interactive%20-%20otherwise%20just%20process%20them%20to%20set%20envvars%0A%20%20%20%20for%20i%20in%20/etc/profile.d/%2A.sh%3B%20do%0A%20%20%20%20%20%20%20%20if%20%5B%20-r%20%22%24i%22%20%5D%3B%20then%0A%20%20%20%20%20%20%20%20%20%20%20%20if%20%5B%20%22%24PS1%22%20%5D%3B%20then%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20.%20%22%24i%22%0A%20%20%20%20%20%20%20%20%20%20%20%20else%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20.%20%22%24i%22%20%3E/dev/null%0A%20%20%20%20%20%20%20%20%20%20%20%20fi%0A%20%20%20%20%20%20%20%20fi%0A%20%20%20%20done%0A%0A%20%20%20%20unset%20i%0A%20%20%20%20unset%20-f%20pathmunge%0A%20%20fi%0A%0Afi%0A%23%20vim%3Ats%3D4%3Asw%3D4%0A%0A%0A
        mode: 0644
        path: /etc/bashrc
        overwrite: true

Rule   Ensure the Default Umask is Set Correctly in /etc/profile   [ref]

To ensure the default umask controlled by /etc/profile is set properly, add or correct the umask setting in /etc/profile to read as follows:
umask 077
         
Note that /etc/profile also reads scrips within /etc/profile.d directory. These scripts are also valid files to set umask value. Therefore, they should also be considered during the check and properly remediated, if necessary.
Rationale:
The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_umask_etc_profile
Identifiers:

CCE-84262-5

References:
cis-csc18
cobit5APO13.01, BAI03.01, BAI03.02, BAI03.03
disaCCI-000366
isa-62443-20094.3.4.3.3
iso27001-2013A.14.1.1, A.14.2.1, A.14.2.5, A.6.1.5
nerc-cipCIP-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
nistAC-6(1), CM-6(a)
nist-csfPR.IP-2
os-srgSRG-OS-000480-GPOS-00228, SRG-OS-000480-GPOS-00227
anssiR36

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,%23%20/etc/profile%0A%0A%23%20System%20wide%20environment%20and%20startup%20programs%2C%20for%20login%20setup%0A%23%20Functions%20and%20aliases%20go%20in%20/etc/bashrc%0A%0A%23%20It%27s%20NOT%20a%20good%20idea%20to%20change%20this%20file%20unless%20you%20know%20what%20you%0A%23%20are%20doing.%20It%27s%20much%20better%20to%20create%20a%20custom.sh%20shell%20script%20in%0A%23%20/etc/profile.d/%20to%20make%20custom%20changes%20to%20your%20environment%2C%20as%20this%0A%23%20will%20prevent%20the%20need%20for%20merging%20in%20future%20updates.%0A%0Apathmunge%20%28%29%20%7B%0A%20%20%20%20case%20%22%3A%24%7BPATH%7D%3A%22%20in%0A%20%20%20%20%20%20%20%20%2A%3A%22%241%22%3A%2A%29%0A%20%20%20%20%20%20%20%20%20%20%20%20%3B%3B%0A%20%20%20%20%20%20%20%20%2A%29%0A%20%20%20%20%20%20%20%20%20%20%20%20if%20%5B%20%22%242%22%20%3D%20%22after%22%20%5D%20%3B%20then%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20PATH%3D%24PATH%3A%241%0A%20%20%20%20%20%20%20%20%20%20%20%20else%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20PATH%3D%241%3A%24PATH%0A%20%20%20%20%20%20%20%20%20%20%20%20fi%0A%20%20%20%20esac%0A%7D%0A%0A%0Aif%20%5B%20-x%20/usr/bin/id%20%5D%3B%20then%0A%20%20%20%20if%20%5B%20-z%20%22%24EUID%22%20%5D%3B%20then%0A%20%20%20%20%20%20%20%20%23%20ksh%20workaround%0A%20%20%20%20%20%20%20%20EUID%3D%60id%20-u%60%0A%20%20%20%20%20%20%20%20UID%3D%60id%20-ru%60%0A%20%20%20%20fi%0A%20%20%20%20USER%3D%22%60id%20-un%60%22%0A%20%20%20%20LOGNAME%3D%24USER%0A%20%20%20%20MAIL%3D%22/var/spool/mail/%24USER%22%0Afi%0A%0A%23%20Path%20manipulation%0Aif%20%5B%20%22%24EUID%22%20%3D%20%220%22%20%5D%3B%20then%0A%20%20%20%20pathmunge%20/usr/sbin%0A%20%20%20%20pathmunge%20/usr/local/sbin%0Aelse%0A%20%20%20%20pathmunge%20/usr/local/sbin%20after%0A%20%20%20%20pathmunge%20/usr/sbin%20after%0Afi%0A%0AHOSTNAME%3D%60/usr/bin/hostname%202%3E/dev/null%60%0AHISTSIZE%3D1000%0Aif%20%5B%20%22%24HISTCONTROL%22%20%3D%20%22ignorespace%22%20%5D%20%3B%20then%0A%20%20%20%20export%20HISTCONTROL%3Dignoreboth%0Aelse%0A%20%20%20%20export%20HISTCONTROL%3Dignoredups%0Afi%0A%0Aexport%20PATH%20USER%20LOGNAME%20MAIL%20HOSTNAME%20HISTSIZE%20HISTCONTROL%0A%0A%23%20By%20default%2C%20we%20want%20umask%20to%20get%20set.%20This%20sets%20it%20for%20login%20shell%0A%23%20Current%20threshold%20for%20system%20reserved%20uid/gids%20is%20200%0A%23%20You%20could%20check%20uidgid%20reservation%20validity%20in%0A%23%20/usr/share/doc/setup-%2A/uidgid%20file%0Aif%20%5B%20%24UID%20-gt%20199%20%5D%20%26%26%20%5B%20%22%60id%20-gn%60%22%20%3D%20%22%60id%20-un%60%22%20%5D%3B%20then%0A%20%20%20%20umask%20027%0Aelse%0A%20%20%20%20umask%20027%0Afi%0A%0Afor%20i%20in%20/etc/profile.d/%2A.sh%20/etc/profile.d/sh.local%20%3B%20do%0A%20%20%20%20if%20%5B%20-r%20%22%24i%22%20%5D%3B%20then%0A%20%20%20%20%20%20%20%20if%20%5B%20%22%24%7B-%23%2Ai%7D%22%20%21%3D%20%22%24-%22%20%5D%3B%20then%20%0A%20%20%20%20%20%20%20%20%20%20%20%20.%20%22%24i%22%0A%20%20%20%20%20%20%20%20else%0A%20%20%20%20%20%20%20%20%20%20%20%20.%20%22%24i%22%20%3E/dev/null%0A%20%20%20%20%20%20%20%20fi%0A%20%20%20%20fi%0Adone%0A%0Aunset%20i%0Aunset%20-f%20pathmunge%0A%0Aif%20%5B%20-n%20%22%24%7BBASH_VERSION-%7D%22%20%5D%20%3B%20then%0A%20%20%20%20%20%20%20%20if%20%5B%20-f%20/etc/bashrc%20%5D%20%3B%20then%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20Bash%20login%20shells%20run%20only%20/etc/profile%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20Bash%20non-login%20shells%20run%20only%20/etc/bashrc%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%23%20Check%20for%20double%20sourcing%20is%20done%20in%20/etc/bashrc.%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20.%20/etc/bashrc%0A%20%20%20%20%20%20%20fi%0Afi%0A%0A%0A
        mode: 0644
        path: /etc/profile
        overwrite: true

Rule   Configure Polyinstantiation of /tmp Directories   [ref]

To configure polyinstantiated /tmp directories, first create the parent directories which will hold the polyinstantiation child directories. Use the following command:
$ sudo mkdir --mode 000 /tmp/tmp-inst
Then, add the following entry to /etc/security/namespace.conf:
/tmp     /tmp/tmp-inst/            level      root,adm
Rationale:
Polyinstantiation of temporary directories is a proactive security measure which reduces chances of attacks that are made possible by /tmp directories being world-writable.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_accounts_polyinstantiated_tmp
References:
anssiR55

Rule   Configure Polyinstantiation of /var/tmp Directories   [ref]

To configure polyinstantiated /tmp directories, first create the parent directories which will hold the polyinstantiation child directories. Use the following command:
$ sudo mkdir --mode 000 /var/tmp/tmp-inst
Then, add the following entry to /etc/security/namespace.conf:
/var/tmp /var/tmp/tmp-inst/    level      root,adm
Rationale:
Polyinstantiation of temporary directories is a proactive security measure which reduces chances of attacks that are made possible by /var/tmp directories being world-writable.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_accounts_polyinstantiated_var_tmp
References:
anssiR55

Rule   Set Interactive Session Timeout   [ref]

Setting the TMOUT option in /etc/profile ensures that all user sessions will terminate based on inactivity. The value of TMOUT should be exported and read only. The TMOUT setting in a file loaded by /etc/profile, e.g. /etc/profile.d/tmout.sh should read as follows:
typeset -xr TMOUT=600
        
or
declare -xr TMOUT=600
        
Using the typeset keyword is preferred for wider compatibility with ksh and other shells.
Rationale:
Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_tmout
References:
cis-csc1, 12, 15, 16
cobit5DSS05.04, DSS05.10, DSS06.10
cui3.1.11
disaCCI-000057, CCI-001133, CCI-002361
isa-62443-20094.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-2013SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9
iso27001-2013A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3
nerc-cipCIP-004-6 R2.2.3, CIP-007-3 R5.1, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3
nistAC-12, SC-10, AC-2(5), CM-6(a)
nist-csfPR.AC-7
osppFMT_MOF_EXT.1
os-srgSRG-OS-000163-GPOS-00072, SRG-OS-000029-GPOS-00010
anssiR32
pcidss48.6.1

Rule   User Initialization Files Must Be Group-Owned By The Primary Group   [ref]

Change the group owner of interactive users files to the group found in
/etc/passwd
for the user. To change the group owner of a local interactive user home directory, use the following command:
$ sudo chgrp USER_GROUP /home/USER/.INIT_FILE
        
This rule ensures every initialization file related to an interactive user is group-owned by an interactive user.
Warning:  Due to OVAL limitation, this rule can report a false negative in a specific situation where two interactive users swap the group-ownership of their respective initialization files.
Rationale:
Local initialization files for interactive users are used to configure the user's shell environment upon logon. Malicious modification of these files could compromise accounts upon logon.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_user_dot_group_ownership
References:
disaCCI-000366
os-srgSRG-OS-000480-GPOS-00227
anssiR50

Rule   User Initialization Files Must Be Owned By the Primary User   [ref]

Set the owner of the user initialization files for interactive users to the primary owner with the following command:
$ sudo chown USER /home/USER/.*
This rule ensures every initialization file related to an interactive user is owned by an interactive user.
Warning:  Due to OVAL limitation, this rule can report a false negative in a specific situation where two interactive users swap the ownership of their respective initialization files.
Rationale:
Local initialization files are used to configure the user's shell environment upon logon. Malicious modification of these files could compromise accounts upon logon.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_user_dot_user_ownership
References:
disaCCI-000366
os-srgSRG-OS-000480-GPOS-00227
anssiR50

Rule   All User Files and Directories In The Home Directory Must Be Group-Owned By The Primary Group   [ref]

Change the group of a local interactive users files and directories to a group that the interactive user is a member of. To change the group owner of a local interactive users files and directories, use the following command:
$ sudo chgrp USER_GROUP /home/USER/FILE_DIR
        
This rule ensures every file or directory under the home directory related to an interactive user is group-owned by an interactive user.
Warning:  Due to OVAL limitation, this rule can report a false negative in a specific situation where two interactive users swap the group-ownership of folders or files in their respective home directories.
Rationale:
If a local interactive users files are group-owned by a group of which the user is not a member, unintended users may be able to access them.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_users_home_files_groupownership
References:
disaCCI-000366
os-srgSRG-OS-000480-GPOS-00227
anssiR50

Rule   All User Files and Directories In The Home Directory Must Have a Valid Owner   [ref]

Either remove all files and directories from the system that do not have a valid user, or assign a valid user to all unowned files and directories. To assign a valid owner to a local interactive user's files and directories, use the following command:
$ sudo chown -R USER /home/USER
        
This rule ensures every file or directory under the home directory related to an interactive user is owned by an interactive user.
Warning:  Due to OVAL limitation, this rule can report a false negative in a specific situation where two interactive users swap the ownership of folders or files in their respective home directories.
Rationale:
If local interactive users do not own the files in their directories, unauthorized users may be able to access them. Additionally, if files are not owned by the user, this could be an indication of system compromise.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_users_home_files_ownership
References:
disaCCI-000366
os-srgSRG-OS-000480-GPOS-00227
anssiR50

Rule   All User Files and Directories In The Home Directory Must Have Mode 0750 Or Less Permissive   [ref]

Set the mode on files and directories in the local interactive user home directory with the following command:
$ sudo chmod 0750 /home/USER/FILE_DIR
        
Files that begin with a "." are excluded from this requirement.
Rationale:
If a local interactive user files have excessive permissions, unintended users may be able to access or modify them.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_users_home_files_permissions
References:
disaCCI-000366
os-srgSRG-OS-000480-GPOS-00227
anssiR50

Rule   Ensure All User Initialization Files Have Mode 0740 Or Less Permissive   [ref]

Set the mode of the user initialization files to 0740 with the following command:
$ sudo chmod 0740 /home/USER/.INIT_FILE
        
Rationale:
Local initialization files are used to configure the user's shell environment upon logon. Malicious modification of these files could compromise accounts upon logon.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permission_user_init_files
References:
disaCCI-000366
os-srgSRG-OS-000480-GPOS-00227
anssiR50
Group   AppArmor   Group contains 5 rules
[ref]   Many security vulnerabilities result from bugs in trusted programs. A trusted program runs with privileges that attackers want to possess. The program fails to keep that trust if there is a bug in the program that allows the attacker to acquire said privilege.

AppArmor® is an application security solution designed specifically to apply privilege confinement to suspect programs. AppArmor allows the administrator to specify the domain of activities the program can perform by developing a security profile. A security profile is a listing of files that the program may access and the operations the program may perform. AppArmor secures applications by enforcing good application behavior without relying on attack signatures, so it can prevent attacks even if previously unknown vulnerabilities are being exploited.

Rule   Ensure AppArmor is installed   [ref]

AppArmor provide Mandatory Access Controls.
Rationale:
Without a Mandatory Access Control system installed only the default Discretionary Access Control system will be available.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_apparmor_installed
References:
disaCCI-001764, CCI-001774, CCI-002165, CCI-002235
os-srgSRG-OS-000368-GPOS-00154, SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000312-GPOS-00124, SRG-OS-000324-GPOS-00125, SRG-OS-000370-GPOS-00155
anssiR45

Rule   Install the pam_apparmor Package   [ref]

The pam_apparmor package can be installed with the following command:
$ sudo dnf install pam_apparmor
Rationale:
Protection of system integrity using AppArmor depends on this package being installed.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_pam_apparmor_installed
References:
disaCCI-001764, CCI-001774, CCI-002165, CCI-002233, CCI-002235
nistAC-3(4), AC-6(8), AC-6(10), CM-7(5)(b), CM-7(2), SC-7(21), CM-6(a)
os-srgSRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000312-GPOS-00124, SRG-OS-000324-GPOS-00125, SRG-OS-000326-GPOS-00126, SRG-OS-000370-GPOS-00155, SRG-OS-000480-GPOS-00230, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00231, SRG-OS-000480-GPOS-00232
anssiR45

Rule   Enforce all AppArmor Profiles   [ref]

AppArmor profiles define what resources applications are able to access. To set all profiles to enforce mode run the following command:
$ sudo aa-enforce /etc/apparmor.d/*
To list unconfined processes run the following command:
$ sudo aa-unconfined
Any unconfined processes may need to have a profile created or activated for them and then be restarted.
Rationale:
Security configuration requirements vary from site to site. Some sites may mandate a policy that is stricter than the default policy, which is perfectly acceptable. This recommendation is intended to ensure that any policies that exist on the system are activated.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_all_apparmor_profiles_enforced
References:
anssiR45

Rule   Ensure AppArmor is Active and Configured   [ref]

Verify that the Apparmor tool is configured to control whitelisted applications and user home directory access control.

The apparmor service can be enabled with the following manifest:
---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 75-master-apparmor-enable
spec:
  config:
    ignition:
      version: 3.1.0
    systemd:
      units:
      - name: apparmor.service
        enabled: true

This will enable the apparmor service in all the nodes labeled with the "master" role.

Note that this needs to be done for each MachineConfigPool

For more information on how to configure nodes with the Machine Config Operator see the relevant documentation.

Rationale:
Using a whitelist provides a configuration management method for allowing the execution of only authorized software. Using only authorized software decreases risk by limiting the number of potential vulnerabilities.

The organization must identify authorized software programs and permit execution of authorized software by adding each authorized program to the "pam_apparmor" exception policy. The process used to identify software programs that are authorized to execute on organizational information systems is commonly referred to as whitelisting.

Verification of whitelisted software occurs prior to execution or at system startup.

Users' home directories/folders may contain information of a sensitive nature. Nonprivileged users should coordinate any sharing of information with a System Administrator (SA) through shared resources.

Apparmor can confine users to their home directory, not allowing them to make any changes outside of their own home directories. Confining users to their home directory will minimize the risk of sharing information.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_apparmor_configured
References:
disaCCI-001764, CCI-001774, CCI-002165, CCI-002233, CCI-002235
nistAC-3(4), AC-6(8), AC-6(10), CM-7(5)(b), CM-7(2), SC-7(21), CM-6(a)
os-srgSRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000312-GPOS-00124, SRG-OS-000324-GPOS-00125, SRG-OS-000326-GPOS-00126, SRG-OS-000370-GPOS-00155, SRG-OS-000480-GPOS-00230, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00231, SRG-OS-000480-GPOS-00232
anssiR45

Rule   Ensure AppArmor is enabled in the bootloader configuration   [ref]

Configure AppArmor to be enabled at boot time and verify that it has not been overwritten by the bootloader boot parameters. Note: This recommendation is designed around the grub bootloader, if LILO or another bootloader is in use in your environment, enact equivalent settings.
Rationale:
AppArmor must be enabled at boot time in your bootloader configuration to ensure that the controls it provides are not overridden.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_grub2_enable_apparmor
References:
anssiR45
Group   GRUB2 bootloader configuration   Group contains 2 groups and 22 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 Red Hat Enterprise Linux CoreOS 4 boot loader for x86 systems is called GRUB2. Options it can pass to the kernel include single-user mode, which provides root access without any authentication, and the ability to disable SELinux. To prevent local users from modifying the boot parameters and endangering security, protect the boot loader configuration with a password and ensure its configuration file's permissions are set properly.
Group   Non-UEFI GRUB2 bootloader configuration   Group contains 6 rules
[ref]   Non-UEFI GRUB2 bootloader configuration

Rule   Verify /boot/grub2/grub.cfg Group Ownership   [ref]

The file /boot/grub2/grub.cfg should be group-owned by the root group to prevent destruction or modification of the file. To properly set the group owner of /boot/grub2/grub.cfg, run the command:
$ sudo chgrp root /boot/grub2/grub.cfg
Rationale:
The root group is a highly-privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_grub2_cfg
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
cui3.4.5
disaCCI-000225
hipaa164.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-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-7.1
os-srgSRG-OS-000480-GPOS-00227
anssiR29
pcidss42.2.6

Rule   Verify /boot/grub2/user.cfg Group Ownership   [ref]

The file /boot/grub2/user.cfg should be group-owned by the root group to prevent reading or modification of the file. To properly set the group owner of /boot/grub2/user.cfg, run the command:
$ sudo chgrp root /boot/grub2/user.cfg
Rationale:
The root group is a highly-privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway. Non-root users who read the boot parameters may be able to identify weaknesses in security upon boot and be able to exploit them.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_user_cfg
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
cui3.4.5
disaCCI-000225
hipaa164.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-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-7.1
os-srgSRG-OS-000480-GPOS-00227
anssiR29
pcidss42.2.6

Rule   Verify /boot/grub2/grub.cfg User Ownership   [ref]

The file /boot/grub2/grub.cfg should be owned by the root user to prevent destruction or modification of the file. To properly set the owner of /boot/grub2/grub.cfg, run the command:
$ sudo chown root /boot/grub2/grub.cfg 
Rationale:
Only root should be able to modify important boot parameters.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_grub2_cfg
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
cui3.4.5
disaCCI-000225
hipaa164.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-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-7.1
os-srgSRG-OS-000480-GPOS-00227
anssiR29
pcidss42.2.6

Rule   Verify /boot/grub2/user.cfg User Ownership   [ref]

The file /boot/grub2/user.cfg should be owned by the root user to prevent reading or modification of the file. To properly set the owner of /boot/grub2/user.cfg, run the command:
$ sudo chown root /boot/grub2/user.cfg 
Rationale:
Only root should be able to modify important boot parameters. Also, non-root users who read the boot parameters may be able to identify weaknesses in security upon boot and be able to exploit them.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_user_cfg
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
cui3.4.5
disaCCI-000225
hipaa164.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-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-7.1
anssiR29
pcidss42.2.6

Rule   Verify /boot/grub2/grub.cfg Permissions   [ref]

File permissions for /boot/grub2/grub.cfg should be set to 600. To properly set the permissions of /boot/grub2/grub.cfg, run the command:
$ sudo chmod 600 /boot/grub2/grub.cfg
Rationale:
Proper permissions ensure that only the root user can modify important boot parameters.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_grub2_cfg
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
cui3.4.5
disaCCI-000225
hipaa164.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-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
anssiR29
pcidss42.2.6

Rule   Verify /boot/grub2/user.cfg Permissions   [ref]

File permissions for /boot/grub2/user.cfg should be set to 600. To properly set the permissions of /boot/grub2/user.cfg, run the command:
$ sudo chmod 600 /boot/grub2/user.cfg
Rationale:
Proper permissions ensure that only the root user can read or modify important boot parameters.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_user_cfg
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
cui3.4.5
disaCCI-000225
hipaa164.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-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
anssiR29
pcidss42.2.6
Group   UEFI GRUB2 bootloader configuration   Group contains 7 rules
[ref]   UEFI GRUB2 bootloader configuration
Warning:  UEFI generally uses vfat file systems, which does not support Unix-style permissions managed by chmod command. In this case, in order to change file permissions for files within /boot/efi it is necessary to update the mount options in /etc/fstab file and reboot the system.

Rule   Verify the UEFI Boot Loader 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_efi_grub2_cfg
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
cui3.4.5
disaCCI-000225
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-7.1
anssiR29

Rule   Verify /boot/grub2/user.cfg Group Ownership   [ref]

The file /boot/grub2/user.cfg should be group-owned by the root group to prevent reading or modification of the file. To properly set the group owner of /boot/grub2/user.cfg, run the command:
$ sudo chgrp root /boot/grub2/user.cfg
Rationale:
The root group is a highly-privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway. Non-root users who read the boot parameters may be able to identify weaknesses in security upon boot and be able to exploit them.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_efi_user_cfg
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
cui3.4.5
disaCCI-000225
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-7.1
anssiR29

Rule   Verify the UEFI Boot Loader 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_efi_grub2_cfg
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
cui3.4.5
disaCCI-000225
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-7.1
anssiR29

Rule   Verify /boot/grub2/user.cfg User Ownership   [ref]

The file /boot/grub2/user.cfg should be owned by the root user to prevent reading or modification of the file. To properly set the owner of /boot/grub2/user.cfg, run the command:
$ sudo chown root /boot/grub2/user.cfg 
Rationale:
Only root should be able to modify important boot parameters. Also, non-root users who read the boot parameters may be able to identify weaknesses in security upon boot and be able to exploit them.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_efi_user_cfg
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
cui3.4.5
disaCCI-000225
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-7.1
anssiR29

Rule   Verify the UEFI Boot Loader grub.cfg Permissions   [ref]

File permissions for /boot/grub2/grub.cfg should be set to 700. To properly set the permissions of /boot/grub2/grub.cfg, run the command:
$ sudo chmod 700 /boot/grub2/grub.cfg
Rationale:
Proper permissions ensure that only the root user can modify important boot parameters.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_efi_grub2_cfg
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
cui3.4.5
disaCCI-000225
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
anssiR29

Rule   Verify /boot/grub2/user.cfg Permissions   [ref]

File permissions for /boot/grub2/user.cfg should be set to 600. To properly set the permissions of /boot/grub2/user.cfg, run the command:
$ sudo chmod 600 /boot/grub2/user.cfg
Rationale:
Proper permissions ensure that only the root user can read or modify important boot parameters.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_efi_user_cfg
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
cui3.4.5
disaCCI-000225
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
anssiR29

Rule   Set the UEFI Boot Loader Password   [ref]

The grub2 boot loader should have a superuser account and password protection enabled to protect boot-time settings.

Since plaintext passwords are a security risk, generate a hash for the password by running the following command:
# grub2-setpassword
When prompted, enter the password that was selected.

Warning:  To prevent hard-coded passwords, automatic remediation of this control is not available. Remediation must be automated as a component of machine provisioning, or followed manually as outlined above. Also, do NOT manually add the superuser account and password to the grub.cfg file as the grub2-mkconfig command overwrites this file.
Rationale:
Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_grub2_uefi_password
Identifiers:

CCE-82552-1

References:
cis-csc11, 12, 14, 15, 16, 18, 3, 5
cobit5DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.03, DSS06.06
cui3.4.5
disaCCI-000213
hipaa164.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-20094.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4
isa-62443-2013SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7
iso27001-2013A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5
nistCM-6(a)
nist-csfPR.AC-4, PR.AC-6, PR.PT-3
osppFIA_UAU.1
os-srgSRG-OS-000080-GPOS-00048
anssiR5

Rule   IOMMU configuration directive   [ref]

On x86 architecture supporting VT-d, the IOMMU manages the access control policy between the hardware devices and some of the system critical units such as the memory. Configure the default Grub2 kernel command line to contain iommu=force as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) iommu=force"
Warning:  Depending on the hardware, devices and operating system used, enabling IOMMU can cause hardware instabilities. Proper function and stability should be assessed before applying remediation to production systems.
Rationale:
On x86 architectures, activating the I/OMMU prevents the system from arbitrary accesses potentially made by hardware devices.
Severity: 
unknown
Rule ID:xccdf_org.ssgproject.content_rule_grub2_enable_iommu_force
References:
anssiR7

Rule   Configure L1 Terminal Fault mitigations   [ref]

L1 Terminal Fault (L1TF) is a hardware vulnerability which allows unprivileged speculative access to data which is available in the Level 1 Data Cache when the page table entry isn't present. Select the appropriate mitigation by adding the argument l1tf=full,force to the default GRUB 2 command line for the Linux operating system. Configure the default Grub2 kernel command line to contain l1tf=full,force as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) l1tf=full,force"
Since Linux Kernel 4.19 you can check the L1TF vulnerability state with the following command: cat /sys/devices/system/cpu/vulnerabilities/l1tf
Warning:  Enabling L1TF mitigations may impact performance of the system.
Rationale:
The L1TF vulnerability allows an attacker to bypass memory access security controls imposed by the system or hypervisor. The L1TF vulnerability allows read access to any physical memory location that is cached in the L1 Data Cache.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_grub2_l1tf_argument
References:
anssiR8

Rule   Force kernel panic on uncorrected MCEs   [ref]

A Machine Check Exception is an error generated by the CPU itdetects an error in itself, memory or I/O devices. These errors may be corrected and generate a check log entry, if an error cannot be corrected the kernel may panic or SIGBUS. To force the kernel to panic on any uncorrected error reported by Machine Check set the MCE tolerance to zero by adding mce=0 to the default GRUB 2 command line for the Linux operating system. Configure the default Grub2 kernel command line to contain mce=0 as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) mce=0"
Rationale:
Allowing uncorrected errors to result on a SIGBUS may allow an attacker to continue trying to exploit a vulnerability such as Rowhammer.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_grub2_mce_argument
References:
anssiR8

Rule   Ensure SMAP is not disabled during boot   [ref]

The SMAP is used to prevent the supervisor mode from unintentionally reading/writing into memory pages in the user space, it is enabled by default since Linux kernel 3.7. But it could be disabled through kernel boot parameters. Ensure that Supervisor Mode Access Prevention (SMAP) is not disabled by the nosmap boot paramenter option. Check that the line
GRUB_CMDLINE_LINUX="..."
within /etc/default/grub doesn't contain the argument nosmap. Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --remove-args="nosmap"
Rationale:
Disabling SMAP can facilitate exploitation of vulnerabilities caused by unintended access and manipulation of data in the user space.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_grub2_nosmap_argument_absent
References:
anssiR1

Rule   Ensure SMEP is not disabled during boot   [ref]

The SMEP is used to prevent the supervisor mode from executing user space code, it is enabled by default since Linux kernel 3.0. But it could be disabled through kernel boot parameters. Ensure that Supervisor Mode Execution Prevention (SMEP) is not disabled by the nosmep boot paramenter option. Check that the line
GRUB_CMDLINE_LINUX="..."
within /etc/default/grub doesn't contain the argument nosmep. Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --remove-args="nosmep"
Rationale:
Disabling SMEP can facilitate exploitation of certain vulnerabilities because it allows the kernel to unintentionally execute code in less privileged memory space.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_grub2_nosmep_argument_absent
References:
anssiR1

Rule   Configure the confidence in TPM for entropy   [ref]

The TPM security chip that is available in most modern systems has a hardware RNG. It is also used to feed the entropy pool, but generally not credited entropy. Use rng_core.default_quality in the kernel command line to set the trust level on the hardware generators. The trust level defines the amount of entropy to credit. A value of 0 tells the system not to trust the hardware random number generators available, and doesn't credit any entropy to the pool. A value of 1000 assigns full confidence in the generators, and credits all the entropy it provides to the pool. Note that the value of rng_core.default_quality is global, affecting the trust on all hardware random number generators. Select the appropriate confidence by adding the argument rng_core.default_quality=500 to the default GRUB 2 command line for the Linux operating system. Configure the default Grub2 kernel command line to contain rng_core.default_quality=500 as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) rng_core.default_quality=500"
Rationale:
A system may struggle to initialize its entropy pool and end up starving. Crediting entropy from the hardware number generators available in the system helps fill up the entropy pool.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_grub2_rng_core_default_quality_argument
References:
anssiR8

Rule   Disable merging of slabs with similar size   [ref]

The kernel may merge similar slabs together to reduce overhead and increase cache hotness of objects. Disabling merging of slabs keeps the slabs separate and reduces the risk of kernel heap overflows overwriting objects in merged caches. To disable merging of slabs in the Kernel add the argument slab_nomerge=yes to the default GRUB 2 command line for the Linux operating system. Configure the default Grub2 kernel command line to contain slab_nomerge=yes as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) slab_nomerge=yes"
Warning:  Disabling merge of slabs will slightly increase kernel memory utilization.
Rationale:
Disabling the merge of slabs of similar sizes prevents the kernel from merging a seemingly useless but vulnerable slab with a useful and valuable slab. This increase the risk that a heap overflow could overwrite objects from merged caches, with unmerged caches the heap overflow would only affect the objects in the same cache. Overall, this reduces the kernel attack surface area by isolating slabs from each other.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_grub2_slab_nomerge_argument
References:
anssiR8

Rule   Configure Speculative Store Bypass Mitigation   [ref]

Certain CPUs are vulnerable to an exploit against a common wide industry wide performance optimization known as Speculative Store Bypass (SSB). In such cases, recent stores to the same memory location cannot always be observed by later loads during speculative execution. However, such stores are unlikely and thus they can be detected prior to instruction retirement at the end of a particular speculation execution window. Since Linux Kernel 4.17 you can check the SSB mitigation state with the following command: cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass Select the appropriate SSB state by adding the argument spec_store_bypass_disable=seccomp to the default GRUB 2 command line for the Linux operating system. Configure the default Grub2 kernel command line to contain spec_store_bypass_disable=seccomp as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) spec_store_bypass_disable=seccomp"
Warning:  Disabling Speculative Store Bypass may impact performance of the system.
Rationale:
In vulnerable processsors, the speculatively forwarded store can be used in a cache side channel attack. An example of this is reading memory to which the attacker does not directly have access, for example inside the sandboxed code.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_grub2_spec_store_bypass_disable_argument
References:
anssiR8

Rule   Enforce Spectre v2 mitigation   [ref]

Spectre V2 is an indirect branch poisoning attack that can lead to data leakage. An exploit for Spectre V2 tricks the indirect branch predictor into executing code from a future indirect branch chosen by the attacker, even if the privilege level is different. Since Linux Kernel 4.15 you can check the Spectre V2 mitigation state with the following command: cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 Enforce the Spectre V2 mitigation by adding the argument spectre_v2=on to the default GRUB 2 command line for the Linux operating system. Configure the default Grub2 kernel command line to contain spectre_v2=on as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) spectre_v2=on"
Rationale:
The Spectre V2 vulnerability allows an attacker to read memory that he should not have access to.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_grub2_spectre_v2_argument
References:
anssiR8
Group   Kernel Configuration   Group contains 41 rules
[ref]   Contains rules that check the kernel configuration that was used to build it.

Rule   Do not allow ACPI methods to be inserted/replaced at run time   [ref]

This debug facility allows ACPI AML methods to be inserted and/or replaced without rebooting the system. This configuration is available from kernel 3.0. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_ACPI_CUSTOM_METHOD, run the following command: grep CONFIG_ACPI_CUSTOM_METHOD /boot/config-* Configs with value 'n' are not explicitly set in the file, so either commented lines or no lines should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
Enabling this feature allows arbitrary kernel memory to be written to by root (uid=0) users, allowing them to bypass certain security measures
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_acpi_custom_method
References:
anssiR15

Rule   Disable kernel support for MISC binaries   [ref]

Enabling CONFIG_BINFMT_MISC makes it possible to plug wrapper-driven binary formats into the kernel. This is specially useful for programs that need an interpreter to run like Java, Python and DOS emulators. Once you have registered such a binary class with the kernel, you can start one of those programs simply by typing in its name at a shell prompt. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_BINFMT_MISC, run the following command: grep CONFIG_BINFMT_MISC /boot/config-* Configs with value 'n' are not explicitly set in the file, so either commented lines or no lines should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This disables arbitrary binary format support and helps reduce attack surface.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_binfmt_misc
References:
anssiR23

Rule   Enable support for BUG()   [ref]

Disabling this option eliminates support for BUG and WARN, reducing the size of your kernel image and potentially quietly ignoring numerous fatal conditions. You should only consider disabling this option for embedded systems with no facilities for reporting errors. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_BUG, run the following command: grep CONFIG_BUG /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
Not setting this variable may hide a number of critical errors.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_bug
References:
anssiR19

Rule   Disable compatibility with brk()   [ref]

Enabling compatiliby with brk() allows legacy binaries to run (i.e. those linked against libc5). But this compatibility comes at the cost of not being able to randomize the heap placement (ASLR). Unless legacy binaries need to run on the system, set CONFIG_COMPAT_BRK to "n". The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_COMPAT_BRK, run the following command: grep CONFIG_COMPAT_BRK /boot/config-* Configs with value 'n' are not explicitly set in the file, so either commented lines or no lines should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
Enabling compatibility with brk() disables support for ASLR.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_compat_brk
References:
anssiR17

Rule   Disable the 32-bit vDSO   [ref]

Certain buggy versions of glibc (2.3.3) will crash if they are presented with a 32-bit vDSO that is not mapped at the address indicated in its segment table. Setting CONFIG_COMPAT_VDSO to y turns off the 32-bit VDSO and works aroud the glibc bug. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_COMPAT_VDSO, run the following command: grep CONFIG_COMPAT_VDSO /boot/config-* Configs with value 'n' are not explicitly set in the file, so either commented lines or no lines should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
Enabling VDSO compatibility hurts performance and disables ASLR.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_compat_vdso
References:
anssiR15

Rule   Enable checks on credential management   [ref]

Enable this to turn on some debug checking for credential management. The additional code keeps track of the number of pointers from task_structs to any given cred struct, and checks to see that this number never exceeds the usage count of the cred struct. Furthermore, if SELinux is enabled, this also checks that the security pointer in the cred struct is never seen to be invalid. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_DEBUG_CREDENTIALS, run the following command: grep CONFIG_DEBUG_CREDENTIALS /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This adds sanity checks and validations to credential data structures.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_debug_credentials
References:
anssiR16

Rule   Disable kernel debugfs   [ref]

debugfs is a virtual file system that kernel developers use to put debugging files into. Enable this option to be able to read and write to these files. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_DEBUG_FS, run the following command: grep CONFIG_DEBUG_FS /boot/config-* Configs with value 'n' are not explicitly set in the file, so either commented lines or no lines should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
To reduce the attack surface, this file system should be disabled if not in use.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_debug_fs
References:
anssiR15

Rule   Enable checks on linked list manipulation   [ref]

Enable this to turn on extended checks in the linked-list walking routines. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_DEBUG_LIST, run the following command: grep CONFIG_DEBUG_LIST /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This add sanity checks to manipulation of linked lists structures in the kernel and may prevent exploits such as CVE-2017-1661, where a race condition and simultaneos operations caused a list to corrupt.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_debug_list
References:
anssiR16

Rule   Enable checks on notifier call chains   [ref]

Enable this to turn on sanity checking for notifier call chains. This is most useful for kernel developers to make sure that modules properly unregister themselves from notifier chains. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_DEBUG_NOTIFIERS, run the following command: grep CONFIG_DEBUG_NOTIFIERS /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This provides validation of notifier chains, it checks whether the notifiers are from the kernel or a module that is still loaded prior to being invoked.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_debug_notifiers
References:
anssiR16

Rule   Enable checks on scatter-gather (SG) table operations   [ref]

Scatter-gather tables are mechanism used for high performance I/O on DMA devices. Enable this to turn on checks on scatter-gather tables. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_DEBUG_SG, run the following command: grep CONFIG_DEBUG_SG /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This can help find problems with drivers that do not properly initialize their SG tables.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_debug_sg
References:
anssiR16

Rule   Configure Low Address Space To Protect From User Allocation   [ref]

This is the portion of low virtual memory which should be protected from userspace allocation. This configuration is available from kernel 3.14, but may be available if backported by distros. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_DEFAULT_MMAP_MIN_ADDR, run the following command: grep CONFIG_DEFAULT_MMAP_MIN_ADDR /boot/config-* For each kernel installed, a line with value should be returned. If the system architecture is x86_64, the value should be 65536. If the system architecture is aarch64, the value should be 32768.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
Keeping a user from writing to low pages can help reduce the impact of kernel NULL pointer bugs.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_default_mmap_min_addr
References:
anssiR25, R27

Rule   Disable /dev/kmem virtual device support   [ref]

Disable support for the /dev/kmem device. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_DEVKMEM, run the following command: grep CONFIG_DEVKMEM /boot/config-* Configs with value 'n' are not explicitly set in the file, so either commented lines or no lines should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
The /dev/kmem device is rarely used, but can be used for certain kind of kernel debugging operations.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_devkmem
References:
anssiR15

Rule   Disable hibernation   [ref]

Enable the suspend to disk (STD) functionality, which is usually called "hibernation" in user interfaces. STD checkpoints the system and powers it off; and restores that checkpoint on reboot. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_HIBERNATION, run the following command: grep CONFIG_HIBERNATION /boot/config-* Configs with value 'n' are not explicitly set in the file, so either commented lines or no lines should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
Suspending to disk allows one to replace the running kernel.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_hibernation
References:
anssiR23

Rule   Disable IA32 emulation   [ref]

Disables support for legacy 32-bit programs under a 64-bit kernel. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_IA32_EMULATION, run the following command: grep CONFIG_IA32_EMULATION /boot/config-* Configs with value 'n' are not explicitly set in the file, so either commented lines or no lines should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Warning:  Only disable support for 32-bit programs if you are sure you don't need any 32-bit program.
Rationale:
Disabling 32-bit backwards compatibility helps reduce the attack surface.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_ia32_emulation
References:
anssiR25

Rule   Disable kexec system call   [ref]

kexec is a system call that implements the ability to shutdown your current kernel, and to start another kernel. It is like a reboot but it is independent of the system firmware. And like a reboot you can start any kernel with it, not just Linux. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_KEXEC, run the following command: grep CONFIG_KEXEC /boot/config-* Configs with value 'n' are not explicitly set in the file, so either commented lines or no lines should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
Prohibits the execution of a new kernel image after reboot.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_kexec
References:
anssiR23

Rule   Disable legacy (BSD) PTY support   [ref]

Disable the Linux traditional BSD-like terminal names /dev/ptyxx for masters and /dev/ttyxx for slaves of pseudo terminals, and use only the modern ptys (devpts) interface. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_LEGACY_PTYS, run the following command: grep CONFIG_LEGACY_PTYS /boot/config-* Configs with value 'n' are not explicitly set in the file, so either commented lines or no lines should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
The legacy scheme has a number of security problems.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_legacy_ptys
References:
anssiR23

Rule   Enable module signature verification   [ref]

Check modules for valid signatures upon load. Note that this option adds the OpenSSL development packages as a kernel build dependency so that the signing tool can use its crypto library. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_MODULE_SIG, run the following command: grep CONFIG_MODULE_SIG /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
Loaded modules must be signed.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_module_sig
References:
anssiR18

Rule   Enable automatic signing of all modules   [ref]

Sign all modules during make modules_install. Without this option, modules must be signed manually, using the scripts/sign-file tool. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_MODULE_SIG_ALL, run the following command: grep CONFIG_MODULE_SIG_ALL /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This ensures the modules are signed during install process.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_module_sig_all
References:
anssiR18

Rule   Require modules to be validly signed   [ref]

Reject unsigned modules or signed modules with an unknown key. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_MODULE_SIG_FORCE, run the following command: grep CONFIG_MODULE_SIG_FORCE /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
Prevent loading modules that are unsigned or signed with an unknown key.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_module_sig_force
References:
anssiR18

Rule   Specify the hash to use when signing modules   [ref]

This configures the kernel to build and sign modules using sha512 as the hash function. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_MODULE_SIG_HASH, run the following command: grep CONFIG_MODULE_SIG_HASH /boot/config-* For each kernel installed, a line with value "sha512" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
Use of strong hash function is important to secure the module against counterfeit signatures.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_module_sig_hash
References:
anssiR18

Rule   Specify module signing key to use   [ref]

Setting this option to something other than its default of certs/signing_key.pem will disable the autogeneration of signing keys and allow the kernel modules to be signed with a key of your choosing. The string provided should identify a file containing both a private key and its corresponding X.509 certificate in PEM form, or — on systems where the OpenSSL ENGINE_pkcs11 is functional — a PKCS#11 URI as defined by RFC7512. In the latter case, the PKCS#11 URI should reference both a certificate and a private key. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_MODULE_SIG_KEY, run the following command: grep CONFIG_MODULE_SIG_KEY /boot/config-* For each kernel installed, a line with value "certs/signing_key.pem" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
A key and certificate is required to sign the built modules.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_module_sig_key
References:
anssiR18

Rule   Sign kernel modules with SHA-512   [ref]

This configures the kernel to build and sign modules using SHA512 as the hash function. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_MODULE_SIG_SHA512, run the following command: grep CONFIG_MODULE_SIG_SHA512 /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
Use of strong hash function is important to secure the module against counterfeit signatures.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_module_sig_sha512
References:
anssiR18

Rule   Enable poison without sanity check   [ref]

Skip the sanity checking on alloc, only fill the pages with poison on free. This reduces some of the overhead of the poisoning feature. This configuration is available from kernel 4.6. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_PAGE_POISONING_NO_SANITY, run the following command: grep CONFIG_PAGE_POISONING_NO_SANITY /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This configuration helps alleviates the performance impact of poisonining.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_page_poisoning_no_sanity
References:
anssiR17

Rule   Use zero for poisoning instead of debugging value   [ref]

Instead of using the existing poison value, fill the pages with zeros. This makes it harder to detect when errors are occurring due to sanitization but the zeroing at free means that it is no longer necessary to write zeros when GFP_ZERO is used on allocation. This configuration is available from kernel 4.19. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_PAGE_POISONING_ZERO, run the following command: grep CONFIG_PAGE_POISONING_ZERO /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This configuration helps alleviates the performance impact of poisonining.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_page_poisoning_zero
References:
anssiR17

Rule   Remove the kernel mapping in user mode   [ref]

This feature reduces the number of hardware side channels by ensuring that the majority of kernel addresses are not mapped into userspace. This configuration is available from kernel 4.15, but may be available if backported by distros. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_PAGE_TABLE_ISOLATION, run the following command: grep CONFIG_PAGE_TABLE_ISOLATION /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This is a countermeasure to the Meltdown attack.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_page_table_isolation
References:
anssiR25

Rule   Kernel panic oops   [ref]

Enable the kernel to panic when it oopses. This has the same effect as setting oops=panic on the kernel command line. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_PANIC_ON_OOPS, run the following command: grep CONFIG_PANIC_ON_OOPS /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This feature ensures that the kernel does not do anything erroneous after an oops which could result in data corruption or other issues.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_panic_on_oops
References:
anssiR19

Rule   Kernel panic timeout   [ref]

Set the timeout value (in seconds) until a reboot occurs when the kernel panics. A timeout of 0 configures the system to wait forever. With a timeout value greater than 0, the system will wait the specified amount of seconds before rebooting. While a timeout value less than 0 makes the system reboot immediately. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_PANIC_TIMEOUT, run the following command: grep CONFIG_PANIC_TIMEOUT /boot/config-* For each kernel installed, a line with value "0" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This is required to enable protection against Spectre v2.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_panic_timeout
References:
anssiR19

Rule   Disable support for /proc/kkcore   [ref]

Provides a virtual ELF core file of the live kernel. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_PROC_KCORE, run the following command: grep CONFIG_PROC_KCORE /boot/config-* Configs with value 'n' are not explicitly set in the file, so either commented lines or no lines should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This feature exposes the memory to the userspace and can assist an attacker in discovering attack vectors.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_proc_kcore
References:
anssiR15

Rule   Randomize the address of the kernel image (KASLR)   [ref]

In support of Kernel Address Space Layout Randomization (KASLR), this randomizes the physical address at which the kernel image is decompressed and the virtual address where the kernel image is mapped. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_RANDOMIZE_BASE, run the following command: grep CONFIG_RANDOMIZE_BASE /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
An unpredictable kernel address makes it more difficult to succeed with exploits that rely on knowledge of the location of kernel code internals.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_randomize_base
References:
anssiR25, R27

Rule   Randomize the kernel memory sections   [ref]

Randomizes the base virtual address of kernel memory sections (physical memory mapping, vmalloc & vmemmap). This configuration is available from kernel 4.8, but may be available if backported by distros. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_RANDOMIZE_MEMORY, run the following command: grep CONFIG_RANDOMIZE_MEMORY /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This security feature makes exploits relying on predictable memory locations less reliable.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_randomize_memory
References:
anssiR25

Rule   Avoid speculative indirect branches in kernel   [ref]

Compile kernel with the retpoline compiler options to guard against kernel-to-user data leaks by avoiding speculative indirect branches. Requires a compiler with -mindirect-branch=thunk-extern support for full protection. The kernel may run slower. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_RETPOLINE, run the following command: grep CONFIG_RETPOLINE /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This is required to enable protection against Spectre v2.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_retpoline
References:
anssiR15

Rule   Enable seccomp to safely compute untrusted bytecode   [ref]

This kernel feature is useful for number crunching applications that may need to compute untrusted bytecode during their execution. By using pipes or other transports made available to the process as file descriptors supporting the read/write syscalls, it's possible to isolate those applications in their own address space using seccomp. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_SECCOMP, run the following command: grep CONFIG_SECCOMP /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
seccomp enables the ability to filter system calls made by an application, effectively isolating the system's resources from it.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_seccomp
References:
anssiR20

Rule   Enable use of Berkeley Packet Filter with seccomp   [ref]

Enable tasks to build secure computing environments defined in terms of Berkeley Packet Filter programs which implement task-defined system call filtering polices. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_SECCOMP_FILTER, run the following command: grep CONFIG_SECCOMP_FILTER /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
Use of BPF filters allows for expressive filtering of system calls using a filter program language with a long history of being exposed to userland.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_seccomp_filter
References:
anssiR20

Rule   Enable different security models   [ref]

This allows you to choose different security modules to be configured into your kernel. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_SECURITY, run the following command: grep CONFIG_SECURITY /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This is enables kernel security primitives required by the LSM framework.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_security
References:
anssiR20

Rule   Restrict unprivileged access to the kernel syslog   [ref]

Enforce restrictions on unprivileged users reading the kernel syslog via dmesg(8). The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_SECURITY_DMESG_RESTRICT, run the following command: grep CONFIG_SECURITY_DMESG_RESTRICT /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
Prevents unprivileged users from retrieving kernel addresses with dmesg.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_security_dmesg_restrict
References:
anssiR15

Rule   Disable mutable hooks   [ref]

Ensure kernel structures associated with LSMs are always mapped as read-only after system boot. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_SECURITY_WRITABLE_HOOKS, run the following command: grep CONFIG_SECURITY_WRITABLE_HOOKS /boot/config-* Configs with value 'n' are not explicitly set in the file, so either commented lines or no lines should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
If CONFIG_SECURITY_WRITABLE_HOOKS is enabled, then hooks can be loaded at runtime and being able to manipulate hooks is a way to bypass all LSMs.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_security_writable_hooks
References:
anssiR20

Rule   Enable Yama support   [ref]

This enables support for LSM module Yama, which extends DAC support with additional system-wide security settings beyond regular Linux discretionary access controls. The module will limit the use of the system call ptrace(). The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_SECURITY_YAMA, run the following command: grep CONFIG_SECURITY_YAMA /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
Unrestricted usage of ptrace allows compromised binaries to run ptrace on another processes of the user.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_security_yama
References:
anssiR20

Rule   Enable SLUB debugging support   [ref]

SLUB has extensive debug support features and this allows the allocator validation checking to be enabled. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_SLUB_DEBUG, run the following command: grep CONFIG_SLUB_DEBUG /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This activates the checking of the memory allocator structures and resets to zero the zones allocated when they are released.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_slub_debug
References:
anssiR17

Rule   Enable TCP/IP syncookie support   [ref]

Normal TCP/IP networking is open to an attack known as SYN flooding. It is denial-of-service attack that prevents legitimate remote users from being able to connect to your computer during an ongoing attack. When enabled the TCP/IP stack will use a cryptographic challenge protocol known as SYN cookies to enable legitimate users to continue to connect, even when your machine is under attack. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_SYN_COOKIES, run the following command: grep CONFIG_SYN_COOKIES /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
SYN cookies provide protection against SYN flooding attacks.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_syn_cookies
References:
anssiR22

Rule   Unmap kernel when running in userspace (aka KAISER)   [ref]

Speculation attacks against some high-performance processors can be used to bypass MMU permission checks and leak kernel data to userspace. This can be defended against by unmapping the kernel when running in userspace, mapping it back in on exception entry via a trampoline page in the vector table. This configuration is available from kernel 4.16, but may be available if backported by distros. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_UNMAP_KERNEL_AT_EL0, run the following command: grep CONFIG_UNMAP_KERNEL_AT_EL0 /boot/config-* For each kernel installed, a line with value "y" should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
This is a countermeasure to the Meltdown attack.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_unmap_kernel_at_el0
References:
anssiR27

Rule   Disable x86 vsyscall emulation   [ref]

Disabling it is roughly equivalent to booting with vsyscall=none, except that it will also disable the helpful warning if a program tries to use a vsyscall. With this option set to N, offending programs will just segfault, citing addresses of the form 0xffffffffff600?00. This configuration is available from kernel 3.19. The configuration that was used to build kernel is available at /boot/config-*. To check the configuration value for CONFIG_X86_VSYSCALL_EMULATION, run the following command: grep CONFIG_X86_VSYSCALL_EMULATION /boot/config-* Configs with value 'n' are not explicitly set in the file, so either commented lines or no lines should be returned.
Warning:  There is no remediation for this besides re-compiling the kernel with the appropriate value for the config.
Rationale:
The vsyscall table is no longer required and is a potential source of ROP gadgets.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_kernel_config_x86_vsyscall_emulation
References:
anssiR15
Group   Configure Syslog   Group contains 3 groups and 7 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 Red Hat Enterprise Linux CoreOS 4, 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 Red Hat Enterprise Linux CoreOS 4 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
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
disaCCI-001314
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
ism0988, 1405
iso27001-2013A.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-cipCIP-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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-10.5.1, Req-10.5.2
anssiR71
pcidss410.3.2

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
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
disaCCI-001314
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
ism0988, 1405
iso27001-2013A.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-cipCIP-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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-10.5.1, Req-10.5.2
anssiR71
pcidss410.3.2

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
References:
disaCCI-001314
ism0988, 1405
nerc-cipCIP-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
nistCM-6(a), AC-6(1)
pcidssReq-10.5.1, Req-10.5.2
anssiR71
pcidss410.3.1
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 dnf install logrotate
Rationale:
The logrotate package provides the logrotate services.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_logrotate_installed
References:
cis-csc1, 14, 15, 16, 3, 5, 6
cobit5APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01
disaCCI-000366
isa-62443-20094.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-2013SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9
iso27001-2013A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1
nistCM-6(a)
nist-csfPR.PT-1
pcidssReq-10.7
anssiR71
pcidss410.5.1

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-82689-1

References:
cis-csc1, 14, 15, 16, 3, 5, 6
cobit5APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01
disaCCI-000366
isa-62443-20094.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-2013SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9
iso27001-2013A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1
nistCM-6(a)
nist-csfPR.PT-1
pcidssReq-10.7
anssiR71

Complexity:low
Disruption:low
Reboot:true
Strategy:restrict
---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,{{ %23%20see%20%22man%20logrotate%22%20for%20details%0A%23%20rotate%20log%20files%20daily%0Adaily%0A%0A%23%20keep%204%20weeks%20worth%20of%20backlogs%0Arotate%2030%0A%0A%23%20create%20new%20%28empty%29%20log%20files%20after%20rotating%20old%20ones%0Acreate%0A%0A%23%20use%20date%20as%20a%20suffix%20of%20the%20rotated%20file%0Adateext%0A%0A%23%20uncomment%20this%20if%20you%20want%20your%20log%20files%20compressed%0A%23compress%0A%0A%23%20RPM%20packages%20drop%20log%20rotation%20information%20into%20this%20directory%0Ainclude%20/etc/logrotate.d%0A%0A%23%20system-specific%20logs%20may%20be%20also%20be%20configured%20here. }}
        mode: 0644
        path: /etc/logrotate.conf
        overwrite: true

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
References:
cis-csc1, 14, 15, 16, 3, 5, 6
cobit5APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01
disaCCI-000366
isa-62443-20094.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-2013SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9
iso27001-2013A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1
nistCM-6(a)
nist-csfPR.PT-1
pcidssReq-10.7
anssiR71
pcidss410.5.1
Group   Rsyslog Logs Sent To Remote Host   Group contains 1 rule
[ref]   If system logs are to be useful in detecting malicious activities, it is necessary to send logs to a remote server. An intruder who has compromised the root account on a system may delete the log entries which indicate that the system was attacked before they are seen by an administrator.

However, it is recommended that logs be stored on the local host in addition to being sent to the loghost, especially if rsyslog has been configured to use the UDP protocol to send messages over a network. UDP does not guarantee reliable delivery, and moderately busy sites will lose log messages occasionally, especially in periods of high traffic which may be the result of an attack. In addition, remote rsyslog messages are not authenticated in any way by default, so it is easy for an attacker to introduce spurious messages to the central log server. Also, some problems cause loss of network connectivity, which will prevent the sending of messages to the central server. For all of these reasons, it is better to store log messages both centrally and on each host, so that they can be correlated if necessary.

Rule   Ensure Logs Sent To Remote Host   [ref]

To configure rsyslog to send logs to a remote log server, open /etc/rsyslog.conf and read and understand the last section of the file, which describes the multiple directives necessary to activate remote logging. Along with these other directives, the system can be configured to forward its logs to a particular log server by adding or correcting one of the following lines, substituting logcollector appropriately. The choice of protocol depends on the environment of the system; although TCP and RELP provide more reliable message delivery, they may not be supported in all environments.
To use UDP for log message delivery:
*.* @logcollector
        

To use TCP for log message delivery:
*.* @@logcollector
        

To use RELP for log message delivery:
*.* :omrelp:logcollector
        

There must be a resolvable DNS CNAME or Alias record set to "logcollector" for logs to be sent correctly to the centralized logging utility.
Warning:  It is important to configure queues in case the client is sending log messages to a remote server. If queues are not configured, the system will stop functioning when the connection to the remote server is not available. Please consult Rsyslog documentation for more information about configuration of queues. The example configuration which should go into /etc/rsyslog.conf can look like the following lines:
$ActionQueueType LinkedList
$ActionQueueFileName queuefilename
$ActionQueueMaxDiskSpace 1g
$ActionQueueSaveOnShutdown on
$ActionResumeRetryCount -1
Rationale:
A log server (loghost) receives syslog messages from one or more systems. This data can be used as an additional log source in the event a system is compromised and its local logs are suspect. Forwarding log messages to a remote loghost also provides system administrators with a centralized place to view the status of multiple hosts within the enterprise.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_rsyslog_remote_loghost
References:
cis-csc1, 13, 14, 15, 16, 2, 3, 5, 6
cobit5APO11.04, APO13.01, BAI03.05, BAI04.04, DSS05.04, DSS05.07, MEA02.01
disaCCI-000366, CCI-001348, CCI-000136, CCI-001851
hipaa164.308(a)(1)(ii)(D), 164.308(a)(5)(ii)(B), 164.308(a)(5)(ii)(C), 164.308(a)(6)(ii), 164.308(a)(8), 164.310(d)(2)(iii), 164.312(b), 164.314(a)(2)(i)(C), 164.314(a)(2)(iii)
isa-62443-20094.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-2013SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 7.1, SR 7.2
ism0988, 1405
iso27001-2013A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.17.2.1
nerc-cipCIP-003-8 R5.2, CIP-004-6 R3.3
nistCM-6(a), AU-4(1), AU-9(2)
nist-csfPR.DS-4, PR.PT-1
osppFAU_GEN.1.1.c
os-srgSRG-OS-000479-GPOS-00224, SRG-OS-000480-GPOS-00227, SRG-OS-000342-GPOS-00133
anssiR71
Group   Network Configuration and Firewalls   Group contains 8 groups and 38 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 9 rules
[ref]   Support for Internet Protocol Security (IPsec) is provided with Libreswan.

Rule   Verify Group Who Owns /etc/ipsec.d Directory   [ref]

To properly set the group owner of /etc/ipsec.d, run the command:
$ sudo chgrp root /etc/ipsec.d
Rationale:
The ownership of the /etc/ipsec.d directory by the root group is important because this directory hosts Libreswan configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the Libreswan configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_groupowner_etc_ipsecd
References:
anssiR50

Rule   Verify User Who Owns /etc/ipsec.d Directory   [ref]

To properly set the owner of /etc/ipsec.d, run the command:
$ sudo chown root /etc/ipsec.d 
Rationale:
The ownership of the /etc/ipsec.d directory by the root user is important because this directory hosts Libreswan configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the Libreswan configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_owner_etc_ipsecd
References:
anssiR50

Rule   Verify Permissions On /etc/ipsec.d Directory   [ref]

To properly set the permissions of /etc/ipsec.d, run the command:
$ sudo chmod 0700 /etc/ipsec.d
Rationale:
Setting correct permissions on the /etc/ipsec.d directory is important because this directory hosts Libreswan configuration. Protection of this directory is critical for system security. Restricting the permissions ensures exclusive control of the Libreswan configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_permissions_etc_ipsecd
References:
anssiR50

Rule   Verify Group Who Owns /etc/ipsec.conf File   [ref]

To properly set the group owner of /etc/ipsec.conf, run the command:
$ sudo chgrp root /etc/ipsec.conf
Rationale:
The ownership of the /etc/ipsec.conf file by the root group is important because this file hosts Libreswan configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the Libreswan configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_etc_ipsec_conf
References:
anssiR50

Rule   Verify Group Who Owns /etc/ipsec.secrets File   [ref]

To properly set the group owner of /etc/ipsec.secrets, run the command:
$ sudo chgrp root /etc/ipsec.secrets
Rationale:
The ownership of the /etc/ipsec.secrets file by the root group is important because this file hosts Libreswan configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the Libreswan configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_etc_ipsec_secrets
References:
anssiR50

Rule   Verify User Who Owns /etc/ipsec.conf File   [ref]

To properly set the owner of /etc/ipsec.conf, run the command:
$ sudo chown root /etc/ipsec.conf 
Rationale:
The ownership of the /etc/ipsec.conf file by the root user is important because this file hosts Libreswan configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the Libreswan configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_etc_ipsec_conf
References:
anssiR50

Rule   Verify User Who Owns /etc/ipsec.secrets File   [ref]

To properly set the owner of /etc/ipsec.secrets, run the command:
$ sudo chown root /etc/ipsec.secrets 
Rationale:
The ownership of the /etc/ipsec.secrets file by the root user is important because this file hosts Libreswan configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the Libreswan configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_etc_ipsec_secrets
References:
anssiR50

Rule   Verify Permissions On /etc/ipsec.conf File   [ref]

To properly set the permissions of /etc/ipsec.conf, run the command:
$ sudo chmod 0644 /etc/ipsec.conf
Rationale:
Setting correct permissions on the /etc/ipsec.conf file is important because this file hosts Libreswan configuration. Protection of this file is critical for system security. Restricting the permissions ensures exclusive control of the Libreswan configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_etc_ipsec_conf
References:
anssiR50

Rule   Verify Permissions On /etc/ipsec.secrets File   [ref]

To properly set the permissions of /etc/ipsec.secrets, run the command:
$ sudo chmod 0644 /etc/ipsec.secrets
Rationale:
Setting correct permissions on the /etc/ipsec.secrets file is important because this file hosts Libreswan configuration. Protection of this file is critical for system security. Restricting the permissions ensures exclusive control of the Libreswan configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_etc_ipsec_secrets
References:
anssiR50
Group   iptables and ip6tables   Group contains 3 rules
[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   Verify Group Who Owns /etc/iptables Directory   [ref]

To properly set the group owner of /etc/iptables, run the command:
$ sudo chgrp root /etc/iptables
Rationale:
The ownership of the /etc/iptables directory by the root group is important because this directory hosts iptables configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the iptables configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_groupowner_etc_iptables
References:
anssiR50

Rule   Verify User Who Owns /etc/iptables Directory   [ref]

To properly set the owner of /etc/iptables, run the command:
$ sudo chown root /etc/iptables 
Rationale:
The ownership of the /etc/iptables directory by the root user is important because this directory hosts iptables configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the iptables configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_owner_etc_iptables
References:
anssiR50

Rule   Verify Permissions On /etc/iptables Directory   [ref]

To properly set the permissions of /etc/iptables, run the command:
$ sudo chmod 0600 /etc/iptables
Rationale:
Setting correct permissions on the /etc/iptables directory is important because this directory hosts iptables configuration. Protection of this directory is critical for system security. Restricting the permissions ensures exclusive control of the iptables configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_permissions_etc_iptables
References:
anssiR50
Group   IPv6   Group contains 1 group and 4 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   Configure IPv6 Settings if Necessary   Group contains 4 rules
[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 Accepting ICMP Redirects for All IPv6 Interfaces   [ref]

To set the runtime status of the net.ipv6.conf.all.accept_redirects kernel parameter, run the following command:
$ sudo sysctl -w net.ipv6.conf.all.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.ipv6.conf.all.accept_redirects = 0
Rationale:
An illicit ICMP redirect message could result in a man-in-the-middle attack.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_redirects
Identifiers:

CCE-82471-4

References:
cis-csc11, 14, 3, 9
cobit5BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06
cui3.1.20
disaCCI-000366, CCI-001551
isa-62443-20094.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-2013SR 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-2013A.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
nistCM-7(a), CM-7(b), CM-6(a), CM-6(b), CM-6.1(iv)
nist-csfPR.IP-1, PR.PT-3
os-srgSRG-OS-000480-GPOS-00227
anssiR13

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.ipv6.conf.all.accept_redirects%3D0%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_ipv6_conf_all_accept_redirects.conf
        overwrite: true

Rule   Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv6 Interfaces   [ref]

To set the runtime status of the net.ipv6.conf.all.accept_source_route kernel parameter, run the following command:
$ sudo sysctl -w net.ipv6.conf.all.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.all.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_all_accept_source_route
Identifiers:

CCE-82480-5

References:
cis-csc1, 12, 13, 14, 15, 16, 18, 4, 6, 8, 9
cobit5APO01.06, APO13.01, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.07, DSS06.02
cui3.1.20
disaCCI-000366
isa-62443-20094.2.3.4, 4.3.3.4, 4.4.3.3
isa-62443-2013SR 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-2013A.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
nistCM-7(a), CM-7(b), CM-6(a)
nist-csfDE.AE-1, ID.AM-3, PR.AC-5, PR.DS-5, PR.PT-4
os-srgSRG-OS-000480-GPOS-00227
anssiR13

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.ipv6.conf.all.accept_source_route%3D0%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_ipv6_conf_all_accept_source_route.conf
        overwrite: true

Rule   Disable Kernel Parameter for Accepting ICMP Redirects by Default on IPv6 Interfaces   [ref]

To set the runtime status of the net.ipv6.conf.default.accept_redirects kernel parameter, run the following command:
$ sudo sysctl -w net.ipv6.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.ipv6.conf.default.accept_redirects = 0
Rationale:
An illicit ICMP redirect message could result in a man-in-the-middle attack.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_redirects
Identifiers:

CCE-82477-1

References:
cis-csc11, 14, 3, 9
cobit5BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06
cui3.1.20
disaCCI-000366, CCI-001551
isa-62443-20094.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-2013SR 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-2013A.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
nistCM-7(a), CM-7(b), CM-6(a)
nist-csfPR.IP-1, PR.PT-3
os-srgSRG-OS-000480-GPOS-00227
anssiR13

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.ipv6.conf.default.accept_redirects%20%3D%200%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_ipv6_conf_default_accept_redirects.conf
        overwrite: true

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-82481-3

References:
cis-csc1, 12, 13, 14, 15, 16, 18, 4, 6, 8, 9
cobit5APO01.06, APO13.01, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.07, DSS06.02
cui3.1.20
disaCCI-000366
isa-62443-20094.2.3.4, 4.3.3.4, 4.4.3.3
isa-62443-2013SR 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-2013A.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
nistCM-7(a), CM-7(b), CM-6(a), CM-6(b), CM-6.1(iv)
nist-csfDE.AE-1, ID.AM-3, PR.AC-5, PR.DS-5, PR.PT-4
pcidssReq-1.4.3
os-srgSRG-OS-000480-GPOS-00227
anssiR13
pcidss41.4.2

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.ipv6.conf.default.accept_source_route%3D0%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_ipv6_conf_default_accept_source_route.conf
        overwrite: true
Group   Kernel Parameters Which Affect Networking   Group contains 2 groups and 19 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 16 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   Disable Accepting Packets Routed Between Local Interfaces   [ref]

To set the runtime status of the net.ipv4.conf.all.accept_local kernel parameter, run the following command:
$ sudo sysctl -w net.ipv4.conf.all.accept_local=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.accept_local = 0
Rationale:
Configure net.ipv4.conf.all.accept_local=0 to consider as invalid the packets received from outside whose source is the 127.0.0.0/8 address block. In combination with suitable routing, this can be used to direct packets between two local interfaces over the wire and have them accepted properly.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_accept_local
References:
anssiR12

Rule   Disable Accepting ICMP Redirects for All IPv4 Interfaces   [ref]

To set the runtime status of the net.ipv4.conf.all.accept_redirects kernel parameter, run the following command:
$ sudo sysctl -w net.ipv4.conf.all.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.all.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_all_accept_redirects
Identifiers:

CCE-82469-8

References:
cis-csc1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9
cjis5.10.1.1
cobit5APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06
cui3.1.20
disaCCI-000366, CCI-001503, CCI-001551
isa-62443-20094.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-2013SR 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-2013A.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
nistCM-7(a), CM-7(b), CM-6(a), SC-7(a)
nist-csfDE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3
os-srgSRG-OS-000480-GPOS-00227
anssiR12

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.ipv4.conf.all.accept_redirects%3D0%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_redirects.conf
        overwrite: true

Rule   Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv4 Interfaces   [ref]

To set the runtime status of the net.ipv4.conf.all.accept_source_route kernel parameter, run the following command:
$ sudo sysctl -w net.ipv4.conf.all.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.ipv4.conf.all.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 IPv4 forwarding is enabled and the system is functioning as a router.

Accepting source-routed packets in the IPv4 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_ipv4_conf_all_accept_source_route
Identifiers:

CCE-82478-9

References:
cis-csc1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9
cobit5APO01.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
cui3.1.20
disaCCI-000366
isa-62443-20094.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-2013SR 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-2013A.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-cipCIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1
nistCM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a)
nist-csfDE.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
os-srgSRG-OS-000480-GPOS-00227
anssiR12

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.ipv4.conf.all.accept_source_route%3D0%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_all_accept_source_route.conf
        overwrite: true

Rule   Configure ARP filtering for All IPv4 Interfaces   [ref]

To set the runtime status of the net.ipv4.conf.all.arp_filter kernel parameter, run the following command:
$ sudo sysctl -w net.ipv4.conf.all.arp_filter=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.arp_filter = 0
         
Warning:  This behaviour may cause problems to system on a high availability or load balancing configuration.
Rationale:
Prevents the Linux Kernel from handling the ARP table globally. By default, the kernel may respond to an ARP request from a certain interface with information from another interface.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_arp_filter
References:
anssiR12

Rule   Configure Response Mode of ARP Requests for All IPv4 Interfaces   [ref]

To set the runtime status of the net.ipv4.conf.all.arp_ignore kernel parameter, run the following command:
$ sudo sysctl -w net.ipv4.conf.all.arp_ignore=2
         
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.arp_ignore = 2
         
Warning:  The ARP response mode may impact behaviour of workloads and firewalls on the system.
Rationale:
Avoids ARP Flux on system that have more than one interface on the same subnet.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_arp_ignore
References:
anssiR12

Rule   Prevent Routing External Traffic to Local Loopback on All IPv4 Interfaces   [ref]

To set the runtime status of the net.ipv4.conf.all.route_localnet kernel parameter, run the following command:
$ sudo sysctl -w net.ipv4.conf.all.route_localnet=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.route_localnet = 0
Rationale:
Refuse the routing of packets whose source or destination address is the local loopback. This prohibits the use of network 127/8 for local routing purposes. Enabling route_localnet can expose applications listening on localhost to external traffic.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_route_localnet
References:
anssiR12

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-82488-8

References:
cis-csc1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9
cobit5APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02
cui3.1.20
disaCCI-000366, CCI-001551
isa-62443-20094.2.3.4, 4.3.3.4, 4.4.3.3
isa-62443-2013SR 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-2013A.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
nistCM-7(a), CM-7(b), CM-6(a), SC-7(a)
nist-csfDE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.PT-4
pcidssReq-1.4.3
os-srgSRG-OS-000480-GPOS-00227
anssiR12
pcidss41.4.3

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.ipv4.conf.all.rp_filter%3D1%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_all_rp_filter.conf
        overwrite: true

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-82482-1

References:
cis-csc1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9
cobit5APO01.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
cui3.1.20
disaCCI-001503, CCI-001551
isa-62443-20094.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-2013SR 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-2013A.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
nistCM-7(a), CM-7(b), CM-6(a), SC-7(a)
nist-csfDE.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
pcidssReq-1.4.3
os-srgSRG-OS-000480-GPOS-00227
anssiR12
pcidss41.4.3

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.ipv4.conf.all.secure_redirects%3D0%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_all_secure_redirects.conf
        overwrite: true

Rule   Configure Sending and Accepting Shared Media Redirects for All IPv4 Interfaces   [ref]

To set the runtime status of the net.ipv4.conf.all.shared_media kernel parameter, run the following command:
$ sudo sysctl -w net.ipv4.conf.all.shared_media=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.shared_media = 0
         
Rationale:
This setting should be aligned with net.ipv4.conf.all.secure_redirects because it overrides it. If shared_media is enabled for an interface secure_redirects will be enabled too.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_shared_media
References:
anssiR12

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-82470-6

References:
cis-csc1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9
cjis5.10.1.1
cobit5APO01.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
cui3.1.20
disaCCI-000366, CCI-001551
isa-62443-20094.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-2013SR 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-2013A.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
nistCM-7(a), CM-7(b), CM-6(a), SC-7(a)
nist-csfDE.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
pcidssReq-1.4.3
os-srgSRG-OS-000480-GPOS-00227
anssiR12
pcidss41.4.3

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.ipv4.conf.default.accept_redirects%3D0%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_default_accept_redirects.conf
        overwrite: true

Rule   Disable Kernel Parameter for Accepting Source-Routed Packets on IPv4 Interfaces by Default   [ref]

To set the runtime status of the net.ipv4.conf.default.accept_source_route kernel parameter, run the following command:
$ sudo sysctl -w net.ipv4.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.ipv4.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.
Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required, such as when IPv4 forwarding is enabled and the system is legitimately functioning as a router.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_accept_source_route
Identifiers:

CCE-82479-7

References:
cis-csc1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9
cjis5.10.1.1
cobit5APO01.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
cui3.1.20
disaCCI-000366, CCI-001551
isa-62443-20094.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-2013SR 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-2013A.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-cipCIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1
nistCM-7(a), CM-7(b), SC-5, SC-7(a)
nist-csfDE.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
os-srgSRG-OS-000480-GPOS-00227
anssiR12

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.ipv4.conf.default.accept_source_route%3D0%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_default_accept_source_route.conf
        overwrite: true

Rule   Enable Kernel Parameter to Use Reverse Path Filtering on all IPv4 Interfaces by Default   [ref]

To set the runtime status of the net.ipv4.conf.default.rp_filter kernel parameter, run the following command:
$ sudo sysctl -w net.ipv4.conf.default.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.default.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_default_rp_filter
Identifiers:

CCE-82489-6

References:
cis-csc1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9
cobit5APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02
cui3.1.20
disaCCI-000366
isa-62443-20094.2.3.4, 4.3.3.4, 4.4.3.3
isa-62443-2013SR 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-2013A.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
nistCM-7(a), CM-7(b), CM-6(a), SC-7(a)
nist-csfDE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.PT-4
os-srgSRG-OS-000480-GPOS-00227
anssiR12

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.ipv4.conf.default.rp_filter%3D1%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_default_rp_filter.conf
        overwrite: true

Rule   Configure Kernel Parameter for Accepting Secure Redirects By Default   [ref]

To set the runtime status of the net.ipv4.conf.default.secure_redirects kernel parameter, run the following command:
$ sudo sysctl -w net.ipv4.conf.default.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.default.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_default_secure_redirects
Identifiers:

CCE-82483-9

References:
cis-csc1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9
cobit5APO01.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
cui3.1.20
disaCCI-001551
isa-62443-20094.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-2013SR 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-2013A.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-cipCIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1
nistCM-7(a), CM-7(b), SC-5, SC-7(a)
nist-csfDE.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
os-srgSRG-OS-000480-GPOS-00227
anssiR12

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.ipv4.conf.default.secure_redirects%3D0%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_default_secure_redirects.conf
        overwrite: true

Rule   Configure Sending and Accepting Shared Media Redirects by Default   [ref]

To set the runtime status of the net.ipv4.conf.default.shared_media kernel parameter, run the following command:
$ sudo sysctl -w net.ipv4.conf.default.shared_media=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.shared_media = 0
         
Rationale:
This setting should be aligned with net.ipv4.conf.default.secure_redirects because it overrides it. If shared_media is enabled for an interface secure_redirects will be enabled too.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_shared_media
References:
anssiR12

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-82490-4

References:
cis-csc1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9
cobit5APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06
cui3.1.20
isa-62443-20094.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-2013SR 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-2013A.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-cipCIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1
nistCM-7(a), CM-7(b), SC-5
nist-csfDE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3
pcidssReq-1.4.3
os-srgSRG-OS-000480-GPOS-00227
anssiR12
pcidss41.4.2

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.ipv4.icmp_ignore_bogus_error_responses%3D1%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_ipv4_icmp_ignore_bogus_error_responses.conf
        overwrite: true

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-82492-0

References:
cis-csc1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9
cjis5.10.1.1
cobit5APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02
cui3.1.20
disaCCI-000366, CCI-001095
isa-62443-20094.2.3.4, 4.3.3.4, 4.4.3.3
isa-62443-2013SR 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-2013A.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
nistCM-7(a), CM-7(b), SC-5(1), SC-5(2), SC-5(3)(a), CM-6(a)
nist-csfDE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.PT-4
pcidssReq-1.4.1
os-srgSRG-OS-000480-GPOS-00227, SRG-OS-000420-GPOS-00186, SRG-OS-000142-GPOS-00071
anssiR12
pcidss41.4.3

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.ipv4.tcp_syncookies%3D1%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_ipv4_tcp_syncookies.conf
        overwrite: true
Group   Network Parameters for Hosts Only   Group contains 3 rules
[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 Sending ICMP Redirects on all IPv4 Interfaces   [ref]

To set the runtime status of the net.ipv4.conf.all.send_redirects kernel parameter, run the following command:
$ sudo sysctl -w net.ipv4.conf.all.send_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.send_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 contain information from the system's route table possibly revealing portions of the network topology.
The ability to send ICMP redirects is only appropriate for systems acting as routers.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_send_redirects
Identifiers:

CCE-82484-7

References:
cis-csc1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9
cjis5.10.1.1
cobit5APO01.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
cui3.1.20
disaCCI-000366
isa-62443-20094.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-2013SR 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-2013A.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-cipCIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1
nistCM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a)
nist-csfDE.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
os-srgSRG-OS-000480-GPOS-00227
anssiR12
pcidss41.4.5

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.ipv4.conf.all.send_redirects%3D0%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_all_send_redirects.conf
        overwrite: true

Rule   Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfaces by Default   [ref]

To set the runtime status of the net.ipv4.conf.default.send_redirects kernel parameter, run the following command:
$ sudo sysctl -w net.ipv4.conf.default.send_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.send_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 contain information from the system's route table possibly revealing portions of the network topology.
The ability to send ICMP redirects is only appropriate for systems acting as routers.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_send_redirects
Identifiers:

CCE-82485-4

References:
cis-csc1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9
cjis5.10.1.1
cobit5APO01.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
cui3.1.20
disaCCI-000366
isa-62443-20094.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-2013SR 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-2013A.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-cipCIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1
nistCM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a)
nist-csfDE.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
os-srgSRG-OS-000480-GPOS-00227
anssiR12
pcidss41.4.5

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.ipv4.conf.default.send_redirects%3D0%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_ipv4_conf_default_send_redirects.conf
        overwrite: true

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
References:
cis-csc1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9
cobit5APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06
cui3.1.20
disaCCI-000366
isa-62443-20094.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-2013SR 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-2013A.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-cipCIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1
nistCM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a)
nist-csfDE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3, PR.PT-4
pcidssReq-1.3.1, Req-1.3.2
os-srgSRG-OS-000480-GPOS-00227
anssiR12
pcidss41.4.3
Group   nftables   Group contains 3 rules
[ref]   If firewalld or iptables are being used in your environment, please follow the guidance in their respective section and pass-over the guidance in this section.

nftables is a subsystem of the Linux kernel providing filtering and classification of network packets/datagrams/frames and is the successor to iptables. The biggest change with the successor nftables is its simplicity. With iptables, we have to configure every single rule and use the syntax which can be compared with normal commands. With nftables, the simpler syntax, much like BPF (Berkely Packet Filter) means shorter lines and less repetition. Support for nftables should also be compiled into the kernel, together with the related nftables modules.

It is available in Linux kernels >= 3.13. Please ensure that your kernel supports nftables before choosing this option.

Rule   Verify Group Who Owns /etc/nftables Directory   [ref]

To properly set the group owner of /etc/nftables, run the command:
$ sudo chgrp root /etc/nftables
Rationale:
The ownership of the /etc/nftables directory by the root group is important because this directory hosts nftables configuration. Protection of this directory is critical for system security. Assigning the ownership to root ensures exclusive control of the nftables configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_groupowner_etc_nftables
References:
anssiR50

Rule   Verify User Who Owns /etc/nftables Directory   [ref]

To properly set the owner of /etc/nftables, run the command:
$ sudo chown root /etc/nftables 
Rationale:
The ownership of the /etc/nftables directory by the root user is important because this directory hosts nftables configuration. Protection of this directory is critical for system security. Assigning the ownership to root ensures exclusive control of the nftables configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_owner_etc_nftables
References:
anssiR50

Rule   Verify Permissions On /etc/nftables Directory   [ref]

To properly set the permissions of /etc/nftables, run the command:
$ sudo chmod 0700 /etc/nftables
Rationale:
Setting correct permissions on the /etc/nftables directory is important because this directory hosts nftables configuration. Protection of this directory is critical for system security. Restricting the permissions ensures exclusive control of the nftables configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_permissions_etc_nftables
References:
anssiR50
Group   File Permissions and Masks   Group contains 7 groups and 52 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 Red Hat Enterprise Linux CoreOS 4 installations:
$ mount -t xfs | awk '{print $3}'
For any systems that use a different local filesystem type, modify this command as appropriate.
Group   Verify Permissions on Important Files and Directories   Group contains 2 groups and 33 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 15 rules

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
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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-cipCIP-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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-8.7.c
os-srgSRG-OS-000480-GPOS-00227
anssiR50
pcidss42.2.6

Rule   Verify Group Who Owns gshadow File   [ref]

To properly set the group owner of /etc/gshadow, run the command:
$ sudo chgrp root /etc/gshadow
Rationale:
The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_etc_gshadow
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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-cipCIP-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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
os-srgSRG-OS-000480-GPOS-00227
anssiR50

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
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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-cipCIP-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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-8.7.c
os-srgSRG-OS-000480-GPOS-00227
anssiR50
pcidss42.2.6

Rule   Verify Group Who Owns shadow File   [ref]

To properly set the group owner of /etc/shadow, run the command:
$ sudo chgrp root /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
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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-cipCIP-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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-8.7.c
os-srgSRG-OS-000480-GPOS-00227
anssiR50
pcidss42.2.6

Rule   Verify Group Who Owns /etc/shells File   [ref]

To properly set the group owner of /etc/shells, run the command:
$ sudo chgrp root /etc/shells
Rationale:
The /etc/shells file contains the list of full pathnames to shells on the system. Since this file is used by many system programs this file should be protected.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_etc_shells
References:
nistAC-3, MP-2
anssiR50

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
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
disaCCI-002223
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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-cipCIP-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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-8.7.c
os-srgSRG-OS-000480-GPOS-00227
anssiR50
pcidss42.2.6

Rule   Verify User Who Owns gshadow File   [ref]

To properly set the owner of /etc/gshadow, run the command:
$ sudo chown root /etc/gshadow 
Rationale:
The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_etc_gshadow
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
disaCCI-002223
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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-cipCIP-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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
os-srgSRG-OS-000480-GPOS-00227
anssiR50

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
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
disaCCI-002223
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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-cipCIP-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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-8.7.c
os-srgSRG-OS-000480-GPOS-00227
anssiR50
pcidss42.2.6

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
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
disaCCI-002223
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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-cipCIP-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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-8.7.c
os-srgSRG-OS-000480-GPOS-00227
anssiR50
pcidss42.2.6

Rule   Verify Who Owns /etc/shells File   [ref]

To properly set the owner of /etc/shells, run the command:
$ sudo chown root /etc/shells 
Rationale:
The /etc/shells file contains the list of full pathnames to shells on the system. Since this file is used by many system programs this file should be protected.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_etc_shells
References:
nistAC-3, MP-2
anssiR50

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
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
disaCCI-002223
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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-cipCIP-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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-8.7.c
os-srgSRG-OS-000480-GPOS-00227
anssiR50
pcidss42.2.6

Rule   Verify Permissions on gshadow File   [ref]

To properly set the permissions of /etc/gshadow, run the command:
$ sudo chmod 0000 /etc/gshadow
Rationale:
The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_etc_gshadow
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
disaCCI-002223
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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-cipCIP-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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
os-srgSRG-OS-000480-GPOS-00227
anssiR50

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
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
disaCCI-002223
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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-cipCIP-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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-8.7.c
os-srgSRG-OS-000480-GPOS-00227
anssiR50
pcidss42.2.6

Rule   Verify Permissions on shadow File   [ref]

To properly set the permissions of /etc/shadow, run the command:
$ sudo chmod 0000 /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
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cjis5.5.2.2
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
disaCCI-002223
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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-cipCIP-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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
pcidssReq-8.7.c
os-srgSRG-OS-000480-GPOS-00227
anssiR50
pcidss42.2.6

Rule   Verify Permissions on /etc/shells File   [ref]

To properly set the permissions of /etc/shells, run the command:
$ sudo chmod 0644 /etc/shells
Rationale:
The /etc/shells file contains the list of full pathnames to shells on the system. Since this file is used by many system programs this file should be protected.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_etc_shells
References:
nistAC-3, MP-2
anssiR50
Group   Verify File Permissions Within Some Important Directories   Group contains 6 rules
[ref]   Some directories contain files whose confidentiality or integrity is notably important and may also be susceptible to misconfiguration over time, particularly if unpackaged software is installed. As such, an argument exists to verify that files' permissions within these directories remain configured correctly and restrictively.

Rule   Verify Group Who Owns /etc/sysctl.d Directory   [ref]

To properly set the group owner of /etc/sysctl.d, run the command:
$ sudo chgrp root /etc/sysctl.d
Rationale:
The ownership of the /etc/sysctl.d directory by the root group is important because this directory hosts kernel configuration. Protection of this directory is critical for system security. Assigning the ownership to root ensures exclusive control of the kernel configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_groupowner_etc_sysctld
References:
anssiR50

Rule   Verify User Who Owns /etc/sysctl.d Directory   [ref]

To properly set the owner of /etc/sysctl.d, run the command:
$ sudo chown root /etc/sysctl.d 
Rationale:
The ownership of the /etc/sysctl.d directory by the root user is important because this directory hosts kernel configuration. Protection of this directory is critical for system security. Assigning the ownership to root ensures exclusive control of the kernel configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_owner_etc_sysctld
References:
anssiR50

Rule   Verify Permissions On /etc/sysctl.d Directory   [ref]

To properly set the permissions of /etc/sysctl.d, run the command:
$ sudo chmod 0755 /etc/sysctl.d
Rationale:
Setting correct permissions on the /etc/sysctl.d directory is important because this directory hosts kernel configuration. Protection of this directory is critical for system security. Restricting the permissions ensures exclusive control of the kernel configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_permissions_etc_sysctld
References:
anssiR50

Rule   Verify that system commands files are group owned by root or a system account   [ref]

System commands files are stored in the following directories by default:
/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
All files in these directories should be owned by the root group, or a system account. If the directory, or any file in these directories, is found to be owned by a group other than root or a a system account correct its ownership with the following command:
$ sudo chgrp root FILE
         
Rationale:
If the operating system allows any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupownership_system_commands_dirs
References:
disaCCI-001499
nistCM-5(6), CM-5(6).1
os-srgSRG-OS-000259-GPOS-00100
anssiR50

Rule   Verify that System Executables Have Root Ownership   [ref]

System executables are stored in the following directories by default:
/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All files in these directories should be owned by the root user. If any file FILE in these directories is found to be owned by a user other than root, correct its ownership with the following command:
$ sudo chown root FILE
         
Rationale:
System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_ownership_binary_dirs
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
disaCCI-001499
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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-cipCIP-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
nistCM-5(6), CM-5(6).1, CM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
os-srgSRG-OS-000259-GPOS-00100
anssiR50

Rule   Verify that System Executables Have Restrictive Permissions   [ref]

System executables are stored in the following directories by default:
/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command:
$ sudo chmod go-w FILE
         
Rationale:
System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_binary_dirs
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
disaCCI-001499
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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-cipCIP-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
nistCM-5(6), CM-5(6).1, CM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
os-srgSRG-OS-000259-GPOS-00100
anssiR50

Rule   Verify that All World-Writable Directories Have Sticky Bits Set   [ref]

When the so-called 'sticky bit' is set on a directory, only the owner of a given file may remove that file from the directory. Without the sticky bit, any user with write access to a directory may remove any file in the directory. Setting the sticky bit prevents users from removing each other's files. In cases where there is no reason for a directory to be world-writable, a better solution is to remove that permission rather than to set the sticky bit. However, if a directory is used by a particular application, consult that application's documentation instead of blindly changing modes.
To set the sticky bit on a world-writable directory DIR, run the following command:
$ sudo chmod +t DIR
        
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 directories present on the system. It is not a problem in most cases, but especially systems with a large number of directories can be affected. See https://access.redhat.com/articles/6999111.
Rationale:
Failing to set the sticky bit on public directories allows unauthorized users to delete files in the directory structure.

The only authorized public directories are those temporary directories supplied with the system, or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system, by users for temporary file storage (such as /tmp), and for directories requiring global read/write access.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_dir_perms_world_writable_sticky_bits
Identifiers:

CCE-82753-5

References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
disaCCI-001090
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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-cipCIP-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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
os-srgSRG-OS-000138-GPOS-00069
anssiR54
pcidss42.2.6

Rule   Verify that system commands directories have root as a group owner   [ref]

System commands are stored in the following directories: by default:
/bin 
/sbin 
/usr/bin 
/usr/sbin 
/usr/local/bin 
/usr/local/sbin
All these directories should have root user as a group owner. If any system command directory is not group owned by a user other than root correct its ownership with the following command:
$ sudo chgrp root DIR
        
Rationale:
If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_dir_system_commands_group_root_owned
References:
disaCCI-001499
nistCM-5(6), CM-5(6).1
os-srgSRG-OS-000259-GPOS-00100
anssiR50

Rule   Verify that system commands directories have root ownership   [ref]

System commands are stored in the following directories by default:
/bin 
/sbin 
/usr/bin 
/usr/sbin 
/usr/local/bin 
/usr/local/sbin
All these directories should be owned by the root user. If any system command directory is not owned by a user other than root correct its ownership with the following command:
$ sudo chown root DIR
        
Rationale:
If the operating system were to allow any user to make changes to software libraries, then those changes might be implemented without undergoing the appropriate testing and approvals that are part of a robust change management process. This requirement applies to operating systems with software libraries that are accessible and configurable, as in the case of interpreted languages. Software libraries also include privileged programs which execute with escalated privileges. Only qualified and authorized individuals must be allowed to obtain access to information system components for purposes of initiating changes, including upgrades and modifications.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_dir_system_commands_root_owned
References:
disaCCI-001499
nistCM-5(6), CM-5(6).1
os-srgSRG-OS-000259-GPOS-00100
anssiR50

Rule   Verify Group Who Owns /etc/crypttab File   [ref]

To properly set the group owner of /etc/crypttab, run the command:
$ sudo chgrp root /etc/crypttab
Rationale:
The ownership of the /etc/crypttab file by the root group is important because this file hosts encrypted block devices configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the encrypted block devices configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_etc_crypttab
References:
anssiR50

Rule   Verify Group Who Owns System.map Files   [ref]

The System.map files are symbol map files generated during the compilation of the Linux kernel. They contain the mapping between kernel symbols and their corresponding memory addresses. These files must be group-owned by root. To properly set the group owner of /boot/System.map*, run the command:
$ sudo chgrp root /boot/System.map*
Rationale:
The purpose of System.map files is primarily for debugging and profiling the kernel. Unrestricted access to these files might disclose information useful to attackers and malicious software leading to more sophisticated exploitation.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_systemmap
References:
anssiR29

Rule   Verify User Who Owns /etc/crypttab File   [ref]

To properly set the owner of /etc/crypttab, run the command:
$ sudo chown root /etc/crypttab 
Rationale:
The ownership of the /etc/crypttab file by the root user is important because this file hosts encrypted block devices configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the encrypted block devices configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_etc_crypttab
References:
anssiR50

Rule   Verify User Who Owns System.map Files   [ref]

The System.map files are symbol map files generated during the compilation of the Linux kernel. They contain the mapping between kernel symbols and their corresponding memory addresses. These files must be owned by root. To properly set the owner of /boot/System.map*, run the command:
$ sudo chown root /boot/System.map* 
Rationale:
The purpose of System.map files is primarily for debugging and profiling the kernel. Unrestricted access to these files might disclose information useful to attackers and malicious software leading to more sophisticated exploitation.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_systemmap
References:
anssiR29

Rule   Verify Permissions On /etc/crypttab File   [ref]

To properly set the permissions of /etc/crypttab, run the command:
$ sudo chmod 0600 /etc/crypttab
Rationale:
Setting correct permissions on the /etc/crypttab file is important because this file hosts encrypted block devices configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the encrypted block devices configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_etc_crypttab
References:
anssiR50

Rule   Verify Permissions on System.map Files   [ref]

The System.map files are symbol map files generated during the compilation of the Linux kernel. They contain the mapping between kernel symbols and their corresponding memory addresses. In general, there is no need for non-root users to read these files. To properly set the permissions of /boot/System.map*, run the command:
$ sudo chmod 0600 /boot/System.map*
Rationale:
The purpose of System.map files is primarily for debugging and profiling the kernel. Unrestricted access to these files might disclose information useful to attackers and malicious software leading to more sophisticated exploitation.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_systemmap
References:
anssiR29

Rule   Ensure No World-Writable Files Exist   [ref]

It is generally a good idea to remove global (other) write access to a file when it is discovered. However, check with documentation for specific applications before making changes. Also, monitor for recurring world-writable files, as these may be symptoms of a misconfigured application or user account. Finally, this applies to real files and not virtual files that are a part of pseudo file systems such as sysfs or procfs.
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 files present on the system. It is not a problem in most cases, but especially systems with a large number of files can be affected. See https://access.redhat.com/articles/6999111.
Rationale:
Data in world-writable files can be modified by any user on the system. In almost all circumstances, files can be configured using a combination of user and group permissions to support whatever legitimate access is needed without the risk caused by world-writable files.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_unauthorized_world_writable
References:
cis-csc12, 13, 14, 15, 16, 18, 3, 5
cobit5APO01.06, DSS05.04, DSS05.07, DSS06.02
isa-62443-20094.3.3.7.3
isa-62443-2013SR 2.1, SR 5.2
iso27001-2013A.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-cipCIP-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
nistCM-6(a), AC-6(1)
nist-csfPR.AC-4, PR.DS-5
anssiR54
pcidss42.2.6
Group   Restrict Partition Mount Options   Group contains 10 rules
[ref]   System partitions can be mounted with certain options that limit what files on those partitions can do. These options are set in the /etc/fstab configuration file, and can be used to make certain types of malicious behavior more difficult.

Rule   Add nosuid Option to /boot   [ref]

The nosuid mount option can be used to prevent execution of setuid programs in /boot. The SUID and SGID permissions should not be required on the boot partition. Add the nosuid option to the list of Options in the systemd.mount unit that controls mounting of /boot.
Rationale:
The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from boot partitions.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_mount_option_boot_nosuid
References:
disaCCI-000366
nerc-cipCIP-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
nistCM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
nist-csfPR.IP-1, PR.PT-2, PR.PT-3
os-srgSRG-OS-000368-GPOS-00154, SRG-OS-000480-GPOS-00227
anssiR28

Rule   Add nosuid Option to /home   [ref]

The nosuid mount option can be used to prevent execution of setuid programs in /home. The SUID and SGID permissions should not be required in these user data directories. Add the nosuid option to the list of Options in the systemd.mount unit that controls mounting of /home.
Rationale:
The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from user home directory partitions.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_mount_option_home_nosuid
References:
cis-csc11, 13, 14, 3, 8, 9
cobit5APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS05.06, DSS06.06
disaCCI-000366
isa-62443-20094.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-2013SR 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-2013A.11.2.9, 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.8.2.1, A.8.2.2, A.8.2.3, A.8.3.1, A.8.3.3, A.9.1.2
nerc-cipCIP-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
nistCM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
nist-csfPR.IP-1, PR.PT-2, PR.PT-3
os-srgSRG-OS-000368-GPOS-00154, SRG-OS-000480-GPOS-00227
anssiR28

Rule   Add nodev Option to Non-Root Local Partitions   [ref]

The nodev mount option prevents files from being interpreted as character or block devices. Legitimate character and block devices should exist only in the /dev directory on the root partition or within chroot jails built for system services. Add the nodev option to the list of Options in the systemd.mount unit that controls mounting of any non-root local partitions.
Rationale:
The nodev mount option prevents files from being interpreted as character or block devices. The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails, for which it is not advised to set nodev on these filesystems.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_mount_option_nodev_nonroot_local_partitions
References:
cis-csc11, 14, 3, 9
cobit5BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06
disaCCI-000366
isa-62443-20094.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-2013SR 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-2013A.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
nerc-cipCIP-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
nistCM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
nist-csfPR.IP-1, PR.PT-3
os-srgSRG-OS-000368-GPOS-00154, SRG-OS-000480-GPOS-00227
anssiR28

Rule   Add noexec Option to /tmp   [ref]

The noexec mount option can be used to prevent binaries from being executed out of /tmp. Add the noexec option to the list of Options in the systemd.mount unit that controls mounting of /tmp.
Rationale:
Allowing users to execute binaries from world-writable directories such as /tmp should never be necessary in normal operation and can expose the system to potential compromise.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_mount_option_tmp_noexec
References:
cis-csc11, 13, 14, 3, 8, 9
cobit5APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS05.06, DSS06.06
disaCCI-001764
isa-62443-20094.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-2013SR 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-2013A.11.2.9, 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.8.2.1, A.8.2.2, A.8.2.3, A.8.3.1, A.8.3.3, A.9.1.2
nerc-cipCIP-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
nistCM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
nist-csfPR.IP-1, PR.PT-2, PR.PT-3
os-srgSRG-OS-000368-GPOS-00154
anssiR28

Rule   Add nosuid Option to /tmp   [ref]

The nosuid mount option can be used to prevent execution of setuid programs in /tmp. The SUID and SGID permissions should not be required in these world-writable directories. Add the nosuid option to the list of Options in the systemd.mount unit that controls mounting of /tmp.
Rationale:
The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from temporary storage partitions.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_mount_option_tmp_nosuid
References:
cis-csc11, 13, 14, 3, 8, 9
cobit5APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS05.06, DSS06.06
disaCCI-001764
isa-62443-20094.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-2013SR 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-2013A.11.2.9, 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.8.2.1, A.8.2.2, A.8.2.3, A.8.3.1, A.8.3.3, A.9.1.2
nerc-cipCIP-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
nistCM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
nist-csfPR.IP-1, PR.PT-2, PR.PT-3
os-srgSRG-OS-000368-GPOS-00154
anssiR28

Rule   Add noexec Option to /var/log   [ref]

The noexec mount option can be used to prevent binaries from being executed out of /var/log. Add the noexec option to the list of Options in the systemd.mount unit that controls mounting of /var/log.
Rationale:
Allowing users to execute binaries from directories containing log files such as /var/log should never be necessary in normal operation and can expose the system to potential compromise.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_mount_option_var_log_noexec
References:
disaCCI-001764
nerc-cipCIP-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
nistCM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
nist-csfPR.IP-1, PR.PT-2, PR.PT-3
os-srgSRG-OS-000368-GPOS-00154
anssiR28

Rule   Add nosuid Option to /var/log   [ref]

The nosuid mount option can be used to prevent execution of setuid programs in /var/log. The SUID and SGID permissions should not be required in directories containing log files. Add the nosuid option to the list of Options in the systemd.mount unit that controls mounting of /var/log.
Rationale:
The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from partitions designated for log files.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_mount_option_var_log_nosuid
References:
disaCCI-001764
nerc-cipCIP-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
nistCM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7
nist-csfPR.IP-1, PR.PT-2, PR.PT-3
os-srgSRG-OS-000368-GPOS-00154
anssiR28

Rule   Add nosuid Option to /var   [ref]

The nosuid mount option can be used to prevent execution of setuid programs in /var. The SUID and SGID permissions should not be required for this directory. Add the nosuid option to the list of Options in the systemd.mount unit that controls mounting of /var.
Rationale:
The presence of SUID and SGID executables should be tightly controlled.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_mount_option_var_nosuid
References:
anssiR28

Rule   Add noexec Option to /var/tmp   [ref]

The noexec mount option can be used to prevent binaries from being executed out of /var/tmp. Add the noexec option to the list of Options in the systemd.mount unit that controls mounting of /var/tmp.
Rationale:
Allowing users to execute binaries from world-writable directories such as /var/tmp should never be necessary in normal operation and can expose the system to potential compromise.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_mount_option_var_tmp_noexec
Identifiers:

CCE-82866-5

References:
disaCCI-001764
os-srgSRG-OS-000368-GPOS-00154
anssiR28

Rule   Add nosuid Option to /var/tmp   [ref]

The nosuid mount option can be used to prevent execution of setuid programs in /var/tmp. The SUID and SGID permissions should not be required in these world-writable directories. Add the nosuid option to the list of Options in the systemd.mount unit that controls mounting of /var/tmp.
Rationale:
The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from temporary storage partitions.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_mount_option_var_tmp_nosuid
Identifiers:

CCE-82736-0

References:
disaCCI-001764
os-srgSRG-OS-000368-GPOS-00154
anssiR28
Group   Restrict Programs from Dangerous Execution Patterns   Group contains 2 groups and 9 rules
[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   Disable Core Dumps   Group contains 1 rule
[ref]   A core dump file is the memory image of an executable program when it was terminated by the operating system due to errant behavior. In most cases, only software developers legitimately need to access these files. The core dump files may also contain sensitive information, or unnecessarily occupy large amounts of disk space.

Once a hard limit is set in /etc/security/limits.conf, or to a file within the /etc/security/limits.d/ directory, a user cannot increase that limit within his or her own session. If access to core dumps is required, consider restricting them to only certain users or groups. See the limits.conf man page for more information.

The core dumps of setuid programs are further protected. The sysctl variable fs.suid_dumpable controls whether the kernel allows core dumps from these programs at all. The default value of 0 is recommended.

Rule   Disable Core Dumps for SUID programs   [ref]

To set the runtime status of the fs.suid_dumpable kernel parameter, run the following command:
$ sudo sysctl -w fs.suid_dumpable=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:
fs.suid_dumpable = 0
Rationale:
The core dump of a setuid program is more likely to contain sensitive data, as the program itself runs with greater privileges than the user who initiated execution of the program. Disabling the ability for any setuid program to write a core file decreases the risk of unauthorized access of such data.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_fs_suid_dumpable
References:
hipaa164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e)
nistSI-11(a), SI-11(b)
anssiR14
pcidss43.3.1.1
Group   Enable ExecShield   Group contains 2 rules
[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.

Rule   Restrict Exposed Kernel Pointer Addresses Access   [ref]

To set the runtime status of the kernel.kptr_restrict kernel parameter, run the following command:
$ sudo sysctl -w kernel.kptr_restrict=2
         
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:
kernel.kptr_restrict = 2
         
Rationale:
Exposing kernel pointers (through procfs or seq_printf()) exposes kernel writeable structures which may contain functions pointers. If a write vulnerability occurs in the kernel, allowing write access to any of this structure, the kernel can be compromised. This option disallow any program without the CAP_SYSLOG capability to get the addresses of kernel pointers by replacing them with 0.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_kernel_kptr_restrict
Identifiers:

CCE-82498-7

References:
disaCCI-002824, CCI-000366
nerc-cipCIP-002-5 R1.1, CIP-002-5 R1.2, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 4.1, CIP-004-6 4.2, CIP-004-6 R2.2.3, CIP-004-6 R2.2.4, CIP-004-6 R2.3, CIP-004-6 R4, CIP-005-6 R1, CIP-005-6 R1.1, CIP-005-6 R1.2, CIP-007-3 R3, CIP-007-3 R3.1, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3, CIP-007-3 R8.4, CIP-009-6 R.1.1, CIP-009-6 R4
nistSC-30, SC-30(2), SC-30(5), CM-6(a)
os-srgSRG-OS-000132-GPOS-00067, SRG-OS-000433-GPOS-00192, SRG-OS-000480-GPOS-00227
anssiR9

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,kernel.kptr_restrict%3D1%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_kernel_kptr_restrict.conf
        overwrite: true

Rule   Enable Randomized Layout of Virtual Address Space   [ref]

To set the runtime status of the kernel.randomize_va_space kernel parameter, run the following command:
$ sudo sysctl -w kernel.randomize_va_space=2
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:
kernel.randomize_va_space = 2
Rationale:
Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code they have introduced into a process's address space during an attempt at exploitation. Additionally, ASLR makes it more difficult for an attacker to know the location of existing code in order to re-purpose it using return oriented programming (ROP) techniques.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_kernel_randomize_va_space
Identifiers:

CCE-88128-4

References:
cui3.1.7
disaCCI-000366, CCI-002824
hipaa164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e)
nerc-cipCIP-002-5 R1.1, CIP-002-5 R1.2, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 4.1, CIP-004-6 4.2, CIP-004-6 R2.2.3, CIP-004-6 R2.2.4, CIP-004-6 R2.3, CIP-004-6 R4, CIP-005-6 R1, CIP-005-6 R1.1, CIP-005-6 R1.2, CIP-007-3 R3, CIP-007-3 R3.1, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3, CIP-007-3 R8.4, CIP-009-6 R.1.1, CIP-009-6 R4
nistSC-30, SC-30(2), CM-6(a)
pcidssReq-2.2.1
os-srgSRG-OS-000433-GPOS-00193, SRG-OS-000480-GPOS-00227
app-srg-ctrSRG-APP-000450-CTR-001105, CNTR-OS-000810, CNTR-OS-000860, CNTR-OS-000870
anssiR9
pcidss43.3.1.1

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,kernel.randomize_va_space%3D2%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_kernel_randomize_va_space.conf
        overwrite: true

Rule   Restrict Access to Kernel Message Buffer   [ref]

To set the runtime status of the kernel.dmesg_restrict kernel parameter, run the following command:
$ sudo sysctl -w kernel.dmesg_restrict=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:
kernel.dmesg_restrict = 1
Rationale:
Unprivileged access to the kernel syslog can expose sensitive kernel address information.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_kernel_dmesg_restrict
Identifiers:

CCE-82499-5

References:
cui3.1.5
disaCCI-001090, CCI-001314
hipaa164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e)
nistSI-11(a), SI-11(b)
os-srgSRG-OS-000132-GPOS-00067, SRG-OS-000138-GPOS-00069
app-srg-ctrSRG-APP-000243-CTR-000600, CNTR-OS-000560, CNTR-OS-000570, CNTR-OS-000580, CNTR-OS-000590, CNTR-OS-000600, CNTR-OS-000610
anssiR9

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,kernel.dmesg_restrict%3D1%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_kernel_dmesg_restrict.conf
        overwrite: true

Rule   Kernel panic on oops   [ref]

To set the runtime status of the kernel.panic_on_oops kernel parameter, run the following command:
$ sudo sysctl -w kernel.panic_on_oops=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:
kernel.panic_on_oops = 1
Warning:  The system may start to panic when it normally wouldn't. A non-catastrophic error that would have allowed the system to continue operating will now result in a panic.
Rationale:
An attacker trying to exploit the kernel may trigger kernel OOPSes, panicking the system will impede them from continuing.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_kernel_panic_on_oops
References:
anssiR9

Rule   Disallow kernel profiling by unprivileged users   [ref]

To set the runtime status of the kernel.perf_event_paranoid kernel parameter, run the following command:
$ sudo sysctl -w kernel.perf_event_paranoid=2
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:
kernel.perf_event_paranoid = 2
Rationale:
Kernel profiling can reveal sensitive information about kernel behaviour.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_kernel_perf_event_paranoid
Identifiers:

CCE-82502-6

References:
disaCCI-001090
nistAC-6
osppFMT_SMF_EXT.1
os-srgSRG-OS-000132-GPOS-00067, SRG-OS-000138-GPOS-00069
app-srg-ctrSRG-APP-000243-CTR-000600, CNTR-OS-000560, CNTR-OS-000570, CNTR-OS-000580, CNTR-OS-000590, CNTR-OS-000600, CNTR-OS-000610
anssiR9

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,kernel.perf_event_paranoid%3D2%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_kernel_perf_event_paranoid.conf
        overwrite: true

Rule   Disable Access to Network bpf() Syscall From Unprivileged Processes   [ref]

To set the runtime status of the kernel.unprivileged_bpf_disabled kernel parameter, run the following command:
$ sudo sysctl -w kernel.unprivileged_bpf_disabled=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:
kernel.unprivileged_bpf_disabled = 1
Rationale:
Loading and accessing the packet filters programs and maps using the bpf() syscall has the potential of revealing sensitive information about the kernel state.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_kernel_unprivileged_bpf_disabled
Identifiers:

CCE-82504-2

References:
disaCCI-000366
nistAC-6, SC-7(10)
osppFMT_SMF_EXT.1
os-srgSRG-OS-000132-GPOS-00067, SRG-OS-000480-GPOS-00227
anssiR9

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,kernel.unprivileged_bpf_disabled%3D1%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_kernel_unprivileged_bpf_disabled.conf
        overwrite: true

Rule   Restrict usage of ptrace to descendant processes   [ref]

To set the runtime status of the kernel.yama.ptrace_scope kernel parameter, run the following command:
$ sudo sysctl -w kernel.yama.ptrace_scope=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:
kernel.yama.ptrace_scope = 1
Rationale:
Unrestricted usage of ptrace allows compromised binaries to run ptrace on another processes of the user. Like this, the attacker can steal sensitive information from the target processes (e.g. SSH sessions, web browser, ...) without any additional assistance from the user (i.e. without resorting to phishing).
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_kernel_yama_ptrace_scope
Identifiers:

CCE-82501-8

References:
disaCCI-000366
nistSC-7(10)
os-srgSRG-OS-000132-GPOS-00067, SRG-OS-000480-GPOS-00227
anssiR11

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,kernel.yama.ptrace_scope%3D1%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_kernel_yama_ptrace_scope.conf
        overwrite: true

Rule   Harden the operation of the BPF just-in-time compiler   [ref]

To set the runtime status of the net.core.bpf_jit_harden kernel parameter, run the following command:
$ sudo sysctl -w net.core.bpf_jit_harden=2
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d:
net.core.bpf_jit_harden = 2
Rationale:
When hardened, the extended Berkeley Packet Filter just-in-time compiler will randomize any kernel addresses in the BPF programs and maps, and will not expose the JIT addresses in /proc/kallsyms.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_sysctl_net_core_bpf_jit_harden
Identifiers:

CCE-82505-9

References:
disaCCI-000366
nistCM-6, SC-7(10)
osppFMT_SMF_EXT.1
os-srgSRG-OS-000480-GPOS-00227
anssiR12

---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
spec:
  config:
    ignition:
      version: 3.1.0
    storage:
      files:
      - contents:
          source: data:,net.core.bpf_jit_harden%3D2%0A
        mode: 0644
        path: /etc/sysctl.d/75-sysctl_net_core_bpf_jit_harden.conf
        overwrite: true
Group   SELinux   Group contains 10 rules
[ref]   SELinux is a feature of the Linux kernel which can be used to guard against misconfigured or compromised programs. SELinux enforces the idea that programs should be limited in what files they can access and what actions they can take.

The default SELinux policy, as configured on Red Hat Enterprise Linux CoreOS 4, has been sufficiently developed and debugged that it should be usable on almost any system with minimal configuration and a small amount of system administrator training. This policy prevents system services - including most of the common network-visible services such as mail servers, FTP servers, and DNS servers - from accessing files which those services have no valid reason to access. This action alone prevents a huge amount of possible damage from network attacks against services, from trojaned software, and so forth.

This guide recommends that SELinux be enabled using the default (targeted) policy on every Red Hat Enterprise Linux CoreOS 4 system, unless that system has unusual requirements which make a stronger policy appropriate.

Rule   Uninstall setroubleshoot-plugins Package   [ref]

The SETroubleshoot plugins are used to analyze SELinux AVC data. The service provides information around configuration errors, unauthorized intrusions, and other potential errors. The setroubleshoot-plugins package can be removed with the following command:
$ sudo dnf erase setroubleshoot-plugins
Rationale:
The SETroubleshoot service is an unnecessary daemon to have running on a server.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_package_setroubleshoot-plugins_removed
Identifiers:

CCE-84091-8

References:
anssiR49

Rule   Uninstall setroubleshoot-server Package   [ref]

The SETroubleshoot service notifies desktop users of SELinux denials. The service provides information around configuration errors, unauthorized intrusions, and other potential errors. The setroubleshoot-server package can be removed with the following command:
$ sudo dnf erase setroubleshoot-server
Rationale:
The SETroubleshoot service is an unnecessary daemon to have running on a server.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_package_setroubleshoot-server_removed
Identifiers:

CCE-84093-4

References:
anssiR49

Rule   Verify Group Who Owns /etc/selinux Directory   [ref]

To properly set the group owner of /etc/selinux, run the command:
$ sudo chgrp root /etc/selinux
Rationale:
The ownership of the /etc/selinux directory by the root group is important because this directory hosts SELinux configuration. Protection of this directory is critical for system security. Assigning the ownership to root ensures exclusive control of the SELinux configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_groupowner_etc_selinux
References:
anssiR50

Rule   Verify User Who Owns /etc/selinux Directory   [ref]

To properly set the owner of /etc/selinux, run the command:
$ sudo chown root /etc/selinux 
Rationale:
The ownership of the /etc/selinux directory by the root user is important because this directory hosts SELinux configuration. Protection of this directory is critical for system security. Assigning the ownership to root ensures exclusive control of the SELinux configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_owner_etc_selinux
References:
anssiR50

Rule   Verify Permissions On /etc/selinux Directory   [ref]

To properly set the permissions of /etc/selinux, run the command:
$ sudo chmod 0755 /etc/selinux
Rationale:
Setting correct permissions on the /etc/selinux directory is important because this directory hosts SELinux configuration. Protection of this directory is critical for system security. Restricting the permissions ensures exclusive control of the SELinux configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_directory_permissions_etc_selinux
References:
anssiR50

Rule   Verify Group Who Owns /etc/sestatus.conf File   [ref]

To properly set the group owner of /etc/sestatus.conf, run the command:
$ sudo chgrp root /etc/sestatus.conf
Rationale:
The ownership of the /etc/sestatus.conf file by the root group is important because this file hosts SELinux configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the SELinux configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_etc_sestatus_conf
References:
anssiR50

Rule   Verify User Who Owns /etc/sestatus.conf File   [ref]

To properly set the owner of /etc/sestatus.conf, run the command:
$ sudo chown root /etc/sestatus.conf 
Rationale:
The ownership of the /etc/sestatus.conf file by the root user is important because this file hosts SELinux configuration. Protection of this file is critical for system security. Assigning the ownership to root ensures exclusive control of the SELinux configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_owner_etc_sestatus_conf
References:
anssiR50

Rule   Verify Permissions On /etc/sestatus.conf File   [ref]

To properly set the permissions of /etc/sestatus.conf, run the command:
$ sudo chmod 0644 /etc/sestatus.conf
Rationale:
Setting correct permissions on the /etc/sestatus.conf file is important because this file hosts SELinux configuration. Protection of this file is critical for system security. Restricting the permissions ensures exclusive control of the SELinux configuration.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_permissions_etc_sestatus_conf
References:
anssiR50

Rule   Configure SELinux Policy   [ref]

The SELinux targeted policy is appropriate for general-purpose desktops and servers, as well as systems in many other roles. To configure the system to use this policy, add or correct the following line in /etc/selinux/config:
SELINUXTYPE=targeted
       
Other policies, such as mls, provide additional security labeling and greater confinement but are not compatible with many general-purpose use cases.
Rationale:
Setting the SELinux policy to targeted or a more specialized policy ensures the system will confine processes that are likely to be targeted for exploitation, such as network or system services.

Note: During the development or debugging of SELinux modules, it is common to temporarily place non-production systems in permissive mode. In such temporary cases, SELinux policies should be developed, and once work is completed, the system should be reconfigured to targeted.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_selinux_policytype
Identifiers:

CCE-82532-3

References:
bsiAPP.4.4.A4
cis-csc1, 11, 12, 13, 14, 15, 16, 18, 3, 4, 5, 6, 8, 9
cobit5APO01.06, APO11.04, APO13.01, BAI03.05, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.03, DSS06.06, MEA02.01
cui3.1.2, 3.7.2
disaCCI-002165, CCI-002696
hipaa164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e)
isa-62443-20094.2.3.4, 4.3.3.2.2, 4.3.3.3.9, 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.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, 4.4.3.3
isa-62443-2013SR 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.10, SR 2.11, SR 2.12, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6
iso27001-2013A.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.2, A.12.4.3, A.12.4.4, A.12.7.1, 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.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5
nerc-cipCIP-003-8 R5.1.1, CIP-003-8 R5.2, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-004-6 R3.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, CIP-007-3 R6.5
nistAC-3, AC-3(3)(a), AU-9, SC-7(21)
nist-csfDE.AE-1, ID.AM-3, PR.AC-4, PR.AC-5, PR.AC-6, PR.DS-5, PR.PT-1, PR.PT-3, PR.PT-4
os-srgSRG-OS-000445-GPOS-00199
app-srg-ctrSRG-APP-000233-CTR-000585, CNTR-OS-000540
anssiR46, R64
pcidss41.2.6

Rule   Ensure SELinux State is Enforcing   [ref]

The SELinux state should be set to enforcing at system boot time. In the file /etc/selinux/config, add or correct the following line to configure the system to boot into enforcing mode:
SELINUX=enforcing
       
Rationale:
Setting the SELinux state to enforcing ensures SELinux is able to confine potentially compromised processes to the security policy, which is designed to prevent them from causing damage to the system or further elevating their privileges.
Severity: 
high
Rule ID:xccdf_org.ssgproject.content_rule_selinux_state
Identifiers:

CCE-82531-5

References:
bsiAPP.4.4.A4
cis-csc1, 11, 12, 13, 14, 15, 16, 18, 3, 4, 5, 6, 8, 9
cobit5APO01.06, APO11.04, APO13.01, BAI03.05, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.03, DSS06.06, MEA02.01
cui3.1.2, 3.7.2
disaCCI-001084, CCI-002165, CCI-002696
hipaa164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e)
isa-62443-20094.2.3.4, 4.3.3.2.2, 4.3.3.3.9, 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.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, 4.4.3.3
isa-62443-2013SR 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.10, SR 2.11, SR 2.12, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6
iso27001-2013A.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.2, A.12.4.3, A.12.4.4, A.12.7.1, 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.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5
nerc-cipCIP-003-8 R5.1.1, CIP-003-8 R5.2, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-004-6 R3.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, CIP-007-3 R6.5
nistAC-3, AC-3(3)(a), AU-9, SC-7(21)
nist-csfDE.AE-1, ID.AM-3, PR.AC-4, PR.AC-5, PR.AC-6, PR.DS-5, PR.PT-1, PR.PT-3, PR.PT-4
os-srgSRG-OS-000445-GPOS-00199, SRG-OS-000134-GPOS-00068
anssiR37, R79
pcidss41.2.6
app-srg-ctrCNTR-OS-000540
Group   Services   Group contains 5 groups and 18 rules
[ref]   The best protection against vulnerable software is running less software. This section describes how to review the software which Red Hat Enterprise Linux CoreOS 4 installs on a system and disable software which is not needed. It then enumerates the software packages installed on a default Red Hat Enterprise Linux CoreOS 4 system and provides guidance about which ones can be safely disabled.

Red Hat Enterprise Linux CoreOS 4 provides a convenient minimal install option that essentially installs the bare necessities for a functional system. When building Red Hat Enterprise Linux CoreOS 4 systems, it is highly recommended to select the minimal packages and then build up the system from there.
Group   Mail Server Software   Group contains 1 group and 2 rules
[ref]   Mail servers are used to send and receive email over the network. Mail is a very common service, and Mail Transfer Agents (MTAs) are obvious targets of network attack. Ensure that systems are not running MTAs unnecessarily, and configure needed MTAs as defensively as possible.

Very few systems at any site should be configured to directly receive email over the network. Users should instead use mail client programs to retrieve email from a central server that supports protocols such as IMAP or POP3. However, it is normal for most systems to be independently capable of sending email, for instance so that cron jobs can report output to an administrator. Most MTAs, including Postfix, support a submission-only mode in which mail can be sent from the local system to a central site MTA (or directly delivered to a local account), but the system still cannot receive mail directly over a network.

The alternatives program in Red Hat Enterprise Linux CoreOS 4 permits selection of other mail server software (such as Sendmail), but Postfix is the default and is preferred. Postfix was coded with security in mind and can also be more effectively contained by SELinux as its modular design has resulted in separate processes performing specific actions. More information is available on its website, http://www.postfix.org.
Group   Configure SMTP For Mail Clients   Group contains 1 rule
[ref]   This section discusses settings for Postfix in a submission-only e-mail configuration.

Rule   Configure System to Forward All Mail For The Root Account   [ref]

Make sure that mails delivered to root user are forwarded to a monitored email address. Make sure that the address change_me@localhost is a valid email address reachable from the system in question. Use the following command to configure the alias:
$ sudo echo "root: change_me@localhost" >> /etc/aliases
$ sudo newaliases
Rationale:
A number of system services utilize email messages sent to the root user to notify system administrators of active or impending issues. These messages must be forwarded to at least one monitored email address.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_postfix_client_configure_mail_alias
References:
disaCCI-000139, CCI-000366
nistCM-6(a)
os-srgSRG-OS-000046-GPOS-00022
anssiR75

Rule   Uninstall Sendmail Package   [ref]

Sendmail is not the default mail transfer agent and is not installed by default. The sendmail package can be removed with the following command:
$ sudo dnf erase sendmail
Rationale:
The sendmail software was not developed with security in mind and its design prevents it from being effectively contained by SELinux. Postfix should be used instead.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_package_sendmail_removed
References:
cis-csc11, 14, 3, 9