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.73

  • draft (as of 2024-04-18)

Table of Contents

  1. System Settings
    1. Installing and Maintaining Software
    2. Account and Access Control
    3. GRUB2 bootloader configuration
    4. Kernel Configuration
    5. Configure Syslog
    6. Network Configuration and Firewalls
    7. File Permissions and Masks
    8. 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 60 groups and 279 rules
Group   System Settings   Group contains 44 groups and 213 rules
[ref]   Contains rules that check correct system settings.
Group   Installing and Maintaining Software   Group contains 7 groups and 25 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
Identifiers and References

References:  1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9, 5.10.1.3, APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06, CCI-002696, CCI-002699, CCI-001744, 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6, 1034, 1288, 1341, 1417, A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3, CM-6(a), DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3, Req-11.5, SRG-OS-000445-GPOS-00199, R76, R79, 11.5.2

Rule   Build and Test AIDE Database   [ref]

Run the following command to generate a new database:
$ sudo /usr/sbin/aide --init
By default, the database will be written to the file /var/lib/aide/aide.db.new.gz. Storing the database, the configuration file /etc/aide.conf, and the binary /usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity. The newly-generated database can be installed as follows:
$ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
To initiate a manual check, run the following command:
$ sudo /usr/sbin/aide --check
If this check produces any unexpected output, investigate.
Rationale:
For AIDE to be effective, an initial database of "known-good" information about files must be captured and it should be able to be verified against the installed files.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_aide_build_database
Identifiers and References

References:  1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9, 5.10.1.3, APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06, 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6, A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3, CM-6(a), DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3, Req-11.5, SRG-OS-000445-GPOS-00199, R76, R79, 11.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
Identifiers and References

References:  12, 15, 8, 5.10.1.2, APO13.01, DSS01.04, DSS05.02, DSS05.03, 3.13.11, 3.13.8, CCI-000068, CCI-000803, CCI-002450, 4.3.3.6.6, SR 1.13, SR 2.6, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, A.11.2.6, A.13.1.1, A.13.2.1, A.14.1.3, A.6.2.1, A.6.2.2, CIP-003-8 R4.2, CIP-007-3 R5.1, SC-12(2), SC-12(3), IA-7, SC-13, CM-6(a), SC-12, PR.AC-3, PR.PT-4, SRG-OS-000033-GPOS-00014, SRG-OS-000396-GPOS-00176, SRG-OS-000478-GPOS-00223, R1

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 and References

Identifiers:  CCE-82739-4

References:  12, 15, 8, APO13.01, DSS05.02, CCI-000366, CCI-001208, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, A.13.1.1, A.13.2.1, A.14.1.3, CM-6(a), SC-5(2), PR.PT-4, SRG-OS-000480-GPOS-00227, R28

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
Identifiers and References

References:  R28

Rule   Ensure /var Located On Separate Partition   [ref]

The /var directory is used by daemons and other system services to store frequently-changing data. Ensure that /var has its own partition or logical volume at installation time, or migrate it using LVM.
Rationale:
Ensuring that /var is mounted on its own partition enables the setting of more restrictive mount options. This helps protect system services such as daemons or other programs which use it. It is not uncommon for the /var directory to contain world-writable directories installed by other software packages.
Severity: 
low
Rule ID:xccdf_org.ssgproject.content_rule_partition_for_var
Identifiers and References

References:  12, 15, 8, APO13.01, DSS05.02, CCI-000366, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, A.13.1.1, A.13.2.1, A.14.1.3, CM-6(a), SC-5(2), PR.PT-4, SRG-OS-000480-GPOS-00227, R28

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 and References

Identifiers:  CCE-82737-8

References:  1, 12, 14, 15, 16, 3, 5, 6, 8, APO11.04, APO13.01, BAI03.05, DSS05.02, DSS05.04, DSS05.07, MEA02.01, CCI-000366, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, 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, CIP-007-3 R6.5, CM-6(a), AU-4, SC-5(2), PR.PT-1, PR.PT-4, SRG-OS-000480-GPOS-00227, R28

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 and References

