Group
Guide to the Secure Configuration of Oracle Linux 9
Group contains 61 groups and 232 rules |
Group
System Settings
Group contains 42 groups and 199 rules |
[ref]
Contains rules that check correct system settings. |
Group
Installing and Maintaining Software
Group contains 6 groups and 30 rules |
[ref]
The following sections contain information on
security-relevant choices during the initial operating system
installation process and the setup of software
updates. |
Group
System and Software Integrity
Group contains 2 groups and 2 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 yum 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 | disa | CCI-002696, CCI-001744 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | ism | 1034, 1288, 1341, 1417 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | nist | CM-6(a) | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | pcidss | Req-11.5 | os-srg | SRG-OS-000445-GPOS-00199 | 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 | disa | CCI-002696, CCI-001744 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | 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
Disk Partitioning
Group contains 6 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 | References: | cis-csc | 12, 15, 8 | cobit5 | APO13.01, DSS05.02 | disa | CCI-000366 | 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 | disa | CCI-000366 | 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.
Ensure that /var/log has its own partition or logical
volume at installation time, or migrate it using LVM. | 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 | 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 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, 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/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 | 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 13 rules |
[ref]
Sudo , which stands for "su 'do'", provides the ability to delegate authority
to certain users, groups of users, or system administrators. When configured for system
users and/or groups, Sudo can allow a user or group to execute privileged commands
that normally only root is allowed to execute.
For more information on Sudo and addition Sudo configuration options, see
https://www.sudo.ws. |
Rule
Install sudo Package
[ref] | The sudo package can be installed with the following command:
$ sudo yum 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 | 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 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 9 rules |
[ref]
The yum 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.
Oracle Linux 9 systems contain an installed software catalog called
the RPM database, which records metadata of installed packages. Consistently using
yum or the graphical Software Update for all software installation
allows for insight into the current inventory of installed software on the system.
|
Rule
Install dnf-automatic Package
[ref] | The dnf-automatic package can be installed with the following command:
$ sudo yum install dnf-automatic
| Rationale: | dnf-automatic is an alternative command line interface (CLI)
to dnf upgrade suitable for automatic, regular execution.
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_dnf-automatic_installed | References: | | |
|
Rule
Configure dnf-automatic to Install Available Updates Automatically
[ref] | To ensure that the packages comprising the available updates will be automatically installed by dnf-automatic , set apply_updates to yes under [commands] section in /etc/dnf/automatic.conf . | Rationale: | Installing software updates is a fundamental mitigation against
the exploitation of publicly-known vulnerabilities. If the most
recent security patches and updates are not installed, unauthorized
users may take advantage of weaknesses in the unpatched software. The
lack of prompt attention to patching could result in a system compromise.
The automated installation of updates ensures that recent security patches
are applied in a timely manner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dnf-automatic_apply_updates | References: | ism | 0940, 1144, 1467, 1472, 1483, 1493, 1494, 1495 | nist | SI-2(5), CM-6(a), SI-2(c) | ospp | FMT_SMF_EXT.1 | os-srg | SRG-OS-000805-GPOS-00260 | anssi | R61 |
| |
|
Rule
Configure dnf-automatic to Install Only Security Updates
[ref] | To configure dnf-automatic to install only security updates
automatically, set upgrade_type to security under
[commands] section in /etc/dnf/automatic.conf . | Rationale: | By default, dnf-automatic installs all available updates.
Reducing the amount of updated packages only to updates that were
issued as a part of a security advisory increases the system stability. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_dnf-automatic_security_updates_only | References: | | |
|
Rule
Ensure gpgcheck Enabled In Main yum Configuration
[ref] | The gpgcheck option controls whether
RPM packages' signatures are always checked prior to installation.
To configure yum to check package signatures before installing
them, ensure the following line appears in /etc/yum.conf in
the [main] section:
gpgcheck=1
| Rationale: | Changes to any software components can have significant effects on the
overall security of the operating system. This requirement ensures the
software has not been tampered with and that it has been provided by a
trusted vendor.
Accordingly, patches, service packs, device drivers, or operating system
components must be signed with a certificate recognized and approved by the
organization.
Verifying the authenticity of the software prior to installation
validates the integrity of the patch or upgrade received from a vendor.
This ensures the software has not been tampered with and that it has been
provided by a trusted vendor. Self-signed certificates are disallowed by
this requirement. Certificates used to verify the software must be from an
approved Certificate Authority (CA). | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_globally_activated | References: | cis-csc | 11, 2, 3, 9 | cjis | 5.10.4.1 | cobit5 | APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02 | cui | 3.4.8 | disa | CCI-003992 | hipaa | 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i) | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4 | nist | CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), SA-12, SA-12(10), CM-11(a), CM-11(b) | nist-csf | PR.DS-6, PR.DS-8, PR.IP-1 | ospp | FPT_TUD_EXT.1, FPT_TUD_EXT.2 | pcidss | Req-6.2 | os-srg | SRG-OS-000366-GPOS-00153 | anssi | R59 | pcidss4 | 6.3.3, 6.3 |
| |
|
Rule
Ensure gpgcheck Enabled for Local Packages
[ref] | yum should be configured to verify the signature(s) of local packages
prior to installation. To configure yum to verify signatures of local
packages, set the localpkg_gpgcheck to 1 in /etc/yum.conf .
| Rationale: | Changes to any software components can have significant effects to the overall security
of the operating system. This requirement ensures the software has not been tampered and
has been provided by a trusted vendor.
Accordingly, patches, service packs, device drivers, or operating system components must
be signed with a certificate recognized and approved by the organization. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_local_packages | References: | cis-csc | 11, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05 | cui | 3.4.8 | disa | CCI-003992 | 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 | isa-62443-2013 | 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 | nist | CM-11(a), CM-11(b), CM-6(a), CM-5(3), SA-12, SA-12(10) | nist-csf | PR.IP-1 | ospp | FPT_TUD_EXT.1, FPT_TUD_EXT.2 | os-srg | SRG-OS-000366-GPOS-00153 | anssi | R59 |
| |
|
Rule
Ensure gpgcheck Enabled for All yum Package Repositories
[ref] | To ensure signature checking is not disabled for
any repos, remove any lines from files in /etc/yum.repos.d of the form:
gpgcheck=0
| Rationale: | Verifying the authenticity of the software prior to installation validates
the integrity of the patch or upgrade received from a vendor. This ensures
the software has not been tampered with and that it has been provided by a
trusted vendor. Self-signed certificates are disallowed by this
requirement. Certificates used to verify the software must be from an
approved Certificate Authority (CA)." | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_never_disabled | References: | cis-csc | 11, 2, 3, 9 | cjis | 5.10.4.1 | cobit5 | APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02 | cui | 3.4.8 | disa | CCI-003992 | hipaa | 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i) | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4 | nist | CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), SA-12, SA-12(10), CM-11(a), CM-11(b) | nist-csf | PR.DS-6, PR.DS-8, PR.IP-1 | ospp | FPT_TUD_EXT.1, FPT_TUD_EXT.2 | pcidss | Req-6.2 | os-srg | SRG-OS-000366-GPOS-00153 | anssi | R59 | pcidss4 | 6.3.3, 6.3 |
| |
|
Rule
Ensure Oracle Linux GPG Key Installed
[ref] | To ensure the system can cryptographically verify base software
packages come from Oracle (and to connect to the Unbreakable Linux Network to
receive them), the Oracle GPG key must properly be installed.
To install the Oracle GPG key, run:
$ sudo uln_register
If the system is not connected to the Internet,
then install the Oracle GPG key from trusted media such as
the Oracle 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-oracle
Alternatively, the key may be pre-loaded during the Oracle installation. In
such cases, the key can be installed by running the following command:
sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
| 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 Oracle GPG key is necessary to
cryptographically verify packages are from Oracle. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_oracle_gpgkey_installed | References: | cis-csc | 11, 2, 3, 9 | cobit5 | APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02 | disa | CCI-001749 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4 | nist | CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), CM-11(a), CM-11(b) | nist-csf | PR.DS-6, PR.DS-8, PR.IP-1 | pcidss | Req-6.2 | anssi | R59 |
| |
|
Rule
Ensure Software Patches Installed
[ref] |
If the system is joined to the ULN
or a yum server, run the following command to install updates:
$ sudo yum update
If the system is not configured to use one of these sources, updates (in the form of RPM packages)
can be manually downloaded from the ULN and installed using rpm .
NOTE: U.S. Defense systems are required to be patched within 30 days or sooner as local policy
dictates. Warning:
The OVAL feed of Oracle Linux 9 is not a XML file, which may not be understood by all scanners. | Rationale: | Installing software updates is a fundamental mitigation against
the exploitation of publicly-known vulnerabilities. If the most
recent security patches and updates are not installed, unauthorized
users may take advantage of weaknesses in the unpatched software. The
lack of prompt attention to patching could result in a system compromise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_security_patches_up_to_date | References: | cis-csc | 18, 20, 4 | cjis | 5.10.4.1 | cobit5 | APO12.01, APO12.02, APO12.03, APO12.04, BAI03.10, DSS05.01, DSS05.02 | disa | CCI-000366 | isa-62443-2009 | 4.2.3, 4.2.3.12, 4.2.3.7, 4.2.3.9 | iso27001-2013 | A.12.6.1, A.14.2.3, A.16.1.3, A.18.2.2, A.18.2.3 | nist | SI-2(5), SI-2(c), CM-6(a) | nist-csf | ID.RA-1, PR.IP-12 | ospp | FMT_MOF_EXT.1 | pcidss | Req-6.2 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R61 | pcidss4 | 6.3.3, 6.3 |
| |
|
Rule
Enable dnf-automatic Timer
[ref] |
The dnf-automatic timer can be enabled with the following command:
$ sudo systemctl enable dnf-automatic.timer
| Rationale: | The dnf-automatic is an alternative command line interface (CLI) to dnf upgrade with specific facilities to make it suitable to be executed automatically and regularly from systemd timers, cron jobs and similar.
The tool is controlled by dnf-automatic.timer SystemD timer. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_timer_dnf-automatic_enabled | References: | | |
|
Group
Account and Access Control
Group contains 11 groups and 29 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
Oracle Linux 9. |
Group
Protect Accounts by Configuring PAM
Group contains 4 groups and 13 rules |
[ref]
PAM, or Pluggable Authentication Modules, is a system
which implements modular authentication for Linux programs. PAM provides
a flexible and configurable architecture for authentication, and it should be configured
to minimize exposure to unnecessary risk. This section contains
guidance on how to accomplish that.
PAM is implemented as a set of shared objects which are
loaded and invoked whenever an application wishes to authenticate a
user. Typically, the application must be running as root in order
to take advantage of PAM, because PAM's modules often need to be able
to access sensitive stores of account information, such as /etc/shadow.
Traditional privileged network listeners
(e.g. sshd) or SUID programs (e.g. sudo) already meet this
requirement. An SUID root application, userhelper, is provided so
that programs which are not SUID or privileged themselves can still
take advantage of PAM.
PAM looks in the directory /etc/pam.d for
application-specific configuration information. For instance, if
the program login attempts to authenticate a user, then PAM's
libraries follow the instructions in the file /etc/pam.d/login
to determine what actions should be taken.
One very important file in /etc/pam.d is
/etc/pam.d/system-auth . This file, which is included by
many other PAM configuration files, defines 'default' system authentication
measures. Modifying this file is a good way to make far-reaching
authentication changes, for instance when implementing a
centralized authentication service. Warning:
Be careful when making changes to PAM's configuration files.
The syntax for these files is complex, and modifications can
have unexpected consequences. The default configurations shipped
with applications should be sufficient for most users. |
Group
Set Lockouts for Failed Password Attempts
Group contains 5 rules |
[ref]
The pam_faillock PAM module provides the capability to
lock out user accounts after a number of failed login attempts. Its
documentation is available in
/usr/share/doc/pam-VERSION/txts/README.pam_faillock .
Warning:
Locking out user accounts presents the
risk of a denial-of-service attack. The lockout policy
must weigh whether the risk of such a
denial-of-service attack outweighs the benefits of thwarting
password guessing attacks. |
Rule
Limit Password Reuse
[ref] | Do not allow users to reuse recent passwords. This can be accomplished by using the
remember option for the pam_unix or pam_pwhistory PAM modules. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report. Warning:
Newer versions of authselect contain an authselect feature to easily and properly
enable pam_pwhistory.so module. If this feature is not yet available in your
system, an authselect custom profile must be used to avoid integrity issues in PAM files. | Rationale: | Preventing re-use of previous passwords helps ensure that a compromised password is not
re-used by a user. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_unix_remember | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.1.1 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.8 | disa | CCI-000200 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(f), IA-5(1)(e) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.5 | os-srg | SRG-OS-000077-GPOS-00045 | anssi | R31 | pcidss4 | 8.3.7, 8.3 |
| |
|
Rule
Lock Accounts After Failed Password Attempts
[ref] | This rule configures the system to lock out accounts after a number of incorrect login attempts
using pam_faillock.so .
pam_faillock.so module requires multiple entries in pam files. These entries must be carefully
defined to work as expected.
Ensure that the file /etc/security/faillock.conf contains the following entry:
deny = <count>
Where count should be less than or equal to
3 and greater than 0.
In order to avoid errors when manually editing these files, it is
recommended to use the appropriate tools, such as authselect or authconfig ,
depending on the OS version. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
If the system supports the /etc/security/faillock.conf file, the pam_faillock
parameters should be defined in faillock.conf file. | Rationale: | By limiting the number of failed logon attempts, the risk of unauthorized system access via
user password guessing, also known as brute-forcing, is reduced. Limits are imposed by locking
the account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny | References: | cis-csc | 1, 12, 15, 16 | cjis | 5.5.3 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.8 | disa | CCI-000044, CCI-002238 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a), AC-7(a) | nist-csf | PR.AC-7 | ospp | FIA_AFL.1 | pcidss | Req-8.1.6 | os-srg | SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | anssi | R31 | ccn | A.30.SEC-OL1 | pcidss4 | 8.3.4, 8.3 |
| |
|
Rule
Configure the root Account for Failed Password Attempts
[ref] | This rule configures the system to lock out the root account after a number of
incorrect login attempts using pam_faillock.so .
pam_faillock.so module requires multiple entries in pam files. These entries must be carefully
defined to work as expected. In order to avoid errors when manually editing these files, it is
recommended to use the appropriate tools, such as authselect or authconfig ,
depending on the OS version. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
If the system supports the /etc/security/faillock.conf file, the pam_faillock
parameters should be defined in faillock.conf file. | Rationale: | By limiting the number of failed logon attempts, the risk of unauthorized system access via
user password guessing, also known as brute-forcing, is reduced. Limits are imposed by locking
the account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny_root | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | disa | CCI-000044, CCI-002238 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a), AC-7(b), IA-5(c) | nist-csf | PR.AC-7 | os-srg | SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | anssi | R31 |
| |
|
Rule
Set Interval For Counting Failed Password Attempts
[ref] | Utilizing pam_faillock.so , the fail_interval directive configures the system
to lock out an account after a number of incorrect login attempts within a specified time
period.
Ensure that the file /etc/security/faillock.conf contains the following entry:
fail_interval = <interval-in-seconds> where interval-in-seconds is 900 or greater.
In order to avoid errors when manually editing these files, it is
recommended to use the appropriate tools, such as authselect or authconfig ,
depending on the OS version. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
If the system supports the /etc/security/faillock.conf file, the pam_faillock
parameters should be defined in faillock.conf file. | Rationale: | By limiting the number of failed logon attempts the risk of unauthorized system
access via user password guessing, otherwise known as brute-forcing, is reduced.
Limits are imposed by locking the account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_interval | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | disa | CCI-000044, CCI-002238 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a), AC-7(a) | nist-csf | PR.AC-7 | ospp | FIA_AFL.1 | os-srg | SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | anssi | R31 |
| |
|
Rule
Set Lockout Time for Failed Password Attempts
[ref] | This rule configures the system to lock out accounts during a specified time period after a
number of incorrect login attempts using pam_faillock.so .
Ensure that the file /etc/security/faillock.conf contains the following entry:
unlock_time=<interval-in-seconds> where
interval-in-seconds is 900 or greater.
pam_faillock.so module requires multiple entries in pam files. These entries must be carefully
defined to work as expected. In order to avoid any errors when manually editing these files,
it is recommended to use the appropriate tools, such as authselect or authconfig ,
depending on the OS version.
If unlock_time is set to 0 , manual intervention by an administrator is required
to unlock a user. This should be done using the faillock tool. Warning:
If the system supports the new /etc/security/faillock.conf file but the
pam_faillock.so parameters are defined directly in /etc/pam.d/system-auth and
/etc/pam.d/password-auth , the remediation will migrate the unlock_time parameter
to /etc/security/faillock.conf to ensure compatibility with authselect tool.
The parameters deny and fail_interval , if used, also have to be migrated
by their respective remediation. Warning:
If the system relies on authselect tool to manage PAM settings, the remediation
will also use authselect tool. However, if any manual modification was made in
PAM files, the authselect integrity check will fail and the remediation will be
aborted in order to preserve intentional changes. In this case, an informative message will
be shown in the remediation report.
If the system supports the /etc/security/faillock.conf file, the pam_faillock
parameters should be defined in faillock.conf file. | Rationale: | By limiting the number of failed logon attempts the risk of unauthorized system
access via user password guessing, otherwise known as brute-forcing, is reduced.
Limits are imposed by locking the account. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_unlock_time | References: | cis-csc | 1, 12, 15, 16 | cjis | 5.5.3 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.8 | disa | CCI-000044, CCI-002238 | isa-62443-2009 | 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | iso27001-2013 | A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3 | nist | CM-6(a), AC-7(b) | nist-csf | PR.AC-7 | ospp | FIA_AFL.1 | pcidss | Req-8.1.7 | os-srg | SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005 | anssi | R31 | ccn | A.30.SEC-OL1 | pcidss4 | 8.3.4, 8.3 |
| |
|
Group
Set Password Quality Requirements
Group contains 1 group and 7 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 7 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 Digit Characters
[ref] | The pam_pwquality module's dcredit parameter controls requirements for
usage of digits in a password. When set to a negative number, any password will be required to
contain that many digits. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each digit. Modify the dcredit setting in
/etc/security/pwquality.conf to require the use of a digit in 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 digits makes password guessing attacks more difficult by ensuring a larger
search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_dcredit | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 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 | ospp | FMT_SMF_EXT.1 | pcidss | Req-8.2.3 | os-srg | SRG-OS-000071-GPOS-00039 | anssi | R31 | pcidss4 | 8.3.6, 8.3 |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Lowercase Characters
[ref] | The pam_pwquality module's lcredit parameter controls requirements for
usage of lowercase letters in a password. When set to a negative number, any password will be required to
contain that many lowercase characters. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each lowercase character. Modify the lcredit setting in
/etc/security/pwquality.conf to require the use of a lowercase character in 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
possble combinations that need to be tested before the password is compromised.
Requiring a minimum number of lowercase characters makes password guessing attacks
more difficult by ensuring a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_lcredit | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 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 | ospp | FMT_SMF_EXT.1 | pcidss | Req-8.2.3 | os-srg | SRG-OS-000070-GPOS-00038 | anssi | R31 | pcidss4 | 8.3.6, 8.3 |
| |
|
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 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 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 | ccn | A.11.SEC-OL3 |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Length
[ref] | The pam_pwquality module's minlen parameter controls requirements for
minimum characters required in a password. Add minlen=15
after pam_pwquality to set minimum password length requirements. | Rationale: | The shorter the password, the lower the number of possible combinations
that need to be tested before the password is compromised.
Password complexity, or strength, is a measure of the effectiveness of a
password in resisting attempts at guessing and brute-force attacks.
Password length is one factor of several that helps to determine strength
and how long it takes to crack a password. Use of more characters in a password
helps to exponentially increase the time and/or resources required to
compromise the password. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_minlen | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.1.1 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 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 | ospp | FMT_SMF_EXT.1 | pcidss | Req-8.2.3 | os-srg | SRG-OS-000078-GPOS-00046 | anssi | R31, R68 | ccn | A.11.SEC-OL3 | pcidss4 | 8.3.6, 8.3 |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Special Characters
[ref] | The pam_pwquality module's ocredit= parameter controls requirements for
usage of special (or "other") characters in a password. When set to a negative number,
any password will be required to contain that many special characters.
When set to a positive number, pam_pwquality will grant +1
additional length credit for each special character. Modify the ocredit setting
in /etc/security/pwquality.conf to equal -1
to require use of a special character in 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 special characters makes password guessing attacks
more difficult by ensuring a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_ocredit | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 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 | ospp | FMT_SMF_EXT.1 | os-srg | SRG-OS-000266-GPOS-00101 | anssi | R31 |
| |
|
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 /etc/security/pwquality.conf to include
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 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, 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 | ccn | A.11.SEC-OL3 |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Uppercase Characters
[ref] | The pam_pwquality module's ucredit= parameter controls requirements for
usage of uppercase letters in a password. When set to a negative number, any password will be required to
contain that many uppercase characters. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each uppercase character. Modify the ucredit setting in
/etc/security/pwquality.conf to require the use of an uppercase character in 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. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_ucredit | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 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 | ospp | FMT_SMF_EXT.1 | pcidss | Req-8.2.3 | os-srg | SRG-OS-000069-GPOS-00037, SRG-OS-000070-GPOS-00038 | anssi | R31 |
| |
|
Group
Set Password Hashing Algorithm
Group contains 1 rule |
[ref]
The system's default algorithm for storing password hashes in
/etc/shadow is SHA-512. This can be configured in several
locations. |
Rule
Set PAM''s Password Hashing Algorithm
[ref] | The PAM system service can be configured to only store encrypted representations of passwords.
In "/etc/pam.d/system-auth", the password section of the file controls which
PAM modules to execute during a password change.
Set the pam_unix.so module in the password section to include the option
sha512 and no other hashing
algorithms as shown below:
password sufficient pam_unix.so sha512
other arguments...
This will help ensure that new passwords for local users will be stored using the
sha512 algorithm. Warning:
The hashing algorithms to be used with pam_unix.so are defined with independent module
options. There are at least 7 possible algorithms and likely more algorithms will be
introduced along the time. Due the the number of options and its possible combinations,
the use of multiple hashing algorithm options may bring unexpected behaviors to the
system. For this reason the check will pass only when one hashing algorithm option is
defined and is aligned to the "var_password_hashing_algorithm_pam" variable. The
remediation will ensure the correct option and remove any other extra hashing algorithm
option. | Rationale: | Passwords need to be protected at all times, and encryption is the standard method for
protecting passwords. If passwords are not encrypted, they can be plainly read
(i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm
are no more protected than if they are kept in plain text.
This setting ensures user and group account administration utilities are configured to store
only encrypted representations of passwords. Additionally, the crypt_style
configuration option in /etc/libuser.conf ensures the use of a strong hashing
algorithm that makes password cracking attacks more difficult. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_systemauth | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.6.2.2 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.13.11 | disa | CCI-000196, CCI-000803, CCI-004062 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 0418, 1055, 1402 | iso27001-2013 | A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3 | nist | IA-5(c), IA-5(1)(c), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.1 | os-srg | SRG-OS-000073-GPOS-00041, SRG-OS-000120-GPOS-00061 | anssi | R68 | ccn | A.19.SEC-OL3 | pcidss4 | 8.3.2, 8.3 |
| |
|
Group
Protect Physical Console Access
Group contains 1 rule |
[ref]
It is impossible to fully protect a system from an
attacker with physical access, so securing the space in which the
system is located should be considered a necessary step. However,
there are some steps which, if taken, make it more difficult for an
attacker to quickly or undetectably modify a system from its
console. |
Rule
Configure Logind to terminate idle sessions after certain time of inactivity
[ref] | To configure logind service to terminate inactive user sessions
after 600 seconds, edit the file
/etc/systemd/logind.conf . Ensure that there is a section
[Login] which contains the configuration
StopIdleSessionSec=600
. | Rationale: | Terminating an idle session within a short time period reduces the window of
opportunity for unauthorized personnel to take control of a management
session enabled on the console or console port that has been let unattended. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_logind_session_timeout | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 3, 5, 7, 8 | cjis | 5.5.6 | cobit5 | APO13.01, BAI03.01, BAI03.02, BAI03.03, DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.1.11 | disa | CCI-001133 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 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 6.2 | iso27001-2013 | A.12.4.1, A.12.4.3, A.14.1.1, A.14.2.1, A.14.2.5, A.18.1.4, A.6.1.2, A.6.1.5, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | 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 | CM-6(a), AC-17(a), AC-2(5), AC-12, AC-17(a), SC-10, CM-6(a) | nist-csf | DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.IP-2 | ospp | FMT_SMF_EXT.1.1 | pcidss | Req-8.1.8 | os-srg | SRG-OS-000163-GPOS-00072 | anssi | R32 |
| |
|
Group
Protect Accounts by Restricting Password-Based Login
Group contains 3 groups and 5 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 | disa | CCI-004066 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 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
Verify Proper Storage and Existence of Password
Hashes
Group contains 2 rules |
[ref]
By default, password hashes for local accounts are stored
in the second field (colon-separated) in
/etc/shadow . This file should be readable only by
processes running with root credentials, preventing users from
casually accessing others' password hashes and attempting
to crack them.
However, it remains possible to misconfigure the system
and store password hashes
in world-readable files such as /etc/passwd , or
to even store passwords themselves in plaintext on the system.
Using system-provided tools for password change/creation
should allow administrators to avoid such misconfiguration. |
Rule
Set number of Password Hashing Rounds - password-auth
[ref] | Configure the number or rounds for the password hashing algorithm. This can be
accomplished by using the rounds option for the pam_unix PAM module.
In file /etc/pam.d/password-auth append rounds=11
to the pam_unix.so entry, as shown below:
password sufficient pam_unix.so ...existing_options... rounds=11
The system's default number of rounds is 5000. Warning:
Setting a high number of hashing rounds makes it more difficult to brute force the password,
but requires more CPU resources to authenticate users. | Rationale: | Using a higher number of rounds makes password cracking attacks more difficult. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_unix_rounds_password_auth | References: | | |
|
Rule
Set number of Password Hashing Rounds - system-auth
[ref] | Configure the number or rounds for the password hashing algorithm. This can be
accomplished by using the rounds option for the pam_unix PAM module.
In file /etc/pam.d/system-auth append rounds=11
to the pam_unix.so entry, as shown below:
password sufficient pam_unix.so ...existing_options... rounds=11
The system's default number of rounds is 5000. Warning:
Setting a high number of hashing rounds makes it more difficult to brute force the password,
but requires more CPU resources to authenticate users. | Rationale: | Using a higher number of rounds makes password cracking attacks more difficult. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_unix_rounds_system_auth | 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, Oracle Linux 9'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 | 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 9 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. |
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 | disa | CCI-000057, CCI-001133 | 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 | ccn | A.5.SEC-OL8 | 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: | | |
|
Rule
Enable authselect
[ref] | Configure user authentication setup to use the authselect tool.
If authselect profile is selected, the rule will enable the minimal profile. Warning:
If the sudo authselect select command returns an error informing that the chosen
profile cannot be selected, it is probably because PAM files have already been modified by
the administrator. If this is the case, in order to not overwrite the desired changes made
by the administrator, the current PAM settings should be investigated before forcing the
selection of the chosen authselect profile. | Rationale: | Authselect is a successor to authconfig.
It is a tool to select system authentication and identity sources from a list of supported
profiles instead of letting the administrator manually build the PAM stack.
That way, it avoids potential breakage of configuration, as it ships several tested profiles
that are well tested and supported to solve different use-cases. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_enable_authselect | References: | disa | CCI-000213 | 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) | nist | AC-3 | ospp | FIA_UAU.1, FIA_AFL.1 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R31 | ccn | enable_authselect | pcidss4 | 8.3.4, 8.3 |
| |
|
Group
GRUB2 bootloader configuration
Group contains 2 groups and 11 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 Oracle Linux 9 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 1 rule |
[ref]
Non-UEFI GRUB2 bootloader configuration |
Rule
Set Boot Loader Password in grub2
[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_password | References: | cis-csc | 1, 11, 12, 14, 15, 16, 18, 3, 5 | cobit5 | DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.06, DSS06.10 | cui | 3.4.5 | disa | CCI-000213 | 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.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nist | CM-6(a) | nist-csf | PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.PT-3 | os-srg | SRG-OS-000080-GPOS-00048 | anssi | R5 | ccn | A.8.SEC-OL7 |
| |
|
Group
UEFI GRUB2 bootloader configuration
Group contains 1 rule |
[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
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 | 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 | disa | CCI-000213 | 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
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.
To ensure that l1tf=full,force
is added as a kernel command line
argument to newly installed kernels, add l1tf=full,force
to the
default Grub2 command line for Linux operating systems. Modify the line within
/etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... l1tf=full,force ..."
Run the following command to update command line for already installed kernels: # grubby --update-kernel=ALL --args="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.
To ensure that mce=0 is added as a kernel command line
argument to newly installed kernels, add mce=0 to the
default Grub2 command line for Linux operating systems. Modify the line within
/etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... mce=0 ..."
Run the following command to update command line for already installed kernels: # grubby --update-kernel=ALL --args="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
Configure Microarchitectural Data Sampling mitigation
[ref] | Microarchitectural Data Sampling (MDS) is a hardware vulnerability which allows unprivileged
speculative access to data which is available in various CPU internal buffers.
When performing store, load, L1 refill operations, processors write data into temporary
microarchitectural structures (buffers), and the data in the buffer can be forwarded to load
operations as an optimization.
Under certain conditions, data unrelated to the load operations can be speculatively
forwarded from the buffers to a disclosure gadget which allows in turn to infer the value
via a cache side channel attack.
Select the appropriate mitigation by adding the argument
mds=full,nosmt
to the default
GRUB 2 command line for the Linux operating system.
To ensure that mds=full,nosmt
is added as a kernel command line
argument to newly installed kernels, add mds=full,nosmt
to the
default Grub2 command line for Linux operating systems. Modify the line within
/etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... mds=full,nosmt ..."
Run the following command to update command line for already installed kernels: # grubby --update-kernel=ALL --args="mds=full,nosmt"
Not all processors are affected by all variants of MDS, but the mitigation mechanism is
identical for all of them.
Since Linux Kernel 5.2 you can check whether the system is vulnerable or mitigated with the
following command:
cat /sys/devices/system/cpu/vulnerabilities/mds
Warning:
Enabling MDS mitigations will impact performance of the system, mainly by workloads with
high rates of user-kernel-user space transitions. For example, system calls, NMIs and interrupts. | Rationale: | The MDS vulnerability allows an attacker to sample data from internal CPU buffers. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_mds_argument | References: | | |
|
Rule
Enable randomization of the page allocator
[ref] | To enable randomization of the page allocator in the kernel, add the
page_alloc.shuffle=1 argument to the default GRUB 2 command line.
To ensure that page_alloc.shuffle=1 is added as a kernel command line
argument to newly installed kernels, add page_alloc.shuffle=1 to the
default Grub2 command line for Linux operating systems. Modify the line within
/etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... page_alloc.shuffle=1 ..."
Run the following command to update command line for already installed kernels: # grubby --update-kernel=ALL --args="page_alloc.shuffle=1"
| Rationale: | The CONFIG_SHUFFLE_PAGE_ALLOCATOR config option is primarily
focused on improving the average utilization of a direct-mapped
memory-side-cache. Aside of this performance effect, it also reduces
predictability of page allocations in situations when the bad actor can
crash the system and somehow leverage knowledge of (page) allocation order
right after a fresh reboot, or can control the timing between a
hot-pluggable memory node (as in NUMA node) and applications allocating
memory ouf of that node. The page_alloc.shuffle=1 kernel command
line parameter then forces this functionality irrespectively of memory cache
architecture. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_page_alloc_shuffle_argument | References: | | |
|
Rule
Enable Kernel Page-Table Isolation (KPTI)
[ref] | To enable Kernel page-table isolation,
add the argument pti=on to the default
GRUB 2 command line for the Linux operating system.
To ensure that pti=on is added as a kernel command line
argument to newly installed kernels, add pti=on to the
default Grub2 command line for Linux operating systems. Modify the line within
/etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... pti=on ..."
Run the following command to update command line for already installed kernels: # grubby --update-kernel=ALL --args="pti=on"
| Rationale: | Kernel page-table isolation is a kernel feature that mitigates
the Meltdown security vulnerability and hardens the kernel
against attempts to bypass kernel address space layout
randomization (KASLR). | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_pti_argument | References: | disa | CCI-002824, CCI-000381 | nist | SI-16 | os-srg | SRG-OS-000433-GPOS-00193, SRG-OS-000095-GPOS-00049 | anssi | R8 |
| |
|
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.
To ensure that rng_core.default_quality=500
is added as a kernel command line
argument to newly installed kernels, add rng_core.default_quality=500
to the
default Grub2 command line for Linux operating systems. Modify the line within
/etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... rng_core.default_quality=500 ..."
Run the following command to update command line for already installed kernels: # grubby --update-kernel=ALL --args="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.
To ensure that slab_nomerge=yes is added as a kernel command line
argument to newly installed kernels, add slab_nomerge=yes to the
default Grub2 command line for Linux operating systems. Modify the line within
/etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... slab_nomerge=yes ..."
Run the following command to update command line for already installed kernels: # grubby --update-kernel=ALL --args="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.
To ensure that spec_store_bypass_disable=seccomp
is added as a kernel command line
argument to newly installed kernels, add spec_store_bypass_disable=seccomp
to the
default Grub2 command line for Linux operating systems. Modify the line within
/etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... spec_store_bypass_disable=seccomp ..."
Run the following command to update command line for already installed kernels: # grubby --update-kernel=ALL --args="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.
To ensure that spectre_v2=on is added as a kernel command line
argument to newly installed kernels, add spectre_v2=on to the
default Grub2 command line for Linux operating systems. Modify the line within
/etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... spectre_v2=on ..."
Run the following command to update command line for already installed kernels: # grubby --update-kernel=ALL --args="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
Network Configuration and Firewalls
Group contains 8 groups and 53 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 16 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 16 rules |
[ref]
A major feature of IPv6 is the extent to which systems
implementing it can automatically configure their networking
devices using information from the network. From a security
perspective, manually configuring important configuration
information is preferable to accepting it from the network
in an unauthenticated fashion. |
Rule
Configure Accepting Default Router in Router Advertisements on All IPv6 Interfaces
[ref] | To set the runtime status of the net.ipv6.conf.all.accept_ra_defrtr kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.all.accept_ra_defrtr=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv6.conf.all.accept_ra_defrtr = 0
| Rationale: | An illicit router advertisement message could result in a man-in-the-middle attack. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_ra_defrtr | References: | | |
|
Rule
Configure Accepting Prefix Information in Router Advertisements on All IPv6 Interfaces
[ref] | To set the runtime status of the net.ipv6.conf.all.accept_ra_pinfo kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.all.accept_ra_pinfo=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv6.conf.all.accept_ra_pinfo = 0
| Rationale: | An illicit router advertisement message could result in a man-in-the-middle attack. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_ra_pinfo | References: | | |
|
Rule
Configure Accepting Router Preference in Router Advertisements on All IPv6 Interfaces
[ref] | To set the runtime status of the net.ipv6.conf.all.accept_ra_rtr_pref kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.all.accept_ra_rtr_pref=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv6.conf.all.accept_ra_rtr_pref = 0
| Rationale: | An illicit router advertisement message could result in a man-in-the-middle attack. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_ra_rtr_pref | References: | | |
|
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 | 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 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 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 | ccn | A.8.SEC-OL6 |
| |
|
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 | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 4, 6, 8, 9 | cobit5 | APO01.06, APO13.01, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.07, DSS06.02 | cui | 3.1.20 | disa | CCI-000366 | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.4.3.3 | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-7(a), CM-7(b), CM-6(a) | 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 | ccn | A.8.SEC-OL6 |
| |
|
Rule
Configure Auto Configuration on All IPv6 Interfaces
[ref] | To set the runtime status of the net.ipv6.conf.all.autoconf kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.all.autoconf=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.autoconf = 0
| Rationale: | An illicit router advertisement message could result in a man-in-the-middle attack. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_autoconf | References: | | |
|
Rule
Configure Maximum Number of Autoconfigured Addresses on All IPv6 Interfaces
[ref] | To set the runtime status of the net.ipv6.conf.all.max_addresses kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.all.max_addresses=1
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.max_addresses = 1
| Rationale: | The number of global unicast IPv6 addresses for each interface should be limited exactly to the number of statically configured addresses. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_max_addresses | References: | | |
|
Rule
Configure Denying Router Solicitations on All IPv6 Interfaces
[ref] | To set the runtime status of the net.ipv6.conf.all.router_solicitations kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.all.router_solicitations=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.router_solicitations = 0
| Rationale: | To prevent discovery of the system by other systems, router solicitation requests should be denied. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_router_solicitations | References: | | |
|
Rule
Configure Accepting Default Router in Router Advertisements on All IPv6 Interfaces By Default
[ref] | To set the runtime status of the net.ipv6.conf.default.accept_ra_defrtr kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.default.accept_ra_defrtr=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv6.conf.default.accept_ra_defrtr = 0
| Rationale: | An illicit router advertisement message could result in a man-in-the-middle attack. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_ra_defrtr | References: | | |
|
Rule
Configure Accepting Prefix Information in Router Advertisements on All IPv6 Interfaces By Default
[ref] | To set the runtime status of the net.ipv6.conf.default.accept_ra_pinfo kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.default.accept_ra_pinfo=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv6.conf.default.accept_ra_pinfo = 0
| Rationale: | An illicit router advertisement message could result in a man-in-the-middle attack. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_ra_pinfo | References: | | |
|
Rule
Configure Accepting Router Preference in Router Advertisements on All IPv6 Interfaces By Default
[ref] | To set the runtime status of the net.ipv6.conf.default.accept_ra_rtr_pref kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.default.accept_ra_rtr_pref=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv6.conf.default.accept_ra_rtr_pref = 0
| Rationale: | An illicit router advertisement message could result in a man-in-the-middle attack. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_ra_rtr_pref | References: | | |
|
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 | 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 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 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 | ccn | A.8.SEC-OL6 |
| |
|
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 | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 4, 6, 8, 9 | cobit5 | APO01.06, APO13.01, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.07, DSS06.02 | cui | 3.1.20 | disa | CCI-000366 | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.4.3.3 | isa-62443-2013 | SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-7(a), CM-7(b), CM-6(a), CM-6(b), CM-6.1(iv) | nist-csf | DE.AE-1, ID.AM-3, PR.AC-5, PR.DS-5, PR.PT-4 | pcidss | Req-1.4.3 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R13 | ccn | A.8.SEC-OL6 | pcidss4 | 1.4.2, 1.4 |
| |
|
Rule
Configure Auto Configuration on All IPv6 Interfaces By Default
[ref] | To set the runtime status of the net.ipv6.conf.default.autoconf kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.default.autoconf=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.autoconf = 0
| Rationale: | An illicit router advertisement message could result in a man-in-the-middle attack. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_autoconf | References: | | |
|
Rule
Configure Maximum Number of Autoconfigured Addresses on All IPv6 Interfaces By Default
[ref] | To set the runtime status of the net.ipv6.conf.default.max_addresses kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.default.max_addresses=1
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.max_addresses = 1
| Rationale: | The number of global unicast IPv6 addresses for each interface should be limited exactly to the number of statically configured addresses. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_max_addresses | References: | | |
|
Rule
Configure Denying Router Solicitations on All IPv6 Interfaces By Default
[ref] | To set the runtime status of the net.ipv6.conf.default.router_solicitations kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.default.router_solicitations=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.router_solicitations = 0
| Rationale: | To prevent discovery of the system by other systems, router solicitation requests should be denied. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_router_solicitations | References: | | |
|
Group
Kernel Parameters Which Affect Networking
Group contains 2 groups and 22 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 19 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 | 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 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 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 | ccn | A.8.SEC-OL6 |
| |
|
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 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | cui | 3.1.20 | disa | CCI-000366 | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | nist | CM-7(a), CM-7(b), SC-5, 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 | ccn | A.8.SEC-OL6 |
| |
|
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
Drop Gratuitious ARP frames on All IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.drop_gratuitous_arp kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.drop_gratuitous_arp=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.drop_gratuitous_arp = 1
Warning:
This can cause problems if ARP proxies are used in the network. | Rationale: | Drop Gratuitous ARP frames to prevent ARP poisoning. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_drop_gratuitous_arp | 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 | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9 | cobit5 | APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02 | cui | 3.1.20 | disa | CCI-000366 | 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 | ccn | A.8.SEC-OL6 | 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 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | cui | 3.1.20 | disa | CCI-001503, CCI-001551 | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-7(a), CM-7(b), CM-6(a), SC-7(a) | nist-csf | DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4 | pcidss | Req-1.4.3 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R12 | ccn | A.8.SEC-OL6 | 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 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | cjis | 5.10.1.1 | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | cui | 3.1.20 | disa | CCI-000366 | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | 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 | ccn | A.8.SEC-OL6 | 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 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | cjis | 5.10.1.1 | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | cui | 3.1.20 | disa | CCI-000366 | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | nist | CM-7(a), CM-7(b), SC-5, 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 | ccn | A.8.SEC-OL6 |
| |
|
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 | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9 | cobit5 | APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02 | cui | 3.1.20 | disa | CCI-000366 | 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 | ccn | A.8.SEC-OL6 |
| |
|
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 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | cui | 3.1.20 | disa | CCI-001551 | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | 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 | ccn | A.8.SEC-OL6 |
| |
|
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 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9 | cobit5 | APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06 | cui | 3.1.20 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 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 | ccn | A.8.SEC-OL6 | pcidss4 | 1.4.2, 1.4 |
| |
|
Rule
Set Kernel Parameter to Increase Local Port Range
[ref] | To set the runtime status of the net.ipv4.ip_local_port_range kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.ip_local_port_range=32768 65535
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv4.ip_local_port_range = 32768 65535
| Rationale: | This setting defines the local port range that is used by TCP and UDP to
choose the local port. The first number is the first, the second the last
local port number. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_ip_local_port_range | References: | | |
|
Rule
Enable Kernel Parameter to Use TCP RFC 1337 on IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.tcp_rfc1337 kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.tcp_rfc1337=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_rfc1337 = 1
| Rationale: | Enable TCP behavior conformant with RFC 1337. When disabled, if a RST is
received in TIME_WAIT state, we close the socket immediately without waiting
for the end of the TIME_WAIT period. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_tcp_rfc1337 | References: | | |
|
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 | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9 | cjis | 5.10.1.1 | cobit5 | APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02 | cui | 3.1.20 | disa | CCI-001095, CCI-000366, CCI-002385 | 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 | ccn | A.8.SEC-OL6 | 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 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | cjis | 5.10.1.1 | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | cui | 3.1.20 | disa | CCI-000366 | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | nist | CM-7(a), CM-7(b), SC-5, 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 | ccn | A.8.SEC-OL6 | 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 | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | cjis | 5.10.1.1 | cobit5 | APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | cui | 3.1.20 | disa | CCI-000366 | isa-62443-2009 | 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | nist | CM-7(a), CM-7(b), SC-5, 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 | ccn | A.8.SEC-OL6 | 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 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.9.1.2 | nerc-cip | CIP-007-3 R4, CIP-007-3 R4.1, CIP-007-3 R4.2, CIP-007-3 R5.1 | nist | CM-7(a), CM-7(b), SC-5, CM-6(a), SC-7(a) | nist-csf | DE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3, PR.PT-4 | pcidss | Req-1.3.1, Req-1.3.2 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R12 | ccn | A.8.SEC-OL6 | 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 8 groups and 68 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 Oracle Linux 9
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 37 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 | disa | CCI-000366 | 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 | disa | CCI-000366 | 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 | disa | CCI-000366 | 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 | disa | CCI-000366 | 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 | disa | CCI-000366 | 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 | disa | CCI-000366 | 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 | disa | CCI-000366 | 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 | disa | CCI-000366 | 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 | disa | CCI-000366 | 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 | disa | CCI-000366 | 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 | disa | CCI-000366 | 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 | disa | CCI-000366 | 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 | disa | CCI-001499 | 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 | disa | CCI-001499 | 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
Ensure All World-Writable Directories Are Owned by root User
[ref] | All directories in local partitions which are world-writable should be owned by root.
If any world-writable directories are not owned by root, this should be investigated.
Following this, the files should be deleted or assigned to root user. | Rationale: | Allowing a user account to own a world-writable directory is undesirable because it allows the
owner of that directory to remove or replace any files that may be placed in the directory by
other users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_dir_perms_world_writable_root_owned | References: | disa | CCI-000366, CCI-001090 | os-srg | SRG-OS-000480-GPOS-00227, SRG-OS-000138-GPOS-00069 | anssi | R54 |
| |
|
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 | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | disa | CCI-001090 | 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 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 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
Ensure All SGID Executables Are Authorized
[ref] | The SGID (set group id) bit should be set only on files that were installed via authorized
means. A straightforward means of identifying unauthorized SGID files is determine if any were
not installed as part of an RPM package, which is cryptographically verified. Investigate the
origin of any unpackaged SGID files. This configuration check considers authorized SGID files
those which were installed via RPM. It is assumed that when an individual has sudo access to
install an RPM and all packages are signed with an organizationally-recognized GPG key, the
software should be considered an approved package on the system. Any SGID file not deployed
through an RPM will be flagged for further review. 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: | Executable files with the SGID permission run with the privileges of the owner of the file.
SGID files of uncertain provenance could allow for unprivileged users to elevate privileges.
The presence of these files should be strictly controlled on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_unauthorized_sgid | 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 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | anssi | R56 |
| |
|
Rule
Ensure All SUID Executables Are Authorized
[ref] | The SUID (set user id) bit should be set only on files that were installed via authorized
means. A straightforward means of identifying unauthorized SUID files is determine if any were
not installed as part of an RPM package, which is cryptographically verified. Investigate the
origin of any unpackaged SUID files. This configuration check considers authorized SUID files
those which were installed via RPM. It is assumed that when an individual has sudo access to
install an RPM and all packages are signed with an organizationally-recognized GPG key, the
software should be considered an approved package on the system. Any SUID file not deployed
through an RPM will be flagged for further review. 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: | Executable files with the SUID permission run with the privileges of the owner of the file.
SUID files of uncertain provenance could allow for unprivileged users to elevate privileges.
The presence of these files should be strictly controlled on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_unauthorized_suid | 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 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | anssi | R56 |
| |
|
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
Ensure All Files Are Owned by a Group
[ref] | If any file is not group-owned by a valid defined group, the cause of the lack of
group-ownership must be investigated. Following this, those files should be deleted or
assigned to an appropriate group. The groups need to be defined in /etc/group
or in /usr/lib/group if nss-altfiles are configured to be used
in /etc/nsswitch.conf .
Locate the mount points related to local devices by the following command:
$ findmnt -n -l -k -it $(awk '/nodev/ { print $2 }' /proc/filesystems | paste -sd,)
For all mount points listed by the previous command, it is necessary to search for files which
do not belong to a valid group using the following command:
$ sudo find MOUNTPOINT -xdev -nogroup 2>/dev/null
Warning:
This rule only considers local groups as valid groups.
If you have your groups defined outside /etc/group or /usr/lib/group , the rule won't consider those. 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: | Unowned files do not directly imply a security problem, but they are generally a sign that
something is amiss. They may be caused by an intruder, by incorrect software installation or
draft software removal, or by failure to remove all files belonging to a deleted account, or
other similar cases. The files should be repaired so they will not cause problems when
accounts are created in the future, and the cause should be discovered and addressed. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_ungroupowned | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.02, DSS06.03, DSS06.06, DSS06.10 | disa | CCI-000366 | 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 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.DS-5, PR.PT-3 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R53 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Ensure All Files Are Owned by a User
[ref] | If any files are not owned by a user, then the cause of their lack of ownership should be
investigated. Following this, the files should be deleted or assigned to an appropriate user.
Locate the mount points related to local devices by the following command:
$ findmnt -n -l -k -it $(awk '/nodev/ { print $2 }' /proc/filesystems | paste -sd,)
For all mount points listed by the previous command, it is necessary to search for files which
do not belong to a valid user using the following command:
$ sudo find MOUNTPOINT -xdev -nouser 2>/dev/null
Warning:
For this rule to evaluate centralized user accounts, getent must be working properly
so that running the command getent passwd returns a list of all users in your organization.
If using the System Security Services Daemon (SSSD), enumerate = true must be configured
in your organization's domain to return a complete list of users 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: | Unowned files do not directly imply a security problem, but they are generally a sign that
something is amiss. They may be caused by an intruder, by incorrect software installation or
draft software removal, or by failure to remove all files belonging to a deleted account, or
other similar cases. The files should be repaired so they will not cause problems when
accounts are created in the future, and the cause should be discovered and addressed. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_no_files_unowned_by_user | References: | cis-csc | 11, 12, 13, 14, 15, 16, 18, 3, 5, 9 | cobit5 | APO01.06, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.03, DSS06.06 | disa | CCI-000366 | 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, 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 5.2, SR 7.6 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.2, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, 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.AC-6, PR.DS-5, PR.IP-1, PR.PT-3 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R53 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Enable Kernel Parameter to Enforce DAC on FIFOs
[ref] | To set the runtime status of the fs.protected_fifos kernel parameter, run the following command: $ sudo sysctl -w fs.protected_fifos=2
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : fs.protected_fifos = 2
| Rationale: | This parameter is available since Linux Kernel 4.19 and allows to prohibit opening
FIFOs that are not owned by the user in world and group writeable sticky directories.
It avoids unintentional writes to an attacker-controlled FIFO where a program expects
to create the regular file. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_fs_protected_fifos | References: | | |
|
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 | References: | disa | CCI-002235, CCI-002165 | 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 Regular files
[ref] | To set the runtime status of the fs.protected_regular kernel parameter, run the following command: $ sudo sysctl -w fs.protected_regular=2
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : fs.protected_regular = 2
| Rationale: | This parameter is available since Linux Kernel 4.19 and allows to prohibit opening
"regular" files that are not owned by the user in world and group writeable sticky
directories. It avoids writes to an attacker-controlled regular file, for example,
when a program expects to create the regular file. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_fs_protected_regular | References: | | |
|
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 | References: | disa | CCI-002235, CCI-002165 | 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 15 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 noexec Option to /boot
[ref] | The noexec mount option can be used to prevent binaries from being
executed out of /boot .
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/boot . | Rationale: | The /boot partition contains the kernel and the bootloader. No
binaries should be executed from this partition after the booting process
finishes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_boot_noexec | References: | | |
|
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 fourth column of
/etc/fstab for the line which 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: | disa | CCI-000366, CCI-001764 | 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 noexec Option to /home
[ref] | The noexec mount option can be used to prevent binaries from being
executed out of /home .
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/home . Warning:
OVAL looks for partitions whose mount point is a substring of any interactive user's home
directory and validates that noexec option is there. Because of this, there could be false
negatives when several partitions share a base substring. For example, if there is a home
directory in /var/tmp/user1 and there are partitions mounted in /var and
/var/tmp . The noexec option is only expected in /var/tmp , but OVAL will
check both.
Bash remediation uses the df command to find out the partition where the home
directory is mounted. However, if the directory doesn't exist the remediation won't be
applied. | Rationale: | The /home directory contains data of individual users. Binaries in
this directory should not be considered as trusted and users should not be
able to execute them. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_home_noexec | References: | | |
|
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 fourth column of
/etc/fstab for the line which controls mounting of
/home . Warning:
OVAL looks for partitions whose mount point is a substring of any interactive user's home
directory and validates that noexec option is there. Because of this, there could be false
negatives when several partitions share a base substring. For example, if there is a home
directory in /var/tmp/user1 and there are partitions mounted in /var and
/var/tmp . The noexec option is only expected in /var/tmp , but OVAL will
check both.
Bash remediation uses the df command to find out the partition where the home
directory is mounted. However, if the directory doesn't exist the remediation won't be
applied. | 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 | disa | CCI-000366, CCI-001764 | 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 fourth column of
/etc/fstab for the line which 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 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 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 nosuid Option to /opt
[ref] | The nosuid mount option can be used to prevent
execution of setuid programs in /opt . The SUID and SGID permissions
should not be required in this directory.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/opt . | Rationale: | The presence of SUID and SGID executables should be tightly controlled. The
/opt directory contains additional software packages. Users should
not be able to execute SUID or SGID binaries from this directory. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_opt_nosuid | References: | | |
|
Rule
Add nosuid Option to /srv
[ref] | The nosuid mount option can be used to prevent
execution of setuid programs in /srv . The SUID and SGID permissions
should not be required in this directory.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/srv . | Rationale: | The presence of SUID and SGID executables should be tightly controlled. The
/srv directory contains files served by various network services such as FTP. Users should
not be able to execute SUID or SGID binaries from this directory. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_srv_nosuid | References: | | |
|
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 fourth column of
/etc/fstab for the line which 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 | disa | CCI-001764 | 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 fourth column of
/etc/fstab for the line which 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 | disa | CCI-001764 | 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 fourth column of
/etc/fstab for the line which 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: | disa | CCI-001764 | 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 fourth column of
/etc/fstab for the line which 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: | disa | CCI-001764 | 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
[ref] | The noexec mount option can be used to prevent binaries from being
executed out of /var .
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/var . | Rationale: | The /var directory contains variable system data such as logs,
mails and caches. No binaries should be executed from this directory. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_var_noexec | References: | | |
|
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 fourth column of
/etc/fstab for the line which 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 fourth column of
/etc/fstab for the line which 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 | 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 fourth column of
/etc/fstab for the line which 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 | References: | | |
|
Group
Restrict Programs from Dangerous Execution Patterns
Group contains 3 groups and 16 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 | ccn | A.8.SEC-OL6 | 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 | References: | disa | CCI-000366, CCI-002824, CCI-001082 | 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) | 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 | References: | cui | 3.1.7 | disa | CCI-000366, CCI-002824 | 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 | anssi | R9 | pcidss4 | 3.3.1.1, 3.3.1, 3.3 |
| |
|
Group
Memory Poisoning
Group contains 2 rules |
[ref]
Memory Poisoning consists of writing a special value to uninitialized or freed memory.
Poisoning can be used as a mechanism to prevent leak of information and detection of
corrupted memory. |
Rule
Enable page allocator poisoning
[ref] | To enable poisoning of free pages,
add the argument page_poison=1 to the default
GRUB 2 command line for the Linux operating system.
To ensure that page_poison=1 is added as a kernel command line
argument to newly installed kernels, add page_poison=1 to the
default Grub2 command line for Linux operating systems. Modify the line within
/etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... page_poison=1 ..."
Run the following command to update command line for already installed kernels: # grubby --update-kernel=ALL --args="page_poison=1"
| Rationale: | Poisoning writes an arbitrary value to freed pages, so any modification or
reference to that page after being freed or before being initialized will be
detected and prevented.
This prevents many types of use-after-free vulnerabilities at little performance cost.
Also prevents leak of data and detection of corrupted memory. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_page_poison_argument | References: | disa | CCI-000366, CCI-001084 | nist | CM-6(a) | os-srg | SRG-OS-000480-GPOS-00227, SRG-OS-000134-GPOS-00068 | anssi | R8 |
| |
|
Rule
Enable SLUB/SLAB allocator poisoning
[ref] | To enable poisoning of SLUB/SLAB objects,
add the argument slub_debug=FZP
to the default
GRUB 2 command line for the Linux operating system.
To ensure that slub_debug=FZP
is added as a kernel command line
argument to newly installed kernels, add slub_debug=FZP
to the
default Grub2 command line for Linux operating systems. Modify the line within
/etc/default/grub as shown below:
GRUB_CMDLINE_LINUX="... slub_debug=FZP ..."
Run the following command to update command line for already installed kernels: # grubby --update-kernel=ALL --args="slub_debug=FZP"
| Rationale: | Poisoning writes an arbitrary value to freed objects, so any modification or
reference to that object after being freed or before being initialized will be
detected and prevented.
This prevents many types of use-after-free vulnerabilities at little performance cost.
Also prevents leak of data and detection of corrupted memory. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_slub_debug_argument | References: | disa | CCI-002824, CCI-001084 | nist | CM-6(a) | os-srg | SRG-OS-000433-GPOS-00192, SRG-OS-000134-GPOS-00068 | anssi | R8 |
| |
|
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 | References: | cui | 3.1.5 | disa | CCI-001082, CCI-001090 | 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) | os-srg | SRG-OS-000132-GPOS-00067, SRG-OS-000138-GPOS-00069 | app-srg-ctr | SRG-APP-000243-CTR-000600 | 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
Limit CPU consumption of the Perf system
[ref] | To set the runtime status of the kernel.perf_cpu_time_max_percent kernel parameter, run the following command: $ sudo sysctl -w kernel.perf_cpu_time_max_percent=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : kernel.perf_cpu_time_max_percent = 1
| Rationale: | The kernel.perf_cpu_time_max_percent configures a treshold of
maximum percentile of CPU that can be used by Perf system. Restricting usage
of Perf system decreases risk of potential availability problems. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_perf_cpu_time_max_percent | References: | | |
|
Rule
Limit sampling frequency of the Perf system
[ref] | To set the runtime status of the kernel.perf_event_max_sample_rate kernel parameter, run the following command: $ sudo sysctl -w kernel.perf_event_max_sample_rate=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : kernel.perf_event_max_sample_rate = 1
| Rationale: | The kernel.perf_event_max_sample_rate parameter configures maximum
frequency of collecting of samples for the Perf system. It is expressed in
samples per second. Restricting usage of Perf system decreases risk
of potential availability problems. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_perf_event_max_sample_rate | 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 | References: | | |
|
Rule
Configure maximum number of process identifiers
[ref] | To set the runtime status of the kernel.pid_max kernel parameter, run the following command: $ sudo sysctl -w kernel.pid_max=65536
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : kernel.pid_max = 65536
| Rationale: | The kernel.pid_max parameter configures upper limit on process
identifiers (PID). If this number is not high enough, it might happen that
forking of new processes is not possible, because all available PIDs are
exhausted. Increasing this number enhances availability. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_pid_max | References: | | |
|
Rule
Disallow magic SysRq key
[ref] | To set the runtime status of the kernel.sysrq kernel parameter, run the following command: $ sudo sysctl -w kernel.sysrq=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : kernel.sysrq = 0
| Rationale: | The Magic SysRq key allows sending certain commands directly to the running
kernel. It can dump various system and process information, potentially
revealing sensitive information. It can also reboot or shutdown the machine,
disturbing its availability. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_sysrq | References: | | |
|
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 | References: | disa | CCI-000366, CCI-001082 | 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 | References: | disa | CCI-000366, CCI-001082 | nist | SC-7(10) | os-srg | SRG-OS-000132-GPOS-00067, SRG-OS-000480-GPOS-00227 | anssi | R11 |
| |
|
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 | References: | | |
|
Rule
Prevent applications from mapping low portion of virtual memory
[ref] | To set the runtime status of the vm.mmap_min_addr kernel parameter, run the following command: $ sudo sysctl -w vm.mmap_min_addr=65536
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : vm.mmap_min_addr = 65536
| Rationale: | The vm.mmap_min_addr parameter specifies the minimum virtual
address that a process is allowed to mmap. Allowing a process to mmap low
portion of virtual memory can have security implications such as such as
heightened risk of kernel null pointer dereference defects. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_vm_mmap_min_addr | References: | | |
|
Group
SELinux
Group contains 1 group and 8 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 Oracle Linux 9, 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 Oracle Linux 9 system, unless that
system has unusual requirements which make a stronger policy
appropriate.
For more information on SELinux, see https://docs.oracle.com/en/operating-systems/oracle-linux/selinux/. |
Group
SELinux - Booleans
Group contains 1 rule |
[ref]
Enable or Disable runtime customization of SELinux system policies
without having to reload or recompile the SELinux policy. |
Rule
Configure the polyinstantiation_enabled SELinux Boolean
[ref] | By default, the SELinux boolean polyinstantiation_enabled is disabled.
This setting should be configured to true.
To set the polyinstantiation_enabled SELinux boolean, run the following command:
$ sudo setsebool -P polyinstantiation_enabled true
| Rationale: | | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sebool_polyinstantiation_enabled | References: | | |
|
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
Ensure SELinux State is Enforcing
[ref] | The SELinux state should be set to enforcing at
system boot time. In the file /etc/selinux/config , add or correct the
following line to configure the system to boot into enforcing mode:
SELINUX=enforcing
| Rationale: | Setting the SELinux state to enforcing ensures SELinux is able to confine
potentially compromised processes to the security policy, which is designed to
prevent them from causing damage to the system or further elevating their
privileges. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_selinux_state | 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 | disa | CCI-002696, CCI-001084 | 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 | os-srg | SRG-OS-000445-GPOS-00199, SRG-OS-000134-GPOS-00068 | anssi | R37, R79 | bsi | APP.4.4.A4, SYS.1.6.A3, SYS.1.6.A18, SYS.1.6.A21 | ccn | A.6.SEC-OL1 | pcidss4 | 1.2.6, 1.2 |
| |
|
Group
Services
Group contains 14 groups and 30 rules |
[ref]
The best protection against vulnerable software is running less software. This section describes how to review
the software which Oracle Linux 9 installs on a system and disable software which is not needed. It
then enumerates the software packages installed on a default Oracle Linux 9 system and provides guidance about which
ones can be safely disabled.
Oracle Linux 9 provides a convenient minimal install option that essentially installs the bare necessities for a functional
system. When building Oracle Linux 9 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 DHCP Server Package
[ref] | If the system does not need to act as a DHCP server,
the dhcp package can be uninstalled.
The dhcp-server package can be removed with the following command:
$ sudo yum erase dhcp-server
| 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_dhcp_removed | References: | cis-csc | 11, 14, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 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 | anssi | R62 | pcidss4 | 2.2.4, 2.2 |
| |
|
Group
Mail Server Software
Group contains 1 group and 3 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 Oracle Linux 9 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 2 rules |
[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
Disable Postfix Network Listening
[ref] | Edit the file /etc/postfix/main.cf to ensure that only the following
inet_interfaces line appears:
inet_interfaces = loopback-only
| Rationale: | This ensures postfix accepts mail messages
(such as cron job reports) from the local system only,
and not from the network, which protects it from network attack. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_postfix_network_listening_disabled | References: | cis-csc | 11, 14, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | disa | CCI-000382 | 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 | anssi | R74 | pcidss4 | 1.4.2, 1.4 |
| |
|
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 yum erase sendmail
| Rationale: | The sendmail software was not developed with security in mind and
its design prevents it from being effectively contained by SELinux. Postfix
should be used instead. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_sendmail_removed | References: | cis-csc | 11, 14, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | disa | CCI-000366, CCI-000381 | 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 3 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://docs.oracle.com/en/operating-systems/oracle-linux/9/network/network-ConfiguringNetworkTime.html#ol-nettime
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
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
Obsolete Services
Group contains 4 groups and 8 rules |
[ref]
This section discusses a number of network-visible
services which have historically caused problems for system
security, and for which disabling or severely limiting the service
has been the best available guidance for some time. As a result of
this, many of these services are not installed as part of Oracle Linux 9
by default.
Organizations which are running these services should
switch to more secure equivalents as soon as possible.
If it remains absolutely necessary to run one of
these services for legacy reasons, care should be taken to restrict
the service as much as possible, for instance by configuring host
firewall software such as iptables to restrict access to the
vulnerable service to only those remote hosts which have a known
need to use it. |
Group
Rlogin, Rsh, and Rexec
Group contains 2 rules |
[ref]
The Berkeley r-commands are legacy services which
allow cleartext remote access and have an insecure trust
model. |
Rule
Uninstall rsh-server Package
[ref] | The rsh-server package can be removed with the following command:
$ sudo yum erase rsh-server
| Rationale: | The rsh-server service provides unencrypted remote access service which does not
provide for the confidentiality and integrity of user passwords or the remote session and has very weak
authentication. If a privileged user were to login using this service, the privileged user password
could be compromised. The rsh-server package provides several obsolete and insecure
network services. Removing it decreases the risk of those services' accidental (or intentional)
activation. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_package_rsh-server_removed | 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 | disa | CCI-000381 | 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.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), IA-5(1)(c) | nist-csf | PR.AC-3, PR.IP-1, PR.PT-3, PR.PT-4 | os-srg | SRG-OS-000095-GPOS-00049 | anssi | R62 | pcidss4 | 2.2.4, 2.2 |
| |
|
Rule
Uninstall rsh Package
[ref] |
The rsh package contains the client commands
for the rsh services | Rationale: | These legacy clients contain numerous security exposures and have
been replaced with the more secure SSH package. Even if the server is removed,
it is best to ensure the clients are also removed to prevent users from
inadvertently attempting to use these commands and therefore exposing
their credentials. Note that removing the rsh package removes
the clients for rsh ,rcp , and rlogin . | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_package_rsh_removed | References: | cui | 3.1.13 | 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) | iso27001-2013 | A.8.2.3, A.13.1.1, A.13.2.1, A.13.2.3, A.14.1.2, A.14.1.3 | anssi | R62 | pcidss4 | 2.2.4, 2.2 |
| |
|
Group
Chat/Messaging Services
Group contains 2 rules |
[ref]
The talk software makes it possible for users to send and receive messages
across systems through a terminal session. |
Rule
Uninstall talk-server Package
[ref] | The talk-server package can be removed with the following command: $ sudo yum erase talk-server
| Rationale: | The talk software presents a security risk as it uses unencrypted protocols
for communications. Removing the talk-server package decreases the
risk of the accidental (or intentional) activation of talk services. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_talk-server_removed | References: | 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) | anssi | R62 | pcidss4 | 2.2.4, 2.2 |
| |
|
Rule
Uninstall talk Package
[ref] | The talk package contains the client program for the
Internet talk protocol, which allows the user to chat with other users on
different systems. Talk is a communication program which copies lines from one
terminal to the terminal of another user.
The talk package can be removed with the following command:
$ sudo yum erase talk
| Rationale: | The talk software presents a security risk as it uses unencrypted protocols
for communications. Removing the talk package decreases the
risk of the accidental (or intentional) activation of talk client program. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_talk_removed | References: | 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) | anssi | R62 | pcidss4 | 2.2.4, 2.2 |
| |
|
Group
Telnet
Group contains 2 rules |
[ref]
The telnet protocol does not provide confidentiality or integrity
for information transmitted on the network. This includes authentication
information such as passwords. Organizations which use telnet should be
actively working to migrate to a more secure protocol. |
Rule
Uninstall telnet-server Package
[ref] | The telnet-server package can be removed with the following command:
$ sudo yum erase telnet-server
| Rationale: | It is detrimental for operating systems to provide, or install by default,
functionality exceeding requirements or mission objectives. These
unnecessary capabilities are often overlooked and therefore may remain
unsecure. They increase the risk to the platform by providing additional
attack vectors.
The telnet service provides an unencrypted remote access service which does
not provide for the confidentiality and integrity of user passwords or the
remote session. If a privileged user were to login using this service, the
privileged user password could be compromised.
Removing the telnet-server package decreases the risk of the
telnet service's accidental (or intentional) activation. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_package_telnet-server_removed | 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 | disa | CCI-000381 | 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.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 | pcidss | Req-2.2.2 | os-srg | SRG-OS-000095-GPOS-00049 | anssi | R62 | ccn | A.8.SEC-OL4 | pcidss4 | 2.2.4, 2.2 |
| |
|
Rule
Remove telnet Clients
[ref] | The telnet client allows users to start connections to other systems via
the telnet protocol. | Rationale: | The telnet protocol is insecure and unencrypted. The use
of an unencrypted transmission medium could allow an unauthorized user
to steal credentials. The ssh package provides an
encrypted session and stronger security and is included in Oracle Linux 9. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_package_telnet_removed | References: | cui | 3.1.13 | 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) | iso27001-2013 | A.8.2.3, A.13.1.1, A.13.2.1, A.13.2.3, A.14.1.2, A.14.1.3 | anssi | R62 | pcidss4 | 2.2.4, 2.2 |
| |
|
Group
TFTP Server
Group contains 2 rules |
[ref]
TFTP is a lightweight version of the FTP protocol which has
traditionally been used to configure networking equipment. However,
TFTP provides little security, and modern versions of networking
operating systems frequently support configuration via SSH or other
more secure protocols. A TFTP server should be run only if no more
secure method of supporting existing equipment can be
found. |
Rule
Uninstall tftp-server Package
[ref] | The tftp-server package can be removed with the following command: $ sudo yum erase tftp-server
| Rationale: | Removing the tftp-server package decreases the risk of the accidental
(or intentional) activation of tftp services.
If TFTP is required for operational support (such as transmission of router
configurations), its use must be documented with the Information Systems
Securty Manager (ISSM), restricted to only authorized personnel, and have
access control rules established. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_package_tftp-server_removed | 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 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 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-000480-GPOS-00227 | anssi | R62 | ccn | A.8.SEC-OL4 | pcidss4 | 2.2.4, 2.2 |
| |
|
Rule
Remove tftp Daemon
[ref] | Trivial File Transfer Protocol (TFTP) is a simple file transfer protocol,
typically used to automatically transfer configuration or boot files between systems.
TFTP does not support authentication and can be easily hacked. The package
tftp is a client program that allows for connections to a tftp server. | Rationale: | It is recommended that TFTP be removed, unless there is a specific need
for TFTP (such as a boot server). In that case, use extreme caution when configuring
the services. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_package_tftp_removed | 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 | 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 | disa | CCI-000366, CCI-004045 | 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 | 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 | disa | CCI-000366 | 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 | disa | CCI-000366 | 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 | disa | CCI-000366 | 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 0600 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 | disa | CCI-000366 | 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 | disa | CCI-000366 | 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 |
|
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 | disa | CCI-001453 | 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 yum 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 command:
$ sudo systemctl enable sssd.service
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 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 | disa | CCI-004046, CCI-001953, CCI-001954 | 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 2 groups and 3 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 1 group and 1 rule |
[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 Information on the Use of Privileged Commands
Group contains 1 rule |
[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 - 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 perm=x -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 perm=x -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 | 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 | disa | CCI-000172, CCI-000130, CCI-000135, CCI-000169, CCI-002884 | 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 | anssi | R33 |
| |
|
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 | References: | disa | CCI-000133, CCI-001881, CCI-001875, CCI-000154, CCI-001882, CCI-000158, CCI-001914, CCI-000169, CCI-001464, CCI-001878, CCI-001877, CCI-001889, CCI-000135, CCI-002884, CCI-001487, CCI-003938, CCI-000132, CCI-000134, CCI-000172, CCI-000130, CCI-000131, CCI-001879, CCI-001880, CCI-001876, CCI-000159 | 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 command:
$ sudo systemctl enable auditd.service
| 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 | 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 | disa | CCI-000133, CCI-001881, CCI-001875, CCI-000154, CCI-001882, CCI-000158, CCI-001914, CCI-000169, CCI-001464, CCI-001878, CCI-001877, CCI-001889, CCI-000135, CCI-002884, CCI-001487, CCI-003938, CCI-000132, CCI-004188, CCI-000134, CCI-000172, CCI-000130, CCI-000131, CCI-001879, CCI-001880, CCI-001876 | 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 | anssi | R33, R73 | pcidss4 | 10.2.1, 10.2 |
| |
|