| Group
Guide to the Secure Configuration of Red Hat Enterprise Linux CoreOS 4
Group contains 50 groups and 151 rules |
| Group
System Settings
Group contains 40 groups and 130 rules |
[ref]
Contains rules that check correct system settings. |
| Group
Installing and Maintaining Software
Group contains 5 groups and 11 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 2 groups and 6 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
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
Enable FIPS Mode
[ref] | To enable FIPS mode, run the following command:
fips-mode-setup --enable
The fips-mode-setup command will configure the system in
FIPS mode by automatically configuring the following:
- Setting the kernel FIPS mode flag (
/proc/sys/crypto/fips_enabled) to 1 - Creating
/etc/system-fips - Setting the system crypto policy in
/etc/crypto-policies/config to FIPS:OSPP - Loading the Dracut
fips module
Warning:
The system needs to be rebooted for these changes to take effect. | | Rationale: | Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to
protect data. The operating system must implement cryptographic modules adhering to the higher
standards approved by the federal government since this provides assurance they have been tested
and validated. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_enable_fips_mode | | Identifiers and References | Identifiers:
CCE-82540-6 References:
CCI-000068, CCI-000803, CCI-002450, 1446, CIP-003-8 R4.2, CIP-007-3 R5.1, CM-3(6), SC-12(2), SC-12(3), IA-7, SC-13, CM-6(a), SC-12, FCS_COP.1(1), FCS_COP.1(2), FCS_COP.1(3), FCS_COP.1(4), FCS_CKM.1, FCS_CKM.2, FCS_TLSC_EXT.1, FCS_RBG_EXT.1, SRG-OS-000478-GPOS-00223, SRG-OS-000396-GPOS-00176, SRG-OS-000120-VMM-000600, SRG-OS-000478-VMM-001980, SRG-OS-000396-VMM-001590 | |
|
| Group
System Cryptographic Policies
Group contains 5 rules |
[ref]
Linux has the capability to centrally configure cryptographic polices. The command
update-crypto-policies is used to set the policy applicable for the various
cryptographic back-ends, such as SSL/TLS libraries. The configured cryptographic
policies will be the default policy used by these backends unless the application
user configures them otherwise. When the system has been configured to use the
centralized cryptographic policies, the administrator is assured that any application
that utilizes the supported backends will follow a policy that adheres to the
configured profile.
Currently the supported backends are:
- GnuTLS library
- OpenSSL library
- NSS library
- OpenJDK
- Libkrb5
- BIND
- OpenSSH
Applications and languages which rely on any of these backends will follow the
system policies as well. Examples are apache httpd, nginx, php, and others. |
Rule
Configure System Cryptography Policy
[ref] | To configure the system cryptography policy to use ciphers only from the FIPS:OSPP
policy, create a MachineConfig as follows:
---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 50-master-configure-crypto-policy
spec:
config:
ignition:
version: 3.1.0
systemd:
units:
- name: configure-crypto-policy.service
enabled: true
contents: |
[Unit]
Before=kubelet.service
[Service]
Type=oneshot
ExecStart=update-crypto-policies --set FIPS:OSPP
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
This will configure the crypto policy appropriately in all the
nodes labeled with the "master" role.
Note that this needs to be done for each MachineConfigPool
For more information on how to configure nodes with the Machine Config
Operator see
the relevant documentation.
The rule checks if settings for selected crypto policy are configured as expected. Configuration files in the /etc/crypto-policies/back-ends are either symlinks to correct files provided by Crypto-policies package or they are regular files in case crypto policy customizations are applied.
Crypto policies may be customized by crypto policy modules, in which case it is delimited from the base policy using a colon. Warning:
The system needs to be rebooted for these changes to take effect. Warning:
System Crypto Modules must be provided by a vendor that undergoes
FIPS-140 certifications.
FIPS-140 is applicable to all Federal agencies that use
cryptographic-based security systems to protect sensitive information
in computer and telecommunication systems (including voice systems) as
defined in Section 5131 of the Information Technology Management Reform
Act of 1996, Public Law 104-106. This standard shall be used in
designing and implementing cryptographic modules that Federal
departments and agencies operate or are operated for them under
contract. See https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf
To meet this, the system has to have cryptographic software provided by
a vendor that has undergone this certification. This means providing
documentation, test results, design information, and independent third
party review by an accredited lab. While open source software is
capable of meeting this, it does not meet FIPS-140 unless the vendor
submits to this process. | | Rationale: | Centralized cryptographic policies simplify applying secure ciphers across an operating system and
the applications that run on that operating system. Use of weak or untested encryption algorithms
undermines the purposes of utilizing encryption to protect data. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_crypto_policy | | Identifiers and References | Identifiers:
CCE-82541-4 References:
164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.312(e)(1), 164.312(e)(2)(ii), 1446, CIP-003-8 R4.2, CIP-007-3 R5.1, CIP-007-3 R7.1, AC-17(a), AC-17(2), CM-6(a), MA-4(6), SC-13, SC-12(2), SC-12(3), FCS_COP.1(1), FCS_COP.1(2), FCS_COP.1(3), FCS_COP.1(4), FCS_CKM.1, FCS_CKM.2, FCS_TLSC_EXT.1, SRG-OS-000396-GPOS-00176, SRG-OS-000393-GPOS-00173, SRG-OS-000394-GPOS-00174 | |
|
Rule
Configure Kerberos to use System Crypto Policy
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
Kerberos is supported by crypto policy, but it's configuration may be
set up to ignore it.
To check that Crypto Policies settings for Kerberos are configured correctly, examine that there is a symlink at
/etc/krb5.conf.d/crypto-policies targeting /etc/cypto-policies/back-ends/krb5.config.
If the symlink exists, Kerberos is configured to use the system-wide crypto policy settings. | | Rationale: | Overriding the system crypto policy makes the behavior of Kerberos violate expectations,
and makes system configuration more fragmented. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_kerberos_crypto_policy | | Identifiers and References | Identifiers:
CCE-82547-1 References:
0418, 1055, 1402, CIP-003-8 R4.2, CIP-007-3 R5.1, SC-13, SC-12(2), SC-12(3), SRG-OS-000120-GPOS-00061 | |
|
Rule
Configure Libreswan to use System Crypto Policy
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
Libreswan is supported by system crypto policy, but the Libreswan configuration may be
set up to ignore it.
To check that Crypto Policies settings are configured correctly, ensure that the /etc/ipsec.conf
includes the appropriate configuration file.
In /etc/ipsec.conf, make sure that the following line
is not commented out or superseded by later includes:
include /etc/crypto-policies/back-ends/libreswan.config | | Rationale: | Overriding the system crypto policy makes the behavior of the Libreswan
service violate expectations, and makes system configuration more
fragmented. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_libreswan_crypto_policy | | Identifiers and References | Identifiers:
CCE-82546-3 References:
CIP-003-8 R4.2, CIP-007-3 R5.1, CM-6(a), MA-4(6), SC-13, SC-12(2), SC-12(3), FCS_IPSEC_EXT.1.4, FCS_IPSEC_EXT.1.6, SRG-OS-000033-GPOS-00014 | |
|
Rule
Configure OpenSSL library to use System Crypto Policy
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
OpenSSL is supported by crypto policy, but the OpenSSL configuration may be
set up to ignore it.
To check that Crypto Policies settings are configured correctly, you have to examine the OpenSSL config file
available under /etc/pki/tls/openssl.cnf.
This file has the ini format, and it enables crypto policy support
if there is a [ crypto_policy ] section that contains the .include /etc/crypto-policies/back-ends/opensslcnf.config directive. | | Rationale: | Overriding the system crypto policy makes the behavior of the Java runtime violates expectations,
and makes system configuration more fragmented. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_openssl_crypto_policy | | Identifiers and References | Identifiers:
CCE-82545-5 References:
CCI-001453, CIP-003-8 R4.2, CIP-007-3 R5.1, CIP-007-3 R7.1, AC-17(a), AC-17(2), CM-6(a), MA-4(6), SC-13, SC-12(2), SC-12(3), SRG-OS-000250-GPOS-00093 | |
|
Rule
Configure SSH to use System Crypto Policy
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
SSH is supported by crypto policy, but the SSH configuration may be
set up to ignore it.
To check that Crypto Policies settings are configured correctly, ensure that
the CRYPTO_POLICY variable is either commented or not set at all
in the /etc/sysconfig/sshd. | | Rationale: | Overriding the system crypto policy makes the behavior of the SSH service violate expectations,
and makes system configuration more fragmented. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_ssh_crypto_policy | | Identifiers and References | References:
164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.312(e)(1), 164.312(e)(2)(ii), CIP-003-8 R4.2, CIP-007-3 R5.1, CIP-007-3 R7.1, AC-17(a), AC-17(2), CM-6(a), MA-4(6), SC-13, SRG-OS-000250-GPOS-00093 | |
|
| Group
Disk Partitioning
Group contains 4 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:
BP28(R12), 12, 15, 8, APO13.01, DSS05.02, CCI-000366, CCI-001208, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, A.13.1.1, A.13.2.1, A.14.1.3, CM-6(a), SC-5(2), PR.PT-4, SRG-OS-000480-GPOS-00227 | |
|
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:
BP28(R12), 12, 15, 8, APO13.01, DSS05.02, CCI-000366, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, A.13.1.1, A.13.2.1, A.14.1.3, CM-6(a), SC-5(2), PR.PT-4, SRG-OS-000480-GPOS-00227, SRG-OS-000341-VMM-001220 | |
|
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:
BP28(R12), BP28(R47), 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 | |
|
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:
BP28(R43), 1, 12, 13, 14, 15, 16, 2, 3, 5, 6, 8, APO11.04, APO13.01, BAI03.05, BAI04.04, DSS05.02, DSS05.04, DSS05.07, MEA02.01, CCI-000366, CCI-001849, 164.312(a)(2)(ii), 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.2, SR 7.6, A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.17.2.1, CIP-007-3 R6.5, CM-6(a), AU-4, SC-5(2), PR.DS-4, PR.PT-1, PR.PT-4, SRG-OS-000341-GPOS-00132, SRG-OS-000480-GPOS-00227, SRG-OS-000341-VMM-001220 | |
|
| Group
Updating Software
Group contains 1 rule |
[ref]
The 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
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:
BP28(R15), 11, 2, 3, 9, 5.10.4.1, APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02, 3.4.8, CCI-001749, 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i), 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4, SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6, A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, CIP-003-8 R4.2, CIP-003-8 R6, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1, CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), PR.DS-6, PR.DS-8, PR.IP-1, FPT_TUD_EXT.1, FPT_TUD_EXT.2, Req-6.2, SRG-OS-000366-GPOS-00153, SRG-OS-000366-VMM-001430, SRG-OS-000370-VMM-001460, SRG-OS-000404-VMM-001650 | |
|
| Group
Account and Access Control
Group contains 7 groups and 14 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 Physical Console Access
Group contains 2 groups and 9 rules |
[ref]
It is impossible to fully protect a system from an
attacker with physical access, so securing the space in which the
system is located should be considered a necessary step. However,
there are some steps which, if taken, make it more difficult for an
attacker to quickly or undetectably modify a system from its
console. |
| Group
Configure Screen Locking
Group contains 1 group and 4 rules |
[ref]
When a user must temporarily leave an account
logged-in, screen locking should be employed to prevent passersby
from abusing the account. User education and training is
particularly important for screen locking to be effective, and policies
can be implemented to reinforce this.
Automatic screen locking is only meant as a safeguard for
those cases where a user forgot to lock the screen. |
| Group
Configure Console Screen Locking
Group contains 4 rules |
[ref]
A console screen locking mechanism is a temporary action taken when a user
stops work and moves away from the immediate physical vicinity of the
information system but does not logout because of the temporary nature of
the absence. Rather than relying on the user to manually lock their
operation system session prior to vacating the vicinity, operating systems
need to be able to identify when a user's session has idled and take action
to initiate the session lock. |
Rule
Install the tmux Package
[ref] | To enable console screen locking, install the tmux package.
A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to log out because of the temporary nature of the absence.
The session lock is implemented at the point where session activity can be determined.
Rather than be forced to wait for a period of time to expire before the user session can be locked, Red Hat Enterprise Linux CoreOS 4 needs to provide users with the ability to manually invoke a session lock so users can secure their session if it is necessary to temporarily vacate the immediate physical vicinity.
Instruct users to begin new terminal sessions with the following command:
$ tmux
The console can now be locked with the following key combination:
ctrl+b :lock-session | | Rationale: | A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate
physical vicinity of the information system but does not logout because of the temporary nature of the absence.
Rather than relying on the user to manually lock their operation system session prior to vacating the vicinity,
operating systems need to be able to identify when a user's session has idled and take action to initiate the
session lock.
The tmux package allows for a session lock to be implemented and configured. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_tmux_installed | | Identifiers and References | References:
1, 12, 15, 16, DSS05.04, DSS05.10, DSS06.10, 3.1.10, CCI-000058, CCI-000056, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, CM-6(a), PR.AC-7, FMT_MOF_EXT.1, SRG-OS-000030-GPOS-00011, SRG-OS-000028-GPOS-00009, SRG-OS-000030-VMM-000110 | |
|
Rule
Support session locking with tmux
[ref] | The tmux terminal multiplexer is used to implement
automatic session locking. It should be started from
/etc/bashrc or drop-in files within /etc/profile.d/. | | Rationale: | Unlike bash itself, the tmux terminal multiplexer
provides a mechanism to lock sessions after period of inactivity.
A session lock is a temporary action taken when a user stops work and moves away from the
immediate physical vicinity of the information system but does not want to
log out because of the temporary nature of the absence. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_bashrc_exec_tmux | | Identifiers and References | References:
CCI-000056, FMT_SMF_EXT.1, SRG-OS-000031-GPOS-00012, SRG-OS-000028-GPOS-00009 | |
|
Rule
Configure tmux to lock session after inactivity
[ref] | To enable console screen locking in tmux terminal multiplexer
after a period of inactivity,
the lock-after-time option has to be set to nonzero value in
/etc/tmux.conf. | | Rationale: | Locking the session after a period of inactivity limits the
potential exposure if the session is left unattended. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_tmux_lock_after_time | | Identifiers and References | References:
CCI-000057, FMT_SMF_EXT.1, SRG-OS-000029-GPOS-00010, SRG-OS-000031-GPOS-00012 | |
|
Rule
Configure the tmux Lock Command
[ref] | To enable console screen locking in tmux terminal multiplexer,
the vlock command must be configured to be used as a locking
mechanism.
Add the following line to /etc/tmux.conf:
set -g lock-command vlock .
The console can now be locked with the following key combination:
ctrl+b :lock-session | | Rationale: | The tmux package allows for a session lock to be implemented and configured.
However, the session lock is implemented by an external command. The tmux
default configuration does not contain an effective session lock. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_tmux_lock_command | | Identifiers and References | References:
CCI-000056, CCI-000058, AC-11(a), AC-11(b), CM-6(a), SRG-OS-000028-GPOS-00009, SRG-OS-000028-VMM-000090, SRG-OS-000030-VMM-000110 | |
|
Rule
Disable debug-shell SystemD Service
[ref] | SystemD's debug-shell service is intended to
diagnose SystemD related boot issues with various systemctl
commands. Once enabled and following a system reboot, the root shell
will be available on tty9 which is access by pressing
CTRL-ALT-F9. The debug-shell service should only be used
for SystemD related issues and should otherwise be disabled.
By default, the debug-shell SystemD service is already disabled.
The debug-shell service can be disabled with the following manifest:
---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 75-master-debug-shell-disable
spec:
config:
ignition:
version: 3.1.0
systemd:
units:
- enabled: false
name: debug-shell.service
This will disable the debug-shell service in all the
nodes labeled with the "master" role.
Note that this needs to be done for each MachineConfigPool
For more information on how to configure nodes with the Machine Config
Operator see
the relevant documentation.
| | Rationale: | This prevents attackers with physical access from trivially bypassing security
on the machine through valid troubleshooting configurations and gaining root
access when the system is rebooted. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_service_debug-shell_disabled | | Identifiers and References | Identifiers:
CCE-82496-1 References:
3.4.5, CCI-000366, 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), CM-6, FIA_UAU.1, SRG-OS-000324-GPOS-00125, SRG-OS-000480-GPOS-00227 | |
|
Rule
Disable Ctrl-Alt-Del Burst Action
[ref] | By default, SystemD will reboot the system if the Ctrl-Alt-Del
key sequence is pressed Ctrl-Alt-Delete more than 7 times in 2 seconds.
To configure the system to ignore the CtrlAltDelBurstAction
setting, create a MachineConfig similar to the following:
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 75-master-disable-ctrlaltdel-burstaction
spec:
config:
ignition:
version: 3.1.0
storage:
files:
- contents:
source: data:,CtrlAltDelBurstAction%3Dnone
mode: 0644
path: /etc/systemd/system.conf.d/disable_ctrlaltdelete_burstaction.conf
overwrite: true
EOF
This will add the relevant configuration to /etc/systemd/system.conf.d/,
thus configuring Systemd apropriately.
Note that this needs to be done for each MachineConfigPool
For more information on how to configure nodes with the Machine Config
Operator see
the relevant documentation.
Warning:
Disabling the Ctrl-Alt-Del key sequence
in /etc/init/control-alt-delete.conf DOES NOT disable the Ctrl-Alt-Del
key sequence if running in runlevel 6 (e.g. in GNOME, KDE, etc.)! The
Ctrl-Alt-Del key sequence will only be disabled if running in
the non-graphical runlevel 3. | | Rationale: | A locally logged-in user who presses Ctrl-Alt-Del, when at the console,
can reboot the system. If accidentally pressed, as could happen in
the case of mixed OS environment, this can create the risk of short-term
loss of availability of systems due to unintentional reboot. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_disable_ctrlaltdel_burstaction | | Identifiers and References | Identifiers:
CCE-82495-3 References:
12, 13, 14, 15, 16, 18, 3, 5, APO01.06, DSS05.04, DSS05.07, DSS06.02, 3.4.5, CCI-000366, 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, 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), CM-6(a), PR.AC-4, PR.DS-5, SRG-OS-000324-GPOS-00125, SRG-OS-000480-GPOS-00227 | |
|
Rule
Disable Ctrl-Alt-Del Reboot Activation
[ref] | By default, SystemD will reboot the system if the Ctrl-Alt-Del
key sequence is pressed.
To configure the system to ignore the Ctrl-Alt-Del key sequence from the
command line instead of rebooting the system, create a MachineConfig
similar to the following:
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 75-master-disable-ctrlaltdel-reboot
spec:
config:
ignition:
version: 3.1.0
systemd:
units:
- name: ctrl-alt-del.target
mask: true
EOF
This will mask the ctrl-alt-del.target systemd target for all the
nodes labeled with the "master" role.
Note that this needs to be done for each MachineConfigPool
For more information on how to configure nodes with the Machine Config
Operator see
the relevant documentation.
| | Rationale: | A locally logged-in user who presses Ctrl-Alt-Del, when at the console,
can reboot the system. If accidentally pressed, as could happen in
the case of mixed OS environment, this can create the risk of short-term
loss of availability of systems due to unintentional reboot. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_disable_ctrlaltdel_reboot | | Identifiers and References | Identifiers:
CCE-82493-8 References:
12, 13, 14, 15, 16, 18, 3, 5, APO01.06, DSS05.04, DSS05.07, DSS06.02, 3.4.5, CCI-000366, 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, 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-000324-GPOS-00125, SRG-OS-000480-GPOS-00227 | |
|
Rule
Verify that Interactive Boot is Disabled
[ref] | Red Hat Enterprise Linux CoreOS 4 systems support an "interactive boot" option that can
be used to prevent services from being started. On a Red Hat Enterprise Linux CoreOS 4
system, interactive boot can be enabled by providing a 1,
yes, true, or on value to the
systemd.confirm_spawn kernel argument in /etc/default/grub.
Remove any instance of systemd.confirm_spawn=(1|yes|true|on) from
the kernel arguments in that file to disable interactive boot.
Recovery booting must also be disabled. Confirm that
GRUB_DISABLE_RECOVERY=true is set in /etc/default/grub.
It is also required to change the runtime configuration, run:
/sbin/grubby --update-kernel=ALL --remove-args="systemd.confirm_spawn"
grub2-mkconfig -o /boot/grub2/grub.cfg | | Rationale: | Using interactive or recovery boot, the console user could disable auditing, firewalls,
or other services, weakening system security. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_disable_interactive_boot | | Identifiers and References | Identifiers:
CCE-82551-3 References:
11, 12, 14, 15, 16, 18, 3, 5, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.03, DSS06.06, 3.1.2, 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, SC-2(1), CM-6(a), PR.AC-4, PR.AC-6, PR.PT-3, FIA_UAU.1, SRG-OS-000480-GPOS-00227 | |
|
Rule
Require Authentication for Single User Mode
[ref] | Single-user mode is intended as a system recovery
method, providing a single user root access to the system by
providing a boot option at startup. By default, no authentication
is performed if single-user mode is selected.
By default, single-user mode is protected by requiring a password and is set
in /usr/lib/systemd/system/rescue.service. | | Rationale: | This prevents attackers with physical access from trivially bypassing security
on the machine and gaining root access. Such accesses are further prevented
by configuring the bootloader password. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_require_singleuser_auth | | Identifiers and References | Identifiers:
CCE-82550-5 References:
1, 11, 12, 14, 15, 16, 18, 3, 5, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.06, DSS06.10, 3.1.1, 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, 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561, A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, 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, AC-3, CM-6(a), PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.PT-3, FIA_UAU.1, SRG-OS-000080-GPOS-00048 | |
|
| Group
Protect Accounts by Restricting Password-Based Login
Group contains 1 group and 1 rule |
[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
Verify Proper Storage and Existence of Password
Hashes
Group contains 1 rule |
[ref]
By default, password hashes for local accounts are stored
in the second field (colon-separated) in
/etc/shadow. This file should be readable only by
processes running with root credentials, preventing users from
casually accessing others' password hashes and attempting
to crack them.
However, it remains possible to misconfigure the system
and store password hashes
in world-readable files such as /etc/passwd, or
to even store passwords themselves in plaintext on the system.
Using system-provided tools for password change/creation
should allow administrators to avoid such misconfiguration. |
Rule
Prevent Login to Accounts With Empty Password
[ref] | If an account is configured for password authentication
but does not have an assigned password, it may be possible to log
into the account without authentication. Remove any instances of the
nullok in
/etc/pam.d/system-auth
to prevent logins with empty passwords. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
Note that this rule is not applicable for systems running within a
container. Having user with empty password within a container is not
considered a risk, because it should not be possible to directly login into
a container anyway. | | Rationale: | If an account has an empty password, anyone could log in and
run commands with the privileges of that account. Accounts with
empty passwords should never be used in operational environments. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_no_empty_passwords | | Identifiers and References | Identifiers:
CCE-82553-9 References:
1, 12, 13, 14, 15, 16, 18, 3, 5, 5.5.2, APO01.06, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.02, DSS06.03, DSS06.10, 3.1.1, 3.1.5, CCI-000366, 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.3, 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, 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.18.1.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, IA-5(1)(a), IA-5(c), CM-6(a), PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.DS-5, FIA_UAU.1, Req-8.2.3, SRG-OS-000480-GPOS-00227 | |
|
| Group
Secure Session Configuration Files for Login Accounts
Group contains 1 group and 4 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 027 | | 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:
BP28(R35), 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 | |
|
Rule
Ensure the Default C Shell Umask is Set Correctly
[ref] | To ensure the default umask for users of the C shell is set properly,
add or correct the umask setting in /etc/csh.cshrc to read as follows:
umask 027 | | 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_csh_cshrc | | Identifiers and References | Identifiers:
CCE-84261-7 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 | |
|
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 027 | | 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:
BP28(R35), 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 | |
|
Rule
Limit the Number of Concurrent Login Sessions Allowed Per User
[ref] | Limiting the number of allowed users and sessions per user can limit risks related to Denial of
Service attacks. This addresses concurrent sessions for a single account and does not address
concurrent sessions by a single user via multiple accounts. To set the number of concurrent
sessions per user add the following line in /etc/security/limits.conf or
a file under /etc/security/limits.d/:
* hard maxlogins 10 | | Rationale: | Limiting simultaneous user logins can insulate the system from denial of service
problems caused by excessive logins. Automated login processes operating improperly or
maliciously may result in an exceptional number of simultaneous login sessions. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_max_concurrent_login_sessions | | Identifiers and References | References:
14, 15, 18, 9, 5.5.2.2, DSS01.05, DSS05.02, CCI-000054, 4.3.3.4, SR 3.1, SR 3.8, A.13.1.1, A.13.1.3, A.13.2.1, A.14.1.2, A.14.1.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, AC-10, CM-6(a), PR.AC-5, SRG-OS-000027-GPOS-00008, SRG-OS-000027-VMM-000080 | |
|
| Group
System Accounting with auditd
Group contains 2 groups and 26 rules |
[ref]
The audit service provides substantial capabilities
for recording system activities. By default, the service audits about
SELinux AVC denials and certain types of security-relevant events
such as system logins, account modifications, and authentication
events performed by programs such as sudo.
Under its default configuration, auditd has modest disk space
requirements, and should not noticeably impact system performance.
NOTE: The Linux Audit daemon auditd can be configured to use
the augenrules program to read audit rules files ( *.rules)
located in /etc/audit/rules.d location and compile them to create
the resulting form of the /etc/audit/audit.rules configuration file
during the daemon startup (default configuration). Alternatively, the auditd
daemon can use the auditctl utility to read audit rules from the
/etc/audit/audit.rules configuration file during daemon startup,
and load them into the kernel. The expected behavior is configured via the
appropriate ExecStartPost directive setting in the
/usr/lib/systemd/system/auditd.service configuration file.
To instruct the auditd daemon to use the augenrules program
to read audit rules (default configuration), use the following setting:
ExecStartPost=-/sbin/augenrules --load
in the /usr/lib/systemd/system/auditd.service configuration file.
In order to instruct the auditd daemon to use the auditctl
utility to read audit rules, use the following setting:
ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
in the /usr/lib/systemd/system/auditd.service configuration file.
Refer to [Service] section of the /usr/lib/systemd/system/auditd.service
configuration file for further details.
Government networks often have substantial auditing
requirements and auditd can be configured to meet these
requirements.
Examining some example audit records demonstrates how the Linux audit system
satisfies common requirements.
The following example from Red Hat Enterprise Linux 7 Documentation available at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/selinux_users_and_administrators_guide/index#sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages
shows the substantial amount of information captured in a
two typical "raw" audit messages, followed by a breakdown of the most important
fields. In this example the message is SELinux-related and reports an AVC
denial (and the associated system call) that occurred when the Apache HTTP
Server attempted to access the /var/www/html/file1 file (labeled with
the samba_share_t type):
type=AVC msg=audit(1226874073.147:96): avc: denied { getattr } for pid=2465 comm="httpd"
path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file
type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13
a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48
gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd"
exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
msg=audit(1226874073.147:96)- The number in parentheses is the unformatted time stamp (Epoch time)
for the event, which can be converted to standard time by using the
date command.
{ getattr }- The item in braces indicates the permission that was denied.
getattr
indicates the source process was trying to read the target file's status information.
This occurs before reading files. This action is denied due to the file being
accessed having the wrong label. Commonly seen permissions include getattr,
read, and write.
comm="httpd"- The executable that launched the process. The full path of the executable is
found in the
exe= section of the system call (SYSCALL) message,
which in this case, is exe="/usr/sbin/httpd".
path="/var/www/html/file1"- The path to the object (target) the process attempted to access.
scontext="unconfined_u:system_r:httpd_t:s0"- The SELinux context of the process that attempted the denied action. In
this case, it is the SELinux context of the Apache HTTP Server, which is running
in the
httpd_t domain.
tcontext="unconfined_u:object_r:samba_share_t:s0"- The SELinux context of the object (target) the process attempted to access.
In this case, it is the SELinux context of
file1. Note: the samba_share_t
type is not accessible to processes running in the httpd_t domain.
- From the system call (
SYSCALL) message, two items are of interest:
success=no: indicates whether the denial (AVC) was enforced or not.
success=no indicates the system call was not successful (SELinux denied
access). success=yes indicates the system call was successful - this can
be seen for permissive domains or unconfined domains, such as initrc_t
and kernel_t.
exe="/usr/sbin/httpd": the full path to the executable that launched
the process, which in this case, is exe="/usr/sbin/httpd".
|
| Group
Configure auditd Data Retention
Group contains 6 rules |
[ref]
The audit system writes data to /var/log/audit/audit.log. By default,
auditd rotates 5 logs by size (6MB), retaining a maximum of 30MB of
data in total, and refuses to write entries when the disk is too
full. This minimizes the risk of audit data filling its partition
and impacting other services. This also minimizes the risk of the audit
daemon temporarily disabling the system if it cannot write audit log (which
it can be configured to do).
For a busy
system or a system which is thoroughly auditing system activity, the default settings
for data retention may be
insufficient. The log file size needed will depend heavily on what types
of events are being audited. First configure auditing to log all the events of
interest. Then monitor the log size manually for awhile to determine what file
size will allow you to keep the required data for the correct time period.
Using a dedicated partition for /var/log/audit prevents the
auditd logs from disrupting system functionality if they fill, and,
more importantly, prevents other activity in /var from filling the
partition and stopping the audit trail. (The audit logs are size-limited and
therefore unlikely to grow without bound unless configured to do so.) Some
machines may have requirements that no actions occur which cannot be audited.
If this is the case, then auditd can be configured to halt the machine
if it runs out of space. Note: Since older logs are rotated,
configuring auditd this way does not prevent older logs from being
rotated away before they can be viewed.
If your system is configured to halt when logging cannot be performed, make
sure this can never happen under normal circumstances! Ensure that
/var/log/audit is on its own partition, and that this partition is
larger than the maximum amount of data auditd will retain
normally. |
Rule
Configure auditd flush priority
[ref] | The auditd service can be configured to
synchronously write audit event data to disk. Add or correct the following
line in /etc/audit/auditd.conf to ensure that audit event data is
fully synchronized with the log files on the disk:
flush = incremental_async | | Rationale: | Audit data should be synchronously written to disk to ensure
log integrity. These parameters assure that all audit event data is fully
synchronized with the log files on the disk. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_data_retention_flush | | Identifiers and References | Identifiers:
CCE-82508-3 References:
1, 12, 13, 14, 15, 16, 2, 3, 5, 6, 7, 8, 9, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, BAI03.05, DSS01.03, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, 3.3.1, CCI-001576, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), 4.3.2.6.7, 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 6.1, SR 6.2, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.14.2.7, A.15.2.1, A.15.2.2, CIP-004-6 R2.2.3, CIP-004-6 R3.3, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, CIP-007-3 R6.5, AU-11, CM-6(a), DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.PT-1, SRG-OS-000480-GPOS-00227 | |
|
Rule
Set number of records to cause an explicit flush to audit logs
[ref] | To configure Audit daemon to issue an explicit flush to disk command
after writing 50 records, set freq to 50
in /etc/audit/auditd.conf. | | Rationale: | If option freq isn't set to 50, the flush to disk
may happen after higher number of records, increasing the danger
of audit loss. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_freq | | Identifiers and References | Identifiers:
CCE-82512-5 References:
CM-6, FAU_GEN.1, SRG-OS-000051-GPOS-00024 | |
|
Rule
Include Local Events in Audit Logs
[ref] | To configure Audit daemon to include local events in Audit logs, set
local_events to yes in /etc/audit/auditd.conf.
This is the default setting. | | Rationale: | If option local_events isn't set to yes only events from
network will be aggregated. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_local_events | | Identifiers and References | Identifiers:
CCE-82509-1 References:
CCI-000366, CM-6, FAU_GEN.1, SRG-OS-000062-GPOS-00031, SRG-OS-000480-GPOS-00227 | |
|
Rule
Resolve information before writing to audit logs
[ref] | To configure Audit daemon to resolve all uid, gid, syscall,
architecture, and socket address information before writing the
events to disk, set log_format to ENRICHED
in /etc/audit/auditd.conf. | | Rationale: | If option log_format isn't set to ENRICHED, the
audit records will be stored in a format exactly as the kernel sends them. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_log_format | | Identifiers and References | Identifiers:
CCE-82511-7 References:
CCI-000366, CM-6, AU-3, FAU_GEN.1.2, SRG-OS-000255-GPOS-00096, SRG-OS-000480-GPOS-00227 | |
|
Rule
Set hostname as computer node name in audit logs
[ref] | To configure Audit daemon to use value returned by gethostname
syscall as computer node name in the audit events,
set name_format to hostname
in /etc/audit/auditd.conf. | | Rationale: | If option name_format is left at its default value of
none, audit events from different computers may be hard
to distinguish. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_name_format | | Identifiers and References | Identifiers:
CCE-82513-3 References:
CCI-001851, CM-6, AU-3, FAU_GEN.1.2, SRG-OS-000039-GPOS-00017, SRG-OS-000342-GPOS-00133, SRG-OS-000479-GPOS-00224 | |
|
Rule
Write Audit Logs to the Disk
[ref] | To configure Audit daemon to write Audit logs to the disk, set
write_logs to yes in /etc/audit/auditd.conf.
This is the default setting. | | Rationale: | If write_logs isn't set to yes, the Audit logs will
not be written to the disk. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_write_logs | | Identifiers and References | Identifiers:
CCE-82510-9 References:
CM-6, FAU_STG.1, SRG-OS-000480-GPOS-00227 | |
|
| Group
System Accounting with auditd
Group contains 16 rules |
[ref]
The auditd program can perform comprehensive
monitoring of system activity. This section makes use of recommended
configuration settings for specific policies or use cases.
The rules in this section make use of rules defined in /usr/share/doc/audit-VERSION/rules. |
Rule
Configure auditing of unsuccessful file accesses
[ref] | Ensure that unsuccessful attempts to access a file are audited.
The following rules configure audit as described above:
## Unsuccessful file access (any other opens) This has to go last.
-a always,exit -F arch=b32 -S open,openat,openat2,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
-a always,exit -F arch=b64 -S open,openat,openat2,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
-a always,exit -F arch=b32 -S open,openat,openat2,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
-a always,exit -F arch=b64 -S open,openat,openat2,open_by_handle_at -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-access
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule utilizes a file provided by Audit package to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | | Rationale: | Unsuccessful attempts to access a file might be signs of malicious activity happening within the system. Auditing of such activities helps in their monitoring and investigation. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_access_failed | | Identifiers and References | References:
0582, 0584, 05885, 0586, 0846, 0957, AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of successful file accesses
[ref] | Ensure that successful attempts to access a file are audited.
The following rules configure audit as described above:
## Successful file access (any other opens) This has to go last.
## These next two are likely to result in a whole lot of events
-a always,exit -F arch=b32 -S open,openat,openat2,open_by_handle_at -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-access
-a always,exit -F arch=b64 -S open,openat,openat2,open_by_handle_at -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-access
The Audit package provides pre-configured rules in /usr/share/audit/sample-rules. The above content can be found in /usr/share/audit/sample-rules/30-ospp-v42-3-access-success.rules.
To deploy this configuration, it is recommended to copy it over to the /etc/audit/rules.d/ directory:
cp /usr/share/audit/sample-rules/30-ospp-v42-3-access-success.rules /etc/audit/rules.d/
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule utilizes a file provided by Audit package to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | | Rationale: | Auditing of successful attempts to access a file helps in investigation of activities performed on the system. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_access_success | | Identifiers and References | References:
0582, 0584, 05885, 0586, 0846, 0957, AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure basic parameters of Audit system
[ref] | Perform basic configuration of Audit system.
Make sure that any previously defined rules are cleared, the auditing system is configured to handle sudden bursts of events, and in cases of failure, messages are configured to be directed to system log.
The following rules configure audit as described above:
## First rule - delete all
-D
## Increase the buffers to survive stress events.
## Make this bigger for busy systems
-b 8192
## This determine how long to wait in burst of events
--backlog_wait_time 60000
## Set failure mode to syslog
-f 1
The Audit package provides pre-configured rules in /usr/share/audit/sample-rules. The above content can be found in /usr/share/audit/sample-rules/10-base-config.rules.
To deploy this configuration, it is recommended to copy it over to the /etc/audit/rules.d/ directory:
cp /usr/share/audit/sample-rules/10-base-config.rules /etc/audit/rules.d/
Load new Audit rules into kernel by running:
augenrules --load Warning:
It might happen that Audit buffer configured by this rule is not large enough for certain use cases. If that is the case, the buffer size can be overridden by placing -b larger_buffer_size into a file within /etc/audit/rules.d directory, replacing larger_file_size with the desired value. The file name should start with a number higher than 10 and lower than 99. | | Rationale: | Without basic configurations, audit may not perform as expected. It may not be able to correctly handle events under stressful conditions, or log events in case of failure. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_basic_configuration | | Identifiers and References | References:
AU-2(a), FAU_GEN.1, SRG-OS-000365-GPOS-00152, SRG-OS-000475-GPOS-00220 | |
|
Rule
Configure auditing of unsuccessful file creations
[ref] | Ensure that unsuccessful attempts to create a file are audited.
The following rules configure audit as described above:
## Unsuccessful file creation (open with O_CREAT)
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&0100 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&0100 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b32 -S open -F a1&0100 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S open -F a1&0100 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&0100 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&0100 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b32 -S open -F a1&0100 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S open -F a1&0100 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-create
The Audit package provides pre-configured rules in /usr/share/audit/sample-rules. The above content can be found in /usr/share/audit/sample-rules/30-ospp-v42-1-create-failed.rules.
To deploy this configuration, it is recommended to copy it over to the /etc/audit/rules.d/ directory:
cp /usr/share/audit/sample-rules/30-ospp-v42-1-create-failed.rules /etc/audit/rules.d/
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule utilizes a file provided by Audit package to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | | Rationale: | Unsuccessful file creations might be a sign of a malicious action being performed on the system. Keeping log of such events helps in monitoring and investigation of such actions. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_create_failed | | Identifiers and References | References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of successful file creations
[ref] | Ensure that successful attempts to create a file are audited.
The following rules configure audit as described above:
## Successful file creation (open with O_CREAT)
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&0100 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&0100 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
-a always,exit -F arch=b32 -S open -F a1&0100 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
-a always,exit -F arch=b64 -S open -F a1&0100 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
-a always,exit -F arch=b32 -S creat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
-a always,exit -F arch=b64 -S creat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-create
The Audit package provides pre-configured rules in /usr/share/audit/sample-rules. The above content can be found in /usr/share/audit/sample-rules/30-ospp-v42-1-create-success.rules.
To deploy this configuration, it is recommended to copy it over to the /etc/audit/rules.d/ directory:
cp /usr/share/audit/sample-rules/30-ospp-v42-1-create-success.rules /etc/audit/rules.d/
Load new Audit rules into kernel by running:
augenrules --load | | Rationale: | Auditing of successful attempts to create a file helps in investigation of actions which happened on the system. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_create_success | | Identifiers and References | References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of unsuccessful file deletions
[ref] | Ensure that unsuccessful attempts to delete a file are audited.
The following rules configure audit as described above:
## Unsuccessful file delete
-a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-delete
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-delete
-a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-delete
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-delete
The Audit package provides pre-configured rules in /usr/share/audit/sample-rules. The above content can be found in /usr/share/audit/sample-rules/30-ospp-v42-4-delete-failed.rules.
To deploy this configuration, it is recommended to copy it over to the /etc/audit/rules.d/ directory:
cp /usr/share/audit/sample-rules/30-ospp-v42-4-delete-failed.rules /etc/audit/rules.d/
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule utilizes a file provided by Audit package to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | | Rationale: | Unsuccessful attempts to delete a file might be signs of malicious activities. Auditing of such events help in monitoring and investigating of such activities. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_delete_failed | | Identifiers and References | References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205, SRG-OS-000468-GPOS-00212 | |
|
Rule
Configure auditing of successful file deletions
[ref] | Ensure that successful attempts to delete a file are audited.
The following rules configure audit as described above:
## Successful file delete
-a always,exit -F arch=b32 -S unlink,unlinkat,rename,renameat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-delete
-a always,exit -F arch=b64 -S unlink,unlinkat,rename,renameat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-delete
The Audit package provides pre-configured rules in /usr/share/audit/sample-rules. The above content can be found in /usr/share/audit/sample-rules/30-ospp-v42-4-delete-success.rules.
To deploy this configuration, it is recommended to copy it over to the /etc/audit/rules.d/ directory:
cp /usr/share/audit/sample-rules/30-ospp-v42-4-delete-success.rules /etc/audit/rules.d/
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule utilizes a file provided by Audit package to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | | Rationale: | Auditing of successful attempts to delete a file may help in monitoring and investigation of activities performed on the system. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_delete_success | | Identifiers and References | References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205, SRG-OS-000468-GPOS-00212 | |
|
Rule
Configure immutable Audit login UIDs
[ref] | Configure kernel to prevent modification of login UIDs once they are set.
Changing login UIDs while this configuration is enforced requires special capabilities which are not available to unprivileged users.
The following rules configure audit as described above:
## Make the loginuid immutable. This prevents tampering with the auid.
--loginuid-immutable
The Audit provides pre-configured rules in /usr/share/audit/sample-rules. The above content can be found in /usr/share/audit/sample-rules/11-loginuid.rules.
To deploy this configuration, it is recommended to copy it over to the /etc/audit/rules.d/ directory:
cp /usr/share/audit/sample-rules/11-loginuid.rules /etc/audit/rules.d/
Load new Audit rules into kernel by running:
augenrules --load | | Rationale: | If modification of login UIDs is not prevented, they can be changed by unprivileged users and make auditing complicated or impossible. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_immutable_login_uids | | Identifiers and References | References:
CCI-000162, AU-2(a), FAU_GEN.1.2, SRG-OS-000462-GPOS-00206, SRG-OS-000475-GPOS-00220, SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029 | |
|
Rule
Configure auditing of unsuccessful file modifications
[ref] | Ensure that unsuccessful attempts to modify a file are audited.
The following rules configure audit as described above:
## Unsuccessful file modifications (open for write or truncate)
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&01003 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&01003 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b32 -S open -F a1&01003 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S open -F a1&01003 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b32 -S truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&01003 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&01003 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b32 -S open -F a1&01003 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S open -F a1&01003 -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b32 -S truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
-a always,exit -F arch=b64 -S truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-modification
The Audit package provides pre-configured rules in /usr/share/audit/sample-rules. The above content can be found in /usr/share/audit/sample-rules/30-ospp-v42-2-modify-failed.rules.
To deploy this configuration, it is recommended to copy it over to the /etc/audit/rules.d/ directory:
cp /usr/share/audit/sample-rules/30-ospp-v42-2-modify-failed.rules /etc/audit/rules.d/
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule utilizes a file provided by Audit package to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | | Rationale: | Unsuccessful file modifications might be a sign of a malicious action being performed on the system. Auditing of such events helps in detection and investigation of such actions. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_modify_failed | | Identifiers and References | References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of successful file modifications
[ref] | Ensure that successful attempts to modify a file are audited.
The following rules configure audit as described above:
## Successful file modifications (open for write or truncate)
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&01003 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&01003 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
-a always,exit -F arch=b32 -S open -F a1&01003 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
-a always,exit -F arch=b64 -S open -F a1&01003 -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
-a always,exit -F arch=b32 -S truncate,ftruncate -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
-a always,exit -F arch=b64 -S truncate,ftruncate -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-modification
The Audit package provides pre-configured rules in /usr/share/audit/sample-rules. The above content can be found in /usr/share/audit/sample-rules/30-ospp-v42-2-modify-success.rules.
To deploy this configuration, it is recommended to copy it over to the /etc/audit/rules.d/ directory:
cp /usr/share/audit/sample-rules/30-ospp-v42-2-modify-success.rules /etc/audit/rules.d/
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule utilizes a file provided by Audit package to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | | Rationale: | Auditing of successful attempts to modify a file helps in investigation of actions which happened on the system. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_modify_success | | Identifiers and References | References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000461-GPOS-00205 | |
|
Rule
Configure auditing of loading and unloading of kernel modules
[ref] | Ensure that loading and unloading of kernel modules is audited.
The following rules configure audit as described above:
## These rules watch for kernel module insertion. By monitoring
## the syscall, we do not need any watches on programs.
-a always,exit -F arch=b32 -S init_module,finit_module -F key=module-load
-a always,exit -F arch=b64 -S init_module,finit_module -F key=module-load
-a always,exit -F arch=b32 -S delete_module -F key=module-unload
-a always,exit -F arch=b64 -S delete_module -F key=module-unload
The Audit package provides pre-configured rules in /usr/share/audit/sample-rules. The above content can be found in /usr/share/audit/sample-rules/43-module-load.rules.
To deploy this configuration, it is recommended to copy it over to the /etc/audit/rules.d/ directory:
cp /usr/share/audit/sample-rules/43-module-load.rules /etc/audit/rules.d/
Load new Audit rules into kernel by running:
augenrules --load | | Rationale: | Loading of a malicious kernel module introduces a risk to the system, as the module has access to sensitive data and perform actions at the operating system kernel level. Having such events audited helps in monitoring and investigating of malicious activities. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_module_load | | Identifiers and References | References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222, SRG-OS-000475-GPOS-00220 | |
|
Rule
Perform general configuration of Audit for OSPP
[ref] | Configure some basic Audit parameters specific for OSPP profile.
In particular, configure Audit to watch for direct modification of files storing system user and group information, and usage of applications with special rights which can change system configuration.
Further audited events include access to audit log it self, attempts to Alter Process and Session Initiation Information, and attempts to modify MAC controls.
The following rules configure audit as described above:
## The purpose of these rules is to meet the requirements for Operating
## System Protection Profile (OSPP)v4.2. These rules depends on having
## the following rule files copied to /etc/audit/rules.d:
##
## 10-base-config.rules, 11-loginuid.rules,
## 30-ospp-v42-1-create-failed.rules, 30-ospp-v42-1-create-success.rules,
## 30-ospp-v42-2-modify-failed.rules, 30-ospp-v42-2-modify-success.rules,
## 30-ospp-v42-3-access-failed.rules, 30-ospp-v42-3-access-success.rules,
## 30-ospp-v42-4-delete-failed.rules, 30-ospp-v42-4-delete-success.rules,
## 30-ospp-v42-5-perm-change-failed.rules,
## 30-ospp-v42-5-perm-change-success.rules,
## 30-ospp-v42-6-owner-change-failed.rules,
## 30-ospp-v42-6-owner-change-success.rules
##
## original copies may be found in /usr/share/audit/sample-rules/
## User add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch passwd and
## shadow for writes
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S open -F a1&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S open -F a1&03 -F path=/etc/passwd -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S openat,open_by_handle_at -F a2&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b32 -S open -F a1&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F arch=b64 -S open -F a1&03 -F path=/etc/shadow -F auid>=1000 -F auid!=unset -F key=user-modify
## User enable and disable. This is entirely handled by pam.
## Group add delete modify. This is covered by pam. However, someone could
## open a file and directly create or modify a user, so we'll watch group and
## gshadow for writes
-a always,exit -F path=/etc/passwd -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/shadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=user-modify
-a always,exit -F path=/etc/group -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
-a always,exit -F path=/etc/gshadow -F perm=wa -F auid>=1000 -F auid!=unset -F key=group-modify
## Use of special rights for config changes. This would be use of setuid
## programs that relate to user accts. This is not all setuid apps because
## requirements are only for ones that affect system configuration.
-a always,exit -F path=/usr/sbin/unix_chkpwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/usernetctl -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/userhelper -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/sbin/seunshare -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/mount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgrp -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newuidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/gpasswd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/newgidmap -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/umount -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/passwd -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/crontab -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
-a always,exit -F path=/usr/bin/at -F perm=x -F auid>=1000 -F auid!=unset -F key=special-config-changes
## Privilege escalation via su or sudo. This is entirely handled by pam.
## Watch for configuration changes to privilege escalation.
-a always,exit -F path=/etc/sudoers -F perm=wa -F key=special-config-changes
-a always,exit -F dir=/etc/sudoers.d/ -F perm=wa -F key=special-config-changes
## Audit log access
-a always,exit -F dir=/var/log/audit/ -F perm=r -F auid>=1000 -F auid!=unset -F key=access-audit-trail
## Attempts to Alter Process and Session Initiation Information
-a always,exit -F path=/var/run/utmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/btmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
-a always,exit -F path=/var/log/wtmp -F perm=wa -F auid>=1000 -F auid!=unset -F key=session
## Attempts to modify MAC controls
-a always,exit -F dir=/etc/selinux/ -F perm=wa -F auid>=1000 -F auid!=unset -F key=MAC-policy
## Software updates. This is entirely handled by rpm.
## System start and shutdown. This is entirely handled by systemd
## Kernel Module loading. This is handled in 43-module-load.rules
## Application invocation. The requirements list an optional requirement
## FPT_SRP_EXT.1 Software Restriction Policies. This event is intended to
## state results from that policy. This would be handled entirely by
## that daemon.
The Audit package provides pre-configured rules in /usr/share/audit/sample-rules. The above content can be found in /usr/share/audit/sample-rules/30-ospp-v42.rules.
To deploy this configuration, it is recommended to copy it over to the /etc/audit/rules.d/ directory:
cp /usr/share/audit/sample-rules/30-ospp-v42.rules /etc/audit/rules.d/
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule utilizes a file provided by Audit package to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | | Rationale: | Auditing of events listed in the description provides data for monitoring and investigation of potentially malicious events e.g. tampering with Audit logs, malicious access to files storing information about system users and groups etc. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_ospp_general | | Identifiers and References | References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000004-GPOS-00004, SRG-OS-000241-GPOS-00091, SRG-OS-000476-GPOS-00221, SRG-OS-000327-GPOS-00127, SRG-OS-000475-GPOS-00220, SRG-OS-000239-GPOS-00089, SRG-OS-000274-GPOS-00104, SRG-OS-000275-GPOS-00105, SRG-OS-000303-GPOS-00120, SRG-OS-000304-GPOS-00121 | |
|
Rule
Configure auditing of unsuccessful ownership changes
[ref] | Ensure that unsuccessful attempts to change an ownership of files or directories are audited.
The following rules configure audit as described above:
## Unsuccessful ownership change
-a always,exit -F arch=b32 -S lchown,fchown,chown,fchownat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-owner-change
-a always,exit -F arch=b64 -S lchown,fchown,chown,fchownat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-owner-change
-a always,exit -F arch=b32 -S lchown,fchown,chown,fchownat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-owner-change
-a always,exit -F arch=b64 -S lchown,fchown,chown,fchownat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-owner-change
The Audit package provides pre-configured rules in /usr/share/audit/sample-rules. The above content can be found in /usr/share/audit/sample-rules/30-ospp-v42-6-owner-change-failed.rules.
To deploy this configuration, it is recommended to copy it over to the /etc/audit/rules.d/ directory:
cp /usr/share/audit/sample-rules/30-ospp-v42-6-owner-change-failed.rules /etc/audit/rules.d/
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule utilizes a file provided by Audit package to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | | Rationale: | Unsuccessful attempts to change an ownership of files or directories might be signs of a malicious activity. Having such events audited helps in monitoring and investigation of such activities. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_owner_change_failed | | Identifiers and References | References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | |
|
Rule
Configure auditing of successful ownership changes
[ref] | Ensure that successful attempts to change an ownership of files or directories are audited.
The following rules configure audit as described above:
## Successful ownership change
-a always,exit -F arch=b32 -S lchown,fchown,chown,fchownat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-owner-change
-a always,exit -F arch=b64 -S lchown,fchown,chown,fchownat -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-owner-change
The Audit package provides pre-configured rules in /usr/share/audit/sample-rules. The above content can be found in /usr/share/audit/sample-rules/30-ospp-v42-6-owner-change-success.rules.
To deploy this configuration, it is recommended to copy it over to the /etc/audit/rules.d/ directory:
cp /usr/share/audit/sample-rules/30-ospp-v42-6-owner-change-success.rules /etc/audit/rules.d/
The file has the following SHA-256 checksum:
7eb41a6aaf6737c2571b6424fae7fa53af4b41a9115b6c5732a5778ccd9900ad
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule utilizes a file provided by Audit package to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | | Rationale: | Auditing of successful ownership changes of files or directories helps in monitoring or investingating of activities performed on the system. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_owner_change_success | | Identifiers and References | References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | |
|
Rule
Configure auditing of unsuccessful permission changes
[ref] | Ensure that unsuccessful attempts to change file or directory permissions are audited.
The following rules configure audit as described above:
## Unsuccessful permission change
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=unsuccessful-perm-change
The Audit package provides pre-configured rules in /usr/share/audit/sample-rules. The above content can be found in /usr/share/audit/sample-rules/30-ospp-v42-5-perm-change-failed.rules.
To deploy this configuration, it is recommended to copy it over to the /etc/audit/rules.d/ directory:
cp /usr/share/audit/sample-rules/30-ospp-v42-5-perm-change-failed.rules /etc/audit/rules.d/
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule utilizes a file provided by Audit package to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | | Rationale: | Unsuccessful attempts to change permissions of files or directories might be signs of malicious activity. Having such events audited helps in monitoring and investigation of such activities. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_perm_change_failed | | Identifiers and References | References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | |
|
Rule
Configure auditing of successful permission changes
[ref] | Ensure that successful attempts to modify permissions of files or directories are audited.
The following rules configure audit as described above:
## Successful permission change
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-perm-change
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat,setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F success=1 -F auid>=1000 -F auid!=unset -F key=successful-perm-change
The Audit package provides pre-configured rules in /usr/share/audit/sample-rules. The above content can be found in /usr/share/audit/sample-rules/30-ospp-v42-5-perm-change-success.rules.
To deploy this configuration, it is recommended to copy it over to the /etc/audit/rules.d/ directory:
cp /usr/share/audit/sample-rules/30-ospp-v42-5-perm-change-success.rules /etc/audit/rules.d/
Load new Audit rules into kernel by running:
augenrules --load
Note: This rule utilizes a file provided by Audit package to comply with OSPP 4.2.1. You may reuse this rule in different profiles. If you decide to do so, it is recommended that you inspect contents of the file closely and make sure that they are alligned with your needs. | | Rationale: | Auditing successful file or directory permission changes helps in monitoring and investigating of activities performed on the system. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_perm_change_success | | Identifiers and References | References:
AU-2(a), FAU_GEN.1.1.c, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209, SRG-OS-000474-GPOS-00219, SRG-OS-000475-GPOS-00220, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | |
|
Rule
Ensure the audit Subsystem is Installed
[ref] | The audit package should be installed. | | Rationale: | The auditd service is an access monitoring and accounting daemon, watching system calls to audit any access, in comparison with potential local access control policy such as SELinux policy. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_audit_installed | | Identifiers and References | Identifiers:
CCE-82669-3 References:
BP28(R50), CCI-000172, CCI-001814, CCI-001875, CCI-001877, CCI-001878, CCI-001879, CCI-001880, CCI-001881, CCI-001882, CCI-001889, CCI-001914, CCI-000169, CIP-004-6 R3.3, CIP-007-3 R6.5, AC-7(a), AU-7(1), AU-7(2), AU-14, AU-12(2), AU-2(a), CM-6(a), FAU_GEN.1, SRG-OS-000062-GPOS-00031, SRG-OS-000037-GPOS-00015, SRG-OS-000038-GPOS-00016, SRG-OS-000039-GPOS-00017, SRG-OS-000040-GPOS-00018, SRG-OS-000041-GPOS-00019, SRG-OS-000042-GPOS-00021, SRG-OS-000051-GPOS-00024, SRG-OS-000054-GPOS-00025, SRG-OS-000122-GPOS-00063, SRG-OS-000254-GPOS-00095, SRG-OS-000255-GPOS-00096, SRG-OS-000337-GPOS-00129, SRG-OS-000348-GPOS-00136, SRG-OS-000349-GPOS-00137, SRG-OS-000350-GPOS-00138, SRG-OS-000351-GPOS-00139, SRG-OS-000352-GPOS-00140, SRG-OS-000353-GPOS-00141, SRG-OS-000354-GPOS-00142, SRG-OS-000358-GPOS-00145, SRG-OS-000365-GPOS-00152, SRG-OS-000392-GPOS-00172, SRG-OS-000475-GPOS-00220 | |
|
Rule
Enable auditd Service
[ref] | The auditd service is an essential userspace component of
the Linux Auditing System, as it is responsible for writing audit records to
disk.
The auditd service can be enabled with the following manifest:
---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 75-master-auditd-enable
spec:
config:
ignition:
version: 3.1.0
systemd:
units:
- name: auditd.service
enabled: true
This will enable the auditd service in all the
nodes labeled with the "master" role.
Note that this needs to be done for each MachineConfigPool
For more information on how to configure nodes with the Machine Config
Operator see
the relevant documentation.
| | Rationale: | Without establishing what type of events occurred, it would be difficult
to establish, correlate, and investigate the events leading up to an outage or attack.
Ensuring the auditd service is active ensures audit records
generated by the kernel are appropriately recorded.
Additionally, a properly configured audit subsystem ensures that actions of
individual system users can be uniquely traced to those users so they
can be held accountable for their actions. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_service_auditd_enabled | | Identifiers and References | Identifiers:
CCE-82463-1 References:
1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9, 5.4.1.1, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, 3.3.1, 3.3.2, 3.3.6, CCI-000126, CCI-000130, CCI-000131, CCI-000132, CCI-000133, CCI-000134, CCI-000135, CCI-000154, CCI-000158, CCI-000366, CCI-001464, CCI-001487, CCI-001814, CCI-001876, CCI-002884, CCI-000169, 164.308(a)(1)(ii)(D), 164.308(a)(5)(ii)(C), 164.310(a)(2)(iv), 164.310(d)(2)(iii), 164.312(b), 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, 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 6.1, SR 6.2, SR 7.1, SR 7.6, A.11.2.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, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, CIP-004-6 R3.3, CIP-007-3 R6.5, AC-2(g), AU-3, AU-10, AU-2(d), AU-12(c), AU-14(1), AC-6(9), CM-6(a), SI-4(23), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1, Req-10.1, SRG-OS-000062-GPOS-00031, SRG-OS-000037-GPOS-00015, SRG-OS-000038-GPOS-00016, SRG-OS-000039-GPOS-00017, SRG-OS-000040-GPOS-00018, SRG-OS-000041-GPOS-00019, SRG-OS-000042-GPOS-00021, SRG-OS-000051-GPOS-00024, SRG-OS-000054-GPOS-00025, SRG-OS-000122-GPOS-00063, SRG-OS-000254-GPOS-00095, SRG-OS-000255-GPOS-00096, SRG-OS-000337-GPOS-00129, SRG-OS-000348-GPOS-00136, SRG-OS-000349-GPOS-00137, SRG-OS-000350-GPOS-00138, SRG-OS-000351-GPOS-00139, SRG-OS-000352-GPOS-00140, SRG-OS-000353-GPOS-00141, SRG-OS-000354-GPOS-00142, SRG-OS-000358-GPOS-00145, SRG-OS-000365-GPOS-00152, SRG-OS-000392-GPOS-00172, SRG-OS-000475-GPOS-00220, SRG-OS-000037-VMM-000150, SRG-OS-000063-VMM-000310, SRG-OS-000038-VMM-000160, SRG-OS-000039-VMM-000170, SRG-OS-000040-VMM-000180, SRG-OS-000041-VMM-000190 | |
|
Rule
Extend Audit Backlog Limit for the Audit Daemon
[ref] | To improve the kernel capacity to queue all log events, even those which occurred
prior to the audit daemon, add the argument audit_backlog_limit=8192 to all
BLS (Boot Loader Specification) entries ('options' line) for the Linux
operating system in /boot/loader/entries/*.conf. | | Rationale: | audit_backlog_limit sets the queue length for audit events awaiting transfer
to the audit daemon. Until the audit daemon is up and running, all log messages
are stored in this queue. If the queue is overrun during boot process, the action
defined by audit failure flag is taken. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_coreos_audit_backlog_limit_kernel_argument | | Identifiers and References | Identifiers:
CCE-82671-9 References:
CM-6(a), SRG-OS-000254-GPOS-00095 | |
|
Rule
Enable Auditing for Processes Which Start Prior to the Audit Daemon
[ref] | To ensure all processes can be audited, even those which start
prior to the audit daemon, add the argument audit=1 to all
BLS (Boot Loader Specification) entries ('options' line) for the Linux
operating system in /boot/loader/entries/*.conf. | | Rationale: | Each process on the system carries an "auditable" flag which indicates whether
its activities can be audited. Although auditd takes care of enabling
this for all processes which launch after it does, adding the kernel argument
ensures it is set for every process during boot. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_coreos_audit_option | | Identifiers and References | Identifiers:
CCE-82670-1 References:
1, 11, 12, 13, 14, 15, 16, 19, 3, 4, 5, 6, 7, 8, 5.4.1.1, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.02, DSS05.03, DSS05.04, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, 3.3.1, CCI-001464, CCI-000130, 164.308(a)(1)(ii)(D), 164.308(a)(5)(ii)(C), 164.310(a)(2)(iv), 164.310(d)(2)(iii), 164.312(b), 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, 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 6.1, SR 7.1, SR 7.6, A.11.2.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, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, CIP-004-6 R3.3, CIP-007-3 R7.1, AC-17(1), AU-14(1), AU-10, CM-6(a), IR-5(1), DE.AE-3, DE.AE-5, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, Req-10.3, SRG-OS-000254-GPOS-00095, SRG-OS-000254-VMM-000880 | |
|
| Group
GRUB2 bootloader configuration
Group contains 1 group and 3 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
UEFI GRUB2 bootloader configuration
Group contains 1 rule |
[ref]
UEFI GRUB2 bootloader configuration |
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:
BP28(R17), 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 | |
|
Rule
Enable Kernel Page-Table Isolation (KPTI)
[ref] | To enable Kernel page-table isolation, add the argument pti=on to all
BLS (Boot Loader Specification) entries ('options' line) for the Linux
operating system in /boot/loader/entries/*.conf. | | Rationale: | Kernel page-table isolation is a kernel feature that mitigates
the Meltdown security vulnerability and hardens the kernel
against attempts to bypass kernel address space layout
randomization (KASLR). | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_coreos_pti_kernel_argument | | Identifiers and References | Identifiers:
CCE-82497-9 References:
SI-16, SRG-OS-000433-GPOS-00193 | |
|
Rule
Disable vsyscalls
[ref] | To disable use of virtual syscalls, add the argument vsyscall=none to all
BLS (Boot Loader Specification) entries ('options' line) for the Linux
operating system in /boot/loader/entries/*.conf. | | Rationale: | Virtual Syscalls provide an opportunity of attack for a user who has control
of the return instruction pointer. | | Severity: | info | | Rule ID: | xccdf_org.ssgproject.content_rule_coreos_vsyscall_kernel_argument | | Identifiers and References | Identifiers:
CCE-82674-3 References:
CM-7(a), SRG-OS-000480-GPOS-00227 | |
|
| Group
zIPL bootloader configuration
Group contains 7 rules |
[ref]
During the boot process, the bootloader is
responsible for starting the execution of the kernel and passing
options to it.
The default Red Hat Enterprise Linux CoreOS 4 boot loader for s390x systems is called zIPL. |
Rule
Enable Auditing to Start Prior to the Audit Daemon in zIPL
[ref] | To ensure all processes can be audited, even those which start prior to the audit daemon,
check that all boot entries in /boot/loader/entries/*.conf have audit=1
included in its options.
To ensure that new kernels and boot entries continue to enable audit,
add audit=1 to /etc/kernel/cmdline. | | Rationale: | Each process on the system carries an "auditable" flag which indicates whether
its activities can be audited. Although auditd takes care of enabling
this for all processes which launch after it does, adding the kernel argument
ensures it is set for every process during boot. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_zipl_audit_argument | | Identifiers and References | References:
FAU_GEN.1 | |
|
Rule
Extend Audit Backlog Limit for the Audit Daemon in zIPL
[ref] | To improve the kernel capacity to queue all log events, even those which start prior to the audit daemon,
check that all boot entries in /boot/loader/entries/*.conf have audit_backlog_limit=8192
included in its options.
To ensure that new kernels and boot entries continue to extend the audit log events queue,
add audit_backlog_limit=8192 to /etc/kernel/cmdline. | | Rationale: | audit_backlog_limit sets the queue length for audit events awaiting transfer
to the audit daemon. Until the audit daemon is up and running, all log messages
are stored in this queue. If the queue is overrun during boot process, the action
defined by audit failure flag is taken. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_zipl_audit_backlog_limit_argument | | Identifiers and References | References:
FAU_STG.1, FAU_STG.3 | |
|
Rule
Ensure all zIPL boot entries are BLS compliant
[ref] | Ensure that zIPL boot entries fully adheres to Boot Loader Specification (BLS)
by checking that /etc/zipl.conf doesn't contain image = . Warning:
To prevent breakage or removal of all boot entries oconfigured in /etc/zipl.conf
automated remediation for this rule is not available. | | Rationale: | Red Hat Enterprise Linux CoreOS 4 adheres to Boot Loader Specification (BLS) and is the prefered method of
configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_zipl_bls_entries_only | | Identifiers and References | | |
|
Rule
Ensure zIPL bootmap is up to date
[ref] | Make sure that /boot/bootmap is up to date.
Every time a boot entry or zIPL configuration is changed /boot/bootmap needs to
be updated to reflect the changes.
Run zipl command to generate an updated /boot/bootmap. | | Rationale: | The file /boot/bootmap contains all boot data, keeping it up to date is crucial to
boot correct kernel and options. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_zipl_bootmap_is_up_to_date | | Identifiers and References | | |
|
Rule
Enable page allocator poisoning in zIPL
[ref] | To enable poisoning of free pages,
check that all boot entries in /boot/loader/entries/*.conf have page_poison=1
included in its options.
To ensure that new kernels and boot entries continue to enable page poisoning,
add page_poison=1 to /etc/kernel/cmdline. | | Rationale: | Poisoning writes an arbitrary value to freed pages, so any modification or
reference to that page after being freed or before being initialized will be
detected and prevented.
This prevents many types of use-after-free vulnerabilities at little performance cost.
Also prevents leak of data and detection of corrupted memory. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_zipl_page_poison_argument | | Identifiers and References | | |
|
Rule
Enable SLUB/SLAB allocator poisoning in zIPL
[ref] | To enable poisoning of SLUB/SLAB objects,
check that all boot entries in /boot/loader/entries/*.conf have slub_debug=P
included in its options.
To ensure that new kernels and boot entries continue to enable poisoning of SLUB/SLAB objects,
add slub_debug=P to /etc/kernel/cmdline. | | Rationale: | Poisoning writes an arbitrary value to freed objects, so any modification or
reference to that object after being freed or before being initialized will be
detected and prevented.
This prevents many types of use-after-free vulnerabilities at little performance cost.
Also prevents leak of data and detection of corrupted memory. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_zipl_slub_debug_argument | | Identifiers and References | | |
|
Rule
Disable vsyscalls in zIPL
[ref] | To disable use of virtual syscalls,
check that all boot entries in /boot/loader/entries/*.conf have vsyscall=none
included in its options.
To ensure that new kernels and boot entries continue to disable virtual syscalls,
add vsyscall=none to /etc/kernel/cmdline. | | Rationale: | Virtual Syscalls provide an opportunity of attack for a user who has control
of the return instruction pointer. | | Severity: | info | | Rule ID: | xccdf_org.ssgproject.content_rule_zipl_vsyscall_argument | | Identifiers and References | References:
FPT_ASLR_EXT.1 | |
|
| Group
Network Configuration and Firewalls
Group contains 10 groups and 28 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
iptables and ip6tables
Group contains 1 group and 1 rule |
[ref]
A host-based firewall called netfilter is included as
part of the Linux kernel distributed with the system. It is
activated by default. This firewall is controlled by the program
iptables, and the entire capability is frequently referred to by
this name. An analogous program called ip6tables handles filtering
for IPv6.
Unlike TCP Wrappers, which depends on the network server
program to support and respect the rules written, netfilter
filtering occurs at the kernel level, before a program can even
process the data from the network packet. As such, any program on
the system is affected by the rules written.
This section provides basic information about strengthening
the iptables and ip6tables configurations included with the system.
For more complete information that may allow the construction of a
sophisticated ruleset tailored to your environment, please consult
the references at the end of this section. |
| Group
Inspect and Activate Default Rules
Group contains 1 rule |
[ref]
View the currently-enforced iptables rules by running
the command:
$ sudo iptables -nL --line-numbers
The command is analogous for ip6tables.
If the firewall does not appear to be active (i.e., no rules
appear), activate it and ensure that it starts at boot by issuing
the following commands (and analogously for ip6tables):
$ sudo service iptables restart
The default iptables rules are:
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
5 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
1 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
The ip6tables default rules are essentially the same. |
Rule
Verify iptables Enabled
[ref] |
The iptables service can be enabled with the following manifest:
---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 75-master-iptables-enable
spec:
config:
ignition:
version: 3.1.0
systemd:
units:
- name: iptables.service
enabled: true
This will enable the iptables service in all the
nodes labeled with the "master" role.
Note that this needs to be done for each MachineConfigPool
For more information on how to configure nodes with the Machine Config
Operator see
the relevant documentation.
| | Rationale: | The iptables service provides the system's host-based firewalling
capability for IPv4 and ICMP. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_service_iptables_enabled | | Identifiers and References | References:
1, 11, 12, 13, 14, 15, 16, 18, 3, 4, 6, 8, 9, APO01.06, APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, 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 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.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.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, CIP-003-8 R4, CIP-003-8 R5, CIP-004-6 R3, AC-4, CM-7(b), CA-3(5), SC-7(21), CM-6(a), DE.AE-1, ID.AM-3, PR.AC-5, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4 | |
|
| Group
IPv6
Group contains 1 group and 6 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 6 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
Configure Accepting Router Advertisements on All IPv6 Interfaces
[ref] | To set the runtime status of the net.ipv6.conf.all.accept_ra kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.all.accept_ra=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_ra = 0 | | Rationale: | An illicit router advertisement 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_ra | | Identifiers and References | Identifiers:
CCE-82467-2 References:
11, 14, 3, 9, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, 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 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 | |
|
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:
BP28(R22), 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 | |
|
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:
BP28(R22), 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 | |
|
Rule
Disable Accepting Router Advertisements on all IPv6 Interfaces by Default
[ref] | To set the runtime status of the net.ipv6.conf.default.accept_ra kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.default.accept_ra=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_ra = 0 | | Rationale: | An illicit router advertisement 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_ra | | Identifiers and References | Identifiers:
CCE-82468-0 References:
11, 14, 3, 9, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, 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 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 | |
|
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:
BP28(R22), 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 | |
|
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:
BP28(R22), 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, SRG-OS-000480-GPOS-00227 | |
|
| Group
Kernel Parameters Which Affect Networking
Group contains 2 groups and 15 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 13 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 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:
BP28(R22), 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 | |
|
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:
BP28(R22), 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 | |
|
Rule
Enable Kernel Parameter to Log Martian Packets on all IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.log_martians kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.log_martians=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.log_martians = 1 | | Rationale: | The presence of "martian" packets (which have impossible addresses)
as well as spoofed packets, source-routed packets, and redirects could be a
sign of nefarious network activity. Logging these packets enables this activity
to be detected. | | Severity: | unknown | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_log_martians | | Identifiers and References | Identifiers:
CCE-82486-2 References:
BP28(R22), 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, DSS01.04, DSS03.05, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.06, 3.1.20, CCI-000126, 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.11.2.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.6.2.1, A.6.2.2, A.9.1.2, CM-7(a), CM-7(b), SC-5(3)(a), DE.CM-1, PR.AC-3, PR.DS-4, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000480-GPOS-00227 | |
|
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:
BP28(R22), 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, SRG-OS-000480-GPOS-00227 | |
|
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:
BP28(R22), 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, SRG-OS-000480-GPOS-00227 | |
|
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:
BP28(R22), 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, SRG-OS-000480-GPOS-00227 | |
|
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:
BP28(R22), 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 | |
|
Rule
Enable Kernel Paremeter to Log Martian Packets on all IPv4 Interfaces by Default
[ref] | To set the runtime status of the net.ipv4.conf.default.log_martians kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.log_martians=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.log_martians = 1 | | Rationale: | The presence of "martian" packets (which have impossible addresses)
as well as spoofed packets, source-routed packets, and redirects could be a
sign of nefarious network activity. Logging these packets enables this activity
to be detected. | | Severity: | unknown | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_log_martians | | Identifiers and References | Identifiers:
CCE-82487-0 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, DSS01.04, DSS03.05, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.06, 3.1.20, CCI-000126, 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.11.2.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.6.2.1, A.6.2.2, A.9.1.2, CM-7(a), CM-7(b), SC-5(3)(a), DE.CM-1, PR.AC-3, PR.DS-4, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000480-GPOS-00227 | |
|
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:
BP28(R22), 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 | |
|
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:
BP28(R22), 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 | |
|
Rule
Enable Kernel Parameter to Ignore ICMP Broadcast Echo Requests on IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.icmp_echo_ignore_broadcasts kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.icmp_echo_ignore_broadcasts = 1 | | Rationale: | Responding to broadcast (ICMP) echoes facilitates network mapping
and provides a vector for amplification attacks.
Ignoring ICMP echo requests (pings) sent to broadcast or multicast
addresses makes the system slightly more difficult to enumerate on the network. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_icmp_echo_ignore_broadcasts | | Identifiers and References | Identifiers:
CCE-82491-2 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, 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 | |
|
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:
BP28(R22), 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, SRG-OS-000480-GPOS-00227 | |
|
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:
BP28(R22), 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, SRG-OS-000480-GPOS-00227, SRG-OS-000420-GPOS-00186, SRG-OS-000142-GPOS-00071 | |
|
| Group
Network Parameters for Hosts Only
Group contains 2 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:
BP28(R22), 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 | |
|
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:
BP28(R22), 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 | |
|
| Group
Uncommon Network Protocols
Group contains 5 rules |
[ref]
The system includes support for several network protocols which are not commonly used.
Although security vulnerabilities in kernel networking code are not frequently discovered,
the consequences can be dramatic. Ensuring uncommon network protocols are disabled
reduces the system's risk to attacks targeted at its implementation of those protocols. Warning:
Although these protocols are not commonly used, avoid disruption
in your network environment by ensuring they are not needed
prior to disabling them. |
Rule
Disable ATM Support
[ref] | The Asynchronous Transfer Mode (ATM) is a protocol operating on
network, data link, and physical layers, based on virtual circuits
and virtual paths.
To configure the system to prevent the atm
kernel module from being loaded, add the following line to the file /etc/modprobe.d/atm.conf:
install atm /bin/true | | Rationale: | Disabling ATM protects the system against exploitation of any
flaws in its implementation. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_atm_disabled | | Identifiers and References | Identifiers:
CCE-82518-2 References:
CCI-000381, AC-18, FMT_SMF_EXT.1, SRG-OS-000095-GPOS-00049 | |
|
Rule
Disable CAN Support
[ref] | The Controller Area Network (CAN) is a serial communications
protocol which was initially developed for automotive and
is now also used in marine, industrial, and medical applications.
To configure the system to prevent the can
kernel module from being loaded, add the following line to the file /etc/modprobe.d/can.conf:
install can /bin/true | | Rationale: | Disabling CAN protects the system against exploitation of any
flaws in its implementation. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_can_disabled | | Identifiers and References | Identifiers:
CCE-82519-0 References:
CCI-000381, AC-18, FMT_SMF_EXT.1, SRG-OS-000095-GPOS-00049 | |
|
Rule
Disable IEEE 1394 (FireWire) Support
[ref] | The IEEE 1394 (FireWire) is a serial bus standard for
high-speed real-time communication.
To configure the system to prevent the firewire-core
kernel module from being loaded, add the following line to the file /etc/modprobe.d/firewire-core.conf:
install firewire-core /bin/true | | Rationale: | Disabling FireWire protects the system against exploitation of any
flaws in its implementation. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_firewire-core_disabled | | Identifiers and References | Identifiers:
CCE-82517-4 References:
CCI-000381, AC-18, FMT_SMF_EXT.1, SRG-OS-000095-GPOS-00049 | |
|
Rule
Disable SCTP Support
[ref] | The Stream Control Transmission Protocol (SCTP) is a
transport layer protocol, designed to support the idea of
message-oriented communication, with several streams of messages
within one connection.
To configure the system to prevent the sctp
kernel module from being loaded, add the following line to the file /etc/modprobe.d/sctp.conf:
install sctp /bin/true | | Rationale: | Disabling SCTP protects
the system against exploitation of any flaws in its implementation. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_sctp_disabled | | Identifiers and References | Identifiers:
CCE-82516-6 References:
11, 14, 3, 9, 5.10.1, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, 3.4.6, CCI-000381, 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-000095-GPOS-00049 | |
|
Rule
Disable TIPC Support
[ref] | The Transparent Inter-Process Communication (TIPC) protocol
is designed to provide communications between nodes in a
cluster.
To configure the system to prevent the tipc
kernel module from being loaded, add the following line to the file /etc/modprobe.d/tipc.conf:
install tipc /bin/true Warning:
This configuration baseline was created to deploy the base operating system for general purpose
workloads. When the operating system is configured for certain purposes, such as
a node in High Performance Computing cluster, it is expected that
the tipc kernel module will be loaded. | | Rationale: | Disabling TIPC protects
the system against exploitation of any flaws in its implementation. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_tipc_disabled | | Identifiers and References | Identifiers:
CCE-82520-8 References:
11, 14, 3, 9, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, CCI-000381, 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, FMT_SMF_EXT.1, SRG-OS-000095-GPOS-00049 | |
|
| Group
Wireless Networking
Group contains 1 group and 1 rule |
[ref]
Wireless networking, such as 802.11
(WiFi) and Bluetooth, can present a security risk to sensitive or
classified systems and networks. Wireless networking hardware is
much more likely to be included in laptop or portable systems than
in desktops or servers.
Removal of hardware provides the greatest assurance that the wireless
capability remains disabled. Acquisition policies often include provisions to
prevent the purchase of equipment that will be used in sensitive spaces and
includes wireless capabilities. If it is impractical to remove the wireless
hardware, and policy permits the device to enter sensitive spaces as long
as wireless is disabled, efforts should instead focus on disabling wireless capability
via software. |
| Group
Disable Wireless Through Software Configuration
Group contains 1 rule |
[ref]
If it is impossible to remove the wireless hardware
from the device in question, disable as much of it as possible
through software. The following methods can disable software
support for wireless networking, but note that these methods do not
prevent malicious software or careless users from re-activating the
devices. |
Rule
Disable Bluetooth Kernel Module
[ref] | The kernel's module loading system can be configured to prevent
loading of the Bluetooth module. Add the following to
the appropriate /etc/modprobe.d configuration file
to prevent the loading of the Bluetooth module:
install bluetooth /bin/true | | Rationale: | If Bluetooth functionality must be disabled, preventing the kernel
from loading the kernel module provides an additional safeguard against its
activation. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_bluetooth_disabled | | Identifiers and References | Identifiers:
CCE-82515-8 References:
11, 12, 14, 15, 3, 8, 9, 5.13.1.3, APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.04, DSS05.02, DSS05.03, DSS05.05, DSS06.06, 3.1.16, CCI-000085, CCI-001551, CCI-001443, 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 7.1, SR 7.6, A.11.2.6, A.12.1.2, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.2.1, A.6.2.2, A.9.1.2, AC-18(a), AC-18(3), CM-7(a), CM-7(b), CM-6(a), MP-7, PR.AC-3, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000095-GPOS-00049, SRG-OS-000300-GPOS-00118 | |
|
| Group
File Permissions and Masks
Group contains 7 groups and 39 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 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. |
Rule
Enable Kernel Parameter to Enforce DAC on Hardlinks
[ref] | To set the runtime status of the fs.protected_hardlinks kernel parameter, run the following command: $ sudo sysctl -w fs.protected_hardlinks=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: fs.protected_hardlinks = 1 | | Rationale: | By enabling this kernel parameter, users can no longer create soft or hard links to
files which they do not own. Disallowing such hardlinks mitigate vulnerabilities
based on insecure file system accessed by privileged programs, avoiding an
exploitation vector exploiting unsafe use of open() or creat(). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_fs_protected_hardlinks | | Identifiers and References | Identifiers:
CCE-82506-7 References:
BP28(R23), CCI-002165, 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), SRG-OS-000312-GPOS-00123, SRG-OS-000324-GPOS-00125 | |
|
Rule
Enable Kernel Parameter to Enforce DAC on Symlinks
[ref] | To set the runtime status of the fs.protected_symlinks kernel parameter, run the following command: $ sudo sysctl -w fs.protected_symlinks=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: fs.protected_symlinks = 1 | | Rationale: | By enabling this kernel parameter, symbolic links are permitted to be followed
only when outside a sticky world-writable directory, or when the UID of the
link and follower match, or when the directory owner matches the symlink's owner.
Disallowing such symlinks helps mitigate vulnerabilities based on insecure file system
accessed by privileged programs, avoiding an exploitation vector exploiting unsafe use of
open() or creat(). | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_fs_protected_symlinks | | Identifiers and References | Identifiers:
CCE-82507-5 References:
BP28(R23), CCI-002165, 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), SRG-OS-000312-GPOS-00123, SRG-OS-000324-GPOS-00125 | |
|
| Group
Restrict Dynamic Mounting and Unmounting of
Filesystems
Group contains 1 rule |
[ref]
Linux includes a number of facilities for the automated addition
and removal of filesystems on a running system. These facilities may be
necessary in many environments, but this capability also carries some risk -- whether direct
risk from allowing users to introduce arbitrary filesystems,
or risk that software flaws in the automated mount facility itself could
allow an attacker to compromise the system.
This command can be used to list the types of filesystems that are
available to the currently executing kernel:
$ find /lib/modules/`uname -r`/kernel/fs -type f -name '*.ko'
If these filesystems are not required then they can be explicitly disabled
in a configuratio file in /etc/modprobe.d. |
Rule
Disable Mounting of cramfs
[ref] |
To configure the system to prevent the cramfs
kernel module from being loaded, add the following line to the file /etc/modprobe.d/cramfs.conf:
install cramfs /bin/true
This effectively prevents usage of this uncommon filesystem.
The cramfs filesystem type is a compressed read-only
Linux filesystem embedded in small footprint systems. A
cramfs image can be used without having to first
decompress the image. | | Rationale: | Removing support for unneeded filesystem types reduces the local attack surface
of the server. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_cramfs_disabled | | Identifiers and References | Identifiers:
CCE-82514-1 References:
11, 14, 3, 9, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, 3.4.6, CCI-000381, 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-000095-GPOS-00049 | |
|
| Group
Restrict Partition Mount Options
Group contains 21 rules |
[ref]
System partitions can be mounted with certain options
that limit what files on those partitions can do. These options
are set in the /etc/fstab configuration file, and can be
used to make certain types of malicious behavior more difficult. |
Rule
Add nodev Option to /boot
[ref] | The nodev mount option can be used to prevent device files from
being created in /boot.
Legitimate character and block devices should exist only in
the /dev directory on the root partition or within chroot
jails built for system services.
Add the nodev option to the list of
Options in the systemd.mount unit that
controls mounting of
/boot. | | Rationale: | The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_boot_nodev | | Identifiers and References | References:
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-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7, PR.IP-1, PR.PT-2, PR.PT-3, SRG-OS-000368-GPOS-00154 | |
|
Rule
Add nosuid Option to /boot
[ref] | The nosuid mount option can be used to prevent
execution of setuid programs in /boot. The SUID and SGID permissions
should not be required on the boot partition.
Add the nosuid option to the list of
Options in the systemd.mount unit that
controls mounting of
/boot. | | Rationale: | The presence of SUID and SGID executables should be tightly controlled. Users
should not be able to execute SUID or SGID binaries from boot partitions. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_boot_nosuid | | Identifiers and References | References:
BP28(R12), CCI-000366, 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-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7, PR.IP-1, PR.PT-2, PR.PT-3, SRG-OS-000368-GPOS-00154, SRG-OS-000480-GPOS-00227 | |
|
Rule
Add nodev Option to /dev/shm
[ref] | The nodev mount option can be used to prevent creation of device
files in /dev/shm. Legitimate character and block devices should
not exist within temporary directories like /dev/shm.
Add the nodev option to the list of
Options in the systemd.mount unit that
controls mounting of
/dev/shm. | | Rationale: | The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_dev_shm_nodev | | Identifiers and References | Identifiers:
CCE-82867-3 References:
11, 13, 14, 3, 8, 9, APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS05.06, DSS06.06, CCI-001764, 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.11.2.9, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.8.2.1, A.8.2.2, A.8.2.3, A.8.3.1, A.8.3.3, A.9.1.2, 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-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7, PR.IP-1, PR.PT-2, PR.PT-3, SRG-OS-000368-GPOS-00154 | |
|
Rule
Add noexec Option to /dev/shm
[ref] | The noexec mount option can be used to prevent binaries
from being executed out of /dev/shm.
It can be dangerous to allow the execution of binaries
from world-writable temporary storage directories such as /dev/shm.
Add the noexec option to the list of
Options in the systemd.mount unit that
controls mounting of
/dev/shm. | | Rationale: | Allowing users to execute binaries from world-writable directories
such as /dev/shm can expose the system to potential compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_dev_shm_noexec | | Identifiers and References | Identifiers:
CCE-82868-1 References:
11, 13, 14, 3, 8, 9, APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS05.06, DSS06.06, CCI-001764, 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.11.2.9, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.8.2.1, A.8.2.2, A.8.2.3, A.8.3.1, A.8.3.3, A.9.1.2, 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-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7, PR.IP-1, PR.PT-2, PR.PT-3, SRG-OS-000368-GPOS-00154 | |
|
Rule
Add nosuid Option to /dev/shm
[ref] | The nosuid mount option can be used to prevent execution
of setuid programs in /dev/shm. The SUID and SGID permissions should not
be required in these world-writable directories.
Add the nosuid option to the list of
Options in the systemd.mount unit that
controls mounting of
/dev/shm. | | Rationale: | The presence of SUID and SGID executables should be tightly controlled. Users
should not be able to execute SUID or SGID binaries from temporary storage partitions. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_dev_shm_nosuid | | Identifiers and References | Identifiers:
CCE-82741-0 References:
11, 13, 14, 3, 8, 9, APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS05.06, DSS06.06, CCI-001764, 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.11.2.9, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.8.2.1, A.8.2.2, A.8.2.3, |
|