Identifiers:  CCE-82738-6

References:  1, 12, 13, 14, 15, 16, 2, 3, 5, 6, 8, APO11.04, APO13.01, BAI03.05, BAI04.04, DSS05.02, DSS05.04, DSS05.07, MEA02.01, CCI-000366, CCI-001849, 164.312(a)(2)(ii), 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.2, SR 7.6, A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.17.2.1, CIP-007-3 R6.5, CM-6(a), AU-4, SC-5(2), PR.DS-4, PR.PT-1, PR.PT-4, FMT_SMF_EXT.1, SRG-OS-000341-GPOS-00132, SRG-OS-000480-GPOS-00227, SRG-APP-000357-CTR-000800, R71, CNTR-OS-000200, CNTR-OS-000670

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 and References

Identifiers:  CCE-82734-5

References:  SRG-OS-000480-GPOS-00227, R28

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
Identifiers and References

References:  R28

Group   Sudo   Group contains 13 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 and References

Identifiers:  CCE-82523-2

References:  1382, 1384, 1386, CM-6(a), FMT_MOF_EXT.1, SRG-OS-000324-GPOS-00125, R33, 2.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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R39

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
Identifiers and References

References:  R39

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
Identifiers and References

References:  Req-10.2.5, R39, 2.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
Identifiers and References

References:  R43

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
Identifiers and References

References:  R42

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
Identifiers and References

References:  R40

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 and References

Identifiers:  CCE-82754-3

References:  11, 2, 3, 9, 5.10.4.1, APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02, 3.4.8, CCI-001749, 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i), 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6, A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, CIP-003-8 R4.2, CIP-003-8 R6, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1, CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), PR.DS-6, PR.DS-8, PR.IP-1, FPT_TUD_EXT.1, FPT_TUD_EXT.2, Req-6.2, SRG-OS-000366-GPOS-00153, R59, 6.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
Identifiers and References

References:  R1

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
Identifiers and References

References:  1, 12, 15, 16, 5, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000195, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, SRG-OS-000072-GPOS-00040, R68

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

To configure the number of retry prompts that are permitted per-session: Edit the pam_pwquality.so statement in /etc/pam.d/system-auth to show retry=3 , or a lower value if site policy is more restrictive. The DoD requirement is a maximum of 3 prompts per session.
Rationale:
Setting the password retry prompts that are permitted on a per-session basis to a low value requires some software, such as SSH, to re-connect. This can slow down and draw additional attention to some types of password-guessing attacks. Note that this is different from account lockout, which is provided by the pam_faillock module.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_accounts_password_pam_retry
Identifiers and References

