| Group
Guide to the Secure Configuration of Red Hat Enterprise Linux CoreOS 4
Group contains 63 groups and 248 rules |
| Group
System Settings
Group contains 43 groups and 174 rules |
[ref]
Contains rules that check correct system settings. |
| Group
Installing and Maintaining Software
Group contains 7 groups and 26 rules |
[ref]
The following sections contain information on
security-relevant choices during the initial operating system
installation process and the setup of software
updates. |
| Group
System and Software Integrity
Group contains 3 groups and 3 rules |
[ref]
System and software integrity can be gained by installing antivirus, increasing
system encryption strength with FIPS, verifying installed software, enabling SELinux,
installing an Intrusion Prevention System, etc. However, installing or enabling integrity
checking tools cannot prevent intrusions, but they can detect that an intrusion
may have occurred. Requirements for integrity checking may be highly dependent on
the environment in which the system will be used. Snapshot-based approaches such
as AIDE may induce considerable overhead in the presence of frequent software updates. |
| Group
Software Integrity Checking
Group contains 1 group and 2 rules |
[ref]
Both the AIDE (Advanced Intrusion Detection Environment)
software and the RPM package management system provide
mechanisms for verifying the integrity of installed software.
AIDE uses snapshots of file metadata (such as hashes) and compares these
to current system files in order to detect changes.
The RPM package management system can conduct integrity
checks by comparing information in its metadata database with
files installed on the system. |
| Group
Verify Integrity with AIDE
Group contains 2 rules |
[ref]
AIDE conducts integrity checks by comparing information about
files with previously-gathered information. Ideally, the AIDE database is
created immediately after initial system configuration, and then again after any
software update. AIDE is highly configurable, with further configuration
information located in /usr/share/doc/aide-VERSION
. |
Rule
Install AIDE
[ref] | The aide package can be installed with the following command:
$ sudo dnf install aide
| | Rationale: | The AIDE package must be installed if it is to be available for integrity checking. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_aide_installed | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | | cjis | 5.10.1.3 | | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | | ism | 1034, 1288, 1341, 1417 | | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | | nist | CM-6(a) | | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | | pcidss | Req-11.5 | | os-srg | SRG-OS-000445-GPOS-00199 | | anssi | R76, R79 | | pcidss4 | 11.5.2 |
| |
|
Rule
Build and Test AIDE Database
[ref] | Run the following command to generate a new database:
$ sudo /usr/sbin/aide --init
By default, the database will be written to the file
/var/lib/aide/aide.db.new.gz.
Storing the database, the configuration file /etc/aide.conf, and the binary
/usr/sbin/aide
(or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity.
The newly-generated database can be installed as follows:
$ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
To initiate a manual check, run the following command:
$ sudo /usr/sbin/aide --check
If this check produces any unexpected output, investigate. | | Rationale: | For AIDE to be effective, an initial database of "known-good" information about files
must be captured and it should be able to be verified against the installed files. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_aide_build_database | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | | cjis | 5.10.1.3 | | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | | nist | CM-6(a) | | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | | pcidss | Req-11.5 | | os-srg | SRG-OS-000445-GPOS-00199 | | anssi | R76, R79 | | pcidss4 | 11.5.2 |
| |
|
| Group
Federal Information Processing Standard (FIPS)
Group contains 1 rule |
[ref]
The Federal Information Processing Standard (FIPS) is a computer security standard which
is developed by the U.S. Government and industry working groups to validate the quality
of cryptographic modules. The FIPS standard provides four security levels to ensure
adequate coverage of different industries, implementation of cryptographic modules, and
organizational sizes and requirements.
FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules
utilize authentication that meets industry and government requirements. For government systems, this allows
Security Levels 1, 2, 3, or 4 for use on Red Hat Enterprise Linux CoreOS 4.
See http://csrc.nist.gov/publications/PubsFIPS.html for more information. |
Rule
Install the dracut-fips-aesni Package
[ref] | To enable FIPS on system that support the Advanced Encryption Standard (AES) or New
Instructions (AES-NI) engine, the system requires that the dracut-fips-aesni
package be installed.
The dracut-fips-aesni package can be installed with the following command:
$ sudo dnf install dracut-fips-aesni
Warning:
The system needs to be rebooted for these changes to take effect. Warning:
System Crypto Modules must be provided by a vendor that undergoes
FIPS-140 certifications.
FIPS-140 is applicable to all Federal agencies that use
cryptographic-based security systems to protect sensitive information
in computer and telecommunication systems (including voice systems) as
defined in Section 5131 of the Information Technology Management Reform
Act of 1996, Public Law 104-106. This standard shall be used in
designing and implementing cryptographic modules that Federal
departments and agencies operate or are operated for them under
contract. See https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf
To meet this, the system has to have cryptographic software provided by
a vendor that has undergone this certification. This means providing
documentation, test results, design information, and independent third
party review by an accredited lab. While open source software is
capable of meeting this, it does not meet FIPS-140 unless the vendor
submits to this process. | | Rationale: | Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to
protect data. The operating system must implement cryptographic modules adhering to the higher
standards approved by the federal government since this provides assurance they have been tested
and validated. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_dracut-fips-aesni_installed | | References: | | cis-csc | 12, 15, 8 | | cjis | 5.10.1.2 | | cobit5 | APO13.01, DSS01.04, DSS05.02, DSS05.03 | | cui | 3.13.11, 3.13.8 | | isa-62443-2009 | 4.3.3.6.6 | | isa-62443-2013 | SR 1.13, SR 2.6, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | | iso27001-2013 | A.11.2.6, A.13.1.1, A.13.2.1, A.14.1.3, A.6.2.1, A.6.2.2 | | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1 | | nist | SC-12(2), SC-12(3), IA-7, SC-13, CM-6(a), SC-12 | | nist-csf | PR.AC-3, PR.PT-4 | | os-srg | SRG-OS-000033-GPOS-00014, SRG-OS-000396-GPOS-00176, SRG-OS-000478-GPOS-00223 | | anssi | R1 |
| |
|
| Group
Disk Partitioning
Group contains 7 rules |
[ref]
To ensure separation and protection of data, there
are top-level system directories which should be placed on their
own physical partition or logical volume. The installer's default
partitioning scheme creates separate logical volumes for
/, /boot, and swap.
- If starting with any of the default layouts, check the box to
\"Review and modify partitioning.\" This allows for the easy creation
of additional logical volumes inside the volume group already
created, though it may require making
/'s logical volume smaller to
create space. In general, using logical volumes is preferable to
using partitions because they can be more easily adjusted
later. - If creating a custom layout, create the partitions mentioned in
the previous paragraph (which the installer will require anyway),
as well as separate ones described in the following sections.
If a system has already been installed, and the default
partitioning
scheme was used, it is possible but nontrivial to
modify it to create separate logical volumes for the directories
listed above. The Logical Volume Manager (LVM) makes this possible. |
Rule
Ensure /home Located On Separate Partition
[ref] | If user home directories will be stored locally, create a separate partition
for /home at installation time (or migrate it later using LVM). If
/home will be mounted from another system such as an NFS server, then
creating a separate partition is not necessary at installation time, and the
mountpoint can instead be configured later. | | Rationale: | Ensuring that /home is mounted on its own partition enables the
setting of more restrictive mount options, and also helps ensure that
users cannot trivially fill partitions used for log or audit data storage. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_home | | Identifiers: | CCE-82739-4 | | References: | | cis-csc | 12, 15, 8 | | cobit5 | APO13.01, DSS05.02 | | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | | iso27001-2013 | A.13.1.1, A.13.2.1, A.14.1.3 | | nist | CM-6(a), SC-5(2) | | nist-csf | PR.PT-4 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R28 |
| |
|
Rule
Ensure /srv Located On Separate Partition
[ref] | If a file server (FTP, TFTP...) is hosted locally, create a separate partition
for /srv at installation time (or migrate it later using LVM). If
/srv will be mounted from another system such as an NFS server, then
creating a separate partition is not necessary at installation time, and the
mountpoint can instead be configured later. | | Rationale: | Srv deserves files for local network file server such as FTP. Ensuring
that /srv is mounted on its own partition enables the setting of
more restrictive mount options, and also helps ensure that
users cannot trivially fill partitions used for log or audit data storage. | | Severity: | unknown | | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_srv | | References: | | |
|
Rule
Ensure /var Located On Separate Partition
[ref] | The /var directory is used by daemons and other system
services to store frequently-changing data. Ensure that /var has its own partition
or logical volume at installation time, or migrate it using LVM. | | Rationale: | Ensuring that /var is mounted on its own partition enables the
setting of more restrictive mount options. This helps protect
system services such as daemons or other programs which use it.
It is not uncommon for the /var directory to contain
world-writable directories installed by other software packages. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var | | References: | | cis-csc | 12, 15, 8 | | cobit5 | APO13.01, DSS05.02 | | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | | iso27001-2013 | A.13.1.1, A.13.2.1, A.14.1.3 | | nist | CM-6(a), SC-5(2) | | nist-csf | PR.PT-4 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R28 |
| |
|
Rule
Ensure /var/log Located On Separate Partition
[ref] | System logs are stored in the /var/log directory.
Partitioning Red Hat CoreOS is a Day 1 operation and cannot
be changed afterwards. For documentation on how to add a
MachineConfig manifest that specifies a separate /var/log
partition, follow:
https://docs.openshift.com/container-platform/latest/installing/installing_platform_agnostic/installing-platform-agnostic.html#installation-user-infra-machines-advanced_disk_installing-platform-agnostic
Note that the Red Hat OpenShift documentation often references a block
device, such as /dev/vda. The name of the available block devices depends
on the underlying infrastructure (bare metal vs cloud), and often the specific
instance type. For example in AWS, some instance types have NVMe drives
(/dev/nvme*), others use /dev/xvda*.
You will need to look for relevant documentation for your infrastructure around this.
In many cases, the simplest thing is to boot a single machine with an Ignition
configuration that just gives you SSH access, and inspect the block devices via
e.g. the lsblk command.
For physical hardware, a good best practice is to reference devices via the
/dev/disk/by-id/ or /dev/disk/by-path links.
| | Rationale: | Placing /var/log in its own partition
enables better separation between log files
and other files in /var/. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var_log | | Identifiers: | CCE-82737-8 | | References: | | cis-csc | 1, 12, 14, 15, 16, 3, 5, 6, 8 | | cobit5 | APO11.04, APO13.01, BAI03.05, DSS05.02, DSS05.04, DSS05.07, MEA02.01 | | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | | iso27001-2013 | A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3 | | nerc-cip | CIP-007-3 R6.5 | | nist | CM-6(a), AU-4, SC-5(2) | | nist-csf | PR.PT-1, PR.PT-4 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R28 |
| |
|
Rule
Ensure /var/log/audit Located On Separate Partition
[ref] | Audit logs are stored in the /var/log/audit directory.
Partitioning Red Hat CoreOS is a Day 1 operation and cannot
be changed afterwards. For documentation on how to add a
MachineConfig manifest that specifies a separate /var/log/audit
partition, follow:
https://docs.openshift.com/container-platform/latest/installing/installing_platform_agnostic/installing-platform-agnostic.html#installation-user-infra-machines-advanced_disk_installing-platform-agnostic
Note that the Red Hat OpenShift documentation often references a block
device, such as /dev/vda. The name of the available block devices depends
on the underlying infrastructure (bare metal vs cloud), and often the specific
instance type. For example in AWS, some instance types have NVMe drives
(/dev/nvme*), others use /dev/xvda*.
You will need to look for relevant documentation for your infrastructure around this.
In many cases, the simplest thing is to boot a single machine with an Ignition
configuration that just gives you SSH access, and inspect the block devices via
e.g. the lsblk command.
For physical hardware, a good best practice is to reference devices via the
/dev/disk/by-id/ or /dev/disk/by-path links.
Make absolutely certain that it is large enough to store all
audit logs that will be created by the auditing daemon. | | Rationale: | Placing /var/log/audit in its own partition
enables better separation between audit files
and other files, and helps ensure that
auditing cannot be halted due to the partition running out
of space. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var_log_audit | | Identifiers: | CCE-82738-6 | | References: | | cis-csc | 1, 12, 13, 14, 15, 16, 2, 3, 5, 6, 8 | | cobit5 | APO11.04, APO13.01, BAI03.05, BAI04.04, DSS05.02, DSS05.04, DSS05.07, MEA02.01 | | hipaa | 164.312(a)(2)(ii) | | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.2, SR 7.6 | | iso27001-2013 | 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 | | nerc-cip | CIP-007-3 R6.5 | | nist | CM-6(a), AU-4, SC-5(2) | | nist-csf | PR.DS-4, PR.PT-1, PR.PT-4 | | ospp | FMT_SMF_EXT.1 | | os-srg | SRG-OS-000341-GPOS-00132, SRG-OS-000480-GPOS-00227 | | app-srg-ctr | SRG-APP-000357-CTR-000800, CNTR-OS-000200, CNTR-OS-000670 | | anssi | R71 |
| |
|
Rule
Ensure /var/tmp Located On Separate Partition
[ref] | The /var/tmp directory is a world-writable directory used
for temporary file storage. Ensure it has its own partition or
logical volume at installation time, or migrate it using LVM. | | Rationale: | The /var/tmp partition is used as temporary storage by many programs.
Placing /var/tmp in its own partition enables the setting of more
restrictive mount options, which can help protect programs which use it. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var_tmp | | Identifiers: | CCE-82734-5 | | References: | | |
|
Rule
Ensure tmp.mount Unit Is Enabled
[ref] | The /tmp directory is a world-writable directory used
for temporary file storage. This directory is managed by systemd-tmpfiles.
Ensure that the tmp.mount systemd unit is enabled. | | Rationale: | The /tmp directory is used as temporary storage by many programs.
Placing /tmp in a tmpfs filesystem enables the setting of more
restrictive mount options, which can help protect programs which use it.
The tmp.mount unit configures the tmpfs filesystem and ensures
the /tmp directory is wiped during reboot. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_systemd_tmp_mount_enabled | | References: | | |
|
| Group
Sudo
Group contains 14 rules |
[ref]
Sudo, which stands for "su 'do'", provides the ability to delegate authority
to certain users, groups of users, or system administrators. When configured for system
users and/or groups, Sudo can allow a user or group to execute privileged commands
that normally only root is allowed to execute.
For more information on Sudo and addition Sudo configuration options, see
https://www.sudo.ws. |
Rule
Install sudo Package
[ref] | The sudo package can be installed with the following command:
$ sudo dnf install sudo
| | Rationale: | sudo is a program designed to allow a system administrator to give
limited root privileges to users and log root activity. The basic philosophy
is to give as few privileges as possible but still allow system users to
get their work done.
| | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_sudo_installed | | Identifiers: | CCE-82523-2 | | References: | | |
|
Rule
Verify Group Who Owns /etc/sudoers.d Directory
[ref] | To properly set the group owner of /etc/sudoers.d, run the command:
$ sudo chgrp root /etc/sudoers.d
| | Rationale: | The ownership of the /etc/sudoers.d directory by the root group is important
because this directory hosts sudo configuration. Protection of this
directory is critical for system security. Assigning the ownership to root
ensures exclusive control of the sudo configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_groupowner_etc_sudoersd | | References: | | |
|
Rule
Verify User Who Owns /etc/sudoers.d Directory
[ref] | To properly set the owner of /etc/sudoers.d, run the command:
$ sudo chown root /etc/sudoers.d
| | Rationale: | The ownership of the /etc/sudoers.d directory by the root user is important
because this directory hosts sudo configuration. Protection of this
directory is critical for system security. Assigning the ownership to root
ensures exclusive control of the sudo configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_owner_etc_sudoersd | | References: | | |
|
Rule
Verify Permissions On /etc/sudoers.d Directory
[ref] | To properly set the permissions of /etc/sudoers.d, run the command: $ sudo chmod 0750 /etc/sudoers.d
| | Rationale: | Setting correct permissions on the /etc/sudoers.d directory is important
because this directory hosts sudo configuration. Protection of this
directory is critical for system security. Restricting the permissions
ensures exclusive control of the sudo configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_permissions_etc_sudoersd | | References: | | |
|
Rule
Verify Group Who Owns /etc/sudoers File
[ref] | To properly set the group owner of /etc/sudoers, run the command:
$ sudo chgrp root /etc/sudoers
| | Rationale: | The ownership of the /etc/sudoers file by the root group is important
because this file hosts sudo configuration. Protection of this
file is critical for system security. Assigning the ownership to root
ensures exclusive control of the sudo configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_sudoers | | References: | | |
|
Rule
Verify User Who Owns /etc/sudoers File
[ref] | To properly set the owner of /etc/sudoers, run the command:
$ sudo chown root /etc/sudoers
| | Rationale: | The ownership of the /etc/sudoers file by the root user is important
because this file hosts sudo configuration. Protection of this
file is critical for system security. Assigning the ownership to root
ensures exclusive control of the sudo configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_sudoers | | References: | | |
|
Rule
Verify Permissions On /etc/sudoers File
[ref] | To properly set the permissions of /etc/sudoers, run the command: $ sudo chmod 0440 /etc/sudoers
| | Rationale: | Setting correct permissions on the /etc/sudoers file is important
because this file hosts sudo configuration. Protection of this
file is critical for system security. Restricting the permissions
ensures exclusive control of the sudo configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_sudoers | | References: | | |
|
Rule
Ensure That the sudo Binary Has the Correct Permissions
[ref] |
To properly set the permissions of /usr/bin/sudo, run the command:
$ sudo chmod 4111 /usr/bin/sudo
| | Rationale: | The sudoers program should only be usable by people who have the correct permissions. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_sudo | | References: | | |
|
Rule
Ensure Privileged Escalated Commands Cannot Execute Other Commands - sudo NOEXEC
[ref] | The sudo NOEXEC tag, when specified, prevents user executed
commands from executing other commands, like a shell for example.
This should be enabled by making sure that the NOEXEC tag exists in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/. | | Rationale: | Restricting the capability of sudo allowed commands to execute sub-commands
prevents users from running programs with privileges they wouldn't have otherwise. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_add_noexec | | References: | | |
|
Rule
Ensure Only Users Logged In To Real tty Can Execute Sudo - sudo requiretty
[ref] | The sudo requiretty tag, when specified, will only execute sudo
commands from users logged in to a real tty.
This should be enabled by making sure that the requiretty tag exists in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/. | | Rationale: | Restricting the use cases in which a user is allowed to execute sudo commands
reduces the attack surface. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_add_requiretty | | References: | | |
|
Rule
Ensure Only Users Logged In To Real tty Can Execute Sudo - sudo use_pty
[ref] | The sudo use_pty tag, when specified, will only execute sudo
commands from users logged in to a real tty.
This should be enabled by making sure that the use_pty tag exists in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/. | | Rationale: | Requiring that sudo commands be run in a pseudo-terminal can prevent an attacker from retaining
access to the user's terminal after the main program has finished executing. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_add_use_pty | | References: | | |
|
Rule
Explicit arguments in sudo specifications
[ref] | All commands in the sudoers file must strictly specify the arguments allowed to be used for a given user.
If the command is supposed to be executed only without arguments, pass "" as an argument in the corresponding user specification. Warning:
This rule doesn't come with a remediation, as absence of arguments in the user spec doesn't mean that the command is intended to be executed with no arguments. Warning:
The rule can produce false findings when an argument contains a comma - sudoers syntax allows comma escaping using backslash, but the check doesn't support that. For example, root ALL=(ALL) echo 1\,2 allows root to execute echo 1,2, but the check would interpret it as two commands echo 1\ and 2. | | Rationale: | Any argument can modify quite significantly the behavior of a program, whether regarding the
realized operation (read, write, delete, etc.) or accessed resources (path in a file system tree). To
avoid any possibility of misuse of a command by a user, the ambiguities must be removed at the
level of its specification.
For example, on some systems, the kernel messages are only accessible by root.
If a user nevertheless must have the privileges to read them, the argument of the dmesg command has to be restricted
in order to prevent the user from flushing the buffer through the -c option:
user ALL = dmesg ""
| | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sudoers_explicit_command_args | | References: | | |
|
Rule
Don't define allowed commands in sudoers by means of exclusion
[ref] | Policies applied by sudo through the sudoers file should not involve negation.
Each user specification in the sudoers file contains a comma-delimited list of command specifications.
The definition can make use glob patterns, as well as of negations.
Indirect definition of those commands by means of exclusion of a set of commands is trivial to bypass, so it is not allowed to use such constructs. Warning:
This rule doesn't come with a remediation, as negations indicate design issues with the sudoers user specifications design. Just removing negations doesn't increase the security - you typically have to rethink the definition of allowed commands to fix the issue. | | Rationale: | Specifying access right using negation is inefficient and can be easily circumvented.
For example, it is expected that a specification like
# To avoid absolutely , this rule can be easily circumvented!
user ALL = ALL ,!/ bin/sh
prevents the execution of the shell
but that’s not the case: just copy the binary /bin/sh to a different name to make it executable
again through the rule keyword ALL. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sudoers_no_command_negation | | References: | | |
|
Rule
Don't target root user in the sudoers file
[ref] | The targeted users of a user specification should be, as much as possible, non privileged users (i.e.: non-root).
User specifications have to explicitly list the runas spec (i.e. the list of target users that can be impersonated), and ALL or root should not be used. Warning:
This rule doesn't come with a remediation, as the exact requirement allows exceptions, and removing lines from the sudoers file can make the system non-administrable. | | Rationale: | It is common that the command to be executed does not require superuser rights (editing a file
whose the owner is not root, sending a signal to an unprivileged process,etc.). In order to limit
any attempt of privilege escalation through a command, it is better to apply normal user rights. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sudoers_no_root_target | | References: | | |
|
| Group
Updating Software
Group contains 1 rule |
[ref]
The dnf command line tool is used to install and
update software packages. The system also provides a graphical
software update tool in the System menu, in the Administration submenu,
called Software Update.
Red Hat Enterprise Linux CoreOS 4 systems contain an installed software catalog called
the RPM database, which records metadata of installed packages. Consistently using
dnf or the graphical Software Update for all software installation
allows for insight into the current inventory of installed software on the system.
|
Rule
Ensure Red Hat GPG Key Installed
[ref] | To ensure the system can cryptographically verify base software packages
come from Red Hat (and to connect to the Red Hat Network to receive them),
the Red Hat GPG key must properly be installed. To install the Red Hat GPG
key, run:
$ sudo subscription-manager register
If the system is not connected to the Internet or an RHN Satellite, then
install the Red Hat GPG key from trusted media such as the Red Hat
installation CD-ROM or DVD. Assuming the disc is mounted in
/media/cdrom, use the following command as the root user to import
it into the keyring:
$ sudo rpm --import /media/cdrom/RPM-GPG-KEY
Alternatively, the key may be pre-loaded during the RHEL installation. In
such cases, the key can be installed by running the following command:
sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
| | Rationale: | Changes to software components can have significant effects on the overall
security of the operating system. This requirement ensures the software has
not been tampered with and that it has been provided by a trusted vendor.
The Red Hat GPG key is necessary to cryptographically verify packages are
from Red Hat. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_redhat_gpgkey_installed | | Identifiers: | CCE-82754-3 | | References: | | cis-csc | 11, 2, 3, 9 | | cjis | 5.10.4.1 | | cobit5 | APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02 | | cui | 3.4.8 | | hipaa | 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i) | | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6 | | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4 | | nerc-cip | CIP-003-8 R4.2, CIP-003-8 R6, CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | | nist | CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a) | | nist-csf | PR.DS-6, PR.DS-8, PR.IP-1 | | ospp | FPT_TUD_EXT.1, FPT_TUD_EXT.2 | | pcidss | Req-6.2 | | os-srg | SRG-OS-000366-GPOS-00153 | | anssi | R59 | | pcidss4 | 6.3.3, 6.3 |
| |
|
Rule
Prefer to use a 64-bit Operating System when supported
[ref] | Prefer installation of 64-bit operating systems when the CPU supports it. Warning:
There is no remediation besides installing a 64-bit operating system. | | Rationale: | Use of a 64-bit operating system offers a few advantages, like a larger address space range for
Address Space Layout Randomization (ASLR) and systematic presence of No eXecute and Execute Disable (NX/XD) protection bits. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_prefer_64bit_os | | References: | | |
|
| Group
Account and Access Control
Group contains 8 groups and 17 rules |
[ref]
In traditional Unix security, if an attacker gains
shell access to a certain login account, they can perform any action
or access any file to which that account has access. Therefore,
making it more difficult for unauthorized people to gain shell
access to accounts, particularly to privileged accounts, is a
necessary part of securing a system. This section introduces
mechanisms for restricting access to accounts under
Red Hat Enterprise Linux CoreOS 4. |
| Group
Protect Accounts by Configuring PAM
Group contains 2 groups and 2 rules |
[ref]
PAM, or Pluggable Authentication Modules, is a system
which implements modular authentication for Linux programs. PAM provides
a flexible and configurable architecture for authentication, and it should be configured
to minimize exposure to unnecessary risk. This section contains
guidance on how to accomplish that.
PAM is implemented as a set of shared objects which are
loaded and invoked whenever an application wishes to authenticate a
user. Typically, the application must be running as root in order
to take advantage of PAM, because PAM's modules often need to be able
to access sensitive stores of account information, such as /etc/shadow.
Traditional privileged network listeners
(e.g. sshd) or SUID programs (e.g. sudo) already meet this
requirement. An SUID root application, userhelper, is provided so
that programs which are not SUID or privileged themselves can still
take advantage of PAM.
PAM looks in the directory /etc/pam.d for
application-specific configuration information. For instance, if
the program login attempts to authenticate a user, then PAM's
libraries follow the instructions in the file /etc/pam.d/login
to determine what actions should be taken.
One very important file in /etc/pam.d is
/etc/pam.d/system-auth. This file, which is included by
many other PAM configuration files, defines 'default' system authentication
measures. Modifying this file is a good way to make far-reaching
authentication changes, for instance when implementing a
centralized authentication service. Warning:
Be careful when making changes to PAM's configuration files.
The syntax for these files is complex, and modifications can
have unexpected consequences. The default configurations shipped
with applications should be sufficient for most users. |
| Group
Set Password Quality Requirements
Group contains 1 group and 2 rules |
[ref]
The default pam_pwquality PAM module provides strength
checking for passwords. It performs a number of checks, such as
making sure passwords are not similar to dictionary words, are of
at least a certain length, are not the previous password reversed,
and are not simply a change of case from the previous password. It
can also require passwords to be in certain character classes. The
pam_pwquality module is the preferred way of configuring
password requirements.
The man pages pam_pwquality(8)
provide information on the capabilities and configuration of
each. |
| Group
Set Password Quality Requirements with pam_pwquality
Group contains 2 rules |
[ref]
The pam_pwquality PAM module can be configured to meet
requirements for a variety of policies.
For example, to configure pam_pwquality to require at least one uppercase
character, lowercase character, digit, and other (special)
character, make sure that pam_pwquality exists in /etc/pam.d/system-auth:
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth.
Next, modify the settings in /etc/security/pwquality.conf to match the following:
difok = 4
minlen = 14
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
maxrepeat = 3
The arguments can be modified to ensure compliance with
your organization's security policy. Discussion of each parameter follows. |
Rule
Ensure PAM Enforces Password Requirements - Minimum Different Categories
[ref] | The pam_pwquality module's minclass parameter controls
requirements for usage of different character classes, or types, of character
that must exist in a password before it is considered valid. For example,
setting this value to three (3) requires that any password must have characters
from at least three different categories in order to be approved. The default
value is zero (0), meaning there are no required classes. There are four
categories available:
* Upper-case characters
* Lower-case characters
* Digits
* Special characters (for example, punctuation)
Modify the minclass setting in /etc/security/pwquality.conf entry
to require 4
differing categories of characters when changing passwords. | | Rationale: | Use of a complex password helps to increase the time and resources required to compromise the password.
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts
at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The
more complex the password, the greater the number of possible combinations that need to be tested before
the password is compromised.
Requiring a minimum number of character categories makes password guessing attacks more difficult
by ensuring a larger search space. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_minclass | | References: | | cis-csc | 1, 12, 15, 16, 5 | | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | | nist | IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4) | | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | | os-srg | SRG-OS-000072-GPOS-00040 | | anssi | R68 |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session
[ref] | To configure the number of retry prompts that are permitted per-session:
Edit the pam_pwquality.so statement in
/etc/pam.d/system-auth to show
retry=3
, or a lower value if site
policy is more restrictive. The DoD requirement is a maximum of 3 prompts
per session. | | Rationale: | Setting the password retry prompts that are permitted on a per-session basis to a low value
requires some software, such as SSH, to re-connect. This can slow down and
draw additional attention to some types of password-guessing attacks. Note that this
is different from account lockout, which is provided by the pam_faillock module. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_retry | | References: | | cis-csc | 1, 11, 12, 15, 16, 3, 5, 9 | | cjis | 5.5.3 | | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 7.6 | | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | | nist | CM-6(a), AC-7(a), IA-5(4) | | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7, PR.IP-1 | | os-srg | SRG-OS-000069-GPOS-00037, SRG-OS-000480-GPOS-00227 | | anssi | R68 |
| |
|
| Group
Protect Accounts by Restricting Password-Based Login
Group contains 2 groups and 3 rules |
[ref]
Conventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the /etc/passwd and
/etc/shadow files. Password-based login is vulnerable to
guessing of weak passwords, and to sniffing and man-in-the-middle
attacks against passwords entered over a network or at an insecure
console. Therefore, mechanisms for accessing accounts by entering
usernames and passwords should be restricted to those which are
operationally necessary. |
| Group
Set Password Expiration Parameters
Group contains 2 rules |
[ref]
The file /etc/login.defs controls several
password-related settings. Programs such as passwd,
su, and
login consult /etc/login.defs to determine
behavior with regard to password aging, expiration warnings,
and length. See the man page login.defs(5) for more information.
Users should be forced to change their passwords, in order to
decrease the utility of compromised passwords. However, the need to
change passwords often should be balanced against the risk that
users will reuse or write down passwords if forced to change them
too often. Forcing password changes every 90-360 days, depending on
the environment, is recommended. Set the appropriate value as
PASS_MAX_DAYS and apply it to existing accounts with the
-M flag.
The PASS_MIN_DAYS ( -m) setting prevents password
changes for 7 days after the first change, to discourage password
cycling. If you use this setting, train users to contact an administrator
for an emergency password change in case a new password becomes
compromised. The PASS_WARN_AGE ( -W) setting gives
users 7 days of warnings at login time that their passwords are about to expire.
For example, for each existing human user USER, expiration parameters
could be adjusted to a 180 day maximum password age, 7 day minimum password
age, and 7 day warning period with the following command:
$ sudo chage -M 180 -m 7 -W 7 USER
|
Rule
Set Password Minimum Length in login.defs
[ref] | To specify password length requirements for new accounts, edit the file
/etc/login.defs and add or correct the following line:
PASS_MIN_LEN 15
The DoD requirement is 15.
The FISMA requirement is 12.
The profile requirement is
15.
If a program consults /etc/login.defs and also another PAM module
(such as pam_pwquality) during a password change operation, then
the most restrictive must be satisfied. See PAM section for more
information about enforcing password quality requirements. | | Rationale: | Requiring a minimum password length makes password
cracking attacks more difficult by ensuring a larger
search space. However, any security benefit from an onerous requirement
must be carefully weighed against usability problems, support costs, or counterproductive
behavior that may result. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_minlen_login_defs | | References: | | cis-csc | 1, 12, 15, 16, 5 | | cjis | 5.6.2.1 | | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | | cui | 3.5.7 | | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | | nist | IA-5(f), IA-5(1)(a), CM-6(a) | | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | | os-srg | SRG-OS-000078-GPOS-00046 | | anssi | R31 |
| |
|
Rule
Set Root Account Password Maximum Age
[ref] | Configure the root account to enforce a 365-day maximum password lifetime restriction by running the following command:
$ sudo chage -M 365 root
| | Rationale: | Any password, no matter how complex, can eventually be cracked. Therefore,
passwords need to be changed periodically. If the operating system does
not limit the lifetime of passwords and force users to change their
passwords, there is the risk that the operating system passwords could be
compromised. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_set_max_life_root | | References: | | |
|
| Group
Restrict Root Logins
Group contains 1 rule |
[ref]
Direct root logins should be allowed only for emergency use.
In normal situations, the administrator should access the system
via a unique unprivileged account, and then use su or sudo to execute
privileged commands. Discouraging administrators from accessing the
root account directly ensures an audit trail in organizations with
multiple administrators. Locking down the channels through which
root can connect directly also reduces opportunities for
password-guessing against the root account. The login program
uses the file /etc/securetty to determine which interfaces
should allow root logins.
The virtual devices /dev/console
and /dev/tty* represent the system consoles (accessible via
the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default
installation). The default securetty file also contains /dev/vc/*.
These are likely to be deprecated in most environments, but may be retained
for compatibility. Root should also be prohibited from connecting
via network protocols. Other sections of this document
include guidance describing how to prevent root from logging in via SSH. |
Rule
Direct root Logins Not Allowed
[ref] | To further limit access to the root account, administrators
can disable root logins at the console by editing the /etc/securetty file.
This file lists all devices the root user is allowed to login to. If the file does
not exist at all, the root user can login through any communication device on the
system, whether via the console or via a raw network interface. This is dangerous
as user can login to the system as root via Telnet, which sends the password in
plain text over the network. By default, Red Hat Enterprise Linux CoreOS 4's
/etc/securetty file only allows the root user to login at the console
physically attached to the system. To prevent root from logging in, remove the
contents of this file. To prevent direct root logins, remove the contents of this
file by typing the following command:
$ sudo echo > /etc/securetty
Warning:
This rule only checks the /etc/securetty file existence and its content.
If you need to restrict user access using the /etc/securetty file, make sure
the pam_securetty.so PAM module is properly enabled in relevant PAM files. | | Rationale: | Disabling direct root logins ensures proper accountability and multifactor
authentication to privileged accounts. Users will first login, then escalate
to privileged (root) access via su / sudo. This is required for FISMA Low
and FISMA Moderate systems. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_no_direct_root_logins | | Identifiers: | CCE-82698-2 | | References: | | cis-csc | 1, 12, 15, 16, 5 | | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | | cui | 3.1.1, 3.1.6 | | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | | nist | IA-2, CM-6(a) | | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | | anssi | R33 | | pcidss4 | 8.6.1, 8.6 |
| |
|
| Group
Secure Session Configuration Files for Login Accounts
Group contains 1 group and 12 rules |
[ref]
When a user logs into a Unix account, the system
configures the user's session by reading a number of files. Many of
these files are located in the user's home directory, and may have
weak permissions as a result of user error or misconfiguration. If
an attacker can modify or even read certain types of account
configuration information, they can often gain full access to the
affected user's account. Therefore, it is important to test and
correct configuration file permissions for interactive accounts,
particularly those of privileged users such as root or system
administrators. |
| Group
Ensure that Users Have Sensible Umask Values
Group contains 3 rules |
[ref]
The umask setting controls the default permissions
for the creation of new files.
With a default umask setting of 077, files and directories
created by users will not be readable by any other user on the
system. Users who wish to make specific files group- or
world-readable can accomplish this by using the chmod command.
Additionally, users can make all their files readable to their
group by default by setting a umask of 027 in their shell
configuration files. If default per-user groups exist (that is, if
every user has a default group whose name is the same as that
user's username and whose only member is the user), then it may
even be safe for users to select a umask of 007, making it very
easy to intentionally share files with groups of which the user is
a member.
|
Rule
Ensure the Default Bash Umask is Set Correctly
[ref] | To ensure the default umask for users of the Bash shell is set properly,
add or correct the umask setting in /etc/bashrc to read
as follows:
umask 077
| | Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read or
written to by unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_umask_etc_bashrc | | Identifiers: | CCE-84260-9 | | References: | | cis-csc | 18 | | cobit5 | APO13.01, BAI03.01, BAI03.02, BAI03.03 | | isa-62443-2009 | 4.3.4.3.3 | | iso27001-2013 | A.14.1.1, A.14.2.1, A.14.2.5, A.6.1.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | AC-6(1), CM-6(a) | | nist-csf | PR.IP-2 | | os-srg | SRG-OS-000480-GPOS-00228, SRG-OS-000480-GPOS-00227 | | anssi | R36 |
| |
|
Rule
Ensure the Default Umask is Set Correctly in login.defs
[ref] | To ensure the default umask controlled by /etc/login.defs is set properly,
add or correct the UMASK setting in /etc/login.defs to read as follows:
UMASK 077
| | Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read and
written to by unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_umask_etc_login_defs | | References: | | cis-csc | 11, 18, 3, 9 | | cobit5 | APO13.01, BAI03.01, BAI03.02, BAI03.03, BAI10.01, BAI10.02, BAI10.03, BAI10.05 | | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3 | | isa-62443-2013 | SR 7.6 | | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.1.1, A.14.2.1, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.5, A.6.1.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | AC-6(1), CM-6(a) | | nist-csf | PR.IP-1, PR.IP-2 | | os-srg | SRG-OS-000480-GPOS-00228 | | anssi | R36 |
| |
|
Rule
Ensure the Default Umask is Set Correctly in /etc/profile
[ref] | To ensure the default umask controlled by /etc/profile is set properly,
add or correct the umask setting in /etc/profile to read as follows:
umask 077
Note that /etc/profile also reads scrips within /etc/profile.d directory.
These scripts are also valid files to set umask value. Therefore, they should also be
considered during the check and properly remediated, if necessary. | | Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read or
written to by unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_umask_etc_profile | | Identifiers: | CCE-84262-5 | | References: | | cis-csc | 18 | | cobit5 | APO13.01, BAI03.01, BAI03.02, BAI03.03 | | isa-62443-2009 | 4.3.4.3.3 | | iso27001-2013 | A.14.1.1, A.14.2.1, A.14.2.5, A.6.1.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | AC-6(1), CM-6(a) | | nist-csf | PR.IP-2 | | os-srg | SRG-OS-000480-GPOS-00228, SRG-OS-000480-GPOS-00227 | | anssi | R36 |
| |
|
Rule
Configure Polyinstantiation of /tmp Directories
[ref] | To configure polyinstantiated /tmp directories, first create the parent directories
which will hold the polyinstantiation child directories. Use the following command:
$ sudo mkdir --mode 000 /tmp/tmp-inst
Then, add the following entry to /etc/security/namespace.conf:
/tmp /tmp/tmp-inst/ level root,adm
| | Rationale: | Polyinstantiation of temporary directories is a proactive security measure
which reduces chances of attacks that are made possible by /tmp
directories being world-writable. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_polyinstantiated_tmp | | References: | | |
|
Rule
Configure Polyinstantiation of /var/tmp Directories
[ref] | To configure polyinstantiated /tmp directories, first create the parent directories
which will hold the polyinstantiation child directories. Use the following command:
$ sudo mkdir --mode 000 /var/tmp/tmp-inst
Then, add the following entry to /etc/security/namespace.conf:
/var/tmp /var/tmp/tmp-inst/ level root,adm
| | Rationale: | Polyinstantiation of temporary directories is a proactive security measure
which reduces chances of attacks that are made possible by /var/tmp
directories being world-writable. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_polyinstantiated_var_tmp | | References: | | |
|
Rule
Set Interactive Session Timeout
[ref] | Setting the TMOUT option in /etc/profile ensures that
all user sessions will terminate based on inactivity.
The value of TMOUT should be exported and read only.
The TMOUT
setting in a file loaded by /etc/profile, e.g.
/etc/profile.d/tmout.sh should read as follows:
typeset -xr TMOUT=600
or
declare -xr TMOUT=600
Using the typeset keyword is preferred for wider compatibility with ksh and other shells. | | Rationale: | Terminating an idle session within a short time period reduces
the window of opportunity for unauthorized personnel to take control of a
management session enabled on the console or console port that has been
left unattended. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_tmout | | References: | | cis-csc | 1, 12, 15, 16 | | cobit5 | DSS05.04, DSS05.10, DSS06.10 | | cui | 3.1.11 | | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | | nerc-cip | CIP-004-6 R2.2.3, CIP-007-3 R5.1, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | | nist | AC-12, SC-10, AC-2(5), CM-6(a) | | nist-csf | PR.AC-7 | | os-srg | SRG-OS-000163-GPOS-00072, SRG-OS-000029-GPOS-00010 | | anssi | R32 | | pcidss4 | 8.6.1, 8.6 |
| |
|
Rule
User Initialization Files Must Be Group-Owned By The Primary Group
[ref] | Change the group owner of interactive users files to the group found
in /etc/passwd for the user. To change the group owner of a local
interactive user home directory, use the following command:
$ sudo chgrp USER_GROUP /home/USER/.INIT_FILE
This rule ensures every initialization file related to an interactive user
is group-owned by an interactive user. Warning:
Due to OVAL limitation, this rule can report a false negative in a
specific situation where two interactive users swap the group-ownership
of their respective initialization files. | | Rationale: | Local initialization files for interactive users are used to configure the
user's shell environment upon logon. Malicious modification of these files could
compromise accounts upon logon. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_user_dot_group_ownership | | References: | | |
|
Rule
User Initialization Files Must Be Owned By the Primary User
[ref] | Set the owner of the user initialization files for interactive users to
the primary owner with the following command:
$ sudo chown USER /home/USER/.*
This rule ensures every initialization file related to an interactive user
is owned by an interactive user. Warning:
Due to OVAL limitation, this rule can report a false negative in a
specific situation where two interactive users swap the ownership of
their respective initialization files. | | Rationale: | Local initialization files are used to configure the user's shell environment
upon logon. Malicious modification of these files could compromise accounts upon
logon. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_user_dot_user_ownership | | References: | | |
|
Rule
All User Files and Directories In The Home Directory Must Be Group-Owned By The Primary Group
[ref] | Change the group of a local interactive users files and directories to a
group that the interactive user is a member of. To change the group owner of a
local interactive users files and directories, use the following command:
$ sudo chgrp USER_GROUP /home/USER/FILE_DIR
This rule ensures every file or directory under the home directory related
to an interactive user is group-owned by an interactive user. Warning:
Due to OVAL limitation, this rule can report a false negative in a
specific situation where two interactive users swap the group-ownership
of folders or files in their respective home directories. | | Rationale: | If a local interactive users files are group-owned by a group of which the
user is not a member, unintended users may be able to access them. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_users_home_files_groupownership | | References: | | |
|
Rule
All User Files and Directories In The Home Directory Must Have a Valid Owner
[ref] | Either remove all files and directories from the system that
do not have a valid user, or assign a valid user to all unowned
files and directories. To assign a valid owner to a local
interactive user's files and directories, use the following command:
$ sudo chown -R USER /home/USER
This rule ensures every file or directory under the home directory related
to an interactive user is owned by an interactive user. Warning:
Due to OVAL limitation, this rule can report a false negative in a
specific situation where two interactive users swap the ownership of
folders or files in their respective home directories. | | Rationale: | If local interactive users do not own the files in their directories,
unauthorized users may be able to access them. Additionally, if files are not
owned by the user, this could be an indication of system compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_users_home_files_ownership | | References: | | |
|
Rule
All User Files and Directories In The Home Directory Must Have Mode 0750 Or Less Permissive
[ref] | Set the mode on files and directories in the local interactive user home
directory with the following command:
$ sudo chmod 0750 /home/USER/FILE_DIR
Files that begin with a "." are excluded from this requirement. | | Rationale: | If a local interactive user files have excessive permissions, unintended users
may be able to access or modify them. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_users_home_files_permissions | | References: | | |
|
Rule
Ensure All User Initialization Files Have Mode 0740 Or Less Permissive
[ref] | Set the mode of the user initialization files to 0740 with the
following command:
$ sudo chmod 0740 /home/USER/.INIT_FILE
| | Rationale: | Local initialization files are used to configure the user's shell environment
upon logon. Malicious modification of these files could compromise accounts upon
logon. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permission_user_init_files | | References: | | |
|
| Group
AppArmor
Group contains 5 rules |
[ref]
Many security vulnerabilities result from bugs in trusted programs. A trusted
program runs with privileges that attackers want to possess. The program fails
to keep that trust if there is a bug in the program that allows the attacker to
acquire said privilege.
AppArmor® is an application security solution designed specifically to apply
privilege confinement to suspect programs. AppArmor allows the administrator to
specify the domain of activities the program can perform by developing a
security profile. A security profile is a listing of files that the program may
access and the operations the program may perform. AppArmor secures
applications by enforcing good application behavior without relying on attack
signatures, so it can prevent attacks even if previously unknown
vulnerabilities are being exploited. |
Rule
Ensure AppArmor is installed
[ref] | AppArmor provide Mandatory Access Controls. | | Rationale: | Without a Mandatory Access Control system installed only the default
Discretionary Access Control system will be available. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_apparmor_installed | | References: | | os-srg | SRG-OS-000368-GPOS-00154, SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000312-GPOS-00124, SRG-OS-000324-GPOS-00125, SRG-OS-000370-GPOS-00155 | | anssi | R45 |
| |
|
Rule
Install the pam_apparmor Package
[ref] | The pam_apparmor package can be installed with the following command:
$ sudo dnf install pam_apparmor
| | Rationale: | Protection of system integrity using AppArmor depends on this package being
installed. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_pam_apparmor_installed | | References: | | nist | AC-3(4), AC-6(8), AC-6(10), CM-7(5)(b), CM-7(2), SC-7(21), CM-6(a) | | os-srg | SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000312-GPOS-00124, SRG-OS-000324-GPOS-00125, SRG-OS-000326-GPOS-00126, SRG-OS-000370-GPOS-00155, SRG-OS-000480-GPOS-00230, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00231, SRG-OS-000480-GPOS-00232 | | anssi | R45 |
| |
|
Rule
Enforce all AppArmor Profiles
[ref] | AppArmor profiles define what resources applications are able to access.
To set all profiles to enforce mode run the following command:
$ sudo aa-enforce /etc/apparmor.d/*
To list unconfined processes run the following command:
$ sudo aa-unconfined
Any unconfined processes may need to have a profile created or activated
for them and then be restarted. | | Rationale: | Security configuration requirements vary from site to site. Some sites may
mandate a policy that is stricter than the default policy, which is perfectly
acceptable. This recommendation is intended to ensure that any policies that
exist on the system are activated. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_all_apparmor_profiles_enforced | | References: | | |
|
Rule
Ensure AppArmor is Active and Configured
[ref] | Verify that the Apparmor tool is configured to
control whitelisted applications and user home directory access
control.
The apparmor service can be enabled with the following manifest:
---
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
labels:
machineconfiguration.openshift.io/role: master
name: 75-master-apparmor-enable
spec:
config:
ignition:
version: 3.1.0
systemd:
units:
- name: apparmor.service
enabled: true
This will enable the apparmor service in all the
nodes labeled with the "master" role.
Note that this needs to be done for each MachineConfigPool
For more information on how to configure nodes with the Machine Config
Operator see
the relevant documentation.
| | Rationale: | Using a whitelist provides a configuration management method for allowing
the execution of only authorized software. Using only authorized software
decreases risk by limiting the number of potential vulnerabilities.
The organization must identify authorized software programs and permit
execution of authorized software by adding each authorized program to the
"pam_apparmor" exception policy. The process used to identify software
programs that are authorized to execute on organizational information
systems is commonly referred to as whitelisting.
Verification of whitelisted software occurs prior to execution or at system
startup.
Users' home directories/folders may contain information of a sensitive
nature. Nonprivileged users should coordinate any sharing of information
with a System Administrator (SA) through shared resources.
Apparmor can confine users to their home directory, not allowing them to
make any changes outside of their own home directories. Confining users to
their home directory will minimize the risk of sharing information. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_apparmor_configured | | References: | | nist | AC-3(4), AC-6(8), AC-6(10), CM-7(5)(b), CM-7(2), SC-7(21), CM-6(a) | | os-srg | SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000312-GPOS-00124, SRG-OS-000324-GPOS-00125, SRG-OS-000326-GPOS-00126, SRG-OS-000370-GPOS-00155, SRG-OS-000480-GPOS-00230, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00231, SRG-OS-000480-GPOS-00232 | | anssi | R45 |
| |
|
Rule
Ensure AppArmor is enabled in the bootloader configuration
[ref] | Configure AppArmor to be enabled at boot time and verify that it has not been
overwritten by the bootloader boot parameters.
Note: This recommendation is designed around the grub bootloader, if LILO or
another bootloader is in use in your environment, enact equivalent settings. | | Rationale: | AppArmor must be enabled at boot time in your bootloader configuration to
ensure that the controls it provides are not overridden. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_enable_apparmor | | References: | | |
|
| Group
GRUB2 bootloader configuration
Group contains 2 groups and 22 rules |
[ref]
During the boot process, the boot loader is
responsible for starting the execution of the kernel and passing
options to it. The boot loader allows for the selection of
different kernels - possibly on different partitions or media.
The default Red Hat Enterprise Linux CoreOS 4 boot loader for x86 systems is called GRUB2.
Options it can pass to the kernel include single-user mode, which
provides root access without any authentication, and the ability to
disable SELinux. To prevent local users from modifying the boot
parameters and endangering security, protect the boot loader configuration
with a password and ensure its configuration file's permissions
are set properly. |
| Group
Non-UEFI GRUB2 bootloader configuration
Group contains 6 rules |
[ref]
Non-UEFI GRUB2 bootloader configuration |
Rule
Verify /boot/grub2/grub.cfg Group Ownership
[ref] | The file /boot/grub2/grub.cfg should
be group-owned by the root group to prevent
destruction or modification of the file.
To properly set the group owner of /boot/grub2/grub.cfg, run the command:
$ sudo chgrp root /boot/grub2/grub.cfg
| | Rationale: | The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_grub2_cfg | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.4.5 | | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-7.1 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R29 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/user.cfg Group Ownership
[ref] | The file /boot/grub2/user.cfg should be group-owned by the root
group to prevent reading or modification of the file.
To properly set the group owner of /boot/grub2/user.cfg, run the command:
$ sudo chgrp root /boot/grub2/user.cfg
| | Rationale: | The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway. Non-root users who read the boot parameters
may be able to identify weaknesses in security upon boot and be able to exploit them. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_user_cfg | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.4.5 | | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-7.1 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R29 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/grub.cfg User Ownership
[ref] | The file /boot/grub2/grub.cfg should
be owned by the root user to prevent destruction
or modification of the file.
To properly set the owner of /boot/grub2/grub.cfg, run the command:
$ sudo chown root /boot/grub2/grub.cfg
| | Rationale: | Only root should be able to modify important boot parameters. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_grub2_cfg | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.4.5 | | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-7.1 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R29 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/user.cfg User Ownership
[ref] | The file /boot/grub2/user.cfg should be owned by the root
user to prevent reading or modification of the file.
To properly set the owner of /boot/grub2/user.cfg, run the command:
$ sudo chown root /boot/grub2/user.cfg
| | Rationale: | Only root should be able to modify important boot parameters. Also, non-root users who read
the boot parameters may be able to identify weaknesses in security upon boot and be able to
exploit them. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_user_cfg | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.4.5 | | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-7.1 | | anssi | R29 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/grub.cfg Permissions
[ref] | File permissions for /boot/grub2/grub.cfg should be set to 600.
To properly set the permissions of /boot/grub2/grub.cfg, run the command:
$ sudo chmod 600 /boot/grub2/grub.cfg
| | Rationale: | Proper permissions ensure that only the root user can modify important boot
parameters. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_grub2_cfg | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.4.5 | | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | anssi | R29 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/user.cfg Permissions
[ref] | File permissions for /boot/grub2/user.cfg should be set to 600.
To properly set the permissions of /boot/grub2/user.cfg, run the command:
$ sudo chmod 600 /boot/grub2/user.cfg
| | Rationale: | Proper permissions ensure that only the root user can read or modify important boot
parameters. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_user_cfg | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.4.5 | | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | anssi | R29 | | pcidss4 | 2.2.6, 2.2 |
| |
|
| Group
UEFI GRUB2 bootloader configuration
Group contains 7 rules |
[ref]
UEFI GRUB2 bootloader configuration Warning:
UEFI generally uses vfat file systems, which does not support Unix-style permissions
managed by chmod command. In this case, in order to change file permissions for files
within /boot/efi it is necessary to update the mount options in /etc/fstab file and
reboot the system. |
Rule
Verify the UEFI Boot Loader grub.cfg Group Ownership
[ref] | The file /boot/grub2/grub.cfg should
be group-owned by the root group to prevent
destruction or modification of the file.
To properly set the group owner of /boot/grub2/grub.cfg, run the command:
$ sudo chgrp root /boot/grub2/grub.cfg
| | Rationale: | The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_efi_grub2_cfg | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.4.5 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-7.1 | | anssi | R29 |
| |
|
Rule
Verify /boot/grub2/user.cfg Group Ownership
[ref] | The file /boot/grub2/user.cfg should be group-owned by the
root group to prevent reading or modification of the file.
To properly set the group owner of /boot/grub2/user.cfg, run the command:
$ sudo chgrp root /boot/grub2/user.cfg
| | Rationale: | The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway. Non-root users who read the boot parameters
may be able to identify weaknesses in security upon boot and be able to exploit them. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_efi_user_cfg | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.4.5 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-7.1 | | anssi | R29 |
| |
|
Rule
Verify the UEFI Boot Loader grub.cfg User Ownership
[ref] | The file /boot/grub2/grub.cfg should
be owned by the root user to prevent destruction
or modification of the file.
To properly set the owner of /boot/grub2/grub.cfg, run the command:
$ sudo chown root /boot/grub2/grub.cfg
| | Rationale: | Only root should be able to modify important boot parameters. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_efi_grub2_cfg | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.4.5 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-7.1 | | anssi | R29 |
| |
|
Rule
Verify /boot/grub2/user.cfg User Ownership
[ref] | The file /boot/grub2/user.cfg should be owned by the root
user to prevent reading or modification of the file.
To properly set the owner of /boot/grub2/user.cfg, run the command:
$ sudo chown root /boot/grub2/user.cfg
| | Rationale: | Only root should be able to modify important boot parameters. Also, non-root users who read
the boot parameters may be able to identify weaknesses in security upon boot and be able to
exploit them. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_efi_user_cfg | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.4.5 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-7.1 | | anssi | R29 |
| |
|
Rule
Verify the UEFI Boot Loader grub.cfg Permissions
[ref] | File permissions for /boot/grub2/grub.cfg should be set to 700.
To properly set the permissions of /boot/grub2/grub.cfg, run the command:
$ sudo chmod 700 /boot/grub2/grub.cfg
| | Rationale: | Proper permissions ensure that only the root user can modify important boot
parameters. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_efi_grub2_cfg | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.4.5 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | anssi | R29 |
| |
|
Rule
Verify /boot/grub2/user.cfg Permissions
[ref] | File permissions for /boot/grub2/user.cfg should be set to 600.
To properly set the permissions of /boot/grub2/user.cfg, run the command:
$ sudo chmod 600 /boot/grub2/user.cfg
| | Rationale: | Proper permissions ensure that only the root user can read or modify important boot
parameters. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_efi_user_cfg | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.4.5 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | anssi | R29 |
| |
|
Rule
Set the UEFI Boot Loader Password
[ref] | The grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
Since plaintext passwords are a security risk, generate a hash for the password
by running the following command:
# grub2-setpassword
When prompted, enter the password that was selected.
Warning:
To prevent hard-coded passwords, automatic remediation of this control is not available. Remediation
must be automated as a component of machine provisioning, or followed manually as outlined above.
Also, do NOT manually add the superuser account and password to the
grub.cfg file as the grub2-mkconfig command overwrites this file. | | Rationale: | Password protection on the boot loader configuration ensures
users with physical access cannot trivially alter
important bootloader settings. These include which kernel to use,
and whether to enter single-user mode. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_uefi_password | | Identifiers: | CCE-82552-1 | | References: | | cis-csc | 11, 12, 14, 15, 16, 18, 3, 5 | | cobit5 | DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.03, DSS06.06 | | cui | 3.4.5 | | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7 | | iso27001-2013 | 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 | | nist | CM-6(a) | | nist-csf | PR.AC-4, PR.AC-6, PR.PT-3 | | ospp | FIA_UAU.1 | | os-srg | SRG-OS-000080-GPOS-00048 | | anssi | R5 |
| |
|
Rule
IOMMU configuration directive
[ref] | On x86 architecture supporting VT-d, the IOMMU manages the access control policy between the hardware devices and some
of the system critical units such as the memory.
Configure the default Grub2 kernel command line to contain iommu=force as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) iommu=force"
Warning:
Depending on the hardware, devices and operating system used, enabling IOMMU can cause hardware instabilities. Proper function and stability should be assessed before applying remediation to production systems. | | Rationale: | On x86 architectures, activating the I/OMMU prevents the system from arbitrary accesses potentially made by
hardware devices. | | Severity: | unknown | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_enable_iommu_force | | References: | | |
|
Rule
Configure L1 Terminal Fault mitigations
[ref] | L1 Terminal Fault (L1TF) is a hardware vulnerability which allows unprivileged
speculative access to data which is available in the Level 1 Data Cache when
the page table entry isn't present.
Select the appropriate mitigation by adding the argument
l1tf=full,force
to the default
GRUB 2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain l1tf= full,force as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) l1tf=full,force"
Since Linux Kernel 4.19 you can check the L1TF vulnerability state with the
following command:
cat /sys/devices/system/cpu/vulnerabilities/l1tf
Warning:
Enabling L1TF mitigations may impact performance of the system. | | Rationale: | The L1TF vulnerability allows an attacker to bypass memory access security controls imposed
by the system or hypervisor. The L1TF vulnerability allows read access to any physical memory
location that is cached in the L1 Data Cache. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_l1tf_argument | | References: | | |
|
Rule
Force kernel panic on uncorrected MCEs
[ref] | A Machine Check Exception is an error generated by the CPU itdetects an error
in itself, memory or I/O devices.
These errors may be corrected and generate a check log entry, if an error
cannot be corrected the kernel may panic or SIGBUS.
To force the kernel to panic on any uncorrected error reported by Machine Check
set the MCE tolerance to zero by adding mce=0
to the default GRUB 2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain mce=0 as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) mce=0"
| | Rationale: | Allowing uncorrected errors to result on a SIGBUS may allow an attacker to continue
trying to exploit a vulnerability such as Rowhammer. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_mce_argument | | References: | | |
|
Rule
Ensure SMAP is not disabled during boot
[ref] | The SMAP is used to prevent the supervisor mode from unintentionally reading/writing into
memory pages in the user space, it is enabled by default since Linux kernel 3.7.
But it could be disabled through kernel boot parameters.
Ensure that Supervisor Mode Access Prevention (SMAP) is not disabled by
the nosmap boot paramenter option.
Check that the line GRUB_CMDLINE_LINUX="..." within /etc/default/grub
doesn't contain the argument nosmap.
Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --remove-args="nosmap"
| | Rationale: | Disabling SMAP can facilitate exploitation of vulnerabilities caused by unintended access and
manipulation of data in the user space. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_nosmap_argument_absent | | References: | | |
|
Rule
Ensure SMEP is not disabled during boot
[ref] | The SMEP is used to prevent the supervisor mode from executing user space code,
it is enabled by default since Linux kernel 3.0. But it could be disabled through
kernel boot parameters.
Ensure that Supervisor Mode Execution Prevention (SMEP) is not disabled by
the nosmep boot paramenter option.
Check that the line GRUB_CMDLINE_LINUX="..." within /etc/default/grub
doesn't contain the argument nosmep.
Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --remove-args="nosmep"
| | Rationale: | Disabling SMEP can facilitate exploitation of certain vulnerabilities because it allows
the kernel to unintentionally execute code in less privileged memory space. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_nosmep_argument_absent | | References: | | |
|
Rule
Configure the confidence in TPM for entropy
[ref] | The TPM security chip that is available in most modern systems has a hardware RNG.
It is also used to feed the entropy pool, but generally not credited entropy.
Use rng_core.default_quality in the kernel command line to set the trust
level on the hardware generators. The trust level defines the amount of entropy to credit.
A value of 0 tells the system not to trust the hardware random number generators
available, and doesn't credit any entropy to the pool.
A value of 1000 assigns full confidence in the generators, and credits all the
entropy it provides to the pool.
Note that the value of rng_core.default_quality is global, affecting the trust
on all hardware random number generators.
Select the appropriate confidence by adding the argument
rng_core.default_quality=500
to the default
GRUB 2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain rng_core.default_quality= 500 as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) rng_core.default_quality=500"
| | Rationale: | A system may struggle to initialize its entropy pool and end up starving. Crediting entropy
from the hardware number generators available in the system helps fill up the entropy pool. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_rng_core_default_quality_argument | | References: | | |
|
Rule
Disable merging of slabs with similar size
[ref] | The kernel may merge similar slabs together to reduce overhead and increase
cache hotness of objects.
Disabling merging of slabs keeps the slabs separate and reduces the risk of
kernel heap overflows overwriting objects in merged caches.
To disable merging of slabs in the Kernel add the argument slab_nomerge=yes
to the default GRUB 2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain slab_nomerge=yes as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) slab_nomerge=yes"
Warning:
Disabling merge of slabs will slightly increase kernel memory utilization. | | Rationale: | Disabling the merge of slabs of similar sizes prevents the kernel from
merging a seemingly useless but vulnerable slab with a useful and valuable slab.
This increase the risk that a heap overflow could overwrite objects from merged caches,
with unmerged caches the heap overflow would only affect the objects in the same cache.
Overall, this reduces the kernel attack surface area by isolating slabs from each other. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_slab_nomerge_argument | | References: | | |
|
Rule
Configure Speculative Store Bypass Mitigation
[ref] | Certain CPUs are vulnerable to an exploit against a common wide industry wide performance
optimization known as Speculative Store Bypass (SSB).
In such cases, recent stores to the same memory location cannot always be observed by later
loads during speculative execution. However, such stores are unlikely and thus they can be
detected prior to instruction retirement at the end of a particular speculation execution
window.
Since Linux Kernel 4.17 you can check the SSB mitigation state with the following command:
cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
Select the appropriate SSB state by adding the argument
spec_store_bypass_disable=seccomp
to the default
GRUB 2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain spec_store_bypass_disable= seccomp as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) spec_store_bypass_disable=seccomp"
Warning:
Disabling Speculative Store Bypass may impact performance of the system. | | Rationale: | In vulnerable processsors, the speculatively forwarded store can be used in a cache side channel
attack. An example of this is reading memory to which the attacker does not directly have access,
for example inside the sandboxed code. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_spec_store_bypass_disable_argument | | References: | | |
|
Rule
Enforce Spectre v2 mitigation
[ref] | Spectre V2 is an indirect branch poisoning attack that can lead to data leakage.
An exploit for Spectre V2 tricks the indirect branch predictor into executing
code from a future indirect branch chosen by the attacker, even if the privilege
level is different.
Since Linux Kernel 4.15 you can check the Spectre V2 mitigation state with the following command:
cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Enforce the Spectre V2 mitigation by adding the argument
spectre_v2=on to the default
GRUB 2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain spectre_v2=on as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) spectre_v2=on"
| | Rationale: | The Spectre V2 vulnerability allows an attacker to read memory that he should not have
access to. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_spectre_v2_argument | | References: | | |
|
| Group
Configure Syslog
Group contains 3 groups and 7 rules |
[ref]
The syslog service has been the default Unix logging mechanism for
many years. It has a number of downsides, including inconsistent log format,
lack of authentication for received messages, and lack of authentication,
encryption, or reliable transport for messages sent over a network. However,
due to its long history, syslog is a de facto standard which is supported by
almost all Unix applications.
In Red Hat Enterprise Linux CoreOS 4, rsyslog has replaced ksyslogd as the
syslog daemon of choice, and it includes some additional security features
such as reliable, connection-oriented (i.e. TCP) transmission of logs, the
option to log to database formats, and the encryption of log data en route to
a central logging server.
This section discusses how to configure rsyslog for
best effect, and how to use tools provided with the system to maintain and
monitor logs. |
| Group
Ensure Proper Configuration of Log Files
Group contains 3 rules |
[ref]
The file /etc/rsyslog.conf controls where log message are written.
These are controlled by lines called rules, which consist of a
selector and an action.
These rules are often customized depending on the role of the system, the
requirements of the environment, and whatever may enable
the administrator to most effectively make use of log data.
The default rules in Red Hat Enterprise Linux CoreOS 4 are:
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* -/var/log/maillog
cron.* /var/log/cron
*.emerg *
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log
See the man page rsyslog.conf(5) for more information.
Note that the rsyslog daemon can be configured to use a timestamp format that
some log processing programs may not understand. If this occurs,
edit the file /etc/rsyslog.conf and add or edit the following line:
$ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
|
Rule
Ensure Log Files Are Owned By Appropriate Group
[ref] | The group-owner of all log files written by
rsyslog should be root.
These log files are determined by the second part of each Rule line in
/etc/rsyslog.conf and typically all appear in /var/log.
For each log file LOGFILE referenced in /etc/rsyslog.conf,
run the following command to inspect the file's group owner:
$ ls -l LOGFILE
If the owner is not root,
run the following command to
correct this:
$ sudo chgrp root LOGFILE
| | Rationale: | The log files generated by rsyslog contain valuable information regarding system
configuration, user authentication, and other such information. Log files should be
protected from unauthorized access. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_files_groupownership | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | ism | 0988, 1405 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-10.5.1, Req-10.5.2 | | anssi | R71 | | pcidss4 | 10.3.2, 10.3 |
| |
|
Rule
Ensure Log Files Are Owned By Appropriate User
[ref] | The owner of all log files written by
rsyslog should be
root.
These log files are determined by the second part of each Rule line in
/etc/rsyslog.conf and typically all appear in /var/log.
For each log file LOGFILE referenced in /etc/rsyslog.conf,
run the following command to inspect the file's owner:
$ ls -l LOGFILE
If the owner is not
root,
run the following command to
correct this:
$ sudo chown root LOGFILE
| | Rationale: | The log files generated by rsyslog contain valuable information regarding system
configuration, user authentication, and other such information. Log files should be
protected from unauthorized access. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_files_ownership | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | ism | 0988, 1405 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-10.5.1, Req-10.5.2 | | anssi | R71 | | pcidss4 | 10.3.2, 10.3 |
| |
|
Rule
Ensure System Log Files Have Correct Permissions
[ref] | The file permissions for all log files written by rsyslog should
be set to 640, or more restrictive. These log files are determined by the
second part of each Rule line in /etc/rsyslog.conf and typically
all appear in /var/log. For each log file LOGFILE
referenced in /etc/rsyslog.conf, run the following command to
inspect the file's permissions:
$ ls -l LOGFILE
If the permissions are not 640 or more restrictive, run the following
command to correct this:
$ sudo chmod 640 LOGFILE
" | | Rationale: | Log files can contain valuable information regarding system
configuration. If the system log files are not protected unauthorized
users could change the logged data, eliminating their forensic value. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_files_permissions | | References: | | ism | 0988, 1405 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | pcidss | Req-10.5.1, Req-10.5.2 | | anssi | R71 | | pcidss4 | 10.3.1, 10.3 |
| |
|
| Group
Ensure All Logs are Rotated by logrotate
Group contains 3 rules |
[ref]
Edit the file /etc/logrotate.d/syslog. Find the first
line, which should look like this (wrapped for clarity):
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler \
/var/log/boot.log /var/log/cron {
Edit this line so that it contains a one-space-separated
listing of each log file referenced in /etc/rsyslog.conf.
All logs in use on a system must be rotated regularly, or the
log files will consume disk space over time, eventually interfering
with system operation. The file /etc/logrotate.d/syslog is the
configuration file used by the logrotate program to maintain all
log files written by syslog. By default, it rotates logs weekly and
stores four archival copies of each log. These settings can be
modified by editing /etc/logrotate.conf, but the defaults are
sufficient for purposes of this guide.
Note that logrotate is run nightly by the cron job
/etc/cron.daily/logrotate. If particularly active logs need to be
rotated more often than once a day, some other mechanism must be
used. |
Rule
Ensure logrotate is Installed
[ref] | logrotate is installed by default. The logrotate package can be installed with the following command: $ sudo dnf install logrotate
| | Rationale: | The logrotate package provides the logrotate services. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_logrotate_installed | | References: | | cis-csc | 1, 14, 15, 16, 3, 5, 6 | | cobit5 | APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01 | | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9 | | iso27001-2013 | A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1 | | nist | CM-6(a) | | nist-csf | PR.PT-1 | | pcidss | Req-10.7 | | anssi | R71 | | pcidss4 | 10.5.1, 10.5 |
| |
|
Rule
Ensure Logrotate Runs Periodically
[ref] | The logrotate utility allows for the automatic rotation of
log files. The frequency of rotation is specified in /etc/logrotate.conf,
which triggers a cron task or a timer. To configure logrotate to run daily, add or correct
the following line in /etc/logrotate.conf:
# rotate log files frequency
daily
| | Rationale: | Log files that are not properly rotated run the risk of growing so large
that they fill up the /var/log partition. Valuable logging information could be lost
if the /var/log partition becomes full. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_logrotate_activated | | Identifiers: | CCE-82689-1 | | References: | | cis-csc | 1, 14, 15, 16, 3, 5, 6 | | cobit5 | APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01 | | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9 | | iso27001-2013 | A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1 | | nist | CM-6(a) | | nist-csf | PR.PT-1 | | pcidss | Req-10.7 | | anssi | R71 |
| |
|
Rule
Enable logrotate Timer
[ref] |
The logrotate timer can be enabled with the following command:
$ sudo systemctl enable logrotate.timer
| | Rationale: | Log files that are not properly rotated run the risk of growing so large
that they fill up the /var/log partition. Valuable logging information could be lost
if the /var/log partition becomes full. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_timer_logrotate_enabled | | References: | | cis-csc | 1, 14, 15, 16, 3, 5, 6 | | cobit5 | APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01 | | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9 | | iso27001-2013 | A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1 | | nist | CM-6(a) | | nist-csf | PR.PT-1 | | pcidss | Req-10.7 | | anssi | R71 | | pcidss4 | 10.5.1, 10.5 |
| |
|
| Group
Rsyslog Logs Sent To Remote Host
Group contains 1 rule |
[ref]
If system logs are to be useful in detecting malicious
activities, it is necessary to send logs to a remote server. An
intruder who has compromised the root account on a system may
delete the log entries which indicate that the system was attacked
before they are seen by an administrator.
However, it is recommended that logs be stored on the local
host in addition to being sent to the loghost, especially if
rsyslog has been configured to use the UDP protocol to send
messages over a network. UDP does not guarantee reliable delivery,
and moderately busy sites will lose log messages occasionally,
especially in periods of high traffic which may be the result of an
attack. In addition, remote rsyslog messages are not
authenticated in any way by default, so it is easy for an attacker to
introduce spurious messages to the central log server. Also, some
problems cause loss of network connectivity, which will prevent the
sending of messages to the central server. For all of these reasons, it is
better to store log messages both centrally and on each host, so
that they can be correlated if necessary. |
Rule
Ensure Logs Sent To Remote Host
[ref] | To configure rsyslog to send logs to a remote log server,
open /etc/rsyslog.conf and read and understand the last section of the file,
which describes the multiple directives necessary to activate remote
logging.
Along with these other directives, the system can be configured
to forward its logs to a particular log server by
adding or correcting one of the following lines,
substituting logcollector appropriately.
The choice of protocol depends on the environment of the system;
although TCP and RELP provide more reliable message delivery,
they may not be supported in all environments.
To use UDP for log message delivery:
*.* @logcollector
Or in RainerScript:
*.* action(type="omfwd" ... target="logcollector" protocol="udp")
To use TCP for log message delivery:
*.* @@logcollector
Or in RainerScript:
*.* action(type="omfwd" ... target="logcollector" protocol="tcp")
To use RELP for log message delivery:
*.* :omrelp:logcollector
Or in RainerScript:
*.* action(type="omfwd" ... target="logcollector" protocol="relp")
There must be a resolvable DNS CNAME or Alias record set to " logcollector" for logs to be sent correctly to the centralized logging utility. Warning:
It is important to configure queues in case the client is sending log
messages to a remote server. If queues are not configured,
the system will stop functioning when the connection
to the remote server is not available. Please consult Rsyslog
documentation for more information about configuration of queues. The
example configuration which should go into /etc/rsyslog.conf
can look like the following lines:
$ActionQueueType LinkedList
$ActionQueueFileName queuefilename
$ActionQueueMaxDiskSpace 1g
$ActionQueueSaveOnShutdown on
$ActionResumeRetryCount -1
Or if using Rainer Script syntax, it could be:
*.* action(type="omfwd" queue.type="linkedlist" queue.filename="example_fwd" action.resumeRetryCount="-1" queue.saveOnShutdown="on" target="example.com" port="30514" protocol="tcp")
| | Rationale: | A log server (loghost) receives syslog messages from one or more
systems. This data can be used as an additional log source in the event a
system is compromised and its local logs are suspect. Forwarding log messages
to a remote loghost also provides system administrators with a centralized
place to view the status of multiple hosts within the enterprise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_remote_loghost | | References: | | cis-csc | 1, 13, 14, 15, 16, 2, 3, 5, 6 | | cobit5 | APO11.04, APO13.01, BAI03.05, BAI04.04, DSS05.04, DSS05.07, MEA02.01 | | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(5)(ii)(B), 164.308(a)(5)(ii)(C), 164.308(a)(6)(ii), 164.308(a)(8), 164.310(d)(2)(iii), 164.312(b), 164.314(a)(2)(i)(C), 164.314(a)(2)(iii) | | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 7.1, SR 7.2 | | ism | 0988, 1405 | | iso27001-2013 | A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.17.2.1 | | nerc-cip | CIP-003-8 R5.2, CIP-004-6 R3.3 | | nist | CM-6(a), AU-4(1), AU-9(2) | | nist-csf | PR.DS-4, PR.PT-1 | | os-srg | SRG-OS-000479-GPOS-00224, SRG-OS-000480-GPOS-00227, SRG-OS-000342-GPOS-00133 | | anssi | R71 |
| |
|
| Group
Network Configuration and Firewalls
Group contains 8 groups and 38 rules |
[ref]
Most systems must be connected to a network of some
sort, and this brings with it the substantial risk of network
attack. This section discusses the security impact of decisions
about networking which must be made when configuring a system.
This section also discusses firewalls, network access
controls, and other network security frameworks, which allow
system-level rules to be written that can limit an attackers' ability
to connect to your system. These rules can specify that network
traffic should be allowed or denied from certain IP addresses,
hosts, and networks. The rules can also specify which of the
system's network services are available to particular hosts or
networks. |
| Group
IPSec Support
Group contains 9 rules |
[ref]
Support for Internet Protocol Security (IPsec)
is provided with Libreswan. |
Rule
Verify Group Who Owns /etc/ipsec.d Directory
[ref] | To properly set the group owner of /etc/ipsec.d, run the command:
$ sudo chgrp root /etc/ipsec.d
| | Rationale: | The ownership of the /etc/ipsec.d directory by the root group is important
because this directory hosts Libreswan configuration. Protection of this
file is critical for system security. Assigning the ownership to root
ensures exclusive control of the Libreswan configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_groupowner_etc_ipsecd | | References: | | |
|
Rule
Verify User Who Owns /etc/ipsec.d Directory
[ref] | To properly set the owner of /etc/ipsec.d, run the command:
$ sudo chown root /etc/ipsec.d
| | Rationale: | The ownership of the /etc/ipsec.d directory by the root user is important
because this directory hosts Libreswan configuration. Protection of this
file is critical for system security. Assigning the ownership to root
ensures exclusive control of the Libreswan configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_owner_etc_ipsecd | | References: | | |
|
Rule
Verify Permissions On /etc/ipsec.d Directory
[ref] | To properly set the permissions of /etc/ipsec.d, run the command: $ sudo chmod 0700 /etc/ipsec.d
| | Rationale: | Setting correct permissions on the /etc/ipsec.d directory is important
because this directory hosts Libreswan configuration. Protection of this
directory is critical for system security. Restricting the permissions
ensures exclusive control of the Libreswan configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_permissions_etc_ipsecd | | References: | | |
|
Rule
Verify Group Who Owns /etc/ipsec.conf File
[ref] | To properly set the group owner of /etc/ipsec.conf, run the command:
$ sudo chgrp root /etc/ipsec.conf
| | Rationale: | The ownership of the /etc/ipsec.conf file by the root group is important
because this file hosts Libreswan configuration. Protection of this
file is critical for system security. Assigning the ownership to root
ensures exclusive control of the Libreswan configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_ipsec_conf | | References: | | |
|
Rule
Verify Group Who Owns /etc/ipsec.secrets File
[ref] | To properly set the group owner of /etc/ipsec.secrets, run the command:
$ sudo chgrp root /etc/ipsec.secrets
| | Rationale: | The ownership of the /etc/ipsec.secrets file by the root group is important
because this file hosts Libreswan configuration. Protection of this
file is critical for system security. Assigning the ownership to root
ensures exclusive control of the Libreswan configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_ipsec_secrets | | References: | | |
|
Rule
Verify User Who Owns /etc/ipsec.conf File
[ref] | To properly set the owner of /etc/ipsec.conf, run the command:
$ sudo chown root /etc/ipsec.conf
| | Rationale: | The ownership of the /etc/ipsec.conf file by the root user is important
because this file hosts Libreswan configuration. Protection of this
file is critical for system security. Assigning the ownership to root
ensures exclusive control of the Libreswan configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_ipsec_conf | | References: | | |
|
Rule
Verify User Who Owns /etc/ipsec.secrets File
[ref] | To properly set the owner of /etc/ipsec.secrets, run the command:
$ sudo chown root /etc/ipsec.secrets
| | Rationale: | The ownership of the /etc/ipsec.secrets file by the root user is important
because this file hosts Libreswan configuration. Protection of this
file is critical for system security. Assigning the ownership to root
ensures exclusive control of the Libreswan configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_ipsec_secrets | | References: | | |
|
Rule
Verify Permissions On /etc/ipsec.conf File
[ref] | To properly set the permissions of /etc/ipsec.conf, run the command: $ sudo chmod 0644 /etc/ipsec.conf
| | Rationale: | Setting correct permissions on the /etc/ipsec.conf file is important
because this file hosts Libreswan configuration. Protection of this
file is critical for system security. Restricting the permissions
ensures exclusive control of the Libreswan configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_ipsec_conf | | References: | | |
|
Rule
Verify Permissions On /etc/ipsec.secrets File
[ref] | To properly set the permissions of /etc/ipsec.secrets, run the command: $ sudo chmod 0644 /etc/ipsec.secrets
| | Rationale: | Setting correct permissions on the /etc/ipsec.secrets file is important
because this file hosts Libreswan configuration. Protection of this
file is critical for system security. Restricting the permissions
ensures exclusive control of the Libreswan configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_ipsec_secrets | | References: | | |
|
| Group
iptables and ip6tables
Group contains 3 rules |
[ref]
A host-based firewall called netfilter is included as
part of the Linux kernel distributed with the system. It is
activated by default. This firewall is controlled by the program
iptables, and the entire capability is frequently referred to by
this name. An analogous program called ip6tables handles filtering
for IPv6.
Unlike TCP Wrappers, which depends on the network server
program to support and respect the rules written, netfilter
filtering occurs at the kernel level, before a program can even
process the data from the network packet. As such, any program on
the system is affected by the rules written.
This section provides basic information about strengthening
the iptables and ip6tables configurations included with the system.
For more complete information that may allow the construction of a
sophisticated ruleset tailored to your environment, please consult
the references at the end of this section. |
Rule
Verify Group Who Owns /etc/iptables Directory
[ref] | To properly set the group owner of /etc/iptables, run the command:
$ sudo chgrp root /etc/iptables
| | Rationale: | The ownership of the /etc/iptables directory by the root group is important
because this directory hosts iptables configuration. Protection of this
file is critical for system security. Assigning the ownership to root
ensures exclusive control of the iptables configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_groupowner_etc_iptables | | References: | | |
|
Rule
Verify User Who Owns /etc/iptables Directory
[ref] | To properly set the owner of /etc/iptables, run the command:
$ sudo chown root /etc/iptables
| | Rationale: | The ownership of the /etc/iptables directory by the root user is important
because this directory hosts iptables configuration. Protection of this
file is critical for system security. Assigning the ownership to root
ensures exclusive control of the iptables configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_owner_etc_iptables | | References: | | |
|
Rule
Verify Permissions On /etc/iptables Directory
[ref] | To properly set the permissions of /etc/iptables, run the command: $ sudo chmod 0700 /etc/iptables
| | Rationale: | Setting correct permissions on the /etc/iptables directory is important
because this directory hosts iptables configuration. Protection of this
directory is critical for system security. Restricting the permissions
ensures exclusive control of the iptables configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_permissions_etc_iptables | | References: | | |
|
| Group
IPv6
Group contains 1 group and 4 rules |
[ref]
The system includes support for Internet Protocol
version 6. A major and often-mentioned improvement over IPv4 is its
enormous increase in the number of available addresses. Another
important feature is its support for automatic configuration of
many network settings. |
| Group
Configure IPv6 Settings if Necessary
Group contains 4 rules |
[ref]
A major feature of IPv6 is the extent to which systems
implementing it can automatically configure their networking
devices using information from the network. From a security
perspective, manually configuring important configuration
information is preferable to accepting it from the network
in an unauthenticated fashion. |
Rule
Disable Accepting ICMP Redirects for All IPv6 Interfaces
[ref] | To set the runtime status of the net.ipv6.conf.all.accept_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.all.accept_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv6.conf.all.accept_redirects = 0
| | Rationale: | An illicit ICMP redirect message could result in a man-in-the-middle attack. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_redirects | | Identifiers: | CCE-82471-4 | | References: | | cis-csc | 11, 14, 3, 9 | | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | | cui | 3.1.20 | | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6 | | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2 | | nist | CM-7(a), CM-7(b), CM-6(a), CM-6(b), CM-6.1(iv) | | nist-csf | PR.IP-1, PR.PT-3 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R13 |
| |
|
Rule
Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv6 Interfaces
[ref] | To set the runtime status of the net.ipv6.conf.all.accept_source_route kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.all.accept_source_route=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv6.conf.all.accept_source_route = 0
| | Rationale: | Source-routed packets allow the source of the packet to suggest routers
forward the packet along a different path than configured on the router, which can
be used to bypass network security measures. This requirement applies only to the
forwarding of source-routerd traffic, such as when IPv6 forwarding is enabled and
the system is functioning as a router.
Accepting source-routed packets in the IPv6 protocol has few legitimate
uses. It should be disabled unless it is absolutely required. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_source_route | | Identifiers: | CCE-82480-5 | | References: | | cis-csc | 1, 12, 13, 14, 15, 16, 18, 4, 6, 8, 9 | | cobit5 | APO01.06, APO13.01, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.1.20 | | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.4.3.3 | | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-7(a), CM-7(b), CM-6(a) | | nist-csf | DE.AE-1, ID.AM-3, PR.AC-5, PR.DS-5, PR.PT-4 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R13 |
| |
|
Rule
Disable Kernel Parameter for Accepting ICMP Redirects by Default on IPv6 Interfaces
[ref] | To set the runtime status of the net.ipv6.conf.default.accept_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.default.accept_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv6.conf.default.accept_redirects = 0
| | Rationale: | An illicit ICMP redirect message could result in a man-in-the-middle attack. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_redirects | | Identifiers: | CCE-82477-1 | | References: | | cis-csc | 11, 14, 3, 9 | | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | | cui | 3.1.20 | | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6 | | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2 | | nist | CM-7(a), CM-7(b), CM-6(a) | | nist-csf | PR.IP-1, PR.PT-3 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R13 |
| |
|
Rule
Disable Kernel Parameter for Accepting Source-Routed Packets on IPv6 Interfaces by Default
[ref] | To set the runtime status of the net.ipv6.conf.default.accept_source_route kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.default.accept_source_route=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv6.conf.default.accept_source_route = 0
| | Rationale: | Source-routed packets allow the source of the packet to suggest routers
forward the packet along a different path than configured on the router, which can
be used to bypass network security measures. This requirement applies only to the
forwarding of source-routerd traffic, such as when IPv6 forwarding is enabled and
the system is functioning as a router.
Accepting source-routed packets in the IPv6 protocol has few legitimate
uses. It should be disabled unless it is absolutely required. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_source_route | | Identifiers: | CCE-82481-3 | | References: | | cis-csc | 1, 12, 13, 14, 15, 16, 18, 4, 6, 8, 9 | | cobit5 | APO01.06, APO13.01, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.1.20 | | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.4.3.3 | | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-7(a), CM-7(b), CM-6(a), CM-6(b), CM-6.1(iv) | | nist-csf | DE.AE-1, ID.AM-3, PR.AC-5, PR.DS-5, PR.PT-4 | | pcidss | Req-1.4.3 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R13 | | pcidss4 | 1.4.2, 1.4 |
| |
|
| Group
Kernel Parameters Which Affect Networking
Group contains 2 groups and 19 rules |
[ref]
The sysctl utility is used to set
parameters which affect the operation of the Linux kernel. Kernel parameters
which affect networking and have security implications are described here. |
| Group
Network Related Kernel Runtime Parameters for Hosts and Routers
Group contains 16 rules |
[ref]
Certain kernel parameters should be set for systems which are
acting as either hosts or routers to improve the system's ability defend
against certain types of IPv4 protocol attacks. |
Rule
Disable Accepting Packets Routed Between Local Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.accept_local kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.accept_local=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.accept_local = 0
| | Rationale: | Configure net.ipv4.conf.all.accept_local=0 to consider as invalid the packets
received from outside whose source is the 127.0.0.0/8 address block.
In combination with suitable routing, this can be used to direct packets between two
local interfaces over the wire and have them accepted properly. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_accept_local | | References: | | |
|
Rule
Disable Accepting ICMP Redirects for All IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.accept_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.accept_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.accept_redirects = 0
| | Rationale: | ICMP redirect messages are used by routers to inform hosts that a more
direct route exists for a particular destination. These messages modify the
host's route table and are unauthenticated. An illicit ICMP redirect
message could result in a man-in-the-middle attack.
This feature of the IPv4 protocol has few legitimate uses. It should be
disabled unless absolutely required." | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_accept_redirects | | Identifiers: | CCE-82469-8 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9 | | cjis | 5.10.1.1 | | cobit5 | APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06 | | cui | 3.1.20 | | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | | iso27001-2013 | A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.9.1.2 | | nist | CM-7(a), CM-7(b), CM-6(a), SC-7(a) | | nist-csf | DE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R12 |
| |
|
Rule
Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.accept_source_route kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.accept_source_route=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.accept_source_route = 0
| | Rationale: | Source-routed packets allow the source of the packet to suggest routers
forward the packet along a different path than configured on the router,
which can be used to bypass network security measures. This requirement
applies only to the forwarding of source-routerd traffic, such as when IPv4
forwarding is enabled and the system is functioning as a router.
Accepting source-routed packets in the IPv4 protocol has few legitimate
uses. It should be disabled unless it is absolutely required. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_accept_source_route | | Identifiers: | CCE-82478-9 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | | cui | 3.1.20 | | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | | nist | CM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a) | | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R12 |
| |
|
Rule
Configure ARP filtering for All IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.arp_filter kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.arp_filter=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.arp_filter = 0
Warning:
This behaviour may cause problems to system on a high availability or load balancing configuration. | | Rationale: | Prevents the Linux Kernel from handling the ARP table globally.
By default, the kernel may respond to an ARP request from a certain interface with information
from another interface. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_arp_filter | | References: | | |
|
Rule
Configure Response Mode of ARP Requests for All IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.arp_ignore kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.arp_ignore=2
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.arp_ignore = 2
Warning:
The ARP response mode may impact behaviour of workloads and firewalls on the system. | | Rationale: | Avoids ARP Flux on system that have more than one interface on the same subnet. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_arp_ignore | | References: | | |
|
Rule
Prevent Routing External Traffic to Local Loopback on All IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.route_localnet kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.route_localnet=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.route_localnet = 0
| | Rationale: | Refuse the routing of packets whose source or destination address is the local loopback.
This prohibits the use of network 127/8 for local routing purposes.
Enabling route_localnet can expose applications listening on localhost to external traffic. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_route_localnet | | References: | | |
|
Rule
Enable Kernel Parameter to Use Reverse Path Filtering on all IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.rp_filter kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.rp_filter=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.rp_filter = 1
| | Rationale: | Enabling reverse path filtering drops packets with source addresses
that should not have been able to be received on the interface they were
received on. It should not be used on systems which are routers for
complicated networks, but is helpful for end hosts and routers serving small
networks. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_rp_filter | | Identifiers: | CCE-82488-8 | | References: | | cis-csc | 1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9 | | cobit5 | APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.1.20 | | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.4.3.3 | | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-7(a), CM-7(b), CM-6(a), SC-7(a) | | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.PT-4 | | pcidss | Req-1.4.3 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R12 | | pcidss4 | 1.4.3, 1.4 |
| |
|
Rule
Disable Kernel Parameter for Accepting Secure ICMP Redirects on all IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.secure_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.secure_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.secure_redirects = 0
| | Rationale: | Accepting "secure" ICMP redirects (from those gateways listed as
default gateways) has few legitimate uses. It should be disabled unless it is
absolutely required. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_secure_redirects | | Identifiers: | CCE-82482-1 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | | cui | 3.1.20 | | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-7(a), CM-7(b), CM-6(a), SC-7(a) | | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4 | | pcidss | Req-1.4.3 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R12 | | pcidss4 | 1.4.3, 1.4 |
| |
|
Rule
Configure Sending and Accepting Shared Media Redirects for All IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.shared_media kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.shared_media=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.shared_media = 0
| | Rationale: | This setting should be aligned with net.ipv4.conf.all.secure_redirects because it overrides it.
If shared_media is enabled for an interface secure_redirects will be enabled too. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_shared_media | | References: | | |
|
Rule
Disable Kernel Parameter for Accepting ICMP Redirects by Default on IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.default.accept_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.accept_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.default.accept_redirects = 0
| | Rationale: | ICMP redirect messages are used by routers to inform hosts that a more
direct route exists for a particular destination. These messages modify the
host's route table and are unauthenticated. An illicit ICMP redirect
message could result in a man-in-the-middle attack.
This feature of the IPv4 protocol has few legitimate uses. It should
be disabled unless absolutely required. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_accept_redirects | | Identifiers: | CCE-82470-6 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | | cjis | 5.10.1.1 | | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | | cui | 3.1.20 | | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-7(a), CM-7(b), CM-6(a), SC-7(a) | | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4 | | pcidss | Req-1.4.3 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R12 | | pcidss4 | 1.4.3, 1.4 |
| |
|
Rule
Disable Kernel Parameter for Accepting Source-Routed Packets on IPv4 Interfaces by Default
[ref] | To set the runtime status of the net.ipv4.conf.default.accept_source_route kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.accept_source_route=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.default.accept_source_route = 0
| | Rationale: | Source-routed packets allow the source of the packet to suggest routers
forward the packet along a different path than configured on the router,
which can be used to bypass network security measures.
Accepting source-routed packets in the IPv4 protocol has few legitimate
uses. It should be disabled unless it is absolutely required, such as when
IPv4 forwarding is enabled and the system is legitimately functioning as a
router. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_accept_source_route | | Identifiers: | CCE-82479-7 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | | cjis | 5.10.1.1 | | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | | cui | 3.1.20 | | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | | nist | CM-7(a), CM-7(b), SC-5, SC-7(a) | | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R12 |
| |
|
Rule
Enable Kernel Parameter to Use Reverse Path Filtering on all IPv4 Interfaces by Default
[ref] | To set the runtime status of the net.ipv4.conf.default.rp_filter kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.rp_filter=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.default.rp_filter = 1
| | Rationale: | Enabling reverse path filtering drops packets with source addresses
that should not have been able to be received on the interface they were
received on. It should not be used on systems which are routers for
complicated networks, but is helpful for end hosts and routers serving small
networks. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_rp_filter | | Identifiers: | CCE-82489-6 | | References: | | cis-csc | 1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9 | | cobit5 | APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.1.20 | | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.4.3.3 | | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-7(a), CM-7(b), CM-6(a), SC-7(a) | | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.PT-4 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R12 |
| |
|
Rule
Configure Kernel Parameter for Accepting Secure Redirects By Default
[ref] | To set the runtime status of the net.ipv4.conf.default.secure_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.secure_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.default.secure_redirects = 0
| | Rationale: | Accepting "secure" ICMP redirects (from those gateways listed as
default gateways) has few legitimate uses. It should be disabled unless it is
absolutely required. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_secure_redirects | | Identifiers: | CCE-82483-9 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | | cui | 3.1.20 | | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | | nist | CM-7(a), CM-7(b), SC-5, SC-7(a) | | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R12 |
| |
|
Rule
Configure Sending and Accepting Shared Media Redirects by Default
[ref] | To set the runtime status of the net.ipv4.conf.default.shared_media kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.shared_media=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.default.shared_media = 0
| | Rationale: | This setting should be aligned with net.ipv4.conf.default.secure_redirects because it overrides it.
If shared_media is enabled for an interface secure_redirects will be enabled too. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_shared_media | | References: | | |
|
Rule
Enable Kernel Parameter to Ignore Bogus ICMP Error Responses on IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.icmp_ignore_bogus_error_responses kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.icmp_ignore_bogus_error_responses = 1
| | Rationale: | Ignoring bogus ICMP error responses reduces
log size, although some activity would not be logged. | | Severity: | unknown | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_icmp_ignore_bogus_error_responses | | Identifiers: | CCE-82490-4 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9 | | cobit5 | APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06 | | cui | 3.1.20 | | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | | iso27001-2013 | A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.9.1.2 | | nerc-cip | CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | | nist | CM-7(a), CM-7(b), SC-5 | | nist-csf | DE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3 | | pcidss | Req-1.4.3 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R12 | | pcidss4 | 1.4.2, 1.4 |
| |
|
Rule
Enable Kernel Parameter to Use TCP Syncookies on Network Interfaces
[ref] | To set the runtime status of the net.ipv4.tcp_syncookies kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.tcp_syncookies=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.tcp_syncookies = 1
| | Rationale: | A TCP SYN flood attack can cause a denial of service by filling a
system's TCP connection table with connections in the SYN_RCVD state.
Syncookies can be used to track a connection when a subsequent ACK is received,
verifying the initiator is attempting a valid connection and is not a flood
source. This feature is activated when a flood condition is detected, and
enables the system to continue servicing valid connection requests. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_tcp_syncookies | | Identifiers: | CCE-82492-0 | | References: | | cis-csc | 1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9 | | cjis | 5.10.1.1 | | cobit5 | APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.1.20 | | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.4.3.3 | | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | CM-7(a), CM-7(b), SC-5(1), SC-5(2), SC-5(3)(a), CM-6(a) | | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.PT-4 | | pcidss | Req-1.4.1 | | os-srg | SRG-OS-000480-GPOS-00227, SRG-OS-000420-GPOS-00186, SRG-OS-000142-GPOS-00071 | | anssi | R12 | | pcidss4 | 1.4.3, 1.4 |
| |
|
| Group
Network Parameters for Hosts Only
Group contains 3 rules |
[ref]
If the system is not going to be used as a router, then setting certain
kernel parameters ensure that the host will not perform routing
of network traffic. |
Rule
Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.send_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.send_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.send_redirects = 0
| | Rationale: | ICMP redirect messages are used by routers to inform hosts that a more
direct route exists for a particular destination. These messages contain information
from the system's route table possibly revealing portions of the network topology.
The ability to send ICMP redirects is only appropriate for systems acting as routers. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_send_redirects | | Identifiers: | CCE-82484-7 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | | cjis | 5.10.1.1 | | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | | cui | 3.1.20 | | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | | nist | CM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a) | | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R12 | | pcidss4 | 1.4.5, 1.4 |
| |
|
Rule
Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfaces by Default
[ref] | To set the runtime status of the net.ipv4.conf.default.send_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.send_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.default.send_redirects = 0
| | Rationale: | ICMP redirect messages are used by routers to inform hosts that a more
direct route exists for a particular destination. These messages contain information
from the system's route table possibly revealing portions of the network topology.
The ability to send ICMP redirects is only appropriate for systems acting as routers. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_send_redirects | | Identifiers: | CCE-82485-4 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | | cjis | 5.10.1.1 | | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | | cui | 3.1.20 | | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | | nist | CM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a) | | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R12 | | pcidss4 | 1.4.5, 1.4 |
| |
|
Rule
Disable Kernel Parameter for IP Forwarding on IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.ip_forward kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.ip_forward=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.ip_forward = 0
Warning:
Certain technologies such as virtual machines, containers, etc. rely on IPv4 forwarding to enable and use networking.
Disabling IPv4 forwarding would cause those technologies to stop working. Therefore, this rule should not be used in
profiles or benchmarks that target usage of IPv4 forwarding. | | Rationale: | Routing protocol daemons are typically used on routers to exchange
network topology information with other routers. If this capability is used when
not required, system network information may be unnecessarily transmitted across
the network. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_ip_forward | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9 | | cobit5 | APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06 | | cui | 3.1.20 | | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | | iso27001-2013 | A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.9.1.2 | | nerc-cip | CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | | nist | CM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a) | | nist-csf | DE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3, PR.PT-4 | | pcidss | Req-1.3.1, Req-1.3.2 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R12 | | pcidss4 | 1.4.3, 1.4 |
| |
|
| Group
nftables
Group contains 3 rules |
[ref]
If firewalld or iptables are being used in your environment, please follow the guidance in their
respective section and pass-over the guidance in this section.
nftables is a subsystem of the Linux kernel providing filtering and classification of network
packets/datagrams/frames and is the successor to iptables. The biggest change with the
successor nftables is its simplicity. With iptables, we have to configure every single rule and
use the syntax which can be compared with normal commands. With nftables, the simpler
syntax, much like BPF (Berkely Packet Filter) means shorter lines and less repetition.
Support for nftables should also be compiled into the kernel, together with the related
nftables modules.
It is available in Linux kernels >= 3.13. Please ensure that your kernel
supports nftables before choosing this option.
|
Rule
Verify Group Who Owns /etc/nftables Directory
[ref] | To properly set the group owner of /etc/nftables, run the command:
$ sudo chgrp root /etc/nftables
| | Rationale: | The ownership of the /etc/nftables directory by the root group is important
because this directory hosts nftables configuration. Protection of this
directory is critical for system security. Assigning the ownership to root
ensures exclusive control of the nftables configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_groupowner_etc_nftables | | References: | | |
|
Rule
Verify User Who Owns /etc/nftables Directory
[ref] | To properly set the owner of /etc/nftables, run the command:
$ sudo chown root /etc/nftables
| | Rationale: | The ownership of the /etc/nftables directory by the root user is important
because this directory hosts nftables configuration. Protection of this
directory is critical for system security. Assigning the ownership to root
ensures exclusive control of the nftables configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_owner_etc_nftables | | References: | | |
|
Rule
Verify Permissions On /etc/nftables Directory
[ref] | To properly set the permissions of /etc/nftables, run the command: $ sudo chmod 0700 /etc/nftables
| | Rationale: | Setting correct permissions on the /etc/nftables directory is important
because this directory hosts nftables configuration. Protection of this
directory is critical for system security. Restricting the permissions
ensures exclusive control of the nftables configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_permissions_etc_nftables | | References: | | |
|
| Group
File Permissions and Masks
Group contains 7 groups and 52 rules |
[ref]
Traditional Unix security relies heavily on file and
directory permissions to prevent unauthorized users from reading or
modifying files to which they should not have access.
Several of the commands in this section search filesystems
for files or directories with certain characteristics, and are
intended to be run on every local partition on a given system.
When the variable PART appears in one of the commands below,
it means that the command is intended to be run repeatedly, with the
name of each local partition substituted for PART in turn.
The following command prints a list of all xfs partitions on the local
system, which is the default filesystem for Red Hat Enterprise Linux CoreOS 4
installations:
$ mount -t xfs | awk '{print $3}'
For any systems that use a different
local filesystem type, modify this command as appropriate. |
| Group
Verify Permissions on Important Files and
Directories
Group contains 2 groups and 33 rules |
[ref]
Permissions for many files on a system must be set
restrictively to ensure sensitive information is properly protected.
This section discusses important
permission restrictions which can be verified
to ensure that no harmful discrepancies have
arisen. |
| Group
Verify Permissions on Files with Local Account Information and Credentials
Group contains 15 rules |
[ref]
The default restrictive permissions for files which act as
important security databases such as passwd, shadow,
group, and gshadow files must be maintained. Many utilities
need read access to the passwd file in order to function properly, but
read access to the shadow file allows malicious attacks against system
passwords, and should never be enabled. |
Rule
Verify Group Who Owns group File
[ref] | To properly set the group owner of /etc/group, run the command:
$ sudo chgrp root /etc/group
| | Rationale: | The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_group | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-8.7.c | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Group Who Owns gshadow File
[ref] | To properly set the group owner of /etc/gshadow, run the command:
$ sudo chgrp root /etc/gshadow
| | Rationale: | The /etc/gshadow file contains group password hashes. Protection of this file
is critical for system security. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_gshadow | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 |
| |
|
Rule
Verify Group Who Owns passwd File
[ref] | To properly set the group owner of /etc/passwd, run the command:
$ sudo chgrp root /etc/passwd
| | Rationale: | The /etc/passwd file contains information about the users that are configured on
the system. Protection of this file is critical for system security. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_passwd | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-8.7.c | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Group Who Owns shadow File
[ref] | To properly set the group owner of /etc/shadow, run the command:
$ sudo chgrp root /etc/shadow
| | Rationale: | The /etc/shadow file stores password hashes. Protection of this file is
critical for system security. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_shadow | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-8.7.c | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Group Who Owns /etc/shells File
[ref] |
To properly set the group owner of /etc/shells, run the command:
$ sudo chgrp root /etc/shells
| | Rationale: | The /etc/shells file contains the list of full pathnames to shells on the system.
Since this file is used by many system programs this file should be protected. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_shells | | References: | | |
|
Rule
Verify User Who Owns group File
[ref] | To properly set the owner of /etc/group, run the command:
$ sudo chown root /etc/group
| | Rationale: | The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_group | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-8.7.c | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify User Who Owns gshadow File
[ref] | To properly set the owner of /etc/gshadow, run the command:
$ sudo chown root /etc/gshadow
| | Rationale: | The /etc/gshadow file contains group password hashes. Protection of this file
is critical for system security. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_gshadow | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 |
| |
|
Rule
Verify User Who Owns passwd File
[ref] | To properly set the owner of /etc/passwd, run the command:
$ sudo chown root /etc/passwd
| | Rationale: | The /etc/passwd file contains information about the users that are configured on
the system. Protection of this file is critical for system security. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_passwd | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-8.7.c | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify User Who Owns shadow File
[ref] | To properly set the owner of /etc/shadow, run the command:
$ sudo chown root /etc/shadow
| | Rationale: | The /etc/shadow file contains the list of local
system accounts and stores password hashes. Protection of this file is
critical for system security. Failure to give ownership of this file
to root provides the designated owner with access to sensitive information
which could weaken the system security posture. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_shadow | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-8.7.c | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Who Owns /etc/shells File
[ref] |
To properly set the owner of /etc/shells, run the command:
$ sudo chown root /etc/shells
| | Rationale: | The /etc/shells file contains the list of full pathnames to shells on the system.
Since this file is used by many system programs this file should be protected. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_shells | | References: | | |
|
Rule
Verify Permissions on group File
[ref] |
To properly set the permissions of /etc/group, run the command:
$ sudo chmod 0644 /etc/group
| | Rationale: | The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_group | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-8.7.c | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Permissions on gshadow File
[ref] |
To properly set the permissions of /etc/gshadow, run the command:
$ sudo chmod 0000 /etc/gshadow
| | Rationale: | The /etc/gshadow file contains group password hashes. Protection of this file
is critical for system security. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_gshadow | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 |
| |
|
Rule
Verify Permissions on passwd File
[ref] |
To properly set the permissions of /etc/passwd, run the command:
$ sudo chmod 0644 /etc/passwd
| | Rationale: | If the /etc/passwd file is writable by a group-owner or the
world the risk of its compromise is increased. The file contains the list of
accounts on the system and associated information, and protection of this file
is critical for system security. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_passwd | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-8.7.c | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Permissions on shadow File
[ref] |
To properly set the permissions of /etc/shadow, run the command:
$ sudo chmod 0000 /etc/shadow
| | Rationale: | The /etc/shadow file contains the list of local
system accounts and stores password hashes. Protection of this file is
critical for system security. Failure to give ownership of this file
to root provides the designated owner with access to sensitive information
which could weaken the system security posture. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_shadow | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.2.2 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-8.7.c | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Permissions on /etc/shells File
[ref] |
To properly set the permissions of /etc/shells, run the command:
$ sudo chmod 0644 /etc/shells
| | Rationale: | The /etc/shells file contains the list of full pathnames to shells on the system.
Since this file is used by many system programs this file should be protected. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_shells | | References: | | |
|
| Group
Verify File Permissions Within Some Important Directories
Group contains 6 rules |
[ref]
Some directories contain files whose confidentiality or integrity
is notably important and may also be susceptible to misconfiguration over time, particularly if
unpackaged software is installed. As such,
an argument exists to verify that files' permissions within these directories remain
configured correctly and restrictively. |
Rule
Verify Group Who Owns /etc/sysctl.d Directory
[ref] | To properly set the group owner of /etc/sysctl.d, run the command:
$ sudo chgrp root /etc/sysctl.d
| | Rationale: | The ownership of the /etc/sysctl.d directory by the root group is important
because this directory hosts kernel configuration. Protection of this
directory is critical for system security. Assigning the ownership to root
ensures exclusive control of the kernel configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_groupowner_etc_sysctld | | References: | | |
|
Rule
Verify User Who Owns /etc/sysctl.d Directory
[ref] | To properly set the owner of /etc/sysctl.d, run the command:
$ sudo chown root /etc/sysctl.d
| | Rationale: | The ownership of the /etc/sysctl.d directory by the root user is important
because this directory hosts kernel configuration. Protection of this
directory is critical for system security. Assigning the ownership to root
ensures exclusive control of the kernel configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_owner_etc_sysctld | | References: | | |
|
Rule
Verify Permissions On /etc/sysctl.d Directory
[ref] | To properly set the permissions of /etc/sysctl.d, run the command: $ sudo chmod 0755 /etc/sysctl.d
| | Rationale: | Setting correct permissions on the /etc/sysctl.d directory is important
because this directory hosts kernel configuration. Protection of this
directory is critical for system security. Restricting the permissions
ensures exclusive control of the kernel configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_permissions_etc_sysctld | | References: | | |
|
Rule
Verify that system commands files are group owned by root or a system account
[ref] | System commands files are stored in the following directories by default:
/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
All files in these directories should be owned by the root group,
or a system account.
If the directory, or any file in these directories, is found to be owned
by a group other than root or a a system account correct its ownership
with the following command:
$ sudo chgrp root FILE
| | Rationale: | If the operating system allows any user to make changes to software
libraries, then those changes might be implemented without undergoing the
appropriate testing and approvals that are part of a robust change management
process.
This requirement applies to operating systems with software libraries
that are accessible and configurable, as in the case of interpreted languages.
Software libraries also include privileged programs which execute with
escalated privileges. Only qualified and authorized individuals must be
allowed to obtain access to information system components for purposes
of initiating changes, including upgrades and modifications. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupownership_system_commands_dirs | | References: | | |
|
Rule
Verify that System Executables Have Root Ownership
[ref] | System executables are stored in the following directories by default:
/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All files in these directories should be owned by the root user.
If any file FILE in these directories is found
to be owned by a user other than root, correct its ownership with the
following command:
$ sudo chown root FILE
| | Rationale: | System binaries are executed by privileged users as well as system services,
and restrictive permissions are necessary to ensure that their
execution of these programs cannot be co-opted. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_ownership_binary_dirs | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-5(6), CM-5(6).1, CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | os-srg | SRG-OS-000259-GPOS-00100 | | anssi | R50 |
| |
|
Rule
Verify that System Executables Have Restrictive Permissions
[ref] | System executables are stored in the following directories by default:
/bin
/sbin
/usr/bin
/usr/libexec
/usr/local/bin
/usr/local/sbin
/usr/sbin
All files in these directories should not be group-writable or world-writable.
If any file FILE in these directories is found
to be group-writable or world-writable, correct its permission with the
following command:
$ sudo chmod go-w FILE
| | Rationale: | System binaries are executed by privileged users, as well as system services,
and restrictive permissions are necessary to ensure execution of these programs
cannot be co-opted. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_binary_dirs | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-5(6), CM-5(6).1, CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | os-srg | SRG-OS-000259-GPOS-00100 | | anssi | R50 |
| |
|
Rule
Verify that All World-Writable Directories Have Sticky Bits Set
[ref] | When the so-called 'sticky bit' is set on a directory, only the owner of a given file may
remove that file from the directory. Without the sticky bit, any user with write access to a
directory may remove any file in the directory. Setting the sticky bit prevents users from
removing each other's files. In cases where there is no reason for a directory to be
world-writable, a better solution is to remove that permission rather than to set the sticky
bit. However, if a directory is used by a particular application, consult that application's
documentation instead of blindly changing modes.
To set the sticky bit on a world-writable directory DIR, run the following command:
$ sudo chmod +t DIR
Warning:
This rule can take a long time to perform the check and might consume a considerable
amount of resources depending on the number of directories present on the system. It is
not a problem in most cases, but especially systems with a large number of directories can
be affected. See https://access.redhat.com/articles/6999111. | | Rationale: | Failing to set the sticky bit on public directories allows unauthorized users to delete files
in the directory structure.
The only authorized public directories are those temporary directories supplied with the
system, or those designed to be temporary file repositories. The setting is normally reserved
for directories used by the system, by users for temporary file storage (such as /tmp),
and for directories requiring global read/write access. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_dir_perms_world_writable_sticky_bits | | Identifiers: | CCE-82753-5 | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | os-srg | SRG-OS-000138-GPOS-00069 | | anssi | R54 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify that system commands directories have root as a group owner
[ref] | System commands are stored in the following directories:
by default:
/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
All these directories should have root user as a group owner.
If any system command directory is not group owned by a user other than root
correct its ownership with the following command:
$ sudo chgrp root DIR
| | Rationale: | If the operating system were to allow any user to make changes to
software libraries, then those changes might be implemented without
undergoing the appropriate testing and approvals that are part of a
robust change management process.
This requirement applies to operating systems with software libraries
that are accessible and configurable, as in the case of interpreted languages.
Software libraries also include privileged programs which execute with escalated
privileges. Only qualified and authorized individuals must be allowed to obtain
access to information system components for purposes of initiating changes,
including upgrades and modifications. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_dir_system_commands_group_root_owned | | References: | | |
|
Rule
Verify that system commands directories have root ownership
[ref] | System commands are stored in the following directories by default:
/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin
All these directories should be owned by the root user.
If any system command directory is not owned by a user other than root
correct its ownership with the following command:
$ sudo chown root DIR
| | Rationale: | If the operating system were to allow any user to make changes to
software libraries, then those changes might be implemented without
undergoing the appropriate testing and approvals that are part of a
robust change management process.
This requirement applies to operating systems with software libraries
that are accessible and configurable, as in the case of interpreted languages.
Software libraries also include privileged programs which execute with escalated
privileges. Only qualified and authorized individuals must be allowed to obtain
access to information system components for purposes of initiating changes,
including upgrades and modifications. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_dir_system_commands_root_owned | | References: | | |
|
Rule
Verify Group Who Owns /etc/crypttab File
[ref] | To properly set the group owner of /etc/crypttab, run the command:
$ sudo chgrp root /etc/crypttab
| | Rationale: | The ownership of the /etc/crypttab file by the root group is important
because this file hosts encrypted block devices configuration. Protection
of this file is critical for system security. Assigning the ownership to
root ensures exclusive control of the encrypted block devices
configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_crypttab | | References: | | |
|
Rule
Verify Group Who Owns System.map Files
[ref] | The System.map files are symbol map files generated during the compilation of the Linux
kernel. They contain the mapping between kernel symbols and their corresponding memory
addresses. These files must be group-owned by root.
To properly set the group owner of /boot/System.map*, run the command:
$ sudo chgrp root /boot/System.map*
| | Rationale: | The purpose of System.map files is primarily for debugging and profiling the kernel.
Unrestricted access to these files might disclose information useful to attackers and
malicious software leading to more sophisticated exploitation. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_systemmap | | References: | | |
|
Rule
Verify User Who Owns /etc/crypttab File
[ref] | To properly set the owner of /etc/crypttab, run the command:
$ sudo chown root /etc/crypttab
| | Rationale: | The ownership of the /etc/crypttab file by the root user is important
because this file hosts encrypted block devices configuration. Protection
of this file is critical for system security. Assigning the ownership to
root ensures exclusive control of the encrypted block devices
configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_crypttab | | References: | | |
|
Rule
Verify User Who Owns System.map Files
[ref] | The System.map files are symbol map files generated during the compilation of the Linux
kernel. They contain the mapping between kernel symbols and their corresponding memory
addresses. These files must be owned by root.
To properly set the owner of /boot/System.map*, run the command:
$ sudo chown root /boot/System.map*
| | Rationale: | The purpose of System.map files is primarily for debugging and profiling the kernel.
Unrestricted access to these files might disclose information useful to attackers and
malicious software leading to more sophisticated exploitation. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_systemmap | | References: | | |
|
Rule
Verify Permissions On /etc/crypttab File
[ref] | To properly set the permissions of /etc/crypttab, run the command: $ sudo chmod 0600 /etc/crypttab
| | Rationale: | Setting correct permissions on the /etc/crypttab file is important
because this file hosts encrypted block devices configuration. Protection
of this file is critical for system security. Assigning the ownership to
root ensures exclusive control of the encrypted block devices
configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_crypttab | | References: | | |
|
Rule
Verify Permissions on System.map Files
[ref] | The System.map files are symbol map files generated during the compilation of the Linux
kernel. They contain the mapping between kernel symbols and their corresponding memory
addresses. In general, there is no need for non-root users to read these files.
To properly set the permissions of /boot/System.map*, run the command:
$ sudo chmod 0600 /boot/System.map*
| | Rationale: | The purpose of System.map files is primarily for debugging and profiling the kernel.
Unrestricted access to these files might disclose information useful to attackers and
malicious software leading to more sophisticated exploitation. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_systemmap | | References: | | |
|
Rule
Ensure No World-Writable Files Exist
[ref] | It is generally a good idea to remove global (other) write access to a file when it is
discovered. However, check with documentation for specific applications before making changes.
Also, monitor for recurring world-writable files, as these may be symptoms of a misconfigured
application or user account. Finally, this applies to real files and not virtual files that
are a part of pseudo file systems such as sysfs or procfs. Warning:
This rule can take a long time to perform the check and might consume a considerable
amount of resources depending on the number of files present on the system. It is not a
problem in most cases, but especially systems with a large number of files can be affected.
See https://access.redhat.com/articles/6999111. | | Rationale: | Data in world-writable files can be modified by any user on the system. In almost all
circumstances, files can be configured using a combination of user and group permissions to
support whatever legitimate access is needed without the risk caused by world-writable files. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_unauthorized_world_writable | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | anssi | R54 | | pcidss4 | 2.2.6, 2.2 |
| |
|
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: | CCE-82506-7 | | References: | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | os-srg | SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000324-GPOS-00125 | | anssi | R14 |
| |
|
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: | CCE-82507-5 | | References: | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-6(a), AC-6(1) | | os-srg | SRG-OS-000312-GPOS-00122, SRG-OS-000312-GPOS-00123, SRG-OS-000324-GPOS-00125 | | anssi | R14 |
| |
|
| Group
Restrict Partition Mount Options
Group contains 10 rules |
[ref]
System partitions can be mounted with certain options
that limit what files on those partitions can do. These options
are set in the /etc/fstab configuration file, and can be
used to make certain types of malicious behavior more difficult. |
Rule
Add nosuid Option to /boot
[ref] | The nosuid mount option can be used to prevent
execution of setuid programs in /boot. The SUID and SGID permissions
should not be required on the boot partition.
Add the nosuid option to the list of
Options in the systemd.mount unit that
controls mounting of
/boot. | | Rationale: | The presence of SUID and SGID executables should be tightly controlled. Users
should not be able to execute SUID or SGID binaries from boot partitions. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_boot_nosuid | | References: | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7 | | nist-csf | PR.IP-1, PR.PT-2, PR.PT-3 | | os-srg | SRG-OS-000368-GPOS-00154, SRG-OS-000480-GPOS-00227 | | anssi | R28 |
| |
|
Rule
Add nosuid Option to /home
[ref] | The nosuid mount option can be used to prevent
execution of setuid programs in /home. The SUID and SGID permissions
should not be required in these user data directories.
Add the nosuid option to the list of
Options in the systemd.mount unit that
controls mounting of
/home. | | Rationale: | The presence of SUID and SGID executables should be tightly controlled. Users
should not be able to execute SUID or SGID binaries from user home directory partitions. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_home_nosuid | | References: | | cis-csc | 11, 13, 14, 3, 8, 9 | | cobit5 | APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS05.06, DSS06.06 | | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6 | | iso27001-2013 | A.11.2.9, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.8.2.1, A.8.2.2, A.8.2.3, A.8.3.1, A.8.3.3, A.9.1.2 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7 | | nist-csf | PR.IP-1, PR.PT-2, PR.PT-3 | | os-srg | SRG-OS-000368-GPOS-00154, SRG-OS-000480-GPOS-00227 | | anssi | R28 |
| |
|
Rule
Add nodev Option to Non-Root Local Partitions
[ref] | The nodev mount option prevents files from being interpreted as
character or block devices. Legitimate character and block devices should
exist only in the /dev directory on the root partition or within
chroot jails built for system services.
Add the nodev option to the list of
Options in the systemd.mount unit that
controls mounting of
any non-root local partitions. | | Rationale: | The nodev mount option prevents files from being
interpreted as character or block devices. The only legitimate location
for device files is the /dev directory located on the root partition.
The only exception to this is chroot jails, for which it is not advised
to set nodev on these filesystems. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_nodev_nonroot_local_partitions | | References: | | cis-csc | 11, 14, 3, 9 | | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6 | | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7 | | nist-csf | PR.IP-1, PR.PT-3 | | os-srg | SRG-OS-000368-GPOS-00154, SRG-OS-000480-GPOS-00227 | | anssi | R28 |
| |
|
Rule
Add noexec Option to /tmp
[ref] | The noexec mount option can be used to prevent binaries
from being executed out of /tmp.
Add the noexec option to the list of
Options in the systemd.mount unit that
controls mounting of
/tmp. | | Rationale: | Allowing users to execute binaries from world-writable directories
such as /tmp should never be necessary in normal operation and
can expose the system to potential compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_tmp_noexec | | References: | | cis-csc | 11, 13, 14, 3, 8, 9 | | cobit5 | APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS05.06, DSS06.06 | | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6 | | iso27001-2013 | A.11.2.9, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.8.2.1, A.8.2.2, A.8.2.3, A.8.3.1, A.8.3.3, A.9.1.2 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7 | | nist-csf | PR.IP-1, PR.PT-2, PR.PT-3 | | os-srg | SRG-OS-000368-GPOS-00154 | | anssi | R28 |
| |
|
Rule
Add nosuid Option to /tmp
[ref] | The nosuid mount option can be used to prevent
execution of setuid programs in /tmp. The SUID and SGID permissions
should not be required in these world-writable directories.
Add the nosuid option to the list of
Options in the systemd.mount unit that
controls mounting of
/tmp. | | Rationale: | The presence of SUID and SGID executables should be tightly controlled. Users
should not be able to execute SUID or SGID binaries from temporary storage partitions. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_tmp_nosuid | | References: | | cis-csc | 11, 13, 14, 3, 8, 9 | | cobit5 | APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS05.06, DSS06.06 | | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6 | | iso27001-2013 | A.11.2.9, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.8.2.1, A.8.2.2, A.8.2.3, A.8.3.1, A.8.3.3, A.9.1.2 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7 | | nist-csf | PR.IP-1, PR.PT-2, PR.PT-3 | | os-srg | SRG-OS-000368-GPOS-00154 | | anssi | R28 |
| |
|
Rule
Add noexec Option to /var/log
[ref] | The noexec mount option can be used to prevent binaries
from being executed out of /var/log.
Add the noexec option to the list of
Options in the systemd.mount unit that
controls mounting of
/var/log. | | Rationale: | Allowing users to execute binaries from directories containing log files
such as /var/log should never be necessary in normal operation and
can expose the system to potential compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_var_log_noexec | | References: | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7 | | nist-csf | PR.IP-1, PR.PT-2, PR.PT-3 | | os-srg | SRG-OS-000368-GPOS-00154 | | anssi | R28 |
| |
|
Rule
Add nosuid Option to /var/log
[ref] | The nosuid mount option can be used to prevent
execution of setuid programs in /var/log. The SUID and SGID permissions
should not be required in directories containing log files.
Add the nosuid option to the list of
Options in the systemd.mount unit that
controls mounting of
/var/log. | | Rationale: | The presence of SUID and SGID executables should be tightly controlled. Users
should not be able to execute SUID or SGID binaries from partitions
designated for log files. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_var_log_nosuid | | References: | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7 | | nist-csf | PR.IP-1, PR.PT-2, PR.PT-3 | | os-srg | SRG-OS-000368-GPOS-00154 | | anssi | R28 |
| |
|
Rule
Add nosuid Option to /var
[ref] | The nosuid mount option can be used to prevent
execution of setuid programs in /var. The SUID and SGID permissions
should not be required for this directory.
Add the nosuid option to the list of
Options in the systemd.mount unit that
controls mounting of
/var. | | Rationale: | The presence of SUID and SGID executables should be tightly controlled. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_var_nosuid | | References: | | |
|
Rule
Add noexec Option to /var/tmp
[ref] | The noexec mount option can be used to prevent binaries
from being executed out of /var/tmp.
Add the noexec option to the list of
Options in the systemd.mount unit that
controls mounting of
/var/tmp. | | Rationale: | Allowing users to execute binaries from world-writable directories
such as /var/tmp should never be necessary in normal operation and
can expose the system to potential compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_var_tmp_noexec | | Identifiers: | CCE-82866-5 | | References: | | |
|
Rule
Add nosuid Option to /var/tmp
[ref] | The nosuid mount option can be used to prevent
execution of setuid programs in /var/tmp. The SUID and SGID permissions
should not be required in these world-writable directories.
Add the nosuid option to the list of
Options in the systemd.mount unit that
controls mounting of
/var/tmp. | | Rationale: | The presence of SUID and SGID executables should be tightly controlled. Users
should not be able to execute SUID or SGID binaries from temporary storage partitions. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_var_tmp_nosuid | | Identifiers: | CCE-82736-0 | | References: | | |
|
| Group
Restrict Programs from Dangerous Execution Patterns
Group contains 2 groups and 9 rules |
[ref]
The recommendations in this section are designed to
ensure that the system's features to protect against potentially
dangerous program execution are activated.
These protections are applied at the system initialization or
kernel level, and defend against certain types of badly-configured
or compromised programs. |
| Group
Disable Core Dumps
Group contains 1 rule |
[ref]
A core dump file is the memory image of an executable
program when it was terminated by the operating system due to
errant behavior. In most cases, only software developers
legitimately need to access these files. The core dump files may
also contain sensitive information, or unnecessarily occupy large
amounts of disk space.
Once a hard limit is set in /etc/security/limits.conf, or
to a file within the /etc/security/limits.d/ directory, a
user cannot increase that limit within his or her own session. If access
to core dumps is required, consider restricting them to only
certain users or groups. See the limits.conf man page for more
information.
The core dumps of setuid programs are further protected. The
sysctl variable fs.suid_dumpable controls whether
the kernel allows core dumps from these programs at all. The default
value of 0 is recommended. |
Rule
Disable Core Dumps for SUID programs
[ref] | To set the runtime status of the fs.suid_dumpable kernel parameter, run the following command: $ sudo sysctl -w fs.suid_dumpable=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: fs.suid_dumpable = 0
| | Rationale: | The core dump of a setuid program is more likely to contain
sensitive data, as the program itself runs with greater privileges than the
user who initiated execution of the program. Disabling the ability for any
setuid program to write a core file decreases the risk of unauthorized access
of such data. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_fs_suid_dumpable | | References: | | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e) | | nist | SI-11(a), SI-11(b) | | anssi | R14 | | pcidss4 | 3.3.1.1, 3.3.1, 3.3 |
| |
|
| Group
Enable ExecShield
Group contains 2 rules |
[ref]
ExecShield describes kernel features that provide
protection against exploitation of memory corruption errors such as buffer
overflows. These features include random placement of the stack and other
memory regions, prevention of execution in memory that should only hold data,
and special handling of text buffers. These protections are enabled by default
on 32-bit systems and controlled through sysctl variables
kernel.exec-shield and kernel.randomize_va_space. On the latest
64-bit systems, kernel.exec-shield cannot be enabled or disabled with
sysctl. |
Rule
Restrict Exposed Kernel Pointer Addresses Access
[ref] | To set the runtime status of the kernel.kptr_restrict kernel parameter, run the following command: $ sudo sysctl -w kernel.kptr_restrict=2
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: kernel.kptr_restrict = 2
| | Rationale: | Exposing kernel pointers (through procfs or seq_printf()) exposes kernel
writeable structures which may contain functions pointers. If a write vulnerability
occurs in the kernel, allowing write access to any of this structure, the kernel can
be compromised. This option disallow any program without the CAP_SYSLOG capability
to get the addresses of kernel pointers by replacing them with 0. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_kptr_restrict | | Identifiers: | CCE-82498-7 | | References: | | nerc-cip | CIP-002-5 R1.1, CIP-002-5 R1.2, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 4.1, CIP-004-6 4.2, CIP-004-6 R2.2.3, CIP-004-6 R2.2.4, CIP-004-6 R2.3, CIP-004-6 R4, CIP-005-6 R1, CIP-005-6 R1.1, CIP-005-6 R1.2, CIP-007-3 R3, CIP-007-3 R3.1, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3, CIP-007-3 R8.4, CIP-009-6 R.1.1, CIP-009-6 R4 | | nist | SC-30, SC-30(2), SC-30(5), CM-6(a) | | ospp | FMT_SMF_EXT.1 | | os-srg | SRG-OS-000132-GPOS-00067, SRG-OS-000433-GPOS-00192, SRG-OS-000480-GPOS-00227 | | anssi | R9 |
| |
|
Rule
Enable Randomized Layout of Virtual Address Space
[ref] | To set the runtime status of the kernel.randomize_va_space kernel parameter, run the following command: $ sudo sysctl -w kernel.randomize_va_space=2
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: kernel.randomize_va_space = 2
| | Rationale: | Address space layout randomization (ASLR) makes it more difficult for an
attacker to predict the location of attack code they have introduced into a
process's address space during an attempt at exploitation. Additionally,
ASLR makes it more difficult for an attacker to know the location of
existing code in order to re-purpose it using return oriented programming
(ROP) techniques. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_randomize_va_space | | Identifiers: | CCE-88128-4 | | References: | | cui | 3.1.7 | | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e) | | nerc-cip | CIP-002-5 R1.1, CIP-002-5 R1.2, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 4.1, CIP-004-6 4.2, CIP-004-6 R2.2.3, CIP-004-6 R2.2.4, CIP-004-6 R2.3, CIP-004-6 R4, CIP-005-6 R1, CIP-005-6 R1.1, CIP-005-6 R1.2, CIP-007-3 R3, CIP-007-3 R3.1, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3, CIP-007-3 R8.4, CIP-009-6 R.1.1, CIP-009-6 R4 | | nist | SC-30, SC-30(2), CM-6(a) | | pcidss | Req-2.2.1 | | os-srg | SRG-OS-000433-GPOS-00193, SRG-OS-000480-GPOS-00227 | | app-srg-ctr | SRG-APP-000450-CTR-001105, CNTR-OS-000810, CNTR-OS-000860, CNTR-OS-000870 | | anssi | R9 | | pcidss4 | 3.3.1.1, 3.3.1, 3.3 |
| |
|
Rule
Restrict Access to Kernel Message Buffer
[ref] | To set the runtime status of the kernel.dmesg_restrict kernel parameter, run the following command: $ sudo sysctl -w kernel.dmesg_restrict=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: kernel.dmesg_restrict = 1
| | Rationale: | Unprivileged access to the kernel syslog can expose sensitive kernel
address information. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_dmesg_restrict | | Identifiers: | CCE-82499-5 | | References: | | cui | 3.1.5 | | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e) | | nist | SI-11(a), SI-11(b) | | ospp | FMT_SMF_EXT.1 | | os-srg | SRG-OS-000132-GPOS-00067, SRG-OS-000138-GPOS-00069 | | app-srg-ctr | SRG-APP-000243-CTR-000600, CNTR-OS-000560, CNTR-OS-000570, CNTR-OS-000580, CNTR-OS-000590, CNTR-OS-000600, CNTR-OS-000610 | | anssi | R9 |
| |
|
Rule
Kernel panic on oops
[ref] | To set the runtime status of the kernel.panic_on_oops kernel parameter, run the following command: $ sudo sysctl -w kernel.panic_on_oops=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: kernel.panic_on_oops = 1
Warning:
The system may start to panic when it normally wouldn't. A non-catastrophic error that
would have allowed the system to continue operating will now result in a panic. | | Rationale: | An attacker trying to exploit the kernel may trigger kernel OOPSes,
panicking the system will impede them from continuing. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_panic_on_oops | | References: | | |
|
Rule
Disallow kernel profiling by unprivileged users
[ref] | To set the runtime status of the kernel.perf_event_paranoid kernel parameter, run the following command: $ sudo sysctl -w kernel.perf_event_paranoid=2
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: kernel.perf_event_paranoid = 2
| | Rationale: | Kernel profiling can reveal sensitive information about kernel behaviour. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_perf_event_paranoid | | Identifiers: | CCE-82502-6 | | References: | | nist | AC-6 | | ospp | FMT_SMF_EXT.1 | | os-srg | SRG-OS-000132-GPOS-00067, SRG-OS-000138-GPOS-00069 | | app-srg-ctr | SRG-APP-000243-CTR-000600, CNTR-OS-000560, CNTR-OS-000570, CNTR-OS-000580, CNTR-OS-000590, CNTR-OS-000600, CNTR-OS-000610 | | anssi | R9 |
| |
|
Rule
Disable Access to Network bpf() Syscall From Unprivileged Processes
[ref] | To set the runtime status of the kernel.unprivileged_bpf_disabled kernel parameter, run the following command: $ sudo sysctl -w kernel.unprivileged_bpf_disabled=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: kernel.unprivileged_bpf_disabled = 1
| | Rationale: | Loading and accessing the packet filters programs and maps using the bpf()
syscall has the potential of revealing sensitive information about the kernel state. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_unprivileged_bpf_disabled | | Identifiers: | CCE-82504-2 | | References: | | nist | AC-6, SC-7(10) | | os-srg | SRG-OS-000132-GPOS-00067, SRG-OS-000480-GPOS-00227 | | anssi | R9 |
| |
|
Rule
Restrict usage of ptrace to descendant processes
[ref] | To set the runtime status of the kernel.yama.ptrace_scope kernel parameter, run the following command: $ sudo sysctl -w kernel.yama.ptrace_scope=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: kernel.yama.ptrace_scope = 1
| | Rationale: | Unrestricted usage of ptrace allows compromised binaries to run ptrace
on another processes of the user. Like this, the attacker can steal
sensitive information from the target processes (e.g. SSH sessions, web browser, ...)
without any additional assistance from the user (i.e. without resorting to phishing).
| | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_yama_ptrace_scope | | Identifiers: | CCE-82501-8 | | References: | | |
|
Rule
Harden the operation of the BPF just-in-time compiler
[ref] | To set the runtime status of the net.core.bpf_jit_harden kernel parameter, run the following command: $ sudo sysctl -w net.core.bpf_jit_harden=2
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d: net.core.bpf_jit_harden = 2
| | Rationale: | When hardened, the extended Berkeley Packet Filter just-in-time compiler
will randomize any kernel addresses in the BPF programs and maps,
and will not expose the JIT addresses in /proc/kallsyms. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_core_bpf_jit_harden | | Identifiers: | CCE-82505-9 | | References: | | |
|
| Group
SELinux
Group contains 7 rules |
[ref]
SELinux is a feature of the Linux kernel which can be
used to guard against misconfigured or compromised programs.
SELinux enforces the idea that programs should be limited in what
files they can access and what actions they can take.
The default SELinux policy, as configured on Red Hat Enterprise Linux CoreOS 4, has been
sufficiently developed and debugged that it should be usable on
almost any system with minimal configuration and a small
amount of system administrator training. This policy prevents
system services - including most of the common network-visible
services such as mail servers, FTP servers, and DNS servers - from
accessing files which those services have no valid reason to
access. This action alone prevents a huge amount of possible damage
from network attacks against services, from trojaned software, and
so forth.
This guide recommends that SELinux be enabled using the
default (targeted) policy on every Red Hat Enterprise Linux CoreOS 4 system, unless that
system has unusual requirements which make a stronger policy
appropriate. |
Rule
Verify Group Who Owns /etc/selinux Directory
[ref] | To properly set the group owner of /etc/selinux, run the command:
$ sudo chgrp root /etc/selinux
| | Rationale: | The ownership of the /etc/selinux directory by the root group is important
because this directory hosts SELinux configuration. Protection of this
directory is critical for system security. Assigning the ownership to root
ensures exclusive control of the SELinux configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_groupowner_etc_selinux | | References: | | |
|
Rule
Verify User Who Owns /etc/selinux Directory
[ref] | To properly set the owner of /etc/selinux, run the command:
$ sudo chown root /etc/selinux
| | Rationale: | The ownership of the /etc/selinux directory by the root user is important
because this directory hosts SELinux configuration. Protection of this
directory is critical for system security. Assigning the ownership to root
ensures exclusive control of the SELinux configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_owner_etc_selinux | | References: | | |
|
Rule
Verify Permissions On /etc/selinux Directory
[ref] | To properly set the permissions of /etc/selinux, run the command: $ sudo chmod 0755 /etc/selinux
| | Rationale: | Setting correct permissions on the /etc/selinux directory is important
because this directory hosts SELinux configuration. Protection of this
directory is critical for system security. Restricting the permissions
ensures exclusive control of the SELinux configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_directory_permissions_etc_selinux | | References: | | |
|
Rule
Verify Group Who Owns /etc/sestatus.conf File
[ref] | To properly set the group owner of /etc/sestatus.conf, run the command:
$ sudo chgrp root /etc/sestatus.conf
| | Rationale: | The ownership of the /etc/sestatus.conf file by the root group is important
because this file hosts SELinux configuration. Protection of this
file is critical for system security. Assigning the ownership to root
ensures exclusive control of the SELinux configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_sestatus_conf | | References: | | |
|
Rule
Verify User Who Owns /etc/sestatus.conf File
[ref] | To properly set the owner of /etc/sestatus.conf, run the command:
$ sudo chown root /etc/sestatus.conf
| | Rationale: | The ownership of the /etc/sestatus.conf file by the root user is important
because this file hosts SELinux configuration. Protection of this
file is critical for system security. Assigning the ownership to root
ensures exclusive control of the SELinux configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_sestatus_conf | | References: | | |
|
Rule
Verify Permissions On /etc/sestatus.conf File
[ref] | To properly set the permissions of /etc/sestatus.conf, run the command: $ sudo chmod 0644 /etc/sestatus.conf
| | Rationale: | Setting correct permissions on the /etc/sestatus.conf file is important
because this file hosts SELinux configuration. Protection of this
file is critical for system security. Restricting the permissions
ensures exclusive control of the SELinux configuration. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_sestatus_conf | | References: | | |
|
Rule
Configure SELinux Policy
[ref] | The SELinux targeted policy is appropriate for
general-purpose desktops and servers, as well as systems in many other roles.
To configure the system to use this policy, add or correct the following line
in /etc/selinux/config:
SELINUXTYPE=targeted
Other policies, such as mls, provide additional security labeling
and greater confinement but are not compatible with many general-purpose
use cases. | | Rationale: | Setting the SELinux policy to targeted or a more specialized policy
ensures the system will confine processes that are likely to be
targeted for exploitation, such as network or system services.
Note: During the development or debugging of SELinux modules, it is common to
temporarily place non-production systems in permissive mode. In such
temporary cases, SELinux policies should be developed, and once work
is completed, the system should be reconfigured to
targeted. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_selinux_policytype | | Identifiers: | CCE-82532-3 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 3, 4, 5, 6, 8, 9 | | cobit5 | APO01.06, APO11.04, APO13.01, BAI03.05, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.03, DSS06.06, MEA02.01 | | cui | 3.1.2, 3.7.2 | | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e) | | isa-62443-2009 | 4.2.3.4, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, 4.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.2, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-004-6 R3.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, CIP-007-3 R6.5 | | nist | AC-3, AC-3(3)(a), AU-9, SC-7(21) | | nist-csf | DE.AE-1, ID.AM-3, PR.AC-4, PR.AC-5, PR.AC-6, PR.DS-5, PR.PT-1, PR.PT-3, PR.PT-4 | | ospp | FMT_MOF_EXT.1 | | os-srg | SRG-OS-000445-GPOS-00199 | | app-srg-ctr | SRG-APP-000233-CTR-000585, CNTR-OS-000540 | | anssi | R46, R64 | | bsi | APP.4.4.A4, SYS.1.6.A3, SYS.1.6.A18, SYS.1.6.A21 | | pcidss4 | 1.2.6, 1.2 |
| |
|
| Group
Services
Group contains 9 groups and 24 rules |
[ref]
The best protection against vulnerable software is running less software. This section describes how to review
the software which Red Hat Enterprise Linux CoreOS 4 installs on a system and disable software which is not needed. It
then enumerates the software packages installed on a default Red Hat Enterprise Linux CoreOS 4 system and provides guidance about which
ones can be safely disabled.
Red Hat Enterprise Linux CoreOS 4 provides a convenient minimal install option that essentially installs the bare necessities for a functional
system. When building Red Hat Enterprise Linux CoreOS 4 systems, it is highly recommended to select the minimal packages and then build up
the system from there. |
| Group
DHCP
Group contains 1 group and 1 rule |
[ref]
The Dynamic Host Configuration Protocol (DHCP) allows
systems to request and obtain an IP address and other configuration
parameters from a server.
This guide recommends configuring networking on clients by manually editing
the appropriate files under /etc/sysconfig. Use of DHCP can make client
systems vulnerable to compromise by rogue DHCP servers, and should be avoided
unless necessary. If using DHCP is necessary, however, there are best practices
that should be followed to minimize security risk. |
| Group
Disable DHCP Server
Group contains 1 rule |
[ref]
The DHCP server dhcpd is not installed or activated by
default. If the software was installed and activated, but the
system does not need to act as a DHCP server, it should be disabled
and removed. |
Rule
Uninstall kea Package
[ref] | If the system does not need to act as a DHCP server,
the kea package can be uninstalled. | | Rationale: | Removing the DHCP server ensures that it cannot be easily or
accidentally reactivated and disrupt network operation. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_kea_removed | | References: | | |
|
| Group
Mail Server Software
Group contains 1 group and 2 rules |
[ref]
Mail servers are used to send and receive email over the network.
Mail is a very common service, and Mail Transfer Agents (MTAs) are obvious
targets of network attack.
Ensure that systems are not running MTAs unnecessarily,
and configure needed MTAs as defensively as possible.
Very few systems at any site should be configured to directly receive email over the
network. Users should instead use mail client programs to retrieve email
from a central server that supports protocols such as IMAP or POP3.
However, it is normal for most systems to be independently capable of sending email,
for instance so that cron jobs can report output to an administrator.
Most MTAs, including Postfix, support a submission-only mode in which mail can be sent from
the local system to a central site MTA (or directly delivered to a local account),
but the system still cannot receive mail directly over a network.
The alternatives program in Red Hat Enterprise Linux CoreOS 4 permits selection of other mail server software
(such as Sendmail), but Postfix is the default and is preferred.
Postfix was coded with security in mind and can also be more effectively contained by
SELinux as its modular design has resulted in separate processes performing specific actions.
More information is available on its website,
http://www.postfix.org. |
| Group
Configure SMTP For Mail Clients
Group contains 1 rule |
[ref]
This section discusses settings for Postfix in a submission-only
e-mail configuration. |
Rule
Configure System to Forward All Mail For The Root Account
[ref] | Make sure that mails delivered to root user are forwarded to a monitored
email address. Make sure that the address
change_me@localhost is a valid email address
reachable from the system in question. Use the following command to
configure the alias:
$ sudo echo "root: change_me@localhost" >> /etc/aliases
$ sudo newaliases
| | Rationale: | A number of system services utilize email messages sent to the root user to
notify system administrators of active or impending issues. These messages must
be forwarded to at least one monitored email address. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_postfix_client_configure_mail_alias | | References: | | |
|
Rule
Uninstall Sendmail Package
[ref] | Sendmail is not the default mail transfer agent and is
not installed by default.
The sendmail package can be removed with the following command:
$ sudo dnf remove sendmail
| | Rationale: | The sendmail software was not developed with security in mind and
its design prevents it from being effectively contained by SELinux. Postfix
should be used instead. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_sendmail_removed | | References: | | cis-csc | 11, 14, 3, 9 | | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6 | | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2 | | nist | CM-7(a), CM-7(b), CM-6(a) | | nist-csf | PR.IP-1, PR.PT-3 | | os-srg | SRG-OS-000480-GPOS-00227, SRG-OS-000095-GPOS-00049 | | anssi | R62 |
| |
|
| Group
Network Time Protocol
Group contains 6 rules |
[ref]
The Network Time Protocol is used to manage the system
clock over a network. Computer clocks are not very accurate, so
time will drift unpredictably on unmanaged systems. Central time
protocols can be used both to ensure that time is consistent among
a network of systems, and that their time is consistent with the
outside world.
If every system on a network reliably reports the same time, then it is much
easier to correlate log messages in case of an attack. In addition, a number of
cryptographic protocols (such as Kerberos) use timestamps to prevent certain
types of attacks. If your network does not have synchronized time, these
protocols may be unreliable or even unusable.
Depending on the specifics of the network, global time accuracy may be just as
important as local synchronization, or not very important at all. If your
network is connected to the Internet, using a public timeserver (or one
provided by your enterprise) provides globally accurate timestamps which may be
essential in investigating or responding to an attack which originated outside
of your network.
A typical network setup involves a small number of internal systems operating
as NTP servers, and the remainder obtaining time information from those
internal servers.
There is a choice between the daemons ntpd and chronyd, which
are available from the repositories in the ntp and chrony
packages respectively.
The default chronyd daemon can work well when external time references
are only intermittently accesible, can perform well even when the network is
congested for longer periods of time, can usually synchronize the clock faster
and with better time accuracy, and quickly adapts to sudden changes in the rate
of the clock, for example, due to changes in the temperature of the crystal
oscillator. Chronyd should be considered for all systems which are
frequently suspended or otherwise intermittently disconnected and reconnected
to a network. Mobile and virtual systems for example.
The ntpd NTP daemon fully supports NTP protocol version 4 (RFC 5905),
including broadcast, multicast, manycast clients and servers, and the orphan
mode. It also supports extra authentication schemes based on public-key
cryptography (RFC 5906). The NTP daemon ( ntpd) should be considered
for systems which are normally kept permanently on. Systems which are required
to use broadcast or multicast IP, or to perform authentication of packets with
the Autokey protocol, should consider using ntpd.
Refer to
https://en.wikipedia.org/wiki/Network_Time_Protocol
for more detailed comparison of features of chronyd
and ntpd daemon features respectively, and for further guidance how to
choose between the two NTP daemons.
The upstream manual pages at
https://chrony-project.org/documentation.html for
chronyd and
http://www.ntp.org for ntpd provide additional
information on the capabilities and configuration of each of the NTP daemons. |
Rule
The Chrony package is installed
[ref] | System time should be synchronized between all systems in an environment. This is
typically done by establishing an authoritative time server or set of servers and having all
systems synchronize their clocks to them.
The chrony package can be installed with the following command:
$ sudo dnf install chrony
| | Rationale: | Time synchronization is important to support time sensitive security mechanisms like
Kerberos and also ensures log files have consistent time records across the enterprise,
which aids in forensic investigations. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_chrony_installed | | References: | | |
|
Rule
Enable the NTP Daemon
[ref] |
As a user with administrator privileges, log into a node in the relevant pool:
$ oc debug node/$NODE_NAME
At the sh-4.4# prompt, run:
# chroot /host
Run the following command to determine the current status of the
chronyd service:
$ sudo systemctl is-active chronyd
If the service is running, it should return the following: active
Note: The chronyd daemon is enabled by default.
As a user with administrator privileges, log into a node in the relevant pool:
$ oc debug node/$NODE_NAME
At the sh-4.4# prompt, run:
# chroot /host
Run the following command to determine the current status of the
ntpd service:
$ sudo systemctl is-active ntpd
If the service is running, it should return the following: active
Note: The ntpd daemon is not enabled by default. Though as mentioned
in the previous sections in certain environments the ntpd daemon might
be preferred to be used rather than the chronyd one. Refer to:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-configuring_ntp_using_the_chrony_suite
for guidance which NTP daemon to choose depending on the environment used. | | Rationale: | Enabling some of chronyd or ntpd services ensures
that the NTP daemon will be running and that the system will synchronize its
time to any servers specified. This is important whether the system is
configured to be a client (and synchronize only its own clock) or it is also
acting as an NTP server to other systems. Synchronizing time is essential for
authentication services such as Kerberos, but it is also important for
maintaining accurate logs and auditing possible security breaches.
The chronyd and ntpd NTP daemons offer all of the
functionality of ntpdate, which is now deprecated. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_service_chronyd_or_ntpd_enabled | | Identifiers: | CCE-82682-6 | | References: | | cis-csc | 1, 14, 15, 16, 3, 5, 6 | | cobit5 | APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01 | | cui | 3.3.7 | | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9 | | ism | 0988, 1405 | | iso27001-2013 | A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1 | | nist | CM-6(a), AU-8(1)(a), AU-12(1) | | nist-csf | PR.PT-1 | | pcidss | Req-10.4.1 | | app-srg-ctr | SRG-APP-000116-CTR-000235, CNTR-OS-000230, CNTR-OS-000240 | | anssi | R71 | | pcidss4 | 10.6.1, 10.6 |
| |
|
Rule
A remote time server for Chrony is configured
[ref] | Chrony is a daemon which implements the Network Time Protocol (NTP). It is designed
to synchronize system clocks across a variety of systems and use a source that is highly
accurate. More information on chrony can be found at
https://chrony-project.org/.
Chrony can be configured to be a client and/or a server.
Add or edit server or pool lines to /etc/chrony.conf as appropriate:
server <remote-server>
Multiple servers may be configured. | | Rationale: | If chrony is in use on the system proper configuration is vital to ensuring time
synchronization is working properly. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_chronyd_specify_remote_server | | References: | | |
|
Rule
Verify Group Who Owns /etc/chrony.keys File
[ref] | To properly set the group owner of /etc/chrony.keys, run the command:
$ sudo chgrp chrony /etc/chrony.keys
| | Rationale: | The ownership of the /etc/chrony.keys file by the chrony group is important
because this file hosts chrony cryptographic keys. Protection
of this file is critical for system security. Assigning the ownership to
chrony ensures exclusive control of the chrony cryptography keys. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_chrony_keys | | References: | | |
|
Rule
Verify User Who Owns /etc/chrony.keys File
[ref] | To properly set the owner of /etc/chrony.keys, run the command:
$ sudo chown root /etc/chrony.keys
| | Rationale: | The ownership of the /etc/chrony.keys file by the chrony user is important
because this file hosts chrony cryptographic keys. Protection
of this file is critical for system security. Assigning the ownership to
chrony ensures exclusive control of the chrony cryptographic keys. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_chrony_keys | | References: | | |
|
Rule
Verify Permissions On /etc/chrony.keys File
[ref] | To properly set the permissions of /etc/chrony.keys, run the command: $ sudo chmod 0640 /etc/chrony.keys
| | Rationale: | Setting correct permissions on the /etc/chrony.keys file is important
because this file hosts chrony cryptographic keys. Protection
of this file is critical for system security. Assigning the correct mode
ensures exclusive control of the chrony cryptographic keys. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_chrony_keys | | References: | | |
|
| Group
SSH Server
Group contains 1 group and 10 rules |
[ref]
The SSH protocol is recommended for remote login and
remote file transfer. SSH provides confidentiality and integrity
for data exchanged between two systems, as well as server
authentication, through the use of public key cryptography. The
implementation included with the system is called OpenSSH, and more
detailed documentation is available from its website,
https://www.openssh.com.
Its server program is called sshd and provided by the RPM package
openssh-server. |
| Group
Configure OpenSSH Server if Necessary
Group contains 1 rule |
[ref]
If the system needs to act as an SSH server, then
certain changes should be made to the OpenSSH daemon configuration
file /etc/ssh/sshd_config. The following recommendations can be
applied to this file. See the sshd_config(5) man page for more
detailed information. |
Rule
Disable SSH Root Login
[ref] | The root user should never be allowed to login to a
system directly over a network.
To disable root login via SSH, add or correct the following line in
/etc/ssh/sshd_config:
PermitRootLogin no
| | Rationale: | Even though the communications channel may be encrypted, an additional layer of
security is gained by extending the policy of not logging directly on as root.
In addition, logging in with a user-specific account provides individual
accountability of actions performed on the system and also helps to minimize
direct attack attempts on root's password. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_disable_root_login | | Identifiers: | CCE-89550-8 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 3, 5 | | cjis | 5.5.6 | | cobit5 | APO01.06, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.02, DSS06.03, DSS06.06, DSS06.10 | | cui | 3.1.1, 3.1.5 | | hipaa | 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii) | | isa-62443-2009 | 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 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.18.1.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 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, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | | nist | AC-6(2), AC-17(a), IA-2, IA-2(5), CM-7(a), CM-7(b), CM-6(a) | | nist-csf | PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.DS-5, PR.PT-3 | | ospp | FAU_GEN.1 | | pcidss | Req-2.2.4 | | os-srg | SRG-OS-000109-GPOS-00056, SRG-OS-000480-GPOS-00227 | | app-srg-ctr | SRG-APP-000148-CTR-000335, SRG-APP-000190-CTR-000500, CNTR-OS-000400, CNTR-OS-000490 | | anssi | R33 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Group Who Owns SSH Server config file
[ref] |
To properly set the group owner of /etc/ssh/sshd_config, run the command:
$ sudo chgrp root /etc/ssh/sshd_config
| | Rationale: | Service configuration files enable or disable features of their respective
services that if configured incorrectly can lead to insecure and vulnerable
configurations. Therefore, service configuration files should be owned by the
correct group to prevent unauthorized changes. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_sshd_config | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | AC-17(a), CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 |
| |
|
Rule
Verify Group Ownership on SSH Server Private *_key Key Files
[ref] | SSH server private keys, files that match the /etc/ssh/*_key glob, must be
group-owned by ssh_keys group. Warning:
Remediation is not possible at bootable container build time because SSH host
keys are generated post-deployment. | | Rationale: | If an unauthorized user obtains the private SSH host key file, the host could be impersonated. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupownership_sshd_private_key | | References: | | |
|
Rule
Verify Group Ownership on SSH Server Public *.pub Key Files
[ref] | SSH server public keys, files that match the /etc/ssh/*.pub glob, must be
group-owned by root group. Warning:
Remediation is not possible at bootable container build time because SSH host
keys are generated post-deployment. | | Rationale: | If a public host key file is modified by an unauthorized user, the SSH service
may be compromised. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupownership_sshd_pub_key | | References: | | |
|
Rule
Verify Owner on SSH Server config file
[ref] |
To properly set the owner of /etc/ssh/sshd_config, run the command:
$ sudo chown root /etc/ssh/sshd_config
| | Rationale: | Service configuration files enable or disable features of their respective
services that if configured incorrectly can lead to insecure and vulnerable
configurations. Therefore, service configuration files should be owned by the
correct group to prevent unauthorized changes. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_sshd_config | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | AC-17(a), CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 |
| |
|
Rule
Verify Ownership on SSH Server Private *_key Key Files
[ref] | SSH server private keys, files that match the /etc/ssh/*_key glob, must be owned
by root user. Warning:
Remediation is not possible at bootable container build time because SSH host
keys are generated post-deployment. | | Rationale: | If an unauthorized user obtains the private SSH host key file, the host could be impersonated. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_ownership_sshd_private_key | | References: | | |
|
Rule
Verify Ownership on SSH Server Public *.pub Key Files
[ref] | SSH server public keys, files that match the /etc/ssh/*.pub glob, must be owned
by root user. Warning:
Remediation is not possible at bootable container build time because SSH host
keys are generated post-deployment. | | Rationale: | If a public host key file is modified by an unauthorized user, the SSH service
may be compromised. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_ownership_sshd_pub_key | | References: | | |
|
Rule
Verify Permissions on SSH Server config file
[ref] |
To properly set the permissions of /etc/ssh/sshd_config, run the command:
$ sudo chmod 0600 /etc/ssh/sshd_config
| | Rationale: | Service configuration files enable or disable features of their respective
services that if configured incorrectly can lead to insecure and vulnerable
configurations. Therefore, service configuration files should be owned by the
correct group to prevent unauthorized changes. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_sshd_config | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | AC-17(a), CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Permissions on SSH Server Private *_key Key Files
[ref] | SSH server private keys - files that match the /etc/ssh/*_key glob, have to have restricted permissions.
If those files are owned by the root user and the root group, they have to have the 0640 permission or stricter.
If they are owned by the root user, but by a dedicated group ssh_keys, they can have the 0640 permission or stricter. Warning:
Remediation is not possible at bootable container build time because SSH host
keys are generated post-deployment. | | Rationale: | If an unauthorized user obtains the private SSH host key file, the host could be
impersonated. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_sshd_private_key | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.1.13, 3.13.10 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | AC-17(a), CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-2.2.4 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 | | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Permissions on SSH Server Public *.pub Key Files
[ref] | To properly set the permissions of /etc/ssh/*.pub, run the command: $ sudo chmod 0644 /etc/ssh/*.pub
Warning:
Remediation is not possible at bootable container build time because SSH host
keys are generated post-deployment. | | Rationale: | If a public host key file is modified by an unauthorized user, the SSH service
may be compromised. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_sshd_pub_key | | References: | | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | | cui | 3.1.13, 3.13.10 | | isa-62443-2009 | 4.3.3.7.3 | | isa-62443-2013 | SR 2.1, SR 5.2 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | | nist | AC-17(a), CM-6(a), AC-6(1) | | nist-csf | PR.AC-4, PR.DS-5 | | pcidss | Req-2.2.4 | | os-srg | SRG-OS-000480-GPOS-00227 | | anssi | R50 | | pcidss4 | 2.2.6, 2.2 |
| |
|
| Group
System Security Services Daemon
Group contains 1 group and 5 rules |
[ref]
The System Security Services Daemon (SSSD) is a system daemon that provides access
to different identity and authentication providers such as Red Hat's IdM, Microsoft's AD,
openLDAP, MIT Kerberos, etc. It uses a common framework that can provide caching and offline
support to systems utilizing SSSD. SSSD using caching to reduce load on authentication
servers permit offline authentication as well as store extended user data.
For more information, see |
| Group
System Security Services Daemon (SSSD) - LDAP
Group contains 2 rules |
[ref]
The System Security Services Daemon (SSSD) is a system daemon that provides access
to different identity and authentication providers such as Red Hat's IdM, Microsoft's AD,
openLDAP, MIT Kerberos, etc. It uses a common framework that can provide caching and offline
support to systems utilizing SSSD. SSSD using caching to reduce load on authentication
servers permit offline authentication as well as store extended user data.
SSSD can support many backends including LDAP. The sssd-ldap backend
allows SSSD to fetch identity information from an LDAP server. |
Rule
Configure SSSD LDAP Backend Client to Demand a Valid Certificate from the Server
[ref] | Configure SSSD to demand a valid certificate from the server to
protect the integrity of LDAP remote access sessions by setting
the ldap_tls_reqcert option in /etc/sssd/sssd.conf
to demand. | | Rationale: | Without a valid certificate presented to the LDAP client backend, the identity of a
server can be forged compromising LDAP remote access sessions. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sssd_ldap_configure_tls_reqcert | | References: | | |
|
Rule
Configure SSSD LDAP Backend to Use TLS For All Transactions
[ref] | The LDAP client should be configured to implement TLS for the integrity
of all remote LDAP authentication sessions. If the id_provider is
set to ldap or ipa in /etc/sssd/sssd.conf or any of the
/etc/sssd/sssd.conf.d configuration files, ldap_id_use_start_tls
must be set to true.
To check if LDAP is configured to use TLS when id_provider is
set to ldap or ipa, use the following command:
$ sudo grep -i ldap_id_use_start_tls /etc/sssd/sssd.conf /etc/sssd/conf.d/*.conf
| | Rationale: | Without cryptographic integrity protections, information can be
altered by unauthorized users without detection. The ssl directive specifies
whether to use TLS or not. If not specified it will default to no.
It should be set to start_tls rather than doing LDAP over SSL. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sssd_ldap_start_tls | | References: | | cis-csc | 11, 12, 14, 15, 3, 8, 9 | | cobit5 | APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.04, DSS05.02, DSS05.03, DSS05.05, DSS06.06 | | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | | iso27001-2013 | A.11.2.6, A.12.1.2, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.2.1, A.6.2.2, A.9.1.2 | | nist | CM-7(a), CM-7(b), CM-6(a) | | nist-csf | PR.AC-3, PR.IP-1, PR.PT-3, PR.PT-4 | | os-srg | SRG-OS-000250-GPOS-00093 | | anssi | R67 |
| |
|
Rule
Install the SSSD Package
[ref] | The sssd package should be installed.
The sssd package can be installed with the following command:
$ sudo dnf install sssd
| | Rationale: | | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_package_sssd_installed | | References: | | cis-csc | 1, 12, 15, 16, 5 | | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | | nist | CM-6(a) | | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | | anssi | R67 |
| |
|
Rule
Enable the SSSD Service
[ref] | The SSSD service should be enabled.
The sssd 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-sssd-enable
spec:
config:
ignition:
version: 3.1.0
systemd:
units:
- name: sssd.service
enabled: true
This will enable the sssd 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.
Warning:
The service requires a valid sssd configuration. If the configuration is not present, the service will fail to start and consequently this rule will be reported as failing. The configuration shipped in your distribution package might not be sufficient. Manual modification of configuration files might be required. | | Rationale: | | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_service_sssd_enabled | | References: | | cis-csc | 1, 12, 15, 16, 5 | | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | | nist | CM-6(a), IA-5(10) | | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | | anssi | R67 |
| |
|
Rule
Configure PAM in SSSD Services
[ref] | SSSD should be configured to run SSSD pam services.
To configure SSSD to known SSH hosts, add pam
to services under the [sssd] section in
/etc/sssd/sssd.conf. For example:
[sssd]
services = sudo, autofs, pam
| | Rationale: | Using an authentication device, such as a CAC or token that is separate from
the information system, ensures that even if the information system is
compromised, that compromise will not affect credentials stored on the
authentication device. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_sssd_enable_pam_services | | References: | | cis-csc | 1, 12, 15, 16, 5 | | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | | nist | IA-2(1), CM-6(a) | | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | | os-srg | SRG-OS-000375-GPOS-00160, SRG-OS-000376-GPOS-00161, SRG-OS-000377-GPOS-00162 | | anssi | R67 |
| |
|
| Group
System Accounting with auditd
Group contains 8 groups and 50 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 Rules for Comprehensive Auditing
Group contains 7 groups and 48 rules |
[ref]
The auditd program can perform comprehensive
monitoring of system activity. This section describes recommended
configuration settings for comprehensive auditing, but a full
description of the auditing system's capabilities is beyond the
scope of this guide. The mailing list linux-audit@redhat.com exists
to facilitate community discussion of the auditing system.
The audit subsystem supports extensive collection of events, including:
- Tracing of arbitrary system calls (identified by name or number)
on entry or exit.
- Filtering by PID, UID, call success, system call argument (with
some limitations), etc.
- Monitoring of specific files for modifications to the file's
contents or metadata.
Auditing rules at startup are controlled by the file /etc/audit/audit.rules.
Add rules to it to meet the auditing requirements for your organization.
Each line in /etc/audit/audit.rules represents a series of arguments
that can be passed to auditctl and can be individually tested
during runtime. See documentation in /usr/share/doc/audit-VERSION
and
in the related man pages for more details.
If copying any example audit rulesets from /usr/share/doc/audit-VERSION,
be sure to comment out the
lines containing arch= which are not appropriate for your system's
architecture. Then review and understand the following rules,
ensuring rules are activated as needed for the appropriate
architecture.
After reviewing all the rules, reading the following sections, and
editing as needed, the new rules can be activated as follows:
$ sudo service auditd restart
|
| Group
Record Events that Modify the System's Discretionary Access Controls
Group contains 14 rules |
[ref]
At a minimum, the audit system should collect file permission
changes for all users and root. Note that the "-F arch=b32" lines should be
present even on a 64 bit system. These commands identify system calls for
auditing. Even if the system is 64 bit it can still execute 32 bit system
calls. Additionally, these rules can be configured in a number of ways while
still achieving the desired effect. An example of this is that the "-S" calls
could be split up and placed on separate lines, however, this is less efficient.
Add the following to /etc/audit/audit.rules:
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If your system is 64 bit then these lines should be duplicated and the
arch=b32 replaced with arch=b64 as follows:
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
|
Rule
Record Events that Modify the System's Discretionary Access Controls - chmod
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured to
use the augenrules program to read audit rules during daemon startup
(the default), add the following line to a file with suffix .rules in
the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_chmod | | Identifiers: | CCE-82556-2 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.5.5 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203 | | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, CNTR-OS-000160, CNTR-OS-000930, CNTR-OS-000950 | | anssi | R73 | | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - chown
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured to
use the augenrules program to read audit rules during daemon startup
(the default), add the following line to a file with suffix .rules in
the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_chown | | Identifiers: | CCE-82557-0 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.5.5 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219 | | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, CNTR-OS-000160, CNTR-OS-000930, CNTR-OS-000950 | | anssi | R73 | | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - fchmod
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured to
use the augenrules program to read audit rules during daemon startup
(the default), add the following line to a file with suffix .rules in
the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchmod | | Identifiers: | CCE-82558-8 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.5.5 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203 | | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, CNTR-OS-000160, CNTR-OS-000930, CNTR-OS-000950 | | anssi | R73 | | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - fchmodat
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured to
use the augenrules program to read audit rules during daemon startup
(the default), add the following line to a file with suffix .rules in
the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchmodat | | Identifiers: | CCE-82559-6 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.5.5 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203 | | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, CNTR-OS-000160, CNTR-OS-000930, CNTR-OS-000950 | | anssi | R73 | | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - fchown
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchown | | Identifiers: | CCE-82560-4 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.5.5 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219 | | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, CNTR-OS-000160, CNTR-OS-000930, CNTR-OS-000950 | | anssi | R73 | | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - fchownat
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchownat | | Identifiers: | CCE-82561-2 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.5.5 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219 | | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, CNTR-OS-000160, CNTR-OS-000930, CNTR-OS-000950 | | anssi | R73 | | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - fremovexattr
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root.
If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fremovexattr | | Identifiers: | CCE-82562-0 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.5.5 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219, SRG-OS-000466-GPOS-00210, SRG-OS-000468-GPOS-00212, SRG-OS-000064-GPOS-00033 | | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000499-CTR-001255, CNTR-OS-000160, CNTR-OS-000930, CNTR-OS-000940, CNTR-OS-000950 | | anssi | R73 | | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - fsetxattr
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fsetxattr | | Identifiers: | CCE-82563-8 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.5.5 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000466-GPOS-00210, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219, SRG-OS-000064-GPOS-00033 | | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270, CNTR-OS-000160, CNTR-OS-000930, CNTR-OS-000940, CNTR-OS-000960 | | anssi | R73 | | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - lchown
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_lchown | | Identifiers: | CCE-82564-6 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.5.5 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219 | | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, CNTR-OS-000160, CNTR-OS-000930, CNTR-OS-000950 | | anssi | R73 | | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - lremovexattr
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root.
If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_lremovexattr | | Identifiers: | CCE-82565-3 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.5.5 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270, CNTR-OS-000160, CNTR-OS-000930, CNTR-OS-000940, CNTR-OS-000950, CNTR-OS-000960 | | anssi | R73 | | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - lsetxattr
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_lsetxattr | | Identifiers: | CCE-82566-1 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.5.5 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000466-GPOS-00210, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219, SRG-OS-000064-GPOS-00033 | | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270, CNTR-OS-000160, CNTR-OS-000930, CNTR-OS-000940, CNTR-OS-000960 | | anssi | R73 | | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - removexattr
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root.
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following line to a file with suffix .rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_removexattr | | Identifiers: | CCE-82567-9 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.5.5 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270, CNTR-OS-000160, CNTR-OS-000930, CNTR-OS-000940, CNTR-OS-000950, CNTR-OS-000960 | | anssi | R73 | | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - setxattr
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_setxattr | | Identifiers: | CCE-82568-7 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.5.5 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000466-GPOS-00210, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203 | | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, CNTR-OS-000160, CNTR-OS-000930 | | anssi | R73 | | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - umount2
[ref] | At a minimum, the audit system should collect file system umount2
changes. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S umount2 -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S umount2 -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S umount2 -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S umount2 -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_umount2 | | References: | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215 | | app-srg-ctr | SRG-APP-000495-CTR-001235, CNTR-OS-000930 | | anssi | R73 |
| |
|
| Group
Record File Deletion Events by User
Group contains 5 rules |
[ref]
At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat,renameat2 -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat,renameat2 -F auid>=1000 -F auid!=unset -F key=delete
|
Rule
Ensure auditd Collects File Deletion Events by User - rename
[ref] | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete
| | Rationale: | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_rename | | Identifiers: | CCE-82575-2 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 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 | | isa-62443-2013 | 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 | | iso27001-2013 | A.11.2.4, 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.1.1, 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.MA-2, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | | pcidss | Req-10.2.7 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00211, SRG-OS-000468-GPOS-00212 | | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270, CNTR-OS-000930, CNTR-OS-000950, CNTR-OS-000960 | | anssi | R73 | | pcidss4 | 10.2.1.7, 10.2.1, 10.2 |
| |
|
Rule
Ensure auditd Collects File Deletion Events by User - renameat
[ref] | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete
| | Rationale: | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_renameat | | Identifiers: | CCE-82576-0 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 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 | | isa-62443-2013 | 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 | | iso27001-2013 | A.11.2.4, 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.1.1, 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.MA-2, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | | pcidss | Req-10.2.7 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00211, SRG-OS-000468-GPOS-00212 | | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270, CNTR-OS-000930, CNTR-OS-000950, CNTR-OS-000960 | | anssi | R73 | | pcidss4 | 10.2.1.7, 10.2.1, 10.2 |
| |
|
Rule
Ensure auditd Collects File Deletion Events by User - rmdir
[ref] | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S rmdir -F auid>=1000 -F auid!=unset -F key=delete
| | Rationale: | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_rmdir | | Identifiers: | CCE-82577-8 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 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 | | isa-62443-2013 | 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 | | iso27001-2013 | A.11.2.4, 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.1.1, 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.MA-2, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | | pcidss | Req-10.2.7 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00211, SRG-OS-000468-GPOS-00212 | | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270, CNTR-OS-000930, CNTR-OS-000950, CNTR-OS-000960 | | anssi | R73 | | pcidss4 | 10.2.1.7, 10.2.1, 10.2 |
| |
|
Rule
Ensure auditd Collects File Deletion Events by User - unlink
[ref] | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete
| | Rationale: | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_unlink | | Identifiers: | CCE-82578-6 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 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 | | isa-62443-2013 | 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 | | iso27001-2013 | A.11.2.4, 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.1.1, 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.MA-2, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | | pcidss | Req-10.2.7 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00211, SRG-OS-000468-GPOS-00212 | | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270, CNTR-OS-000930, CNTR-OS-000950, CNTR-OS-000960 | | anssi | R73 | | pcidss4 | 10.2.1.7, 10.2.1, 10.2 |
| |
|
Rule
Ensure auditd Collects File Deletion Events by User - unlinkat
[ref] | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete
| | Rationale: | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_unlinkat | | Identifiers: | CCE-82579-4 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 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 | | isa-62443-2013 | 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 | | iso27001-2013 | A.11.2.4, 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.1.1, 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.MA-2, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | | pcidss | Req-10.2.7 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00211, SRG-OS-000468-GPOS-00212 | | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270, CNTR-OS-000930, CNTR-OS-000950, CNTR-OS-000960 | | anssi | R73 | | pcidss4 | 10.2.1.7, 10.2.1, 10.2 |
| |
|
| Group
Record Unauthorized Access Attempts Events to Files (unsuccessful)
Group contains 5 rules |
[ref]
At a minimum, the audit system should collect unauthorized file
accesses for all users and root. Note that the "-F arch=b32" lines should be
present even on a 64 bit system. These commands identify system calls for
auditing. Even if the system is 64 bit it can still execute 32 bit system
calls. Additionally, these rules can be configured in a number of ways while
still achieving the desired effect. An example of this is that the "-S" calls
could be split up and placed on separate lines, however, this is less efficient.
Add the following to /etc/audit/audit.rules:
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If your system is 64 bit then these lines should be duplicated and the
arch=b32 replaced with arch=b64 as follows:
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
|
Rule
Record Unsuccessful Access Attempts to Files - creat
[ref] | At a minimum, the audit system should collect unauthorized file
accesses for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_creat | | Identifiers: | CCE-82621-4 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.2.4, Req-10.2.1 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205 | | app-srg-ctr | SRG-APP-000495-CTR-001235 | | anssi | R73 |
| |
|
Rule
Record Unsuccessful Access Attempts to Files - ftruncate
[ref] | At a minimum, the audit system should collect unauthorized file
accesses for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_ftruncate | | Identifiers: | CCE-82629-7 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.2.4, Req-10.2.1 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205 | | app-srg-ctr | SRG-APP-000495-CTR-001235 | | anssi | R73 |
| |
|
Rule
Record Unsuccessful Access Attempts to Files - open
[ref] | At a minimum, the audit system should collect unauthorized file
accesses for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_open | | Identifiers: | CCE-82633-9 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.2.4, Req-10.2.1 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205 | | app-srg-ctr | SRG-APP-000495-CTR-001235 | | anssi | R73 |
| |
|
Rule
Record Unsuccessful Access Attempts to Files - openat
[ref] | At a minimum, the audit system should collect unauthorized file
accesses for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_openat | | Identifiers: | CCE-82634-7 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.2.4, Req-10.2.1 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205 | | app-srg-ctr | SRG-APP-000495-CTR-001235 | | anssi | R73 |
| |
|
Rule
Record Unsuccessful Access Attempts to Files - truncate
[ref] | At a minimum, the audit system should collect unauthorized file
accesses for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_truncate | | Identifiers: | CCE-82651-1 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.2.4, Req-10.2.1 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205 | | app-srg-ctr | SRG-APP-000495-CTR-001235 | | anssi | R73 |
| |
|
| Group
Record Information on Kernel Modules Loading and Unloading
Group contains 3 rules |
[ref]
To capture kernel module loading and unloading events, use following lines, setting ARCH to
either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S init_module,delete_module -F key=modules
Place to add the lines depends on a way auditd daemon is configured. If it is configured
to use the augenrules program (the default), add the lines to a file with suffix
.rules in the directory /etc/audit/rules.d.
If the auditd daemon is configured to use the auditctl utility,
add the lines to file /etc/audit/audit.rules. |
Rule
Ensure auditd Collects Information on Kernel Module Unloading - delete_module
[ref] | To capture kernel module unloading events, use following line, setting ARCH to
either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S delete_module -F key=modules
Place to add the line depends on a way auditd daemon is configured. If it is configured
to use the augenrules program (the default), add the line to a file with suffix
.rules in the directory /etc/audit/rules.d.
If the auditd daemon is configured to use the auditctl utility,
add the line to file /etc/audit/audit.rules. | | Rationale: | The removal of kernel modules can be used to alter the behavior of
the kernel and potentially introduce malicious code into kernel space. It is important
to have an audit trail of modules that have been introduced into the kernel. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_delete | | Identifiers: | CCE-82580-2 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.2.7 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222 | | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000504-CTR-001280, CNTR-OS-000930, CNTR-OS-000980 | | anssi | R73 |
| |
|
Rule
Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module
[ref] | If the auditd daemon is configured to use the augenrules program
to read audit rules during daemon startup (the default), add the following lines to a file
with suffix .rules in the directory /etc/audit/rules.d to capture kernel module
loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system:
-a always,exit -F arch=ARCH -S finit_module -F key=modules
If the auditd daemon is configured to use the auditctl utility to read audit
rules during daemon startup, add the following lines to /etc/audit/audit.rules file
in order to capture kernel module loading and unloading events, setting ARCH to either b32 or
b64 as appropriate for your system:
-a always,exit -F arch=ARCH -S finit_module -F key=modules
| | Rationale: | The addition/removal of kernel modules can be used to alter the behavior of
the kernel and potentially introduce malicious code into kernel space. It is important
to have an audit trail of modules that have been introduced into the kernel. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_finit | | Identifiers: | CCE-82581-0 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.2.7 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222 | | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000504-CTR-001280, CNTR-OS-000930, CNTR-OS-000980 | | anssi | R73 |
| |
|
Rule
Ensure auditd Collects Information on Kernel Module Loading - init_module
[ref] | To capture kernel module loading events, use following line, setting ARCH to
either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S init_module -F key=modules
Place to add the line depends on a way auditd daemon is configured. If it is configured
to use the augenrules program (the default), add the line to a file with suffix
.rules in the directory /etc/audit/rules.d.
If the auditd daemon is configured to use the auditctl utility,
add the line to file /etc/audit/audit.rules. | | Rationale: | The addition of kernel modules can be used to alter the behavior of
the kernel and potentially introduce malicious code into kernel space. It is important
to have an audit trail of modules that have been introduced into the kernel. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_init | | Identifiers: | CCE-82582-8 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.2.7 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222 | | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000504-CTR-001280, CNTR-OS-000930, CNTR-OS-000980 | | anssi | R73 |
| |
|
| Group
Record Attempts to Alter Logon and Logout Events
Group contains 2 rules |
[ref]
The audit system already collects login information for all users
and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d in order to watch for attempted manual
edits of files involved in storing logon events:
-w /var/log/tallylog -p wa -k logins
-w /var/log/faillock -p wa -k logins
-w /var/log/lastlog -p wa -k logins
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file in order to watch for unattempted manual
edits of files involved in storing logon events:
-w /var/log/tallylog -p wa -k logins
-w /var/log/faillock -p wa -k logins
-w /var/log/lastlog -p wa -k logins
|
Rule
Record Attempts to Alter Logon and Logout Events - faillock
[ref] | The audit system already collects login information for all users
and root.
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /var/log/faillock -p wa -k logins
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /var/log/faillock -p wa -k logins
| | Rationale: | Manual editing of these files may indicate nefarious activity, such
as an attacker attempting to remove evidence of an intrusion. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_login_events_faillock | | Identifiers: | CCE-82583-6 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.2.3 | | os-srg | SRG-OS-000392-GPOS-00172, SRG-OS-000470-GPOS-00214, SRG-OS-000473-GPOS-00218 | | app-srg-ctr | SRG-APP-000503-CTR-001275, SRG-APP-000506-CTR-001290, CNTR-OS-000970, CNTR-OS-001000 | | anssi | R73 | | pcidss4 | 10.2.1.3, 10.2.1, 10.2 |
| |
|
Rule
Record Attempts to Alter Logon and Logout Events - lastlog
[ref] | The audit system already collects login information for all users
and root.
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /var/log/lastlog -p wa -k logins
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /var/log/lastlog -p wa -k logins
| | Rationale: | Manual editing of these files may indicate nefarious activity, such
as an attacker attempting to remove evidence of an intrusion. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_login_events_lastlog | | Identifiers: | CCE-82584-4 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.2.3 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000473-GPOS-00218, SRG-OS-000470-GPOS-00214 | | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000503-CTR-001275, SRG-APP-000506-CTR-001290, CNTR-OS-000930, CNTR-OS-000970, CNTR-OS-001000 | | anssi | R73 | | pcidss4 | 10.2.1.3, 10.2.1, 10.2 |
| |
|
| Group
Record Information on the Use of Privileged Commands
Group contains 2 rules |
[ref]
At a minimum, the audit system should collect the execution of
privileged commands for all users and root. |
Rule
Ensure auditd Collects Information on the Use of Privileged Commands
[ref] | The audit system should collect information about usage of privileged commands for all users.
These are commands with suid or sgid bits on and they are specially risky in local block
device partitions not mounted with noexec and nosuid options. Therefore, these partitions
should be first identified by the following command:
findmnt -n -l -k -it $(awk '/nodev/ { print $2 }' /proc/filesystems | paste -sd,) | grep -Pv "noexec|nosuid"
For all partitions listed by the previous command, it is necessary to search for
setuid / setgid programs using the following command:
$ sudo find PARTITION -xdev -perm /6000 -type f 2>/dev/null
For each setuid / setgid program identified by the previous command, an audit rule must be
present in the appropriate place using the following line structure, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -F path=PROG_PATH -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the augenrules program to read
audit rules during daemon startup, add the line to a file with suffix .rules in the
/etc/audit/rules.d directory, replacing the PROG_PATH part with the full path
of that setuid / setgid identified program.
If the auditd daemon is configured to use the auditctl utility instead, add
the line to the /etc/audit/audit.rules file, also replacing the PROG_PATH part
with the full path of that setuid / setgid identified program. Warning:
This rule checks for multiple syscalls related to privileged commands. If needed to check
specific privileged commands, other more specific rules should be considered. For example:
audit_rules_privileged_commands_suaudit_rules_privileged_commands_umountaudit_rules_privileged_commands_passwd
Warning:
Note that OVAL check and Bash / Ansible remediation of this rule
explicitly excludes file systems mounted at /proc directory
and its subdirectories. It is a virtual file system and it doesn't
contain executable applications. At the same time, interacting with this
file system during check or remediation caused undesirable errors. | | Rationale: | Misuse of privileged functions, either intentionally or unintentionally by authorized users,
or by unauthorized external entities that have compromised system accounts, is a serious and
ongoing concern that can have significant adverse impacts on organizations.
Auditing the use of privileged functions is one way to detect such misuse and identify the
risk from insider and advanced persistent threats.
Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert
their normal role of providing some necessary but limited capability. As such, motivation
exists to monitor these programs for unusual activity. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands | | Identifiers: | CCE-82589-3 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | APO08.04, 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.05, 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 | | cui | 3.1.7 | | isa-62443-2009 | 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.5, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.3.4.5.9, 4.4.2.1, 4.4.2.2, 4.4.2.4 | | isa-62443-2013 | 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 3.9, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | | ism | 0582, 0584, 05885, 0586, 0846, 0957 | | iso27001-2013 | 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.1, A.16.1.2, A.16.1.3, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.3, A.6.2.1, A.6.2.2 | | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | | nist | AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | DE.AE-2, DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, DE.DP-4, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, RS.CO-2 | | pcidss | Req-10.2.2 | | os-srg | SRG-OS-000327-GPOS-00127 | | anssi | R73 |
| |
|
Rule
Ensure auditd Collects Information on the Use of Privileged Commands - sudo
[ref] |
At a minimum, the audit system should collect the execution of privileged
commands for all users and root.
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add
a line of the following form to a file with suffix .rules
in the directory /etc/audit/rules.d:
-a always,exit -F path=/usr/bin/sudo -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add a line of the
following form to /etc/audit/audit.rules:
-a always,exit -F path=/usr/bin/sudo -F auid>=1000 -F auid!=unset -F key=privileged
| | Rationale: | Misuse of privileged functions, either intentionally or unintentionally by
authorized users, or by unauthorized external entities that have compromised system accounts,
is a serious and ongoing concern and can have significant adverse impacts on organizations.
Auditing the use of privileged functions is one way to detect such misuse and identify
the risk from insider and advanced persistent threats.
Privileged programs are subject to escalation-of-privilege attacks,
which attempt to subvert their normal role of providing some necessary but
limited capability. As such, motivation exists to monitor these programs for
unusual activity. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_sudo | | Identifiers: | CCE-82606-5 | | References: | | cis-csc | 1, 12, 13, 14, 15, 16, 2, 3, 5, 6, 7, 8, 9 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, SR 6.2 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.PT-1 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-OS-000755-GPOS-00220 | | app-srg-ctr | SRG-APP-000029-CTR-000085, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, CNTR-OS-000080, CNTR-OS-000930, CNTR-OS-000950 | | anssi | R33 |
| |
|
| Group
Records Events that Modify Date and Time Information
Group contains 4 rules |
[ref]
Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time. All changes to the system
time should be audited. |
Rule
Record attempts to alter time through adjtimex
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S adjtimex -F key=audit_time_rules
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S adjtimex -F key=audit_time_rules
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S adjtimex -F key=audit_time_rules
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S adjtimex -F key=audit_time_rules
The -k option allows for the specification of a key in string form that can be
used for better reporting capability through ausearch and aureport. Multiple
system calls can be defined on the same line to save space if desired, but is
not required. See an example of multiple combined syscalls:
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules
| | Rationale: | Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time (such as sshd). All changes
to the system time should be audited. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_time_adjtimex | | Identifiers: | CCE-82614-9 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.4.2.b | | anssi | R73 | | pcidss4 | 10.6.3, 10.6 |
| |
|
Rule
Record Attempts to Alter Time Through clock_settime
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
The -k option allows for the specification of a key in string form that can
be used for better reporting capability through ausearch and aureport.
Multiple system calls can be defined on the same line to save space if
desired, but is not required. See an example of multiple combined syscalls:
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules
| | Rationale: | Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time (such as sshd). All changes
to the system time should be audited. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_time_clock_settime | | Identifiers: | CCE-82615-6 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.4.2.b | | anssi | R73 | | pcidss4 | 10.6.3, 10.6 |
| |
|
Rule
Record Attempts to Alter Time Through stime
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d for both 32 bit and 64 bit systems:
-a always,exit -F arch=b32 -S stime -F key=audit_time_rules
Since the 64 bit version of the "stime" system call is not defined in the audit
lookup table, the corresponding "-F arch=b64" form of this rule is not expected
to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule
form itself is sufficient for both 32 bit and 64 bit systems). If the
auditd daemon is configured to use the auditctl utility to
read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file for both 32 bit and 64 bit systems:
-a always,exit -F arch=b32 -S stime -F key=audit_time_rules
Since the 64 bit version of the "stime" system call is not defined in the audit
lookup table, the corresponding "-F arch=b64" form of this rule is not expected
to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule
form itself is sufficient for both 32 bit and 64 bit systems). The -k option
allows for the specification of a key in string form that can be used for
better reporting capability through ausearch and aureport. Multiple system
calls can be defined on the same line to save space if desired, but is not
required. See an example of multiple combined system calls:
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules
| | Rationale: | Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time (such as sshd). All changes
to the system time should be audited. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_time_stime | | Identifiers: | CCE-82617-2 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.4.2.b | | anssi | R73 | | pcidss4 | 10.6.3, 10.6 |
| |
|
Rule
Record Attempts to Alter the localtime File
[ref] |
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/localtime -p wa -k audit_time_rules
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/localtime -p wa -k audit_time_rules
| | Rationale: | Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time (such as sshd). All changes
to the system time should be audited. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_time_watch_localtime | | Identifiers: | CCE-82618-0 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.4.2.b | | anssi | R73 | | pcidss4 | 10.6.3, 10.6 |
| |
|
Rule
Make the auditd Configuration Immutable
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d in order to make the auditd configuration
immutable:
-e 2
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file in order to make the auditd configuration
immutable:
-e 2
With this setting, a reboot will be required to change any audit rules. | | Rationale: | Making the audit configuration immutable prevents accidental as
well as malicious modification of the audit rules, although it may be
problematic if legitimate changes are needed during system
operation. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_immutable | | Identifiers: | CCE-82668-5 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 3, 4, 5, 6, 7, 8 | | cjis | 5.4.1.1 | | cobit5 | APO01.06, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, BAI03.05, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, DSS06.02, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | | cui | 3.3.1, 3.4.3 | | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.310(a)(2)(iv), 164.312(d), 164.310(d)(2)(iii), 164.312(b), 164.312(e) | | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.7.3, 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 | | isa-62443-2013 | SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 5.2, SR 6.1 | | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, 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.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | | nist | AC-6(9), CM-6(a) | | nist-csf | DE.AE-3, DE.AE-5, ID.SC-4, PR.AC-4, PR.DS-5, PR.PT-1, RS.AN-1, RS.AN-4 | | pcidss | Req-10.5.2 | | os-srg | SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029 | | app-srg-ctr | SRG-APP-000119-CTR-000245, SRG-APP-000120-CTR-000250, CNTR-OS-000310 | | anssi | R73 | | pcidss4 | 10.3.2, 10.3 |
| |
|
Rule
Record Events that Modify the System's Mandatory Access Controls
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/selinux/ -p wa -k MAC-policy
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-w /etc/selinux/ -p wa -k MAC-policy
| | Rationale: | The system's mandatory access policy (SELinux or Apparmor) should not be
arbitrarily changed by anything other than administrator action. All changes to
MAC policy should be audited. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_mac_modification | | Identifiers: | CCE-82586-9 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.8 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.5.5 | | anssi | R73 | | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Ensure auditd Collects Information on Exporting to Media (successful)
[ref] | At a minimum, the audit system should collect media exportation
events for all users and root. If the auditd daemon is configured to
use the augenrules program to read audit rules during daemon startup
(the default), add the following line to a file with suffix .rules in
the directory /etc/audit/rules.d, setting ARCH to either b32 for
32-bit system, or having two lines for both b32 and b64 in case your
system is 64-bit:
-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 for
32-bit system, or having two lines for both b32 and b64 in case your
system is 64-bit:
-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export
| | Rationale: | The unauthorized exportation of data to external media could result in an information leak
where classified information, Privacy Act information, and intellectual property could be lost. An audit
trail should be created each time a filesystem is mounted to help identify and guard against information
loss. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_media_export | | Identifiers: | CCE-82587-7 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.2.7 | | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215 | | app-srg-ctr | SRG-APP-000495-CTR-001235, CNTR-OS-000930 | | anssi | R73 | | pcidss4 | 10.2.1.7, 10.2.1, 10.2 |
| |
|
Rule
Record Events that Modify the System's Network Environment
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 for
32-bit system, or having two lines for both b32 and b64 in case your system
is 64-bit:
-a always,exit -F arch=ARCH -S sethostname,setdomainname -F key=audit_rules_networkconfig_modification
-w /etc/issue -p wa -k audit_rules_networkconfig_modification
-w /etc/issue.net -p wa -k audit_rules_networkconfig_modification
-w /etc/hosts -p wa -k audit_rules_networkconfig_modification
-w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, setting ARCH to either b32 for
32-bit system, or having two lines for both b32 and b64 in case your system
is 64-bit:
-a always,exit -F arch=ARCH -S sethostname,setdomainname -F key=audit_rules_networkconfig_modification
-w /etc/issue -p wa -k audit_rules_networkconfig_modification
-w /etc/issue.net -p wa -k audit_rules_networkconfig_modification
-w /etc/hosts -p wa -k audit_rules_networkconfig_modification
-w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification
| | Rationale: | The network environment should not be modified by anything other
than administrator action. Any change to network parameters should be
audited. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_networkconfig_modification | | Identifiers: | CCE-82588-5 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | 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 | | pcidss | Req-10.5.5 | | anssi | R73 | | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Attempts to Alter Process and Session Initiation Information btmp
[ref] | The audit system already collects process information for all
users and root.
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /var/log/btmp -p wa -k session
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /var/log/btmp -p wa -k session
| | Rationale: | Manual editing of these files may indicate nefarious activity, such
as an attacker attempting to remove evidence of an intrusion. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_session_events_btmp | | References: | | hipaa | 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) | | nist | AU-12(c), AU-12.1(iv) | | os-srg | SRG-OS-000472-GPOS-00217 | | anssi | R73 | | pcidss4 | 10.2.1.3, 10.2.1, 10.2 |
| |
|
Rule
Record Attempts to Alter Process and Session Initiation Information utmp
[ref] | The audit system already collects process information for all
users and root.
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /var/run/utmp -p wa -k session
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /var/run/utmp -p wa -k session
| | Rationale: | Manual editing of these files may indicate nefarious activity, such
as an attacker attempting to remove evidence of an intrusion. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_session_events_utmp | | References: | | hipaa | 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) | | nist | AU-12(c), AU-12.1(iv) | | os-srg | SRG-OS-000472-GPOS-00217 | | anssi | R73 | | pcidss4 | 10.2.1.3, 10.2.1, 10.2 |
| |
|
Rule
Record Attempts to Alter Process and Session Initiation Information wtmp
[ref] | The audit system already collects process information for all
users and root.
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /var/log/wtmp -p wa -k session
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /var/log/wtmp -p wa -k session
| | Rationale: | Manual editing of these files may indicate nefarious activity, such
as an attacker attempting to remove evidence of an intrusion. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_session_events_wtmp | | References: | | hipaa | 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) | | nist | AU-12(c), AU-12.1(iv) | | os-srg | SRG-OS-000472-GPOS-00217 | | anssi | R73 | | pcidss4 | 10.2.1.3, 10.2.1, 10.2 |
| |
|
Rule
Ensure auditd Collects System Administrator Actions
[ref] |
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/sudoers -p wa -k actions
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/sudoers -p wa -k actions
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/sudoers.d/ -p wa -k actions
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/sudoers.d/ -p wa -k actions
| | Rationale: | The actions taken by system administrators should be audited to keep a record
of what was executed on the system, as well as, for accountability purposes. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_sysadmin_actions | | Identifiers: | CCE-82613-1 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 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 | | isa-62443-2013 | SR 1.1, SR 1.13, 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 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 | | iso27001-2013 | 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.1.2, A.6.2.1, A.6.2.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 | | nist | AC-2(7)(b), AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | | pcidss | Req-10.2.2, Req-10.2.5.b | | os-srg | SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000304-GPOS-00121, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221 | | app-srg-ctr | SRG-APP-000026-CTR-000070, SRG-APP-000027-CTR-000075, SRG-APP-000028-CTR-000080, SRG-APP-000291-CTR-000675, SRG-APP-000292-CTR-000680, SRG-APP-000293-CTR-000685, SRG-APP-000294-CTR-000690, SRG-APP-000319-CTR-000745, SRG-APP-000320-CTR-000750, SRG-APP-000509-CTR-001305, CNTR-OS-000050, CNTR-OS-000060, CNTR-OS-000070 | | anssi | R73 | | pcidss4 | 10.2.1.5, 10.2.1, 10.2 |
| |
|
Rule
Record Events that Modify User/Group Information - /etc/group
[ref] |
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/group -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/group -p wa -k audit_rules_usergroup_modification
| | Rationale: | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_group | | Identifiers: | CCE-82654-5 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 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 | | isa-62443-2013 | SR 1.1, SR 1.13, 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 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 | | iso27001-2013 | 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.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | | nist | AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | | pcidss | Req-10.2.5 | | os-srg | SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221 | | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000503-CTR-001275, CNTR-OS-000930, CNTR-OS-000950, CNTR-OS-000970 | | anssi | R73 | | pcidss4 | 10.2.1.5, 10.2.1, 10.2 |
| |
|
Rule
Record Events that Modify User/Group Information - /etc/gshadow
[ref] |
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
| | Rationale: | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_gshadow | | Identifiers: | CCE-82655-2 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 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 | | isa-62443-2013 | SR 1.1, SR 1.13, 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 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 | | iso27001-2013 | 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.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | | nist | AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | | pcidss | Req-10.2.5 | | os-srg | SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221 | | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000503-CTR-001275, CNTR-OS-000930, CNTR-OS-000950, CNTR-OS-000970 | | anssi | R73 | | pcidss4 | 10.2.1.5, 10.2.1, 10.2 |
| |
|
Rule
Record Events that Modify User/Group Information - /etc/security/opasswd
[ref] |
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
| | Rationale: | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_opasswd | | Identifiers: | CCE-82656-0 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 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 | | isa-62443-2013 | SR 1.1, SR 1.13, 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 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 | | iso27001-2013 | 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.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | | nist | AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | | pcidss | Req-10.2.5 | | os-srg | SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221 | | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000503-CTR-001275, CNTR-OS-000930, CNTR-OS-000940, CNTR-OS-000970 | | anssi | R73 | | pcidss4 | 10.2.1.5, 10.2.1, 10.2 |
| |
|
Rule
Record Events that Modify User/Group Information - /etc/passwd
[ref] |
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
| | Rationale: | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_passwd | | Identifiers: | CCE-82657-8 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 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 | | isa-62443-2013 | SR 1.1, SR 1.13, 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 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 | | iso27001-2013 | 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.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | | nist | AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | | pcidss | Req-10.2.5 | | os-srg | SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000304-GPOS-00121, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221, SRG-OS-000274-GPOS-00104, SRG-OS-000275-GPOS-00105, SRG-OS-000276-GPOS-00106, SRG-OS-000277-GPOS-00107 | | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000503-CTR-001275, CNTR-OS-000930, CNTR-OS-000950, CNTR-OS-000970 | | anssi | R73 | | pcidss4 | 10.2.1.5, 10.2.1, 10.2 |
| |
|
Rule
Record Events that Modify User/Group Information - /etc/shadow
[ref] |
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
| | Rationale: | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. | | Severity: | medium | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_shadow | | Identifiers: | CCE-82658-6 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | | cui | 3.1.7 | | hipaa | 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) | | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 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 | | isa-62443-2013 | SR 1.1, SR 1.13, 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 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 | | iso27001-2013 | 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.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | | nist | AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a) | | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | | pcidss | Req-10.2.5 | | os-srg | SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221 | | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000503-CTR-001275, CNTR-OS-000930, CNTR-OS-000950, CNTR-OS-000970 | | anssi | R73 | | pcidss4 | 10.2.1.5, 10.2.1, 10.2 |
| |
|
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: | CCE-82669-3 | | References: | | hipaa | 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) | | nerc-cip | CIP-004-6 R3.3, CIP-007-3 R6.5 | | nist | AC-7(a), AU-7(1), AU-7(2), AU-14, AU-12(2), AU-2(a), CM-6(a) | | ospp | FAU_GEN.1 | | pcidss | Req-10.1 | | os-srg | 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 | | anssi | R33, R73 | | pcidss4 | 10.2.1, 10.2 |
| |
|
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: | CCE-82463-1 | | References: | | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | | cjis | 5.4.1.1 | | cobit5 | 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 | | cui | 3.3.1, 3.3.2, 3.3.6 | | hipaa | 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) | | isa-62443-2009 | 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 | | isa-62443-2013 | 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 | | iso27001-2013 | 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 | | nerc-cip | CIP-004-6 R3.3, CIP-007-3 R6.5 | | nist | 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) | | nist-csf | 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 | | ospp | FAU_GEN.1 | | pcidss | Req-10.1 | | os-srg | 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 | | app-srg-ctr | SRG-APP-000095-CTR-000170, SRG-APP-000409-CTR-000990, SRG-APP-000508-CTR-001300, SRG-APP-000510-CTR-001310, CNTR-OS-000150, CNTR-OS-000180 | | anssi | R33, R73 | | pcidss4 | 10.2.1, 10.2 |
| |
|