Group
Guide to the Secure Configuration of Amazon Linux 2023
Group contains 106 groups and 356 rules |
Group
System Settings
Group contains 51 groups and 203 rules |
[ref]
Contains rules that check correct system settings. |
Group
Installing and Maintaining Software
Group contains 7 groups and 18 rules |
[ref]
The following sections contain information on
security-relevant choices during the initial operating system
installation process and the setup of software
updates. |
Group
System and Software Integrity
Group contains 3 groups and 6 rules |
[ref]
System and software integrity can be gained by installing antivirus, increasing
system encryption strength with FIPS, verifying installed software, enabling SELinux,
installing an Intrusion Prevention System, etc. However, installing or enabling integrity
checking tools cannot prevent intrusions, but they can detect that an intrusion
may have occurred. Requirements for integrity checking may be highly dependent on
the environment in which the system will be used. Snapshot-based approaches such
as AIDE may induce considerable overhead in the presence of frequent software updates. |
Group
Software Integrity Checking
Group contains 1 group and 4 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 4 rules |
[ref]
AIDE conducts integrity checks by comparing information about
files with previously-gathered information. Ideally, the AIDE database is
created immediately after initial system configuration, and then again after any
software update. AIDE is highly configurable, with further configuration
information located in /usr/share/doc/aide-VERSION
. |
Rule
Install AIDE
[ref] | The aide package can be installed with the following command:
$ sudo dnf install aide
| Rationale: | The AIDE package must be installed if it is to be available for integrity checking. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_aide_installed | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | disa | CCI-002696, CCI-002699, 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 | cis | 1.3.1 | pcidss4 | 11.5.2 |
| |
|
Rule
Build and Test AIDE Database
[ref] | Run the following command to generate a new database:
$ sudo /usr/sbin/aide --init
By default, the database will be written to the file
/var/lib/aide/aide.db.new.gz .
Storing the database, the configuration file /etc/aide.conf , and the binary
/usr/sbin/aide
(or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity.
The newly-generated database can be installed as follows:
$ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
To initiate a manual check, run the following command:
$ sudo /usr/sbin/aide --check
If this check produces any unexpected output, investigate. | Rationale: | For AIDE to be effective, an initial database of "known-good" information about files
must be captured and it should be able to be verified against the installed files. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_aide_build_database | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 2, 3, 5, 7, 8, 9 | cjis | 5.10.1.3 | cobit5 | APO01.06, BAI01.06, BAI02.01, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS04.07, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.02, DSS06.06 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4 | isa-62443-2013 | SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 4.1, SR 6.2, SR 7.6 | iso27001-2013 | A.11.2.4, A.12.1.2, A.12.2.1, A.12.4.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.7, A.15.2.1, A.8.2.3 | nist | CM-6(a) | nist-csf | DE.CM-1, DE.CM-7, PR.DS-1, PR.DS-6, PR.DS-8, PR.IP-1, PR.IP-3 | pcidss | Req-11.5 | os-srg | SRG-OS-000445-GPOS-00199 | anssi | R76, R79 | cis | 1.3.1 | pcidss4 | 11.5.2 |
| |
|
Rule
Configure AIDE to Verify the Audit Tools
[ref] | The operating system file integrity tool must be configured to protect the integrity of the audit tools. | Rationale: | Protecting the integrity of the tools used for auditing purposes is a
critical step toward ensuring the integrity of audit information. Audit
information includes all information (e.g., audit records, audit settings,
and audit reports) needed to successfully audit information system
activity.
Audit tools include but are not limited to vendor-provided and open-source
audit tools needed to successfully view and manipulate audit information
system activity and records. Audit tools include custom queries and report
generators.
It is not uncommon for attackers to replace the audit tools or inject code
into the existing tools to provide the capability to hide or erase system
activity from the audit logs.
To address this risk, audit tools must be cryptographically signed to
provide the capability to identify when the audit tools have been modified,
manipulated, or replaced. An example is a checksum hash of the file or
files. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_aide_check_audit_tools | References: | | |
|
Rule
Configure Periodic Execution of AIDE
[ref] | At a minimum, AIDE should be configured to run a weekly scan.
To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab :
05 4 * * * root /usr/sbin/aide --check
To implement a weekly execution of AIDE at 4:05am using cron, add the following line to /etc/crontab :
05 4 * * 0 root /usr/sbin/aide --check
AIDE can be executed periodically through other means; this is merely one example.
The usage of cron's special time codes, such as @daily and
@weekly is acceptable. | Rationale: | By default, AIDE does not install itself for periodic execution. Periodically
running AIDE is necessary to reveal unexpected changes in installed files.
Unauthorized changes to the baseline configuration could make the system vulnerable
to various attacks or allow unauthorized access to the operating system. Changes to
operating system configurations can have unintended side effects, some of which may
be relevant to security.
Detecting such changes and providing an automated response can help avoid unintended,
negative consequences that could ultimately affect the security state of the operating
system. The operating system's Information Management Officer (IMO)/Information System
Security Officer (ISSO) and System Administrators (SAs) must be notified via email and/or
monitoring system trap when there is an unauthorized modification of a configuration item. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_aide_periodic_cron_checking | 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-001744, CCI-002699, CCI-002702 | 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 | SI-7, SI-7(1), 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-000363-GPOS-00150, SRG-OS-000446-GPOS-00200, SRG-OS-000447-GPOS-00201 | anssi | R76 | cis | 1.3.2 | pcidss4 | 11.5.2 |
| |
|
Group
System Cryptographic Policies
Group contains 2 rules |
[ref]
Linux has the capability to centrally configure cryptographic polices. The command
update-crypto-policies is used to set the policy applicable for the various
cryptographic back-ends, such as SSL/TLS libraries. The configured cryptographic
policies will be the default policy used by these backends unless the application
user configures them otherwise. When the system has been configured to use the
centralized cryptographic policies, the administrator is assured that any application
that utilizes the supported backends will follow a policy that adheres to the
configured profile.
Currently the supported backends are:
- GnuTLS library
- OpenSSL library
- NSS library
- OpenJDK
- Libkrb5
- BIND
- OpenSSH
Applications and languages which rely on any of these backends will follow the
system policies as well. Examples are apache httpd, nginx, php, and others. |
Rule
Configure System Cryptography Policy
[ref] | To configure the system cryptography policy to use ciphers only from the DEFAULT
policy, run the following command:
$ sudo update-crypto-policies --set DEFAULT
The rule checks if settings for selected crypto policy are configured as expected. Configuration files in the /etc/crypto-policies/back-ends are either symlinks to correct files provided by Crypto-policies package or they are regular files in case crypto policy customizations are applied.
Crypto policies may be customized by crypto policy modules, in which case it is delimited from the base policy using a colon. Warning:
The system needs to be rebooted for these changes to take effect. Warning:
System Crypto Modules must be provided by a vendor that undergoes
FIPS-140 certifications.
FIPS-140 is applicable to all Federal agencies that use
cryptographic-based security systems to protect sensitive information
in computer and telecommunication systems (including voice systems) as
defined in Section 5131 of the Information Technology Management Reform
Act of 1996, Public Law 104-106. This standard shall be used in
designing and implementing cryptographic modules that Federal
departments and agencies operate or are operated for them under
contract. See https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf
To meet this, the system has to have cryptographic software provided by
a vendor that has undergone this certification. This means providing
documentation, test results, design information, and independent third
party review by an accredited lab. While open source software is
capable of meeting this, it does not meet FIPS-140 unless the vendor
submits to this process. | Rationale: | Centralized cryptographic policies simplify applying secure ciphers across an operating system and
the applications that run on that operating system. Use of weak or untested encryption algorithms
undermines the purposes of utilizing encryption to protect data. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_configure_crypto_policy | References: | hipaa | 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.312(e)(1), 164.312(e)(2)(ii) | ism | 1446 | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1, CIP-007-3 R7.1 | nist | AC-17(a), AC-17(2), CM-6(a), MA-4(6), SC-13, SC-12(2), SC-12(3) | ospp | FCS_COP.1(1), FCS_COP.1(2), FCS_COP.1(3), FCS_COP.1(4), FCS_CKM.1, FCS_CKM.2, FCS_TLSC_EXT.1 | os-srg | SRG-OS-000396-GPOS-00176, SRG-OS-000393-GPOS-00173, SRG-OS-000394-GPOS-00174 | cis | 1.9 | pcidss4 | 2.2.7, 2.2 |
| |
|
Rule
Configure SSH to use System Crypto Policy
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
SSH is supported by crypto policy, but the SSH configuration may be
set up to ignore it.
To check that Crypto Policies settings are configured correctly, ensure that
the CRYPTO_POLICY variable is either commented or not set at all
in the /etc/sysconfig/sshd . | Rationale: | Overriding the system crypto policy makes the behavior of the SSH service violate expectations,
and makes system configuration more fragmented. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_configure_ssh_crypto_policy | References: | disa | CCI-001453 | hipaa | 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.312(e)(1), 164.312(e)(2)(ii) | nerc-cip | CIP-003-8 R4.2, CIP-007-3 R5.1, CIP-007-3 R7.1 | nist | AC-17(a), AC-17(2), CM-6(a), MA-4(6), SC-13 | ospp | FCS_SSH_EXT.1, FCS_SSHS_EXT.1, FCS_SSHC_EXT.1 | pcidss | Req-2.2 | os-srg | SRG-OS-000250-GPOS-00093 | cis | 4.2.14 | pcidss4 | 2.2.7, 2.2 |
| |
|
Group
Disk Partitioning
Group contains 7 rules |
[ref]
To ensure separation and protection of data, there
are top-level system directories which should be placed on their
own physical partition or logical volume. The installer's default
partitioning scheme creates separate logical volumes for
/ , /boot , and swap .
- If starting with any of the default layouts, check the box to
\"Review and modify partitioning.\" This allows for the easy creation
of additional logical volumes inside the volume group already
created, though it may require making
/ 's logical volume smaller to
create space. In general, using logical volumes is preferable to
using partitions because they can be more easily adjusted
later. - If creating a custom layout, create the partitions mentioned in
the previous paragraph (which the installer will require anyway),
as well as separate ones described in the following sections.
If a system has already been installed, and the default
partitioning
scheme was used, it is possible but nontrivial to
modify it to create separate logical volumes for the directories
listed above. The Logical Volume Manager (LVM) makes this possible. |
Rule
Ensure /dev/shm is configured
[ref] | The /dev/shm is a traditional shared memory concept.
One program will create a memory portion, which other processes
(if permitted) can access. If /dev/shm is not configured,
tmpfs will be mounted to /dev/shm by systemd. Warning:
This rule does not have a remedation.
It is expected that this will be managed by systemd and will be a tmpfs partition. | Rationale: | Any user can upload and execute files inside the /dev/shm similar to
the /tmp partition. Configuring /dev/shm allows an administrator
to set the noexec option on the mount, making /dev/shm useless for an attacker to
install executable code. It would also prevent an attacker from establishing a
hardlink to a system setuid program and wait for it to be updated. Once the program
was updated, the hardlink would be broken and the attacker would have his own copy
of the program. If the program happened to have a security vulnerability, the attacker
could continue to exploit the known flaw. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_dev_shm | References: | | |
|
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, CCI-001208 | 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 | cis | 1.1.7.1 |
| |
|
Rule
Ensure /tmp Located On Separate Partition
[ref] | The /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 /tmp partition is used as temporary storage by many programs.
Placing /tmp in its own partition enables the setting of more
restrictive mount options, which can help protect programs which use it. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_tmp | 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 | cis | 1.1.2.1 |
| |
|
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 | cis | 1.1.3.1 |
| |
|
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 | cis | 1.1.5.1 |
| |
|
Rule
Ensure /var/log/audit Located On Separate Partition
[ref] | Audit logs are stored in the /var/log/audit directory.
Ensure that /var/log/audit has its own partition or logical
volume at installation time, or migrate it using LVM.
Make absolutely certain that it is large enough to store all
audit logs that will be created by the auditing daemon. | Rationale: | Placing /var/log/audit in its own partition
enables better separation between audit files
and other files, and helps ensure that
auditing cannot be halted due to the partition running out
of space. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_partition_for_var_log_audit | References: | cis-csc | 1, 12, 13, 14, 15, 16, 2, 3, 5, 6, 8 | cobit5 | APO11.04, APO13.01, BAI03.05, BAI04.04, DSS05.02, DSS05.04, DSS05.07, MEA02.01 | disa | CCI-000366, CCI-001849 | hipaa | 164.312(a)(2)(ii) | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.2, SR 7.6 | iso27001-2013 | A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.17.2.1 | nerc-cip | CIP-007-3 R6.5 | nist | CM-6(a), AU-4, SC-5(2) | nist-csf | PR.DS-4, PR.PT-1, PR.PT-4 | ospp | FMT_SMF_EXT.1 | os-srg | SRG-OS-000341-GPOS-00132, SRG-OS-000480-GPOS-00227 | app-srg-ctr | SRG-APP-000357-CTR-000800 | anssi | R71 | cis | 1.1.6.1 |
| |
|
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: | | |
|
Group
Sudo
Group contains 4 rules |
[ref]
Sudo , which stands for "su 'do'", provides the ability to delegate authority
to certain users, groups of users, or system administrators. When configured for system
users and/or groups, Sudo can allow a user or group to execute privileged commands
that normally only root is allowed to execute.
For more information on Sudo and addition Sudo configuration options, see
https://www.sudo.ws. |
Rule
Install sudo Package
[ref] | The sudo package can be installed with the following command:
$ sudo dnf install sudo
| Rationale: | sudo is a program designed to allow a system administrator to give
limited root privileges to users and log root activity. The basic philosophy
is to give as few privileges as possible but still allow system users to
get their work done.
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_sudo_installed | 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
Ensure Sudo Logfile Exists - sudo logfile
[ref] | A custom log sudo file can be configured with the 'logfile' tag. This rule configures
a sudo custom logfile at the default location suggested by CIS, which uses
/var/log/sudo.log. | Rationale: | A sudo log file simplifies auditing of sudo commands. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_custom_logfile | References: | | |
|
Rule
Require Re-Authentication When Using the sudo Command
[ref] | The sudo timestamp_timeout tag sets the amount of time sudo password prompt waits.
The default timestamp_timeout value is 5 minutes.
The timestamp_timeout should be configured by making sure that the
timestamp_timeout tag exists in
/etc/sudoers configuration file or any sudo configuration snippets
in /etc/sudoers.d/ .
If the value is set to an integer less than 0, the user's time stamp will not expire
and the user will not have to re-authenticate for privileged actions until the user's session is terminated. | Rationale: | Without re-authentication, users may access resources or perform tasks for which they
do not have authorization.
When operating systems provide the capability to escalate a functional capability, it
is critical that the user re-authenticate. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_require_reauthentication | References: | disa | CCI-002038 | nist | IA-11 | os-srg | SRG-OS-000373-GPOS-00156, SRG-OS-000373-GPOS-00157, SRG-OS-000373-GPOS-00158 | cis | 4.3.4, 4.3.5 | pcidss4 | 2.2.6, 2.2 |
| |
|
Group
Updating Software
Group contains 1 rule |
[ref]
The dnf command line tool is used to install and
update software packages. The system also provides a graphical
software update tool in the System menu, in the Administration submenu,
called Software Update.
Amazon Linux 2023 systems contain an installed software catalog called
the RPM database, which records metadata of installed packages. Consistently using
dnf or the graphical Software Update for all software installation
allows for insight into the current inventory of installed software on the system.
|
Rule
Ensure gpgcheck Enabled In Main dnf Configuration
[ref] | The gpgcheck option controls whether
RPM packages' signatures are always checked prior to installation.
To configure dnf to check package signatures before installing
them, ensure the following line appears in /etc/dnf/dnf.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-001749 | 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 | cis | 1.2.2 | pcidss4 | 6.3.3, 6.3 |
| |
|
Group
Account and Access Control
Group contains 14 groups and 62 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
Amazon Linux 2023. |
Group
Warning Banners for System Accesses
Group contains 12 rules |
[ref]
Each system should expose as little information about
itself as possible.
System banners, which are typically displayed just before a
login prompt, give out information about the service or the host's
operating system. This might include the distribution name and the
system kernel version, and the particular version of a network
service. This information can assist intruders in gaining access to
the system as it can reveal whether the system is running
vulnerable software. Most network services can be configured to
limit what information is displayed.
Many organizations implement security policies that require a
system banner provide notice of the system's ownership, provide
warning to unauthorized users, and remind authorized users of their
consent to monitoring. |
Rule
Modify the System Login Banner
[ref] |
To configure the system login banner edit /etc/issue . Replace the
default text with a message compliant with the local site policy or a legal
disclaimer.
The DoD required text is either:
You are accessing a U.S. Government (USG) Information System (IS) that
is provided for USG-authorized use only. By using this IS (which includes
any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS
for purposes including, but not limited to, penetration testing, COMSEC
monitoring, network operations and defense, personnel misconduct (PM), law
enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private,
are subject to routine monitoring, interception, and search, and may be
disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access
controls) to protect USG interests -- not for your personal benefit or
privacy.
-Notwithstanding the above, using this IS does not constitute consent
to PM, LE or CI investigative searching or monitoring of the content of
privileged communications, or work product, related to personal
representation or services by attorneys, psychotherapists, or clergy, and
their assistants. Such communications and work product are private and
confidential. See User Agreement for details.
OR:
I've read & consent to terms in IS user agreem't.
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
System use notifications are required only for access via login interfaces
with human users and are not required when such human interfaces do not
exist. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_banner_etc_issue | References: | cis-csc | 1, 12, 15, 16 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.9 | disa | CCI-000048, CCI-000050, CCI-001384, CCI-001385, CCI-001386, CCI-001387, CCI-001388 | 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 | nist | AC-8(a), AC-8(c) | nist-csf | PR.AC-7 | ospp | FMT_MOF_EXT.1 | os-srg | SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 | cis | 1.7.2 |
| |
|
Rule
Modify the System Login Banner for Remote Connections
[ref] | To configure the system login banner edit /etc/issue.net . Replace the
default text with a message compliant with the local site policy or a legal
disclaimer.
The DoD required text is either:
You are accessing a U.S. Government (USG) Information System (IS) that
is provided for USG-authorized use only. By using this IS (which includes
any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS
for purposes including, but not limited to, penetration testing, COMSEC
monitoring, network operations and defense, personnel misconduct (PM), law
enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private,
are subject to routine monitoring, interception, and search, and may be
disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access
controls) to protect USG interests -- not for your personal benefit or
privacy.
-Notwithstanding the above, using this IS does not constitute consent
to PM, LE or CI investigative searching or monitoring of the content of
privileged communications, or work product, related to personal
representation or services by attorneys, psychotherapists, or clergy, and
their assistants. Such communications and work product are private and
confidential. See User Agreement for details.
OR:
I've read & consent to terms in IS user agreem't.
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
System use notifications are required only for access via login interfaces
with human users and are not required when such human interfaces do not
exist. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_banner_etc_issue_net | References: | disa | CCI-000048, CCI-001384, CCI-001385, CCI-001386, CCI-001387, CCI-001388 | os-srg | SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 | cis | 1.7.3 |
| |
|
Rule
Modify the System Message of the Day Banner
[ref] | To configure the system message banner edit /etc/motd . Replace the
default text with a message compliant with the local site policy or a legal
disclaimer.
The DoD required text is either:
You are accessing a U.S. Government (USG) Information System (IS) that
is provided for USG-authorized use only. By using this IS (which includes
any device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS
for purposes including, but not limited to, penetration testing, COMSEC
monitoring, network operations and defense, personnel misconduct (PM), law
enforcement (LE), and counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private,
are subject to routine monitoring, interception, and search, and may be
disclosed or used for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access
controls) to protect USG interests -- not for your personal benefit or
privacy.
-Notwithstanding the above, using this IS does not constitute consent
to PM, LE or CI investigative searching or monitoring of the content of
privileged communications, or work product, related to personal
representation or services by attorneys, psychotherapists, or clergy, and
their assistants. Such communications and work product are private and
confidential. See User Agreement for details.
OR:
I've read & consent to terms in IS user agreem't.
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
System use notifications are required only for access via login interfaces
with human users and are not required when such human interfaces do not
exist. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_banner_etc_motd | References: | | |
|
Rule
Verify Group Ownership of System Login Banner
[ref] |
To properly set the group owner of /etc/issue , run the command:
$ sudo chgrp root /etc/issue
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper group ownership will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_issue | References: | | |
|
Rule
Verify Group Ownership of System Login Banner for Remote Connections
[ref] |
To properly set the group owner of /etc/issue.net , run the command:
$ sudo chgrp root /etc/issue.net
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper group ownership will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_issue_net | References: | | |
|
Rule
Verify Group Ownership of Message of the Day Banner
[ref] |
To properly set the group owner of /etc/motd , run the command:
$ sudo chgrp root /etc/motd
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper group ownership will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_motd | References: | | |
|
Rule
Verify ownership of System Login Banner
[ref] |
To properly set the owner of /etc/issue , run the command:
$ sudo chown root /etc/issue
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper ownership will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_issue | References: | | |
|
Rule
Verify ownership of System Login Banner for Remote Connections
[ref] |
To properly set the owner of /etc/issue.net , run the command:
$ sudo chown root /etc/issue.net
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper ownership will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_issue_net | References: | | |
|
Rule
Verify ownership of Message of the Day Banner
[ref] |
To properly set the owner of /etc/motd , run the command:
$ sudo chown root /etc/motd
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper ownership will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_motd | References: | | |
|
Rule
Verify permissions on System Login Banner
[ref] |
To properly set the permissions of /etc/issue , run the command:
$ sudo chmod 0644 /etc/issue
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper permissions will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_issue | References: | | |
|
Rule
Verify permissions on System Login Banner for Remote Connections
[ref] |
To properly set the permissions of /etc/issue.net , run the command:
$ sudo chmod 0644 /etc/issue.net
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper permissions will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_issue_net | References: | | |
|
Rule
Verify permissions on Message of the Day Banner
[ref] |
To properly set the permissions of /etc/motd , run the command:
$ sudo chmod 0644 /etc/motd
| Rationale: | Display of a standardized and approved use notification before granting
access to the operating system ensures privacy and security notification
verbiage used is consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
Proper permissions will ensure that only root user can modify the banner. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_motd | References: | | |
|
Group
Protect Accounts by Configuring PAM
Group contains 4 groups and 12 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 6 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
Configure the Use of the pam_faillock.so Module in the /etc/pam.d/password-auth File.
[ref] | The pam_faillock.so module must be loaded in preauth in /etc/pam.d/password-auth. | Rationale: | If the pam_faillock.so module is not loaded the system will not correctly lockout accounts to prevent
password guessing attacks. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_account_password_pam_faillock_password_auth | References: | | |
|
Rule
Configure the Use of the pam_faillock.so Module in the /etc/pam.d/system-auth File.
[ref] | The pam_faillock.so module must be loaded in preauth in /etc/pam.d/system-auth. | Rationale: | If the pam_faillock.so module is not loaded the system will not correctly lockout accounts to prevent
password guessing attacks. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_account_password_pam_faillock_system_auth | References: | | |
|
Rule
Limit Password Reuse: password-auth
[ref] | Do not allow users to reuse recent passwords. This can be accomplished by using the
remember option for the pam_pwhistory PAM module.
On systems with newer versions of authselect , the pam_pwhistory PAM module
can be enabled via authselect feature:
authselect enable-feature with-pwhistory
Otherwise, it should be enabled using an authselect custom profile.
Newer systems also have the /etc/security/pwhistory.conf file for setting
pam_pwhistory module options. This file should be used whenever available.
Otherwise, the pam_pwhistory module options can be set in PAM files.
The value for remember option must be equal or greater than
5
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.
If a custom profile was created and used in the system before this authselect feature was
available, the new feature can't be used with this custom profile and the
remediation will fail. In this case, the custom profile should be recreated or manually
updated. | 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_pwhistory_remember_password_auth | 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 | cis | 4.5.3 | pcidss4 | 8.3.7, 8.3 |
| |
|
Rule
Limit Password Reuse: system-auth
[ref] | Do not allow users to reuse recent passwords. This can be accomplished by using the
remember option for the pam_pwhistory PAM module.
On systems with newer versions of authselect , the pam_pwhistory PAM module
can be enabled via authselect feature:
authselect enable-feature with-pwhistory
Otherwise, it should be enabled using an authselect custom profile.
Newer systems also have the /etc/security/pwhistory.conf file for setting
pam_pwhistory module options. This file should be used whenever available.
Otherwise, the pam_pwhistory module options can be set in PAM files.
The value for remember option must be equal or greater than
5
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_pwhistory_remember_system_auth | 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 | cis | 4.5.3 | 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-002236, CCI-002237, 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 | cis | 4.5.2 | pcidss4 | 8.3.4, 8.3 |
| |
|
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-002236, CCI-002237, 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 | cis | 4.5.2 | pcidss4 | 8.3.4, 8.3 |
| |
|
Group
Set Password Quality Requirements
Group contains 1 group and 3 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 3 rules |
[ref]
The pam_pwquality PAM module can be configured to meet
requirements for a variety of policies.
For example, to configure pam_pwquality to require at least one uppercase
character, lowercase character, digit, and other (special)
character, make sure that pam_pwquality exists in /etc/pam.d/system-auth :
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth .
Next, modify the settings in /etc/security/pwquality.conf to match the following:
difok = 4
minlen = 14
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
maxrepeat = 3
The arguments can be modified to ensure compliance with
your organization's security policy. Discussion of each parameter follows. |
Rule
Ensure PAM Enforces Password Requirements - Minimum Different Categories
[ref] | The pam_pwquality module's minclass parameter controls
requirements for usage of different character classes, or types, of character
that must exist in a password before it is considered valid. For example,
setting this value to three (3) requires that any password must have characters
from at least three different categories in order to be approved. The default
value is zero (0), meaning there are no required classes. There are four
categories available:
* Upper-case characters
* Lower-case characters
* Digits
* Special characters (for example, punctuation)
Modify the minclass setting in /etc/security/pwquality.conf entry
to require 4
differing categories of characters when changing passwords. | Rationale: | Use of a complex password helps to increase the time and resources required to compromise the password.
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts
at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The
more complex the password, the greater the number of possible combinations that need to be tested before
the password is compromised.
Requiring a minimum number of character categories makes password guessing attacks more difficult
by ensuring a larger search space. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_minclass | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-000195 | 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 | cis | 4.5.1 |
| |
|
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=14
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-000205, 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 | cis | 4.5.1 | pcidss4 | 8.3.6, 8.3 |
| |
|
Rule
Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session
[ref] | To configure the number of retry prompts that are permitted per-session:
Edit the pam_pwquality.so statement in
/etc/pam.d/system-auth to show
retry=3
, or a lower value if site
policy is more restrictive. The DoD requirement is a maximum of 3 prompts
per session. | Rationale: | Setting the password retry prompts that are permitted on a per-session basis to a low value
requires some software, such as SSH, to re-connect. This can slow down and
draw additional attention to some types of password-guessing attacks. Note that this
is different from account lockout, which is provided by the pam_faillock module. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_retry | References: | cis-csc | 1, 11, 12, 15, 16, 3, 5, 9 | cjis | 5.5.3 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-000192, CCI-000366 | 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 | ospp | FMT_MOF_EXT.1 | os-srg | SRG-OS-000069-GPOS-00037, SRG-OS-000480-GPOS-00227 | anssi | R68 | cis | 4.5.1 |
| |
|
Group
Set Password Hashing Algorithm
Group contains 3 rules |
[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 Password Hashing Algorithm in /etc/login.defs
[ref] | In /etc/login.defs , add or update the following line to ensure the system will use
SHA512 as the hashing algorithm:
ENCRYPT_METHOD SHA512
| 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.
Using a stronger hashing algorithm makes password cracking attacks more difficult. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_logindefs | 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 | 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 | cis | 4.5.4 | pcidss4 | 8.3.2, 8.3 |
| |
|
Rule
Set PAM''s Password Hashing Algorithm - password-auth
[ref] | The PAM system service can be configured to only store encrypted representations of passwords.
In /etc/pam.d/password-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_passwordauth | 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 | 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 | cis | 4.5.4 |
| |
|
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 | cis | 4.5.4 | pcidss4 | 8.3.2, 8.3 |
| |
|
Group
Protect Accounts by Restricting Password-Based Login
Group contains 4 groups and 24 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 Account Expiration Parameters
Group contains 2 rules |
[ref]
Accounts can be configured to be automatically disabled
after a certain time period,
meaning that they will require administrator interaction to become usable again.
Expiration of accounts after inactivity can be set for all accounts by default
and also on a per-account basis, such as for accounts that are known to be temporary.
To configure automatic expiration of an account following
the expiration of its password (that is, after the password has expired and not been changed),
run the following command, substituting NUM_DAYS and USER appropriately:
$ sudo chage -I NUM_DAYS USER
Accounts, such as temporary accounts, can also be configured to expire on an explicitly-set date with the
-E option.
The file /etc/default/useradd controls
default settings for all newly-created accounts created with the system's
normal command line utilities. Warning:
This will only apply to newly created accounts |
Rule
Set Account Expiration Following Inactivity
[ref] | To specify the number of days after a password expires (which
signifies inactivity) until an account is permanently disabled, add or correct
the following line in /etc/default/useradd :
INACTIVE=30
If a password is currently on the verge of expiration, then
30
day(s) remain(s) until the account is automatically
disabled. However, if the password will not expire for another 60 days, then 60
days plus 30 day(s) could
elapse until the account would be automatically disabled. See the
useradd man page for more information. | Rationale: | Inactive identifiers pose a risk to systems and applications because attackers may exploit an inactive identifier and potentially obtain undetected access to the system.
Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials.
Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_account_disable_post_pw_expiration | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 3, 5, 7, 8 | cjis | 5.6.2.1.1 | cobit5 | DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.6 | disa | CCI-000017, CCI-000795 | 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 | 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.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 | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | nist | IA-4(e), AC-2(3), CM-6(a) | nist-csf | DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7 | pcidss | Req-8.1.4 | os-srg | SRG-OS-000118-GPOS-00060 | cis | 4.6.1.4 | pcidss4 | 8.2.6, 8.2 |
| |
|
Rule
Ensure All Accounts on the System Have Unique Names
[ref] | Ensure accounts on the system have unique names.
To ensure all accounts have unique names, run the following command:
$ sudo getent passwd | awk -F: '{ print $1}' | uniq -d
If a username is returned, change or delete the username. | Rationale: | Unique usernames allow for accountability on the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_account_unique_name | References: | | |
|
Group
Set Password Expiration Parameters
Group contains 7 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 Maximum Age
[ref] | To specify password maximum age for new accounts,
edit the file /etc/login.defs
and add or correct the following line:
PASS_MAX_DAYS 365
A value of 180 days is sufficient for many environments.
The DoD requirement is 60.
The profile requirement is 365 . | 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.
Setting the password maximum age ensures users are required to
periodically change their passwords. Requiring shorter password lifetimes
increases the risk of users writing down the password in a convenient
location subject to physical compromise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_maximum_age_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.6 | disa | CCI-000199, 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 | 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(f), IA-5(1)(d), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.4 | os-srg | SRG-OS-000076-GPOS-00044 | cis | 4.6.1.1 | pcidss4 | 8.3.9, 8.3 |
| |
|
Rule
Set Password Minimum Age
[ref] | To specify password minimum age for new accounts,
edit the file /etc/login.defs
and add or correct the following line:
PASS_MIN_DAYS 1
A value of 1 day is considered sufficient for many
environments. The DoD requirement is 1.
The profile requirement is 1 . | Rationale: | Enforcing a minimum password lifetime helps to prevent repeated password
changes to defeat the password reuse or history enforcement requirement. If
users are allowed to immediately and continually change their password,
then the password could be repeatedly changed in a short period of time to
defeat the organization's policy regarding password reuse.
Setting the minimum password age protects against users cycling back to a
favorite password after satisfying the password reuse requirement. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_minimum_age_login_defs | 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-000198, 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 | 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(f), IA-5(1)(d), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | os-srg | SRG-OS-000075-GPOS-00043 | cis | 4.6.1.2 |
| |
|
Rule
Set Existing Passwords Maximum Age
[ref] | Configure non-compliant accounts to enforce a 365-day maximum password lifetime
restriction by running the following command:
$ sudo chage -M 365
USER
| 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_existing | References: | | |
|
Rule
Set Existing Passwords Minimum Age
[ref] | Configure non-compliant accounts to enforce a 24 hours/1 day minimum password
lifetime by running the following command:
$ sudo chage -m 1 USER
| Rationale: | Enforcing a minimum password lifetime helps to prevent repeated password
changes to defeat the password reuse or history enforcement requirement. If
users are allowed to immediately and continually change their password, the
password could be repeatedly changed in a short period of time to defeat the
organization's policy regarding password reuse. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_set_min_life_existing | References: | disa | CCI-000198 | nist | IA-5(f), IA-5(1)(d), CM-6(a) | os-srg | SRG-OS-000075-GPOS-00043 | cis | 4.6.1.2 |
| |
|
Rule
Set Existing Passwords Warning Age
[ref] | To configure how many days prior to password expiration that a warning will be issued to
users, run the command:
$ sudo chage --warndays 7
USER
The DoD requirement is 7, and CIS recommendation is no less than 7 days.
This profile requirement is 7 . | Rationale: | Providing an advance warning that a password will be expiring gives users
time to think of a secure password. Users caught unaware may choose a simple
password or write it down where it may be discovered. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_set_warn_age_existing | References: | | |
|
Rule
Set Password Warning Age
[ref] | To specify how many days prior to password
expiration that a warning will be issued to users,
edit the file /etc/login.defs and add or correct
the following line:
PASS_WARN_AGE 7
The DoD requirement is 7.
The profile requirement is 7 . | Rationale: | Setting the password warning age enables users to
make the change at a practical time. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_warn_age_login_defs | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 3, 5, 7, 8 | cobit5 | DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.8 | 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 | 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 | ism | 0418, 1055, 1402 | iso27001-2013 | A.12.4.1, A.12.4.3, 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 | IA-5(f), IA-5(1)(d), CM-6(a) | nist-csf | DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.4 | cis | 4.6.1.3 | pcidss4 | 8.3.9, 8.3 |
| |
|
Rule
Set existing passwords a period of inactivity before they been locked
[ref] | Configure user accounts that have been inactive for over a given period of time
to be automatically disabled by running the following command:
$ sudo chage --inactive 30USER
| Rationale: | Inactive accounts pose a threat to system security since the users are not logging in to
notice failed login attempts or other anomalies. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_set_post_pw_existing | References: | cobit5 | DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.6 | disa | CCI-000017, CCI-000795, CCI-003627, CCI-003628 | 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 | 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.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 | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | nist | IA-4(e), AC-2(3), CM-6(a) | nist-csf | DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7 | pcidss | Req-8.1.4 | os-srg | SRG-OS-000118-GPOS-00060 | cis | 4.6.1.4 | pcidss4 | 8.2.6, 8.2 |
| |
|
Group
Verify Proper Storage and Existence of Password
Hashes
Group contains 5 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
Verify All Account Password Hashes are Shadowed
[ref] | If any password hashes are stored in /etc/passwd (in the second field,
instead of an x or * ), the cause of this misconfiguration should be
investigated. The account should have its password reset and the hash should be
properly stored, or the account should be deleted entirely. | Rationale: | The hashes for all user account passwords should be stored in
the file /etc/shadow and never in /etc/passwd ,
which is readable by all users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_all_shadowed | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.5.2 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.5.10 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1 | ism | 1410 | 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(h), CM-6(a) | nist-csf | PR.AC-1, PR.AC-6, PR.AC-7 | pcidss | Req-8.2.1 | cis | 6.2.1 | pcidss4 | 8.3.2, 8.3 |
| |
|
Rule
Ensure all users last password change date is in the past
[ref] | All users should have a password change date in the past. Warning:
Automatic remediation is not available, in order to avoid any system disruption. | Rationale: | If a user recorded password change date is in the future then they could
bypass any set password expiration. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_last_change_is_in_past | References: | | |
|
Rule
All GIDs referenced in /etc/passwd must be defined in /etc/group
[ref] | Add a group to the system for each GID referenced without a corresponding group. | Rationale: | If a user is assigned the Group Identifier (GID) of a group not existing on the system, and a group
with the Group Identifier (GID) is subsequently created, the user may have unintended rights to
any files associated with the group. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_gid_passwd_group_same | References: | cis-csc | 1, 12, 15, 16, 5 | cjis | 5.5.2 | cobit5 | DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | disa | CCI-000764 | 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 | pcidss | Req-8.5.a | os-srg | SRG-OS-000104-GPOS-00051 | cis | 6.2.3 | pcidss4 | 8.2.2, 8.2 |
| |
|
Rule
Ensure There Are No Accounts With Blank or Null Passwords
[ref] | Check the "/etc/shadow" file for blank passwords with the
following command:
$ sudo awk -F: '!$2 {print $1}' /etc/shadow
If the command returns any results, this is a finding.
Configure all accounts on the system to have a password or lock
the account with the following commands:
Perform a password reset:
$ sudo passwd [username]
Lock an account:
$ sudo passwd -l [username]
Warning:
Note that this rule is not applicable for systems running within a container. Having user with empty password within a container is not considered a risk, because it should not be possible to directly login into a container anyway. | Rationale: | If an account has an empty password, anyone could log in and
run commands with the privileges of that account. Accounts with
empty passwords should never be used in operational environments. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_no_empty_passwords_etc_shadow | References: | | |
|
Rule
Verify No .forward Files Exist
[ref] | The .forward file specifies an email address to forward the user's mail to. | Rationale: | Use of the .forward file poses a security risk in that sensitive data may
be inadvertently transferred outside the organization. The .forward file
also poses a risk as it can be used to execute commands that may perform
unintended actions. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_no_forward_files | References: | | |
|
Group
Restrict Root Logins
Group contains 7 rules |
[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
Verify Only Root Has UID 0
[ref] | If any account other than root has a UID of 0, this misconfiguration should
be investigated and the accounts other than root should be removed or have
their UID changed.
If the account is associated with system commands or applications the UID
should be changed to one greater than "0" but less than "1000."
Otherwise assign a UID greater than "1000" that has not already been
assigned. | Rationale: | An account has root authority if it has a UID of 0. Multiple accounts
with a UID of 0 afford more opportunity for potential intruders to
guess a password for a privileged account. Proper configuration of
sudo is recommended to afford multiple system administrators
access to root privileges in an accountable manner. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_no_uid_except_zero | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.02, DSS06.03, DSS06.10 | cui | 3.1.1, 3.1.5 | disa | CCI-000366 | 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 | 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 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 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, AC-6(5), IA-4(b) | nist-csf | PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.DS-5 | pcidss | Req-8.5 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 6.2.9 | pcidss4 | 8.2.1, 8.2 |
| |
|
Rule
Verify Root Has A Primary GID 0
[ref] | The root user should have a primary group of 0. | Rationale: | To help ensure that root-owned files are not inadvertently exposed to other users. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_root_gid_zero | References: | | |
|
Rule
Ensure the Group Used by pam_wheel.so Module Exists on System and is Empty
[ref] | Ensure that the group sugroup referenced by
var_pam_wheel_group_for_su variable and used as value for the pam_wheel.so
group option exists and has no members. This empty group used by
pam_wheel.so in /etc/pam.d/su ensures that no user can run commands with
altered privileges through the su command. Warning:
Note that this rule just ensures the group exists and has no members. This rule does not
configure pam_wheel.so module. The pam_wheel.so module configuration is
accomplished by use_pam_wheel_group_for_su rule. | Rationale: | The su program allows to run commands with a substitute user and group ID.
It is commonly used to run commands as the root user.
Limiting access to such command is considered a good security practice. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_pam_wheel_group_empty | References: | | |
|
Rule
Ensure Authentication Required for Single User Mode
[ref] | Single user mode is used for recovery when the system detects an
issue during boot or by manual selection from the bootloader. | Rationale: | Requiring authentication in single user mode prevents an unauthorized
user from rebooting the system into single user to gain root privileges
without credentials. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_root_password_configured | References: | | |
|
Rule
Ensure that System Accounts Are Locked
[ref] | Some accounts are not associated with a human user of the system, and exist to perform some
administrative functions. An attacker should not be able to log into these accounts.
System accounts are those user accounts with a user ID less than 1000 .
If any system account other than root , halt , sync , shutdown
and nfsnobody has an unlocked password, disable it with the command:
$ sudo usermod -L account
| Rationale: | Disabling authentication for default system accounts makes it more difficult for attackers
to make use of them to compromise a system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_no_password_auth_for_systemaccounts | References: | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | AC-6, CM-6(a) | cis | 4.6.2 | pcidss4 | 8.2.2, 8.2 |
| |
|
Rule
Ensure that System Accounts Do Not Run a Shell Upon Login
[ref] | Some accounts are not associated with a human user of the system, and exist to perform some
administrative functions. Should an attacker be able to log into these accounts, they should
not be granted access to a shell.
The login shell for each local account is stored in the last field of each line in
/etc/passwd . System accounts are those user accounts with a user ID less than
1000 . The user ID is stored in the third field. If any system account
other than root has a login shell, disable it with the command:
$ sudo usermod -s /sbin/nologin account
Warning:
Do not perform the steps in this section on the root account. Doing so might cause the
system to become inaccessible. | Rationale: | Ensuring shells are not given to system accounts upon login makes it more difficult for
attackers to make use of system accounts. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_no_shelllogin_for_systemaccounts | References: | cis-csc | 1, 12, 13, 14, 15, 16, 18, 3, 5, 7, 8 | cobit5 | DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS06.03 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4 | isa-62443-2013 | SR 1.1, 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 | ism | 1491 | iso27001-2013 | A.12.4.1, A.12.4.3, 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 | AC-6, CM-6(a), CM-6(b), CM-6.1(iv) | nist-csf | DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.6.2 | pcidss4 | 8.2.2, 8.2 |
| |
|
Rule
Enforce Usage of pam_wheel with Group Parameter for su Authentication
[ref] | To ensure that only users who are members of the group set in the group option of
pam_wheel.so module can run commands with altered privileges through the su
command, make sure that the following line exists in the file /etc/pam.d/su :
auth required pam_wheel.so use_uid group=sugroup
Warning:
Note that ensure_pam_wheel_group_empty rule complements this requirement by
ensuring the referenced group exists and has no members. | Rationale: | The su program allows to run commands with a substitute user and group ID.
It is commonly used to run commands as the root user.
Limiting access to such command is considered a good security practice. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_use_pam_wheel_group_for_su | References: | | |
|
Rule
Ensure All Accounts on the System Have Unique User IDs
[ref] | Change user IDs (UIDs), or delete accounts, so each has a unique name. Warning:
Automatic remediation of this control is not available due to unique requirements of each
system. | Rationale: | To assure accountability and prevent unauthenticated access, interactive users must be identified and authenticated to prevent potential misuse and compromise of the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_account_unique_id | References: | disa | CCI-000135, CCI-000764, CCI-000804 | pcidss | Req-8.1.1 | os-srg | SRG-OS-000104-GPOS-00051, SRG-OS-000121-GPOS-00062 | cis | 6.2.4 | pcidss4 | 8.2.1, 8.2 |
| |
|
Rule
Ensure All Groups on the System Have Unique Group ID
[ref] | Change the group name or delete groups, so each has a unique id. Warning:
Automatic remediation of this control is not available due to the unique requirements of each system. | Rationale: | To assure accountability and prevent unauthenticated access, groups must be identified uniquely to prevent potential misuse and compromise of the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_group_unique_id | References: | | |
|
Rule
Ensure All Groups on the System Have Unique Group Names
[ref] | Change the group name or delete groups, so each has a unique name. Warning:
Automatic remediation of this control is not available due to the unique requirements of each system. | Rationale: | To assure accountability and prevent unauthenticated access, groups must be identified uniquely to prevent potential misuse and compromise of the system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_group_unique_name | References: | | |
|
Group
Secure Session Configuration Files for Login Accounts
Group contains 2 groups and 14 rules |
[ref]
When a user logs into a Unix account, the system
configures the user's session by reading a number of files. Many of
these files are located in the user's home directory, and may have
weak permissions as a result of user error or misconfiguration. If
an attacker can modify or even read certain types of account
configuration information, they can often gain full access to the
affected user's account. Therefore, it is important to test and
correct configuration file permissions for interactive accounts,
particularly those of privileged users such as root or system
administrators. |
Group
Ensure that No Dangerous Directories Exist in Root's Path
Group contains 2 rules |
[ref]
The active path of the root account can be obtained by
starting a new root shell and running:
# echo $PATH
This will produce a colon-separated list of
directories in the path.
Certain path elements could be considered dangerous, as they could lead
to root executing unknown or
untrusted programs, which could contain malicious
code.
Since root may sometimes work inside
untrusted directories, the . character, which represents the
current directory, should never be in the root path, nor should any
directory which can be written to by an unprivileged or
semi-privileged (system) user.
It is a good practice for administrators to always execute
privileged commands by typing the full path to the
command. |
Rule
Ensure that Root's Path Does Not Include World or Group-Writable Directories
[ref] | For each element in root's path, run:
# ls -ld DIR
and ensure that write permissions are disabled for group and
other. | Rationale: | Such entries increase the risk that root could
execute code provided by unprivileged users,
and potentially malicious code. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_root_path_dirs_no_write | References: | cis-csc | 11, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05 | disa | CCI-000366 | 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-6(a), CM-6(a) | nist-csf | PR.IP-1 | cis | 6.2.8 |
| |
|
Rule
Ensure that Root's Path Does Not Include Relative Paths or Null Directories
[ref] | Ensure that none of the directories in root's path is equal to a single
. character, or
that it contains any instances that lead to relative path traversal, such as
.. or beginning a path without the slash ( / ) character.
Also ensure that there are no "empty" elements in the path, such as in these examples:
PATH=:/bin
PATH=/bin:
PATH=/bin::/sbin
These empty elements have the same effect as a single . character. | Rationale: | Including these entries increases the risk that root could
execute code from an untrusted location. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_root_path_no_dot | References: | cis-csc | 11, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05 | disa | CCI-000366 | 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-6(a), CM-6(a) | nist-csf | PR.IP-1 | cis | 6.2.8 |
| |
|
Group
Ensure that Users Have Sensible Umask Values
Group contains 3 rules |
[ref]
The umask setting controls the default permissions
for the creation of new files.
With a default umask setting of 077, files and directories
created by users will not be readable by any other user on the
system. Users who wish to make specific files group- or
world-readable can accomplish this by using the chmod command.
Additionally, users can make all their files readable to their
group by default by setting a umask of 027 in their shell
configuration files. If default per-user groups exist (that is, if
every user has a default group whose name is the same as that
user's username and whose only member is the user), then it may
even be safe for users to select a umask of 007, making it very
easy to intentionally share files with groups of which the user is
a member.
|
Rule
Ensure the Default Bash Umask is Set Correctly
[ref] | To ensure the default umask for users of the Bash shell is set properly,
add or correct the umask setting in /etc/bashrc to read
as follows:
umask 027
| Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read or
written to by unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_umask_etc_bashrc | References: | cis-csc | 18 | cobit5 | APO13.01, BAI03.01, BAI03.02, BAI03.03 | disa | CCI-000366 | isa-62443-2009 | 4.3.4.3.3 | iso27001-2013 | A.14.1.1, A.14.2.1, A.14.2.5, A.6.1.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | AC-6(1), CM-6(a) | nist-csf | PR.IP-2 | os-srg | SRG-OS-000480-GPOS-00228, SRG-OS-000480-GPOS-00227 | anssi | R36 | cis | 4.6.5 |
| |
|
Rule
Ensure the Default Umask is Set Correctly in login.defs
[ref] | To ensure the default umask controlled by /etc/login.defs is set properly,
add or correct the UMASK setting in /etc/login.defs to read as follows:
UMASK 027
| Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read and
written to by unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_umask_etc_login_defs | References: | cis-csc | 11, 18, 3, 9 | cobit5 | APO13.01, BAI03.01, BAI03.02, BAI03.03, BAI10.01, BAI10.02, BAI10.03, BAI10.05 | disa | CCI-000366 | isa-62443-2009 | 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 7.6 | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.1.1, A.14.2.1, A.14.2.2, A.14.2.3, A.14.2.4, A.14.2.5, A.6.1.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | AC-6(1), CM-6(a) | nist-csf | PR.IP-1, PR.IP-2 | os-srg | SRG-OS-000480-GPOS-00228 | anssi | R36 | cis | 4.6.5 |
| |
|
Rule
Ensure the Default Umask is Set Correctly in /etc/profile
[ref] | To ensure the default umask controlled by /etc/profile is set properly,
add or correct the umask setting in /etc/profile to read as follows:
umask 027
Note that /etc/profile also reads scrips within /etc/profile.d directory.
These scripts are also valid files to set umask value. Therefore, they should also be
considered during the check and properly remediated, if necessary. | Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read or
written to by unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_umask_etc_profile | References: | cis-csc | 18 | cobit5 | APO13.01, BAI03.01, BAI03.02, BAI03.03 | disa | CCI-000366 | isa-62443-2009 | 4.3.4.3.3 | iso27001-2013 | A.14.1.1, A.14.2.1, A.14.2.5, A.6.1.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | AC-6(1), CM-6(a) | nist-csf | PR.IP-2 | os-srg | SRG-OS-000480-GPOS-00228, SRG-OS-000480-GPOS-00227 | anssi | R36 | cis | 4.6.5 |
| |
|
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=900
or
declare -xr TMOUT=900
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, CCI-002361 | 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 | ospp | FMT_MOF_EXT.1 | os-srg | SRG-OS-000163-GPOS-00072, SRG-OS-000029-GPOS-00010 | anssi | R32 | cis | 4.6.3 | 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 Interactive Users Home Directories Must Exist
[ref] | Create home directories to all local interactive users that currently do not
have a home directory assigned. Use the following commands to create the user
home directory assigned in /etc/passwd :
$ sudo mkdir /home/USER
| Rationale: | If a local interactive user has a home directory defined that does not exist,
the user may be given access to the / directory as the current working directory
upon logon. This could create a Denial of Service because the user would not be
able to access their logon configuration files, and it may give them visibility
to system files they normally would not be able to access. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_user_interactive_home_directory_exists | References: | | |
|
Rule
Ensure users' .netrc Files are not group or world accessible
[ref] | While the system administrator can establish secure permissions for users' .netrc files, the
users can easily override these.
This rule ensures every .netrc file or directory under the home directory related
to an interactive user is not group or world accessible | Rationale: | .netrc files may contain unencrypted passwords that may be used to attack other systems.
Note: While the complete removal of .netrc files is recommended, if any are required on the
system, secure permissions must be applied. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_users_netrc_file_permissions | References: | | |
|
Rule
All Interactive User Home Directories Must Be Group-Owned By The Primary Group
[ref] | Change the group owner of interactive users home directory to the
group found in /etc/passwd . To change the group owner of
interactive users home directory, use the following command:
$ sudo chgrp USER_GROUP /home/USER
This rule ensures every home directory related to an interactive user is
group-owned by an interactive user. It also ensures that interactive users
are group-owners of one and only one home directory. 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 home directories. | Rationale: | If the Group Identifier (GID) of a local interactive users home directory is
not the same as the primary GID of the user, this would allow unauthorized
access to the users files, and users that share the same group may not be
able to access files that they legitimately should. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupownership_home_directories | References: | | |
|
Rule
All Interactive User Home Directories Must Be Owned By The Primary User
[ref] | Change the owner of interactive users home directories to that correct
owner. To change the owner of a interactive users home directory, use
the following command:
$ sudo chown USER /home/USER
This rule ensures every home directory related to an interactive user is
owned by an interactive user. It also ensures that interactive users are
owners of one and only one home directory. 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 home directories. | Rationale: | If a local interactive user does not own their home directory, unauthorized
users could access or modify the user's files, and the users may not be able to
access their own files. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_ownership_home_directories | 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
All Interactive User Home Directories Must Have mode 0750 Or Less Permissive
[ref] | Change the mode of interactive users home directories to 0750 . To
change the mode of interactive users home directory, use the
following command:
$ sudo chmod 0750 /home/USER
| Rationale: | Excessive permissions on local interactive user home directories may allow
unauthorized access to user files by other users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_home_directories | References: | | |
|
Group
GRUB2 bootloader configuration
Group contains 1 group and 6 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 Amazon Linux 2023 boot loader for x86 systems is called GRUB2.
Options it can pass to the kernel include single-user mode, which
provides root access without any authentication, and the ability to
disable SELinux. To prevent local users from modifying the boot
parameters and endangering security, protect the boot loader configuration
with a password and ensure its configuration file's permissions
are set properly. |
Group
Non-UEFI GRUB2 bootloader configuration
Group contains 6 rules |
[ref]
Non-UEFI GRUB2 bootloader configuration |
Rule
Verify /boot/grub2/grub.cfg Group Ownership
[ref] | The file /boot/grub2/grub.cfg should
be group-owned by the root group to prevent
destruction or modification of the file.
To properly set the group owner of /boot/grub2/grub.cfg , run the command:
$ sudo chgrp root /boot/grub2/grub.cfg
| Rationale: | The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_grub2_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R29 | cis | 1.4.1 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/user.cfg Group Ownership
[ref] | The file /boot/grub2/user.cfg should be group-owned by the root
group to prevent reading or modification of the file.
To properly set the group owner of /boot/grub2/user.cfg , run the command:
$ sudo chgrp root /boot/grub2/user.cfg
| Rationale: | The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway. Non-root users who read the boot parameters
may be able to identify weaknesses in security upon boot and be able to exploit them. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_user_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R29 | cis | 1.4.1 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/grub.cfg User Ownership
[ref] | The file /boot/grub2/grub.cfg should
be owned by the root user to prevent destruction
or modification of the file.
To properly set the owner of /boot/grub2/grub.cfg , run the command:
$ sudo chown root /boot/grub2/grub.cfg
| Rationale: | Only root should be able to modify important boot parameters. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_grub2_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R29 | cis | 1.4.1 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/user.cfg User Ownership
[ref] | The file /boot/grub2/user.cfg should be owned by the root
user to prevent reading or modification of the file.
To properly set the owner of /boot/grub2/user.cfg , run the command:
$ sudo chown root /boot/grub2/user.cfg
| Rationale: | Only root should be able to modify important boot parameters. Also, non-root users who read
the boot parameters may be able to identify weaknesses in security upon boot and be able to
exploit them. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_user_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-7.1 | anssi | R29 | cis | 1.4.1 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/grub.cfg Permissions
[ref] | File permissions for /boot/grub2/grub.cfg should be set to 600.
To properly set the permissions of /boot/grub2/grub.cfg , run the command:
$ sudo chmod 600 /boot/grub2/grub.cfg
| Rationale: | Proper permissions ensure that only the root user can modify important boot
parameters. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_grub2_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | anssi | R29 | cis | 1.4.1 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify /boot/grub2/user.cfg Permissions
[ref] | File permissions for /boot/grub2/user.cfg should be set to 600.
To properly set the permissions of /boot/grub2/user.cfg , run the command:
$ sudo chmod 600 /boot/grub2/user.cfg
| Rationale: | Proper permissions ensure that only the root user can read or modify important boot
parameters. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_user_cfg | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | cui | 3.4.5 | disa | CCI-000225 | hipaa | 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii) | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | anssi | R29 | cis | 1.4.1 | pcidss4 | 2.2.6, 2.2 |
| |
|
Group
Configure Syslog
Group contains 4 groups and 12 rules |
[ref]
The syslog service has been the default Unix logging mechanism for
many years. It has a number of downsides, including inconsistent log format,
lack of authentication for received messages, and lack of authentication,
encryption, or reliable transport for messages sent over a network. However,
due to its long history, syslog is a de facto standard which is supported by
almost all Unix applications.
In Amazon Linux 2023, rsyslog has replaced ksyslogd as the
syslog daemon of choice, and it includes some additional security features
such as reliable, connection-oriented (i.e. TCP) transmission of logs, the
option to log to database formats, and the encryption of log data en route to
a central logging server.
This section discusses how to configure rsyslog for
best effect, and how to use tools provided with the system to maintain and
monitor logs. |
Group
Ensure Proper Configuration of Log Files
Group contains 3 rules |
[ref]
The file /etc/rsyslog.conf controls where log message are written.
These are controlled by lines called rules, which consist of a
selector and an action.
These rules are often customized depending on the role of the system, the
requirements of the environment, and whatever may enable
the administrator to most effectively make use of log data.
The default rules in Amazon Linux 2023 are:
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* -/var/log/maillog
cron.* /var/log/cron
*.emerg *
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log
See the man page rsyslog.conf(5) for more information.
Note that the rsyslog daemon can be configured to use a timestamp format that
some log processing programs may not understand. If this occurs,
edit the file /etc/rsyslog.conf and add or edit the following line:
$ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
|
Rule
Ensure Log Files Are Owned By Appropriate Group
[ref] | The group-owner of all log files written by
rsyslog should be root .
These log files are determined by the second part of each Rule line in
/etc/rsyslog.conf and typically all appear in /var/log .
For each log file LOGFILE referenced in /etc/rsyslog.conf ,
run the following command to inspect the file's group owner:
$ ls -l LOGFILE
If the owner is not root ,
run the following command to
correct this:
$ sudo chgrp root LOGFILE
| Rationale: | The log files generated by rsyslog contain valuable information regarding system
configuration, user authentication, and other such information. Log files should be
protected from unauthorized access. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_files_groupownership | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | disa | CCI-001314 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | ism | 0988, 1405 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-10.5.1, Req-10.5.2 | anssi | R71 | cis | 5.1.3 | pcidss4 | 10.3.2, 10.3 |
| |
|
Rule
Ensure Log Files Are Owned By Appropriate User
[ref] | The owner of all log files written by
rsyslog should be
root .
These log files are determined by the second part of each Rule line in
/etc/rsyslog.conf and typically all appear in /var/log .
For each log file LOGFILE referenced in /etc/rsyslog.conf ,
run the following command to inspect the file's owner:
$ ls -l LOGFILE
If the owner is not
root ,
run the following command to
correct this:
$ sudo chown root LOGFILE
| Rationale: | The log files generated by rsyslog contain valuable information regarding system
configuration, user authentication, and other such information. Log files should be
protected from unauthorized access. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_files_ownership | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | disa | CCI-001314 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | ism | 0988, 1405 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-10.5.1, Req-10.5.2 | anssi | R71 | cis | 5.1.3 | pcidss4 | 10.3.2, 10.3 |
| |
|
Rule
Ensure System Log Files Have Correct Permissions
[ref] | The file permissions for all log files written by rsyslog should
be set to 640, or more restrictive. These log files are determined by the
second part of each Rule line in /etc/rsyslog.conf and typically
all appear in /var/log . For each log file LOGFILE
referenced in /etc/rsyslog.conf , run the following command to
inspect the file's permissions:
$ ls -l LOGFILE
If the permissions are not 640 or more restrictive, run the following
command to correct this:
$ sudo chmod 640 LOGFILE
" | Rationale: | Log files can contain valuable information regarding system
configuration. If the system log files are not protected unauthorized
users could change the logged data, eliminating their forensic value. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_files_permissions | References: | disa | CCI-001314 | ism | 0988, 1405 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | pcidss | Req-10.5.1, Req-10.5.2 | anssi | R71 | cis | 5.1.3 | pcidss4 | 10.3.1, 10.3 |
| |
|
Group
systemd-journald
Group contains 5 rules |
[ref]
systemd-journald is a system service that collects and stores
logging data. It creates and maintains structured, indexed
journals based on logging information that is received from a
variety of sources.
For more information on systemd-journald and additional systemd-journald configuration options, see
https://systemd.io/. |
Rule
Enable systemd-journald Service
[ref] | The systemd-journald service is an essential component of
systemd.
The systemd-journald service can be enabled with the following command:
$ sudo systemctl enable systemd-journald.service
| Rationale: | In the event of a system failure, Amazon Linux 2023 must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to system processes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_service_systemd-journald_enabled | References: | | |
|
Rule
Ensure journald is configured to compress large log files
[ref] | The journald system can compress large log files to avoid fill the system disk. | Rationale: | Log files that are not properly compressed run the risk of growing so large that they fill up the log partition. Valuable logging information could be lost if the log partition becomes full. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_journald_compress | References: | | |
|
Rule
Ensure journald is configured to send logs to rsyslog
[ref] | Data from journald may be stored in volatile memory or persisted locally.
Utilities exist to accept remote export of journald logs. | Rationale: | Storing log data on a remote host protects log integrity from local attacks. If an attacker gains root access on the local system, they could tamper with or remove log data that is stored on the local system. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_journald_forward_to_syslog | References: | | |
|
Rule
Ensure journald is configured to write log files to persistent disk
[ref] | The journald system may store log files in volatile memory or locally on disk.
If the logs are only stored in volatile memory they will we lost upon reboot. | Rationale: | Log files contain valuable data and need to be persistent to aid in possible investigations. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_journald_storage | References: | | |
|
Rule
Disable systemd-journal-remote Socket
[ref] | Journald supports the ability to receive messages from remote hosts,
thus acting as a log server. Clients should not receive data from
other hosts.
NOTE:
The same package, systemd-journal-remote , is used for both sending
logs to remote hosts and receiving incoming logs.
With regards to receiving logs, there are two Systemd unit files;
systemd-journal-remote.socket and systemd-journal-remote.service. | Rationale: | If a client is configured to also receive data, thus turning it into
a server, the client system is acting outside it's operational boundary. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_socket_systemd-journal-remote_disabled | References: | | |
|
Group
Configure rsyslogd to Accept Remote Messages If Acting as a Log Server
Group contains 1 rule |
[ref]
By default, rsyslog does not listen over the network
for log messages. If needed, modules can be enabled to allow
the rsyslog daemon to receive messages from other systems and for the system
thus to act as a log server.
If the system is not a log server, then lines concerning these modules
should remain commented out.
|
Rule
Ensure rsyslog Does Not Accept Remote Messages Unless Acting As Log Server
[ref] | The rsyslog daemon should not accept remote messages unless the system acts as a log
server. To ensure that it is not listening on the network, ensure any of the following lines
are not found in rsyslog configuration files.
If using legacy syntax:
$ModLoad imtcp
$InputTCPServerRun port
$ModLoad imudp
$UDPServerRun port
$ModLoad imrelp
$InputRELPServerRun port
If using RainerScript syntax:
module(load="imtcp")
module(load="imudp")
input(type="imtcp" port="514")
input(type="imudp" port="514")
| Rationale: | Any process which receives messages from the network incurs some risk of receiving malicious
messages. This risk can be eliminated for rsyslog by configuring it not to listen on the
network. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_nolisten | 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, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.07, DSS06.02, MEA02.01 | disa | CCI-000318, CCI-000366, CCI-000368, CCI-001812, CCI-001813, CCI-001814 | isa-62443-2009 | 4.2.3.4, 4.3.3.3.9, 4.3.3.4, 4.3.3.5.8, 4.3.4.3.2, 4.3.4.3.3, 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 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 | ism | 0988, 1405 | 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.5.1, A.12.6.2, 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.14.2.2, A.14.2.3, A.14.2.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | 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.IP-1, PR.PT-1, PR.PT-4 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 5.1.1.7 |
| |
|
Group
Rsyslog Logs Sent To Remote Host
Group contains 1 rule |
[ref]
If system logs are to be useful in detecting malicious
activities, it is necessary to send logs to a remote server. An
intruder who has compromised the root account on a system may
delete the log entries which indicate that the system was attacked
before they are seen by an administrator.
However, it is recommended that logs be stored on the local
host in addition to being sent to the loghost, especially if
rsyslog has been configured to use the UDP protocol to send
messages over a network. UDP does not guarantee reliable delivery,
and moderately busy sites will lose log messages occasionally,
especially in periods of high traffic which may be the result of an
attack. In addition, remote rsyslog messages are not
authenticated in any way by default, so it is easy for an attacker to
introduce spurious messages to the central log server. Also, some
problems cause loss of network connectivity, which will prevent the
sending of messages to the central server. For all of these reasons, it is
better to store log messages both centrally and on each host, so
that they can be correlated if necessary. |
Rule
Ensure Logs Sent To Remote Host
[ref] | To configure rsyslog to send logs to a remote log server,
open /etc/rsyslog.conf and read and understand the last section of the file,
which describes the multiple directives necessary to activate remote
logging.
Along with these other directives, the system can be configured
to forward its logs to a particular log server by
adding or correcting one of the following lines,
substituting logcollector appropriately.
The choice of protocol depends on the environment of the system;
although TCP and RELP provide more reliable message delivery,
they may not be supported in all environments.
To use UDP for log message delivery:
*.* @logcollector
To use TCP for log message delivery:
*.* @@logcollector
To use RELP for log message delivery:
*.* :omrelp:logcollector
There must be a resolvable DNS CNAME or Alias record set to " logcollector" for logs to be sent correctly to the centralized logging utility. Warning:
It is important to configure queues in case the client is sending log
messages to a remote server. If queues are not configured,
the system will stop functioning when the connection
to the remote server is not available. Please consult Rsyslog
documentation for more information about configuration of queues. The
example configuration which should go into /etc/rsyslog.conf
can look like the following lines:
$ActionQueueType LinkedList
$ActionQueueFileName queuefilename
$ActionQueueMaxDiskSpace 1g
$ActionQueueSaveOnShutdown on
$ActionResumeRetryCount -1
| Rationale: | A log server (loghost) receives syslog messages from one or more
systems. This data can be used as an additional log source in the event a
system is compromised and its local logs are suspect. Forwarding log messages
to a remote loghost also provides system administrators with a centralized
place to view the status of multiple hosts within the enterprise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_remote_loghost | References: | cis-csc | 1, 13, 14, 15, 16, 2, 3, 5, 6 | cobit5 | APO11.04, APO13.01, BAI03.05, BAI04.04, DSS05.04, DSS05.07, MEA02.01 | disa | CCI-000366, CCI-001348, CCI-000136, CCI-001851 | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(5)(ii)(B), 164.308(a)(5)(ii)(C), 164.308(a)(6)(ii), 164.308(a)(8), 164.310(d)(2)(iii), 164.312(b), 164.314(a)(2)(i)(C), 164.314(a)(2)(iii) | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 7.1, SR 7.2 | ism | 0988, 1405 | iso27001-2013 | A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.17.2.1 | nerc-cip | CIP-003-8 R5.2, CIP-004-6 R3.3 | nist | CM-6(a), AU-4(1), AU-9(2) | nist-csf | PR.DS-4, PR.PT-1 | ospp | FAU_GEN.1.1.c | os-srg | SRG-OS-000479-GPOS-00224, SRG-OS-000480-GPOS-00227, SRG-OS-000342-GPOS-00133 | anssi | R71 | cis | 5.1.1.6 |
| |
|
Rule
Ensure rsyslog is Installed
[ref] | Rsyslog is installed by default. The rsyslog package can be installed with the following command: $ sudo dnf install rsyslog
| Rationale: | The rsyslog package provides the rsyslog daemon, which provides
system logging services. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_rsyslog_installed | References: | cis-csc | 1, 14, 15, 16, 3, 5, 6 | cobit5 | APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01 | disa | CCI-001311, CCI-001312, CCI-000366 | hipaa | 164.312(a)(2)(ii) | isa-62443-2009 | 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9 | iso27001-2013 | A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1 | nist | CM-6(a) | nist-csf | PR.PT-1 | ospp | FTP_ITC_EXT.1.1 | os-srg | SRG-OS-000479-GPOS-00224, SRG-OS-000051-GPOS-00024, SRG-OS-000480-GPOS-00227 | cis | 5.1.1.1 |
| |
|
Rule
Ensure rsyslog Default File Permissions Configured
[ref] | rsyslog will create logfiles that do not already exist on the system.
This settings controls what permissions will be applied to these newly
created files. | Rationale: | It is important to ensure that log files have the correct permissions
to ensure that sensitive data is archived and protected. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_filecreatemode | References: | | |
|
Group
Network Configuration and Firewalls
Group contains 10 groups and 35 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
firewalld
Group contains 2 groups and 5 rules |
[ref]
The dynamic firewall daemon firewalld provides a
dynamically managed firewall with support for network “zones” to assign
a level of trust to a network and its associated connections and interfaces.
It has support for IPv4 and IPv6 firewall settings. It supports Ethernet
bridges and has a separation of runtime and permanent configuration options.
It also has an interface for services or applications to add firewall rules
directly.
A graphical configuration tool, firewall-config , is used to configure
firewalld , which in turn uses iptables tool to communicate
with Netfilter in the kernel which implements packet filtering.
The firewall service provided by firewalld is dynamic rather than
static because changes to the configuration can be made at anytime and are
immediately implemented. There is no need to save or apply the changes. No
unintended disruption of existing network connections occurs as no part of
the firewall has to be reloaded. |
Group
Inspect and Activate Default firewalld Rules
Group contains 2 rules |
[ref]
Firewalls can be used to separate networks into different zones
based on the level of trust the user has decided to place on the devices and
traffic within that network. NetworkManager informs firewalld to which
zone an interface belongs. An interface's assigned zone can be changed by
NetworkManager or via the firewall-config tool.
The zone settings in /etc/firewalld/ are a range of preset settings
which can be quickly applied to a network interface. These are the zones
provided by firewalld sorted according to the default trust level of the
zones from untrusted to trusted:
drop
Any incoming network packets are dropped, there is no
reply. Only outgoing network connections are possible. block
Any incoming network connections are rejected with an
icmp-host-prohibited message for IPv4 and icmp6-adm-prohibited
for IPv6. Only network connections initiated from within the system are
possible. public
For use in public areas. You do not trust the other
computers on the network to not harm your computer. Only selected incoming
connections are accepted. external
For use on external networks with masquerading enabled
especially for routers. You do not trust the other computers on the network to
not harm your computer. Only selected incoming connections are accepted. dmz
For computers in your demilitarized zone that are
publicly-accessible with limited access to your internal network. Only selected
incoming connections are accepted. work
For use in work areas. You mostly trust the other computers
on networks to not harm your computer. Only selected incoming connections are
accepted. home
For use in home areas. You mostly trust the other computers
on networks to not harm your computer. Only selected incoming connections are
accepted. internal
For use on internal networks. You mostly trust the
other computers on the networks to not harm your computer. Only selected
incoming connections are accepted. trusted
All network connections are accepted.
It is possible to designate one of these zones to be the default zone. When
interface connections are added to NetworkManager , they are assigned
to the default zone. On installation, the default zone in firewalld is set to
be the public zone.
To find out all the settings of a zone, for example the public zone,
enter the following command as root:
# firewall-cmd --zone=public --list-all
Example output of this command might look like the following:
# firewall-cmd --zone=public --list-all
public
interfaces:
services: mdns dhcpv6-client ssh
ports:
forward-ports:
icmp-blocks: source-quench
To view the network zones currently active, enter the following command as root:
# firewall-cmd --get-service
The following listing displays the result of this command
on common Amazon Linux 2023 system:
# firewall-cmd --get-service
amanda-client bacula bacula-client dhcp dhcpv6 dhcpv6-client dns ftp
high-availability http https imaps ipp ipp-client ipsec kerberos kpasswd
ldap ldaps libvirt libvirt-tls mdns mountd ms-wbt mysql nfs ntp openvpn
pmcd pmproxy pmwebapi pmwebapis pop3s postgresql proxy-dhcp radius rpc-bind
samba samba-client smtp ssh telnet tftp tftp-client transmission-client
vnc-server wbem-https
Finally to view the network zones that will be active after the next firewalld
service reload, enter the following command as root:
# firewall-cmd --get-service --permanent
|
Rule
Install firewalld Package
[ref] | The firewalld package can be installed with the following command:
$ sudo dnf install firewalld
| Rationale: | "Firewalld" provides an easy and effective way to block/limit remote access to the system via ports, services, and protocols.
Remote access services, such as those providing remote access to network devices and information systems, which lack automated control capabilities, increase risk and make remote user access management difficult at best.
Remote access is access to DoD nonpublic information systems by an authorized user (or an information system) communicating through an external, non-organization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless.
Amazon Linux 2023 functionality (e.g., SSH) must be capable of taking enforcement action if the audit reveals unauthorized activity.
Automated control of remote access sessions allows organizations to ensure ongoing compliance with remote access policies by enforcing connection rules of remote access applications on a variety of information system components (e.g., servers, workstations, notebook computers, smartphones, and tablets)." | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_firewalld_installed | References: | disa | CCI-002314 | nist | CM-6(a) | ospp | FMT_SMF_EXT.1 | os-srg | SRG-OS-000096-GPOS-00050, SRG-OS-000297-GPOS-00115, SRG-OS-000298-GPOS-00116, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00232 | cis | 3.4.1.2 | pcidss4 | 1.2.1, 1.2 |
| |
|
Rule
Verify firewalld Enabled
[ref] |
The firewalld service can be enabled with the following command:
$ sudo systemctl enable firewalld.service
| Rationale: | Access control methods provide the ability to enhance system security posture
by restricting services and known good IP addresses and address ranges. This
prevents connections from unknown hosts and protocols. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_service_firewalld_enabled | References: | cis-csc | 11, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05 | cui | 3.1.3, 3.4.7 | disa | CCI-000366, CCI-000382, CCI-002314 | 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 | nerc-cip | CIP-003-8 R4, CIP-003-8 R5, CIP-004-6 R3 | nist | AC-4, CM-7(b), CA-3(5), SC-7(21), CM-6(a) | nist-csf | PR.IP-1 | ospp | FMT_SMF_EXT.1 | os-srg | SRG-OS-000096-GPOS-00050, SRG-OS-000297-GPOS-00115, SRG-OS-000480-GPOS-00227, SRG-OS-000480-GPOS-00231, SRG-OS-000480-GPOS-00232 | cis | 3.4.1.2 | pcidss4 | 1.2.1, 1.2 |
| |
|
Group
Strengthen the Default Ruleset
Group contains 3 rules |
[ref]
The default rules can be strengthened. The system
scripts that activate the firewall rules expect them to be defined
in configuration files under the /etc/firewalld/services
and /etc/firewalld/zones directories.
The following recommendations describe how to strengthen the
default ruleset configuration file. An alternative to editing this
configuration file is to create a shell script that makes calls to
the firewall-cmd program to load in rules under the /etc/firewalld/services
and /etc/firewalld/zones directories.
Instructions apply to both unless otherwise noted. Language and address
conventions for regular firewalld rules are used throughout this section. Warning:
The program firewall-config
allows additional services to penetrate the default firewall rules
and automatically adjusts the firewalld ruleset(s). |
Rule
Configure Firewalld to Restrict Loopback Traffic
[ref] | Configure firewalld to restrict loopback traffic to the lo interface.
The loopback traffic must be trusted by assigning the lo interface to the
firewalld
trusted zone. However, the loopback traffic must be restricted
to the loopback interface as an anti-spoofing measure.
To configure firewalld to restrict loopback traffic to the lo interface,
run the following commands:
sudo firewall-cmd --permanent --zone=trusted --add-rich-rule='rule family=ipv4 source address="127.0.0.1" destination not address="127.0.0.1" drop'
sudo firewall-cmd --permanent --zone=trusted --add-rich-rule='rule family=ipv6 source address="::1" destination not address="::1" drop'
To ensure firewalld settings are applied in runtime, run the following command:
firewall-cmd --reload
| Rationale: | Loopback traffic is generated between processes on machine and is typically critical to
operation of the system. The loopback interface is the only place that loopback network
traffic should be seen, all other interfaces should ignore traffic on this network as an
anti-spoofing measure. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_firewalld_loopback_traffic_restricted | References: | | |
|
Rule
Configure Firewalld to Trust Loopback Traffic
[ref] | Assign loopback interface to the firewalld
trusted zone in order to
explicitly allow the loopback traffic in the system.
To configure firewalld to trust loopback traffic, run the following command:
sudo firewall-cmd --permanent --zone=trusted --add-interface=lo
To ensure firewalld settings are applied in runtime, run the following command:
firewall-cmd --reload
| Rationale: | Loopback traffic is generated between processes on machine and is typically critical to
operation of the system. The loopback interface is the only place that loopback network
traffic should be seen, all other interfaces should ignore traffic on this network as an
anti-spoofing measure. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_firewalld_loopback_traffic_trusted | References: | | |
|
Rule
Set Default firewalld Zone for Incoming Packets
[ref] | To set the default zone to drop for
the built-in default zone which processes incoming IPv4 and IPv6 packets,
modify the following line in
/etc/firewalld/firewalld.conf to be:
DefaultZone=drop
Warning:
To prevent denying any access to the system, automatic remediation
of this control is not available. Remediation must be automated as
a component of machine provisioning, or followed manually as outlined
above. | Rationale: | In firewalld the default zone is applied only after all
the applicable rules in the table are examined for a match. Setting the
default zone to drop implements proper design for a firewall, i.e.
any packets which are not explicitly permitted should not be
accepted. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_set_firewalld_default_zone | References: | cis-csc | 11, 14, 3, 9 | cjis | 5.10.1 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | cui | 3.1.3, 3.4.7, 3.13.6 | 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 | ism | 1416 | 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 | CA-3(5), CM-7(b), SC-7(23), CM-6(a) | nist-csf | PR.IP-1, PR.PT-3 | ospp | FMT_MOF_EXT.1 | pcidss | Req-1.4 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 3.4.2.1 | pcidss4 | 1.3.1, 1.3 |
| |
|
Group
IPv6
Group contains 1 group and 7 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 7 rules |
[ref]
A major feature of IPv6 is the extent to which systems
implementing it can automatically configure their networking
devices using information from the network. From a security
perspective, manually configuring important configuration
information is preferable to accepting it from the network
in an unauthenticated fashion. |
Rule
Configure Accepting Router Advertisements on All IPv6 Interfaces
[ref] | To set the runtime status of the net.ipv6.conf.all.accept_ra kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.all.accept_ra=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv6.conf.all.accept_ra = 0
| Rationale: | An illicit router advertisement message could result in a man-in-the-middle attack. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_ra | 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 | cis | 3.3.9 |
| |
|
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, CCI-001551 | 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 | cis | 3.3.2 |
| |
|
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 | cis | 3.3.1 |
| |
|
Rule
Disable Kernel Parameter for IPv6 Forwarding
[ref] | To set the runtime status of the net.ipv6.conf.all.forwarding kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.all.forwarding=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.forwarding = 0
| Rationale: | IP forwarding permits the kernel to forward packets from one network
interface to another. The ability to forward packets between two networks is
only appropriate for systems acting as routers. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_forwarding | 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 | 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), CM-6(b), CM-6.1(iv) | nist-csf | DE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 3.2.1 |
| |
|
Rule
Disable Accepting Router Advertisements on all IPv6 Interfaces by Default
[ref] | To set the runtime status of the net.ipv6.conf.default.accept_ra kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.default.accept_ra=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv6.conf.default.accept_ra = 0
| Rationale: | An illicit router advertisement message could result in a man-in-the-middle attack. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_ra | 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 | cis | 3.3.9 |
| |
|
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, CCI-001551 | 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 | cis | 3.3.2 |
| |
|
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 | cis | 3.3.1 | pcidss4 | 1.4.2, 1.4 |
| |
|
Group
Kernel Parameters Which Affect Networking
Group contains 2 groups and 16 rules |
[ref]
The sysctl utility is used to set
parameters which affect the operation of the Linux kernel. Kernel parameters
which affect networking and have security implications are described here. |
Group
Network Related Kernel Runtime Parameters for Hosts and Routers
Group contains 13 rules |
[ref]
Certain kernel parameters should be set for systems which are
acting as either hosts or routers to improve the system's ability defend
against certain types of IPv4 protocol attacks. |
Rule
Disable Accepting ICMP Redirects for All IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.accept_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.accept_redirects=0
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv4.conf.all.accept_redirects = 0
| Rationale: | ICMP redirect messages are used by routers to inform hosts that a more
direct route exists for a particular destination. These messages modify the
host's route table and are unauthenticated. An illicit ICMP redirect
message could result in a man-in-the-middle attack.
This feature of the IPv4 protocol has few legitimate uses. It should be
disabled unless absolutely required." | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_accept_redirects | 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, CCI-001503, CCI-001551 | 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 | cis | 3.3.2 |
| |
|
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 | cis | 3.3.1 |
| |
|
Rule
Enable Kernel Parameter to Log Martian Packets on all IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.log_martians kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.log_martians=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv4.conf.all.log_martians = 1
| Rationale: | The presence of "martian" packets (which have impossible addresses)
as well as spoofed packets, source-routed packets, and redirects could be a
sign of nefarious network activity. Logging these packets enables this activity
to be detected. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_log_martians | 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, DSS01.04, DSS03.05, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.06 | cui | 3.1.20 | disa | CCI-000126 | 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.11.2.6, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.2.1, A.6.2.2, A.9.1.2 | nist | CM-7(a), CM-7(b), SC-5(3)(a) | nist-csf | DE.CM-1, PR.AC-3, PR.DS-4, PR.IP-1, PR.PT-3, PR.PT-4 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 3.3.4 |
| |
|
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, CCI-001551 | 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 | cis | 3.3.7 | 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 | cis | 3.3.3 | pcidss4 | 1.4.3, 1.4 |
| |
|
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, 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 | cis | 3.3.2 | 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, 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 | cis | 3.3.1 |
| |
|
Rule
Enable Kernel Paremeter to Log Martian Packets on all IPv4 Interfaces by Default
[ref] | To set the runtime status of the net.ipv4.conf.default.log_martians kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.log_martians=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv4.conf.default.log_martians = 1
| Rationale: | The presence of "martian" packets (which have impossible addresses)
as well as spoofed packets, source-routed packets, and redirects could be a
sign of nefarious network activity. Logging these packets enables this activity
to be detected. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_log_martians | 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, DSS01.04, DSS03.05, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.06 | cui | 3.1.20 | disa | CCI-000126 | 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.11.2.6, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.2.1, A.6.2.2, A.9.1.2 | nist | CM-7(a), CM-7(b), SC-5(3)(a) | nist-csf | DE.CM-1, PR.AC-3, PR.DS-4, PR.IP-1, PR.PT-3, PR.PT-4 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 3.3.4 |
| |
|
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 | cis | 3.3.7 |
| |
|
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 | cis | 3.3.3 |
| |
|
Rule
Enable Kernel Parameter to Ignore ICMP Broadcast Echo Requests on IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.icmp_echo_ignore_broadcasts kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv4.icmp_echo_ignore_broadcasts = 1
| Rationale: | Responding to broadcast (ICMP) echoes facilitates network mapping
and provides a vector for amplification attacks.
Ignoring ICMP echo requests (pings) sent to broadcast or multicast
addresses makes the system slightly more difficult to enumerate on the network. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_icmp_echo_ignore_broadcasts | 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 | 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 | cis | 3.3.5 | pcidss4 | 1.4.2, 1.4 |
| |
|
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 | 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 | cis | 3.3.6 | pcidss4 | 1.4.2, 1.4 |
| |
|
Rule
Enable Kernel Parameter to Use TCP Syncookies on Network Interfaces
[ref] | To set the runtime status of the net.ipv4.tcp_syncookies kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.tcp_syncookies=1
To make sure that the setting is persistent, add the following line to a file in the directory /etc/sysctl.d : net.ipv4.tcp_syncookies = 1
| Rationale: | A TCP SYN flood attack can cause a denial of service by filling a
system's TCP connection table with connections in the SYN_RCVD state.
Syncookies can be used to track a connection when a subsequent ACK is received,
verifying the initiator is attempting a valid connection and is not a flood
source. This feature is activated when a flood condition is detected, and
enables the system to continue servicing valid connection requests. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_tcp_syncookies | 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-000366, CCI-001095 | 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 | cis | 3.3.8 | 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 | cis | 3.2.2 | 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 | cis | 3.2.2 | 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 | cis | 3.2.1 | 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
Install nftables Package
[ref] | nftables provides a new in-kernel packet classification framework that is based on a
network-specific Virtual Machine (VM) and a new nft userspace command line tool.
nftables reuses the existing Netfilter subsystems such as the existing hook infrastructure,
the connection tracking system, NAT, userspace queuing and logging subsystem.
The nftables package can be installed with the following command:
$ sudo dnf install nftables
| Rationale: | nftables is a subsystem of the Linux kernel that can protect against threats
originating from within a corporate network to include malicious mobile code and poorly
configured software on a host.
| Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_nftables_installed | References: | | |
|
Rule
Verify nftables Service is Disabled
[ref] | nftables is a subsystem of the Linux kernel providing filtering and classification of network
packets/datagrams/frames and is the successor to iptables.
The nftables service can be disabled with the following command:
systemctl disable nftables
| Rationale: | Running both firewalld and nftables may lead to conflict. nftables
is actually one of the backends for firewalld management tools. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_service_nftables_disabled | References: | | |
|
Rule
Ensure a Table Exists for Nftables
[ref] | Tables in nftables hold chains. Each table only has one address family and only applies
to packets of this family. Tables can have one of six families. Warning:
Adding or editing rules in a running nftables can cause loss of connectivity to the system. Warning:
Both the SCE check and remediation for this rule only consider runtime settings.
There is no specific file to check as it depends on each site's policy. Therefore, check
and remediation use the nft command directly. The fix is not persistent across system
reboots. Warning:
SCE check does not support variables, therefore the SCE check in this rule only checks the
address family, regardless of the table name. | Rationale: | Nftables doesn't have any default tables. Without a table being built, nftables will not
filter network traffic. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_set_nftables_table | References: | | |
|
Group
Uncommon Network Protocols
Group contains 4 rules |
[ref]
The system includes support for several network protocols which are not commonly used.
Although security vulnerabilities in kernel networking code are not frequently discovered,
the consequences can be dramatic. Ensuring uncommon network protocols are disabled
reduces the system's risk to attacks targeted at its implementation of those protocols. Warning:
Although these protocols are not commonly used, avoid disruption
in your network environment by ensuring they are not needed
prior to disabling them. |
Rule
Disable DCCP Support
[ref] | The Datagram Congestion Control Protocol (DCCP) is a
relatively new transport layer protocol, designed to support
streaming media and telephony.
To configure the system to prevent the dccp
kernel module from being loaded, add the following line to the file /etc/modprobe.d/dccp.conf :
install dccp /bin/false
| Rationale: | Disabling DCCP protects
the system against exploitation of any flaws in its implementation. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_dccp_disabled | References: | cis-csc | 11, 14, 3, 9 | cjis | 5.10.1 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | cui | 3.4.6 | disa | CCI-001958 | 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 | pcidss | Req-1.4.2 | os-srg | SRG-OS-000096-GPOS-00050, SRG-OS-000378-GPOS-00163 | cis | 3.1.2 | pcidss4 | 1.4.2, 1.4 |
| |
|
Rule
Disable RDS Support
[ref] | The Reliable Datagram Sockets (RDS) protocol is a transport
layer protocol designed to provide reliable high-bandwidth,
low-latency communications between nodes in a cluster.
To configure the system to prevent the rds
kernel module from being loaded, add the following line to the file /etc/modprobe.d/rds.conf :
install rds /bin/false
| Rationale: | Disabling RDS protects
the system against exploitation of any flaws in its implementation. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_rds_disabled | References: | cis-csc | 11, 14, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6 | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2 | nist | CM-7(a), CM-7(b), CM-6(a) | nist-csf | PR.IP-1, PR.PT-3 | cis | 3.1.4 |
| |
|
Rule
Disable SCTP Support
[ref] | The Stream Control Transmission Protocol (SCTP) is a
transport layer protocol, designed to support the idea of
message-oriented communication, with several streams of messages
within one connection.
To configure the system to prevent the sctp
kernel module from being loaded, add the following line to the file /etc/modprobe.d/sctp.conf :
install sctp /bin/false
| Rationale: | Disabling SCTP protects
the system against exploitation of any flaws in its implementation. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_sctp_disabled | References: | cis-csc | 11, 14, 3, 9 | cjis | 5.10.1 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | cui | 3.4.6 | disa | CCI-000381, 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 | pcidss | Req-1.4.2 | os-srg | SRG-OS-000095-GPOS-00049, SRG-OS-000480-GPOS-00227 | cis | 3.1.3 | pcidss4 | 1.4.2, 1.4 |
| |
|
Rule
Disable TIPC Support
[ref] | The Transparent Inter-Process Communication (TIPC) protocol
is designed to provide communications between nodes in a
cluster.
To configure the system to prevent the tipc
kernel module from being loaded, add the following line to the file /etc/modprobe.d/tipc.conf :
install tipc /bin/false
Warning:
This configuration baseline was created to deploy the base operating system for general purpose
workloads. When the operating system is configured for certain purposes, such as
a node in High Performance Computing cluster, it is expected that
the tipc kernel module will be loaded. | Rationale: | Disabling TIPC protects
the system against exploitation of any flaws in its implementation. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_tipc_disabled | References: | cis-csc | 11, 14, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | disa | 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 | ospp | FMT_SMF_EXT.1 | os-srg | SRG-OS-000095-GPOS-00049 | cis | 3.1.5 |
| |
|
Group
File Permissions and Masks
Group contains 8 groups and 62 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 Amazon Linux 2023
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 31 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 24 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 Backup 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 is a backup file of /etc/group , and as such,
it 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_backup_etc_group | References: | | |
|
Rule
Verify Group Who Owns Backup 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 is a backup of /etc/gshadow , and as such,
it contains group password hashes. Protection of this file is critical for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_backup_etc_gshadow | References: | | |
|
Rule
Verify Group Who Owns Backup 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 is a backup file of /etc/passwd , and as such,
it 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_backup_etc_passwd | References: | | |
|
Rule
Verify User Who Owns Backup 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 is a backup file of /etc/shadow , and as such,
it contains the list of local system accounts and password hashes.
Protection of this file is critical for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_backup_etc_shadow | References: | | |
|
Rule
Verify Group Who Owns group File
[ref] | To properly set the group owner of /etc/group , run the command: $ sudo chgrp root /etc/group
| Rationale: | The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_group | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-8.7.c | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R50 | cis | 6.1.4 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Group Who Owns gshadow File
[ref] | To properly set the group owner of /etc/gshadow , run the command: $ sudo chgrp root /etc/gshadow
| Rationale: | The /etc/gshadow file contains group password hashes. Protection of this file
is critical for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_gshadow | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R50 | cis | 6.1.8 |
| |
|
Rule
Verify Group Who Owns passwd File
[ref] | To properly set the group owner of /etc/passwd , run the command: $ sudo chgrp root /etc/passwd
| Rationale: | The /etc/passwd file contains information about the users that are configured on
the system. Protection of this file is critical for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_passwd | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-8.7.c | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R50 | cis | 6.1.1, 6.1.2 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Group Who Owns shadow File
[ref] | To properly set the group owner of /etc/shadow , run the command: $ sudo chgrp root /etc/shadow
| Rationale: | The /etc/shadow file stores password hashes. Protection of this file is
critical for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_shadow | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cjis | 5.5.2.2 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | pcidss | Req-8.7.c | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R50 | cis | 6.1.6 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify User Who Owns Backup group File
[ref] | To properly set the owner of /etc/group- , run the command: $ sudo chown root /etc/group-
| Rationale: | The /etc/group- file is a backup file of /etc/group , and as such,
it 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_backup_etc_group | References: | | |
|
Rule
Verify User Who Owns Backup gshadow File
[ref] | To properly set the owner of /etc/gshadow- , run the command: $ sudo chown root /etc/gshadow-
| Rationale: | The /etc/gshadow- file is a backup of /etc/gshadow , and as such,
it contains group password hashes. Protection of this file is critical for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_backup_etc_gshadow | References: | | |
|
Rule
Verify User Who Owns Backup passwd File
[ref] | To properly set the owner of /etc/passwd- , run the command: $ sudo chown root /etc/passwd-
| Rationale: | The /etc/passwd- file is a backup file of /etc/passwd , and as such,
it 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_backup_etc_passwd | References: | | |
|
Rule
Verify Group Who Owns Backup shadow File
[ref] | To properly set the owner of /etc/shadow- , run the command: $ sudo chown root /etc/shadow-
| Rationale: | The /etc/shadow- file is a backup file of /etc/shadow , and as such,
it contains the list of local system accounts and password hashes.
Protection of this file is critical for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_backup_etc_shadow | 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-002223 | 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 | cis | 6.1.4 | 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-002223 | 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 | cis | 6.1.8 |
| |
|
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-002223 | 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 | cis | 6.1.1, 6.1.2 | 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-002223 | 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 | cis | 6.1.6 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Permissions on Backup group File
[ref] |
To properly set the permissions of /etc/group- , run the command:
$ sudo chmod 0644 /etc/group-
| Rationale: | The /etc/group- file is a backup file of /etc/group , and as such,
it 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_backup_etc_group | References: | | |
|
Rule
Verify Permissions on Backup gshadow File
[ref] |
To properly set the permissions of /etc/gshadow- , run the command:
$ sudo chmod 0000 /etc/gshadow-
| Rationale: | The /etc/gshadow- file is a backup of /etc/gshadow , and as such,
it contains group password hashes. Protection of this file is critical for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_backup_etc_gshadow | References: | | |
|
Rule
Verify Permissions on Backup passwd File
[ref] |
To properly set the permissions of /etc/passwd- , run the command:
$ sudo chmod 0644 /etc/passwd-
| Rationale: | The /etc/passwd- file is a backup file of /etc/passwd , and as such,
it 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_permissions_backup_etc_passwd | References: | | |
|
Rule
Verify Permissions on Backup shadow File
[ref] |
To properly set the permissions of /etc/shadow- , run the command:
$ sudo chmod 0000 /etc/shadow-
| Rationale: | The /etc/shadow- file is a backup file of /etc/shadow , and as such,
it contains the list of local system accounts and password hashes.
Protection of this file is critical for system security. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_backup_etc_shadow | 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-002223 | 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 | cis | 6.1.4 | 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-002223 | 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 | cis | 6.1.8 |
| |
|
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-002223 | 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 | cis | 6.1.1, 6.1.2 | 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-002223 | 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 | cis | 6.1.6 | pcidss4 | 2.2.6, 2.2 |
| |
|
Group
Verify File Permissions Within Some Important Directories
Group contains 3 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 that audit tools are owned by group root
[ref] | The Amazon Linux 2023 operating system audit tools must have the proper
ownership configured to protected against unauthorized access.
Verify it by running the following command:
$ stat -c "%n %G" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules
/sbin/auditctl root
/sbin/aureport root
/sbin/ausearch root
/sbin/autrace root
/sbin/auditd root
/sbin/audispd root
/sbin/augenrules root
Audit tools needed to successfully view and manipulate audit information
system activity and records. Audit tools include custom queries and report
generators | Rationale: | Protecting audit information also includes identifying and protecting the
tools used to view and manipulate log data. Therefore, protecting audit
tools is necessary to prevent unauthorized operation on audit information.
Operating systems providing tools to interface with audit information
will leverage user permissions and roles identifying the user accessing the
tools and the corresponding rights the user enjoys to make access decisions
regarding the access to audit tools. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupownership_audit_binaries | References: | disa | CCI-001493, CCI-001494 | os-srg | SRG-OS-000256-GPiOS-00097, SRG-OS-000257-GPOS-00098 | cis | 5.2.4.10 |
| |
|
Rule
Verify that audit tools are owned by root
[ref] | The Amazon Linux 2023 operating system audit tools must have the proper
ownership configured to protected against unauthorized access.
Verify it by running the following command:
$ stat -c "%n %U" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules
/sbin/auditctl root
/sbin/aureport root
/sbin/ausearch root
/sbin/autrace root
/sbin/auditd root
/sbin/audispd root
/sbin/augenrules root
Audit tools needed to successfully view and manipulate audit information
system activity and records. Audit tools include custom queries and report
generators | Rationale: | Protecting audit information also includes identifying and protecting the
tools used to view and manipulate log data. Therefore, protecting audit
tools is necessary to prevent unauthorized operation on audit information.
Operating systems providing tools to interface with audit information
will leverage user permissions and roles identifying the user accessing the
tools and the corresponding rights the user enjoys to make access decisions
regarding the access to audit tools. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_ownership_audit_binaries | References: | disa | CCI-001493, CCI-001494 | os-srg | SRG-OS-000256-GPiOS-00097, SRG-OS-000257-GPOS-00098 | cis | 5.2.4.9 |
| |
|
Rule
Verify that audit tools Have Mode 0755 or less
[ref] | The Amazon Linux 2023 operating system audit tools must have the proper
permissions configured to protected against unauthorized access.
Verify it by running the following command:
$ stat -c "%n %a" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/audispd /sbin/augenrules
/sbin/auditctl 755
/sbin/aureport 755
/sbin/ausearch 755
/sbin/autrace 755
/sbin/auditd 755
/sbin/audispd 755
/sbin/augenrules 755
Audit tools needed to successfully view and manipulate audit information
system activity and records. Audit tools include custom queries and report
generators | Rationale: | Protecting audit information also includes identifying and protecting the
tools used to view and manipulate log data. Therefore, protecting audit
tools is necessary to prevent unauthorized operation on audit information.
Operating systems providing tools to interface with audit information
will leverage user permissions and roles identifying the user accessing the
tools and the corresponding rights the user enjoys to make access decisions
regarding the access to audit tools. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_audit_binaries | References: | disa | CCI-001493, CCI-001494 | os-srg | SRG-OS-000256-GPOS-00097, SRG-OS-000257-GPOS-00098 | cis | 5.2.4.8 |
| |
|
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 | cis | 6.1.11 | pcidss4 | 2.2.6, 2.2 |
| |
|
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 | cis | 6.1.11 | 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 group present in /etc/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.
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 , 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, CCI-002165 | 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 | cis | 6.1.12 | 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, CCI-002165 | 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 | cis | 6.1.12 | pcidss4 | 2.2.6, 2.2 |
| |
|
Group
Restrict Dynamic Mounting and Unmounting of
Filesystems
Group contains 8 rules |
[ref]
Linux includes a number of facilities for the automated addition
and removal of filesystems on a running system. These facilities may be
necessary in many environments, but this capability also carries some risk -- whether direct
risk from allowing users to introduce arbitrary filesystems,
or risk that software flaws in the automated mount facility itself could
allow an attacker to compromise the system.
This command can be used to list the types of filesystems that are
available to the currently executing kernel:
$ find /lib/modules/`uname -r`/kernel/fs -type f -name '*.ko'
If these filesystems are not required then they can be explicitly disabled
in a configuratio file in /etc/modprobe.d . |
Rule
Disable Mounting of cramfs
[ref] |
To configure the system to prevent the cramfs
kernel module from being loaded, add the following line to the file /etc/modprobe.d/cramfs.conf :
install cramfs /bin/false
This effectively prevents usage of this uncommon filesystem.
The cramfs filesystem type is a compressed read-only
Linux filesystem embedded in small footprint systems. A
cramfs image can be used without having to first
decompress the image. | Rationale: | Removing support for unneeded filesystem types reduces the local attack surface
of the server. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_cramfs_disabled | References: | cis-csc | 11, 14, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | cui | 3.4.6 | disa | 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-000095-GPOS-00049 | cis | 1.1.1.3 |
| |
|
Rule
Disable Mounting of freevxfs
[ref] |
To configure the system to prevent the freevxfs
kernel module from being loaded, add the following line to the file /etc/modprobe.d/freevxfs.conf :
install freevxfs /bin/false
This effectively prevents usage of this uncommon filesystem. | Rationale: | Linux kernel modules which implement filesystems that are not needed by the
local system should be disabled. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_freevxfs_disabled | References: | cis-csc | 11, 14, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | cui | 3.4.6 | 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 | cis | 1.1.1.4 |
| |
|
Rule
Disable Mounting of hfs
[ref] |
To configure the system to prevent the hfs
kernel module from being loaded, add the following line to the file /etc/modprobe.d/hfs.conf :
install hfs /bin/false
This effectively prevents usage of this uncommon filesystem. | Rationale: | Linux kernel modules which implement filesystems that are not needed by the
local system should be disabled. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_hfs_disabled | References: | cis-csc | 11, 14, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | cui | 3.4.6 | 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 | cis | 1.1.1.6 |
| |
|
Rule
Disable Mounting of hfsplus
[ref] |
To configure the system to prevent the hfsplus
kernel module from being loaded, add the following line to the file /etc/modprobe.d/hfsplus.conf :
install hfsplus /bin/false
This effectively prevents usage of this uncommon filesystem. | Rationale: | Linux kernel modules which implement filesystems that are not needed by the
local system should be disabled. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_hfsplus_disabled | References: | cis-csc | 11, 14, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | cui | 3.4.6 | 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 | cis | 1.1.1.7 |
| |
|
Rule
Disable Mounting of jffs2
[ref] |
To configure the system to prevent the jffs2
kernel module from being loaded, add the following line to the file /etc/modprobe.d/jffs2.conf :
install jffs2 /bin/false
This effectively prevents usage of this uncommon filesystem. | Rationale: | Linux kernel modules which implement filesystems that are not needed by the
local system should be disabled. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_jffs2_disabled | References: | cis-csc | 11, 14, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | cui | 3.4.6 | 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 | cis | 1.1.1.5 |
| |
|
Rule
Disable Mounting of squashfs
[ref] |
To configure the system to prevent the squashfs
kernel module from being loaded, add the following line to the file /etc/modprobe.d/squashfs.conf :
install squashfs /bin/false
This effectively prevents usage of this uncommon filesystem.
The squashfs filesystem type is a compressed read-only Linux
filesystem embedded in small footprint systems (similar to
cramfs ). A squashfs image can be used without having
to first decompress the image. | Rationale: | Removing support for unneeded filesystem types reduces the local attack
surface of the system. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_squashfs_disabled | References: | cis-csc | 11, 14, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | cui | 3.4.6 | 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 | cis | 1.1.1.1 |
| |
|
Rule
Disable Mounting of udf
[ref] |
To configure the system to prevent the udf
kernel module from being loaded, add the following line to the file /etc/modprobe.d/udf.conf :
install udf /bin/false
This effectively prevents usage of this uncommon filesystem.
The udf filesystem type is the universal disk format
used to implement the ISO/IEC 13346 and ECMA-167 specifications.
This is an open vendor filesystem type for data storage on a broad
range of media. This filesystem type is neccessary to support
writing DVDs and newer optical disc formats. | Rationale: | Removing support for unneeded filesystem types reduces the local
attack surface of the system. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_udf_disabled | References: | cis-csc | 11, 14, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | cui | 3.4.6 | 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 | cis | 1.1.1.2 |
| |
|
Rule
Disable Modprobe Loading of USB Storage Driver
[ref] | To prevent USB storage devices from being used, configure the kernel module loading system
to prevent automatic loading of the USB storage driver.
To configure the system to prevent the usb-storage
kernel module from being loaded, add the following line to the file /etc/modprobe.d/usb-storage.conf :
install usb-storage /bin/false
This will prevent the modprobe program from loading the usb-storage
module, but will not prevent an administrator (or another program) from using the
insmod program to load the module manually. | Rationale: | USB storage devices such as thumb drives can be used to introduce
malicious software. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_usb-storage_disabled | References: | cis-csc | 1, 12, 15, 16, 5 | cobit5 | APO13.01, DSS01.04, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10 | cui | 3.1.21 | disa | CCI-000366, CCI-000778, CCI-001958 | hipaa | 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.310(d)(1), 164.310(d)(2), 164.312(a)(1), 164.312(a)(2)(iv), 164.312(b) | 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.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.6 | iso27001-2013 | A.11.2.6, A.13.1.1, A.13.2.1, A.18.1.4, A.6.2.1, A.6.2.2, 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-7(a), CM-7(b), CM-6(a), MP-7 | nist-csf | PR.AC-1, PR.AC-3, PR.AC-6, PR.AC-7 | os-srg | SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-00163, SRG-OS-000480-GPOS-00227 | app-srg-ctr | SRG-APP-000141-CTR-000315 | cis | 1.1.9 | pcidss4 | 3.4.2, 3.4 |
| |
|
Group
Restrict Partition Mount Options
Group contains 19 rules |
[ref]
System partitions can be mounted with certain options
that limit what files on those partitions can do. These options
are set in the /etc/fstab configuration file, and can be
used to make certain types of malicious behavior more difficult. |
Rule
Add nodev Option to /dev/shm
[ref] | The nodev mount option can be used to prevent creation of device
files in /dev/shm . Legitimate character and block devices should
not exist within temporary directories like /dev/shm .
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/dev/shm . | Rationale: | The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_dev_shm_nodev | 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 | cis | 1.1.8.2 |
| |
|
Rule
Add noexec Option to /dev/shm
[ref] | The noexec mount option can be used to prevent binaries
from being executed out of /dev/shm .
It can be dangerous to allow the execution of binaries
from world-writable temporary storage directories such as /dev/shm .
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/dev/shm . | Rationale: | Allowing users to execute binaries from world-writable directories
such as /dev/shm can expose the system to potential compromise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_dev_shm_noexec | 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 | cis | 1.1.8.3 |
| |
|
Rule
Add nosuid Option to /dev/shm
[ref] | The nosuid mount option can be used to prevent execution
of setuid programs in /dev/shm . The SUID and SGID permissions should not
be required in these world-writable directories.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/dev/shm . | Rationale: | The presence of SUID and SGID executables should be tightly controlled. Users
should not be able to execute SUID or SGID binaries from temporary storage partitions. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_dev_shm_nosuid | 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 | cis | 1.1.8.4 |
| |
|
Rule
Add nodev Option to /home
[ref] | The nodev mount option can be used to prevent device files from
being created in /home .
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
/home . | Rationale: | The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_home_nodev | 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 . | 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 | 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 | cis | 1.1.7.3 |
| |
|
Rule
Add nodev Option to /tmp
[ref] | The nodev mount option can be used to prevent device files from
being created in /tmp . Legitimate character and block devices
should not exist within temporary directories like /tmp .
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/tmp . | Rationale: | The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_tmp_nodev | 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 | cis | 1.1.2.2 |
| |
|
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 | cis | 1.1.2.3 |
| |
|
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 | cis | 1.1.2.4 |
| |
|
Rule
Add nodev Option to /var/log/audit
[ref] | The nodev mount option can be used to prevent device files from
being created in /var/log/audit .
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
/var/log/audit . | Rationale: | The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_var_log_audit_nodev | 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 | cis | 1.1.6.3 |
| |
|
Rule
Add noexec Option to /var/log/audit
[ref] | The noexec mount option can be used to prevent binaries
from being executed out of /var/log/audit .
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/log/audit . | Rationale: | Allowing users to execute binaries from directories containing audit log files
such as /var/log/audit 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_audit_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 | cis | 1.1.6.2 |
| |
|
Rule
Add nosuid Option to /var/log/audit
[ref] | The nosuid mount option can be used to prevent
execution of setuid programs in /var/log/audit . The SUID and SGID permissions
should not be required in directories containing audit log files.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/log/audit . | 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 audit log files. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_var_log_audit_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 | cis | 1.1.6.4 |
| |
|
Rule
Add nodev Option to /var/log
[ref] | The nodev mount option can be used to prevent device files from
being created in /var/log .
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
/var/log . | Rationale: | The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_var_log_nodev | 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 | cis | 1.1.5.2 |
| |
|
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 | cis | 1.1.5.3 |
| |
|
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 | cis | 1.1.5.4 |
| |
|
Rule
Add nodev Option to /var
[ref] | The nodev mount option can be used to prevent device files from
being created in /var .
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
/var . | Rationale: | The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_var_nodev | References: | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | CM-7(a), CM-7(b), CM-6(a), AC-6, AC-6(1), MP-7 | nist-csf | PR.IP-1, PR.PT-2, PR.PT-3 | os-srg | SRG-OS-000368-GPOS-00154 | cis | 1.1.3.2 |
| |
|
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 nodev Option to /var/tmp
[ref] | The nodev mount option can be used to prevent device files from
being created in /var/tmp . Legitimate character and block devices
should not exist within temporary directories like /var/tmp .
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/tmp . | Rationale: | The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_mount_option_var_tmp_nodev | 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 2 groups and 4 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 2 rules |
[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 dump backtraces
[ref] | The ProcessSizeMax option in [Coredump] section
of /etc/systemd/coredump.conf
specifies the maximum size in bytes of a core which will be processed.
Core dumps exceeding this size may be stored, but the backtrace will not
be generated. Warning:
If the /etc/systemd/coredump.conf file
does not already contain the [Coredump] section,
the value will not be configured correctly. | Rationale: | A core dump includes a memory image taken at the time the operating system
terminates an application. The memory image could contain sensitive data
and is generally useful only for developers or system operators trying to
debug problems.
Enabling core dumps on production systems is not recommended,
however there may be overriding operational requirements to enable advanced
debuging. Permitting temporary enablement of core dumps during such situations
should be reviewed through local needs and policy. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_coredump_disable_backtraces | References: | | |
|
Rule
Disable storing core dump
[ref] | The Storage option in [Coredump] sectionof /etc/systemd/coredump.conf
can be set to none to disable storing core dumps permanently. Warning:
If the /etc/systemd/coredump.conf file
does not already contain the [Coredump] section,
the value will not be configured correctly. | Rationale: | A core dump includes a memory image taken at the time the operating system
terminates an application. The memory image could contain sensitive data
and is generally useful only for developers or system operators trying to
debug problems. Enabling core dumps on production systems is not recommended,
however there may be overriding operational requirements to enable advanced
debuging. Permitting temporary enablement of core dumps during such situations
should be reviewed through local needs and policy. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_coredump_disable_storage | References: | | |
|
Group
Enable ExecShield
Group contains 1 rule |
[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
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 | cis | 1.5.1 | pcidss4 | 3.3.1.1, 3.3.1, 3.3 |
| |
|
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: | | |
|
Group
SELinux
Group contains 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 Amazon Linux 2023, 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 Amazon Linux 2023 system, unless that
system has unusual requirements which make a stronger policy
appropriate. |
Rule
Install libselinux Package
[ref] | The libselinux package can be installed with the following command:
$ sudo dnf install libselinux
| Rationale: | Security-enhanced Linux is a feature of the Linux kernel and a number of utilities
with enhanced security functionality designed to add mandatory access controls to Linux.
The libselinux package contains the core library of the Security-enhanced Linux system. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_package_libselinux_installed | References: | | |
|
Rule
Uninstall mcstrans Package
[ref] | The mcstransd daemon provides category label information
to client processes requesting information. The label translations are defined
in /etc/selinux/targeted/setrans.conf .
The mcstrans package can be removed with the following command:
$ sudo dnf erase mcstrans
| Rationale: | Since this service is not used very often, disable it to reduce the
amount of potentially vulnerable code running on the system. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_package_mcstrans_removed | References: | | |
|
Rule
Uninstall setroubleshoot Package
[ref] | The SETroubleshoot service notifies desktop users of SELinux
denials. The service provides information around configuration errors,
unauthorized intrusions, and other potential errors.
The setroubleshoot package can be removed with the following command:
$ sudo dnf erase setroubleshoot
| Rationale: | The SETroubleshoot service is an unnecessary daemon to
have running on a server, especially if
X Windows is removed or disabled. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_package_setroubleshoot_removed | References: | | |
|
Rule
Ensure SELinux Not Disabled in /etc/default/grub
[ref] | SELinux can be disabled at boot time by an argument in
/etc/default/grub .
Remove any instances of selinux=0 from the kernel arguments in that
file to prevent SELinux from being disabled at boot. | Rationale: | Disabling a major host protection feature, such as SELinux, at boot time prevents
it from confining system services at boot time. Further, it increases
the chances that it will remain off during system operation. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_enable_selinux | 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-000022, CCI-000032 | 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.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 | AC-3, AC-3(3)(a) | 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 | cis | 1.6.1.2 | pcidss4 | 1.2.6, 1.2 |
| |
|
Rule
Ensure No Daemons are Unconfined by SELinux
[ref] | Daemons for which the SELinux policy does not contain rules will inherit the
context of the parent process. Because daemons are launched during
startup and descend from the init process, they inherit the unconfined_service_t context.
To check for unconfined daemons, run the following command:
$ sudo ps -eZ | grep "unconfined_service_t"
It should produce no output in a well-configured system. Warning:
Automatic remediation of this control is not available. Remediation
can be achieved by amending SELinux policy or stopping the unconfined
daemons as outlined above. | Rationale: | Daemons which run with the unconfined_service_t context may cause AVC denials,
or allow privileges that the daemon does not require. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_selinux_confinement_of_daemons | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 3, 5, 6, 9 | cobit5 | APO01.06, APO11.04, BAI03.05, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, MEA02.01 | cui | 3.1.2, 3.1.5, 3.7.2 | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e) | isa-62443-2009 | 4.3.3.3.9, 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.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.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.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 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.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.5.1, A.12.6.2, A.12.7.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | 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-3(3)(a), AC-6 | nist-csf | PR.AC-4, PR.DS-5, PR.IP-1, PR.PT-1, PR.PT-3 | cis | 1.6.1.6 | pcidss4 | 1.2.6, 1.2 |
| |
|
Rule
Ensure SELinux is Not Disabled
[ref] | The SELinux state should be set to enforcing or permissive at system boot
time. In the file /etc/selinux/config , add or correct the following line to configure
the system to boot into enforcing or permissive mode:
SELINUX=enforcing
OR
SELINUX=permissive
Warning:
In case the SELinux is "disabled", the automated remediation will adopt a more
conservative approach and set it to "permissive" in order to avoid any system disruption
and give the administrator the opportunity to assess the impact and necessary efforts
before setting it to "enforcing", which is strongly recommended. | Rationale: | Running SELinux in disabled mode is strongly discouraged. It prevents enforcing the SELinux
controls without a system reboot. It also avoids labeling any persistent objects such as
files, making it difficult to enable SELinux in the future. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_selinux_not_disabled | References: | | |
|
Rule
Configure SELinux Policy
[ref] | The SELinux targeted policy is appropriate for
general-purpose desktops and servers, as well as systems in many other roles.
To configure the system to use this policy, add or correct the following line
in /etc/selinux/config :
SELINUXTYPE=targeted
Other policies, such as mls , provide additional security labeling
and greater confinement but are not compatible with many general-purpose
use cases. | Rationale: | Setting the SELinux policy to targeted or a more specialized policy
ensures the system will confine processes that are likely to be
targeted for exploitation, such as network or system services.
Note: During the development or debugging of SELinux modules, it is common to
temporarily place non-production systems in permissive mode. In such
temporary cases, SELinux policies should be developed, and once work
is completed, the system should be reconfigured to
targeted . | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_selinux_policytype | 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-002165, CCI-002696 | 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 | app-srg-ctr | SRG-APP-000233-CTR-000585 | anssi | R46, R64 | bsi | APP.4.4.A4, SYS.1.6.A3 | cis | 1.6.1.3 | pcidss4 | 1.2.6, 1.2 |
| |
|
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-001084, CCI-002165, CCI-002696 | 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 | cis | 1.6.1.5 | pcidss4 | 1.2.6, 1.2 |
| |
|
Group
Services
Group contains 41 groups and 82 rules |
[ref]
The best protection against vulnerable software is running less software. This section describes how to review
the software which Amazon Linux 2023 installs on a system and disable software which is not needed. It
then enumerates the software packages installed on a default Amazon Linux 2023 system and provides guidance about which
ones can be safely disabled.
Amazon Linux 2023 provides a convenient minimal install option that essentially installs the bare necessities for a functional
system. When building Amazon Linux 2023 systems, it is highly recommended to select the minimal packages and then build up
the system from there. |
Group
Avahi Server
Group contains 1 group and 1 rule |
[ref]
The Avahi daemon implements the DNS Service Discovery
and Multicast DNS protocols, which provide service and host
discovery on a network. It allows a system to automatically
identify resources on the network, such as printers or web servers.
This capability is also known as mDNSresponder and is a major part
of Zeroconf networking. |
Group
Disable Avahi Server if Possible
Group contains 1 rule |
[ref]
Because the Avahi daemon service keeps an open network
port, it is subject to network attacks.
Disabling it can reduce the system's vulnerability to such attacks. |
Rule
Uninstall avahi Server Package
[ref] | If the system does not need to have an Avahi server which implements
the DNS Service Discovery and Multicast DNS protocols,
the avahi-autoipd and avahi packages can be uninstalled. | Rationale: | Automatic discovery of network services is not normally required for
system functionality. It is recommended to remove this package to reduce
the potential attack surface. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_avahi_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 | cis | 2.2.2 |
| |
|
Group
Cron and At Daemons
Group contains 1 group and 28 rules |
[ref]
The cron and at services are used to allow commands to
be executed at a later time. The cron service is required by almost
all systems to perform necessary maintenance tasks, while at may or
may not be required on a given system. Both daemons should be
configured defensively. |
Group
Restrict at and cron to Authorized Users if Necessary
Group contains 9 rules |
[ref]
The /etc/cron.allow and /etc/at.allow files contain lists of
users who are allowed to use cron and at to delay execution of
processes. If these files exist and if the corresponding files
/etc/cron.deny and /etc/at.deny do not exist, then only users
listed in the relevant allow files can run the crontab and at commands
to submit jobs to be run at scheduled intervals. On many systems, only the
system administrator needs the ability to schedule jobs. Note that even if a
given user is not listed in cron.allow , cron jobs can still be run as
that user. The cron.allow file controls only administrative access
to the crontab command for scheduling and modifying cron jobs.
To restrict at and cron to only authorized users:
- Remove the
cron.deny file:$ sudo rm /etc/cron.deny
- Edit
/etc/cron.allow , adding one line for each user allowed to use
the crontab command to create cron jobs. - Remove the
at.deny file:$ sudo rm /etc/at.deny
- Edit
/etc/at.allow , adding one line for each user allowed to use
the at command to create at jobs.
|
Rule
Ensure that /etc/at.deny does not exist
[ref] | The file /etc/at.deny should not exist.
Use /etc/at.allow instead. | Rationale: | Access to at should be restricted.
It is easier to manage an allow list than a deny list. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_at_deny_not_exist | References: | | |
|
Rule
Ensure that /etc/cron.allow exists
[ref] | The file /etc/cron.allow should exist and should be used instead
of /etc/cron.deny . | Rationale: | Access to crontab should be restricted.
It is easier to manage an allow list than a deny list.
Therefore, /etc/cron.allow needs to be created and used instead of /etc/cron.deny .
Regardless of the existence of any of these files, the root administrative user is always allowed to setup a crontab. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_cron_allow_exists | References: | | |
|
Rule
Ensure that /etc/cron.deny does not exist
[ref] | The file /etc/cron.deny should not exist.
Use /etc/cron.allow instead. | Rationale: | Access to cron should be restricted.
It is easier to manage an allow list than a deny list. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_cron_deny_not_exist | References: | | |
|
Rule
Verify Group Who Owns /etc/at.allow file
[ref] | If /etc/at.allow exists, it must be group-owned by root .
To properly set the group owner of /etc/at.allow , run the command:
$ sudo chgrp root /etc/at.allow
| Rationale: | If the owner of the at.allow file is not set to root, the possibility exists for an
unauthorized user to view or edit sensitive information. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_at_allow | References: | | |
|
Rule
Verify Group Who Owns /etc/cron.allow file
[ref] | If /etc/cron.allow exists, it must be group-owned by root .
To properly set the group owner of /etc/cron.allow , run the command:
$ sudo chgrp root /etc/cron.allow
| Rationale: | If the owner of the cron.allow file is not set to root, the possibility exists for an
unauthorized user to view or edit sensitive information. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_cron_allow | 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 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.8 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify User Who Owns /etc/at.allow file
[ref] | If /etc/at.allow exists, it must be owned by root .
To properly set the owner of /etc/at.allow , run the command:
$ sudo chown root /etc/at.allow
| Rationale: | If the owner of the at.allow file is not set to root, the possibility exists for an
unauthorized user to view or edit sensitive information. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_at_allow | References: | | |
|
Rule
Verify User Who Owns /etc/cron.allow file
[ref] | If /etc/cron.allow exists, it must be owned by root .
To properly set the owner of /etc/cron.allow , run the command:
$ sudo chown root /etc/cron.allow
| Rationale: | If the owner of the cron.allow file is not set to root, the possibility exists for an
unauthorized user to view or edit sensitive information. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_cron_allow | 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 | nist | CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.8 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Permissions on /etc/at.allow file
[ref] | If /etc/at.allow exists, it must have permissions 0640
or more restrictive.
To properly set the permissions of /etc/at.allow , run the command:
$ sudo chmod 0640 /etc/at.allow
| Rationale: | If the permissions of the at.allow file are not set to 0640 or more restrictive,
the possibility exists for an unauthorized user to view or edit sensitive information. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_at_allow | References: | | |
|
Rule
Verify Permissions on /etc/cron.allow file
[ref] | If /etc/cron.allow exists, it must have permissions 0640
or more restrictive.
To properly set the permissions of /etc/cron.allow , run the command:
$ sudo chmod 0640 /etc/cron.allow
| Rationale: | If the permissions of the cron.allow file are not set to 0640 or more restrictive,
the possibility exists for an unauthorized user to view or edit sensitive information. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_cron_allow | References: | | |
|
Rule
Enable cron Service
[ref] | The crond service is used to execute commands at
preconfigured times. It is required by almost all systems to perform necessary
maintenance tasks, such as notifying root of system activity.
The crond service can be enabled with the following command:
$ sudo systemctl enable crond.service
| Rationale: | Due to its usage for maintenance and security-supporting tasks,
enabling the cron daemon is essential. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_service_crond_enabled | References: | cis-csc | 11, 14, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | 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 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-6(a) | nist-csf | PR.IP-1, PR.PT-3 | cis | 4.1.1 |
| |
|
Rule
Verify Group Who Owns cron.d
[ref] |
To properly set the group owner of /etc/cron.d , run the command:
$ sudo chgrp root /etc/cron.d
| 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_cron_d | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.7 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Group Who Owns cron.daily
[ref] |
To properly set the group owner of /etc/cron.daily , run the command:
$ sudo chgrp root /etc/cron.daily
| 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_cron_daily | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.4 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Group Who Owns cron.hourly
[ref] |
To properly set the group owner of /etc/cron.hourly , run the command:
$ sudo chgrp root /etc/cron.hourly
| 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_cron_hourly | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.3 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Group Who Owns cron.monthly
[ref] |
To properly set the group owner of /etc/cron.monthly , run the command:
$ sudo chgrp root /etc/cron.monthly
| 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_cron_monthly | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.6 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Group Who Owns cron.weekly
[ref] |
To properly set the group owner of /etc/cron.weekly , run the command:
$ sudo chgrp root /etc/cron.weekly
| 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_cron_weekly | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.5 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Group Who Owns Crontab
[ref] |
To properly set the group owner of /etc/crontab , run the command:
$ sudo chgrp root /etc/crontab
| 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_crontab | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.2 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Owner on cron.d
[ref] |
To properly set the owner of /etc/cron.d , run the command:
$ sudo chown root /etc/cron.d
| 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 user to prevent unauthorized changes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_cron_d | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.7 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Owner on cron.daily
[ref] |
To properly set the owner of /etc/cron.daily , run the command:
$ sudo chown root /etc/cron.daily
| 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 user to prevent unauthorized changes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_cron_daily | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.4 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Owner on cron.hourly
[ref] |
To properly set the owner of /etc/cron.hourly , run the command:
$ sudo chown root /etc/cron.hourly
| 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 user to prevent unauthorized changes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_cron_hourly | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.3 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Owner on cron.monthly
[ref] |
To properly set the owner of /etc/cron.monthly , run the command:
$ sudo chown root /etc/cron.monthly
| 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 user to prevent unauthorized changes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_cron_monthly | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.6 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Owner on cron.weekly
[ref] |
To properly set the owner of /etc/cron.weekly , run the command:
$ sudo chown root /etc/cron.weekly
| 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 user to prevent unauthorized changes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_cron_weekly | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.5 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Owner on crontab
[ref] |
To properly set the owner of /etc/crontab , run the command:
$ sudo chown root /etc/crontab
| 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 user to prevent unauthorized changes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_crontab | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.2 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Permissions on cron.d
[ref] |
To properly set the permissions of /etc/cron.d , run the command:
$ sudo chmod 0700 /etc/cron.d
| 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 have the
correct access rights to prevent unauthorized changes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_cron_d | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.7 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Permissions on cron.daily
[ref] |
To properly set the permissions of /etc/cron.daily , run the command:
$ sudo chmod 0700 /etc/cron.daily
| 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 have the
correct access rights to prevent unauthorized changes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_cron_daily | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.4 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Permissions on cron.hourly
[ref] |
To properly set the permissions of /etc/cron.hourly , run the command:
$ sudo chmod 0700 /etc/cron.hourly
| 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 have the
correct access rights to prevent unauthorized changes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_cron_hourly | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.3 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Permissions on cron.monthly
[ref] |
To properly set the permissions of /etc/cron.monthly , run the command:
$ sudo chmod 0700 /etc/cron.monthly
| 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 have the
correct access rights to prevent unauthorized changes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_cron_monthly | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.6 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Permissions on cron.weekly
[ref] |
To properly set the permissions of /etc/cron.weekly , run the command:
$ sudo chmod 0700 /etc/cron.weekly
| 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 have the
correct access rights to prevent unauthorized changes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_cron_weekly | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.5 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Verify Permissions on crontab
[ref] |
To properly set the permissions of /etc/crontab , run the command:
$ sudo chmod 0600 /etc/crontab
| 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 have the
correct access rights to prevent unauthorized changes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_crontab | 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 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.1.2 | pcidss4 | 2.2.6, 2.2 |
| |
|
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 package can be removed with the following command:
$ sudo dnf erase dhcp
| 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 | cis | 2.2.4 | pcidss4 | 2.2.4, 2.2 |
| |
|
Group
DNS Server
Group contains 1 group and 2 rules |
[ref]
Most organizations have an operational need to run at
least one nameserver. However, there are many common attacks
involving DNS server software, and this server software should
be disabled on any system
on which it is not needed. |
Group
Disable DNS Server
Group contains 1 rule |
[ref]
DNS software should be disabled on any systems which does not
need to be a nameserver. Note that the BIND DNS server software is
not installed on Amazon Linux 2023 by default. The remainder of this section
discusses secure configuration of systems which must be
nameservers. |
Rule
Uninstall bind Package
[ref] | The named service is provided by the bind package.
The bind package can be removed with the following command:
$ sudo dnf erase bind
| Rationale: | If there is no need to make DNS server software available,
removing it provides a safeguard against its activation. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_package_bind_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 | cis | 2.2.5 |
| |
|
Rule
Uninstall dnsmasq Package
[ref] | dnsmasq is a lightweight tool that provides DNS caching, DNS forwarding and
DHCP (Dynamic Host Configuration Protocol) services.
The dnsmasq package can be removed with the following command:
$ sudo dnf erase dnsmasq
| Rationale: | Unless a system is specifically designated to act as a DNS
caching, DNS forwarding and/or DHCP server, it is recommended that the
package be removed to reduce the potential attack surface. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_package_dnsmasq_removed | References: | | |
|
Group
FTP Server
Group contains 1 group and 2 rules |
[ref]
FTP is a common method for allowing remote access to
files. Like telnet, the FTP protocol is unencrypted, which means
that passwords and other data transmitted during the session can be
captured and that the session is vulnerable to hijacking.
Therefore, running the FTP server software is not recommended.
However, there are some FTP server configurations which may
be appropriate for some environments, particularly those which
allow only read-only anonymous access as a means of downloading
data available to the public. |
Group
Disable vsftpd if Possible
Group contains 1 rule |
[ref]
To minimize attack surface, disable vsftpd if at all
possible. |
Rule
Uninstall vsftpd Package
[ref] | The vsftpd package can be removed with the following command: $ sudo dnf erase vsftpd
| Rationale: | Removing the vsftpd package decreases the risk of its
accidental activation. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_package_vsftpd_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-000197, 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), IA-5(1)(c), IA-5(1).1(v), CM-7, CM-7.1(ii) | nist-csf | PR.IP-1, PR.PT-3 | os-srg | SRG-OS-000074-GPOS-00042, SRG-OS-000095-GPOS-00049, SRG-OS-000480-GPOS-00227 | cis | 2.2.6 |
| |
|
Rule
Remove ftp Package
[ref] | FTP (File Transfer Protocol) is a traditional and widely used standard tool for
transferring files between a server and clients over a network, especially where no
authentication is necessary (permits anonymous users to connect to a server).
The ftp package can be removed with the following command:
$ sudo dnf erase ftp
| Rationale: | FTP does not protect the confidentiality of data or authentication credentials. It
is recommended SFTP be used if file transfer is required. Unless there is a need
to run the system as a FTP server (for example, to allow anonymous downloads), it is
recommended that the package be removed to reduce the potential attack surface. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_package_ftp_removed | References: | | |
|
Group
Web Server
Group contains 2 groups and 2 rules |
[ref]
The web server is responsible for providing access to
content via the HTTP protocol. Web servers represent a significant
security risk because:
- The HTTP port is commonly probed by malicious sources
- Web server software is very complex, and includes a long
history of vulnerabilities
- The HTTP protocol is unencrypted and vulnerable to passive
monitoring
The system's default web server software is Apache 2 and is
provided in the RPM package httpd . |
Group
Disable Apache if Possible
Group contains 1 rule |
[ref]
If Apache was installed and activated, but the system
does not need to act as a web server, then it should be disabled
and removed from the system. |
Rule
Uninstall httpd Package
[ref] |
The httpd package can be removed with the following command:
$ sudo dnf erase httpd
| Rationale: | If there is no need to make the web server software available,
removing it provides a safeguard against its activation. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_package_httpd_removed | References: | cis-csc | 11, 14, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6 | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2 | nist | CM-7(a), CM-7(b), CM-6(a) | nist-csf | PR.IP-1, PR.PT-3 | cis | 2.2.8 |
| |
|
Group
Disable NGINX if Possible
Group contains 1 rule |
[ref]
If NGINX was installed and activated, but the system does not need to act as a web server,
then it should be removed from the system. |
Rule
Uninstall nginx Package
[ref] | The nginx package can be removed with the following command:
$ sudo dnf erase nginx
| Rationale: | If there is no need to make the web server software available,
removing it provides a safeguard against its activation. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_package_nginx_removed | References: | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6 | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2 | nist | CM-7(a), CM-7(b), CM-6(a) | nist-csf | PR.IP-1, PR.PT-3 | cis | 2.2.8 |
| |
|
Group
IMAP and POP3 Server
Group contains 2 groups and 2 rules |
[ref]
Dovecot provides IMAP and POP3 services. It is not
installed by default. The project page at
http://www.dovecot.org
contains more detailed information about Dovecot
configuration. |
Group
Disable Cyrus IMAP
Group contains 1 rule |
[ref]
If the system does not need to operate as an IMAP or
POP3 server, the Cyrus IMAP software should be removed. |
Rule
Uninstall cyrus-imapd Package
[ref] | The cyrus-imapd package can be removed with the following command:
$ sudo dnf erase cyrus-imapd
| Rationale: | If there is no need to make the cyrus-imapd software available,
removing it provides a safeguard against its activation. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_package_cyrus-imapd_removed | References: | | |
|
Group
Disable Dovecot
Group contains 1 rule |
[ref]
If the system does not need to operate as an IMAP or
POP3 server, the dovecot software should be disabled and removed. |
Rule
Uninstall dovecot Package
[ref] |
The dovecot package can be removed with the following command:
$ sudo dnf erase dovecot
| Rationale: | If there is no need to make the Dovecot software available,
removing it provides a safeguard against its activation. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_package_dovecot_removed | References: | | |
|
Group
LDAP
Group contains 1 group and 1 rule |
[ref]
LDAP is a popular directory service, that is, a
standardized way of looking up information from a central database.
Amazon Linux 2023 includes software that enables a system to act as both
an LDAP client and server. |
Group
Configure OpenLDAP Clients
Group contains 1 rule |
[ref]
This section provides information on which security settings are
important to configure in OpenLDAP clients by manually editing the appropriate
configuration files. Amazon Linux 2023 provides an automated configuration tool called
authconfig and a graphical wrapper for authconfig called
system-config-authentication . However, these tools do not provide as
much control over configuration as manual editing of configuration files. The
authconfig tools do not allow you to specify locations of SSL certificate
files, which is useful when trying to use SSL cleanly across several protocols.
Installation and configuration of OpenLDAP on Amazon Linux 2023 is available at Warning:
Before configuring any system to be an
LDAP client, ensure that a working LDAP server is present on the
network. |
Rule
Ensure LDAP client is not installed
[ref] | The Lightweight Directory Access Protocol (LDAP) is a service that provides
a method for looking up information from a central database.
The openldap-clients package can be removed with the following command:
$ sudo dnf erase openldap-clients
| Rationale: | If the system does not need to act as an LDAP client, it is recommended that the software is removed to reduce the potential attack surface. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_package_openldap-clients_removed | References: | | |
|
Group
Mail Server Software
Group contains 1 group and 2 rules |
[ref]
Mail servers are used to send and receive email over the network.
Mail is a very common service, and Mail Transfer Agents (MTAs) are obvious
targets of network attack.
Ensure that systems are not running MTAs unnecessarily,
and configure needed MTAs as defensively as possible.
Very few systems at any site should be configured to directly receive email over the
network. Users should instead use mail client programs to retrieve email
from a central server that supports protocols such as IMAP or POP3.
However, it is normal for most systems to be independently capable of sending email,
for instance so that cron jobs can report output to an administrator.
Most MTAs, including Postfix, support a submission-only mode in which mail can be sent from
the local system to a central site MTA (or directly delivered to a local account),
but the system still cannot receive mail directly over a network.
The alternatives program in Amazon Linux 2023 permits selection of other mail server software
(such as Sendmail), but Postfix is the default and is preferred.
Postfix was coded with security in mind and can also be more effectively contained by
SELinux as its modular design has resulted in separate processes performing specific actions.
More information is available on its website,
http://www.postfix.org. |
Group
Configure SMTP For Mail Clients
Group contains 1 rule |
[ref]
This section discusses settings for Postfix in a submission-only
e-mail configuration. |
Rule
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 | cis | 2.2.15 | pcidss4 | 1.4.2, 1.4 |
| |
|
Rule
Ensure Mail Transfer Agent is not Listening on any non-loopback Address
[ref] | Mail Transfer Agents (MTA), such as sendmail and Postfix, are used to
listen for incoming mail and transfer the messages to the appropriate
user or mail server. If the system is not intended to be a mail server,
it is recommended that the MTA be configured to only process local mail. | Rationale: | The software for all Mail Transfer Agents is complex and most have a
long history of security issues. While it is important to ensure that
the system can process local mail messages, it is not necessary to have
the MTA's daemon listening on a port unless the server is intended to
be a mail server that receives and processes mail from other systems. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_has_nonlocal_mta | References: | | |
|
Group
NFS and RPC
Group contains 4 groups and 2 rules |
[ref]
The Network File System is a popular distributed filesystem for
the Unix environment, and is very widely deployed. This section discusses the
circumstances under which it is possible to disable NFS and its dependencies,
and then details steps which should be taken to secure
NFS's configuration. This section is relevant to systems operating as NFS
clients, as well as to those operating as NFS servers. |
Group
Disable All NFS Services if Possible
Group contains 1 group and 1 rule |
[ref]
If there is not a reason for the system to operate as either an
NFS client or an NFS server, follow all instructions in this section to disable
subsystems required by NFS. Warning:
The steps in this section will prevent a system
from operating as either an NFS client or an NFS server. Only perform these
steps on systems which do not need NFS at all. |
Group
Disable Services Used Only by NFS
Group contains 1 rule |
[ref]
If NFS is not needed, disable the NFS client daemons nfslock, rpcgssd, and rpcidmapd.
All of these daemons run with elevated privileges, and many listen for network
connections. If they are not needed, they should be disabled to improve system
security posture. |
Rule
Disable rpcbind Service
[ref] | The rpcbind utility maps RPC services to the ports on which they listen.
RPC processes notify rpcbind when they start, registering the ports they
are listening on and the RPC program numbers they expect to serve. The
rpcbind service redirects the client to the proper port number so it can
communicate with the requested service. If the system does not require RPC
(such as for NFS servers) then this service should be disabled.
The rpcbind service can be disabled with the following command:
$ sudo systemctl mask --now rpcbind.service
| Rationale: | If the system does not require rpc based services, it is recommended that
rpcbind be disabled to reduce the attack surface. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_service_rpcbind_disabled | References: | | |
|
Group
Configure NFS Clients
Group contains 1 group and 1 rule |
[ref]
The steps in this section are appropriate for systems which operate as NFS clients. |
Group
Disable NFS Server Daemons
Group contains 1 rule |
[ref]
There is no need to run the NFS server daemons nfs and
rpcsvcgssd except on a small number of properly secured systems
designated as NFS servers. Ensure that these daemons are turned off on
clients. |
Rule
Disable Network File System (nfs)
[ref] | The Network File System (NFS) service allows remote hosts to mount
and interact with shared filesystems on the local system. If the local system
is not designated as a NFS server then this service should be disabled.
The nfs-server service can be disabled with the following command:
$ sudo systemctl mask --now nfs-server.service
| Rationale: | Unnecessary services should be disabled to decrease the attack surface of the system. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_service_nfs_disabled | References: | cis-csc | 11, 12, 14, 15, 16, 18, 3, 5 | cobit5 | DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.03, DSS06.06 | 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-7(a), CM-7(b), CM-6(a) | nist-csf | PR.AC-4, PR.AC-6, PR.PT-3 | cis | 2.2.16 |
| |
|
Group
Network Time Protocol
Group contains 2 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.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html
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
A remote time server for Chrony is configured
[ref] | Chrony is a daemon which implements the Network Time Protocol (NTP). It is designed
to synchronize system clocks across a variety of systems and use a source that is highly
accurate. More information on chrony can be found at
https://chrony-project.org/.
Chrony can be configured to be a client and/or a server.
Add or edit server or pool lines to /etc/chrony.conf as appropriate:
server <remote-server>
Multiple servers may be configured. | Rationale: | If chrony is in use on the system proper configuration is vital to ensuring time
synchronization is working properly. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_chronyd_specify_remote_server | References: | | |
|
Rule
Ensure that chronyd is running under chrony user account
[ref] | chrony is a daemon which implements the Network Time Protocol (NTP). It is designed to
synchronize system clocks across a variety of systems and use a source that is highly
accurate. More information on chrony can be found at
https://chrony-project.org/.
Chrony can be configured to be a client and/or a server.
To ensure that chronyd is running under chrony user account,
add or edit the
OPTIONS variable in /etc/sysconfig/chronyd to include -u chrony :
OPTIONS="-u chrony"
This recommendation only applies if chrony is in use on the system. | Rationale: | If chrony is in use on the system proper configuration is vital to ensuring time synchronization
is working properly. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_chronyd_run_as_chrony_user | References: | | |
|
Group
Obsolete Services
Group contains 3 groups and 5 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 Amazon Linux 2023
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 1 rule |
[ref]
The Berkeley r-commands are legacy services which
allow cleartext remote access and have an insecure trust
model. |
Rule
Remove Rsh Trust Files
[ref] | The files /etc/hosts.equiv and ~/.rhosts (in
each user's home directory) list remote hosts and users that are trusted by the
local system when using the rshd daemon.
To remove these files, run the following command to delete them from any
location:
$ sudo rm /etc/hosts.equiv
$ rm ~/.rhosts
| Rationale: | This action is only meaningful if .rhosts support is permitted
through PAM. Trust files are convenient, but when used in conjunction with
the R-services, they can allow unauthenticated access to a system. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_no_rsh_trust_files | 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-001436 | 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 | cis | 6.2.11 |
| |
|
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 dnf 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 | cis | 2.2.13 | 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 Amazon Linux 2023. | 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 | cis | 2.3.1 | pcidss4 | 2.2.4, 2.2 |
| |
|
Group
TFTP Server
Group contains 1 rule |
[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 dnf 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-000318, CCI-000366, CCI-000368, CCI-001812, CCI-001813, CCI-001814 | 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 | cis | 2.2.7 | pcidss4 | 2.2.4, 2.2 |
| |
|
Rule
Uninstall rsync Package
[ref] | The rsyncd service can be used to synchronize files between systems over network links.
The rsync package can be removed with the following command:
$ sudo dnf erase rsync
| Rationale: | The rsyncd service presents a security risk as it uses unencrypted protocols for
communication. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_rsync_removed | References: | | |
|
Group
Print Support
Group contains 1 rule |
[ref]
The Common Unix Printing System (CUPS) service provides both local
and network printing support. A system running the CUPS service can accept
print jobs from other systems, process them, and send them to the appropriate
printer. It also provides an interface for remote administration through a web
browser. The CUPS service is installed and activated by default. The project
homepage and more detailed documentation are available at
http://www.cups.org.
|
Rule
Uninstall CUPS Package
[ref] | The cups package can be removed with the following command:
$ sudo dnf erase cups
| Rationale: | If the system does not need to print jobs or accept print jobs from other systems, it is
recommended that CUPS be removed to reduce the potential attack surface. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_package_cups_removed | References: | cis-csc | 11, 14, 3, 9 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06 | isa-62443-2009 | 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3 | isa-62443-2013 | SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6 | iso27001-2013 | A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2 | nist | CM-7(a), CM-7(b), CM-6(a) | nist-csf | PR.IP-1, PR.PT-3 | cis | 2.2.3 |
| |
|
Group
Proxy Server
Group contains 1 group and 1 rule |
[ref]
A proxy server is a very desirable target for a
potential adversary because much (or all) sensitive data for a
given infrastructure may flow through it. Therefore, if one is
required, the system acting as a proxy server should be dedicated
to that purpose alone and be stored in a physically secure
location. The system's default proxy server software is Squid, and
provided in an RPM package of the same name. |
Group
Disable Squid if Possible
Group contains 1 rule |
[ref]
If Squid was installed and activated, but the system
does not need to act as a proxy server, then it should be disabled
and removed. |
Rule
Uninstall squid Package
[ref] | The squid package can be removed with the following command: $ sudo dnf erase squid
| Rationale: | If there is no need to make the proxy server software available,
removing it provides a safeguard against its activation. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_package_squid_removed | References: | | |
|
Group
Samba(SMB) Microsoft Windows File Sharing Server
Group contains 1 group and 1 rule |
[ref]
When properly configured, the Samba service allows
Linux systems to provide file and print sharing to Microsoft
Windows systems. There are two software packages that provide
Samba support. The first, samba-client , provides a series of
command line tools that enable a client system to access Samba
shares. The second, simply labeled samba , provides the Samba
service. It is this second package that allows a Linux system to
act as an Active Directory server, a domain controller, or as a
domain member. Only the samba-client package is installed by
default. |
Group
Disable Samba if Possible
Group contains 1 rule |
[ref]
Even after the Samba server package has been installed, it
will remain disabled. Do not enable this service unless it is
absolutely necessary to provide Microsoft Windows file and print
sharing functionality. |
Rule
Uninstall Samba Package
[ref] | The samba package can be removed with the following command: $ sudo dnf erase samba
| Rationale: | If there is no need to make the Samba software available,
removing it provides a safeguard against its activation. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_package_samba_removed | References: | | |
|
Group
SNMP Server
Group contains 1 group and 2 rules |
[ref]
The Simple Network Management Protocol allows
administrators to monitor the state of network devices, including
computers. Older versions of SNMP were well-known for weak
security, such as plaintext transmission of the community string
(used for authentication) and usage of easily-guessable
choices for the community string. |
Group
Disable SNMP Server if Possible
Group contains 2 rules |
[ref]
The system includes an SNMP daemon that allows for its remote
monitoring, though it not installed by default. If it was installed and
activated but is not needed, the software should be disabled and removed. |
Rule
Uninstall net-snmp Package
[ref] |
The net-snmp package provides the snmpd service.
The net-snmp package can be removed with the following command:
$ sudo dnf erase net-snmp
| Rationale: | If there is no need to run SNMP server software,
removing the package provides a safeguard against its
activation. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_package_net-snmp_removed | References: | | |
|
Rule
Disable snmpd Service
[ref] |
The snmpd service can be disabled with the following command:
$ sudo systemctl mask --now snmpd.service
| Rationale: | Running SNMP software provides a network-based avenue of attack, and
should be disabled if not needed. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_service_snmpd_disabled | References: | | |
|
Group
SSH Server
Group contains 1 group and 26 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 17 rules |
[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
Set SSH Client Alive Count Max
[ref] | The SSH server sends at most ClientAliveCountMax messages
during a SSH session and waits for a response from the SSH client.
The option ClientAliveInterval configures timeout after
each ClientAliveCountMax message. If the SSH server does not
receive a response from the client, then the connection is considered unresponsive
and terminated.
For SSH earlier than v8.2, a ClientAliveCountMax value of 0
causes a timeout precisely when the ClientAliveInterval is set.
Starting with v8.2, a value of 0 disables the timeout functionality
completely. If the option is set to a number greater than 0 , then
the session will be disconnected after
ClientAliveInterval * ClientAliveCountMax seconds without receiving
a keep alive message. | Rationale: | This ensures a user login will be terminated as soon as the ClientAliveInterval
is reached. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_set_keepalive | 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-000879, CCI-001133, CCI-002361 | 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.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 | 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 | pcidss | Req-8.1.8 | os-srg | SRG-OS-000163-GPOS-00072, SRG-OS-000279-GPOS-00109 | cis | 4.2.20 | pcidss4 | 8.2.8, 8.2 |
| |
|
Rule
Set SSH Client Alive Interval
[ref] | SSH allows administrators to set a network responsiveness timeout interval.
After this interval has passed, the unresponsive client will be automatically logged out.
To set this timeout interval, edit the following line in /etc/ssh/sshd_config as
follows:
ClientAliveInterval 900
The timeout interval is given in seconds. For example, have a timeout
of 10 minutes, set interval to 600.
If a shorter timeout has already been set for the login shell, that value will
preempt any SSH setting made in /etc/ssh/sshd_config . Keep in mind that
some processes may stop SSH from correctly detecting that the user is idle. Warning:
SSH disconnecting unresponsive clients will not have desired effect without also
configuring ClientAliveCountMax in the SSH service configuration. Warning:
Following conditions may prevent the SSH session to time out:
- Remote processes on the remote machine generates output. As the output has to be transferred over the network to the client, the timeout is reset every time such transfer happens.
- Any
scp or sftp activity by the same user to the host resets the timeout.
| Rationale: | Terminating an idle ssh 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_sshd_set_idle_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-000879, CCI-001133, CCI-002361 | 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 | pcidss | Req-8.1.8 | os-srg | SRG-OS-000126-GPOS-00066, SRG-OS-000163-GPOS-00072, SRG-OS-000279-GPOS-00109, SRG-OS-000395-GPOS-00175 | cis | 4.2.20 | pcidss4 | 8.2.8, 8.2 |
| |
|
Rule
Disable Host-Based Authentication
[ref] | SSH's cryptographic host-based authentication is
more secure than .rhosts authentication. However, it is
not recommended that hosts unilaterally trust one another, even
within an organization.
The default SSH configuration disables host-based authentication. The appropriate
configuration is used if no value is set for HostbasedAuthentication .
To explicitly disable host-based authentication, add or correct the
following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :
HostbasedAuthentication no
| Rationale: | SSH trust relationships mean a compromise on one host
can allow an attacker to move trivially to other hosts. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_disable_host_auth | References: | cis-csc | 11, 12, 14, 15, 16, 18, 3, 5, 9 | cjis | 5.5.6 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.03, DSS06.06 | cui | 3.1.12 | disa | CCI-000366 | 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, 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 | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | 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.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 | 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 | AC-3, AC-17(a), CM-7(a), CM-7(b), CM-6(a) | nist-csf | PR.AC-4, PR.AC-6, PR.IP-1, PR.PT-3 | ospp | FIA_UAU.1 | os-srg | SRG-OS-000480-GPOS-00229 | cis | 4.2.8 | pcidss4 | 8.3.1, 8.3 |
| |
|
Rule
Disable SSH Access via Empty Passwords
[ref] | Disallow SSH login with empty passwords.
The default SSH configuration disables logins with empty passwords. The appropriate
configuration is used if no value is set for PermitEmptyPasswords .
To explicitly disallow SSH login from accounts with empty passwords,
add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :
PermitEmptyPasswords no
Any accounts with empty passwords should be disabled immediately, and PAM configuration
should prevent users from being able to assign themselves empty passwords. | Rationale: | Configuring this setting for the SSH daemon provides additional assurance
that remote login via SSH will require a password, even in the event of
misconfiguration elsewhere. | Severity: | high | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_disable_empty_passwords | References: | cis-csc | 11, 12, 13, 14, 15, 16, 18, 3, 5, 9 | cjis | 5.5.6 | 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 | cui | 3.1.1, 3.1.5 | disa | CCI-000366, CCI-000766 | 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, 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 | AC-17(a), CM-7(a), CM-7(b), CM-6(a) | nist-csf | PR.AC-4, PR.AC-6, PR.DS-5, PR.IP-1, PR.PT-3 | ospp | FIA_UAU.1 | pcidss | Req-2.2.4 | os-srg | SRG-OS-000106-GPOS-00053, SRG-OS-000480-GPOS-00229, SRG-OS-000480-GPOS-00227 | cis | 4.2.9 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Disable SSH Support for .rhosts Files
[ref] | SSH can emulate the behavior of the obsolete rsh
command in allowing users to enable insecure access to their
accounts via .rhosts files.
The default SSH configuration disables support for .rhosts . The appropriate
configuration is used if no value is set for IgnoreRhosts .
To explicitly disable support for .rhosts files, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :
IgnoreRhosts yes
| Rationale: | SSH trust relationships mean a compromise on one host
can allow an attacker to move trivially to other hosts. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_disable_rhosts | References: | cis-csc | 11, 12, 14, 15, 16, 18, 3, 5, 9 | cjis | 5.5.6 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.03, DSS06.06 | cui | 3.1.12 | 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 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.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 | AC-17(a), CM-7(a), CM-7(b), CM-6(a) | nist-csf | PR.AC-4, PR.AC-6, PR.IP-1, PR.PT-3 | ospp | FIA_UAU.1 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 4.2.11 | pcidss4 | 2.2.6, 2.2 |
| |
|
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.d/00-complianceascode-hardening.conf :
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-000770 | 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 | cis | 4.2.7 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Disable SSH TCP Forwarding
[ref] | The AllowTcpForwarding parameter specifies whether TCP forwarding is permitted.
To disable TCP forwarding, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :
AllowTcpForwarding no
| Rationale: | Leaving port forwarding enabled can expose the organization to security risks and back-doors. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_disable_tcp_forwarding | References: | | |
|
Rule
Disable X11 Forwarding
[ref] | The X11Forwarding parameter provides the ability to tunnel X11 traffic
through the connection to enable remote graphic connections.
SSH has the capability to encrypt remote X11 connections when SSH's
X11Forwarding option is enabled.
The default SSH configuration disables X11Forwarding. The appropriate
configuration is used if no value is set for X11Forwarding .
To explicitly disable X11 Forwarding, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :
X11Forwarding no
| Rationale: | Disable X11 forwarding unless there is an operational requirement to use X11
applications directly. There is a small risk that the remote X11 servers of
users who are logged in via SSH with X11 forwarding could be compromised by
other users on the X11 server. Note that even if X11 forwarding is disabled,
users can always install their own forwarders. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_disable_x11_forwarding | References: | | |
|
Rule
Do Not Allow SSH Environment Options
[ref] | Ensure that users are not able to override environment variables of the SSH daemon.
The default SSH configuration disables environment processing. The appropriate
configuration is used if no value is set for PermitUserEnvironment .
To explicitly disable Environment options, add or correct the following
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :
PermitUserEnvironment no
| Rationale: | SSH environment options potentially allow users to bypass
access restriction in some configurations. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_do_not_permit_user_env | References: | cis-csc | 11, 3, 9 | cjis | 5.5.6 | cobit5 | BAI10.01, BAI10.02, BAI10.03, BAI10.05 | cui | 3.1.12 | disa | CCI-000366 | 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.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 | AC-17(a), CM-7(a), CM-7(b), CM-6(a) | nist-csf | PR.IP-1 | pcidss | Req-2.2.4 | os-srg | SRG-OS-000480-GPOS-00229 | cis | 4.2.10 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Enable PAM
[ref] | UsePAM Enables the Pluggable Authentication Module interface. If set to “yes” this will
enable PAM authentication using ChallengeResponseAuthentication and
PasswordAuthentication in addition to PAM account and session module processing for all
authentication types.
To enable PAM authentication, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :
UsePAM yes
| Rationale: | When UsePAM is set to yes, PAM runs through account and session types properly. This is
important if you want to restrict access to services based off of IP, time or other factors of
the account. Additionally, you can make sure users inherit certain environment variables
on login or disallow access to the server. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_enable_pam | References: | | |
|
Rule
Enable SSH Warning Banner
[ref] | To enable the warning banner and ensure it is consistent
across the system, add or correct the following line in
/etc/ssh/sshd_config :
Banner /etc/issue.net
Another section contains information on how to create an
appropriate system-wide warning banner. | Rationale: | The warning message reinforces policy awareness during the logon process and
facilitates possible legal action against attackers. Alternatively, systems
whose ownership should not be obvious should ensure usage of a banner that does
not provide easy attribution. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_enable_warning_banner_net | References: | cjis | 5.5.6 | cobit5 | DSS05.04, DSS05.10, DSS06.10 | cui | 3.1.9 | disa | CCI-000048, CCI-000050, CCI-001384, CCI-001385, CCI-001386, CCI-001387, CCI-001388 | 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.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 | nist | AC-8(a), AC-8(c), AC-17(a), CM-6(a) | nist-csf | PR.AC-7 | ospp | FTA_TAB.1 | os-srg | SRG-OS-000023-GPOS-00006, SRG-OS-000228-GPOS-00088 | cis | 4.2.15 |
| |
|
Rule
Limit Users' SSH Access
[ref] | By default, the SSH configuration allows any user with an account
to access the system. There are several options available to limit
which users and group can access the system via SSH. It is
recommended that at least one of the following options be leveraged:
- AllowUsers variable gives the system administrator the option of
allowing specific users to ssh into the system. The list consists of
space separated user names. Numeric user IDs are not recognized with
this variable. If a system administrator wants to restrict user
access further by specifically allowing a user's access only from a
particular host, the entry can be specified in the form of user@host.
- AllowGroups variable gives the system administrator the option of
allowing specific groups of users to ssh into the system. The list
consists of space separated group names. Numeric group IDs are not
recognized with this variable.
- DenyUsers variable gives the system administrator the option of
denying specific users to ssh into the system. The list consists of
space separated user names. Numeric user IDs are not recognized with
this variable. If a system administrator wants to restrict user
access further by specifically denying a user's access from a
particular host, the entry can be specified in the form of user@host.
- DenyGroups variable gives the system administrator the option of
denying specific groups of users to ssh into the system. The list
consists of space separated group names. Numeric group IDs are not
recognized with this variable. Warning:
Automated remediation is not available for this configuration check
because each system has unique user names and group names. | Rationale: | Specifying which accounts are allowed SSH access into the system reduces the
possibility of unauthorized access to the system. | Severity: | unknown | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_limit_user_access | 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.1.12 | 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 | 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 | AC-3, CM-6(a) | nist-csf | PR.AC-4, PR.AC-6, PR.PT-3 | pcidss | Req-2.2.4 | cis | 4.2.4 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Ensure SSH LoginGraceTime is configured
[ref] | The LoginGraceTime parameter to the SSH server specifies the time allowed for successful authentication to
the SSH server. The longer the Grace period is the more open unauthenticated connections
can exist. Like other session controls in this session the Grace Period should be limited to
appropriate limits to ensure the service is available for needed access. | Rationale: | Setting the LoginGraceTime parameter to a low number will minimize the risk of successful
brute force attacks to the SSH server. It will also limit the number of concurrent
unauthenticated connections. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_set_login_grace_time | References: | | |
|
Rule
Set SSH Daemon LogLevel to VERBOSE
[ref] | The VERBOSE parameter configures the SSH daemon to record login and logout activity.
To specify the log level in
SSH, add or correct the following line in
/etc/ssh/sshd_config.d/00-complianceascode-hardening.conf :
LogLevel VERBOSE
| Rationale: | SSH provides several logging levels with varying amounts of verbosity. DEBUG is specifically
not recommended other than strictly for debugging SSH communications since it provides
so much data that it is difficult to identify important security information. INFO or
VERBOSE level is the basic level that only records login activity of SSH users. In many
situations, such as Incident Response, it is important to determine when a particular user was active
on a system. The logout record can eliminate those users who disconnected, which helps narrow the
field. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_set_loglevel_verbose | References: | | |
|
Rule
Set SSH authentication attempt limit
[ref] | The MaxAuthTries parameter specifies the maximum number of authentication attempts
permitted per connection. Once the number of failures reaches half this value, additional failures are logged.
to set MaxAUthTries edit /etc/ssh/sshd_config as follows:
MaxAuthTries 4
| Rationale: | Setting the MaxAuthTries parameter to a low number will minimize the risk of successful
brute force attacks to the SSH server. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_set_max_auth_tries | References: | ism | 0421, 0422, 0431, 0974, 1173, 1401, 1504, 1505, 1546, 1557, 1558, 1559, 1560, 1561 | cis | 4.2.16 | pcidss4 | 2.2.6, 2.2 |
| |
|
Rule
Set SSH MaxSessions limit
[ref] | The MaxSessions parameter specifies the maximum number of open sessions permitted
from a given connection. To set MaxSessions edit
/etc/ssh/sshd_config as follows: MaxSessions 10
| Rationale: | To protect a system from denial of service due to a large number of concurrent
sessions, use the rate limiting function of MaxSessions to protect availability
of sshd logins and prevent overwhelming the daemon. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_set_max_sessions | References: | | |
|
Rule
Ensure SSH MaxStartups is configured
[ref] | The MaxStartups parameter specifies the maximum number of concurrent
unauthenticated connections to the SSH daemon. Additional connections will be
dropped until authentication succeeds or the LoginGraceTime expires for a
connection. To confgure MaxStartups, you should add or correct the following
line in the
/etc/ssh/sshd_config file:
MaxStartups 10:30:60
CIS recommends a MaxStartups value of '10:30:60', or more restrictive where
dictated by site policy. | Rationale: | To protect a system from denial of service due to a large number of pending
authentication connection attempts, use the rate limiting function of MaxStartups
to protect availability of sshd logins and prevent overwhelming the daemon. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_set_maxstartups | References: | | |
|
Rule
Verify Group Who Owns SSH Server config file
[ref] |
To properly set the group owner of /etc/ssh/sshd_config , run the command:
$ sudo chgrp root /etc/ssh/sshd_config
| Rationale: | Service configuration files enable or disable features of their respective
services that if configured incorrectly can lead to insecure and vulnerable
configurations. Therefore, service configuration files should be owned by the
correct group to prevent unauthorized changes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_sshd_config | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | AC-17(a), CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R50 | cis | 4.2.1 |
| |
|
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. | 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. | Rationale: | If a public host key file is modified by an unauthorized user, the SSH service
may be compromised. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupownership_sshd_pub_key | References: | | |
|
Rule
Verify Owner on SSH Server config file
[ref] |
To properly set the owner of /etc/ssh/sshd_config , run the command:
$ sudo chown root /etc/ssh/sshd_config
| Rationale: | Service configuration files enable or disable features of their respective
services that if configured incorrectly can lead to insecure and vulnerable
configurations. Therefore, service configuration files should be owned by the
correct group to prevent unauthorized changes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_sshd_config | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | AC-17(a), CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R50 | cis | 4.2.1 |
| |
|
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. | 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. | Rationale: | If a public host key file is modified by an unauthorized user, the SSH service
may be compromised. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_ownership_sshd_pub_key | References: | | |
|
Rule
Verify Permissions on SSH Server config file
[ref] |
To properly set the permissions of /etc/ssh/sshd_config , run the command:
$ sudo chmod 0600 /etc/ssh/sshd_config
| Rationale: | Service configuration files enable or disable features of their respective
services that if configured incorrectly can lead to insecure and vulnerable
configurations. Therefore, service configuration files should be owned by the
correct group to prevent unauthorized changes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_sshd_config | References: | cis-csc | 12, 13, 14, 15, 16, 18, 3, 5 | cobit5 | APO01.06, DSS05.04, DSS05.07, DSS06.02 | isa-62443-2009 | 4.3.3.7.3 | isa-62443-2013 | SR 2.1, SR 5.2 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-007-3 R2.1, CIP-007-3 R2.2, CIP-007-3 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.1, CIP-007-3 R5.1.2 | nist | AC-17(a), CM-6(a), AC-6(1) | nist-csf | PR.AC-4, PR.DS-5 | os-srg | SRG-OS-000480-GPOS-00227 | anssi | R50 | cis | 4.2.1 | 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. | 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 | cis | 4.2.2 | 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
| 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 | cis | 4.2.3 | pcidss4 | 2.2.6, 2.2 |
| |
|
Group
X Window System
Group contains 1 group and 1 rule |
[ref]
The X Window System implementation included with the
system is called X.org. |
Group
Disable X Windows
Group contains 1 rule |
[ref]
Unless there is a mission-critical reason for the
system to run a graphical user interface, ensure X is not set to start
automatically at boot and remove the X Windows software packages.
There is usually no reason to run X Windows
on a dedicated server system, as it increases the system's attack surface and consumes
system resources. Administrators of server systems should instead login via
SSH or on the text console. |
Rule
Remove the X Windows Package Group
[ref] | By removing the xorg-x11-server-common package, the system no longer has X Windows
installed. If X Windows is not installed then the system cannot boot into graphical user mode.
This prevents the system from being accidentally or maliciously booted into a graphical.target
mode. To do so, run the following command:
$ sudo dnf groupremove "X Window System"
$ sudo dnf remove xorg-x11-server-common
Warning:
The installation and use of a Graphical User Interface (GUI) increases your attack vector and decreases your
overall security posture. Removing the package xorg-x11-server-common package will remove the graphical target
which might bring your system to an inconsistent state requiring additional configuration to access the system
again. If a GUI is an operational requirement, a tailored profile that removes this rule should used before
continuing installation. | Rationale: | Unnecessary service packages must not be installed to decrease the attack surface of the system. X windows has a long history of security
vulnerabilities and should not be installed unless approved and documented. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_package_xorg-x11-server-common_removed | References: | cis-csc | 12, 15, 8 | cobit5 | APO13.01, DSS01.04, DSS05.02, DSS05.03 | disa | CCI-000366 | isa-62443-2009 | 4.3.3.6.6 | isa-62443-2013 | SR 1.13, SR 2.6, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.13.1.1, A.13.2.1, A.14.1.3, A.6.2.1, A.6.2.2 | nist | CM-7(a), CM-7(b), CM-6(a) | nist-csf | PR.AC-3, PR.PT-4 | os-srg | SRG-OS-000480-GPOS-00227 | cis | 2.2.1 |
| |
|
Group
System Accounting with auditd
Group contains 11 groups and 71 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 9 groups and 62 rules |
[ref]
The auditd program can perform comprehensive
monitoring of system activity. This section describes recommended
configuration settings for comprehensive auditing, but a full
description of the auditing system's capabilities is beyond the
scope of this guide. The mailing list linux-audit@redhat.com exists
to facilitate community discussion of the auditing system.
The audit subsystem supports extensive collection of events, including:
- Tracing of arbitrary system calls (identified by name or number)
on entry or exit.
- Filtering by PID, UID, call success, system call argument (with
some limitations), etc.
- Monitoring of specific files for modifications to the file's
contents or metadata.
Auditing rules at startup are controlled by the file /etc/audit/audit.rules .
Add rules to it to meet the auditing requirements for your organization.
Each line in /etc/audit/audit.rules represents a series of arguments
that can be passed to auditctl and can be individually tested
during runtime. See documentation in /usr/share/doc/audit-VERSION
and
in the related man pages for more details.
If copying any example audit rulesets from /usr/share/doc/audit-VERSION ,
be sure to comment out the
lines containing arch= which are not appropriate for your system's
architecture. Then review and understand the following rules,
ensuring rules are activated as needed for the appropriate
architecture.
After reviewing all the rules, reading the following sections, and
editing as needed, the new rules can be activated as follows:
$ sudo service auditd restart
|
Group
Record Events that Modify the System's Discretionary Access Controls
Group contains 13 rules |
[ref]
At a minimum, the audit system should collect file permission
changes for all users and root. Note that the "-F arch=b32" lines should be
present even on a 64 bit system. These commands identify system calls for
auditing. Even if the system is 64 bit it can still execute 32 bit system
calls. Additionally, these rules can be configured in a number of ways while
still achieving the desired effect. An example of this is that the "-S" calls
could be split up and placed on separate lines, however, this is less efficient.
Add the following to /etc/audit/audit.rules :
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b32 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If your system is 64 bit then these lines should be duplicated and the
arch=b32 replaced with arch=b64 as follows:
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
-a always,exit -F arch=b64 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
|
Rule
Record Events that Modify the System's Discretionary Access Controls - chmod
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured to
use the augenrules program to read audit rules during daemon startup
(the default), add the following line to a file with suffix .rules in
the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_chmod | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000126, CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.5.5 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203 | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255 | anssi | R73 | cis | 5.2.3.9 | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - chown
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured to
use the augenrules program to read audit rules during daemon startup
(the default), add the following line to a file with suffix .rules in
the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_chown | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000126, CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.5.5 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219 | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255 | anssi | R73 | cis | 5.2.3.9 | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - fchmod
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured to
use the augenrules program to read audit rules during daemon startup
(the default), add the following line to a file with suffix .rules in
the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchmod | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000126, CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.5.5 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203 | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255 | anssi | R73 | cis | 5.2.3.9 | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - fchmodat
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured to
use the augenrules program to read audit rules during daemon startup
(the default), add the following line to a file with suffix .rules in
the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchmodat | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000126, CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.5.5 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203 | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255 | anssi | R73 | cis | 5.2.3.9 | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - fchown
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchown | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000126, CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.5.5 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219 | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255 | anssi | R73 | cis | 5.2.3.9 | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - fchownat
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchownat | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000126, CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.5.5 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219 | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255 | anssi | R73 | cis | 5.2.3.9 | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - fremovexattr
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root.
If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fremovexattr | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.5.5 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219, SRG-OS-000466-GPOS-00210, SRG-OS-000468-GPOS-00212, SRG-OS-000064-GPOS-00033 | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000499-CTR-001255 | anssi | R73 | cis | 5.2.3.9 | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - fsetxattr
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fsetxattr | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000126, CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.5.5 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000466-GPOS-00210, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219, SRG-OS-000064-GPOS-00033 | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 | anssi | R73 | cis | 5.2.3.9 | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - lchown
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_lchown | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000126, CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.5.5 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000466-GPOS-00210, SRG-OS-000458-GPOS-00203, SRG-OS-000474-GPOS-00219 | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255 | anssi | R73 | cis | 5.2.3.9 | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - lremovexattr
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root.
If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_lremovexattr | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.5.5 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 | anssi | R73 | cis | 5.2.3.9 | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - lsetxattr
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_lsetxattr | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000126, CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.5.5 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000466-GPOS-00210, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219, SRG-OS-000064-GPOS-00033 | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 | anssi | R73 | cis | 5.2.3.9 | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - removexattr
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root.
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following line to a file with suffix .rules in the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_removexattr | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.5.5 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000458-GPOS-00203, SRG-OS-000462-GPOS-00206, SRG-OS-000463-GPOS-00207, SRG-OS-000468-GPOS-00212, SRG-OS-000471-GPOS-00215, SRG-OS-000474-GPOS-00219, SRG-OS-000466-GPOS-00210, SRG-OS-000064-GPOS-00033 | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 | anssi | R73 | cis | 5.2.3.9 | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Discretionary Access Controls - setxattr
[ref] | At a minimum, the audit system should collect file permission
changes for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following line to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=unset -F key=perm_mod
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | The changing of file permissions could indicate that a user is attempting to
gain access to information that would otherwise be disallowed. Auditing DAC modifications
can facilitate the identification of patterns of abuse among both authorized and
unauthorized users. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_setxattr | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000126, CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.5.5 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000466-GPOS-00210, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203 | app-srg-ctr | SRG-APP-000091-CTR-000160, SRG-APP-000492-CTR-001220, SRG-APP-000493-CTR-001225, SRG-APP-000494-CTR-001230, SRG-APP-000500-CTR-001260, SRG-APP-000507-CTR-001295, SRG-APP-000495-CTR-001235 | anssi | R73 | cis | 5.2.3.9 | pcidss4 | 10.3.4, 10.3 |
| |
|
Group
Record Execution Attempts to Run ACL Privileged Commands
Group contains 2 rules |
[ref]
At a minimum, the audit system should collect the execution of
ACL privileged commands for all users and root. |
Rule
Record Any Attempts to Run chacl
[ref] | At a minimum, the audit system should collect any execution attempt
of the chacl command for all users and root. If the auditd
daemon is configured to use the augenrules program to read audit rules
during daemon startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F path=/usr/bin/chacl -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 the following lines to
/etc/audit/audit.rules file:
-a always,exit -F path=/usr/bin/chacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
| Rationale: | Without generating audit records that are specific to the security and
mission needs of the organization, it would be difficult to establish,
correlate, and investigate the events relating to an incident or identify
those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_execution_chacl | References: | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-002884 | 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 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255 | cis | 5.2.3.17 |
| |
|
Rule
Record Any Attempts to Run setfacl
[ref] | At a minimum, the audit system should collect any execution attempt
of the setfacl command for all users and root. If the auditd
daemon is configured to use the augenrules program to read audit rules
during daemon startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F path=/usr/bin/setfacl -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 the following lines to
/etc/audit/audit.rules file:
-a always,exit -F path=/usr/bin/setfacl -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
| Rationale: | Without generating audit records that are specific to the security and
mission needs of the organization, it would be difficult to establish,
correlate, and investigate the events relating to an incident or identify
those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_execution_setfacl | References: | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-002884 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215 | app-srg-ctr | SRG-APP-000495-CTR-001235 | cis | 5.2.3.16 |
| |
|
Group
Record Execution Attempts to Run SELinux Privileged Commands
Group contains 1 rule |
[ref]
At a minimum, the audit system should collect the execution of
SELinux privileged commands for all users and root. |
Rule
Record Any Attempts to Run chcon
[ref] | At a minimum, the audit system should collect any execution attempt
of the chcon command for all users and root. If the auditd
daemon is configured to use the augenrules program to read audit rules
during daemon startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F path=/usr/bin/chcon -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 the following lines to
/etc/audit/audit.rules file:
-a always,exit -F path=/usr/bin/chcon -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_execution_chcon | 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-000130, CCI-000135, CCI-000169, CCI-000172, 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 | ospp | FAU_GEN.1.1.c | 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-000468-GPOS-00212, SRG-OS-000471-GPOS-00215, SRG-OS-000463-GPOS-00207, SRG-OS-000465-GPOS-00209 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 | cis | 5.2.3.15 |
| |
|
Group
Record File Deletion Events by User
Group contains 4 rules |
[ref]
At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d , setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=unset -F key=delete
|
Rule
Ensure auditd Collects File Deletion Events by User - rename
[ref] | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d , setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete
| Rationale: | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_rename | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-000366, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.4, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.1.1, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.MA-2, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.7 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00211, SRG-OS-000468-GPOS-00212 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 | anssi | R73 | cis | 5.2.3.13 | pcidss4 | 10.2.1.7, 10.2.1, 10.2 |
| |
|
Rule
Ensure auditd Collects File Deletion Events by User - renameat
[ref] | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d , setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete
| Rationale: | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_renameat | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-000366, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.4, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.1.1, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.MA-2, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.7 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00211, SRG-OS-000468-GPOS-00212 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 | anssi | R73 | cis | 5.2.3.13 | pcidss4 | 10.2.1.7, 10.2.1, 10.2 |
| |
|
Rule
Ensure auditd Collects File Deletion Events by User - unlink
[ref] | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d , setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete
| Rationale: | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_unlink | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-000366, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.4, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.1.1, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.MA-2, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.7 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00211, SRG-OS-000468-GPOS-00212 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 | anssi | R73 | cis | 5.2.3.13 | pcidss4 | 10.2.1.7, 10.2.1, 10.2 |
| |
|
Rule
Ensure auditd Collects File Deletion Events by User - unlinkat
[ref] | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d , setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete
| Rationale: | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_unlinkat | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-000366, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.4, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.1.1, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.MA-2, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.7 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00211, SRG-OS-000468-GPOS-00212 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000501-CTR-001265, SRG-APP-000502-CTR-001270 | anssi | R73 | cis | 5.2.3.13 | pcidss4 | 10.2.1.7, 10.2.1, 10.2 |
| |
|
Group
Record Unauthorized Access Attempts Events to Files (unsuccessful)
Group contains 5 rules |
[ref]
At a minimum, the audit system should collect unauthorized file
accesses for all users and root. Note that the "-F arch=b32" lines should be
present even on a 64 bit system. These commands identify system calls for
auditing. Even if the system is 64 bit it can still execute 32 bit system
calls. Additionally, these rules can be configured in a number of ways while
still achieving the desired effect. An example of this is that the "-S" calls
could be split up and placed on separate lines, however, this is less efficient.
Add the following to /etc/audit/audit.rules :
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If your system is 64 bit then these lines should be duplicated and the
arch=b32 replaced with arch=b64 as follows:
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
|
Rule
Record Unsuccessful Access Attempts to Files - creat
[ref] | At a minimum, the audit system should collect unauthorized file
accesses for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_creat | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.4, Req-10.2.1 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205 | app-srg-ctr | SRG-APP-000495-CTR-001235 | anssi | R73 | cis | 5.2.3.7 |
| |
|
Rule
Record Unsuccessful Access Attempts to Files - ftruncate
[ref] | At a minimum, the audit system should collect unauthorized file
accesses for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_ftruncate | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.4, Req-10.2.1 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205 | app-srg-ctr | SRG-APP-000495-CTR-001235 | anssi | R73 | cis | 5.2.3.7 |
| |
|
Rule
Record Unsuccessful Access Attempts to Files - open
[ref] | At a minimum, the audit system should collect unauthorized file
accesses for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_open | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.4, Req-10.2.1 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205 | app-srg-ctr | SRG-APP-000495-CTR-001235 | anssi | R73 | cis | 5.2.3.7 |
| |
|
Rule
Record Unsuccessful Access Attempts to Files - openat
[ref] | At a minimum, the audit system should collect unauthorized file
accesses for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_openat | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.4, Req-10.2.1 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205 | app-srg-ctr | SRG-APP-000495-CTR-001235 | anssi | R73 | cis | 5.2.3.7 |
| |
|
Rule
Record Unsuccessful Access Attempts to Files - truncate
[ref] | At a minimum, the audit system should collect unauthorized file
accesses for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S truncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S truncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | Rationale: | Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_truncate | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.4, Req-10.2.1 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205 | app-srg-ctr | SRG-APP-000495-CTR-001235 | anssi | R73 | cis | 5.2.3.7 |
| |
|
Group
Record Information on Kernel Modules Loading and Unloading
Group contains 5 rules |
[ref]
To capture kernel module loading and unloading events, use following lines, setting ARCH to
either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S init_module,delete_module -F key=modules
Place to add the lines depends on a way auditd daemon is configured. If it is configured
to use the augenrules program (the default), add the lines to a file with suffix
.rules in the directory /etc/audit/rules.d .
If the auditd daemon is configured to use the auditctl utility,
add the lines to file /etc/audit/audit.rules . |
Rule
Ensure auditd Collects Information on Kernel Module Unloading - create_module
[ref] | To capture kernel module unloading events, use following line, setting ARCH to
either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S create_module -F key=module-change
Place to add the line depends on a way auditd daemon is configured. If it is configured
to use the augenrules program (the default), add the line to a file with suffix
.rules in the directory /etc/audit/rules.d .
If the auditd daemon is configured to use the auditctl utility,
add the line to file /etc/audit/audit.rules . | Rationale: | The removal of kernel modules can be used to alter the behavior of
the kernel and potentially introduce malicious code into kernel space. It is important
to have an audit trail of modules that have been introduced into the kernel. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_create | References: | disa | CCI-000172 | os-srg | SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222 | cis | 5.2.3.19 |
| Remediation Shell script ⇲# Remediation is applicable only in certain platforms
if [ ! -f /.dockerenv ] && [ ! -f /run/.containerenv ] && rpm --quiet -q audit && { ! ( grep -q aarch64 /proc/sys/kernel/osrelease ); }; then
# First perform the remediation of the syscall rule
# Retrieve hardware architecture of the underlying system
# Note: 32-bit and 64-bit kernel syscall numbers not always line up =>
# it's required on a 64-bit system to check also for the presence
# of 32-bit's equivalent of the corresponding rule.
# (See `man 7 audit.rules` for details )
[ "$(getconf LONG_BIT)" = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64")
for ARCH in "${RULE_ARCHS[@]}"
do
ACTION_ARCH_FILTERS="-a always,exit -F arch=$ARCH"
OTHER_FILTERS=""
AUID_FILTERS=""
SYSCALL="create_module"
KEY="module-change"
SYSCALL_GROUPING=""
# Perform the remediation for both possible tools: 'auditctl' and 'augenrules'
unset syscall_a
unset syscall_grouping
unset syscall_string
unset syscall
unset file_to_edit
unset rule_to_edit
unset rule_syscalls_to_edit
unset other_string
unset auid_string
unset full_rule
# Load macro arguments into arrays
read -a syscall_a <<< $SYSCALL
read -a syscall_grouping <<< $SYSCALL_GROUPING
# Create a list of audit *.rules files that should be inspected for presence and correctness
# of a particular audit rule. The scheme is as follows:
#
# -----------------------------------------------------------------------------------------
# Tool used to load audit rules | Rule already defined | Audit rules file to inspect |
# -----------------------------------------------------------------------------------------
# auditctl | Doesn't matter | /etc/audit/audit.rules |
# -----------------------------------------------------------------------------------------
# augenrules | Yes | /etc/audit/rules.d/*.rules |
# augenrules | No | /etc/audit/rules.d/$key.rules |
# -----------------------------------------------------------------------------------------
#
files_to_inspect=()
# If audit tool is 'augenrules', then check if the audit rule is defined
# If rule is defined, add '/etc/audit/rules.d/*.rules' to the list for inspection
# If rule isn't defined yet, add '/etc/audit/rules.d/$key.rules' to the list for inspection
default_file="/etc/audit/rules.d/$KEY.rules"
# As other_filters may include paths, lets use a different delimiter for it
# The "F" script expression tells sed to print the filenames where the expressions matched
readarray -t files_to_inspect < <(sed -s -n -e "/^$ACTION_ARCH_FILTERS/!d" -e "\#$OTHER_FILTERS#!d" -e "/$AUID_FILTERS/!d" -e "F" /etc/audit/rules.d/*.rules)
# Case when particular rule isn't defined in /etc/audit/rules.d/*.rules yet
if [ ${#files_to_inspect[@]} -eq "0" ]
then
file_to_inspect="/etc/audit/rules.d/$KEY.rules"
files_to_inspect=("$file_to_inspect")
if [ ! -e "$file_to_inspect" ]
then
touch "$file_to_inspect"
chmod 0640 "$file_to_inspect"
fi
fi
# After converting to jinja, we cannot return; therefore we skip the rest of the macro if needed instead
skip=1
for audit_file in "${files_to_inspect[@]}"
do
# Filter existing $audit_file rules' definitions to select those that satisfy the rule pattern,
# i.e, collect rules that match:
# * the action, list and arch, (2-nd argument)
# * the other filters, (3-rd argument)
# * the auid filters, (4-rd argument)
readarray -t similar_rules < <(sed -e "/^$ACTION_ARCH_FILTERS/!d" -e "\#$OTHER_FILTERS#!d" -e "/$AUID_FILTERS/!d" "$audit_file")
candidate_rules=()
# Filter out rules that have more fields then required. This will remove rules more specific than the required scope
for s_rule in "${similar_rules[@]}"
do
# Strip all the options and fields we know of,
# than check if there was any field left over
extra_fields=$(sed -E -e "s/^$ACTION_ARCH_FILTERS//" -e "s#$OTHER_FILTERS##" -e "s/$AUID_FILTERS//" -e "s/((:?-S [[:alnum:],]+)+)//g" -e "s/-F key=\w+|-k \w+//"<<< "$s_rule")
grep -q -- "-F" <<< "$extra_fields" || candidate_rules+=("$s_rule")
done
if [[ ${#syscall_a[@]} -ge 1 ]]
then
# Check if the syscall we want is present in any of the similar existing rules
for rule in "${candidate_rules[@]}"
do
rule_syscalls=$(echo "$rule" | grep -o -P '(-S [\w,]+)+' | xargs)
all_syscalls_found=0
for syscall in "${syscall_a[@]}"
do
grep -q -- "\b${syscall}\b" <<< "$rule_syscalls" || {
# A syscall was not found in the candidate rule
all_syscalls_found=1
}
done
if [[ $all_syscalls_found -eq 0 ]]
then
# We found a rule with all the syscall(s) we want; skip rest of macro
skip=0
break
fi
# Check if this rule can be grouped with our target syscall and keep track of it
for syscall_g in "${syscall_grouping[@]}"
do
if grep -q -- "\b${syscall_g}\b" <<< "$rule_syscalls"
then
file_to_edit=${audit_file}
rule_to_edit=${rule}
rule_syscalls_to_edit=${rule_syscalls}
fi
done
done
else
# If there is any candidate rule, it is compliant; skip rest of macro
if [ "${#candidate_rules[@]}" -gt 0 ]
then
skip=0
fi
fi
if [ "$skip" -eq 0 ]; then
break
fi
done
if [ "$skip" -ne 0 ]; then
# We checked all rules that matched the expected resemblance pattern (action, arch & auid)
# At this point we know if we need to either append the $full_rule or group
# the syscall together with an exsiting rule
# Append the full_rule if it cannot be grouped to any other rule
if [ -z ${rule_to_edit+x} ]
then
# Build full_rule while avoid adding double spaces when other_filters is empty
if [ "${#syscall_a[@]}" -gt 0 ]
then
syscall_string=""
for syscall in "${syscall_a[@]}"
do
syscall_string+=" -S $syscall"
done
fi
other_string=$([[ $OTHER_FILTERS ]] && echo " $OTHER_FILTERS") || /bin/true
auid_string=$([[ $AUID_FILTERS ]] && echo " $AUID_FILTERS") || /bin/true
full_rule="$ACTION_ARCH_FILTERS${syscall_string}${other_string}${auid_string} -F key=$KEY" || /bin/true
echo "$full_rule" >> "$default_file"
chmod o-rwx ${default_file}
else
# Check if the syscalls are declared as a comma separated list or
# as multiple -S parameters
if grep -q -- "," <<< "${rule_syscalls_to_edit}"
then
delimiter=","
else
delimiter=" -S "
fi
new_grouped_syscalls="${rule_syscalls_to_edit}"
for syscall in "${syscall_a[@]}"
do
grep -q -- "\b${syscall}\b" <<< "${rule_syscalls_to_edit}" || {
# A syscall was not found in the candidate rule
new_grouped_syscalls+="${delimiter}${syscall}"
}
done
# Group the syscall in the rule
sed -i -e "\#${rule_to_edit}#s#${rule_syscalls_to_edit}#${new_grouped_syscalls}#" "$file_to_edit"
fi
fi
unset syscall_a
unset syscall_grouping
unset syscall_string
unset syscall
unset file_to_edit
unset rule_to_edit
unset rule_syscalls_to_edit
unset other_string
unset auid_string
unset full_rule
# Load macro arguments into arrays
read -a syscall_a <<< $SYSCALL
read -a syscall_grouping <<< $SYSCALL_GROUPING
# Create a list of audit *.rules files that should be inspected for presence and correctness
# of a particular audit rule. The scheme is as follows:
#
# -----------------------------------------------------------------------------------------
# Tool used to load audit rules | Rule already defined | Audit rules file to inspect |
# -----------------------------------------------------------------------------------------
# auditctl | Doesn't matter | /etc/audit/audit.rules |
# -----------------------------------------------------------------------------------------
# augenrules | Yes | /etc/audit/rules.d/*.rules |
# augenrules | No | /etc/audit/rules.d/$key.rules |
# -----------------------------------------------------------------------------------------
#
files_to_inspect=()
# If audit tool is 'auditctl', then add '/etc/audit/audit.rules'
# file to the list of files to be inspected
default_file="/etc/audit/audit.rules"
files_to_inspect+=('/etc/audit/audit.rules' )
# After converting to jinja, we cannot return; therefore we skip the rest of the macro if needed instead
skip=1
for audit_file in "${files_to_inspect[@]}"
do
# Filter existing $audit_file rules' definitions to select those that satisfy the rule pattern,
# i.e, collect rules that match:
# * the action, list and arch, (2-nd argument)
# * the other filters, (3-rd argument)
# * the auid filters, (4-rd argument)
readarray -t similar_rules < <(sed -e "/^$ACTION_ARCH_FILTERS/!d" -e "\#$OTHER_FILTERS#!d" -e "/$AUID_FILTERS/!d" "$audit_file")
candidate_rules=()
# Filter out rules that have more fields then required. This will remove rules more specific than the required scope
for s_rule in "${similar_rules[@]}"
do
# Strip all the options and fields we know of,
# than check if there was any field left over
extra_fields=$(sed -E -e "s/^$ACTION_ARCH_FILTERS//" -e "s#$OTHER_FILTERS##" -e "s/$AUID_FILTERS//" -e "s/((:?-S [[:alnum:],]+)+)//g" -e "s/-F key=\w+|-k \w+//"<<< "$s_rule")
grep -q -- "-F" <<< "$extra_fields" || candidate_rules+=("$s_rule")
done
if [[ ${#syscall_a[@]} -ge 1 ]]
then
# Check if the syscall we want is present in any of the similar existing rules
for rule in "${candidate_rules[@]}"
do
rule_syscalls=$(echo "$rule" | grep -o -P '(-S [\w,]+)+' | xargs)
all_syscalls_found=0
for syscall in "${syscall_a[@]}"
do
grep -q -- "\b${syscall}\b" <<< "$rule_syscalls" || {
# A syscall was not found in the candidate rule
all_syscalls_found=1
}
done
if [[ $all_syscalls_found -eq 0 ]]
then
# We found a rule with all the syscall(s) we want; skip rest of macro
skip=0
break
fi
# Check if this rule can be grouped with our target syscall and keep track of it
for syscall_g in "${syscall_grouping[@]}"
do
if grep -q -- "\b${syscall_g}\b" <<< "$rule_syscalls"
then
file_to_edit=${audit_file}
rule_to_edit=${rule}
rule_syscalls_to_edit=${rule_syscalls}
fi
done
done
else
# If there is any candidate rule, it is compliant; skip rest of macro
if [ "${#candidate_rules[@]}" -gt 0 ]
then
skip=0
fi
fi
if [ "$skip" -eq 0 ]; then
break
fi
done
if [ "$skip" -ne 0 ]; then
# We checked all rules that matched the expected resemblance pattern (action, arch & auid)
# At this point we know if we need to either append the $full_rule or group
# the syscall together with an exsiting rule
# Append the full_rule if it cannot be grouped to any other rule
if [ -z ${rule_to_edit+x} ]
then
# Build full_rule while avoid adding double spaces when other_filters is empty
if [ "${#syscall_a[@]}" -gt 0 ]
then
syscall_string=""
for syscall in "${syscall_a[@]}"
do
syscall_string+=" -S $syscall"
done
fi
other_string=$([[ $OTHER_FILTERS ]] && echo " $OTHER_FILTERS") || /bin/true
auid_string=$([[ $AUID_FILTERS ]] && echo " $AUID_FILTERS") || /bin/true
full_rule="$ACTION_ARCH_FILTERS${syscall_string}${other_string}${auid_string} -F key=$KEY" || /bin/true
echo "$full_rule" >> "$default_file"
chmod o-rwx ${default_file}
else
# Check if the syscalls are declared as a comma separated list or
# as multiple -S parameters
if grep -q -- "," <<< "${rule_syscalls_to_edit}"
then
delimiter=","
else
delimiter=" -S "
fi
new_grouped_syscalls="${rule_syscalls_to_edit}"
for syscall in "${syscall_a[@]}"
do
grep -q -- "\b${syscall}\b" <<< "${rule_syscalls_to_edit}" || {
# A syscall was not found in the candidate rule
new_grouped_syscalls+="${delimiter}${syscall}"
}
done
# Group the syscall in the rule
sed -i -e "\#${rule_to_edit}#s#${rule_syscalls_to_edit}#${new_grouped_syscalls}#" "$file_to_edit"
fi
fi
done
else
>&2 echo 'Remediation is not applicable, nothing was done'
fi
Remediation Ansible snippet ⇲Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
- name: Gather the package facts
package_facts:
manager: auto
tags:
- audit_rules_kernel_module_loading_create
- configure_strategy
- low_complexity
- low_disruption
- medium_severity
- no_reboot_needed
- name: Set architecture for audit finit_module tasks
set_fact:
audit_arch: b64
when:
- '"audit" in ansible_facts.packages'
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- not ( ansible_architecture == "aarch64" )
- ansible_architecture == "aarch64" or ansible_architecture == "ppc64" or ansible_architecture
== "ppc64le" or ansible_architecture == "s390x" or ansible_architecture == "x86_64"
tags:
- audit_rules_kernel_module_loading_create
- configure_strategy
- low_complexity
- low_disruption
- medium_severity
- no_reboot_needed
- name: Perform remediation of Audit rules for finit_module for 32bit platform
block:
- name: Declare list of syscalls
set_fact:
syscalls:
- create_module
syscall_grouping: []
- name: Check existence of create_module in /etc/audit/rules.d/
find:
paths: /etc/audit/rules.d
contains: -a always,exit -F arch=b32(( -S |,)\w+)*(( -S |,){{ item }})+(( -S
|,)\w+)* (-k\s+|-F\s+key=)\S+\s*$
patterns: '*.rules'
register: find_command
loop: '{{ (syscall_grouping + syscalls) | unique }}'
- name: Reset syscalls found per file
set_fact:
syscalls_per_file: {}
found_paths_dict: {}
- name: Declare syscalls found per file
set_fact: syscalls_per_file="{{ syscalls_per_file | combine( {item.files[0].path
:[item.item] + syscalls_per_file.get(item.files[0].path, []) } ) }}"
loop: '{{ find_command.results | selectattr(''matched'') | list }}'
- name: Declare files where syscalls were found
set_fact: found_paths="{{ find_command.results | map(attribute='files') | flatten
| map(attribute='path') | list }}"
- name: Count occurrences of syscalls in paths
set_fact: found_paths_dict="{{ found_paths_dict | combine({ item:1+found_paths_dict.get(item,
0) }) }}"
loop: '{{ find_command.results | map(attribute=''files'') | flatten | map(attribute=''path'')
| list }}'
- name: Get path with most syscalls
set_fact: audit_file="{{ (found_paths_dict | dict2items() | sort(attribute='value')
| last).key }}"
when: found_paths | length >= 1
- name: No file with syscall found, set path to /etc/audit/rules.d/module-change.rules
set_fact: audit_file="/etc/audit/rules.d/module-change.rules"
when: found_paths | length == 0
- name: Declare found syscalls
set_fact: syscalls_found="{{ find_command.results | selectattr('matched') | map(attribute='item')
| list }}"
- name: Declare missing syscalls
set_fact: missing_syscalls="{{ syscalls | difference(syscalls_found) }}"
- name: Replace the audit rule in {{ audit_file }}
lineinfile:
path: '{{ audit_file }}'
regexp: (-a always,exit -F arch=b32)(?=.*(?:(?:-S |,)(?:{{ syscalls_per_file[audit_file]
| join("|") }}))\b)((?:( -S |,)\w+)+)( (?:-k |-F key=)\w+)
line: \1\2\3{{ missing_syscalls | join("\3") }}\4
backrefs: true
state: present
when: syscalls_found | length > 0 and missing_syscalls | length > 0
- name: Add the audit rule to {{ audit_file }}
lineinfile:
path: '{{ audit_file }}'
line: -a always,exit -F arch=b32 -S {{ syscalls | join(',') }} -F key=module-change
create: true
mode: o-rwx
state: present
when: syscalls_found | length == 0
- name: Declare list of syscalls
set_fact:
syscalls:
- create_module
syscall_grouping: []
- name: Check existence of create_module in /etc/audit/audit.rules
find:
paths: /etc/audit
contains: -a always,exit -F arch=b32(( -S |,)\w+)*(( -S |,){{ item }})+(( -S
|,)\w+)* (-k\s+|-F\s+key=)\S+\s*$
patterns: audit.rules
register: find_command
loop: '{{ (syscall_grouping + syscalls) | unique }}'
- name: Set path to /etc/audit/audit.rules
set_fact: audit_file="/etc/audit/audit.rules"
- name: Declare found syscalls
set_fact: syscalls_found="{{ find_command.results | selectattr('matched') | map(attribute='item')
| list }}"
- name: Declare missing syscalls
set_fact: missing_syscalls="{{ syscalls | difference(syscalls_found) }}"
- name: Replace the audit rule in {{ audit_file }}
lineinfile:
path: '{{ audit_file }}'
regexp: (-a always,exit -F arch=b32)(?=.*(?:(?:-S |,)(?:{{ syscalls_found |
join("|") }}))\b)((?:( -S |,)\w+)+)( (?:-k |-F key=)\w+)
line: \1\2\3{{ missing_syscalls | join("\3") }}\4
backrefs: true
state: present
when: syscalls_found | length > 0 and missing_syscalls | length > 0
- name: Add the audit rule to {{ audit_file }}
lineinfile:
path: '{{ audit_file }}'
line: -a always,exit -F arch=b32 -S {{ syscalls | join(',') }} -F key=module-change
create: true
mode: o-rwx
state: present
when: syscalls_found | length == 0
when:
- '"audit" in ansible_facts.packages'
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- not ( ansible_architecture == "aarch64" )
tags:
- audit_rules_kernel_module_loading_create
- configure_strategy
- low_complexity
- low_disruption
- medium_severity
- no_reboot_needed
- name: Perform remediation of Audit rules for finit_module for 64bit platform
block:
- name: Declare list of syscalls
set_fact:
syscalls:
- create_module
syscall_grouping: []
- name: Check existence of create_module in /etc/audit/rules.d/
find:
paths: /etc/audit/rules.d
contains: -a always,exit -F arch=b64(( -S |,)\w+)*(( -S |,){{ item }})+(( -S
|,)\w+)* (-k\s+|-F\s+key=)\S+\s*$
patterns: '*.rules'
register: find_command
loop: '{{ (syscall_grouping + syscalls) | unique }}'
- name: Reset syscalls found per file
set_fact:
syscalls_per_file: {}
found_paths_dict: {}
- name: Declare syscalls found per file
set_fact: syscalls_per_file="{{ syscalls_per_file | combine( {item.files[0].path
:[item.item] + syscalls_per_file.get(item.files[0].path, []) } ) }}"
loop: '{{ find_command.results | selectattr(''matched'') | list }}'
- name: Declare files where syscalls were found
set_fact: found_paths="{{ find_command.results | map(attribute='files') | flatten
| map(attribute='path') | list }}"
- name: Count occurrences of syscalls in paths
set_fact: found_paths_dict="{{ found_paths_dict | combine({ item:1+found_paths_dict.get(item,
0) }) }}"
loop: '{{ find_command.results | map(attribute=''files'') | flatten | map(attribute=''path'')
| list }}'
- name: Get path with most syscalls
set_fact: audit_file="{{ (found_paths_dict | dict2items() | sort(attribute='value')
| last).key }}"
when: found_paths | length >= 1
- name: No file with syscall found, set path to /etc/audit/rules.d/module-change.rules
set_fact: audit_file="/etc/audit/rules.d/module-change.rules"
when: found_paths | length == 0
- name: Declare found syscalls
set_fact: syscalls_found="{{ find_command.results | selectattr('matched') | map(attribute='item')
| list }}"
- name: Declare missing syscalls
set_fact: missing_syscalls="{{ syscalls | difference(syscalls_found) }}"
- name: Replace the audit rule in {{ audit_file }}
lineinfile:
path: '{{ audit_file }}'
regexp: (-a always,exit -F arch=b64)(?=.*(?:(?:-S |,)(?:{{ syscalls_per_file[audit_file]
| join("|") }}))\b)((?:( -S |,)\w+)+)( (?:-k |-F key=)\w+)
line: \1\2\3{{ missing_syscalls | join("\3") }}\4
backrefs: true
state: present
when: syscalls_found | length > 0 and missing_syscalls | length > 0
- name: Add the audit rule to {{ audit_file }}
lineinfile:
path: '{{ audit_file }}'
line: -a always,exit -F arch=b64 -S {{ syscalls | join(',') }} -F key=module-change
create: true
mode: o-rwx
state: present
when: syscalls_found | length == 0
- name: Declare list of syscalls
set_fact:
syscalls:
- create_module
syscall_grouping: []
- name: Check existence of create_module in /etc/audit/audit.rules
find:
paths: /etc/audit
contains: -a always,exit -F arch=b64(( -S |,)\w+)*(( -S |,){{ item }})+(( -S
|,)\w+)* (-k\s+|-F\s+key=)\S+\s*$
patterns: audit.rules
register: find_command
loop: '{{ (syscall_grouping + syscalls) | unique }}'
- name: Set path to /etc/audit/audit.rules
set_fact: audit_file="/etc/audit/audit.rules"
- name: Declare found syscalls
set_fact: syscalls_found="{{ find_command.results | selectattr('matched') | map(attribute='item')
| list }}"
- name: Declare missing syscalls
set_fact: missing_syscalls="{{ syscalls | difference(syscalls_found) }}"
- name: Replace the audit rule in {{ audit_file }}
lineinfile:
path: '{{ audit_file }}'
regexp: (-a always,exit -F arch=b64)(?=.*(?:(?:-S |,)(?:{{ syscalls_found |
join("|") }}))\b)((?:( -S |,)\w+)+)( (?:-k |-F key=)\w+)
line: \1\2\3{{ missing_syscalls | join("\3") }}\4
backrefs: true
state: present
when: syscalls_found | length > 0 and missing_syscalls | length > 0
- name: Add the audit rule to {{ audit_file }}
lineinfile:
path: '{{ audit_file }}'
line: -a always,exit -F arch=b64 -S {{ syscalls | join(',') }} -F key=module-change
create: true
mode: o-rwx
state: present
when: syscalls_found | length == 0
when:
- '"audit" in ansible_facts.packages'
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- not ( ansible_architecture == "aarch64" )
- audit_arch == "b64"
tags:
- audit_rules_kernel_module_loading_create
- configure_strategy
- low_complexity
- low_disruption
- medium_severity
- no_reboot_needed
|
|
Rule
Ensure auditd Collects Information on Kernel Module Unloading - delete_module
[ref] | To capture kernel module unloading events, use following line, setting ARCH to
either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S delete_module -F key=modules
Place to add the line depends on a way auditd daemon is configured. If it is configured
to use the augenrules program (the default), add the line to a file with suffix
.rules in the directory /etc/audit/rules.d .
If the auditd daemon is configured to use the auditctl utility,
add the line to file /etc/audit/audit.rules . | Rationale: | The removal of kernel modules can be used to alter the behavior of
the kernel and potentially introduce malicious code into kernel space. It is important
to have an audit trail of modules that have been introduced into the kernel. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_delete | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.7 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000504-CTR-001280 | anssi | R73 | cis | 5.2.3.19 |
| |
|
Rule
Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module
[ref] | If the auditd daemon is configured to use the augenrules program
to read audit rules during daemon startup (the default), add the following lines to a file
with suffix .rules in the directory /etc/audit/rules.d to capture kernel module
loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system:
-a always,exit -F arch=ARCH -S finit_module -F key=modules
If the auditd daemon is configured to use the auditctl utility to read audit
rules during daemon startup, add the following lines to /etc/audit/audit.rules file
in order to capture kernel module loading and unloading events, setting ARCH to either b32 or
b64 as appropriate for your system:
-a always,exit -F arch=ARCH -S finit_module -F key=modules
| Rationale: | The addition/removal of kernel modules can be used to alter the behavior of
the kernel and potentially introduce malicious code into kernel space. It is important
to have an audit trail of modules that have been introduced into the kernel. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_finit | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.7 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000504-CTR-001280 | anssi | R73 | cis | 5.2.3.19 |
| |
|
Rule
Ensure auditd Collects Information on Kernel Module Loading - init_module
[ref] | To capture kernel module loading events, use following line, setting ARCH to
either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S init_module -F key=modules
Place to add the line depends on a way auditd daemon is configured. If it is configured
to use the augenrules program (the default), add the line to a file with suffix
.rules in the directory /etc/audit/rules.d .
If the auditd daemon is configured to use the auditctl utility,
add the line to file /etc/audit/audit.rules . | Rationale: | The addition of kernel modules can be used to alter the behavior of
the kernel and potentially introduce malicious code into kernel space. It is important
to have an audit trail of modules that have been introduced into the kernel. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_init | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.7 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000504-CTR-001280 | anssi | R73 | cis | 5.2.3.19 |
| |
|
Rule
Ensure auditd Collects Information on Kernel Module Loading and Unloading - query_module
[ref] | If the auditd daemon is configured to use the augenrules program
to read audit rules during daemon startup (the default), add the following lines to a file
with suffix .rules in the directory /etc/audit/rules.d to capture kernel module
loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system:
-a always,exit -F arch=ARCH -S query_module -F auid>=1000 -F auid!=unset -F key=modules
If the auditd daemon is configured to use the auditctl utility to read audit
rules during daemon startup, add the following lines to /etc/audit/audit.rules file
in order to capture kernel module loading and unloading events, setting ARCH to either b32 or
b64 as appropriate for your system:
-a always,exit -F arch=ARCH -S query_module -F auid>=1000 -F auid!=unset -F key=modules
| Rationale: | The addition/removal of kernel modules can be used to alter the behavior of
the kernel and potentially introduce malicious code into kernel space. It is important
to have an audit trail of modules that have been introduced into the kernel. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_query | References: | | Remediation Shell script ⇲# Remediation is applicable only in certain platforms
if [ ! -f /.dockerenv ] && [ ! -f /run/.containerenv ] && rpm --quiet -q audit && { ! ( grep -q aarch64 /proc/sys/kernel/osrelease ); }; then
# First perform the remediation of the syscall rule
# Retrieve hardware architecture of the underlying system
# Note: 32-bit and 64-bit kernel syscall numbers not always line up =>
# it's required on a 64-bit system to check also for the presence
# of 32-bit's equivalent of the corresponding rule.
# (See `man 7 audit.rules` for details )
[ "$(getconf LONG_BIT)" = "32" ] && RULE_ARCHS=("b32") || RULE_ARCHS=("b32" "b64")
for ARCH in "${RULE_ARCHS[@]}"
do
ACTION_ARCH_FILTERS="-a always,exit -F arch=$ARCH"
OTHER_FILTERS=""
AUID_FILTERS="-F auid>=1000 -F auid!=unset"
SYSCALL="query_module"
KEY="modules"
SYSCALL_GROUPING="init_module query_module"
# Perform the remediation for both possible tools: 'auditctl' and 'augenrules'
unset syscall_a
unset syscall_grouping
unset syscall_string
unset syscall
unset file_to_edit
unset rule_to_edit
unset rule_syscalls_to_edit
unset other_string
unset auid_string
unset full_rule
# Load macro arguments into arrays
read -a syscall_a <<< $SYSCALL
read -a syscall_grouping <<< $SYSCALL_GROUPING
# Create a list of audit *.rules files that should be inspected for presence and correctness
# of a particular audit rule. The scheme is as follows:
#
# -----------------------------------------------------------------------------------------
# Tool used to load audit rules | Rule already defined | Audit rules file to inspect |
# -----------------------------------------------------------------------------------------
# auditctl | Doesn't matter | /etc/audit/audit.rules |
# -----------------------------------------------------------------------------------------
# augenrules | Yes | /etc/audit/rules.d/*.rules |
# augenrules | No | /etc/audit/rules.d/$key.rules |
# -----------------------------------------------------------------------------------------
#
files_to_inspect=()
# If audit tool is 'augenrules', then check if the audit rule is defined
# If rule is defined, add '/etc/audit/rules.d/*.rules' to the list for inspection
# If rule isn't defined yet, add '/etc/audit/rules.d/$key.rules' to the list for inspection
default_file="/etc/audit/rules.d/$KEY.rules"
# As other_filters may include paths, lets use a different delimiter for it
# The "F" script expression tells sed to print the filenames where the expressions matched
readarray -t files_to_inspect < <(sed -s -n -e "/^$ACTION_ARCH_FILTERS/!d" -e "\#$OTHER_FILTERS#!d" -e "/$AUID_FILTERS/!d" -e "F" /etc/audit/rules.d/*.rules)
# Case when particular rule isn't defined in /etc/audit/rules.d/*.rules yet
if [ ${#files_to_inspect[@]} -eq "0" ]
then
file_to_inspect="/etc/audit/rules.d/$KEY.rules"
files_to_inspect=("$file_to_inspect")
if [ ! -e "$file_to_inspect" ]
then
touch "$file_to_inspect"
chmod 0640 "$file_to_inspect"
fi
fi
# After converting to jinja, we cannot return; therefore we skip the rest of the macro if needed instead
skip=1
for audit_file in "${files_to_inspect[@]}"
do
# Filter existing $audit_file rules' definitions to select those that satisfy the rule pattern,
# i.e, collect rules that match:
# * the action, list and arch, (2-nd argument)
# * the other filters, (3-rd argument)
# * the auid filters, (4-rd argument)
readarray -t similar_rules < <(sed -e "/^$ACTION_ARCH_FILTERS/!d" -e "\#$OTHER_FILTERS#!d" -e "/$AUID_FILTERS/!d" "$audit_file")
candidate_rules=()
# Filter out rules that have more fields then required. This will remove rules more specific than the required scope
for s_rule in "${similar_rules[@]}"
do
# Strip all the options and fields we know of,
# than check if there was any field left over
extra_fields=$(sed -E -e "s/^$ACTION_ARCH_FILTERS//" -e "s#$OTHER_FILTERS##" -e "s/$AUID_FILTERS//" -e "s/((:?-S [[:alnum:],]+)+)//g" -e "s/-F key=\w+|-k \w+//"<<< "$s_rule")
grep -q -- "-F" <<< "$extra_fields" || candidate_rules+=("$s_rule")
done
if [[ ${#syscall_a[@]} -ge 1 ]]
then
# Check if the syscall we want is present in any of the similar existing rules
for rule in "${candidate_rules[@]}"
do
rule_syscalls=$(echo "$rule" | grep -o -P '(-S [\w,]+)+' | xargs)
all_syscalls_found=0
for syscall in "${syscall_a[@]}"
do
grep -q -- "\b${syscall}\b" <<< "$rule_syscalls" || {
# A syscall was not found in the candidate rule
all_syscalls_found=1
}
done
if [[ $all_syscalls_found -eq 0 ]]
then
# We found a rule with all the syscall(s) we want; skip rest of macro
skip=0
break
fi
# Check if this rule can be grouped with our target syscall and keep track of it
for syscall_g in "${syscall_grouping[@]}"
do
if grep -q -- "\b${syscall_g}\b" <<< "$rule_syscalls"
then
file_to_edit=${audit_file}
rule_to_edit=${rule}
rule_syscalls_to_edit=${rule_syscalls}
fi
done
done
else
# If there is any candidate rule, it is compliant; skip rest of macro
if [ "${#candidate_rules[@]}" -gt 0 ]
then
skip=0
fi
fi
if [ "$skip" -eq 0 ]; then
break
fi
done
if [ "$skip" -ne 0 ]; then
# We checked all rules that matched the expected resemblance pattern (action, arch & auid)
# At this point we know if we need to either append the $full_rule or group
# the syscall together with an exsiting rule
# Append the full_rule if it cannot be grouped to any other rule
if [ -z ${rule_to_edit+x} ]
then
# Build full_rule while avoid adding double spaces when other_filters is empty
if [ "${#syscall_a[@]}" -gt 0 ]
then
syscall_string=""
for syscall in "${syscall_a[@]}"
do
syscall_string+=" -S $syscall"
done
fi
other_string=$([[ $OTHER_FILTERS ]] && echo " $OTHER_FILTERS") || /bin/true
auid_string=$([[ $AUID_FILTERS ]] && echo " $AUID_FILTERS") || /bin/true
full_rule="$ACTION_ARCH_FILTERS${syscall_string}${other_string}${auid_string} -F key=$KEY" || /bin/true
echo "$full_rule" >> "$default_file"
chmod o-rwx ${default_file}
else
# Check if the syscalls are declared as a comma separated list or
# as multiple -S parameters
if grep -q -- "," <<< "${rule_syscalls_to_edit}"
then
delimiter=","
else
delimiter=" -S "
fi
new_grouped_syscalls="${rule_syscalls_to_edit}"
for syscall in "${syscall_a[@]}"
do
grep -q -- "\b${syscall}\b" <<< "${rule_syscalls_to_edit}" || {
# A syscall was not found in the candidate rule
new_grouped_syscalls+="${delimiter}${syscall}"
}
done
# Group the syscall in the rule
sed -i -e "\#${rule_to_edit}#s#${rule_syscalls_to_edit}#${new_grouped_syscalls}#" "$file_to_edit"
fi
fi
unset syscall_a
unset syscall_grouping
unset syscall_string
unset syscall
unset file_to_edit
unset rule_to_edit
unset rule_syscalls_to_edit
unset other_string
unset auid_string
unset full_rule
# Load macro arguments into arrays
read -a syscall_a <<< $SYSCALL
read -a syscall_grouping <<< $SYSCALL_GROUPING
# Create a list of audit *.rules files that should be inspected for presence and correctness
# of a particular audit rule. The scheme is as follows:
#
# -----------------------------------------------------------------------------------------
# Tool used to load audit rules | Rule already defined | Audit rules file to inspect |
# -----------------------------------------------------------------------------------------
# auditctl | Doesn't matter | /etc/audit/audit.rules |
# -----------------------------------------------------------------------------------------
# augenrules | Yes | /etc/audit/rules.d/*.rules |
# augenrules | No | /etc/audit/rules.d/$key.rules |
# -----------------------------------------------------------------------------------------
#
files_to_inspect=()
# If audit tool is 'auditctl', then add '/etc/audit/audit.rules'
# file to the list of files to be inspected
default_file="/etc/audit/audit.rules"
files_to_inspect+=('/etc/audit/audit.rules' )
# After converting to jinja, we cannot return; therefore we skip the rest of the macro if needed instead
skip=1
for audit_file in "${files_to_inspect[@]}"
do
# Filter existing $audit_file rules' definitions to select those that satisfy the rule pattern,
# i.e, collect rules that match:
# * the action, list and arch, (2-nd argument)
# * the other filters, (3-rd argument)
# * the auid filters, (4-rd argument)
readarray -t similar_rules < <(sed -e "/^$ACTION_ARCH_FILTERS/!d" -e "\#$OTHER_FILTERS#!d" -e "/$AUID_FILTERS/!d" "$audit_file")
candidate_rules=()
# Filter out rules that have more fields then required. This will remove rules more specific than the required scope
for s_rule in "${similar_rules[@]}"
do
# Strip all the options and fields we know of,
# than check if there was any field left over
extra_fields=$(sed -E -e "s/^$ACTION_ARCH_FILTERS//" -e "s#$OTHER_FILTERS##" -e "s/$AUID_FILTERS//" -e "s/((:?-S [[:alnum:],]+)+)//g" -e "s/-F key=\w+|-k \w+//"<<< "$s_rule")
grep -q -- "-F" <<< "$extra_fields" || candidate_rules+=("$s_rule")
done
if [[ ${#syscall_a[@]} -ge 1 ]]
then
# Check if the syscall we want is present in any of the similar existing rules
for rule in "${candidate_rules[@]}"
do
rule_syscalls=$(echo "$rule" | grep -o -P '(-S [\w,]+)+' | xargs)
all_syscalls_found=0
for syscall in "${syscall_a[@]}"
do
grep -q -- "\b${syscall}\b" <<< "$rule_syscalls" || {
# A syscall was not found in the candidate rule
all_syscalls_found=1
}
done
if [[ $all_syscalls_found -eq 0 ]]
then
# We found a rule with all the syscall(s) we want; skip rest of macro
skip=0
break
fi
# Check if this rule can be grouped with our target syscall and keep track of it
for syscall_g in "${syscall_grouping[@]}"
do
if grep -q -- "\b${syscall_g}\b" <<< "$rule_syscalls"
then
file_to_edit=${audit_file}
rule_to_edit=${rule}
rule_syscalls_to_edit=${rule_syscalls}
fi
done
done
else
# If there is any candidate rule, it is compliant; skip rest of macro
if [ "${#candidate_rules[@]}" -gt 0 ]
then
skip=0
fi
fi
if [ "$skip" -eq 0 ]; then
break
fi
done
if [ "$skip" -ne 0 ]; then
# We checked all rules that matched the expected resemblance pattern (action, arch & auid)
# At this point we know if we need to either append the $full_rule or group
# the syscall together with an exsiting rule
# Append the full_rule if it cannot be grouped to any other rule
if [ -z ${rule_to_edit+x} ]
then
# Build full_rule while avoid adding double spaces when other_filters is empty
if [ "${#syscall_a[@]}" -gt 0 ]
then
syscall_string=""
for syscall in "${syscall_a[@]}"
do
syscall_string+=" -S $syscall"
done
fi
other_string=$([[ $OTHER_FILTERS ]] && echo " $OTHER_FILTERS") || /bin/true
auid_string=$([[ $AUID_FILTERS ]] && echo " $AUID_FILTERS") || /bin/true
full_rule="$ACTION_ARCH_FILTERS${syscall_string}${other_string}${auid_string} -F key=$KEY" || /bin/true
echo "$full_rule" >> "$default_file"
chmod o-rwx ${default_file}
else
# Check if the syscalls are declared as a comma separated list or
# as multiple -S parameters
if grep -q -- "," <<< "${rule_syscalls_to_edit}"
then
delimiter=","
else
delimiter=" -S "
fi
new_grouped_syscalls="${rule_syscalls_to_edit}"
for syscall in "${syscall_a[@]}"
do
grep -q -- "\b${syscall}\b" <<< "${rule_syscalls_to_edit}" || {
# A syscall was not found in the candidate rule
new_grouped_syscalls+="${delimiter}${syscall}"
}
done
# Group the syscall in the rule
sed -i -e "\#${rule_to_edit}#s#${rule_syscalls_to_edit}#${new_grouped_syscalls}#" "$file_to_edit"
fi
fi
done
else
>&2 echo 'Remediation is not applicable, nothing was done'
fi
Remediation Ansible snippet ⇲Complexity: | low |
---|
Disruption: | low |
---|
Reboot: | false |
---|
Strategy: | configure |
---|
- name: Gather the package facts
package_facts:
manager: auto
tags:
- audit_rules_kernel_module_loading_query
- configure_strategy
- low_complexity
- low_disruption
- medium_severity
- no_reboot_needed
- name: Set architecture for audit query_module tasks
set_fact:
audit_arch: b64
when:
- '"audit" in ansible_facts.packages'
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- not ( ansible_architecture == "aarch64" )
- ansible_architecture == "aarch64" or ansible_architecture == "ppc64" or ansible_architecture
== "ppc64le" or ansible_architecture == "s390x" or ansible_architecture == "x86_64"
tags:
- audit_rules_kernel_module_loading_query
- configure_strategy
- low_complexity
- low_disruption
- medium_severity
- no_reboot_needed
- name: Perform remediation of Audit rules for query_module for x86 platform
block:
- name: Declare list of syscalls
set_fact:
syscalls:
- query_module
syscall_grouping:
- init_module
- query_module
- name: Check existence of query_module in /etc/audit/rules.d/
find:
paths: /etc/audit/rules.d
contains: -a always,exit -F arch=b32(( -S |,)\w+)*(( -S |,){{ item }})+(( -S
|,)\w+)* -F auid>=1000 -F auid!=unset (-k\s+|-F\s+key=)\S+\s*$
patterns: '*.rules'
register: find_command
loop: '{{ (syscall_grouping + syscalls) | unique }}'
- name: Reset syscalls found per file
set_fact:
syscalls_per_file: {}
found_paths_dict: {}
- name: Declare syscalls found per file
set_fact: syscalls_per_file="{{ syscalls_per_file | combine( {item.files[0].path
:[item.item] + syscalls_per_file.get(item.files[0].path, []) } ) }}"
loop: '{{ find_command.results | selectattr(''matched'') | list }}'
- name: Declare files where syscalls were found
set_fact: found_paths="{{ find_command.results | map(attribute='files') | flatten
| map(attribute='path') | list }}"
- name: Count occurrences of syscalls in paths
set_fact: found_paths_dict="{{ found_paths_dict | combine({ item:1+found_paths_dict.get(item,
0) }) }}"
loop: '{{ find_command.results | map(attribute=''files'') | flatten | map(attribute=''path'')
| list }}'
- name: Get path with most syscalls
set_fact: audit_file="{{ (found_paths_dict | dict2items() | sort(attribute='value')
| last).key }}"
when: found_paths | length >= 1
- name: No file with syscall found, set path to /etc/audit/rules.d/module-change.rules
set_fact: audit_file="/etc/audit/rules.d/module-change.rules"
when: found_paths | length == 0
- name: Declare found syscalls
set_fact: syscalls_found="{{ find_command.results | selectattr('matched') | map(attribute='item')
| list }}"
- name: Declare missing syscalls
set_fact: missing_syscalls="{{ syscalls | difference(syscalls_found) }}"
- name: Replace the audit rule in {{ audit_file }}
lineinfile:
path: '{{ audit_file }}'
regexp: (-a always,exit -F arch=b32)(?=.*(?:(?:-S |,)(?:{{ syscalls_per_file[audit_file]
| join("|") }}))\b)((?:( -S |,)\w+)+)( -F auid>=1000 -F auid!=unset (?:-k
|-F key=)\w+)
line: \1\2\3{{ missing_syscalls | join("\3") }}\4
backrefs: true
state: present
when: syscalls_found | length > 0 and missing_syscalls | length > 0
- name: Add the audit rule to {{ audit_file }}
lineinfile:
path: '{{ audit_file }}'
line: -a always,exit -F arch=b32 -S {{ syscalls | join(',') }} -F auid>=1000
-F auid!=unset -F key=module-change
create: true
mode: o-rwx
state: present
when: syscalls_found | length == 0
- name: Declare list of syscalls
set_fact:
syscalls:
- query_module
syscall_grouping:
- init_module
- query_module
- name: Check existence of query_module in /etc/audit/audit.rules
find:
paths: /etc/audit
contains: -a always,exit -F arch=b32(( -S |,)\w+)*(( -S |,){{ item }})+(( -S
|,)\w+)* -F auid>=1000 -F auid!=unset (-k\s+|-F\s+key=)\S+\s*$
patterns: audit.rules
register: find_command
loop: '{{ (syscall_grouping + syscalls) | unique }}'
- name: Set path to /etc/audit/audit.rules
set_fact: audit_file="/etc/audit/audit.rules"
- name: Declare found syscalls
set_fact: syscalls_found="{{ find_command.results | selectattr('matched') | map(attribute='item')
| list }}"
- name: Declare missing syscalls
set_fact: missing_syscalls="{{ syscalls | difference(syscalls_found) }}"
- name: Replace the audit rule in {{ audit_file }}
lineinfile:
path: '{{ audit_file }}'
regexp: (-a always,exit -F arch=b32)(?=.*(?:(?:-S |,)(?:{{ syscalls_found |
join("|") }}))\b)((?:( -S |,)\w+)+)( -F auid>=1000 -F auid!=unset (?:-k |-F
key=)\w+)
line: \1\2\3{{ missing_syscalls | join("\3") }}\4
backrefs: true
state: present
when: syscalls_found | length > 0 and missing_syscalls | length > 0
- name: Add the audit rule to {{ audit_file }}
lineinfile:
path: '{{ audit_file }}'
line: -a always,exit -F arch=b32 -S {{ syscalls | join(',') }} -F auid>=1000
-F auid!=unset -F key=module-change
create: true
mode: o-rwx
state: present
when: syscalls_found | length == 0
when:
- '"audit" in ansible_facts.packages'
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- not ( ansible_architecture == "aarch64" )
tags:
- audit_rules_kernel_module_loading_query
- configure_strategy
- low_complexity
- low_disruption
- medium_severity
- no_reboot_needed
- name: Perform remediation of Audit rules for query_module for x86_64 platform
block:
- name: Declare list of syscalls
set_fact:
syscalls:
- query_module
syscall_grouping:
- init_module
- query_module
- name: Check existence of query_module in /etc/audit/rules.d/
find:
paths: /etc/audit/rules.d
contains: -a always,exit -F arch=b64(( -S |,)\w+)*(( -S |,){{ item }})+(( -S
|,)\w+)* -F auid>=1000 -F auid!=unset (-k\s+|-F\s+key=)\S+\s*$
patterns: '*.rules'
register: find_command
loop: '{{ (syscall_grouping + syscalls) | unique }}'
- name: Reset syscalls found per file
set_fact:
syscalls_per_file: {}
found_paths_dict: {}
- name: Declare syscalls found per file
set_fact: syscalls_per_file="{{ syscalls_per_file | combine( {item.files[0].path
:[item.item] + syscalls_per_file.get(item.files[0].path, []) } ) }}"
loop: '{{ find_command.results | selectattr(''matched'') | list }}'
- name: Declare files where syscalls were found
set_fact: found_paths="{{ find_command.results | map(attribute='files') | flatten
| map(attribute='path') | list }}"
- name: Count occurrences of syscalls in paths
set_fact: found_paths_dict="{{ found_paths_dict | combine({ item:1+found_paths_dict.get(item,
0) }) }}"
loop: '{{ find_command.results | map(attribute=''files'') | flatten | map(attribute=''path'')
| list }}'
- name: Get path with most syscalls
set_fact: audit_file="{{ (found_paths_dict | dict2items() | sort(attribute='value')
| last).key }}"
when: found_paths | length >= 1
- name: No file with syscall found, set path to /etc/audit/rules.d/module-change.rules
set_fact: audit_file="/etc/audit/rules.d/module-change.rules"
when: found_paths | length == 0
- name: Declare found syscalls
set_fact: syscalls_found="{{ find_command.results | selectattr('matched') | map(attribute='item')
| list }}"
- name: Declare missing syscalls
set_fact: missing_syscalls="{{ syscalls | difference(syscalls_found) }}"
- name: Replace the audit rule in {{ audit_file }}
lineinfile:
path: '{{ audit_file }}'
regexp: (-a always,exit -F arch=b64)(?=.*(?:(?:-S |,)(?:{{ syscalls_per_file[audit_file]
| join("|") }}))\b)((?:( -S |,)\w+)+)( -F auid>=1000 -F auid!=unset (?:-k
|-F key=)\w+)
line: \1\2\3{{ missing_syscalls | join("\3") }}\4
backrefs: true
state: present
when: syscalls_found | length > 0 and missing_syscalls | length > 0
- name: Add the audit rule to {{ audit_file }}
lineinfile:
path: '{{ audit_file }}'
line: -a always,exit -F arch=b64 -S {{ syscalls | join(',') }} -F auid>=1000
-F auid!=unset -F key=module-change
create: true
mode: o-rwx
state: present
when: syscalls_found | length == 0
- name: Declare list of syscalls
set_fact:
syscalls:
- query_module
syscall_grouping:
- init_module
- query_module
- name: Check existence of query_module in /etc/audit/audit.rules
find:
paths: /etc/audit
contains: -a always,exit -F arch=b64(( -S |,)\w+)*(( -S |,){{ item }})+(( -S
|,)\w+)* -F auid>=1000 -F auid!=unset (-k\s+|-F\s+key=)\S+\s*$
patterns: audit.rules
register: find_command
loop: '{{ (syscall_grouping + syscalls) | unique }}'
- name: Set path to /etc/audit/audit.rules
set_fact: audit_file="/etc/audit/audit.rules"
- name: Declare found syscalls
set_fact: syscalls_found="{{ find_command.results | selectattr('matched') | map(attribute='item')
| list }}"
- name: Declare missing syscalls
set_fact: missing_syscalls="{{ syscalls | difference(syscalls_found) }}"
- name: Replace the audit rule in {{ audit_file }}
lineinfile:
path: '{{ audit_file }}'
regexp: (-a always,exit -F arch=b64)(?=.*(?:(?:-S |,)(?:{{ syscalls_found |
join("|") }}))\b)((?:( -S |,)\w+)+)( -F auid>=1000 -F auid!=unset (?:-k |-F
key=)\w+)
line: \1\2\3{{ missing_syscalls | join("\3") }}\4
backrefs: true
state: present
when: syscalls_found | length > 0 and missing_syscalls | length > 0
- name: Add the audit rule to {{ audit_file }}
lineinfile:
path: '{{ audit_file }}'
line: -a always,exit -F arch=b64 -S {{ syscalls | join(',') }} -F auid>=1000
-F auid!=unset -F key=module-change
create: true
mode: o-rwx
state: present
when: syscalls_found | length == 0
when:
- '"audit" in ansible_facts.packages'
- ansible_virtualization_type not in ["docker", "lxc", "openvz", "podman", "container"]
- not ( ansible_architecture == "aarch64" )
- audit_arch == "b64"
tags:
- audit_rules_kernel_module_loading_query
- configure_strategy
- low_complexity
- low_disruption
- medium_severity
- no_reboot_needed
|
|
Group
Record Attempts to Alter Logon and Logout Events
Group contains 2 rules |
[ref]
The audit system already collects login information for all users
and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d in order to watch for attempted manual
edits of files involved in storing logon events:
-w /var/log/tallylog -p wa -k logins
-w /var/run/faillock -p wa -k logins
-w /var/log/lastlog -p wa -k logins
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file in order to watch for unattempted manual
edits of files involved in storing logon events:
-w /var/log/tallylog -p wa -k logins
-w /var/run/faillock -p wa -k logins
-w /var/log/lastlog -p wa -k logins
|
Rule
Record Attempts to Alter Logon and Logout Events - faillock
[ref] | The audit system already collects login information for all users
and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d in order to watch for attempted manual
edits of files involved in storing logon events:
-w /var/run/faillock -p wa -k logins
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file in order to watch for unattempted manual
edits of files involved in storing logon events:
-w /var/run/faillock -p wa -k logins
| Rationale: | Manual editing of these files may indicate nefarious activity, such
as an attacker attempting to remove evidence of an intrusion. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_login_events_faillock | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000126, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.3 | os-srg | SRG-OS-000392-GPOS-00172, SRG-OS-000470-GPOS-00214, SRG-OS-000473-GPOS-00218 | app-srg-ctr | SRG-APP-000503-CTR-001275, SRG-APP-000506-CTR-001290 | anssi | R73 | cis | 5.2.3.12 | pcidss4 | 10.2.1.3, 10.2.1, 10.2 |
| |
|
Rule
Record Attempts to Alter Logon and Logout Events - lastlog
[ref] | The audit system already collects login information for all users
and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d in order to watch for attempted manual
edits of files involved in storing logon events:
-w /var/log/lastlog -p wa -k logins
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file in order to watch for unattempted manual
edits of files involved in storing logon events:
-w /var/log/lastlog -p wa -k logins
| Rationale: | Manual editing of these files may indicate nefarious activity, such
as an attacker attempting to remove evidence of an intrusion. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_login_events_lastlog | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000126, CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.3 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000473-GPOS-00218, SRG-OS-000470-GPOS-00214 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000503-CTR-001275, SRG-APP-000506-CTR-001290 | anssi | R73 | cis | 5.2.3.12 | pcidss4 | 10.2.1.3, 10.2.1, 10.2 |
| |
|
Group
Record Information on the Use of Privileged Commands
Group contains 3 rules |
[ref]
At a minimum, the audit system should collect the execution of
privileged commands for all users and root. |
Rule
Ensure auditd Collects Information on the Use of Privileged Commands
[ref] | The audit system should collect information about usage of privileged commands for all users.
These are commands with suid or sgid bits on and they are specially risky in local block
device partitions not mounted with noexec and nosuid options. Therefore, these partitions
should be first identified by the following command:
findmnt -n -l -k -it $(awk '/nodev/ { print $2 }' /proc/filesystems | paste -sd,) | grep -Pv "noexec|nosuid"
For all partitions listed by the previous command, it is necessary to search for
setuid / setgid programs using the following command:
$ sudo find PARTITION -xdev -perm /6000 -type f 2>/dev/null
For each setuid / setgid program identified by the previous command, an audit rule must be
present in the appropriate place using the following line structure:
-a always,exit -F path=PROG_PATH -F perm=x -F auid>=1000 -F auid!=unset -F key=privileged
If the auditd daemon is configured to use the augenrules program to read
audit rules during daemon startup, add the line to a file with suffix .rules in the
/etc/audit/rules.d directory, replacing the PROG_PATH part with the full path
of that setuid / setgid identified program.
If the auditd daemon is configured to use the auditctl utility instead, add
the line to the /etc/audit/audit.rules file, also replacing the PROG_PATH part
with the full path of that setuid / setgid identified program. Warning:
This rule checks for multiple syscalls related to privileged commands. If needed to check
specific privileged commands, other more specific rules should be considered. For example:
audit_rules_privileged_commands_su audit_rules_privileged_commands_umount audit_rules_privileged_commands_passwd
Warning:
Note that OVAL check and Bash / Ansible remediation of this rule
explicitly excludes file systems mounted at /proc directory
and its subdirectories. It is a virtual file system and it doesn't
contain executable applications. At the same time, interacting with this
file system during check or remediation caused undesirable errors. | Rationale: | Misuse of privileged functions, either intentionally or unintentionally by authorized users,
or by unauthorized external entities that have compromised system accounts, is a serious and
ongoing concern that can have significant adverse impacts on organizations.
Auditing the use of privileged functions is one way to detect such misuse and identify the
risk from insider and advanced persistent threats.
Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert
their normal role of providing some necessary but limited capability. As such, motivation
exists to monitor these programs for unusual activity. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO08.04, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.05, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-002234 | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.5, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.3.4.5.9, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 3.9, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | ism | 0582, 0584, 05885, 0586, 0846, 0957 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.1, A.16.1.2, A.16.1.3, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.3, A.6.2.1, A.6.2.2 | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | nist | AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-2, DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, DE.DP-4, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, RS.CO-2 | pcidss | Req-10.2.2 | os-srg | SRG-OS-000327-GPOS-00127 | anssi | R73 | cis | 5.2.3.6 |
| |
|
Rule
Ensure auditd Collects Information on the Use of Privileged Commands - kmod
[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 :
-w /usr/bin/kmod -p x -k modules
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 :
-w /usr/bin/kmod -p x -k modules
| Rationale: | Without generating audit records that are specific to the security and
mission needs of the organization, it would be difficult to establish,
correlate, and investigate the events relating to an incident or identify
those responsible for one.
Audit records can be generated from various components within the
information system (e.g., module or policy filter). | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_kmod | References: | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-002884 | nist | AU-3, AU-3.1, AU-12(a), AU-12.1(ii), AU-12.1(iv)AU-12(c), MA-4(1)(a) | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000471-GPOS-00216, SRG-OS-000477-GPOS-00222 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000504-CTR-001280 | anssi | R73 | cis | 5.2.3.19 |
| |
|
Rule
Ensure auditd Collects Information on the Use of Privileged Commands - usermod
[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/sbin/usermod -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/sbin/usermod -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_usermod | References: | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-002884 | 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 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255 | cis | 5.2.3.18 |
| |
|
Group
Records Events that Modify Date and Time Information
Group contains 5 rules |
[ref]
Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time. All changes to the system
time should be audited. |
Rule
Record attempts to alter time through adjtimex
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S adjtimex -F key=audit_time_rules
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S adjtimex -F key=audit_time_rules
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S adjtimex -F key=audit_time_rules
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S adjtimex -F key=audit_time_rules
The -k option allows for the specification of a key in string form that can be
used for better reporting capability through ausearch and aureport. Multiple
system calls can be defined on the same line to save space if desired, but is
not required. See an example of multiple combined syscalls:
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules
| Rationale: | Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time (such as sshd). All changes
to the system time should be audited. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_time_adjtimex | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-001487, CCI-000169 | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e) | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | pcidss | Req-10.4.2.b | anssi | R73 | cis | 5.2.3.4 | pcidss4 | 10.6.3, 10.6 |
| |
|
Rule
Record Attempts to Alter Time Through clock_settime
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
The -k option allows for the specification of a key in string form that can
be used for better reporting capability through ausearch and aureport.
Multiple system calls can be defined on the same line to save space if
desired, but is not required. See an example of multiple combined syscalls:
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules
| Rationale: | Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time (such as sshd). All changes
to the system time should be audited. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_time_clock_settime | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-001487, CCI-000169 | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e) | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | pcidss | Req-10.4.2.b | anssi | R73 | cis | 5.2.3.4 | pcidss4 | 10.6.3, 10.6 |
| |
|
Rule
Record attempts to alter time through settimeofday
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S settimeofday -F key=audit_time_rules
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S settimeofday -F key=audit_time_rules
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S settimeofday -F key=audit_time_rules
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S settimeofday -F key=audit_time_rules
The -k option allows for the specification of a key in string form that can be
used for better reporting capability through ausearch and aureport. Multiple
system calls can be defined on the same line to save space if desired, but is
not required. See an example of multiple combined syscalls:
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules
| Rationale: | Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time (such as sshd). All changes
to the system time should be audited. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_time_settimeofday | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-001487, CCI-000169 | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e) | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | pcidss | Req-10.4.2.b | cis | 5.2.3.4 | pcidss4 | 10.6.3, 10.6 |
| |
|
Rule
Record Attempts to Alter Time Through stime
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d for both 32 bit and 64 bit systems:
-a always,exit -F arch=b32 -S stime -F key=audit_time_rules
Since the 64 bit version of the "stime" system call is not defined in the audit
lookup table, the corresponding "-F arch=b64" form of this rule is not expected
to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule
form itself is sufficient for both 32 bit and 64 bit systems). If the
auditd daemon is configured to use the auditctl utility to
read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file for both 32 bit and 64 bit systems:
-a always,exit -F arch=b32 -S stime -F key=audit_time_rules
Since the 64 bit version of the "stime" system call is not defined in the audit
lookup table, the corresponding "-F arch=b64" form of this rule is not expected
to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule
form itself is sufficient for both 32 bit and 64 bit systems). The -k option
allows for the specification of a key in string form that can be used for
better reporting capability through ausearch and aureport. Multiple system
calls can be defined on the same line to save space if desired, but is not
required. See an example of multiple combined system calls:
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules
| Rationale: | Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time (such as sshd). All changes
to the system time should be audited. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_time_stime | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-001487, CCI-000169 | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e) | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | pcidss | Req-10.4.2.b | anssi | R73 | cis | 5.2.3.4 | pcidss4 | 10.6.3, 10.6 |
| |
|
Rule
Record Attempts to Alter the localtime File
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the default),
add the following line to a file with suffix .rules in the directory
/etc/audit/rules.d :
-w /etc/localtime -p wa -k audit_time_rules
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-w /etc/localtime -p wa -k audit_time_rules
The -k option allows for the specification of a key in string form that can
be used for better reporting capability through ausearch and aureport and
should always be used. | Rationale: | Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time (such as sshd). All changes
to the system time should be audited. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_time_watch_localtime | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-001487, CCI-000169 | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e) | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | pcidss | Req-10.4.2.b | anssi | R73 | cis | 5.2.3.4 | pcidss4 | 10.6.3, 10.6 |
| |
|
Rule
Make the auditd Configuration Immutable
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d in order to make the auditd configuration
immutable:
-e 2
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file in order to make the auditd configuration
immutable:
-e 2
With this setting, a reboot will be required to change any audit rules. | Rationale: | Making the audit configuration immutable prevents accidental as
well as malicious modification of the audit rules, although it may be
problematic if legitimate changes are needed during system
operation. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_immutable | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 3, 4, 5, 6, 7, 8 | cjis | 5.4.1.1 | cobit5 | APO01.06, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, BAI03.05, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, DSS06.02, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.3.1, 3.4.3 | disa | CCI-000162, CCI-000163, CCI-000164 | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.310(a)(2)(iv), 164.312(d), 164.310(d)(2)(iii), 164.312(b), 164.312(e) | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.7.3, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 5.2, SR 6.1 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, ID.SC-4, PR.AC-4, PR.DS-5, PR.PT-1, RS.AN-1, RS.AN-4 | pcidss | Req-10.5.2 | os-srg | SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029 | app-srg-ctr | SRG-APP-000119-CTR-000245, SRG-APP-000120-CTR-000250 | anssi | R73 | cis | 5.2.3.20 | pcidss4 | 10.3.2, 10.3 |
| |
|
Rule
Record Events that Modify the System's Mandatory Access Controls
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d :
-w /etc/selinux/ -p wa -k MAC-policy
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-w /etc/selinux/ -p wa -k MAC-policy
| Rationale: | The system's mandatory access policy (SELinux) should not be
arbitrarily changed by anything other than administrator action. All changes to
MAC policy should be audited. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_mac_modification | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.8 | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e) | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.5.5 | anssi | R73 | cis | 5.2.3.14 | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Mandatory Access Controls in usr/share
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d :
-w /usr/share/selinux/ -p wa -k MAC-policy
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-w /usr/share/selinux/ -p wa -k MAC-policy
| Rationale: | The system's mandatory access policy (SELinux) should not be
arbitrarily changed by anything other than administrator action. All changes to
MAC policy should be audited. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_mac_modification_usr_share | References: | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.8 | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e) | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.5.5 | cis | 5.2.3.14 |
| |
|
Rule
Ensure auditd Collects Information on Exporting to Media (successful)
[ref] | At a minimum, the audit system should collect media exportation
events for all users and root. If the auditd daemon is configured to
use the augenrules program to read audit rules during daemon startup
(the default), add the following line to a file with suffix .rules in
the directory /etc/audit/rules.d , setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export
| Rationale: | The unauthorized exportation of data to external media could result in an information leak
where classified information, Privacy Act information, and intellectual property could be lost. An audit
trail should be created each time a filesystem is mounted to help identify and guard against information
loss. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_media_export | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | pcidss | Req-10.2.7 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215 | app-srg-ctr | SRG-APP-000495-CTR-001235 | anssi | R73 | cis | 5.2.3.10 | pcidss4 | 10.2.1.7, 10.2.1, 10.2 |
| |
|
Rule
Record Events that Modify the System's Network Environment
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d , setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S sethostname,setdomainname -F key=audit_rules_networkconfig_modification
-w /etc/issue -p wa -k audit_rules_networkconfig_modification
-w /etc/issue.net -p wa -k audit_rules_networkconfig_modification
-w /etc/hosts -p wa -k audit_rules_networkconfig_modification
-w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S sethostname,setdomainname -F key=audit_rules_networkconfig_modification
-w /etc/issue -p wa -k audit_rules_networkconfig_modification
-w /etc/issue.net -p wa -k audit_rules_networkconfig_modification
-w /etc/hosts -p wa -k audit_rules_networkconfig_modification
-w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification
| Rationale: | The network environment should not be modified by anything other
than administrator action. Any change to network parameters should be
audited. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_networkconfig_modification | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e) | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | pcidss | Req-10.5.5 | anssi | R73 | cis | 5.2.3.5 | pcidss4 | 10.3.4, 10.3 |
| |
|
Rule
Record Events that Modify the System's Network Environment
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d :
-w /etc/sysconfig/network-scripts -p wa -k audit_rules_networkconfig_modification_network_scripts
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-w /etc/sysconfig/network-scripts -p wa -k audit_rules_networkconfig_modification_network_scripts
| Rationale: | The network environment should not be modified by anything other
than administrator action. Any change to network parameters should be
audited. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_networkconfig_modification_network_scripts | References: | | |
|
Rule
Record Attempts to Alter Process and Session Initiation Information
[ref] | The audit system already collects process information for all
users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d in order to watch for attempted manual
edits of files involved in storing such process information:
-w /var/run/utmp -p wa -k session
-w /var/log/btmp -p wa -k session
-w /var/log/wtmp -p wa -k session
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file in order to watch for attempted manual
edits of files involved in storing such process information:
-w /var/run/utmp -p wa -k session
-w /var/log/btmp -p wa -k session
-w /var/log/wtmp -p wa -k session
| Rationale: | Manual editing of these files may indicate nefarious activity, such
as an attacker attempting to remove evidence of an intrusion. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_session_events | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | hipaa | 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e) | isa-62443-2009 | 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | ism | 0582, 0584, 05885, 0586, 0846, 0957 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AU-2(d), AU-12(c), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.3 | app-srg-ctr | SRG-APP-000505-CTR-001285 | anssi | R73 | cis | 5.2.3.11 | pcidss4 | 10.2.1.3, 10.2.1, 10.2 |
| |
|
Rule
Record Events When Executables Are Run As Another User
[ref] | Verify the system generates an audit record when actions are run as another user.
sudo provides users with temporary elevated privileges to perform operations, either as the superuser or another user.
If audit is using the "auditctl" tool to load the rules, run the following command:
$ sudo grep execve /etc/audit/audit.rules
If audit is using the "augenrules" tool to load the rules, run the following command:
$ sudo grep -r execve /etc/audit/rules.d
-a always,exit -F arch=b32 -S execve -C euid!=uid -F auid!=unset -k user_emulation
-a always,exit -F arch=b64 S execve -C euid!=uid -F auid!=unset -k user_emulation
If both the "b32" and "b64" audit rules for "SUID" files are not defined, this is a finding. Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. | Rationale: | Creating an audit log of users with temporary elevated privileges and the
operation(s) they performed is essential to reporting. Administrators will
want to correlate the events written to the audit trail with the records
written to sudo's logfile to verify if unauthorized commands have
been executed.
Misuse of privileged functions, either intentionally or unintentionally by
authorized users, or by unauthorized external entities that have
compromised information 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 threats and the advanced persistent threat. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_suid_auid_privilege_function | References: | | |
|
Rule
Ensure auditd Collects System Administrator Actions
[ref] | At a minimum, the audit system should collect administrator actions
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the default),
add the following line to a file with suffix .rules in the directory
/etc/audit/rules.d :
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions
| Rationale: | The actions taken by system administrators should be audited to keep a record
of what was executed on the system, as well as, for accountability purposes. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_sysadmin_actions | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000126, CCI-000130, CCI-000135, CCI-000169, CCI-000172, 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.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.1, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nist | AC-2(7)(b), AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.2, Req-10.2.5.b | os-srg | SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000304-GPOS-00121, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221 | app-srg-ctr | SRG-APP-000026-CTR-000070, SRG-APP-000027-CTR-000075, SRG-APP-000028-CTR-000080, SRG-APP-000291-CTR-000675, SRG-APP-000292-CTR-000680, SRG-APP-000293-CTR-000685, SRG-APP-000294-CTR-000690, SRG-APP-000319-CTR-000745, SRG-APP-000320-CTR-000750, SRG-APP-000509-CTR-001305 | anssi | R73 | cis | 5.2.3.1 | pcidss4 | 10.2.1.5, 10.2.1, 10.2 |
| |
|
Rule
Record Events that Modify User/Group Information - /etc/group
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d , in order to capture events that modify
account changes:
-w /etc/group -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, in order to capture events that modify
account changes:
-w /etc/group -p wa -k audit_rules_usergroup_modification
| Rationale: | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_group | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000018, CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-001403, CCI-001404, CCI-001405, CCI-001683, CCI-001684, CCI-001685, CCI-001686, CCI-002130, CCI-002132, 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.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.1, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | nist | AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.5 | os-srg | SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000503-CTR-001275 | anssi | R73 | cis | 5.2.3.8 | pcidss4 | 10.2.1.5, 10.2.1, 10.2 |
| |
|
Rule
Record Events that Modify User/Group Information - /etc/gshadow
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d , in order to capture events that modify
account changes:
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, in order to capture events that modify
account changes:
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
| Rationale: | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_gshadow | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000018, CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-001403, CCI-001404, CCI-001405, CCI-001683, CCI-001684, CCI-001685, CCI-001686, CCI-002130, CCI-002132, 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.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.1, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | nist | AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.5 | os-srg | SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000503-CTR-001275 | anssi | R73 | cis | 5.2.3.8 | pcidss4 | 10.2.1.5, 10.2.1, 10.2 |
| |
|
Rule
Record Events that Modify User/Group Information - /etc/security/opasswd
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d , in order to capture events that modify
account changes:
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, in order to capture events that modify
account changes:
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
| Rationale: | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_opasswd | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000018, CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-001403, CCI-001404, CCI-001405, CCI-001683, CCI-001684, CCI-001685, CCI-001686, CCI-002130, CCI-002132, 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.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.1, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | nist | AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.5 | os-srg | SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000496-CTR-001240, SRG-APP-000497-CTR-001245, SRG-APP-000498-CTR-001250, SRG-APP-000503-CTR-001275 | anssi | R73 | cis | 5.2.3.8 | pcidss4 | 10.2.1.5, 10.2.1, 10.2 |
| |
|
Rule
Record Events that Modify User/Group Information - /etc/passwd
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d , in order to capture events that modify
account changes:
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, in order to capture events that modify
account changes:
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
| Rationale: | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_passwd | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000018, CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-001403, CCI-001404, CCI-001405, CCI-001683, CCI-001684, CCI-001685, CCI-001686, CCI-002130, CCI-002132, 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.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.1, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | nist | AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.5 | os-srg | SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000304-GPOS-00121, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221, SRG-OS-000274-GPOS-00104, SRG-OS-000275-GPOS-00105, SRG-OS-000276-GPOS-00106, SRG-OS-000277-GPOS-00107 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000503-CTR-001275 | anssi | R73 | cis | 5.2.3.8 | pcidss4 | 10.2.1.5, 10.2.1, 10.2 |
| |
|
Rule
Record Events that Modify User/Group Information - /etc/shadow
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d , in order to capture events that modify
account changes:
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, in order to capture events that modify
account changes:
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
| Rationale: | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_shadow | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | cjis | 5.4.1.1 | cobit5 | APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.1.7 | disa | CCI-000018, CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-001403, CCI-001404, CCI-001405, CCI-001683, CCI-001684, CCI-001685, CCI-001686, CCI-002130, CCI-002132, 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.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 1.1, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6 | iso27001-2013 | A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5 | nerc-cip | CIP-004-6 R2.2.2, CIP-004-6 R2.2.3, CIP-007-3 R.1.3, CIP-007-3 R5, CIP-007-3 R5.1.1, CIP-007-3 R5.1.3, CIP-007-3 R5.2.1, CIP-007-3 R5.2.3 | nist | AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4 | ospp | FAU_GEN.1.1.c | pcidss | Req-10.2.5 | os-srg | SRG-OS-000004-GPOS-00004, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000304-GPOS-00121, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000470-GPOS-00214, SRG-OS-000471-GPOS-00215, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000466-GPOS-00210, SRG-OS-000476-GPOS-00221 | app-srg-ctr | SRG-APP-000495-CTR-001235, SRG-APP-000499-CTR-001255, SRG-APP-000503-CTR-001275 | anssi | R73 | cis | 5.2.3.8 | pcidss4 | 10.2.1.5, 10.2.1, 10.2 |
| |
|
Rule
Record Attempts to perform maintenance activities
[ref] | The Amazon Linux 2023 operating system must generate audit records for
privileged activities, nonlocal maintenance, diagnostic sessions and
other system-level access.
Verify the operating system audits activities performed during nonlocal
maintenance and diagnostic sessions. Run the following command:
$ sudo auditctl -l | grep sudo.log
-w /var/log/sudo.log -p wa -k maintenance
| Rationale: | If events associated with nonlocal administrative access or diagnostic
sessions are not logged, a major tool for assessing and investigating
attacks would not be available.
This requirement addresses auditing-related issues associated with
maintenance tools used specifically for diagnostic and repair actions
on organizational information systems.
Nonlocal maintenance and diagnostic activities are those activities
conducted by individuals communicating through a network, either an
external network (e.g., the internet) or an internal network. Local
maintenance and diagnostic activities are those activities carried
out by individuals physically present at the information system or
information system component and not communicating across a network
connection.
This requirement applies to hardware/software diagnostic test
equipment or tools. This requirement does not cover hardware/software
components that may support information system maintenance, yet are a
part of the system, for example, the software implementing "ping,"
"ls," "ipconfig," or the hardware and software implementing the
monitoring port of an Ethernet switch. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_audit_sudo_log_events | References: | disa | CCI-000172, CCI-002884 | pcidss | Req-10.2.2, Req-10.2.5.b | os-srg | SRG-OS-000392-GPOS-00172, SRG-OS-000471-GPOS-00215 | anssi | R73 | cis | 5.2.3.3 | pcidss4 | 10.2.1.3, 10.2.1, 10.2 |
| |
|
Rule
System Audit Logs Must Have Mode 0750 or Less Permissive
[ref] |
If log_group in /etc/audit/auditd.conf is set to a group other than the root
group account, change the mode of the audit log files with the following command:
$ sudo chmod 0750 /var/log/audit
Otherwise, change the mode of the audit log files with the following command:
$ sudo chmod 0700 /var/log/audit
| Rationale: | If users can write to audit logs, audit trails can be modified or destroyed. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_directory_permissions_var_log_audit | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 3, 4, 5, 6, 7, 8 | cobit5 | APO01.06, APO11.04, APO12.06, BAI03.05, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, DSS06.02, MEA02.01 | disa | CCI-000162, CCI-000163, CCI-000164 | isa-62443-2009 | 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.7.3, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 5.2, SR 6.1 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nerc-cip | CIP-003-8 R5.1.1, CIP-003-8 R5.2, CIP-003-8 R5.3, CIP-004-6 R2.3, CIP-004-6 R3.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 R6.5 | nist | CM-6(a), AC-6(1), AU-9 | nist-csf | DE.AE-3, DE.AE-5, PR.AC-4, PR.DS-5, PR.PT-1, RS.AN-1, RS.AN-4 | os-srg | SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029 | cis | 5.2.4.4 |
| |
|
Rule
System Audit Logs Must Be Group Owned By Root
[ref] | All audit logs must be group owned by root user. The path for audit log can
be configured via log_file parameter in /etc/audit/auditd.conf
or, by default, the path for audit log is /var/log/audit/ .
To properly set the group owner of /var/log/audit/* , run the command:
$ sudo chgrp root /var/log/audit/*
If log_group in /etc/audit/auditd.conf is set to a group other
than the root group account, change the group ownership of the audit logs
to this specific group. | Rationale: | Unauthorized disclosure of audit records can reveal system and configuration data to
attackers, thus compromising its confidentiality. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_group_ownership_var_log_audit | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 3, 4, 5, 6, 7, 8 | cjis | 5.4.1.1 | cobit5 | APO01.06, APO11.04, APO12.06, BAI03.05, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, DSS06.02, MEA02.01 | cui | 3.3.1 | disa | CCI-000162, CCI-000163, CCI-000164, CCI-001314 | isa-62443-2009 | 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.7.3, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 5.2, SR 6.1 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1), AU-9(4) | nist-csf | DE.AE-3, DE.AE-5, PR.AC-4, PR.DS-5, PR.PT-1, RS.AN-1, RS.AN-4 | pcidss | Req-10.5.1 | os-srg | SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029, SRG-OS-000206-GPOS-00084 | cis | 5.2.4.3 | pcidss4 | 10.3.2, 10.3 |
| |
|
Rule
Audit Configuration Files Must Be Owned By Group root
[ref] | All audit configuration files must be owned by group root.
chown :root /etc/audit/audit*.{rules,conf} /etc/audit/rules.d/*
| Rationale: | Without the capability to restrict which roles and individuals can
select which events are audited, unauthorized personnel may be able
to prevent the auditing of critical events.
Misconfigured audits may degrade the system's performance by
overwhelming the audit log. Misconfigured audits may also make it more
difficult to establish, correlate, and investigate the events relating
to an incident or identify those responsible for one. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupownership_audit_configuration | References: | | |
|
Rule
Audit Configuration Files Must Be Owned By Root
[ref] | All audit configuration files must be owned by root user.
To properly set the owner of /etc/audit/ , run the command:
$ sudo chown root /etc/audit/
To properly set the owner of /etc/audit/rules.d/ , run the command:
$ sudo chown root /etc/audit/rules.d/
| Rationale: | Without the capability to restrict which roles and individuals can
select which events are audited, unauthorized personnel may be able
to prevent the auditing of critical events.
Misconfigured audits may degrade the system's performance by
overwhelming the audit log. Misconfigured audits may also make it more
difficult to establish, correlate, and investigate the events relating
to an incident or identify those responsible for one. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_ownership_audit_configuration | References: | | |
|
Rule
System Audit Logs Must Be Owned By Root
[ref] | All audit logs must be owned by root user. The path for audit log can be
configured via log_file parameter in /etc/audit/auditd.conf
or by default, the path for audit log is /var/log/audit/ .
To properly set the owner of /var/log/audit/* , run the command:
$ sudo chown root /var/log/audit/*
| Rationale: | Unauthorized disclosure of audit records can reveal system and configuration data to
attackers, thus compromising its confidentiality. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_ownership_var_log_audit_stig | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 3, 4, 5, 6, 7, 8 | cjis | 5.4.1.1 | cobit5 | APO01.06, APO11.04, APO12.06, BAI03.05, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, DSS06.02, MEA02.01 | cui | 3.3.1 | disa | CCI-000162, CCI-000163, CCI-000164, CCI-001314 | isa-62443-2009 | 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.7.3, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 5.2, SR 6.1 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | nist | CM-6(a), AC-6(1), AU-9(4) | nist-csf | DE.AE-3, DE.AE-5, PR.AC-4, PR.DS-5, PR.PT-1, RS.AN-1, RS.AN-4 | pcidss | Req-10.5.1 | os-srg | SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029, SRG-OS-000206-GPOS-00084 | cis | 5.2.4.2 |
| |
|
Rule
Audit Configuration Files Permissions are 640 or More Restrictive
[ref] | All audit configuration files permissions must be 640 or more restrictive.
chmod 0640 /etc/audit/audit*.{rules,conf} /etc/audit/rules.d/*
| Rationale: | Without the capability to restrict which roles and individuals can
select which events are audited, unauthorized personnel may be able
to prevent the auditing of critical events.
Misconfigured audits may degrade the system's performance by
overwhelming the audit log. Misconfigured audits may also make it more
difficult to establish, correlate, and investigate the events relating
to an incident or identify those responsible for one. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_audit_configuration | References: | | |
|
Rule
System Audit Logs Must Have Mode 0640 or Less Permissive
[ref] |
If log_group in /etc/audit/auditd.conf is set to a group other than the
root
group account, change the mode of the audit log files with the following command:
$ sudo chmod 0640 audit_file
Otherwise, change the mode of the audit log files with the following command:
$ sudo chmod 0600 audit_file
| Rationale: | If users can write to audit logs, audit trails can be modified or destroyed. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_var_log_audit | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 18, 19, 3, 4, 5, 6, 7, 8 | cjis | 5.4.1.1 | cobit5 | APO01.06, APO11.04, APO12.06, BAI03.05, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, DSS06.02, MEA02.01 | cui | 3.3.1 | disa | CCI-000162, CCI-000163, CCI-000164, CCI-001314 | isa-62443-2009 | 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.7.3, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 5.2, SR 6.1 | iso27001-2013 | A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5 | 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), AU-9(4) | nist-csf | DE.AE-3, DE.AE-5, PR.AC-4, PR.DS-5, PR.PT-1, RS.AN-1, RS.AN-4 | pcidss | Req-10.5 | os-srg | SRG-OS-000057-GPOS-00027, SRG-OS-000058-GPOS-00028, SRG-OS-000059-GPOS-00029, SRG-OS-000206-GPOS-00084 | app-srg-ctr | SRG-APP-000118-CTR-000240 | cis | 5.2.4.1 | pcidss4 | 10.3.1, 10.3 |
| |
|
Group
Configure auditd Data Retention
Group contains 5 rules |
[ref]
The audit system writes data to /var/log/audit/audit.log . By default,
auditd rotates 5 logs by size (6MB), retaining a maximum of 30MB of
data in total, and refuses to write entries when the disk is too
full. This minimizes the risk of audit data filling its partition
and impacting other services. This also minimizes the risk of the audit
daemon temporarily disabling the system if it cannot write audit log (which
it can be configured to do).
For a busy
system or a system which is thoroughly auditing system activity, the default settings
for data retention may be
insufficient. The log file size needed will depend heavily on what types
of events are being audited. First configure auditing to log all the events of
interest. Then monitor the log size manually for awhile to determine what file
size will allow you to keep the required data for the correct time period.
Using a dedicated partition for /var/log/audit prevents the
auditd logs from disrupting system functionality if they fill, and,
more importantly, prevents other activity in /var from filling the
partition and stopping the audit trail. (The audit logs are size-limited and
therefore unlikely to grow without bound unless configured to do so.) Some
machines may have requirements that no actions occur which cannot be audited.
If this is the case, then auditd can be configured to halt the machine
if it runs out of space. Note: Since older logs are rotated,
configuring auditd this way does not prevent older logs from being
rotated away before they can be viewed.
If your system is configured to halt when logging cannot be performed, make
sure this can never happen under normal circumstances! Ensure that
/var/log/audit is on its own partition, and that this partition is
larger than the maximum amount of data auditd will retain
normally.
|
Rule
Configure auditd mail_acct Action on Low Disk Space
[ref] | The auditd service can be configured to send email to
a designated account in certain situations. Add or correct the following line
in /etc/audit/auditd.conf to ensure that administrators are notified
via email for those situations:
action_mail_acct = root
| Rationale: | Email sent to the root account is typically aliased to the
administrators of the system, who can take appropriate action. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_data_retention_action_mail_acct | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8 | cjis | 5.4.1.1 | cobit5 | APO11.04, APO12.06, APO13.01, BAI03.05, BAI04.04, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, MEA02.01 | cui | 3.3.1 | disa | CCI-000139, CCI-001855 | hipaa | 164.312(a)(2)(ii) | isa-62443-2009 | 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, SR 7.1, SR 7.2 | iso27001-2013 | A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.16.1.4, A.16.1.5, A.16.1.7, A.17.2.1 | nerc-cip | CIP-003-8 R1.3, CIP-003-8 R3, CIP-003-8 R3.1, CIP-003-8 R3.2, CIP-003-8 R3.3, CIP-003-8 R5.1.1, CIP-003-8 R5.3, CIP-004-6 R2.2.3, CIP-004-6 R2.3, CIP-007-3 R5.1, CIP-007-3 R5.1.2, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3 | nist | IA-5(1), AU-5(a), AU-5(2), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, PR.DS-4, PR.PT-1, RS.AN-1, RS.AN-4 | pcidss | Req-10.7.a | os-srg | SRG-OS-000046-GPOS-00022, SRG-OS-000343-GPOS-00134 | cis | 5.2.2.3 |
| |
|
Rule
Configure auditd admin_space_left Action on Low Disk Space
[ref] | The auditd service can be configured to take an action
when disk space is running low but prior to running out of space completely.
Edit the file /etc/audit/auditd.conf . Add or modify the following line,
substituting ACTION appropriately:
admin_space_left_action = ACTION
Set this value to single to cause the system to switch to single user
mode for corrective action. Acceptable values also include suspend and
halt . For certain systems, the need for availability
outweighs the need to log all actions, and a different setting should be
determined. Details regarding all possible values for ACTION are described in the
auditd.conf man page. | Rationale: | Administrators should be made aware of an inability to record
audit records. If a separate partition or logical volume of adequate size
is used, running low on space for audit records should never occur. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_data_retention_admin_space_left_action | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8 | cjis | 5.4.1.1 | cobit5 | APO11.04, APO12.06, APO13.01, BAI03.05, BAI04.04, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, MEA02.01 | cui | 3.3.1 | disa | CCI-000140, CCI-001343, CCI-001855 | hipaa | 164.312(a)(2)(ii) | isa-62443-2009 | 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, SR 7.1, SR 7.2 | iso27001-2013 | A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.16.1.4, A.16.1.5, A.16.1.7, A.17.2.1 | nist | AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, PR.DS-4, PR.PT-1, RS.AN-1, RS.AN-4 | pcidss | Req-10.7 | os-srg | SRG-OS-000343-GPOS-00134 | cis | 5.2.2.3 | pcidss4 | 10.5.1, 10.5 |
| |
|
Rule
Configure auditd Max Log File Size
[ref] | Determine the amount of audit data (in megabytes)
which should be retained in each log file. Edit the file
/etc/audit/auditd.conf . Add or modify the following line, substituting
the correct value of 6 for STOREMB:
max_log_file = STOREMB
Set the value to 6 (MB) or higher for general-purpose systems.
Larger values, of course,
support retention of even more audit data. | Rationale: | The total storage for audit log files must be large enough to retain
log information over the period required. This is a function of the maximum
log file size and the number of logs retained. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_data_retention_max_log_file | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 3, 4, 5, 6, 7, 8 | cjis | 5.4.1.1 | cobit5 | APO11.04, APO12.06, BAI03.05, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, MEA02.01 | isa-62443-2009 | 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1 | iso27001-2013 | A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.16.1.4, A.16.1.5, A.16.1.7 | nerc-cip | CIP-004-6 R2.2.3, CIP-004-6 R3.3, CIP-007-3 R5.2, CIP-007-3 R5.3.1, CIP-007-3 R5.3.2, CIP-007-3 R5.3.3, CIP-007-3 R6.5 | nist | AU-11, CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, PR.PT-1, RS.AN-1, RS.AN-4 | pcidss | Req-10.7 | cis | 5.2.2.1 |
| |
|
Rule
Configure auditd max_log_file_action Upon Reaching Maximum Log Size
[ref] | The default action to take when the logs reach their maximum size
is to rotate the log files, discarding the oldest one. To configure the action taken
by auditd , add or correct the line in /etc/audit/auditd.conf :
max_log_file_action = ACTION
Possible values for ACTION are described in the auditd.conf man
page. These include:
ignore syslog suspend rotate keep_logs
Set the ACTION to keep_logs .
The setting is case-insensitive. | Rationale: | Automatically rotating logs (by setting this to rotate )
minimizes the chances of the system unexpectedly running out of disk space by
being overwhelmed with log data. However, for systems that must never discard
log data, or which use external processes to transfer it and reclaim space,
keep_logs can be employed. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_data_retention_max_log_file_action | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8 | cjis | 5.4.1.1 | cobit5 | APO11.04, APO12.06, APO13.01, BAI03.05, BAI04.04, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, MEA02.01 | disa | CCI-000140 | hipaa | 164.312(a)(2)(ii) | isa-62443-2009 | 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, SR 7.1, SR 7.2 | iso27001-2013 | A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.16.1.4, A.16.1.5, A.16.1.7, A.17.2.1 | nist | AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, PR.DS-4, PR.PT-1, RS.AN-1, RS.AN-4 | pcidss | Req-10.7 | os-srg | SRG-OS-000047-GPOS-00023 | cis | 5.2.2.2 |
| |
|
Rule
Configure auditd space_left Action on Low Disk Space
[ref] | The auditd service can be configured to take an action
when disk space starts to run low.
Edit the file /etc/audit/auditd.conf . Modify the following line,
substituting ACTION appropriately:
space_left_action = ACTION
Possible values for ACTION are described in the auditd.conf man page.
These include:
syslog email exec suspend single halt
Set this to email (instead of the default,
which is suspend ) as it is more likely to get prompt attention. Acceptable values
also include suspend , single , and halt . | Rationale: | Notifying administrators of an impending disk space problem may
allow them to take corrective action prior to any disruption. | Severity: | medium | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_data_retention_space_left_action | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8 | cjis | 5.4.1.1 | cobit5 | APO11.04, APO12.06, APO13.01, BAI03.05, BAI04.04, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, MEA02.01 | cui | 3.3.1 | disa | CCI-001855 | hipaa | 164.312(a)(2)(ii) | isa-62443-2009 | 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4 | isa-62443-2013 | SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, SR 7.1, SR 7.2 | iso27001-2013 | A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.16.1.4, A.16.1.5, A.16.1.7, A.17.2.1 | nist | AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a) | nist-csf | DE.AE-3, DE.AE-5, PR.DS-4, PR.PT-1, RS.AN-1, RS.AN-4 | pcidss | Req-10.7 | os-srg | SRG-OS-000343-GPOS-00134 | cis | 5.2.2.3 | pcidss4 | 10.5.1, 10.5 |
| |
|
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-000130, CCI-000131, CCI-000132, CCI-000133, CCI-000134, CCI-000135, CCI-000154, CCI-000158, CCI-000172, CCI-001464, CCI-001487, CCI-001814, CCI-001875, CCI-001876, CCI-001877, CCI-001878, CCI-001879, CCI-001880, CCI-001881, CCI-001882, CCI-001889, CCI-001914, CCI-002884, CCI-000169, CCI-003938 | 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 | cis | 5.2.1.1 | 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-000126, CCI-000130, CCI-000131, CCI-000132, CCI-000133, CCI-000134, CCI-000135, CCI-000154, CCI-000158, CCI-000172, CCI-000366, CCI-001464, CCI-001487, CCI-001814, CCI-001875, CCI-001876, CCI-001877, CCI-002884, CCI-001878, CCI-001879, CCI-001880, CCI-001881, CCI-001882, CCI-001889, CCI-001914, CCI-000169, CCI-003938 | 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 | cis | 5.2.1.4 | pcidss4 | 10.2.1, 10.2 |
| |
|
Rule
Enable Auditing for Processes Which Start Prior to the Audit Daemon
[ref] | To ensure all processes can be audited, even those which start
prior to the audit daemon, add the argument audit=1 to the default
GRUB 2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain audit=1 as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) audit=1"
| Rationale: | Each process on the system carries an "auditable" flag which indicates whether
its activities can be audited. Although auditd takes care of enabling
this for all processes which launch after it does, adding the kernel argument
ensures it is set for every process during boot. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_audit_argument | References: | cis-csc | 1, 11, 12, 13, 14, 15, 16, 19, 3, 4, 5, 6, 7, 8 | 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.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.02, DSS05.03, DSS05.04, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01 | cui | 3.3.1 | disa | CCI-001464, CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-002884 | 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 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.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2 | nist | AC-17(1), AU-14(1), AU-10, CM-6(a), IR-5(1) | nist-csf | DE.AE-3, DE.AE-5, 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.3 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000473-GPOS-00218, SRG-OS-000254-GPOS-00095 | cis | 5.2.1.2 | pcidss4 | 10.7.2, 10.7 |
| |
|
Rule
Extend Audit Backlog Limit for the Audit Daemon
[ref] | To improve the kernel capacity to queue all log events, even those which occurred
prior to the audit daemon, add the argument audit_backlog_limit=8192 to the default
GRUB 2 command line for the Linux operating system.
Configure the default Grub2 kernel command line to contain audit_backlog_limit=8192 as follows:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) audit_backlog_limit=8192"
| Rationale: | audit_backlog_limit sets the queue length for audit events awaiting transfer
to the audit daemon. Until the audit daemon is up and running, all log messages
are stored in this queue. If the queue is overrun during boot process, the action
defined by audit failure flag is taken. | Severity: | low | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_audit_backlog_limit_argument | References: | disa | CCI-000130, CCI-000135, CCI-000169, CCI-000172, CCI-001849, CCI-002884 | nist | CM-6(a) | ospp | FAU_STG.1, FAU_STG.3 | os-srg | SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000062-GPOS-00031, SRG-OS-000254-GPOS-00095, SRG-OS-000341-GPOS-00132, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215 | cis | 5.2.1.3 | pcidss4 | 10.7.2, 10.7 |
| |
|