References:  1, 11, 12, 15, 16, 3, 5, 9, 5.5.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, CCI-000192, CCI-000366, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 7.6, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, CM-6(a), AC-7(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, PR.IP-1, FMT_MOF_EXT.1, SRG-OS-000069-GPOS-00037, SRG-OS-000480-GPOS-00227, R68

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
Identifiers and References

References:  1, 12, 13, 14, 15, 16, 18, 3, 5, 7, 8, 5.5.6, APO13.01, BAI03.01, BAI03.02, BAI03.03, DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, 3.1.11, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.3, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 6.2, A.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, CIP-004-6 R2.2.3, CIP-007-3 R5.1, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, CM-6(a), AC-17(a), AC-2(5), AC-12, AC-17(a), SC-10, CM-6(a), DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.IP-2, FMT_SMF_EXT.1.1, Req-8.1.8, SRG-OS-000163-GPOS-00072, R32

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
Identifiers and References

References:  R31

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 and References

Identifiers:  CCE-82698-2

References:  1, 12, 15, 16, 5, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, 3.1.1, 3.1.6, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, IA-2, CM-6(a), PR.AC-1, PR.AC-6, PR.AC-7, R33, 8.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 and References

Identifiers:  CCE-84260-9

References:  18, APO13.01, BAI03.01, BAI03.02, BAI03.03, CCI-000366, 4.3.4.3.3, A.14.1.1, A.14.2.1, A.14.2.5, A.6.1.5, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2, AC-6(1), CM-6(a), PR.IP-2, SRG-OS-000480-GPOS-00228, SRG-OS-000480-GPOS-00227, R36


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 and References

Identifiers:  CCE-84262-5

References:  18, APO13.01, BAI03.01, BAI03.02, BAI03.03, CCI-000366, 4.3.4.3.3, A.14.1.1, A.14.2.1, A.14.2.5, A.6.1.5, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2, AC-6(1), CM-6(a), PR.IP-2, SRG-OS-000480-GPOS-00228, SRG-OS-000480-GPOS-00227, R36


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
Identifiers and References

References:  R55

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
Identifiers and References

References:  R55

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
Identifiers and References

References:  1, 12, 15, 16, DSS05.04, DSS05.10, DSS06.10, 3.1.11, CCI-000057, CCI-001133, CCI-002361, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, CIP-004-6 R2.2.3, CIP-007-3 R5.1, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, AC-12, SC-10, AC-2(5), CM-6(a), PR.AC-7, FMT_MOF_EXT.1, SRG-OS-000163-GPOS-00072, SRG-OS-000029-GPOS-00010, R32, 8.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
Identifiers and References

References:  CCI-000366, SRG-OS-000480-GPOS-00227, R50

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
Identifiers and References

References:  CCI-000366, SRG-OS-000480-GPOS-00227, R50

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
Identifiers and References

References:  CCI-000366, SRG-OS-000480-GPOS-00227, R50

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
Identifiers and References

References:  CCI-000366, SRG-OS-000480-GPOS-00227, R50

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
Identifiers and References

References:  CCI-000366, SRG-OS-000480-GPOS-00227, R50

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
Identifiers and References

References:  CCI-000366, SRG-OS-000480-GPOS-00227, R50

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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, 5.5.2.2, APO01.06, DSS05.04, DSS05.07, DSS06.02, 3.4.5, CCI-000225, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-7.1, SRG-OS-000480-GPOS-00227, R29, 2.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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, 5.5.2.2, APO01.06, DSS05.04, DSS05.07, DSS06.02, 3.4.5, CCI-000225, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-7.1, SRG-OS-000480-GPOS-00227, R29, 2.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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, 5.5.2.2, APO01.06, DSS05.04, DSS05.07, DSS06.02, 3.4.5, CCI-000225, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-7.1, SRG-OS-000480-GPOS-00227, R29, 2.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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, 5.5.2.2, APO01.06, DSS05.04, DSS05.07, DSS06.02, 3.4.5, CCI-000225, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-7.1, R29, 2.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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, APO01.06, DSS05.04, DSS05.07, DSS06.02, 3.4.5, CCI-000225, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, R29, 2.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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, APO01.06, DSS05.04, DSS05.07, DSS06.02, 3.4.5, CCI-000225, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, R29, 2.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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, 5.5.2.2, APO01.06, DSS05.04, DSS05.07, DSS06.02, 3.4.5, CCI-000225, 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-7.1, R29

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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, 5.5.2.2, APO01.06, DSS05.04, DSS05.07, DSS06.02, 3.4.5, CCI-000225, 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-7.1, R29

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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, 5.5.2.2, APO01.06, DSS05.04, DSS05.07, DSS06.02, 3.4.5, CCI-000225, 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-7.1, R29

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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, 5.5.2.2, APO01.06, DSS05.04, DSS05.07, DSS06.02, 3.4.5, CCI-000225, 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-7.1, R29

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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, APO01.06, DSS05.04, DSS05.07, DSS06.02, 3.4.5, CCI-000225, 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, R29

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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, APO01.06, DSS05.04, DSS05.07, DSS06.02, 3.4.5, CCI-000225, 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, R29

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 and References

Identifiers:  CCE-82552-1

References:  11, 12, 14, 15, 16, 18, 3, 5, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.03, DSS06.06, 3.4.5, CCI-000213, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), 4.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, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, A.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, CM-6(a), PR.AC-4, PR.AC-6, PR.PT-3, FIA_UAU.1, SRG-OS-000080-GPOS-00048, R5

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
Identifiers and References

