Guide to the Secure Configuration of Amazon Linux 2023
The SCAP Security Guide Project
https://www.open-scap.org/security-policies/scap-security-guide
https://www.open-scap.org/security-policies/scap-security-guide
This guide presents a catalog of security-relevant
configuration settings for Amazon Linux 2023. It is a rendering of
content structured in the eXtensible Configuration Checklist Description Format (XCCDF)
in order to support security automation. The SCAP content is
is available in the
Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.
scap-security-guide package which is developed at
https://www.open-scap.org/security-policies/scap-security-guide.
Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.
Do not attempt to implement any of the settings in
this guide without first testing them in a non-operational environment. The
creators of this guidance assume no responsibility whatsoever for its use by
other parties, and makes no guarantees, expressed or implied, about its
quality, reliability, or any other characteristic.
Evaluation Characteristics
| Evaluation target | ip-172-31-90-234.ec2.internal |
|---|---|
| Benchmark URL | #scap_org.open-scap_comp_ssg-al2023-xccdf.xml |
| Benchmark ID | xccdf_org.ssgproject.content_benchmark_AL-2023 |
| Benchmark version | 0.1.79 |
| Profile ID | xccdf_pelotech_profile_cis_fips |
| Started at | 2026-03-29T19:51:33+00:00 |
| Finished at | 2026-03-29T19:53:37+00:00 |
| Performed by | ec2-user |
| Test system | cpe:/a:redhat:openscap:1.3.13 |
CPE Platforms
- cpe:/o:amazon:amazon_linux:2023
Addresses
- IPv4 127.0.0.1
- IPv4 172.31.90.234
- IPv6 0:0:0:0:0:0:0:1
- IPv6 fe80:0:0:0:1070:81ff:feb5:921f
- MAC 00:00:00:00:00:00
- MAC 12:70:81:B5:92:1F
Compliance and Scoring
There were no failed or uncertain rules. It seems that no action is necessary.
Rule results
Score
| Scoring system | Score | Maximum | Percent |
|---|---|---|---|
| urn:xccdf:scoring:default | 100.000000 | 100.000000 |
Rule Overview
Result Details
Install AIDExccdf_org.ssgproject.content_rule_package_aide_installed medium
Install AIDE
| Rule ID | xccdf_org.ssgproject.content_rule_package_aide_installed | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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. |
Build and Test AIDE Databasexccdf_org.ssgproject.content_rule_aide_build_database medium
Build and Test AIDE Database
| Rule ID | xccdf_org.ssgproject.content_rule_aide_build_database | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | Run the following command to generate a new database:
$ sudo /usr/sbin/aide --initBy 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.gzTo initiate a manual check, run the following command: $ sudo /usr/sbin/aide --checkIf 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. | ||||||||||||||||||||||||||
| Warnings | warning
In RHEL Image Mode (bootc) systems, the AIDE database must be regenerated after each system update.
Image Mode systems receive updates through new container images that may include modified files.
After applying system updates, run the following commands to regenerate the AIDE database:
$ sudo /usr/sbin/aide --initThen replace the existing database: $ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gzFailure to regenerate the AIDE database after updates will result in false positive alerts for legitimate system changes introduced by the update process. |
Configure AIDE to Verify the Audit Toolsxccdf_org.ssgproject.content_rule_aide_check_audit_tools medium
Configure AIDE to Verify the Audit Tools
| Rule ID | xccdf_org.ssgproject.content_rule_aide_check_audit_tools | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||
| Severity | medium | ||||||
| References: |
| ||||||
| Description | 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. |
Configure Periodic Execution of AIDExccdf_org.ssgproject.content_rule_aide_periodic_cron_checking medium
Configure Periodic Execution of AIDE
| Rule ID | xccdf_org.ssgproject.content_rule_aide_periodic_cron_checking | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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 --checkTo 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 --checkAIDE 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. |
Configure System Cryptography Policyxccdf_org.ssgproject.content_rule_configure_crypto_policy high
Configure System Cryptography Policy
| Rule ID | xccdf_org.ssgproject.content_rule_configure_crypto_policy | ||||||||||||||||
| Result | pass | ||||||||||||||||
| Multi-check rule | no | ||||||||||||||||
| OVAL Definition ID | oval:ssg-configure_crypto_policy:def:1 | ||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||
| Severity | high | ||||||||||||||||
| References: |
| ||||||||||||||||
| Description | To configure the system cryptography policy to use ciphers only from the FIPS
policy, run the following command:
$ sudo update-crypto-policies --set FIPS
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. | ||||||||||||||||
| 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. | ||||||||||||||||
| Warnings | 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. |
OVAL test results details
check for crypto policy correctly configured in /etc/crypto-policies/config oval:ssg-test_configure_crypto_policy:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| true | /etc/crypto-policies/config | FIPS |
check for crypto policy correctly configured in /etc/crypto-policies/state/current oval:ssg-test_configure_crypto_policy_current:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| true | /etc/crypto-policies/state/current | FIPS |
Check if update-crypto-policies has been run oval:ssg-test_crypto_policies_updated:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Var ref | Value |
|---|---|---|
| true | oval:ssg-variable_crypto_policies_config_file_timestamp:var:1 | 1774813696 |
Check if /etc/crypto-policies/back-ends/nss.config exists oval:ssg-test_crypto_policy_nss_config:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| not evaluated | /etc/crypto-policies/back-ends/nss.config | symbolic link | 0 | 0 | 39 | rwxrwxrwx |
Configure SSH to use System Crypto Policyxccdf_org.ssgproject.content_rule_configure_ssh_crypto_policy medium
Configure SSH to use System Crypto Policy
| Rule ID | xccdf_org.ssgproject.content_rule_configure_ssh_crypto_policy | ||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||
| Severity | medium | ||||||||||||||||||
| References: |
| ||||||||||||||||||
| Description | 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. |
Ensure /dev/shm is configuredxccdf_org.ssgproject.content_rule_partition_for_dev_shm low
Ensure /dev/shm is configured
| Rule ID | xccdf_org.ssgproject.content_rule_partition_for_dev_shm | ||
| Result | pass | ||
| Multi-check rule | no | ||
| OVAL Definition ID | oval:ssg-partition_for_dev_shm:def:1 | ||
| Time | 2026-03-29T19:51:33+00:00 | ||
| Severity | low | ||
| References: |
| ||
| Description | 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. | ||
| 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. | ||
| Warnings | warning
This rule does not have a remediation.
It is expected that this will be managed by systemd and will be a tmpfs partition. |
OVAL test results details
/dev/shm on own partition oval:ssg-testdev_shm_partition:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Mount point | Device | Uuid | Fs type | Mount options | Mount options | Mount options | Mount options | Mount options | Total space | Space used | Space left |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| not evaluated | /dev/shm | tmpfs | tmpfs | rw | seclabel | nosuid | nodev | noexec | 117863 | 0 | 117863 |
Ensure /tmp Located On Separate Partitionxccdf_org.ssgproject.content_rule_partition_for_tmp low
Ensure /tmp Located On Separate Partition
| Rule ID | xccdf_org.ssgproject.content_rule_partition_for_tmp | ||||||||||||||||
| Result | pass | ||||||||||||||||
| Multi-check rule | no | ||||||||||||||||
| OVAL Definition ID | oval:ssg-partition_for_tmp:def:1 | ||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||
| Severity | low | ||||||||||||||||
| References: |
| ||||||||||||||||
| Description | 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. |
OVAL test results details
/tmp on own partition oval:ssg-testtmp_partition:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Mount point | Device | Uuid | Fs type | Mount options | Mount options | Mount options | Mount options | Mount options | Total space | Space used | Space left |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| not evaluated | /tmp | tmpfs | tmpfs | rw | seclabel | nosuid | nodev | noexec | 117863 | 42994 | 74869 |
Install sudo Packagexccdf_org.ssgproject.content_rule_package_sudo_installed medium
Install sudo Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_sudo_installed | ||||||||||||||
| Result | notapplicable | ||||||||||||||
| Multi-check rule | no | ||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||
| Severity | medium | ||||||||||||||
| References: |
| ||||||||||||||
| Description | 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. |
Ensure Only Users Logged In To Real tty Can Execute Sudo - sudo use_ptyxccdf_org.ssgproject.content_rule_sudo_add_use_pty medium
Ensure Only Users Logged In To Real tty Can Execute Sudo - sudo use_pty
| Rule ID | xccdf_org.ssgproject.content_rule_sudo_add_use_pty | ||||||||
| Result | notapplicable | ||||||||
| Multi-check rule | no | ||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||
| Severity | medium | ||||||||
| References: |
| ||||||||
| Description | 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. |
Ensure Sudo Logfile Exists - sudo logfilexccdf_org.ssgproject.content_rule_sudo_custom_logfile low
Ensure Sudo Logfile Exists - sudo logfile
| Rule ID | xccdf_org.ssgproject.content_rule_sudo_custom_logfile | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||
| Severity | low | ||||||
| References: |
| ||||||
| Description | 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. |
Require Re-Authentication When Using the sudo Commandxccdf_org.ssgproject.content_rule_sudo_require_reauthentication medium
Require Re-Authentication When Using the sudo Command
| Rule ID | xccdf_org.ssgproject.content_rule_sudo_require_reauthentication | ||||||||
| Result | notapplicable | ||||||||
| Multi-check rule | no | ||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||
| Severity | medium | ||||||||
| References: |
| ||||||||
| Description | 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. |
Ensure gpgcheck Enabled In Main dnf Configurationxccdf_org.ssgproject.content_rule_ensure_gpgcheck_globally_activated high
Ensure gpgcheck Enabled In Main dnf Configuration
| Rule ID | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_globally_activated | ||||||||||||||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-ensure_gpgcheck_globally_activated:def:1 | ||||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||||||||
| Severity | high | ||||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||||
| Description | 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). |
OVAL test results details
check value of gpgcheck in /etc/dnf/dnf.conf oval:ssg-test_ensure_gpgcheck_globally_activated:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/dnf/dnf.conf | gpgcheck=True |
Verify Group Ownership of System Login Bannerxccdf_org.ssgproject.content_rule_file_groupowner_etc_issue medium
Verify Group Ownership of System Login Banner
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_etc_issue | ||
| Result | pass | ||
| Multi-check rule | no | ||
| OVAL Definition ID | oval:ssg-file_groupowner_etc_issue:def:1 | ||
| Time | 2026-03-29T19:51:33+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description |
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. |
OVAL test results details
Testing group ownership of /etc/issue oval:ssg-test_file_groupowner_etc_issue_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_groupowner_etc_issue_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/issue | oval:ssg-symlink_file_groupowner:ste:1 | oval:ssg-state_file_groupowner_etc_issue_0_0:ste:1 |
Verify Group Ownership of System Login Banner for Remote Connectionsxccdf_org.ssgproject.content_rule_file_groupowner_etc_issue_net medium
Verify Group Ownership of System Login Banner for Remote Connections
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_etc_issue_net | ||||
| Result | pass | ||||
| Multi-check rule | no | ||||
| OVAL Definition ID | oval:ssg-file_groupowner_etc_issue_net:def:1 | ||||
| Time | 2026-03-29T19:51:33+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description |
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. |
OVAL test results details
Testing group ownership of /etc/issue.net oval:ssg-test_file_groupowner_etc_issue_net_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_groupowner_etc_issue_net_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/issue.net | oval:ssg-symlink_file_groupowner:ste:1 | oval:ssg-state_file_groupowner_etc_issue_net_0_0:ste:1 |
Verify Group Ownership of Message of the Day Bannerxccdf_org.ssgproject.content_rule_file_groupowner_etc_motd medium
Verify Group Ownership of Message of the Day Banner
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_etc_motd | ||
| Result | pass | ||
| Multi-check rule | no | ||
| OVAL Definition ID | oval:ssg-file_groupowner_etc_motd:def:1 | ||
| Time | 2026-03-29T19:51:33+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description |
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. |
OVAL test results details
Testing group ownership of /etc/motd oval:ssg-test_file_groupowner_etc_motd_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_groupowner_etc_motd_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/motd | oval:ssg-symlink_file_groupowner:ste:1 | oval:ssg-state_file_groupowner_etc_motd_0_0:ste:1 |
Verify ownership of System Login Bannerxccdf_org.ssgproject.content_rule_file_owner_etc_issue medium
Verify ownership of System Login Banner
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_etc_issue | ||
| Result | pass | ||
| Multi-check rule | no | ||
| OVAL Definition ID | oval:ssg-file_owner_etc_issue:def:1 | ||
| Time | 2026-03-29T19:51:33+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description |
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. |
OVAL test results details
Testing user ownership of /etc/issue oval:ssg-test_file_owner_etc_issue_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_owner_etc_issue_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/issue | oval:ssg-symlink_file_owner:ste:1 | oval:ssg-state_file_owner_etc_issue_0_0:ste:1 |
Verify ownership of System Login Banner for Remote Connectionsxccdf_org.ssgproject.content_rule_file_owner_etc_issue_net medium
Verify ownership of System Login Banner for Remote Connections
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_etc_issue_net | ||||
| Result | pass | ||||
| Multi-check rule | no | ||||
| OVAL Definition ID | oval:ssg-file_owner_etc_issue_net:def:1 | ||||
| Time | 2026-03-29T19:51:33+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description |
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. |
OVAL test results details
Testing user ownership of /etc/issue.net oval:ssg-test_file_owner_etc_issue_net_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_owner_etc_issue_net_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/issue.net | oval:ssg-symlink_file_owner:ste:1 | oval:ssg-state_file_owner_etc_issue_net_0_0:ste:1 |
Verify ownership of Message of the Day Bannerxccdf_org.ssgproject.content_rule_file_owner_etc_motd medium
Verify ownership of Message of the Day Banner
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_etc_motd | ||
| Result | pass | ||
| Multi-check rule | no | ||
| OVAL Definition ID | oval:ssg-file_owner_etc_motd:def:1 | ||
| Time | 2026-03-29T19:51:33+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description |
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. |
OVAL test results details
Testing user ownership of /etc/motd oval:ssg-test_file_owner_etc_motd_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_owner_etc_motd_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/motd | oval:ssg-symlink_file_owner:ste:1 | oval:ssg-state_file_owner_etc_motd_0_0:ste:1 |
Configure the Use of the pam_faillock.so Module in the /etc/pam.d/password-auth File.xccdf_org.ssgproject.content_rule_account_password_pam_faillock_password_auth medium
Configure the Use of the pam_faillock.so Module in the /etc/pam.d/password-auth File.
| Rule ID | xccdf_org.ssgproject.content_rule_account_password_pam_faillock_password_auth | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||
| Severity | medium | ||||||
| References: |
| ||||||
| Description | 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. |
Configure the Use of the pam_faillock.so Module in the /etc/pam.d/system-auth File.xccdf_org.ssgproject.content_rule_account_password_pam_faillock_system_auth medium
Configure the Use of the pam_faillock.so Module in the /etc/pam.d/system-auth File.
| Rule ID | xccdf_org.ssgproject.content_rule_account_password_pam_faillock_system_auth | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||
| Severity | medium | ||||||
| References: |
| ||||||
| Description | 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. |
Limit Password Reuse: password-authxccdf_org.ssgproject.content_rule_accounts_password_pam_pwhistory_remember_password_auth medium
Limit Password Reuse: password-auth
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_password_pam_pwhistory_remember_password_auth | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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-pwhistoryOtherwise, 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
| ||||||||||||||||||||||||||
| Rationale | Preventing reuse of previous passwords helps ensure that a compromised password is not
reused by a user. | ||||||||||||||||||||||||||
| Warnings | 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. |
Limit Password Reuse: system-authxccdf_org.ssgproject.content_rule_accounts_password_pam_pwhistory_remember_system_auth medium
Limit Password Reuse: system-auth
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_password_pam_pwhistory_remember_system_auth | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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-pwhistoryOtherwise, 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
| ||||||||||||||||||||||||||
| Rationale | Preventing reuse of previous passwords helps ensure that a compromised password is not
reused by a user. | ||||||||||||||||||||||||||
| Warnings | 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. |
Lock Accounts After Failed Password Attemptsxccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny medium
Lock Accounts After Failed Password Attempts
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | 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. | ||||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||||
| Warnings | 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. |
Set Lockout Time for Failed Password Attemptsxccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_unlock_time medium
Set Lockout Time for Failed Password Attempts
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_unlock_time | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | 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. | ||||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||||
| Warnings | 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. |
Ensure PAM Enforces Password Requirements - Minimum Different Categoriesxccdf_org.ssgproject.content_rule_accounts_password_pam_minclass medium
Ensure PAM Enforces Password Requirements - Minimum Different Categories
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_password_pam_minclass | ||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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. |
Ensure PAM Enforces Password Requirements - Minimum Lengthxccdf_org.ssgproject.content_rule_accounts_password_pam_minlen medium
Ensure PAM Enforces Password Requirements - Minimum Length
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_password_pam_minlen | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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. |
Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Sessionxccdf_org.ssgproject.content_rule_accounts_password_pam_retry medium
Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_password_pam_retry | ||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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 profile requirement is a maximum of retry=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. |
Set Password Hashing Algorithm in /etc/login.defsxccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_logindefs medium
Set Password Hashing Algorithm in /etc/login.defs
| Rule ID | xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_logindefs | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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. |
Set PAM''s Password Hashing Algorithm - password-authxccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_passwordauth medium
Set PAM''s Password Hashing Algorithm - password-auth
| Rule ID | xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_passwordauth | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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. | ||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||
| Warnings | 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. |
Set PAM''s Password Hashing Algorithmxccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_systemauth medium
Set PAM''s Password Hashing Algorithm
| Rule ID | xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_systemauth | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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. | ||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||
| Warnings | 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. |
Set Account Expiration Following Inactivityxccdf_org.ssgproject.content_rule_account_disable_post_pw_expiration medium
Set Account Expiration Following Inactivity
| Rule ID | xccdf_org.ssgproject.content_rule_account_disable_post_pw_expiration | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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. |
Ensure All Accounts on the System Have Unique Namesxccdf_org.ssgproject.content_rule_account_unique_name medium
Ensure All Accounts on the System Have Unique Names
| Rule ID | xccdf_org.ssgproject.content_rule_account_unique_name | ||||||||
| Result | notapplicable | ||||||||
| Multi-check rule | no | ||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||
| Severity | medium | ||||||||
| References: |
| ||||||||
| Description | 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. |
Set Password Maximum Agexccdf_org.ssgproject.content_rule_accounts_maximum_age_login_defs medium
Set Password Maximum Age
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_maximum_age_login_defs | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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
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. |
Set Password Minimum Agexccdf_org.ssgproject.content_rule_accounts_minimum_age_login_defs medium
Set Password Minimum Age
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_minimum_age_login_defs | ||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||
| Description | 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 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. |
Set Existing Passwords Maximum Agexccdf_org.ssgproject.content_rule_accounts_password_set_max_life_existing medium
Set Existing Passwords Maximum Age
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_password_set_max_life_existing | ||||||||
| Result | notapplicable | ||||||||
| Multi-check rule | no | ||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||
| Severity | medium | ||||||||
| References: |
| ||||||||
| Description | 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. |
Set Existing Passwords Minimum Agexccdf_org.ssgproject.content_rule_accounts_password_set_min_life_existing medium
Set Existing Passwords Minimum Age
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_password_set_min_life_existing | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||
| Severity | medium | ||||||
| References: |
| ||||||
| Description | 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. |
Set Existing Passwords Warning Agexccdf_org.ssgproject.content_rule_accounts_password_set_warn_age_existing medium
Set Existing Passwords Warning Age
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_password_set_warn_age_existing | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||
| Severity | medium | ||||||
| References: |
| ||||||
| Description | 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
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. |
Set Password Warning Agexccdf_org.ssgproject.content_rule_accounts_password_warn_age_login_defs medium
Set Password Warning Age
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_password_warn_age_login_defs | ||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||
| Description | 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 profile requirement is 7. | ||||||||||||||||||||||||
| Rationale | Setting the password warning age enables users to
make the change at a practical time. |
Set existing passwords a period of inactivity before they been lockedxccdf_org.ssgproject.content_rule_accounts_set_post_pw_existing medium
Set existing passwords a period of inactivity before they been locked
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_set_post_pw_existing | ||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||
| Description | 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 30 USER | ||||||||||||||||||||||||
| Rationale | Inactive accounts pose a threat to system security since the users are not logging in to
notice failed login attempts or other anomalies. |
Verify All Account Password Hashes are Shadowedxccdf_org.ssgproject.content_rule_accounts_password_all_shadowed medium
Verify All Account Password Hashes are Shadowed
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_password_all_shadowed | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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. |
Ensure all users last password change date is in the pastxccdf_org.ssgproject.content_rule_accounts_password_last_change_is_in_past medium
Ensure all users last password change date is in the past
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_password_last_change_is_in_past | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:51:33+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | All users should have a password change date in the past. | ||||
| Rationale | If a user recorded password change date is in the future then they could
bypass any set password expiration. | ||||
| Warnings | warning
Automatic remediation is not available, in order to avoid any system disruption. |
All GIDs referenced in /etc/passwd must be defined in /etc/groupxccdf_org.ssgproject.content_rule_gid_passwd_group_same low
All GIDs referenced in /etc/passwd must be defined in /etc/group
| Rule ID | xccdf_org.ssgproject.content_rule_gid_passwd_group_same | ||||||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-gid_passwd_group_same:def:1 | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||
| Severity | low | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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. |
OVAL test results details
Verify all GIDs referenced in /etc/passwd are defined in /etc/group oval:ssg-test_gid_passwd_group_same:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| true | /etc/passwd | root:x:0:0: |
| true | /etc/passwd | bin:x:1:1: |
| true | /etc/passwd | daemon:x:2:2: |
| true | /etc/passwd | adm:x:3:4: |
| true | /etc/passwd | lp:x:4:7: |
| true | /etc/passwd | sync:x:5:0: |
| true | /etc/passwd | shutdown:x:6:0: |
| true | /etc/passwd | halt:x:7:0: |
| true | /etc/passwd | mail:x:8:12: |
| true | /etc/passwd | operator:x:11:0: |
| true | /etc/passwd | games:x:12:100: |
| true | /etc/passwd | ftp:x:14:50: |
| true | /etc/passwd | nobody:x:65534:65534: |
| true | /etc/passwd | dbus:x:81:81: |
| true | /etc/passwd | systemd-network:x:192:192: |
| true | /etc/passwd | systemd-oom:x:998:998: |
| true | /etc/passwd | chrony:x:997:997: |
| true | /etc/passwd | sshd:x:74:74: |
| true | /etc/passwd | systemd-coredump:x:996:996: |
| true | /etc/passwd | systemd-resolve:x:193:193: |
| true | /etc/passwd | systemd-timesync:x:995:995: |
| true | /etc/passwd | ec2-user:x:1000:1000: |
| true | /etc/passwd | cwagent:x:994:994: |
Ensure There Are No Accounts With Blank or Null Passwordsxccdf_org.ssgproject.content_rule_no_empty_passwords_etc_shadow high
Ensure There Are No Accounts With Blank or Null Passwords
| Rule ID | xccdf_org.ssgproject.content_rule_no_empty_passwords_etc_shadow | ||||||||
| Result | notapplicable | ||||||||
| Multi-check rule | no | ||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||
| Severity | high | ||||||||
| References: |
| ||||||||
| Description | 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] | ||||||||
| 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. | ||||||||
| Warnings | 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. |
Verify No .forward Files Existxccdf_org.ssgproject.content_rule_no_forward_files medium
Verify No .forward Files Exist
| Rule ID | xccdf_org.ssgproject.content_rule_no_forward_files | ||
| Result | notapplicable | ||
| Multi-check rule | no | ||
| Time | 2026-03-29T19:51:33+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description | 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. |
Verify Only Root Has UID 0xccdf_org.ssgproject.content_rule_accounts_no_uid_except_zero high
Verify Only Root Has UID 0
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_no_uid_except_zero | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||
| Severity | high | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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. |
Verify Root Has A Primary GID 0xccdf_org.ssgproject.content_rule_accounts_root_gid_zero high
Verify Root Has A Primary GID 0
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_root_gid_zero | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||
| Severity | high | ||||||
| References: |
| ||||||
| Description | 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. |
Ensure the Group Used by pam_wheel.so Module Exists on System and is Emptyxccdf_org.ssgproject.content_rule_ensure_pam_wheel_group_empty medium
Ensure the Group Used by pam_wheel.so Module Exists on System and is Empty
| Rule ID | xccdf_org.ssgproject.content_rule_ensure_pam_wheel_group_empty | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:51:33+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. | ||||
| 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. | ||||
| Warnings | 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. |
Ensure Authentication Required for Single User Modexccdf_org.ssgproject.content_rule_ensure_root_password_configured medium
Ensure Authentication Required for Single User Mode
| Rule ID | xccdf_org.ssgproject.content_rule_ensure_root_password_configured | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:51:33+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
Ensure that System Accounts Are Lockedxccdf_org.ssgproject.content_rule_no_password_auth_for_systemaccounts medium
Ensure that System Accounts Are Locked
| Rule ID | xccdf_org.ssgproject.content_rule_no_password_auth_for_systemaccounts | ||||||||
| Result | notapplicable | ||||||||
| Multi-check rule | no | ||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||
| Severity | medium | ||||||||
| References: |
| ||||||||
| Description | 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. |
Ensure that System Accounts Do Not Run a Shell Upon Loginxccdf_org.ssgproject.content_rule_no_shelllogin_for_systemaccounts medium
Ensure that System Accounts Do Not Run a Shell Upon Login
| Rule ID | xccdf_org.ssgproject.content_rule_no_shelllogin_for_systemaccounts | ||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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
| ||||||||||||||||||||||
| Rationale | Ensuring shells are not given to system accounts upon login makes it more difficult for
attackers to make use of system accounts. | ||||||||||||||||||||||
| Warnings | warning
Do not perform the steps in this section on the root account. Doing so might cause the
system to become inaccessible. |
Enforce Usage of pam_wheel with Group Parameter for su Authenticationxccdf_org.ssgproject.content_rule_use_pam_wheel_group_for_su medium
Enforce Usage of pam_wheel with Group Parameter for su Authentication
| Rule ID | xccdf_org.ssgproject.content_rule_use_pam_wheel_group_for_su | ||||
| Result | pass | ||||
| Multi-check rule | no | ||||
| OVAL Definition ID | oval:ssg-use_pam_wheel_group_for_su:def:1 | ||||
| Time | 2026-03-29T19:51:33+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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
| ||||
| 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. | ||||
| Warnings | warning
Note that ensure_pam_wheel_group_empty rule complements this requirement by
ensuring the referenced group exists and has no members. |
OVAL test results details
check /etc/pam.d/su for correct setting oval:ssg-test_use_pam_wheel_group_for_su:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| true | /etc/pam.d/su | auth required pam_wheel.so use_uid group=sugroup |
Ensure All Accounts on the System Have Unique User IDsxccdf_org.ssgproject.content_rule_account_unique_id medium
Ensure All Accounts on the System Have Unique User IDs
| Rule ID | xccdf_org.ssgproject.content_rule_account_unique_id | ||||||||
| Result | notapplicable | ||||||||
| Multi-check rule | no | ||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||
| Severity | medium | ||||||||
| References: |
| ||||||||
| Description | Change user IDs (UIDs), or delete accounts, so each has a unique name. | ||||||||
| Rationale | To assure accountability and prevent unauthenticated access, interactive users must be identified and authenticated to prevent potential misuse and compromise of the system. | ||||||||
| Warnings | warning
Automatic remediation of this control is not available due to unique requirements of each
system. |
Ensure All Groups on the System Have Unique Group IDxccdf_org.ssgproject.content_rule_group_unique_id medium
Ensure All Groups on the System Have Unique Group ID
| Rule ID | xccdf_org.ssgproject.content_rule_group_unique_id | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||
| Severity | medium | ||||||
| References: |
| ||||||
| Description | Change the group name or delete groups, so each has a unique id. | ||||||
| Rationale | To assure accountability and prevent unauthenticated access, groups must be identified uniquely to prevent potential misuse and compromise of the system. | ||||||
| Warnings | warning
Automatic remediation of this control is not available due to the unique requirements of each system. |
Ensure All Groups on the System Have Unique Group Namesxccdf_org.ssgproject.content_rule_group_unique_name medium
Ensure All Groups on the System Have Unique Group Names
| Rule ID | xccdf_org.ssgproject.content_rule_group_unique_name | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:51:33+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | Change the group name or delete groups, so each has a unique name. | ||||
| Rationale | To assure accountability and prevent unauthenticated access, groups must be identified uniquely to prevent potential misuse and compromise of the system. | ||||
| Warnings | warning
Automatic remediation of this control is not available due to the unique requirements of each system. |
Ensure that Root's Path Does Not Include World or Group-Writable Directoriesxccdf_org.ssgproject.content_rule_accounts_root_path_dirs_no_write medium
Ensure that Root's Path Does Not Include World or Group-Writable Directories
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_root_path_dirs_no_write | ||||||||||||||||
| Result | pass | ||||||||||||||||
| Multi-check rule | no | ||||||||||||||||
| OVAL Definition ID | oval:ssg-accounts_root_path_dirs_no_write:def:1 | ||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||
| Severity | medium | ||||||||||||||||
| References: |
| ||||||||||||||||
| Description | 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. |
OVAL test results details
Check if there aren't directories in root's path having write permission set for group or other oval:ssg-test_accounts_root_path_dirs_no_group_other_write:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_accounts_root_path_dirs_no_group_other_write:obj:1 of type file_object
| Path | Filename | Filter | Filter | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
| oval:ssg-state_accounts_root_path_dirs_wrong_perms:ste:1 | oval:ssg-state_accounts_root_path_dirs_symlink:ste:1 |
Ensure that Root's Path Does Not Include Relative Paths or Null Directoriesxccdf_org.ssgproject.content_rule_root_path_no_dot unknown
Ensure that Root's Path Does Not Include Relative Paths or Null Directories
| Rule ID | xccdf_org.ssgproject.content_rule_root_path_no_dot | ||||||||||||||||
| Result | pass | ||||||||||||||||
| Multi-check rule | no | ||||||||||||||||
| OVAL Definition ID | oval:ssg-root_path_no_dot:def:1 | ||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||
| Severity | unknown | ||||||||||||||||
| References: |
| ||||||||||||||||
| Description | 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::/sbinThese 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. |
OVAL test results details
environment variable PATH starts with : or . oval:ssg-test_env_var_begins:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Pid | Name | Value |
|---|---|---|---|
| false | 2328 | PATH | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/snapd/snap/bin |
environment variable PATH doesn't contain : twice in a row oval:ssg-test_env_var_contains_doublecolon:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Pid | Name | Value |
|---|---|---|---|
| false | 2328 | PATH | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/snapd/snap/bin |
environment variable PATH doesn't contain . twice in a row oval:ssg-test_env_var_contains_doubleperiod:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Pid | Name | Value |
|---|---|---|---|
| false | 2328 | PATH | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/snapd/snap/bin |
environment variable PATH ends with : or . oval:ssg-test_env_var_ends:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Pid | Name | Value |
|---|---|---|---|
| false | 2328 | PATH | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/snapd/snap/bin |
environment variable PATH starts with an absolute path / oval:ssg-test_env_var_begins_slash:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Pid | Name | Value |
|---|---|---|---|
| false | 2328 | PATH | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/snapd/snap/bin |
environment variable PATH contains relative paths oval:ssg-test_env_var_contains_relative_path:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Pid | Name | Value |
|---|---|---|---|
| false | 2328 | PATH | /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/lib/snapd/snap/bin |
Ensure the Default Bash Umask is Set Correctlyxccdf_org.ssgproject.content_rule_accounts_umask_etc_bashrc medium
Ensure the Default Bash Umask is Set Correctly
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_umask_etc_bashrc | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description | 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. |
Ensure the Default Umask is Set Correctly in login.defsxccdf_org.ssgproject.content_rule_accounts_umask_etc_login_defs medium
Ensure the Default Umask is Set Correctly in login.defs
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_umask_etc_login_defs | ||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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. |
Ensure the Default Umask is Set Correctly in /etc/profilexccdf_org.ssgproject.content_rule_accounts_umask_etc_profile medium
Ensure the Default Umask is Set Correctly in /etc/profile
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_umask_etc_profile | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description | 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 scripts 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. |
Set Interactive Session Timeoutxccdf_org.ssgproject.content_rule_accounts_tmout medium
Set Interactive Session Timeout
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_tmout | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | Setting the TMOUT option in /etc/profile ensures that
all user sessions will terminate based on inactivity. A value of 0 (zero)
disables the automatic logout feature and is therefore not a compliant setting.
The value of TMOUT should be a positive integer, 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. |
User Initialization Files Must Be Group-Owned By The Primary Groupxccdf_org.ssgproject.content_rule_accounts_user_dot_group_ownership medium
User Initialization Files Must Be Group-Owned By The Primary Group
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_user_dot_group_ownership | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||
| Severity | medium | ||||||
| References: |
| ||||||
| Description | Change the group owner of interactive users files to the group found
in /etc/passwdfor 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. | ||||||
| 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. | ||||||
| Warnings | 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. |
User Initialization Files Must Be Owned By the Primary Userxccdf_org.ssgproject.content_rule_accounts_user_dot_user_ownership medium
User Initialization Files Must Be Owned By the Primary User
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_user_dot_user_ownership | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||
| Severity | medium | ||||||
| References: |
| ||||||
| Description | 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. | ||||||
| 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. | ||||||
| Warnings | 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. |
All Interactive Users Home Directories Must Existxccdf_org.ssgproject.content_rule_accounts_user_interactive_home_directory_exists medium
All Interactive Users Home Directories Must Exist
| Rule ID | xccdf_org.ssgproject.content_rule_accounts_user_interactive_home_directory_exists | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:51:33+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
All Interactive User Home Directories Must Be Group-Owned By The Primary Groupxccdf_org.ssgproject.content_rule_file_groupownership_home_directories medium
All Interactive User Home Directories Must Be Group-Owned By The Primary Group
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupownership_home_directories | ||||
| Result | pass | ||||
| Multi-check rule | no | ||||
| OVAL Definition ID | oval:ssg-file_groupownership_home_directories:def:1 | ||||
| Time | 2026-03-29T19:51:33+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. | ||||
| 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. | ||||
| Warnings | 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. |
OVAL test results details
All home directories are group-owned by a local interactive group oval:ssg-test_file_groupownership_home_directories:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| true | /home/ec2-user/ | directory | 1000 | 1000 | 74 | rwx------ |
All Interactive User Home Directories Must Be Owned By The Primary Userxccdf_org.ssgproject.content_rule_file_ownership_home_directories medium
All Interactive User Home Directories Must Be Owned By The Primary User
| Rule ID | xccdf_org.ssgproject.content_rule_file_ownership_home_directories | ||||
| Result | pass | ||||
| Multi-check rule | no | ||||
| OVAL Definition ID | oval:ssg-file_ownership_home_directories:def:1 | ||||
| Time | 2026-03-29T19:51:33+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. | ||||
| 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. | ||||
| Warnings | 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. |
OVAL test results details
All home directories are owned by a local interactive user oval:ssg-test_file_ownership_home_directories:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Type | UID | GID | Size (B) | Permissions |
|---|---|---|---|---|---|---|
| true | /home/ec2-user/ | directory | 1000 | 1000 | 74 | rwx------ |
It should not exist duplicated owners of home dirs oval:ssg-test_file_ownership_home_directories_duplicated:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Var ref | Value |
|---|---|---|
| true | oval:ssg-var_file_ownership_home_directories_uids_count:var:1 | 1 |
Verify /boot/grub2/grub.cfg Group Ownershipxccdf_org.ssgproject.content_rule_file_groupowner_grub2_cfg medium
Verify /boot/grub2/grub.cfg Group Ownership
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_grub2_cfg | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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. |
Verify /boot/grub2/user.cfg Group Ownershipxccdf_org.ssgproject.content_rule_file_groupowner_user_cfg medium
Verify /boot/grub2/user.cfg Group Ownership
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_user_cfg | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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. |
Verify /boot/grub2/grub.cfg User Ownershipxccdf_org.ssgproject.content_rule_file_owner_grub2_cfg medium
Verify /boot/grub2/grub.cfg User Ownership
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_grub2_cfg | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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. |
Verify /boot/grub2/user.cfg User Ownershipxccdf_org.ssgproject.content_rule_file_owner_user_cfg medium
Verify /boot/grub2/user.cfg User Ownership
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_user_cfg | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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. |
Ensure Log Files Are Owned By Appropriate Groupxccdf_org.ssgproject.content_rule_rsyslog_files_groupownership medium
Ensure Log Files Are Owned By Appropriate Group
| Rule ID | xccdf_org.ssgproject.content_rule_rsyslog_files_groupownership | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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. |
Ensure Log Files Are Owned By Appropriate Userxccdf_org.ssgproject.content_rule_rsyslog_files_ownership medium
Ensure Log Files Are Owned By Appropriate User
| Rule ID | xccdf_org.ssgproject.content_rule_rsyslog_files_ownership | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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. |
Enable systemd-journald Servicexccdf_org.ssgproject.content_rule_service_systemd-journald_enabled medium
Enable systemd-journald Service
| Rule ID | xccdf_org.ssgproject.content_rule_service_systemd-journald_enabled | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||
| Severity | medium | ||||||
| References: |
| ||||||
| Description | 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. |
Ensure journald is configured to compress large log filesxccdf_org.ssgproject.content_rule_journald_compress medium
Ensure journald is configured to compress large log files
| Rule ID | xccdf_org.ssgproject.content_rule_journald_compress | ||
| Result | notapplicable | ||
| Multi-check rule | no | ||
| Time | 2026-03-29T19:51:33+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description | 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. |
Ensure journald is configured to send logs to rsyslogxccdf_org.ssgproject.content_rule_journald_forward_to_syslog medium
Ensure journald is configured to send logs to rsyslog
| Rule ID | xccdf_org.ssgproject.content_rule_journald_forward_to_syslog | ||
| Result | notapplicable | ||
| Multi-check rule | no | ||
| Time | 2026-03-29T19:51:33+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description | 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. |
Ensure journald is configured to write log files to persistent diskxccdf_org.ssgproject.content_rule_journald_storage medium
Ensure journald is configured to write log files to persistent disk
| Rule ID | xccdf_org.ssgproject.content_rule_journald_storage | ||
| Result | notapplicable | ||
| Multi-check rule | no | ||
| Time | 2026-03-29T19:51:33+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description | 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 be lost upon reboot. | ||
| Rationale | Log files contain valuable data and need to be persistent to aid in possible investigations. |
Disable systemd-journal-remote Socketxccdf_org.ssgproject.content_rule_socket_systemd-journal-remote_disabled medium
Disable systemd-journal-remote Socket
| Rule ID | xccdf_org.ssgproject.content_rule_socket_systemd-journal-remote_disabled | ||
| Result | notapplicable | ||
| Multi-check rule | no | ||
| Time | 2026-03-29T19:51:33+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description | 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. |
Ensure rsyslog Does Not Accept Remote Messages Unless Acting As Log Serverxccdf_org.ssgproject.content_rule_rsyslog_nolisten medium
Ensure rsyslog Does Not Accept Remote Messages Unless Acting As Log Server
| Rule ID | xccdf_org.ssgproject.content_rule_rsyslog_nolisten | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description | 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. |
Ensure Logs Sent To Remote Hostxccdf_org.ssgproject.content_rule_rsyslog_remote_loghost medium
Ensure Logs Sent To Remote Host
| Rule ID | xccdf_org.ssgproject.content_rule_rsyslog_remote_loghost | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | To configure rsyslog to send logs to a remote log server,
open /etc/rsyslog.conf and read and understand the last section of the file,
which describes the multiple directives necessary to activate remote
logging.
Along with these other directives, the system can be configured
to forward its logs to a particular log server by
adding or correcting one of the following lines,
substituting logcollector appropriately.
The choice of protocol depends on the environment of the system;
although TCP and RELP provide more reliable message delivery,
they may not be supported in all environments.
To use UDP for log message delivery: *.* @logcollector
Or in RainerScript: *.* action(type="omfwd" ... target="logcollector" protocol="udp") To use TCP for log message delivery: *.* @@logcollector
Or in RainerScript: *.* action(type="omfwd" ... target="logcollector" protocol="tcp") To use RELP for log message delivery: *.* :omrelp:logcollector
Or in RainerScript: *.* action(type="omfwd" ... target="logcollector" protocol="relp") There must be a resolvable DNS CNAME or Alias record set to "logcollector" for logs to be sent correctly to the centralized logging utility. | ||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||
| Warnings | 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 -1Or if using Rainer Script syntax, it could be: *.* action(type="omfwd" queue.type="linkedlist" queue.filename="example_fwd" action.resumeRetryCount="-1" queue.saveOnShutdown="on" target="example.com" port="30514" protocol="tcp") |
Ensure rsyslog is Installedxccdf_org.ssgproject.content_rule_package_rsyslog_installed medium
Ensure rsyslog is Installed
| Rule ID | xccdf_org.ssgproject.content_rule_package_rsyslog_installed | ||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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. |
Ensure rsyslog Default File Permissions Configuredxccdf_org.ssgproject.content_rule_rsyslog_filecreatemode medium
Ensure rsyslog Default File Permissions Configured
| Rule ID | xccdf_org.ssgproject.content_rule_rsyslog_filecreatemode | ||
| Result | notapplicable | ||
| Multi-check rule | no | ||
| Time | 2026-03-29T19:51:33+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description | 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. |
Install firewalld Packagexccdf_org.ssgproject.content_rule_package_firewalld_installed medium
Install firewalld Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_firewalld_installed | ||||||||||||
| Result | notapplicable | ||||||||||||
| Multi-check rule | no | ||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||
| Severity | medium | ||||||||||||
| References: |
| ||||||||||||
| Description | 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 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)." |
Verify firewalld Enabledxccdf_org.ssgproject.content_rule_service_firewalld_enabled medium
Verify firewalld Enabled
| Rule ID | xccdf_org.ssgproject.content_rule_service_firewalld_enabled | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description |
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. |
Configure Firewalld to Restrict Loopback Trafficxccdf_org.ssgproject.content_rule_firewalld_loopback_traffic_restricted medium
Configure Firewalld to Restrict Loopback Traffic
| Rule ID | xccdf_org.ssgproject.content_rule_firewalld_loopback_traffic_restricted | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:51:33+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
Configure Firewalld to Trust Loopback Trafficxccdf_org.ssgproject.content_rule_firewalld_loopback_traffic_trusted medium
Configure Firewalld to Trust Loopback Traffic
| Rule ID | xccdf_org.ssgproject.content_rule_firewalld_loopback_traffic_trusted | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:51:33+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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=loTo 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. |
Set Default firewalld Zone for Incoming Packetsxccdf_org.ssgproject.content_rule_set_firewalld_default_zone medium
Set Default firewalld Zone for Incoming Packets
| Rule ID | xccdf_org.ssgproject.content_rule_set_firewalld_default_zone | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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 | ||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||
| Warnings | 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. |
Configure Accepting Router Advertisements on All IPv6 Interfacesxccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_ra medium
Configure Accepting Router Advertisements on All IPv6 Interfaces
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_ra | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description | 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=0To 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. |
Disable Accepting ICMP Redirects for All IPv6 Interfacesxccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_redirects medium
Disable Accepting ICMP Redirects for All IPv6 Interfaces
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_redirects | ||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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=0To 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. |
Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv6 Interfacesxccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_source_route medium
Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv6 Interfaces
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_source_route | ||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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=0To 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. |
Disable Kernel Parameter for IPv6 Forwardingxccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_forwarding medium
Disable Kernel Parameter for IPv6 Forwarding
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_forwarding | ||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||
| Severity | medium | ||||||||||||||||||
| References: |
| ||||||||||||||||||
| Description | 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=0To 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. |
Disable Accepting Router Advertisements on all IPv6 Interfaces by Defaultxccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_ra medium
Disable Accepting Router Advertisements on all IPv6 Interfaces by Default
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_ra | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description | 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=0To 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. |
Disable Kernel Parameter for Accepting ICMP Redirects by Default on IPv6 Interfacesxccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_redirects medium
Disable Kernel Parameter for Accepting ICMP Redirects by Default on IPv6 Interfaces
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_redirects | ||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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=0To 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. |
Disable Kernel Parameter for Accepting Source-Routed Packets on IPv6 Interfaces by Defaultxccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_source_route medium
Disable Kernel Parameter for Accepting Source-Routed Packets on IPv6 Interfaces by Default
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_default_accept_source_route | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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=0To 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. |
Disable Accepting ICMP Redirects for All IPv4 Interfacesxccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_accept_redirects medium
Disable Accepting ICMP Redirects for All IPv4 Interfaces
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_accept_redirects | ||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||
| Description | 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=0To 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." |
Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv4 Interfacesxccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_accept_source_route medium
Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv4 Interfaces
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_accept_source_route | ||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||
| Description | 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=0To 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. |
Enable Kernel Parameter to Log Martian Packets on all IPv4 Interfacesxccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_log_martians unknown
Enable Kernel Parameter to Log Martian Packets on all IPv4 Interfaces
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_log_martians | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||
| Severity | unknown | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description | 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=1To 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. |
Enable Kernel Parameter to Use Reverse Path Filtering on all IPv4 Interfacesxccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_rp_filter medium
Enable Kernel Parameter to Use Reverse Path Filtering on all IPv4 Interfaces
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_rp_filter | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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=1To 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. |
Disable Kernel Parameter for Accepting Secure ICMP Redirects on all IPv4 Interfacesxccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_secure_redirects medium
Disable Kernel Parameter for Accepting Secure ICMP Redirects on all IPv4 Interfaces
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_secure_redirects | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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=0To 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. |
Disable Kernel Parameter for Accepting ICMP Redirects by Default on IPv4 Interfacesxccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_accept_redirects medium
Disable Kernel Parameter for Accepting ICMP Redirects by Default on IPv4 Interfaces
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_accept_redirects | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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=0To 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. |
Disable Kernel Parameter for Accepting Source-Routed Packets on IPv4 Interfaces by Defaultxccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_accept_source_route medium
Disable Kernel Parameter for Accepting Source-Routed Packets on IPv4 Interfaces by Default
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_accept_source_route | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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=0To 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. |
Enable Kernel Parameter to Log Martian Packets on all IPv4 Interfaces by Defaultxccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_log_martians unknown
Enable Kernel Parameter to Log Martian Packets on all IPv4 Interfaces by Default
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_log_martians | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||
| Severity | unknown | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description | 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=1To 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. |
Enable Kernel Parameter to Use Reverse Path Filtering on all IPv4 Interfaces by Defaultxccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_rp_filter medium
Enable Kernel Parameter to Use Reverse Path Filtering on all IPv4 Interfaces by Default
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_rp_filter | ||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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=1To 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. |
Configure Kernel Parameter for Accepting Secure Redirects By Defaultxccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_secure_redirects medium
Configure Kernel Parameter for Accepting Secure Redirects By Default
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_secure_redirects | ||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||
| Description | 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=0To 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. |
Enable Kernel Parameter to Ignore ICMP Broadcast Echo Requests on IPv4 Interfacesxccdf_org.ssgproject.content_rule_sysctl_net_ipv4_icmp_echo_ignore_broadcasts medium
Enable Kernel Parameter to Ignore ICMP Broadcast Echo Requests on IPv4 Interfaces
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_icmp_echo_ignore_broadcasts | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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=1To 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. |
Enable Kernel Parameter to Ignore Bogus ICMP Error Responses on IPv4 Interfacesxccdf_org.ssgproject.content_rule_sysctl_net_ipv4_icmp_ignore_bogus_error_responses unknown
Enable Kernel Parameter to Ignore Bogus ICMP Error Responses on IPv4 Interfaces
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_icmp_ignore_bogus_error_responses | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||
| Severity | unknown | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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=1To 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. |
Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfacesxccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_send_redirects medium
Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfaces
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_send_redirects | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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=0To 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. |
Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfaces by Defaultxccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_send_redirects medium
Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfaces by Default
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_send_redirects | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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=0To 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. |
Disable Kernel Parameter for IP Forwarding on IPv4 Interfacesxccdf_org.ssgproject.content_rule_sysctl_net_ipv4_ip_forward medium
Disable Kernel Parameter for IP Forwarding on IPv4 Interfaces
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_ip_forward | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:33+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | To set the runtime status of the net.ipv4.ip_forward kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.ip_forward=0To 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 | ||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||
| Warnings | 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. |
Install nftables Packagexccdf_org.ssgproject.content_rule_package_nftables_installed medium
Install nftables Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_nftables_installed | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:51:57+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
Verify nftables Service is Disabledxccdf_org.ssgproject.content_rule_service_nftables_disabled medium
Verify nftables Service is Disabled
| Rule ID | xccdf_org.ssgproject.content_rule_service_nftables_disabled | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:51:57+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
Ensure a Table Exists for Nftablesxccdf_org.ssgproject.content_rule_set_nftables_table medium
Ensure a Table Exists for Nftables
| Rule ID | xccdf_org.ssgproject.content_rule_set_nftables_table | ||
| Result | notchecked | ||
| Multi-check rule | no | ||
| Time | 2026-03-29T19:51:57+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description | 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. | ||
| Rationale | Nftables doesn't have any default tables. Without a table being built, nftables will not
filter network traffic. | ||
| Warnings | 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. | ||
Disable DCCP Supportxccdf_org.ssgproject.content_rule_kernel_module_dccp_disabled medium
Disable DCCP Support
| Rule ID | xccdf_org.ssgproject.content_rule_kernel_module_dccp_disabled | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:57+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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/falseThis entry will cause a non-zero return value during a dccp module installation
and additionally convey the meaning of the entry to the user in form of an error message.
If you would like to omit a non-zero return value and an error message, you may want to add a different line instead
(both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan):
install dccp /bin/true | ||||||||||||||||||||||||||
| Rationale | Disabling DCCP protects
the system against exploitation of any flaws in its implementation. |
Disable RDS Supportxccdf_org.ssgproject.content_rule_kernel_module_rds_disabled low
Disable RDS Support
| Rule ID | xccdf_org.ssgproject.content_rule_kernel_module_rds_disabled | ||||||||||||||||
| Result | notapplicable | ||||||||||||||||
| Multi-check rule | no | ||||||||||||||||
| Time | 2026-03-29T19:51:57+00:00 | ||||||||||||||||
| Severity | low | ||||||||||||||||
| References: |
| ||||||||||||||||
| Description | 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/falseThis entry will cause a non-zero return value during a rds module installation
and additionally convey the meaning of the entry to the user in form of an error message.
If you would like to omit a non-zero return value and an error message, you may want to add a different line instead
(both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan):
install rds /bin/true | ||||||||||||||||
| Rationale | Disabling RDS protects
the system against exploitation of any flaws in its implementation. |
Disable SCTP Supportxccdf_org.ssgproject.content_rule_kernel_module_sctp_disabled medium
Disable SCTP Support
| Rule ID | xccdf_org.ssgproject.content_rule_kernel_module_sctp_disabled | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:51:57+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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/falseThis entry will cause a non-zero return value during a sctp module installation
and additionally convey the meaning of the entry to the user in form of an error message.
If you would like to omit a non-zero return value and an error message, you may want to add a different line instead
(both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan):
install sctp /bin/true | ||||||||||||||||||||||||||||
| Rationale | Disabling SCTP protects
the system against exploitation of any flaws in its implementation. |
Disable TIPC Supportxccdf_org.ssgproject.content_rule_kernel_module_tipc_disabled low
Disable TIPC Support
| Rule ID | xccdf_org.ssgproject.content_rule_kernel_module_tipc_disabled | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:51:57+00:00 | ||||||||||||||||||||
| Severity | low | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description | 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/falseThis entry will cause a non-zero return value during a tipc module installation
and additionally convey the meaning of the entry to the user in form of an error message.
If you would like to omit a non-zero return value and an error message, you may want to add a different line instead
(both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan):
install tipc /bin/true | ||||||||||||||||||||
| Rationale | Disabling TIPC protects
the system against exploitation of any flaws in its implementation. | ||||||||||||||||||||
| Warnings | 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. |
Verify Group Who Owns Backup group Filexccdf_org.ssgproject.content_rule_file_groupowner_backup_etc_group medium
Verify Group Who Owns Backup group File
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_backup_etc_group | ||||||||||
| Result | pass | ||||||||||
| Multi-check rule | no | ||||||||||
| OVAL Definition ID | oval:ssg-file_groupowner_backup_etc_group:def:1 | ||||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||||
| Severity | medium | ||||||||||
| References: |
| ||||||||||
| Description | 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. |
OVAL test results details
Testing group ownership of /etc/group- oval:ssg-test_file_groupowner_backup_etc_group_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_groupowner_backup_etc_group_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/group- | oval:ssg-symlink_file_groupowner:ste:1 | oval:ssg-state_file_groupowner_backup_etc_group_0_0:ste:1 |
Verify Group Who Owns Backup gshadow Filexccdf_org.ssgproject.content_rule_file_groupowner_backup_etc_gshadow medium
Verify Group Who Owns Backup gshadow File
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_backup_etc_gshadow | ||||||||
| Result | pass | ||||||||
| Multi-check rule | no | ||||||||
| OVAL Definition ID | oval:ssg-file_groupowner_backup_etc_gshadow:def:1 | ||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||
| Severity | medium | ||||||||
| References: |
| ||||||||
| Description | 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. |
OVAL test results details
Testing group ownership of /etc/gshadow- oval:ssg-test_file_groupowner_backup_etc_gshadow_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_groupowner_backup_etc_gshadow_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/gshadow- | oval:ssg-symlink_file_groupowner:ste:1 | oval:ssg-state_file_groupowner_backup_etc_gshadow_0_0:ste:1 |
Verify Group Who Owns Backup passwd Filexccdf_org.ssgproject.content_rule_file_groupowner_backup_etc_passwd medium
Verify Group Who Owns Backup passwd File
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_backup_etc_passwd | ||||||||||
| Result | pass | ||||||||||
| Multi-check rule | no | ||||||||||
| OVAL Definition ID | oval:ssg-file_groupowner_backup_etc_passwd:def:1 | ||||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||||
| Severity | medium | ||||||||||
| References: |
| ||||||||||
| Description | 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. |
OVAL test results details
Testing group ownership of /etc/passwd- oval:ssg-test_file_groupowner_backup_etc_passwd_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_groupowner_backup_etc_passwd_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/passwd- | oval:ssg-symlink_file_groupowner:ste:1 | oval:ssg-state_file_groupowner_backup_etc_passwd_0_0:ste:1 |
Verify User Who Owns Backup shadow Filexccdf_org.ssgproject.content_rule_file_groupowner_backup_etc_shadow medium
Verify User Who Owns Backup shadow File
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_backup_etc_shadow | ||||||||
| Result | pass | ||||||||
| Multi-check rule | no | ||||||||
| OVAL Definition ID | oval:ssg-file_groupowner_backup_etc_shadow:def:1 | ||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||
| Severity | medium | ||||||||
| References: |
| ||||||||
| Description | 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. |
OVAL test results details
Testing group ownership of /etc/shadow- oval:ssg-test_file_groupowner_backup_etc_shadow_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_groupowner_backup_etc_shadow_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/shadow- | oval:ssg-symlink_file_groupowner:ste:1 | oval:ssg-state_file_groupowner_backup_etc_shadow_0_0:ste:1 |
Verify Group Who Owns group Filexccdf_org.ssgproject.content_rule_file_groupowner_etc_group medium
Verify Group Who Owns group File
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_etc_group | ||||||||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-file_groupowner_etc_group:def:1 | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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. |
OVAL test results details
Testing group ownership of /etc/group oval:ssg-test_file_groupowner_etc_group_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_groupowner_etc_group_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/group | oval:ssg-symlink_file_groupowner:ste:1 | oval:ssg-state_file_groupowner_etc_group_0_0:ste:1 |
Verify Group Who Owns gshadow Filexccdf_org.ssgproject.content_rule_file_groupowner_etc_gshadow medium
Verify Group Who Owns gshadow File
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_etc_gshadow | ||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-file_groupowner_etc_gshadow:def:1 | ||||||||||||||||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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. |
OVAL test results details
Testing group ownership of /etc/gshadow oval:ssg-test_file_groupowner_etc_gshadow_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_groupowner_etc_gshadow_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/gshadow | oval:ssg-symlink_file_groupowner:ste:1 | oval:ssg-state_file_groupowner_etc_gshadow_0_0:ste:1 |
Verify Group Who Owns passwd Filexccdf_org.ssgproject.content_rule_file_groupowner_etc_passwd medium
Verify Group Who Owns passwd File
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_etc_passwd | ||||||||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-file_groupowner_etc_passwd:def:1 | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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. |
OVAL test results details
Testing group ownership of /etc/passwd oval:ssg-test_file_groupowner_etc_passwd_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_groupowner_etc_passwd_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/passwd | oval:ssg-symlink_file_groupowner:ste:1 | oval:ssg-state_file_groupowner_etc_passwd_0_0:ste:1 |
Verify Group Who Owns shadow Filexccdf_org.ssgproject.content_rule_file_groupowner_etc_shadow medium
Verify Group Who Owns shadow File
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_etc_shadow | ||||||||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-file_groupowner_etc_shadow:def:1 | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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. |
OVAL test results details
Testing group ownership of /etc/shadow oval:ssg-test_file_groupowner_etc_shadow_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_groupowner_etc_shadow_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/shadow | oval:ssg-symlink_file_groupowner:ste:1 | oval:ssg-state_file_groupowner_etc_shadow_0_0:ste:1 |
Verify User Who Owns Backup group Filexccdf_org.ssgproject.content_rule_file_owner_backup_etc_group medium
Verify User Who Owns Backup group File
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_backup_etc_group | ||||||||||
| Result | pass | ||||||||||
| Multi-check rule | no | ||||||||||
| OVAL Definition ID | oval:ssg-file_owner_backup_etc_group:def:1 | ||||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||||
| Severity | medium | ||||||||||
| References: |
| ||||||||||
| Description | 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. |
OVAL test results details
Testing user ownership of /etc/group- oval:ssg-test_file_owner_backup_etc_group_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_owner_backup_etc_group_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/group- | oval:ssg-symlink_file_owner:ste:1 | oval:ssg-state_file_owner_backup_etc_group_0_0:ste:1 |
Verify User Who Owns Backup gshadow Filexccdf_org.ssgproject.content_rule_file_owner_backup_etc_gshadow medium
Verify User Who Owns Backup gshadow File
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_backup_etc_gshadow | ||||||||
| Result | pass | ||||||||
| Multi-check rule | no | ||||||||
| OVAL Definition ID | oval:ssg-file_owner_backup_etc_gshadow:def:1 | ||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||
| Severity | medium | ||||||||
| References: |
| ||||||||
| Description | 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. |
OVAL test results details
Testing user ownership of /etc/gshadow- oval:ssg-test_file_owner_backup_etc_gshadow_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_owner_backup_etc_gshadow_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/gshadow- | oval:ssg-symlink_file_owner:ste:1 | oval:ssg-state_file_owner_backup_etc_gshadow_0_0:ste:1 |
Verify User Who Owns Backup passwd Filexccdf_org.ssgproject.content_rule_file_owner_backup_etc_passwd medium
Verify User Who Owns Backup passwd File
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_backup_etc_passwd | ||||||||||
| Result | pass | ||||||||||
| Multi-check rule | no | ||||||||||
| OVAL Definition ID | oval:ssg-file_owner_backup_etc_passwd:def:1 | ||||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||||
| Severity | medium | ||||||||||
| References: |
| ||||||||||
| Description | 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. |
OVAL test results details
Testing user ownership of /etc/passwd- oval:ssg-test_file_owner_backup_etc_passwd_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_owner_backup_etc_passwd_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/passwd- | oval:ssg-symlink_file_owner:ste:1 | oval:ssg-state_file_owner_backup_etc_passwd_0_0:ste:1 |
Verify Group Who Owns Backup shadow Filexccdf_org.ssgproject.content_rule_file_owner_backup_etc_shadow medium
Verify Group Who Owns Backup shadow File
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_backup_etc_shadow | ||||||||||
| Result | pass | ||||||||||
| Multi-check rule | no | ||||||||||
| OVAL Definition ID | oval:ssg-file_owner_backup_etc_shadow:def:1 | ||||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||||
| Severity | medium | ||||||||||
| References: |
| ||||||||||
| Description | 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. |
OVAL test results details
Testing user ownership of /etc/shadow- oval:ssg-test_file_owner_backup_etc_shadow_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_owner_backup_etc_shadow_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/shadow- | oval:ssg-symlink_file_owner:ste:1 | oval:ssg-state_file_owner_backup_etc_shadow_0_0:ste:1 |
Verify User Who Owns group Filexccdf_org.ssgproject.content_rule_file_owner_etc_group medium
Verify User Who Owns group File
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_etc_group | ||||||||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-file_owner_etc_group:def:1 | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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. |
OVAL test results details
Testing user ownership of /etc/group oval:ssg-test_file_owner_etc_group_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_owner_etc_group_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/group | oval:ssg-symlink_file_owner:ste:1 | oval:ssg-state_file_owner_etc_group_0_0:ste:1 |
Verify User Who Owns gshadow Filexccdf_org.ssgproject.content_rule_file_owner_etc_gshadow medium
Verify User Who Owns gshadow File
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_etc_gshadow | ||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-file_owner_etc_gshadow:def:1 | ||||||||||||||||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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. |
OVAL test results details
Testing user ownership of /etc/gshadow oval:ssg-test_file_owner_etc_gshadow_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_owner_etc_gshadow_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/gshadow | oval:ssg-symlink_file_owner:ste:1 | oval:ssg-state_file_owner_etc_gshadow_0_0:ste:1 |
Verify User Who Owns passwd Filexccdf_org.ssgproject.content_rule_file_owner_etc_passwd medium
Verify User Who Owns passwd File
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_etc_passwd | ||||||||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-file_owner_etc_passwd:def:1 | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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. |
OVAL test results details
Testing user ownership of /etc/passwd oval:ssg-test_file_owner_etc_passwd_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_owner_etc_passwd_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/passwd | oval:ssg-symlink_file_owner:ste:1 | oval:ssg-state_file_owner_etc_passwd_0_0:ste:1 |
Verify User Who Owns shadow Filexccdf_org.ssgproject.content_rule_file_owner_etc_shadow medium
Verify User Who Owns shadow File
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_etc_shadow | ||||||||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-file_owner_etc_shadow:def:1 | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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. |
OVAL test results details
Testing user ownership of /etc/shadow oval:ssg-test_file_owner_etc_shadow_0:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_file_owner_etc_shadow_0:obj:1 of type file_object
| Filepath | Filter | Filter |
|---|---|---|
| /etc/shadow | oval:ssg-symlink_file_owner:ste:1 | oval:ssg-state_file_owner_etc_shadow_0_0:ste:1 |
Verify that All World-Writable Directories Have Sticky Bits Setxccdf_org.ssgproject.content_rule_dir_perms_world_writable_sticky_bits medium
Verify that All World-Writable Directories Have Sticky Bits Set
| Rule ID | xccdf_org.ssgproject.content_rule_dir_perms_world_writable_sticky_bits | ||||||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-dir_perms_world_writable_sticky_bits:def:1 | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:52:06+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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
| ||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||
| Warnings | 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.warning
Please note that there might be cases where the rule remediation cannot fix directory permissions.
This can happen for example when running on a system with some immutable parts.
These immutable parts cannot be remediated because they are read-only.
Example of such directories can be OStree deployments located at /sysroot/ostree/deploy.
In such case, it is needed to make modifications to the underlying ostree snapshot and this is out of scope of regular rule remediation. |
OVAL test results details
Check the existence of world-writable directories without sticky bits oval:ssg-test_dir_perms_world_writable_sticky_bits:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-object_dir_perms_world_writable_sticky_bits:obj:1 of type file_object
| Behaviors | Path | Filename | Filter | ||
|---|---|---|---|---|---|
| oval:ssg-state_dir_perms_world_writable_sticky_bits:ste:1 |
Ensure All Files Are Owned by a Userxccdf_org.ssgproject.content_rule_no_files_unowned_by_user medium
Ensure All Files Are Owned by a User
| Rule ID | xccdf_org.ssgproject.content_rule_no_files_unowned_by_user | ||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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 | ||||||||||||||||||||||
| 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. | ||||||||||||||||||||||
| Warnings | warning
For this rule to evaluate centralized user accounts, getent must be working properly
so that running the command getent passwdreturns a list of all users in your organization. If using the System Security Services Daemon (SSSD), enumerate = truemust 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. |
Disable Mounting of cramfsxccdf_org.ssgproject.content_rule_kernel_module_cramfs_disabled low
Disable Mounting of cramfs
| Rule ID | xccdf_org.ssgproject.content_rule_kernel_module_cramfs_disabled | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||||||||||||||
| Severity | low | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description |
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/falseThis entry will cause a non-zero return value during a cramfs module installation
and additionally convey the meaning of the entry to the user in form of an error message.
If you would like to omit a non-zero return value and an error message, you may want to add a different line instead
(both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan):
install cramfs /bin/trueThis 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. |
Disable Mounting of freevxfsxccdf_org.ssgproject.content_rule_kernel_module_freevxfs_disabled low
Disable Mounting of freevxfs
| Rule ID | xccdf_org.ssgproject.content_rule_kernel_module_freevxfs_disabled | ||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||
| Time | 2026-03-29T19:53:36+00:00 | ||||||||||||||||||
| Severity | low | ||||||||||||||||||
| References: |
| ||||||||||||||||||
| Description |
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/falseThis entry will cause a non-zero return value during a freevxfs module installation
and additionally convey the meaning of the entry to the user in form of an error message.
If you would like to omit a non-zero return value and an error message, you may want to add a different line instead
(both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan):
install freevxfs /bin/trueThis 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. |
Disable Mounting of hfsxccdf_org.ssgproject.content_rule_kernel_module_hfs_disabled low
Disable Mounting of hfs
| Rule ID | xccdf_org.ssgproject.content_rule_kernel_module_hfs_disabled | ||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||
| Severity | low | ||||||||||||||||||
| References: |
| ||||||||||||||||||
| Description |
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/falseThis entry will cause a non-zero return value during a hfs module installation
and additionally convey the meaning of the entry to the user in form of an error message.
If you would like to omit a non-zero return value and an error message, you may want to add a different line instead
(both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan):
install hfs /bin/trueThis 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. |
Disable Mounting of hfsplusxccdf_org.ssgproject.content_rule_kernel_module_hfsplus_disabled low
Disable Mounting of hfsplus
| Rule ID | xccdf_org.ssgproject.content_rule_kernel_module_hfsplus_disabled | ||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||
| Severity | low | ||||||||||||||||||
| References: |
| ||||||||||||||||||
| Description |
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/falseThis entry will cause a non-zero return value during a hfsplus module installation
and additionally convey the meaning of the entry to the user in form of an error message.
If you would like to omit a non-zero return value and an error message, you may want to add a different line instead
(both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan):
install hfsplus /bin/trueThis 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. |
Disable Mounting of jffs2xccdf_org.ssgproject.content_rule_kernel_module_jffs2_disabled low
Disable Mounting of jffs2
| Rule ID | xccdf_org.ssgproject.content_rule_kernel_module_jffs2_disabled | ||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||
| Severity | low | ||||||||||||||||||
| References: |
| ||||||||||||||||||
| Description |
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/falseThis entry will cause a non-zero return value during a jffs2 module installation
and additionally convey the meaning of the entry to the user in form of an error message.
If you would like to omit a non-zero return value and an error message, you may want to add a different line instead
(both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan):
install jffs2 /bin/trueThis 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. |
Disable Mounting of squashfsxccdf_org.ssgproject.content_rule_kernel_module_squashfs_disabled low
Disable Mounting of squashfs
| Rule ID | xccdf_org.ssgproject.content_rule_kernel_module_squashfs_disabled | ||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||
| Severity | low | ||||||||||||||||||
| References: |
| ||||||||||||||||||
| Description |
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/falseThis entry will cause a non-zero return value during a squashfs module installation
and additionally convey the meaning of the entry to the user in form of an error message.
If you would like to omit a non-zero return value and an error message, you may want to add a different line instead
(both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan):
install squashfs /bin/trueThis 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. |
Disable Mounting of udfxccdf_org.ssgproject.content_rule_kernel_module_udf_disabled low
Disable Mounting of udf
| Rule ID | xccdf_org.ssgproject.content_rule_kernel_module_udf_disabled | ||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||
| Severity | low | ||||||||||||||||||
| References: |
| ||||||||||||||||||
| Description |
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/falseThis entry will cause a non-zero return value during a udf module installation
and additionally convey the meaning of the entry to the user in form of an error message.
If you would like to omit a non-zero return value and an error message, you may want to add a different line instead
(both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan):
install udf /bin/trueThis 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 necessary to support
writing DVDs and newer optical disc formats. | ||||||||||||||||||
| Rationale | Removing support for unneeded filesystem types reduces the local
attack surface of the system. |
Disable Modprobe Loading of USB Storage Driverxccdf_org.ssgproject.content_rule_kernel_module_usb-storage_disabled medium
Disable Modprobe Loading of USB Storage Driver
| Rule ID | xccdf_org.ssgproject.content_rule_kernel_module_usb-storage_disabled | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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/falseThis entry will cause a non-zero return value during a usb-storage module installation
and additionally convey the meaning of the entry to the user in form of an error message.
If you would like to omit a non-zero return value and an error message, you may want to add a different line instead
(both /bin/true and /bin/false are allowed by OVAL and will be accepted by the scan):
install usb-storage /bin/trueThis 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. |
Add nodev Option to /dev/shmxccdf_org.ssgproject.content_rule_mount_option_dev_shm_nodev medium
Add nodev Option to /dev/shm
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_dev_shm_nodev | ||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-mount_option_dev_shm_nodev:def:1 | ||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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. |
OVAL test results details
nodev on /dev/shm oval:ssg-test_dev_shm_partition_nodev_expected:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Mount point | Device | Uuid | Fs type | Mount options | Mount options | Mount options | Mount options | Mount options | Total space | Space used | Space left |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| true | /dev/shm | tmpfs | tmpfs | rw | seclabel | nosuid | nodev | noexec | 117863 | 0 | 117863 |
/dev/shm exists oval:ssg-test_dev_shm_partition_nodev_expected_exist:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Mount point | Device | Uuid | Fs type | Mount options | Mount options | Mount options | Mount options | Mount options | Total space | Space used | Space left |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| not evaluated | /dev/shm | tmpfs | tmpfs | rw | seclabel | nosuid | nodev | noexec | 117863 | 0 | 117863 |
nodev on /dev/shm in /etc/fstab oval:ssg-test_dev_shm_partition_nodev_expected_in_fstab:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| true | /etc/fstab | tmpfs /dev/shm tmpfs defaults,nodev,noexec,nosuid |
Add noexec Option to /dev/shmxccdf_org.ssgproject.content_rule_mount_option_dev_shm_noexec medium
Add noexec Option to /dev/shm
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_dev_shm_noexec | ||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-mount_option_dev_shm_noexec:def:1 | ||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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. |
OVAL test results details
noexec on /dev/shm oval:ssg-test_dev_shm_partition_noexec_expected:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Mount point | Device | Uuid | Fs type | Mount options | Mount options | Mount options | Mount options | Mount options | Total space | Space used | Space left |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| true | /dev/shm | tmpfs | tmpfs | rw | seclabel | nosuid | nodev | noexec | 117863 | 0 | 117863 |
/dev/shm exists oval:ssg-test_dev_shm_partition_noexec_expected_exist:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Mount point | Device | Uuid | Fs type | Mount options | Mount options | Mount options | Mount options | Mount options | Total space | Space used | Space left |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| not evaluated | /dev/shm | tmpfs | tmpfs | rw | seclabel | nosuid | nodev | noexec | 117863 | 0 | 117863 |
noexec on /dev/shm in /etc/fstab oval:ssg-test_dev_shm_partition_noexec_expected_in_fstab:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| true | /etc/fstab | tmpfs /dev/shm tmpfs defaults,nodev,noexec,nosuid |
Add nosuid Option to /dev/shmxccdf_org.ssgproject.content_rule_mount_option_dev_shm_nosuid medium
Add nosuid Option to /dev/shm
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_dev_shm_nosuid | ||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-mount_option_dev_shm_nosuid:def:1 | ||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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. |
OVAL test results details
nosuid on /dev/shm oval:ssg-test_dev_shm_partition_nosuid_expected:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Mount point | Device | Uuid | Fs type | Mount options | Mount options | Mount options | Mount options | Mount options | Total space | Space used | Space left |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| true | /dev/shm | tmpfs | tmpfs | rw | seclabel | nosuid | nodev | noexec | 117863 | 0 | 117863 |
/dev/shm exists oval:ssg-test_dev_shm_partition_nosuid_expected_exist:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Mount point | Device | Uuid | Fs type | Mount options | Mount options | Mount options | Mount options | Mount options | Total space | Space used | Space left |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| not evaluated | /dev/shm | tmpfs | tmpfs | rw | seclabel | nosuid | nodev | noexec | 117863 | 0 | 117863 |
nosuid on /dev/shm in /etc/fstab oval:ssg-test_dev_shm_partition_nosuid_expected_in_fstab:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| true | /etc/fstab | tmpfs /dev/shm tmpfs defaults,nodev,noexec,nosuid |
Add nodev Option to /homexccdf_org.ssgproject.content_rule_mount_option_home_nodev unknown
Add nodev Option to /home
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_home_nodev | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | unknown | ||||
| References: |
| ||||
| Description | 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. |
Add nosuid Option to /homexccdf_org.ssgproject.content_rule_mount_option_home_nosuid medium
Add nosuid Option to /home
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_home_nosuid | ||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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. |
Add nodev Option to /tmpxccdf_org.ssgproject.content_rule_mount_option_tmp_nodev medium
Add nodev Option to /tmp
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_tmp_nodev | ||||||||||||||||||||
| Result | pass | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| OVAL Definition ID | oval:ssg-mount_option_tmp_nodev:def:1 | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description | 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. |
OVAL test results details
nodev on /tmp oval:ssg-test_tmp_partition_nodev_optional:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Mount point | Device | Uuid | Fs type | Mount options | Mount options | Mount options | Mount options | Mount options | Total space | Space used | Space left |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| true | /tmp | tmpfs | tmpfs | rw | seclabel | nosuid | nodev | noexec | 117863 | 42994 | 74869 |
/tmp exists oval:ssg-test_tmp_partition_nodev_optional_exist:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Mount point | Device | Uuid | Fs type | Mount options | Mount options | Mount options | Mount options | Mount options | Total space | Space used | Space left |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| not evaluated | /tmp | tmpfs | tmpfs | rw | seclabel | nosuid | nodev | noexec | 117863 | 42994 | 74869 |
nodev on /tmp in /etc/fstab oval:ssg-test_tmp_partition_nodev_optional_in_fstab:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| true | /etc/fstab | tmpfs /tmp tmpfs defaults,noexec,nodev,nosuid |
/tmp exists in /etc/fstab oval:ssg-test_tmp_partition_nodev_optional_exist_in_fstab:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/fstab | tmpfs /tmp tmpfs defaults,noexec,nodev,nosuid |
Add noexec Option to /tmpxccdf_org.ssgproject.content_rule_mount_option_tmp_noexec medium
Add noexec Option to /tmp
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_tmp_noexec | ||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-mount_option_tmp_noexec:def:1 | ||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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. |
OVAL test results details
noexec on /tmp oval:ssg-test_tmp_partition_noexec_optional:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Mount point | Device | Uuid | Fs type | Mount options | Mount options | Mount options | Mount options | Mount options | Total space | Space used | Space left |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| true | /tmp | tmpfs | tmpfs | rw | seclabel | nosuid | nodev | noexec | 117863 | 42994 | 74869 |
/tmp exists oval:ssg-test_tmp_partition_noexec_optional_exist:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Mount point | Device | Uuid | Fs type | Mount options | Mount options | Mount options | Mount options | Mount options | Total space | Space used | Space left |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| not evaluated | /tmp | tmpfs | tmpfs | rw | seclabel | nosuid | nodev | noexec | 117863 | 42994 | 74869 |
noexec on /tmp in /etc/fstab oval:ssg-test_tmp_partition_noexec_optional_in_fstab:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| true | /etc/fstab | tmpfs /tmp tmpfs defaults,noexec,nodev,nosuid |
/tmp exists in /etc/fstab oval:ssg-test_tmp_partition_noexec_optional_exist_in_fstab:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/fstab | tmpfs /tmp tmpfs defaults,noexec,nodev,nosuid |
Add nosuid Option to /tmpxccdf_org.ssgproject.content_rule_mount_option_tmp_nosuid medium
Add nosuid Option to /tmp
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_tmp_nosuid | ||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-mount_option_tmp_nosuid:def:1 | ||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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. |
OVAL test results details
nosuid on /tmp oval:ssg-test_tmp_partition_nosuid_optional:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Mount point | Device | Uuid | Fs type | Mount options | Mount options | Mount options | Mount options | Mount options | Total space | Space used | Space left |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| true | /tmp | tmpfs | tmpfs | rw | seclabel | nosuid | nodev | noexec | 117863 | 42994 | 74869 |
/tmp exists oval:ssg-test_tmp_partition_nosuid_optional_exist:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Mount point | Device | Uuid | Fs type | Mount options | Mount options | Mount options | Mount options | Mount options | Total space | Space used | Space left |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| not evaluated | /tmp | tmpfs | tmpfs | rw | seclabel | nosuid | nodev | noexec | 117863 | 42994 | 74869 |
nosuid on /tmp in /etc/fstab oval:ssg-test_tmp_partition_nosuid_optional_in_fstab:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| true | /etc/fstab | tmpfs /tmp tmpfs defaults,noexec,nodev,nosuid |
/tmp exists in /etc/fstab oval:ssg-test_tmp_partition_nosuid_optional_exist_in_fstab:tst:1 true
Following items have been found on the system:
| Result of item-state comparison | Path | Content |
|---|---|---|
| not evaluated | /etc/fstab | tmpfs /tmp tmpfs defaults,noexec,nodev,nosuid |
Add nodev Option to /var/log/auditxccdf_org.ssgproject.content_rule_mount_option_var_log_audit_nodev medium
Add nodev Option to /var/log/audit
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_var_log_audit_nodev | ||||||||||||
| Result | notapplicable | ||||||||||||
| Multi-check rule | no | ||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||
| Severity | medium | ||||||||||||
| References: |
| ||||||||||||
| Description | 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. |
Add noexec Option to /var/log/auditxccdf_org.ssgproject.content_rule_mount_option_var_log_audit_noexec medium
Add noexec Option to /var/log/audit
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_var_log_audit_noexec | ||||||||||||
| Result | notapplicable | ||||||||||||
| Multi-check rule | no | ||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||
| Severity | medium | ||||||||||||
| References: |
| ||||||||||||
| Description | 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. |
Add nosuid Option to /var/log/auditxccdf_org.ssgproject.content_rule_mount_option_var_log_audit_nosuid medium
Add nosuid Option to /var/log/audit
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_var_log_audit_nosuid | ||||||||||||
| Result | notapplicable | ||||||||||||
| Multi-check rule | no | ||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||
| Severity | medium | ||||||||||||
| References: |
| ||||||||||||
| Description | 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. |
Add nodev Option to /var/logxccdf_org.ssgproject.content_rule_mount_option_var_log_nodev medium
Add nodev Option to /var/log
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_var_log_nodev | ||||||||||
| Result | notapplicable | ||||||||||
| Multi-check rule | no | ||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||
| Severity | medium | ||||||||||
| References: |
| ||||||||||
| Description | 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. |
Add noexec Option to /var/logxccdf_org.ssgproject.content_rule_mount_option_var_log_noexec medium
Add noexec Option to /var/log
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_var_log_noexec | ||||||||||||
| Result | notapplicable | ||||||||||||
| Multi-check rule | no | ||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||
| Severity | medium | ||||||||||||
| References: |
| ||||||||||||
| Description | 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. |
Add nosuid Option to /var/logxccdf_org.ssgproject.content_rule_mount_option_var_log_nosuid medium
Add nosuid Option to /var/log
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_var_log_nosuid | ||||||||||||
| Result | notapplicable | ||||||||||||
| Multi-check rule | no | ||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||
| Severity | medium | ||||||||||||
| References: |
| ||||||||||||
| Description | 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. |
Add nodev Option to /varxccdf_org.ssgproject.content_rule_mount_option_var_nodev medium
Add nodev Option to /var
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_var_nodev | ||||||||||
| Result | notapplicable | ||||||||||
| Multi-check rule | no | ||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||
| Severity | medium | ||||||||||
| References: |
| ||||||||||
| Description | 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. |
Add nosuid Option to /varxccdf_org.ssgproject.content_rule_mount_option_var_nosuid medium
Add nosuid Option to /var
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_var_nosuid | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
Add nodev Option to /var/tmpxccdf_org.ssgproject.content_rule_mount_option_var_tmp_nodev medium
Add nodev Option to /var/tmp
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_var_tmp_nodev | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
Add noexec Option to /var/tmpxccdf_org.ssgproject.content_rule_mount_option_var_tmp_noexec medium
Add noexec Option to /var/tmp
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_var_tmp_noexec | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||
| Severity | medium | ||||||
| References: |
| ||||||
| Description | 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. |
Add nosuid Option to /var/tmpxccdf_org.ssgproject.content_rule_mount_option_var_tmp_nosuid medium
Add nosuid Option to /var/tmp
| Rule ID | xccdf_org.ssgproject.content_rule_mount_option_var_tmp_nosuid | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||
| Severity | medium | ||||||
| References: |
| ||||||
| Description | 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. |
Disable core dump backtracesxccdf_org.ssgproject.content_rule_coredump_disable_backtraces medium
Disable core dump backtraces
| Rule ID | xccdf_org.ssgproject.content_rule_coredump_disable_backtraces | ||||||||||
| Result | notapplicable | ||||||||||
| Multi-check rule | no | ||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||
| Severity | medium | ||||||||||
| References: |
| ||||||||||
| Description | The ProcessSizeMax option in [Coredump] section
of /etc/systemd/coredump.conf or in a drop-in file under
/etc/systemd/coredump.conf.d/ 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. | ||||||||||
| 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
debugging. Permitting temporary enablement of core dumps during such situations
should be reviewed through local needs and policy. | ||||||||||
| Warnings | warning
If the /etc/systemd/coredump.conf file or a drop-in file under /etc/systemd/coredump.conf.d/
does not already contain the [Coredump] section,
the value will not be configured correctly. |
Disable storing core dumpxccdf_org.ssgproject.content_rule_coredump_disable_storage medium
Disable storing core dump
| Rule ID | xccdf_org.ssgproject.content_rule_coredump_disable_storage | ||||||||||
| Result | notapplicable | ||||||||||
| Multi-check rule | no | ||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||
| Severity | medium | ||||||||||
| References: |
| ||||||||||
| Description | The Storage option in [Coredump] section
of /etc/systemd/coredump.conf or a drop-in file in
/etc/systemd/coredump.conf.d/*.conf
can be set to none to disable storing core dumps permanently. | ||||||||||
| 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
debugging. Permitting temporary enablement of core dumps during such situations
should be reviewed through local needs and policy. | ||||||||||
| Warnings | warning
If the /etc/systemd/coredump.conf file or a drop-in file under /etc/systemd/coredump.conf.d/
does not already contain the [Coredump] section,
the value will not be configured correctly. |
Enable Randomized Layout of Virtual Address Spacexccdf_org.ssgproject.content_rule_sysctl_kernel_randomize_va_space medium
Enable Randomized Layout of Virtual Address Space
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_kernel_randomize_va_space | ||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | To set the runtime status of the kernel.randomize_va_space kernel parameter, run the following command: $ sudo sysctl -w kernel.randomize_va_space=2To 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. |
Restrict usage of ptrace to descendant processesxccdf_org.ssgproject.content_rule_sysctl_kernel_yama_ptrace_scope medium
Restrict usage of ptrace to descendant processes
| Rule ID | xccdf_org.ssgproject.content_rule_sysctl_kernel_yama_ptrace_scope | ||||||||||||
| Result | notapplicable | ||||||||||||
| Multi-check rule | no | ||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||
| Severity | medium | ||||||||||||
| References: |
| ||||||||||||
| Description | To set the runtime status of the kernel.yama.ptrace_scope kernel parameter, run the following command: $ sudo sysctl -w kernel.yama.ptrace_scope=1To 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).
|
Install libselinux Packagexccdf_org.ssgproject.content_rule_package_libselinux_installed high
Install libselinux Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_libselinux_installed | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | high | ||||
| References: |
| ||||
| Description | 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. |
Uninstall mcstrans Packagexccdf_org.ssgproject.content_rule_package_mcstrans_removed low
Uninstall mcstrans Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_mcstrans_removed | ||
| Result | notapplicable | ||
| Multi-check rule | no | ||
| Time | 2026-03-29T19:53:37+00:00 | ||
| Severity | low | ||
| References: |
| ||
| Description | 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 remove mcstrans | ||
| Rationale | Since this service is not used very often, disable it to reduce the
amount of potentially vulnerable code running on the system. |
Uninstall setroubleshoot Packagexccdf_org.ssgproject.content_rule_package_setroubleshoot_removed low
Uninstall setroubleshoot Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_setroubleshoot_removed | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | low | ||||
| References: |
| ||||
| Description | 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 remove setroubleshoot | ||||
| Rationale | The SETroubleshoot service is an unnecessary daemon to
have running on a server, especially if
X Windows is removed or disabled. |
Ensure SELinux Not Disabled in /etc/default/grubxccdf_org.ssgproject.content_rule_grub2_enable_selinux medium
Ensure SELinux Not Disabled in /etc/default/grub
| Rule ID | xccdf_org.ssgproject.content_rule_grub2_enable_selinux | ||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||
| Description | 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. |
Ensure No Daemons are Unconfined by SELinuxxccdf_org.ssgproject.content_rule_selinux_confinement_of_daemons medium
Ensure No Daemons are Unconfined by SELinux
| Rule ID | xccdf_org.ssgproject.content_rule_selinux_confinement_of_daemons | ||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||
| Description | 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. | ||||||||||||||||||||||||
| Rationale | Daemons which run with the unconfined_service_t context may cause AVC denials,
or allow privileges that the daemon does not require. | ||||||||||||||||||||||||
| Warnings | 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. |
Ensure SELinux is Not Disabledxccdf_org.ssgproject.content_rule_selinux_not_disabled high
Ensure SELinux is Not Disabled
| Rule ID | xccdf_org.ssgproject.content_rule_selinux_not_disabled | ||
| Result | notapplicable | ||
| Multi-check rule | no | ||
| Time | 2026-03-29T19:53:37+00:00 | ||
| Severity | high | ||
| References: |
| ||
| Description | 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=enforcingOR SELINUX=permissiveEnsure that all files have correct SELinux labels by running: fixfiles onbootThen reboot the system. | ||
| 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. | ||
| Warnings | 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. |
Configure SELinux Policyxccdf_org.ssgproject.content_rule_selinux_policytype medium
Configure SELinux Policy
| Rule ID | xccdf_org.ssgproject.content_rule_selinux_policytype | ||||||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||||||
| Description | 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. |
Ensure SELinux State is Enforcingxccdf_org.ssgproject.content_rule_selinux_state high
Ensure SELinux State is Enforcing
| Rule ID | xccdf_org.ssgproject.content_rule_selinux_state | ||||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||||
| Severity | high | ||||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||||
| Description | 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
Ensure that all files have correct SELinux labels by running:
fixfiles onbootThen reboot the system. | ||||||||||||||||||||||||||||||||||
| 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. |
Uninstall avahi Server Packagexccdf_org.ssgproject.content_rule_package_avahi_removed medium
Uninstall avahi Server Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_avahi_removed | ||||||||||||||||
| Result | pass | ||||||||||||||||
| Multi-check rule | no | ||||||||||||||||
| OVAL Definition ID | oval:ssg-package_avahi_removed:def:1 | ||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||
| Severity | medium | ||||||||||||||||
| References: |
| ||||||||||||||||
| Description | 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. |
OVAL test results details
package avahi is removed oval:ssg-test_package_avahi_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_avahi_removed:obj:1 of type rpminfo_object
| Name |
|---|
| avahi |
Ensure that /etc/at.deny does not existxccdf_org.ssgproject.content_rule_file_at_deny_not_exist medium
Ensure that /etc/at.deny does not exist
| Rule ID | xccdf_org.ssgproject.content_rule_file_at_deny_not_exist | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
Ensure that /etc/cron.allow existsxccdf_org.ssgproject.content_rule_file_cron_allow_exists medium
Ensure that /etc/cron.allow exists
| Rule ID | xccdf_org.ssgproject.content_rule_file_cron_allow_exists | ||
| Result | notapplicable | ||
| Multi-check rule | no | ||
| Time | 2026-03-29T19:53:37+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description | 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. |
Ensure that /etc/cron.deny does not existxccdf_org.ssgproject.content_rule_file_cron_deny_not_exist medium
Ensure that /etc/cron.deny does not exist
| Rule ID | xccdf_org.ssgproject.content_rule_file_cron_deny_not_exist | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
Verify Group Who Owns /etc/at.allow filexccdf_org.ssgproject.content_rule_file_groupowner_at_allow medium
Verify Group Who Owns /etc/at.allow file
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_at_allow | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
Verify Group Who Owns /etc/cron.allow filexccdf_org.ssgproject.content_rule_file_groupowner_cron_allow medium
Verify Group Who Owns /etc/cron.allow file
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_cron_allow | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description | 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. |
Verify User Who Owns /etc/at.allow filexccdf_org.ssgproject.content_rule_file_owner_at_allow medium
Verify User Who Owns /etc/at.allow file
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_at_allow | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
Verify User Who Owns /etc/cron.allow filexccdf_org.ssgproject.content_rule_file_owner_cron_allow medium
Verify User Who Owns /etc/cron.allow file
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_cron_allow | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description | 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. |
Enable cron Servicexccdf_org.ssgproject.content_rule_service_crond_enabled medium
Enable cron Service
| Rule ID | xccdf_org.ssgproject.content_rule_service_crond_enabled | ||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||
| Severity | medium | ||||||||||||||||||
| References: |
| ||||||||||||||||||
| Description | 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. |
Verify Group Who Owns cron.dxccdf_org.ssgproject.content_rule_file_groupowner_cron_d medium
Verify Group Who Owns cron.d
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_cron_d | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description |
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. |
Verify Group Who Owns cron.dailyxccdf_org.ssgproject.content_rule_file_groupowner_cron_daily medium
Verify Group Who Owns cron.daily
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_cron_daily | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description |
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. |
Verify Group Who Owns cron.hourlyxccdf_org.ssgproject.content_rule_file_groupowner_cron_hourly medium
Verify Group Who Owns cron.hourly
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_cron_hourly | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description |
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. |
Verify Group Who Owns cron.monthlyxccdf_org.ssgproject.content_rule_file_groupowner_cron_monthly medium
Verify Group Who Owns cron.monthly
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_cron_monthly | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description |
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. |
Verify Group Who Owns cron.weeklyxccdf_org.ssgproject.content_rule_file_groupowner_cron_weekly medium
Verify Group Who Owns cron.weekly
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_cron_weekly | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description |
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. |
Verify Group Who Owns Crontabxccdf_org.ssgproject.content_rule_file_groupowner_crontab medium
Verify Group Who Owns Crontab
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_crontab | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description |
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. |
Verify Owner on cron.dxccdf_org.ssgproject.content_rule_file_owner_cron_d medium
Verify Owner on cron.d
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_cron_d | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description |
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. |
Verify Owner on cron.dailyxccdf_org.ssgproject.content_rule_file_owner_cron_daily medium
Verify Owner on cron.daily
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_cron_daily | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description |
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. |
Verify Owner on cron.hourlyxccdf_org.ssgproject.content_rule_file_owner_cron_hourly medium
Verify Owner on cron.hourly
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_cron_hourly | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description |
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. |
Verify Owner on cron.monthlyxccdf_org.ssgproject.content_rule_file_owner_cron_monthly medium
Verify Owner on cron.monthly
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_cron_monthly | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description |
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. |
Verify Owner on cron.weeklyxccdf_org.ssgproject.content_rule_file_owner_cron_weekly medium
Verify Owner on cron.weekly
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_cron_weekly | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description |
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. |
Verify Owner on crontabxccdf_org.ssgproject.content_rule_file_owner_crontab medium
Verify Owner on crontab
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_crontab | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description |
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. |
Uninstall DHCP Server Packagexccdf_org.ssgproject.content_rule_package_dhcp_removed medium
Uninstall DHCP Server Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_dhcp_removed | ||||||||||||||||||||
| Result | pass | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| OVAL Definition ID | oval:ssg-package_dhcp_removed:def:1 | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description | 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 remove dhcp | ||||||||||||||||||||
| Rationale | Removing the DHCP server ensures that it cannot be easily or
accidentally reactivated and disrupt network operation. |
OVAL test results details
package dhcp is removed oval:ssg-test_package_dhcp_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_dhcp_removed:obj:1 of type rpminfo_object
| Name |
|---|
| dhcp |
Uninstall bind Packagexccdf_org.ssgproject.content_rule_package_bind_removed low
Uninstall bind Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_bind_removed | ||||||||||||||||
| Result | pass | ||||||||||||||||
| Multi-check rule | no | ||||||||||||||||
| OVAL Definition ID | oval:ssg-package_bind_removed:def:1 | ||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||
| Severity | low | ||||||||||||||||
| References: |
| ||||||||||||||||
| Description | The named service is provided by the bind package.
The bind package can be removed with the following command:
$ sudo dnf remove bind | ||||||||||||||||
| Rationale | If there is no need to make DNS server software available,
removing it provides a safeguard against its activation. |
OVAL test results details
package bind is removed oval:ssg-test_package_bind_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_bind_removed:obj:1 of type rpminfo_object
| Name |
|---|
| bind |
Uninstall dnsmasq Packagexccdf_org.ssgproject.content_rule_package_dnsmasq_removed low
Uninstall dnsmasq Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_dnsmasq_removed | ||
| Result | pass | ||
| Multi-check rule | no | ||
| OVAL Definition ID | oval:ssg-package_dnsmasq_removed:def:1 | ||
| Time | 2026-03-29T19:53:37+00:00 | ||
| Severity | low | ||
| References: |
| ||
| Description | 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 remove 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. |
OVAL test results details
package dnsmasq is removed oval:ssg-test_package_dnsmasq_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_dnsmasq_removed:obj:1 of type rpminfo_object
| Name |
|---|
| dnsmasq |
Uninstall vsftpd Packagexccdf_org.ssgproject.content_rule_package_vsftpd_removed high
Uninstall vsftpd Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_vsftpd_removed | ||||||||||||||||||
| Result | pass | ||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||
| OVAL Definition ID | oval:ssg-package_vsftpd_removed:def:1 | ||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||
| Severity | high | ||||||||||||||||||
| References: |
| ||||||||||||||||||
| Description | The vsftpd package can be removed with the following command: $ sudo dnf remove vsftpd | ||||||||||||||||||
| Rationale | Removing the vsftpd package decreases the risk of its
accidental activation. |
OVAL test results details
package vsftpd is removed oval:ssg-test_package_vsftpd_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_vsftpd_removed:obj:1 of type rpminfo_object
| Name |
|---|
| vsftpd |
Remove ftp Packagexccdf_org.ssgproject.content_rule_package_ftp_removed low
Remove ftp Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_ftp_removed | ||||
| Result | pass | ||||
| Multi-check rule | no | ||||
| OVAL Definition ID | oval:ssg-package_ftp_removed:def:1 | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | low | ||||
| References: |
| ||||
| Description | 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 remove 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. |
OVAL test results details
package ftp is removed oval:ssg-test_package_ftp_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_ftp_removed:obj:1 of type rpminfo_object
| Name |
|---|
| ftp |
Uninstall httpd Packagexccdf_org.ssgproject.content_rule_package_httpd_removed unknown
Uninstall httpd Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_httpd_removed | ||||||||||||||||
| Result | pass | ||||||||||||||||
| Multi-check rule | no | ||||||||||||||||
| OVAL Definition ID | oval:ssg-package_httpd_removed:def:1 | ||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||
| Severity | unknown | ||||||||||||||||
| References: |
| ||||||||||||||||
| Description | The httpd package can be removed with the following command:
$ sudo dnf remove httpd | ||||||||||||||||
| Rationale | If there is no need to make the web server software available,
removing it provides a safeguard against its activation. |
OVAL test results details
package httpd is removed oval:ssg-test_package_httpd_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_httpd_removed:obj:1 of type rpminfo_object
| Name |
|---|
| httpd |
Uninstall nginx Packagexccdf_org.ssgproject.content_rule_package_nginx_removed unknown
Uninstall nginx Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_nginx_removed | ||||||||||||||
| Result | pass | ||||||||||||||
| Multi-check rule | no | ||||||||||||||
| OVAL Definition ID | oval:ssg-package_nginx_removed:def:1 | ||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||
| Severity | unknown | ||||||||||||||
| References: |
| ||||||||||||||
| Description | The nginx package can be removed with the following command:
$ sudo dnf remove nginx | ||||||||||||||
| Rationale | If there is no need to make the web server software available,
removing it provides a safeguard against its activation. |
OVAL test results details
package nginx is removed oval:ssg-test_package_nginx_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_nginx_removed:obj:1 of type rpminfo_object
| Name |
|---|
| nginx |
Uninstall cyrus-imapd Packagexccdf_org.ssgproject.content_rule_package_cyrus-imapd_removed unknown
Uninstall cyrus-imapd Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_cyrus-imapd_removed | ||
| Result | pass | ||
| Multi-check rule | no | ||
| OVAL Definition ID | oval:ssg-package_cyrus-imapd_removed:def:1 | ||
| Time | 2026-03-29T19:53:37+00:00 | ||
| Severity | unknown | ||
| References: |
| ||
| Description | The cyrus-imapd package can be removed with the following command:
$ sudo dnf remove cyrus-imapd | ||
| Rationale | If there is no need to make the cyrus-imapd software available,
removing it provides a safeguard against its activation. |
OVAL test results details
package cyrus-imapd is removed oval:ssg-test_package_cyrus-imapd_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_cyrus-imapd_removed:obj:1 of type rpminfo_object
| Name |
|---|
| cyrus-imapd |
Uninstall dovecot Packagexccdf_org.ssgproject.content_rule_package_dovecot_removed unknown
Uninstall dovecot Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_dovecot_removed | ||
| Result | pass | ||
| Multi-check rule | no | ||
| OVAL Definition ID | oval:ssg-package_dovecot_removed:def:1 | ||
| Time | 2026-03-29T19:53:37+00:00 | ||
| Severity | unknown | ||
| References: |
| ||
| Description |
The dovecot package can be removed with the following command:
$ sudo dnf remove dovecot | ||
| Rationale | If there is no need to make the Dovecot software available,
removing it provides a safeguard against its activation. |
OVAL test results details
package dovecot is removed oval:ssg-test_package_dovecot_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_dovecot_removed:obj:1 of type rpminfo_object
| Name |
|---|
| dovecot |
Ensure LDAP client is not installedxccdf_org.ssgproject.content_rule_package_openldap-clients_removed low
Ensure LDAP client is not installed
| Rule ID | xccdf_org.ssgproject.content_rule_package_openldap-clients_removed | ||
| Result | pass | ||
| Multi-check rule | no | ||
| OVAL Definition ID | oval:ssg-package_openldap-clients_removed:def:1 | ||
| Time | 2026-03-29T19:53:37+00:00 | ||
| Severity | low | ||
| References: |
| ||
| Description | 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 remove 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. |
OVAL test results details
package openldap-clients is removed oval:ssg-test_package_openldap-clients_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_openldap-clients_removed:obj:1 of type rpminfo_object
| Name |
|---|
| openldap-clients |
Disable Postfix Network Listeningxccdf_org.ssgproject.content_rule_postfix_network_listening_disabled medium
Disable Postfix Network Listening
| Rule ID | xccdf_org.ssgproject.content_rule_postfix_network_listening_disabled | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description | 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. |
Ensure Mail Transfer Agent is not Listening on any non-loopback Addressxccdf_org.ssgproject.content_rule_has_nonlocal_mta medium
Ensure Mail Transfer Agent is not Listening on any non-loopback Address
| Rule ID | xccdf_org.ssgproject.content_rule_has_nonlocal_mta | ||
| Result | notapplicable | ||
| Multi-check rule | no | ||
| Time | 2026-03-29T19:53:37+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description | 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. |
Disable rpcbind Servicexccdf_org.ssgproject.content_rule_service_rpcbind_disabled low
Disable rpcbind Service
| Rule ID | xccdf_org.ssgproject.content_rule_service_rpcbind_disabled | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | low | ||||
| References: |
| ||||
| Description | 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. |
Disable Network File System (nfs)xccdf_org.ssgproject.content_rule_service_nfs_disabled unknown
Disable Network File System (nfs)
| Rule ID | xccdf_org.ssgproject.content_rule_service_nfs_disabled | ||||||||||||||||
| Result | notapplicable | ||||||||||||||||
| Multi-check rule | no | ||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||
| Severity | unknown | ||||||||||||||||
| References: |
| ||||||||||||||||
| Description | 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. |
A remote time server for Chrony is configuredxccdf_org.ssgproject.content_rule_chronyd_specify_remote_server medium
A remote time server for Chrony is configured
| Rule ID | xccdf_org.ssgproject.content_rule_chronyd_specify_remote_server | ||||||||||||||
| Result | notapplicable | ||||||||||||||
| Multi-check rule | no | ||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||
| Severity | medium | ||||||||||||||
| References: |
| ||||||||||||||
| Description | 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. |
Ensure that chronyd is running under chrony user accountxccdf_org.ssgproject.content_rule_chronyd_run_as_chrony_user medium
Ensure that chronyd is running under chrony user account
| Rule ID | xccdf_org.ssgproject.content_rule_chronyd_run_as_chrony_user | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
Remove Rsh Trust Filesxccdf_org.ssgproject.content_rule_no_rsh_trust_files high
Remove Rsh Trust Files
| Rule ID | xccdf_org.ssgproject.content_rule_no_rsh_trust_files | ||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||
| Severity | high | ||||||||||||||||||
| References: |
| ||||||||||||||||||
| Description | 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. |
Uninstall telnet-server Packagexccdf_org.ssgproject.content_rule_package_telnet-server_removed high
Uninstall telnet-server Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_telnet-server_removed | ||||||||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-package_telnet-server_removed:def:1 | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||
| Severity | high | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | The telnet-server package can be removed with the following command:
$ sudo dnf remove 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
insecure. 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. |
OVAL test results details
package telnet-server is removed oval:ssg-test_package_telnet-server_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_telnet-server_removed:obj:1 of type rpminfo_object
| Name |
|---|
| telnet-server |
Remove telnet Clientsxccdf_org.ssgproject.content_rule_package_telnet_removed low
Remove telnet Clients
| Rule ID | xccdf_org.ssgproject.content_rule_package_telnet_removed | ||||||||||||||
| Result | pass | ||||||||||||||
| Multi-check rule | no | ||||||||||||||
| OVAL Definition ID | oval:ssg-package_telnet_removed:def:1 | ||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||
| Severity | low | ||||||||||||||
| References: |
| ||||||||||||||
| Description | 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. |
OVAL test results details
package telnet is removed oval:ssg-test_package_telnet_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_telnet_removed:obj:1 of type rpminfo_object
| Name |
|---|
| telnet |
Uninstall tftp-server Packagexccdf_org.ssgproject.content_rule_package_tftp-server_removed high
Uninstall tftp-server Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_tftp-server_removed | ||||||||||||||||||||||
| Result | pass | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| OVAL Definition ID | oval:ssg-package_tftp-server_removed:def:1 | ||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||
| Severity | high | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | The tftp-server package can be removed with the following command: $ sudo dnf remove 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 Security Manager (ISSM), restricted to only authorized personnel, and have access control rules established. |
OVAL test results details
package tftp-server is removed oval:ssg-test_package_tftp-server_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_tftp-server_removed:obj:1 of type rpminfo_object
| Name |
|---|
| tftp-server |
Uninstall rsync Packagexccdf_org.ssgproject.content_rule_package_rsync_removed medium
Uninstall rsync Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_rsync_removed | ||
| Result | pass | ||
| Multi-check rule | no | ||
| OVAL Definition ID | oval:ssg-package_rsync_removed:def:1 | ||
| Time | 2026-03-29T19:53:37+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description | 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 remove rsync | ||
| Rationale | The rsyncd service presents a security risk as it uses unencrypted protocols for
communication. |
OVAL test results details
package rsync is removed oval:ssg-test_package_rsync_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_rsync_removed:obj:1 of type rpminfo_object
| Name |
|---|
| rsync |
Uninstall CUPS Packagexccdf_org.ssgproject.content_rule_package_cups_removed unknown
Uninstall CUPS Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_cups_removed | ||||||||||||||||
| Result | pass | ||||||||||||||||
| Multi-check rule | no | ||||||||||||||||
| OVAL Definition ID | oval:ssg-package_cups_removed:def:1 | ||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||
| Severity | unknown | ||||||||||||||||
| References: |
| ||||||||||||||||
| Description | The cups package can be removed with the following command:
$ sudo dnf remove 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. |
OVAL test results details
package cups is removed oval:ssg-test_package_cups_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_cups_removed:obj:1 of type rpminfo_object
| Name |
|---|
| cups |
Uninstall squid Packagexccdf_org.ssgproject.content_rule_package_squid_removed unknown
Uninstall squid Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_squid_removed | ||||
| Result | pass | ||||
| Multi-check rule | no | ||||
| OVAL Definition ID | oval:ssg-package_squid_removed:def:1 | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | unknown | ||||
| References: |
| ||||
| Description | The squid package can be removed with the following command: $ sudo dnf remove squid | ||||
| Rationale | If there is no need to make the proxy server software available,
removing it provides a safeguard against its activation. |
OVAL test results details
package squid is removed oval:ssg-test_package_squid_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_squid_removed:obj:1 of type rpminfo_object
| Name |
|---|
| squid |
Uninstall Samba Packagexccdf_org.ssgproject.content_rule_package_samba_removed unknown
Uninstall Samba Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_samba_removed | ||
| Result | pass | ||
| Multi-check rule | no | ||
| OVAL Definition ID | oval:ssg-package_samba_removed:def:1 | ||
| Time | 2026-03-29T19:53:37+00:00 | ||
| Severity | unknown | ||
| References: |
| ||
| Description | The samba package can be removed with the following command: $ sudo dnf remove samba | ||
| Rationale | If there is no need to make the Samba software available,
removing it provides a safeguard against its activation. |
OVAL test results details
package samba is removed oval:ssg-test_package_samba_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_samba_removed:obj:1 of type rpminfo_object
| Name |
|---|
| samba |
Uninstall net-snmp Packagexccdf_org.ssgproject.content_rule_package_net-snmp_removed unknown
Uninstall net-snmp Package
| Rule ID | xccdf_org.ssgproject.content_rule_package_net-snmp_removed | ||||
| Result | pass | ||||
| Multi-check rule | no | ||||
| OVAL Definition ID | oval:ssg-package_net-snmp_removed:def:1 | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | unknown | ||||
| References: |
| ||||
| Description |
The net-snmp package provides the snmpd service.
The net-snmp package can be removed with the following command:
$ sudo dnf remove net-snmp | ||||
| Rationale | If there is no need to run SNMP server software,
removing the package provides a safeguard against its
activation. |
OVAL test results details
package net-snmp is removed oval:ssg-test_package_net-snmp_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_net-snmp_removed:obj:1 of type rpminfo_object
| Name |
|---|
| net-snmp |
Disable snmpd Servicexccdf_org.ssgproject.content_rule_service_snmpd_disabled low
Disable snmpd Service
| Rule ID | xccdf_org.ssgproject.content_rule_service_snmpd_disabled | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | low | ||||
| References: |
| ||||
| Description |
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. |
Set SSH Client Alive Count Maxxccdf_org.ssgproject.content_rule_sshd_set_keepalive medium
Set SSH Client Alive Count Max
| Rule ID | xccdf_org.ssgproject.content_rule_sshd_set_keepalive | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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. |
Set SSH Client Alive Intervalxccdf_org.ssgproject.content_rule_sshd_set_idle_timeout medium
Set SSH Client Alive Interval
| Rule ID | xccdf_org.ssgproject.content_rule_sshd_set_idle_timeout | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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. | ||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||
| Warnings | 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:
|
Disable Host-Based Authenticationxccdf_org.ssgproject.content_rule_disable_host_auth medium
Disable Host-Based Authentication
| Rule ID | xccdf_org.ssgproject.content_rule_disable_host_auth | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | 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. |
Disable SSH Access via Empty Passwordsxccdf_org.ssgproject.content_rule_sshd_disable_empty_passwords high
Disable SSH Access via Empty Passwords
| Rule ID | xccdf_org.ssgproject.content_rule_sshd_disable_empty_passwords | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | high | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | 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 noAny 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. |
Disable SSH Support for .rhosts Filesxccdf_org.ssgproject.content_rule_sshd_disable_rhosts medium
Disable SSH Support for .rhosts Files
| Rule ID | xccdf_org.ssgproject.content_rule_sshd_disable_rhosts | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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. |
Disable SSH Root Loginxccdf_org.ssgproject.content_rule_sshd_disable_root_login medium
Disable SSH Root Login
| Rule ID | xccdf_org.ssgproject.content_rule_sshd_disable_root_login | ||||||||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||||||||
| Description | 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. |
Disable SSH TCP Forwardingxccdf_org.ssgproject.content_rule_sshd_disable_tcp_forwarding medium
Disable SSH TCP Forwarding
| Rule ID | xccdf_org.ssgproject.content_rule_sshd_disable_tcp_forwarding | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
Disable X11 Forwardingxccdf_org.ssgproject.content_rule_sshd_disable_x11_forwarding medium
Disable X11 Forwarding
| Rule ID | xccdf_org.ssgproject.content_rule_sshd_disable_x11_forwarding | ||||||||||
| Result | notapplicable | ||||||||||
| Multi-check rule | no | ||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||
| Severity | medium | ||||||||||
| References: |
| ||||||||||
| Description | 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. |
Do Not Allow SSH Environment Optionsxccdf_org.ssgproject.content_rule_sshd_do_not_permit_user_env medium
Do Not Allow SSH Environment Options
| Rule ID | xccdf_org.ssgproject.content_rule_sshd_do_not_permit_user_env | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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. |
Enable PAMxccdf_org.ssgproject.content_rule_sshd_enable_pam medium
Enable PAM
| Rule ID | xccdf_org.ssgproject.content_rule_sshd_enable_pam | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||
| Severity | medium | ||||||
| References: |
| ||||||
| Description | 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. |
Limit Users' SSH Accessxccdf_org.ssgproject.content_rule_sshd_limit_user_access unknown
Limit Users' SSH Access
| Rule ID | xccdf_org.ssgproject.content_rule_sshd_limit_user_access | ||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||
| Severity | unknown | ||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||
| Description | 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. | ||||||||||||||||||||||||
| Rationale | Specifying which accounts are allowed SSH access into the system reduces the
possibility of unauthorized access to the system. | ||||||||||||||||||||||||
| Warnings | warning
Automated remediation is not available for this configuration check
because each system has unique user names and group names. |
Ensure SSH LoginGraceTime is configuredxccdf_org.ssgproject.content_rule_sshd_set_login_grace_time medium
Ensure SSH LoginGraceTime is configured
| Rule ID | xccdf_org.ssgproject.content_rule_sshd_set_login_grace_time | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
Set SSH Daemon LogLevel to VERBOSExccdf_org.ssgproject.content_rule_sshd_set_loglevel_verbose medium
Set SSH Daemon LogLevel to VERBOSE
| Rule ID | xccdf_org.ssgproject.content_rule_sshd_set_loglevel_verbose | ||||||||||||
| Result | notapplicable | ||||||||||||
| Multi-check rule | no | ||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||
| Severity | medium | ||||||||||||
| References: |
| ||||||||||||
| Description | 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. |
Set SSH authentication attempt limitxccdf_org.ssgproject.content_rule_sshd_set_max_auth_tries medium
Set SSH authentication attempt limit
| Rule ID | xccdf_org.ssgproject.content_rule_sshd_set_max_auth_tries | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||
| Severity | medium | ||||||
| References: |
| ||||||
| Description | 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. |
Set SSH MaxSessions limitxccdf_org.ssgproject.content_rule_sshd_set_max_sessions medium
Set SSH MaxSessions limit
| Rule ID | xccdf_org.ssgproject.content_rule_sshd_set_max_sessions | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
Ensure SSH MaxStartups is configuredxccdf_org.ssgproject.content_rule_sshd_set_maxstartups medium
Ensure SSH MaxStartups is configured
| Rule ID | xccdf_org.ssgproject.content_rule_sshd_set_maxstartups | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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 configure MaxStartups, you should
add or edit the following line in the /etc/ssh/sshd_config file:
MaxStartups 10:30:60
| ||||
| 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. |
Verify Group Who Owns SSH Server config filexccdf_org.ssgproject.content_rule_file_groupowner_sshd_config medium
Verify Group Who Owns SSH Server config file
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupowner_sshd_config | ||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description |
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. |
Verify Group Ownership on SSH Server Private *_key Key Filesxccdf_org.ssgproject.content_rule_file_groupownership_sshd_private_key medium
Verify Group Ownership on SSH Server Private *_key Key Files
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupownership_sshd_private_key | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. | ||||
| Warnings | warning
Remediation is not possible at bootable container build time because SSH host
keys are generated post-deployment. |
Verify Group Ownership on SSH Server Public *.pub Key Filesxccdf_org.ssgproject.content_rule_file_groupownership_sshd_pub_key medium
Verify Group Ownership on SSH Server Public *.pub Key Files
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupownership_sshd_pub_key | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. | ||||
| Warnings | warning
Remediation is not possible at bootable container build time because SSH host
keys are generated post-deployment. |
Verify Owner on SSH Server config filexccdf_org.ssgproject.content_rule_file_owner_sshd_config medium
Verify Owner on SSH Server config file
| Rule ID | xccdf_org.ssgproject.content_rule_file_owner_sshd_config | ||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description |
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. |
Verify Ownership on SSH Server Private *_key Key Filesxccdf_org.ssgproject.content_rule_file_ownership_sshd_private_key medium
Verify Ownership on SSH Server Private *_key Key Files
| Rule ID | xccdf_org.ssgproject.content_rule_file_ownership_sshd_private_key | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. | ||||
| Warnings | warning
Remediation is not possible at bootable container build time because SSH host
keys are generated post-deployment. |
Verify Ownership on SSH Server Public *.pub Key Filesxccdf_org.ssgproject.content_rule_file_ownership_sshd_pub_key medium
Verify Ownership on SSH Server Public *.pub Key Files
| Rule ID | xccdf_org.ssgproject.content_rule_file_ownership_sshd_pub_key | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. | ||||
| Warnings | warning
Remediation is not possible at bootable container build time because SSH host
keys are generated post-deployment. |
Remove the X Windows Package Groupxccdf_org.ssgproject.content_rule_package_xorg-x11-server-common_removed medium
Remove the X Windows Package Group
| Rule ID | xccdf_org.ssgproject.content_rule_package_xorg-x11-server-common_removed | ||||||||||||||||||
| Result | pass | ||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||
| OVAL Definition ID | oval:ssg-package_xorg-x11-server-common_removed:def:1 | ||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||
| Severity | medium | ||||||||||||||||||
| References: |
| ||||||||||||||||||
| Description | 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 | ||||||||||||||||||
| 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. | ||||||||||||||||||
| Warnings | 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. |
OVAL test results details
package xorg-x11-server-common is removed oval:ssg-test_package_xorg-x11-server-common_removed:tst:1 true
No items have been found conforming to the following objects:
Object oval:ssg-obj_test_package_xorg-x11-server-common_removed:obj:1 of type rpminfo_object
| Name |
|---|
| xorg-x11-server-common |
Record Events that Modify the System's Discretionary Access Controls - chmodxccdf_org.ssgproject.content_rule_audit_rules_dac_modification_chmod medium
Record Events that Modify the System's Discretionary Access Controls - chmod
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_chmod | ||||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||||
| Description | 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_modIf 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_modIf 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_modIf 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 | ||||||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Events that Modify the System's Discretionary Access Controls - chownxccdf_org.ssgproject.content_rule_audit_rules_dac_modification_chown medium
Record Events that Modify the System's Discretionary Access Controls - chown
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_chown | ||||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||||
| Description | 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_modIf 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_modIf 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_modIf 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 | ||||||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Events that Modify the System's Discretionary Access Controls - fchmodxccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchmod medium
Record Events that Modify the System's Discretionary Access Controls - fchmod
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchmod | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | 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_modIf 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_modIf 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_modIf 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 | ||||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Events that Modify the System's Discretionary Access Controls - fchmodatxccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchmodat medium
Record Events that Modify the System's Discretionary Access Controls - fchmodat
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchmodat | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | 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_modIf 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_modIf 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_modIf 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 | ||||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Events that Modify the System's Discretionary Access Controls - fchownxccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchown medium
Record Events that Modify the System's Discretionary Access Controls - fchown
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchown | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | 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_modIf 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_modIf 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_modIf 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 | ||||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Events that Modify the System's Discretionary Access Controls - fchownatxccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchownat medium
Record Events that Modify the System's Discretionary Access Controls - fchownat
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fchownat | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | 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_modIf 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_modIf 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_modIf 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 | ||||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Events that Modify the System's Discretionary Access Controls - fremovexattrxccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fremovexattr medium
Record Events that Modify the System's Discretionary Access Controls - fremovexattr
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fremovexattr | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | 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 | ||||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Events that Modify the System's Discretionary Access Controls - fsetxattrxccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fsetxattr medium
Record Events that Modify the System's Discretionary Access Controls - fsetxattr
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_fsetxattr | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | 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_modIf 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_modIf 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_modIf 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 | ||||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Events that Modify the System's Discretionary Access Controls - lchownxccdf_org.ssgproject.content_rule_audit_rules_dac_modification_lchown medium
Record Events that Modify the System's Discretionary Access Controls - lchown
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_lchown | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | 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_modIf 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_modIf 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_modIf 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 | ||||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Events that Modify the System's Discretionary Access Controls - lremovexattrxccdf_org.ssgproject.content_rule_audit_rules_dac_modification_lremovexattr medium
Record Events that Modify the System's Discretionary Access Controls - lremovexattr
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_lremovexattr | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | 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 | ||||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Events that Modify the System's Discretionary Access Controls - lsetxattrxccdf_org.ssgproject.content_rule_audit_rules_dac_modification_lsetxattr medium
Record Events that Modify the System's Discretionary Access Controls - lsetxattr
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_lsetxattr | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | 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_modIf 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_modIf 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_modIf 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 | ||||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Events that Modify the System's Discretionary Access Controls - removexattrxccdf_org.ssgproject.content_rule_audit_rules_dac_modification_removexattr medium
Record Events that Modify the System's Discretionary Access Controls - removexattr
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_removexattr | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | 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 | ||||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Events that Modify the System's Discretionary Access Controls - setxattrxccdf_org.ssgproject.content_rule_audit_rules_dac_modification_setxattr medium
Record Events that Modify the System's Discretionary Access Controls - setxattr
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_dac_modification_setxattr | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | 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_modIf 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_modIf 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_modIf 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 | ||||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Any Attempts to Run chaclxccdf_org.ssgproject.content_rule_audit_rules_execution_chacl medium
Record Any Attempts to Run chacl
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_execution_chacl | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||
| Severity | medium | ||||||
| References: |
| ||||||
| Description |
At a minimum, the audit system should collect the execution of privileged
commands for all users and root.
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add
a line of the following form to a file with suffix .rules
in the directory /etc/audit/rules.d:
-a always,exit -F path=/usr/bin/chacl -F auid>=1000 -F auid!=unset -F key=privilegedIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add a line of the
following form to /etc/audit/audit.rules:
-a always,exit -F path=/usr/bin/chacl -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). |
Record Any Attempts to Run setfaclxccdf_org.ssgproject.content_rule_audit_rules_execution_setfacl medium
Record Any Attempts to Run setfacl
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_execution_setfacl | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||
| Severity | medium | ||||||
| References: |
| ||||||
| Description |
At a minimum, the audit system should collect the execution of privileged
commands for all users and root.
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add
a line of the following form to a file with suffix .rules
in the directory /etc/audit/rules.d:
-a always,exit -F path=/usr/bin/setfacl -F auid>=1000 -F auid!=unset -F key=privilegedIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add a line of the
following form to /etc/audit/audit.rules:
-a always,exit -F path=/usr/bin/setfacl -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). |
Record Any Attempts to Run chconxccdf_org.ssgproject.content_rule_audit_rules_execution_chcon medium
Record Any Attempts to Run chcon
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_execution_chcon | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description |
At a minimum, the audit system should collect the execution of privileged
commands for all users and root.
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add
a line of the following form to a file with suffix .rules
in the directory /etc/audit/rules.d:
-a always,exit -F path=/usr/bin/chcon -F auid>=1000 -F auid!=unset -F key=privilegedIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add a line of the
following form to /etc/audit/audit.rules:
-a always,exit -F path=/usr/bin/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. |
Ensure auditd Collects File Deletion Events by User - renamexccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_rename medium
Ensure auditd Collects File Deletion Events by User - rename
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_rename | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=deleteIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete | ||||||||||||||||||||||||||||||
| Rationale | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. |
Ensure auditd Collects File Deletion Events by User - renameatxccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_renameat medium
Ensure auditd Collects File Deletion Events by User - renameat
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_renameat | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=deleteIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete | ||||||||||||||||||||||||||||||
| Rationale | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. |
Ensure auditd Collects File Deletion Events by User - unlinkxccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_unlink medium
Ensure auditd Collects File Deletion Events by User - unlink
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_unlink | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=deleteIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete | ||||||||||||||||||||||||||||||
| Rationale | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. |
Ensure auditd Collects File Deletion Events by User - unlinkatxccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_unlinkat medium
Ensure auditd Collects File Deletion Events by User - unlinkat
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_unlinkat | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=deleteIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 for 32-bit
system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete | ||||||||||||||||||||||||||||||
| Rationale | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. |
Record Unsuccessful Access Attempts to Files - creatxccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_creat medium
Record Unsuccessful Access Attempts to Files - creat
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_creat | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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=accessIf 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=accessIf 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=accessIf 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 | ||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Unsuccessful Access Attempts to Files - ftruncatexccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_ftruncate medium
Record Unsuccessful Access Attempts to Files - ftruncate
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_ftruncate | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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=accessIf 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=accessIf 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=accessIf 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 | ||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Unsuccessful Access Attempts to Files - openxccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_open medium
Record Unsuccessful Access Attempts to Files - open
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_open | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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=accessIf 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=accessIf 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=accessIf 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 | ||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Unsuccessful Access Attempts to Files - openatxccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_openat medium
Record Unsuccessful Access Attempts to Files - openat
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_openat | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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=accessIf 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=accessIf 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=accessIf 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 | ||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||
| Warnings | 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. |
Record Unsuccessful Access Attempts to Files - truncatexccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_truncate medium
Record Unsuccessful Access Attempts to Files - truncate
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_truncate | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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=accessIf 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=accessIf 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=accessIf 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 | ||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||
| Warnings | 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. |
Ensure auditd Collects Information on Kernel Module Unloading - create_modulexccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_create medium
Ensure auditd Collects Information on Kernel Module Unloading - create_module
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_create | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description |
To capture kernel module loading and unloading events, use the 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=modulesPlace 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. |
Ensure auditd Collects Information on Kernel Module Unloading - delete_modulexccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_delete medium
Ensure auditd Collects Information on Kernel Module Unloading - delete_module
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_delete | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description |
To capture kernel module loading and unloading events, use the 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=modulesPlace 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. |
Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_modulexccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_finit medium
Ensure auditd Collects Information on Kernel Module Loading and Unloading - finit_module
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_finit | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description |
To capture kernel module loading and unloading events, use the 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 finit_module -F key=modulesPlace 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/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. |
Ensure auditd Collects Information on Kernel Module Loading - init_modulexccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_init medium
Ensure auditd Collects Information on Kernel Module Loading - init_module
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_init | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description |
To capture kernel module loading and unloading events, use the 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=modulesPlace 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. |
Ensure auditd Collects Information on Kernel Module Loading and Unloading - query_modulexccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_query medium
Ensure auditd Collects Information on Kernel Module Loading and Unloading - query_module
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_loading_query | ||
| Result | notapplicable | ||
| Multi-check rule | no | ||
| Time | 2026-03-29T19:53:37+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description |
To capture kernel module loading and unloading events, use the 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 query_module -F key=modulesPlace 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/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. |
Record Attempts to Alter Logon and Logout Events - faillockxccdf_org.ssgproject.content_rule_audit_rules_login_events_faillock medium
Record Attempts to Alter Logon and Logout Events - faillock
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_login_events_faillock | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | The audit system already collects login information for all users
and root.
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /var/run/faillock -p wa -k loginsIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /var/run/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. |
Record Attempts to Alter Logon and Logout Events - lastlogxccdf_org.ssgproject.content_rule_audit_rules_login_events_lastlog medium
Record Attempts to Alter Logon and Logout Events - lastlog
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_login_events_lastlog | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | The audit system already collects login information for all users
and root.
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /var/log/lastlog -p wa -k loginsIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /var/log/lastlog -p wa -k logins | ||||||||||||||||||||||||||||||||
| Rationale | Manual editing of these files may indicate nefarious activity, such
as an attacker attempting to remove evidence of an intrusion. |
Ensure auditd Collects Information on the Use of Privileged Commandsxccdf_org.ssgproject.content_rule_audit_rules_privileged_commands medium
Ensure auditd Collects Information on the Use of Privileged Commands
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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/nullFor each setuid / setgid program identified by the previous command, an audit rule must be present in the appropriate place using the following line structure, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit: -a always,exit -F arch=ARCH -F path=PROG_PATH -F perm=x -F auid>=1000 -F auid!=unset -F key=privilegedIf 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. | ||||||||||||||||||||||||||||||
| 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. | ||||||||||||||||||||||||||||||
| Warnings | 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:
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. |
Ensure auditd Collects Information on the Use of Privileged Commands - kmodxccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_kmod medium
Ensure auditd Collects Information on the Use of Privileged Commands - kmod
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_kmod | ||||||||||
| Result | notapplicable | ||||||||||
| Multi-check rule | no | ||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||
| Severity | medium | ||||||||||
| References: |
| ||||||||||
| Description |
At a minimum, the audit system should collect the execution of privileged
commands for all users and root.
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add
a line of the following form to a file with suffix .rules
in the directory /etc/audit/rules.d:
-a always,exit -F path=/usr/bin/kmod -F auid>=1000 -F auid!=unset -F key=privilegedIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add a line of the
following form to /etc/audit/audit.rules:
-a always,exit -F path=/usr/bin/kmod -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). |
Ensure auditd Collects Information on the Use of Privileged Commands - usermodxccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_usermod medium
Ensure auditd Collects Information on the Use of Privileged Commands - usermod
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_privileged_commands_usermod | ||||||
| Result | notapplicable | ||||||
| Multi-check rule | no | ||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||
| Severity | medium | ||||||
| References: |
| ||||||
| Description |
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 auid>=1000 -F auid!=unset -F key=privilegedIf 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 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. |
Record attempts to alter time through adjtimexxccdf_org.ssgproject.content_rule_audit_rules_time_adjtimex medium
Record attempts to alter time through adjtimex
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_time_adjtimex | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S adjtimex -F key=audit_time_rulesIf 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_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S adjtimex -F key=audit_time_rulesThe -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. |
Record Attempts to Alter Time Through clock_settimexccdf_org.ssgproject.content_rule_audit_rules_time_clock_settime medium
Record Attempts to Alter Time Through clock_settime
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_time_clock_settime | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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-changeIf 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-changeIf 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-changeIf 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-changeThe -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. |
Record attempts to alter time through settimeofdayxccdf_org.ssgproject.content_rule_audit_rules_time_settimeofday medium
Record attempts to alter time through settimeofday
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_time_settimeofday | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S settimeofday -F key=audit_time_rulesIf 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_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S settimeofday -F key=audit_time_rulesThe -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. |
Record Attempts to Alter Time Through stimexccdf_org.ssgproject.content_rule_audit_rules_time_stime medium
Record Attempts to Alter Time Through stime
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_time_stime | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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_rulesSince 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_rulesSince 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. |
Record Attempts to Alter the localtime Filexccdf_org.ssgproject.content_rule_audit_rules_time_watch_localtime medium
Record Attempts to Alter the localtime File
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_time_watch_localtime | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description |
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/localtime -p wa -k audit_time_rulesIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/localtime -p wa -k audit_time_rules | ||||||||||||||||||||||||||||||
| Rationale | Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time (such as sshd). All changes
to the system time should be audited. |
Make the auditd Configuration Immutablexccdf_org.ssgproject.content_rule_audit_rules_immutable medium
Make the auditd Configuration Immutable
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_immutable | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | 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 2If 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 2With 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. |
Record Events that Modify the System's Mandatory Access Controlsxccdf_org.ssgproject.content_rule_audit_rules_mac_modification medium
Record Events that Modify the System's Mandatory Access Controls
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_mac_modification | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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-policyIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-w /etc/selinux/ -p wa -k MAC-policy | ||||||||||||||||||||||||||||
| Rationale | The system's mandatory access policy (SELinux or Apparmor) should not be
arbitrarily changed by anything other than administrator action. All changes to
MAC policy should be audited. |
Record Events that Modify the System's Mandatory Access Controls in usr/sharexccdf_org.ssgproject.content_rule_audit_rules_mac_modification_usr_share medium
Record Events that Modify the System's Mandatory Access Controls in usr/share
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_mac_modification_usr_share | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description |
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /usr/share/selinux/ -p wa -k MAC-policyIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /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. |
Ensure auditd Collects Information on Exporting to Media (successful)xccdf_org.ssgproject.content_rule_audit_rules_media_export medium
Ensure auditd Collects Information on Exporting to Media (successful)
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_media_export | ||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||
| Description | At a minimum, the audit system should collect media exportation
events for all users and root. If the auditd daemon is configured to
use the augenrules program to read audit rules during daemon startup
(the default), add the following line to a file with suffix .rules in
the directory /etc/audit/rules.d, setting ARCH to either b32 for
32-bit system, or having two lines for both b32 and b64 in case your
system is 64-bit:
-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=exportIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 for
32-bit system, or having two lines for both b32 and b64 in case your
system is 64-bit:
-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export | ||||||||||||||||||||||||||||||||
| Rationale | The unauthorized exportation of data to external media could result in an information leak
where classified information, Privacy Act information, and intellectual property could be lost. An audit
trail should be created each time a filesystem is mounted to help identify and guard against information
loss. |
Record Events that Modify the System's Network Environmentxccdf_org.ssgproject.content_rule_audit_rules_networkconfig_modification medium
Record Events that Modify the System's Network Environment
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_networkconfig_modification | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 for
32-bit system, or having two lines for both b32 and b64 in case your system
is 64-bit:
-a always,exit -F arch=ARCH -S sethostname,setdomainname -F key=audit_rules_networkconfig_modification -w /etc/issue -p wa -k audit_rules_networkconfig_modification -w /etc/issue.net -p wa -k audit_rules_networkconfig_modification -w /etc/hosts -p wa -k audit_rules_networkconfig_modification -w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modificationIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, setting ARCH to either b32 for
32-bit system, or having two lines for both b32 and b64 in case your system
is 64-bit:
-a always,exit -F arch=ARCH -S sethostname,setdomainname -F key=audit_rules_networkconfig_modification -w /etc/issue -p wa -k audit_rules_networkconfig_modification -w /etc/issue.net -p wa -k audit_rules_networkconfig_modification -w /etc/hosts -p wa -k audit_rules_networkconfig_modification -w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification | ||||||||||||||||||||||||||||||
| Rationale | The network environment should not be modified by anything other
than administrator action. Any change to network parameters should be
audited. |
Record Events that Modify the System's Network Environment - /etc/sysconfig/network-scriptsxccdf_org.ssgproject.content_rule_audit_rules_networkconfig_modification_network_scripts medium
Record Events that Modify the System's Network Environment - /etc/sysconfig/network-scripts
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_networkconfig_modification_network_scripts | ||
| Result | notapplicable | ||
| Multi-check rule | no | ||
| Time | 2026-03-29T19:53:37+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description |
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/sysconfig/network-scripts -p wa -k audit_rules_networkconfig_modification_network_scriptsIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/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. |
Record Attempts to Alter Process and Session Initiation Informationxccdf_org.ssgproject.content_rule_audit_rules_session_events medium
Record Attempts to Alter Process and Session Initiation Information
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_session_events | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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 sessionIf 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. |
Record Events When Executables Are Run As Another Userxccdf_org.ssgproject.content_rule_audit_rules_suid_auid_privilege_function medium
Record Events When Executables Are Run As Another User
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_suid_auid_privilege_function | ||
| Result | notapplicable | ||
| Multi-check rule | no | ||
| Time | 2026-03-29T19:53:37+00:00 | ||
| Severity | medium | ||
| References: |
| ||
| Description | 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.rulesIf 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_emulationIf both the "b32" and "b64" audit rules for "SUID" files are not defined, this is a finding. | ||
| 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. | ||
| Warnings | warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. |
Ensure auditd Collects System Administrator Actionsxccdf_org.ssgproject.content_rule_audit_rules_sysadmin_actions medium
Ensure auditd Collects System Administrator Actions
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_sysadmin_actions | ||||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||||
| Description |
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/sudoers -p wa -k actionsIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/sudoers -p wa -k actionsIf the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/sudoers.d/ -p wa -k actionsIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/sudoers.d/ -p wa -k actions | ||||||||||||||||||||||||||||||||||
| Rationale | The actions taken by system administrators should be audited to keep a record
of what was executed on the system, as well as, for accountability purposes. |
Record Events that Modify User/Group Information - /etc/groupxccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_group medium
Record Events that Modify User/Group Information - /etc/group
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_group | ||||||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||||||
| Description |
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/group -p wa -k audit_rules_usergroup_modificationIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/group -p wa -k audit_rules_usergroup_modification | ||||||||||||||||||||||||||||||||||||
| Rationale | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. |
Record Events that Modify User/Group Information - /etc/gshadowxccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_gshadow medium
Record Events that Modify User/Group Information - /etc/gshadow
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_gshadow | ||||||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||||||
| Description |
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/gshadow -p wa -k audit_rules_usergroup_modificationIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification | ||||||||||||||||||||||||||||||||||||
| Rationale | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. |
Record Events that Modify User/Group Information - /etc/security/opasswdxccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_opasswd medium
Record Events that Modify User/Group Information - /etc/security/opasswd
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_opasswd | ||||||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||||||
| Description |
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modificationIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification | ||||||||||||||||||||||||||||||||||||
| Rationale | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. |
Record Events that Modify User/Group Information - /etc/passwdxccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_passwd medium
Record Events that Modify User/Group Information - /etc/passwd
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_passwd | ||||||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||||||
| Description |
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/passwd -p wa -k audit_rules_usergroup_modificationIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/passwd -p wa -k audit_rules_usergroup_modification | ||||||||||||||||||||||||||||||||||||
| Rationale | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. |
Record Events that Modify User/Group Information - /etc/shadowxccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_shadow medium
Record Events that Modify User/Group Information - /etc/shadow
| Rule ID | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_shadow | ||||||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||||||
| Description |
If the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/shadow -p wa -k audit_rules_usergroup_modificationIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /etc/shadow -p wa -k audit_rules_usergroup_modification | ||||||||||||||||||||||||||||||||||||
| Rationale | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. |
Record Attempts to perform maintenance activitiesxccdf_org.ssgproject.content_rule_audit_sudo_log_events medium
Record Attempts to perform maintenance activities
| Rule ID | xccdf_org.ssgproject.content_rule_audit_sudo_log_events | ||||||||||
| Result | notapplicable | ||||||||||
| Multi-check rule | no | ||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||
| Severity | medium | ||||||||||
| References: |
| ||||||||||
| Description | 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 maintenanceIf the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add the
following lines to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /var/log/sudo.log -p wa -k maintenanceIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules:
-w /var/log/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. |
System Audit Logs Must Be Group Owned By Rootxccdf_org.ssgproject.content_rule_file_group_ownership_var_log_audit medium
System Audit Logs Must Be Group Owned By Root
| Rule ID | xccdf_org.ssgproject.content_rule_file_group_ownership_var_log_audit | ||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||
| Description | 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.confor, 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. |
Audit Configuration Files Must Be Owned By Group rootxccdf_org.ssgproject.content_rule_file_groupownership_audit_configuration medium
Audit Configuration Files Must Be Owned By Group root
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupownership_audit_configuration | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
Audit Configuration Files Must Be Owned By Rootxccdf_org.ssgproject.content_rule_file_ownership_audit_configuration medium
Audit Configuration Files Must Be Owned By Root
| Rule ID | xccdf_org.ssgproject.content_rule_file_ownership_audit_configuration | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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. |
System Audit Logs Must Be Owned By Rootxccdf_org.ssgproject.content_rule_file_ownership_var_log_audit_stig medium
System Audit Logs Must Be Owned By Root
| Rule ID | xccdf_org.ssgproject.content_rule_file_ownership_var_log_audit_stig | ||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||
| Description | 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.confor 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. |
Configure auditd mail_acct Action on Low Disk Spacexccdf_org.ssgproject.content_rule_auditd_data_retention_action_mail_acct medium
Configure auditd mail_acct Action on Low Disk Space
| Rule ID | xccdf_org.ssgproject.content_rule_auditd_data_retention_action_mail_acct | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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. |
Configure auditd admin_space_left Action on Low Disk Spacexccdf_org.ssgproject.content_rule_auditd_data_retention_admin_space_left_action medium
Configure auditd admin_space_left Action on Low Disk Space
| Rule ID | xccdf_org.ssgproject.content_rule_auditd_data_retention_admin_space_left_action | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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. |
Configure auditd Max Log File Sizexccdf_org.ssgproject.content_rule_auditd_data_retention_max_log_file medium
Configure auditd Max Log File Size
| Rule ID | xccdf_org.ssgproject.content_rule_auditd_data_retention_max_log_file | ||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||
| Description | 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. |
Configure auditd max_log_file_action Upon Reaching Maximum Log Sizexccdf_org.ssgproject.content_rule_auditd_data_retention_max_log_file_action medium
Configure auditd max_log_file_action Upon Reaching Maximum Log Size
| Rule ID | xccdf_org.ssgproject.content_rule_auditd_data_retention_max_log_file_action | ||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||
| Description | 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:
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. |
Configure auditd space_left Action on Low Disk Spacexccdf_org.ssgproject.content_rule_auditd_data_retention_space_left_action medium
Configure auditd space_left Action on Low Disk Space
| Rule ID | xccdf_org.ssgproject.content_rule_auditd_data_retention_space_left_action | ||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||
| Description | 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:
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. |
Verify that audit tools are owned by group rootxccdf_org.ssgproject.content_rule_file_groupownership_audit_binaries medium
Verify that audit tools are owned by group root
| Rule ID | xccdf_org.ssgproject.content_rule_file_groupownership_audit_binaries | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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 rootAudit 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. |
Verify that audit tools are owned by rootxccdf_org.ssgproject.content_rule_file_ownership_audit_binaries medium
Verify that audit tools are owned by root
| Rule ID | xccdf_org.ssgproject.content_rule_file_ownership_audit_binaries | ||||
| Result | notapplicable | ||||
| Multi-check rule | no | ||||
| Time | 2026-03-29T19:53:37+00:00 | ||||
| Severity | medium | ||||
| References: |
| ||||
| Description | 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 rootAudit 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. |
Ensure the audit Subsystem is Installedxccdf_org.ssgproject.content_rule_package_audit_installed medium
Ensure the audit Subsystem is Installed
| Rule ID | xccdf_org.ssgproject.content_rule_package_audit_installed | ||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||
| References: |
| ||||||||||||||||||||
| Description | 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. |
Enable auditd Servicexccdf_org.ssgproject.content_rule_service_auditd_enabled medium
Enable auditd Service
| Rule ID | xccdf_org.ssgproject.content_rule_service_auditd_enabled | ||||||||||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||||||||||
| Severity | medium | ||||||||||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||||||||||
| Description | 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. |
Enable Auditing for Processes Which Start Prior to the Audit Daemonxccdf_org.ssgproject.content_rule_grub2_audit_argument low
Enable Auditing for Processes Which Start Prior to the Audit Daemon
| Rule ID | xccdf_org.ssgproject.content_rule_grub2_audit_argument | ||||||||||||||||||||||||||||||
| Result | notapplicable | ||||||||||||||||||||||||||||||
| Multi-check rule | no | ||||||||||||||||||||||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||||||||||||||||||||||
| Severity | low | ||||||||||||||||||||||||||||||
| References: |
| ||||||||||||||||||||||||||||||
| Description | 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. |
Extend Audit Backlog Limit for the Audit Daemonxccdf_org.ssgproject.content_rule_grub2_audit_backlog_limit_argument low
Extend Audit Backlog Limit for the Audit Daemon
| Rule ID | xccdf_org.ssgproject.content_rule_grub2_audit_backlog_limit_argument | ||||||||||
| Result | notapplicable | ||||||||||
| Multi-check rule | no | ||||||||||
| Time | 2026-03-29T19:53:37+00:00 | ||||||||||
| Severity | low | ||||||||||
| References: |
| ||||||||||
| Description | 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. |
Red Hat and Red Hat Enterprise Linux are either registered
trademarks or trademarks of Red Hat, Inc. in the United States and other
countries. All other names are registered trademarks or trademarks of their
respective companies.