References:  R7

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
Identifiers and References

References:  R8

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
Identifiers and References

References:  R8

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
Identifiers and References

References:  R1

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
Identifiers and References

References:  R1

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
Identifiers and References

References:  R8

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
Identifiers and References

References:  R8

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
Identifiers and References

References:  R8

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
Identifiers and References

References:  R8

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
Identifiers and References

References:  R15

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
Identifiers and References

References:  R23

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
Identifiers and References

References:  R19

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
Identifiers and References

References:  R17

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
Identifiers and References

References:  R15

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
Identifiers and References

References:  R16

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
Identifiers and References

References:  R15

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
Identifiers and References

References:  R16

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
Identifiers and References

References:  R16

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
Identifiers and References

References:  R16

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
Identifiers and References

References:  R25, 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
Identifiers and References

References:  R15

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
Identifiers and References

References:  R23

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
Identifiers and References

References:  R25

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
Identifiers and References

References:  R23

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
Identifiers and References

References:  R23

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
Identifiers and References

References:  R18

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
Identifiers and References

References:  R18

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
Identifiers and References

References:  R18

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
Identifiers and References

References:  R18

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
Identifiers and References

References:  R18

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
Identifiers and References

References:  R18

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
Identifiers and References

References:  R17

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
Identifiers and References

References:  R17

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
Identifiers and References

References:  R25

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
Identifiers and References

References:  R19

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
Identifiers and References

References:  R19

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
Identifiers and References

References:  R15

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
Identifiers and References

References:  R25, 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
Identifiers and References

References:  R25

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
Identifiers and References

References:  R15

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
Identifiers and References

References:  R20

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
Identifiers and References

References:  R20

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
Identifiers and References

References:  R20

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
Identifiers and References

References:  R15

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
Identifiers and References

References:  R20

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
Identifiers and References

References:  R20

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
Identifiers and References

References:  R17

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
Identifiers and References

References:  R22

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
Identifiers and References

References:  R27

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
Identifiers and References

References:  R15

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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, APO01.06, DSS05.04, DSS05.07, DSS06.02, CCI-001314, 4.3.3.7.3, SR 2.1, SR 5.2, 0988, 1405, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-003-8 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, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-10.5.1, Req-10.5.2, R71, 10.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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, APO01.06, DSS05.04, DSS05.07, DSS06.02, CCI-001314, 4.3.3.7.3, SR 2.1, SR 5.2, 0988, 1405, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-003-8 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, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-10.5.1, Req-10.5.2, R71, 10.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
Identifiers and References

References:  CCI-001314, 0988, 1405, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2, CM-6(a), AC-6(1), Req-10.5.1, Req-10.5.2, R71, 10.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
Identifiers and References

References:  1, 14, 15, 16, 3, 5, 6, APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01, CCI-000366, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, CM-6(a), PR.PT-1, Req-10.7, R71, 10.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 and References

Identifiers:  CCE-82689-1

References:  1, 14, 15, 16, 3, 5, 6, APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01, CCI-000366, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, CM-6(a), PR.PT-1, Req-10.7, R71


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
Identifiers and References

References:  1, 14, 15, 16, 3, 5, 6, APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01, CCI-000366, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, CM-6(a), PR.PT-1, Req-10.7, R71, 10.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
Identifiers and References

References:  1, 13, 14, 15, 16, 2, 3, 5, 6, APO11.04, APO13.01, BAI03.05, BAI04.04, DSS05.04, DSS05.07, MEA02.01, CCI-000366, CCI-001348, CCI-000136, CCI-001851, 164.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), 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 7.1, SR 7.2, 0988, 1405, A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.17.2.1, CIP-003-8 R5.2, CIP-004-6 R3.3, CM-6(a), AU-4(1), AU-9(2), PR.DS-4, PR.PT-1, FAU_GEN.1.1.c, SRG-OS-000479-GPOS-00224, SRG-OS-000480-GPOS-00227, SRG-OS-000342-GPOS-00133, R71

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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 and References

Identifiers:  CCE-82471-4

References:  11, 14, 3, 9, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, 3.1.20, CCI-000366, CCI-001551, 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, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2, CM-7(a), CM-7(b), CM-6(a), CM-6(b), CM-6.1(iv), PR.IP-1, PR.PT-3, SRG-OS-000480-GPOS-00227, R13


---
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 and References

Identifiers:  CCE-82480-5

References:  1, 12, 13, 14, 15, 16, 18, 4, 6, 8, 9, APO01.06, APO13.01, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.07, DSS06.02, 3.1.20, CCI-000366, 4.2.3.4, 4.3.3.4, 4.4.3.3, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, A.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, CM-7(a), CM-7(b), CM-6(a), DE.AE-1, ID.AM-3, PR.AC-5, PR.DS-5, PR.PT-4, SRG-OS-000480-GPOS-00227, R13


---
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 and References

Identifiers:  CCE-82477-1

References:  11, 14, 3, 9, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, 3.1.20, CCI-000366, CCI-001551, 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, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2, CM-7(a), CM-7(b), CM-6(a), PR.IP-1, PR.PT-3, SRG-OS-000480-GPOS-00227, R13


---
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 and References

Identifiers:  CCE-82481-3

References:  1, 12, 13, 14, 15, 16, 18, 4, 6, 8, 9, APO01.06, APO13.01, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.07, DSS06.02, 3.1.20, CCI-000366, 4.2.3.4, 4.3.3.4, 4.4.3.3, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, A.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, CM-7(a), CM-7(b), CM-6(a), CM-6(b), CM-6.1(iv), DE.AE-1, ID.AM-3, PR.AC-5, PR.DS-5, PR.PT-4, Req-1.4.3, SRG-OS-000480-GPOS-00227, R13, 1.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
Identifiers and References

References:  R12

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 and References

Identifiers:  CCE-82469-8

References:  1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9, 5.10.1.1, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06, 3.1.20, CCI-000366, CCI-001503, CCI-001551, 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, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 6.2, SR 7.1, SR 7.2, SR 7.6, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.9.1.2, CM-7(a), CM-7(b), CM-6(a), SC-7(a), DE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3, SRG-OS-000480-GPOS-00227, R12


---
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 and References

Identifiers:  CCE-82478-9

References:  1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9, APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, 3.1.20, CCI-000366, 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1, CM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000480-GPOS-00227, R12


---
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
Identifiers and References

References:  R12

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
Identifiers and References

References:  R12

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
Identifiers and References

References:  R12

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 and References

Identifiers:  CCE-82488-8

References:  1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9, APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02, 3.1.20, CCI-000366, CCI-001551, 4.2.3.4, 4.3.3.4, 4.4.3.3, 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, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-7(a), CM-7(b), CM-6(a), SC-7(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.PT-4, Req-1.4.3, SRG-OS-000480-GPOS-00227, R12, 1.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 and References

Identifiers:  CCE-82482-1

References:  1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9, APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, 3.1.20, CCI-001503, CCI-001551, 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-7(a), CM-7(b), CM-6(a), SC-7(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4, Req-1.4.3, SRG-OS-000480-GPOS-00227, R12, 1.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
Identifiers and References

References:  R12

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 and References

Identifiers:  CCE-82470-6

References:  1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9, 5.10.1.1, APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, 3.1.20, CCI-000366, CCI-001551, 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-7(a), CM-7(b), CM-6(a), SC-7(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4, Req-1.4.3, SRG-OS-000480-GPOS-00227, R12, 1.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 and References

Identifiers:  CCE-82479-7

References:  1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9, 5.10.1.1, APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, 3.1.20, CCI-000366, CCI-001551, 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1, CM-7(a), CM-7(b), SC-5, SC-7(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000480-GPOS-00227, R12


---
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 and References

Identifiers:  CCE-82489-6

References:  1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9, APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02, 3.1.20, CCI-000366, 4.2.3.4, 4.3.3.4, 4.4.3.3, 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, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-7(a), CM-7(b), CM-6(a), SC-7(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.PT-4, SRG-OS-000480-GPOS-00227, R12


---
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 and References

Identifiers:  CCE-82483-9

References:  1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9, APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, 3.1.20, CCI-001551, 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1, CM-7(a), CM-7(b), SC-5, SC-7(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000480-GPOS-00227, R12


---
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
Identifiers and References

References:  R12

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 and References

Identifiers:  CCE-82490-4

References:  1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06, 3.1.20, 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, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 6.2, SR 7.1, SR 7.2, SR 7.6, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.9.1.2, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1, CM-7(a), CM-7(b), SC-5, DE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3, Req-1.4.3, SRG-OS-000480-GPOS-00227, R12, 1.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 and References

Identifiers:  CCE-82492-0

References:  1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9, 5.10.1.1, APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02, 3.1.20, CCI-000366, CCI-001095, 4.2.3.4, 4.3.3.4, 4.4.3.3, 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, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CM-7(a), CM-7(b), SC-5(1), SC-5(2), SC-5(3)(a), CM-6(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.PT-4, Req-1.4.1, SRG-OS-000480-GPOS-00227, SRG-OS-000420-GPOS-00186, SRG-OS-000142-GPOS-00071, R12, 1.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 and References

Identifiers:  CCE-82484-7

References:  1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9, 5.10.1.1, APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, 3.1.20, CCI-000366, 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1, CM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000480-GPOS-00227, R12, 1.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 and References

Identifiers:  CCE-82485-4

References:  1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9, 5.10.1.1, APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, 3.1.20, CCI-000366, 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1, CM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000480-GPOS-00227, R12, 1.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
Identifiers and References

References:  1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06, 3.1.20, CCI-000366, 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, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.9.1.2, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1, CM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a), DE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3, PR.PT-4, Req-1.3.1, Req-1.3.2, SRG-OS-000480-GPOS-00227, R12, 1.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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  R50

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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, 5.5.2.2, APO01.06, DSS05.04, DSS05.07, DSS06.02, 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-003-8 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, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-8.7.c, SRG-OS-000480-GPOS-00227, R50, 2.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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, APO01.06, DSS05.04, DSS05.07, DSS06.02, 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-003-8 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, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, SRG-OS-000480-GPOS-00227, R50

Rule   Verify Group Who Owns passwd File   [ref]

To properly set the group owner of /etc/passwd, run the command:
$ sudo chgrp root /etc/passwd
Rationale:
The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security.
Severity: 
medium
Rule ID:xccdf_org.ssgproject.content_rule_file_groupowner_etc_passwd
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, 5.5.2.2, APO01.06, DSS05.04, DSS05.07, DSS06.02, 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-003-8 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, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-8.7.c, SRG-OS-000480-GPOS-00227, R50, 2.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
Identifiers and References

References:  12, 13, 14, 15, 16, 18, 3, 5, 5.5.2.2, APO01.06, DSS05.04, DSS05.07, DSS06.02, 4.3.3.7.3, SR 2.1, SR 5.2, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-003-8 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, CM-6(a), AC-6(1),