| Group
Guide to the Secure Configuration of openEuler 22.03 LTS
Group contains 99 groups and 240 rules |
| Group
System Settings
Group contains 62 groups and 191 rules |
[ref]
Contains rules that check correct system settings. |
| Group
SELinux
Group contains 3 rules |
[ref]
SELinux is a feature of the Linux kernel which can be
used to guard against misconfigured or compromised programs.
SELinux enforces the idea that programs should be limited in what
files they can access and what actions they can take.
The default SELinux policy, as configured on openEuler 22.03 LTS, has been
sufficiently developed and debugged that it should be usable on
almost any system with minimal configuration and a small
amount of system administrator training. This policy prevents
system services - including most of the common network-visible
services such as mail servers, FTP servers, and DNS servers - from
accessing files which those services have no valid reason to
access. This action alone prevents a huge amount of possible damage
from network attacks against services, from trojaned software, and
so forth.
This guide recommends that SELinux be enabled using the
default (targeted) policy on every openEuler 22.03 LTS system, unless that
system has unusual requirements which make a stronger policy
appropriate. |
Rule
Configure SELinux Policy
[ref] | The SELinux targeted policy is appropriate for
general-purpose desktops and servers, as well as systems in many other roles.
To configure the system to use this policy, add or correct the following line
in /etc/selinux/config:
SELINUXTYPE=targeted
Other policies, such as mls, provide additional security labeling
and greater confinement but are not compatible with many general-purpose
use cases. | | Rationale: | Setting the SELinux policy to targeted or a more specialized policy
ensures the system will confine processes that are likely to be
targeted for exploitation, such as network or system services.
Note: During the development or debugging of SELinux modules, it is common to
temporarily place non-production systems in permissive mode. In such
temporary cases, SELinux policies should be developed, and once work
is completed, the system should be reconfigured to
targeted. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_selinux_policytype | | Identifiers and References | References:
NT28(R66), 1.6.1.3, 3.1.2, 3.7.2, CCI-002696, 164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e), AC-3, AC-3(3)(a), AU-9, SC-7(21), DE.AE-1, ID.AM-3, PR.AC-4, PR.AC-5, PR.AC-6, PR.DS-5, PR.PT-1, PR.PT-3, PR.PT-4, SRG-OS-000445-GPOS-00199, SRG-OS-000445-VMM-001780, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, 4.2.3.4, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, 4.4.3.3, APO01.06, APO11.04, APO13.01, BAI03.05, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.03, DSS06.06, MEA02.01, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 3, 4, 5, 6, 8, 9 | |
|
Rule
Ensure SELinux State is Enforcing
[ref] | The SELinux state should be set to enforcing at
system boot time. In the file /etc/selinux/config, add or correct the
following line to configure the system to boot into enforcing mode:
SELINUX=enforcing | | Rationale: | Setting the SELinux state to enforcing ensures SELinux is able to confine
potentially compromised processes to the security policy, which is designed to
prevent them from causing damage to the system or further elevating their
privileges. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_selinux_state | | Identifiers and References | References:
1.6.1.2, 3.1.2, 3.7.2, CCI-002165, CCI-002696, 164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e), AC-3, AC-3(3)(a), AU-9, SC-7(21), DE.AE-1, ID.AM-3, PR.AC-4, PR.AC-5, PR.AC-6, PR.DS-5, PR.PT-1, PR.PT-3, PR.PT-4, SRG-OS-000445-GPOS-00199, SRG-OS-000445-VMM-001780, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, 4.2.3.4, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, 4.4.3.3, APO01.06, APO11.04, APO13.01, BAI03.05, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.03, DSS06.06, MEA02.01, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 3, 4, 5, 6, 8, 9, NT28(R4) | |
|
Rule
Avoid using programms labeled unconfined_service_t
[ref] | The purpose of SELinux setting the unconfined_service_t label
is to enable some third-party service processes that are not
configured with SELinux policies to run unfettered. By default,
when systemd runs a third-party application with the label bin_t
or usr_t (generally located in /usr/bin, /opt, etc. directories),
the generated process label is unconfined_service_t.
The difference from other high-privilege labels (such as unconfined_t,
initrc_t, etc.) is that unconfined_service_t has very few domain
conversion rules, which means that even if the process runs applications
that have been configured with SELinux policies, the label of the
new process will still be unconfined_service_t. The SELinux policy
configured for the process will not take effect. If it is attacked,
it will have a greater impact on the system.
It can not be scanned automatically, please check it manually.
| | Rationale: | Programs labeled unconfined_service_t are restricted from running. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_disabled_unconfined_service_t_programs | | Identifiers and References | | |
|
| Group
Account and Access Control
Group contains 13 groups and 35 rules |
[ref]
In traditional Unix security, if an attacker gains
shell access to a certain login account, they can perform any action
or access any file to which that account has access. Therefore,
making it more difficult for unauthorized people to gain shell
access to accounts, particularly to privileged accounts, is a
necessary part of securing a system. This section introduces
mechanisms for restricting access to accounts under
openEuler 22.03 LTS. |
| Group
Protect Accounts by Restricting Password-Based Login
Group contains 4 groups and 15 rules |
[ref]
Conventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the /etc/passwd and
/etc/shadow files. Password-based login is vulnerable to
guessing of weak passwords, and to sniffing and man-in-the-middle
attacks against passwords entered over a network or at an insecure
console. Therefore, mechanisms for accessing accounts by entering
usernames and passwords should be restricted to those which are
operationally necessary. |
| Group
Set Password Expiration Parameters
Group contains 3 rules |
[ref]
The file /etc/login.defs controls several
password-related settings. Programs such as passwd,
su, and
login consult /etc/login.defs to determine
behavior with regard to password aging, expiration warnings,
and length. See the man page login.defs(5) for more information.
Users should be forced to change their passwords, in order to
decrease the utility of compromised passwords. However, the need to
change passwords often should be balanced against the risk that
users will reuse or write down passwords if forced to change them
too often. Forcing password changes every 90-360 days, depending on
the environment, is recommended. Set the appropriate value as
PASS_MAX_DAYS and apply it to existing accounts with the
-M flag.
The PASS_MIN_DAYS ( -m) setting prevents password
changes for 7 days after the first change, to discourage password
cycling. If you use this setting, train users to contact an administrator
for an emergency password change in case a new password becomes
compromised. The PASS_WARN_AGE ( -W) setting gives
users 7 days of warnings at login time that their passwords are about to expire.
For example, for each existing human user USER, expiration parameters
could be adjusted to a 180 day maximum password age, 7 day minimum password
age, and 7 day warning period with the following command:
$ sudo chage -M 180 -m 7 -W 7 USER |
Rule
Set Password Maximum Age
[ref] | To specify password maximum age for new accounts,
edit the file /etc/login.defs
and add or correct the following line:
PASS_MAX_DAYS 90
A value of 180 days is sufficient for many environments.
The DoD requirement is 60.
The profile requirement is 90.
Considering the usability of the community release of openEuler in different scenarios,
the password expiration time is not configured in the openEuler release by default.
Please set the password expiration time based on the site requirements. | | Rationale: | Any password, no matter how complex, can eventually be cracked. Therefore, passwords
need to be changed periodically. If the operating system does not limit the lifetime
of passwords and force users to change their passwords, there is the risk that the
operating system passwords could be compromised.
Setting the password maximum age ensures users are required to
periodically change their passwords. Requiring shorter password lifetimes
increases the risk of users writing down the password in a convenient
location subject to physical compromise. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_maximum_age_login_defs | | Identifiers and References | References:
5.4.1.1, 5.6.2.1, 3.5.6, CCI-000199, IA-5(f), IA-5(1)(d), CM-6(a), PR.AC-1, PR.AC-6, PR.AC-7, Req-8.2.4, SRG-OS-000076-GPOS-00044, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16, 5 | |
|
Rule
Set Password Minimum Age
[ref] | To specify password minimum age for new accounts,
edit the file /etc/login.defs
and add or correct the following line:
PASS_MIN_DAYS 0
A value of 1 day is considered sufficient for many
environments. The DoD requirement is 1.
The profile requirement is 0. | | Rationale: | Enforcing a minimum password lifetime helps to prevent repeated password
changes to defeat the password reuse or history enforcement requirement. If
users are allowed to immediately and continually change their password,
then the password could be repeatedly changed in a short period of time to
defeat the organization's policy regarding password reuse.
Setting the minimum password age protects against users cycling back to a
favorite password after satisfying the password reuse requirement. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_minimum_age_login_defs | | Identifiers and References | References:
5.6.2.1.1, 3.5.8, CCI-000198, IA-5(f), IA-5(1)(d), CM-6(a), PR.AC-1, PR.AC-6, PR.AC-7, SRG-OS-000075-GPOS-00043, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16, 5 | |
|
Rule
Set Password Warning Age
[ref] | To specify how many days prior to password
expiration that a warning will be issued to users,
edit the file /etc/login.defs and add or correct
the following line:
PASS_WARN_AGE 7
The DoD requirement is 7.
The profile requirement is 7. | | Rationale: | Setting the password warning age enables users to
make the change at a practical time. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_warn_age_login_defs | | Identifiers and References | References:
3.5.8, IA-5(f), IA-5(1)(d), CM-6(a), DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 6.2, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, A.12.4.1, A.12.4.3, A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, 1, 12, 13, 14, 15, 16, 18, 3, 5, 7, 8 | |
|
| Group
Restrict Root Logins
Group contains 1 rule |
[ref]
Direct root logins should be allowed only for emergency use.
In normal situations, the administrator should access the system
via a unique unprivileged account, and then use su or sudo to execute
privileged commands. Discouraging administrators from accessing the
root account directly ensures an audit trail in organizations with
multiple administrators. Locking down the channels through which
root can connect directly also reduces opportunities for
password-guessing against the root account. The login program
uses the file /etc/securetty to determine which interfaces
should allow root logins.
The virtual devices /dev/console
and /dev/tty* represent the system consoles (accessible via
the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default
installation). The default securetty file also contains /dev/vc/*.
These are likely to be deprecated in most environments, but may be retained
for compatibility. Root should also be prohibited from connecting
via network protocols. Other sections of this document
include guidance describing how to prevent root from logging in via SSH. |
Rule
Verify Only Root Has UID 0
[ref] | If any account other than root has a UID of 0, this misconfiguration should
be investigated and the accounts other than root should be removed or have
their UID changed.
If the account is associated with system commands or applications the UID
should be changed to one greater than "0" but less than "1000."
Otherwise assign a UID greater than "1000" that has not already been
assigned. | | Rationale: | An account has root authority if it has a UID of 0. Multiple accounts
with a UID of 0 afford more opportunity for potential intruders to
guess a password for a privileged account. Proper configuration of
sudo is recommended to afford multiple system administrators
access to root privileges in an accountable manner. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_no_uid_except_zero | | Identifiers and References | References:
6.2.5, 3.1.1, 3.1.5, CCI-000366, IA-2, AC-6(5), IA-4(b), PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.DS-5, SRG-OS-000480-GPOS-00227, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 5.2, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, APO01.06, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.02, DSS06.03, DSS06.10, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.18.1.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, 1, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
| Group
Verify Proper Storage and Existence of Password
Hashes
Group contains 3 rules |
[ref]
By default, password hashes for local accounts are stored
in the second field (colon-separated) in
/etc/shadow. This file should be readable only by
processes running with root credentials, preventing users from
casually accessing others' password hashes and attempting
to crack them.
However, it remains possible to misconfigure the system
and store password hashes
in world-readable files such as /etc/passwd, or
to even store passwords themselves in plaintext on the system.
Using system-provided tools for password change/creation
should allow administrators to avoid such misconfiguration. |
Rule
All GIDs referenced in /etc/passwd must be defined in /etc/group
[ref] | Add a group to the system for each GID referenced without a corresponding group. | | Rationale: | If a user is assigned the Group Identifier (GID) of a group not existing on the system, and a group
with the Gruop Identifier (GID) is subsequently created, the user may have unintended rights to
any files associated with the group. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_gid_passwd_group_same | | Identifiers and References | References:
5.5.2, CCI-000764, IA-2, CM-6(a), PR.AC-1, PR.AC-6, PR.AC-7, Req-8.5.a, SRG-OS-000104-GPOS-00051, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16, 5 | |
|
Rule
Verify No netrc Files Exist
[ref] | The .netrc files contain login information
used to auto-login into FTP servers and reside in the user's home
directory. These files may contain unencrypted passwords to
remote FTP servers making them susceptible to access by unauthorized
users and should not be used. Any .netrc files should be removed. | | Rationale: | Unencrypted passwords for remote FTP servers may be stored in .netrc
files. DoD policy requires passwords be encrypted in storage and not used
in access scripts. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_no_netrc_files | | Identifiers and References | References:
CCI-000196, IA-5(h), IA-5(1)(c), CM-6(a), IA-5(7), PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.PT-3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.06, DSS06.10, A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, 1, 11, 12, 14, 15, 16, 18, 3, 5 | |
|
Rule
Verify No forward Files Exist
[ref] | The .forward file can be configured with an email address, which
will be automatically forwarded to when users receive emails. If there are
no related email forwarding scenarios, it is recommended to delete the
.forward file.
Use the following script to check:
| | Rationale: | If there is a .forward file, it may cause user emails carrying
sensitive information to be automatically forwarded to high-risk mailboxes. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_no_forward_files | | Identifiers and References | | |
|
| Group
Set Account Expiration Parameters
Group contains 2 rules |
[ref]
Accounts can be configured to be automatically disabled
after a certain time period,
meaning that they will require administrator interaction to become usable again.
Expiration of accounts after inactivity can be set for all accounts by default
and also on a per-account basis, such as for accounts that are known to be temporary.
To configure automatic expiration of an account following
the expiration of its password (that is, after the password has expired and not been changed),
run the following command, substituting NUM_DAYS and USER appropriately:
$ sudo chage -I NUM_DAYS USER
Accounts, such as temporary accounts, can also be configured to expire on an explicitly-set date with the
-E option.
The file /etc/default/useradd controls
default settings for all newly-created accounts created with the system's
normal command line utilities. Warning:
This will only apply to newly created accounts |
Rule
Ensure All Accounts on the System Have Unique Names
[ref] | Change usernames, or delete accounts, so each has a unique name. | | Rationale: | Unique usernames allow for accountability on the system. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_account_unique_name | | Identifiers and References | References:
5.5.2, CCI-000770, CCI-000804, Req-8.1.1 | |
|
Rule
Assign Expiration Date to Temporary Accounts
[ref] | Temporary accounts are established as part of normal account activation
procedures when there is a need for short-term accounts. In the event
temporary or emergency accounts are required, configure the system to
terminate them after a documented time period. For every temporary and
emergency account, run the following command to set an expiration date on
it, substituting USER and YYYY-MM-DD
appropriately:
$ sudo chage -E YYYY-MM-DD USER
YYYY-MM-DD indicates the documented expiration date for the
account. For U.S. Government systems, the operating system must be
configured to automatically terminate these types of accounts after a
period of 72 hours. | | Rationale: | If temporary user accounts remain active when no longer needed or for
an excessive period, these accounts may be used to gain unauthorized access.
To mitigate this risk, automated termination of all temporary accounts
must be set upon account creation.
| | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_account_temp_expire_date | | Identifiers and References | References:
CCI-000016, CCI-001682, AC-2(2), AC-2(3), CM-6(a), DE.CM-1, DE.CM-3, PR.AC-1, PR.AC-4, PR.AC-6, SRG-OS-000123-GPOS-00064, SRG-OS-000002-GPOS-00002, SRG-OS-000002-VMM-000020, SRG-OS-000123-VMM-000620, SR 1.1, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 6.2, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, DSS01.03, DSS03.05, DSS05.04, DSS05.05, DSS05.07, DSS06.03, A.12.4.1, A.12.4.3, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, 1, 12, 13, 14, 15, 16, 18, 3, 5, 7, 8 | |
|
Rule
Ensure All Groups on the System Have Unique Group Names
[ref] | Change the group name or delete groups, so each has a unique name. | | Rationale: | To assure accountability and prevent unauthenticated access, groups must be identified uniquely to prevent potential misuse and compromise of the system. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_group_unique_name | | Identifiers and References | | |
|
Rule
Ensure All Accounts on the System Have Unique User IDs
[ref] | Change user IDs (UIDs), or delete accounts, so each has a unique id. | | Rationale: | To assure accountability and prevent unauthenticated access, interactive users must be identified and authenticated to prevent potential misuse and compromise of the system. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_account_unique_id | | Identifiers and References | | |
|
Rule
All Accounts Are Necessary
[ref] |
It can not be scanned automatically, please check it manually.
If any account is not necessary, it should be removed from /etc/passwd.
| | Rationale: | It is a risk if an account exists in system but it is not necessary. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_are_necessary | | Identifiers and References | | |
|
Rule
Ensure All Accounts on the System Have Unique Master Group IDs
[ref] | Change user master group IDs, or delete accounts. | | Rationale: | To assure accountability and prevent unauthenticated access, interactive users must be identified and authenticated to prevent potential misuse and compromise of the system. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_account_unique_group_id | | Identifiers and References | | |
|
Rule
Ensure All Groups on the System Have Unique Group ID
[ref] | Change the group name or delete groups, so each has a unique id. | | Rationale: | To assure accountability and prevent unauthenticated access, groups must be identified uniquely to prevent potential misuse and compromise of the system. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_group_unique_id | | Identifiers and References | | |
|
Rule
All Login Accounts Are Necessary
[ref] | It can not be scanned automatically, please check it manually.
If any account need not login, it should be removed from /etc/passwd
or it should be marked by "nologin".
It can be checked as below cli commands:
- List all nologin accounts, then check it manually:
# cat /etc/passwd | grep "\/sbin\/nologin\|\/bin\/false" | awk -F ":" '{print $1}'
- List all login accounts, then check it manually:
# cat /etc/passwd | grep -v "\/sbin\/nologin\|\/bin\/false" | awk -F ":" '{print $1}'
- List all accounts which the password are locked:
# cat /etc/passwd | awk -F ":" '{print $1}' | xargs -I '{}' passwd -S '{}' | awk '($2=="L" || $2=="LK") {print $1}'
- List all accounts which the password are not locked:
# cat /etc/passwd | awk -F ":" '{print $1}' | xargs -I '{}' passwd -S '{}' | awk '($2!="L" && $2!="LK") {print $1}'
| | Rationale: | It is a risk if an account can login system but it is not necessary. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_login_accounts_are_necessary | | Identifiers and References | | |
|
| Group
Protect Physical Console Access
Group contains 2 rules |
[ref]
It is impossible to fully protect a system from an
attacker with physical access, so securing the space in which the
system is located should be considered a necessary step. However,
there are some steps which, if taken, make it more difficult for an
attacker to quickly or undetectably modify a system from its
console. |
Rule
Disable debug-shell SystemD Service
[ref] | SystemD's debug-shell service is intended to
diagnose SystemD related boot issues with various systemctl
commands. Once enabled and following a system reboot, the root shell
will be available on tty9 which is access by pressing
CTRL-ALT-F9. The debug-shell service should only be used
for SystemD related issues and should otherwise be disabled.
By default, the debug-shell SystemD service is already disabled.
The debug-shell service can be disabled with the following command:
$ sudo systemctl disable debug-shell.service
The debug-shell service can be masked with the following command:
$ sudo systemctl mask debug-shell.service | | Rationale: | This prevents attackers with physical access from trivially bypassing security
on the machine through valid troubleshooting configurations and gaining root
access when the system is rebooted. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_service_debug-shell_disabled | | Identifiers and References | References:
3.4.5, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), FIA_AFL.1, SRG-OS-000324-GPOS-00125 | |
|
Rule
Require Authentication for Single User Mode
[ref] | Single-user mode is intended as a system recovery
method, providing a single user root access to the system by
providing a boot option at startup. By default, no authentication
is performed if single-user mode is selected.
By default, single-user mode is protected by requiring a password and is set
in /usr/lib/systemd/system/rescue.service. | | Rationale: | This prevents attackers with physical access from trivially bypassing security
on the machine and gaining root access. Such accesses are further prevented
by configuring the bootloader password. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_require_singleuser_auth | | Identifiers and References | References:
3.1.1, 3.4.5, CCI-000213, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), IA-2, AC-3, CM-6(a), PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.PT-3, FIA_AFL.1, SRG-OS-000080-GPOS-00048, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.06, DSS06.10, A.18.1.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, 1, 11, 12, 14, 15, 16, 18, 3, 5 | |
|
| Group
Protect Accounts by Configuring PAM
Group contains 4 groups and 15 rules |
[ref]
PAM, or Pluggable Authentication Modules, is a system
which implements modular authentication for Linux programs. PAM provides
a flexible and configurable architecture for authentication, and it should be configured
to minimize exposure to unnecessary risk. This section contains
guidance on how to accomplish that.
PAM is implemented as a set of shared objects which are
loaded and invoked whenever an application wishes to authenticate a
user. Typically, the application must be running as root in order
to take advantage of PAM, because PAM's modules often need to be able
to access sensitive stores of account information, such as /etc/shadow.
Traditional privileged network listeners
(e.g. sshd) or SUID programs (e.g. sudo) already meet this
requirement. An SUID root application, userhelper, is provided so
that programs which are not SUID or privileged themselves can still
take advantage of PAM.
PAM looks in the directory /etc/pam.d for
application-specific configuration information. For instance, if
the program login attempts to authenticate a user, then PAM's
libraries follow the instructions in the file /etc/pam.d/login
to determine what actions should be taken.
One very important file in /etc/pam.d is
/etc/pam.d/system-auth. This file, which is included by
many other PAM configuration files, defines 'default' system authentication
measures. Modifying this file is a good way to make far-reaching
authentication changes, for instance when implementing a
centralized authentication service. Warning:
Be careful when making changes to PAM's configuration files.
The syntax for these files is complex, and modifications can
have unexpected consequences. The default configurations shipped
with applications should be sufficient for most users. |
| Group
Set Password Hashing Algorithm
Group contains 1 rule |
[ref]
The system's default algorithm for storing password hashes in
/etc/shadow is SHA-512. This can be configured in several
locations. |
Rule
Set PAM's Password Hashing Algorithm
[ref] | The PAM system service can be configured to only store encrypted
representations of passwords. In /etc/pam.d/system-auth, the
password section of the file controls which PAM modules execute
during a password change. Set the pam_unix.so module in the
password section to include the argument sha512, as shown
below:
password sufficient pam_unix.so sha512 other arguments...
This will help ensure when local users change their passwords, hashes for
the new passwords will be generated using the SHA-512 algorithm. This is
the default. | | 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
kepy 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 ensures the use
of a strong hashing algorithm that makes password cracking attacks more
difficult. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_set_password_hashing_algorithm_systemauth | | Identifiers and References | References:
6.3.1, 5.6.2.2, 3.13.11, CCI-000196, IA-5(c), IA-5(1)(c), CM-6(a), PR.AC-1, PR.AC-6, PR.AC-7, Req-8.2.1, SRG-OS-000073-GPOS-00041, SRG-OS-000480-VMM-002000, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16, 5 | |
|
| Group
Set Password Quality Requirements
Group contains 1 group and 8 rules |
[ref]
The default pam_pwquality PAM module provides strength
checking for passwords. It performs a number of checks, such as
making sure passwords are not similar to dictionary words, are of
at least a certain length, are not the previous password reversed,
and are not simply a change of case from the previous password. It
can also require passwords to be in certain character classes. The
pam_pwquality module is the preferred way of configuring
password requirements.
The pam_cracklib PAM module can also provide strength
checking for passwords as the pam_pwquality module.
It performs a number of checks, such as making sure passwords are
not similar to dictionary words, are of at least a certain length,
are not the previous password reversed, and are not simply a change
of case from the previous password. It can also require passwords to
be in certain character classes.
The man pages pam_pwquality(8) and pam_cracklib(8)
provide information on the capabilities and configuration of
each. |
| Group
Set Password Quality Requirements with pam_pwquality
Group contains 8 rules |
[ref]
The pam_pwquality PAM module can be configured to meet
requirements for a variety of policies.
For example, to configure pam_pwquality to require at least one uppercase
character, lowercase character, digit, and other (special)
character, make sure that pam_pwquality exists in /etc/pam.d/system-auth:
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth.
Next, modify the settings in /etc/security/pwquality.conf to match the following:
difok = 4
minlen = 14
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
maxrepeat = 3
The arguments can be modified to ensure compliance with
your organization's security policy. Discussion of each parameter follows. |
Rule
Ensure PAM Enforces Password Requirements - Minimum Different Categories
[ref] | The pam_pwquality module's minclass parameter controls
requirements for usage of different character classes, or types, of character
that must exist in a password before it is considered valid. For example,
setting this value to three (3) requires that any password must have characters
from at least three different categories in order to be approved. The default
value is zero (0), meaning there are no required classes. There are four
categories available:
* Upper-case characters
* Lower-case characters
* Digits
* Special characters (for example, punctuation)
Modify the minclass setting in /etc/security/pwquality.conf entry
to require 3
differing categories of characters when changing passwords. | | Rationale: | Use of a complex password helps to increase the time and resources required to compromise the password.
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts
at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The
more complex the password, the greater the number of possible combinations that need to be tested before
the password is compromised.
Requiring a minimum number of character categories makes password guessing attacks more difficult
by ensuring a larger search space. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_minclass | | Identifiers and References | References:
CCI-000195, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, SRG-OS-000072-GPOS-00040, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16, 5 | |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Length
[ref] | The pam_pwquality module's minlen parameter controls requirements for
minimum characters required in a password. Add minlen=8
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
compromose the password. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_minlen | | Identifiers and References | References:
6.3.2, 5.6.2.1.1, CCI-000205, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, FMT_MOF_EXT.1, Req-8.2.3, SRG-OS-000078-GPOS-00046, SRG-OS-000072-VMM-000390, SRG-OS-000078-VMM-000450, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16, 5 | |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Digit Characters
[ref] | The pam_pwquality module's dcredit parameter controls requirements for
usage of digits in a password. When set to a negative number, any password will be required to
contain that many digits. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each digit. Modify the dcredit setting in
/etc/security/pwquality.conf to require the use of a digit in passwords. | | Rationale: | Use of a complex password helps to increase the time and resources required
to compromise the password. Password complexity, or strength, is a measure of
the effectiveness of a password in resisting attempts at guessing and brute-force
attacks.
Password complexity is one factor of several that determines how long it takes
to crack a password. The more complex the password, the greater the number of
possible combinations that need to be tested before the password is compromised.
Requiring digits makes password guessing attacks more difficult by ensuring a larger
search space. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_dcredit | | Identifiers and References | References:
6.3.2, CCI-000194, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, FMT_MOF_EXT.1, Req-8.2.3, SRG-OS-000071-GPOS-00039, SRG-OS-000071-VMM-000380, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16, 5 | |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Uppercase Characters
[ref] | The pam_pwquality module's ucredit= parameter controls requirements for
usage of uppercase letters in a password. When set to a negative number, any password will be required to
contain that many uppercase characters. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each uppercase character. Modify the ucredit setting in
/etc/security/pwquality.conf to require the use of an uppercase character in passwords. | | Rationale: | Use of a complex password helps to increase the time and resources reuiqred to compromise the password.
Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts
at guessing and brute-force attacks.
Password complexity is one factor of several that determines how long it takes to crack a password. The more
complex the password, the greater the number of possible combinations that need to be tested before
the password is compromised. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_ucredit | | Identifiers and References | References:
6.3.2, CCI-000192, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, FMT_MOF_EXT.1, Req-8.2.3, SRG-OS-000069-GPOS-00037, SRG-OS-000069-VMM-000360, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16, 5 | |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Special Characters
[ref] | The pam_pwquality module's ocredit= parameter controls requirements for
usage of special (or "other") characters in a password. When set to a negative number,
any password will be required to contain that many special characters.
When set to a positive number, pam_pwquality will grant +1
additional length credit for each special character. Modify the ocredit setting
in /etc/security/pwquality.conf to equal 0
to require use of a special character in passwords. | | Rationale: | Use of a complex password helps to increase the time and resources required
to compromise the password. Password complexity, or strength, is a measure of
the effectiveness of a password in resisting attempts at guessing and brute-force
attacks.
Password complexity is one factor of several that determines how long it takes
to crack a password. The more complex the password, the greater the number of
possble combinations that need to be tested before the password is compromised.
Requiring a minimum number of special characters makes password guessing attacks
more difficult by ensuring a larger search space. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_ocredit | | Identifiers and References | References:
CCI-001619, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, FMT_MOF_EXT.1, SRG-OS-000266-GPOS-00101, SRG-OS-000266-VMM-000940, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16, 5 | |
|
Rule
Ensure PAM Enforces Password Requirements - Prevent the Use of Dictionary Words
[ref] | The pam_pwquality module's dictcheck check if passwords contains dictionary words. When
dictcheck is set to 1 passwords will be checked for dictionary words.
Considering the usability of the community release of openEuler in different scenarios,
the weak password dictionary check is not configured for the openEuler release by default.
Please configure the weak password dictionary check based on the site requirements. | | 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.
Passwords with dictionary words may be more vulnerable to password-guessing attacks. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_dictcheck | | Identifiers and References | | |
|
Rule
Ensure PAM Enforces Password Requirements - Minimum Lowercase Characters
[ref] | The pam_pwquality module's lcredit parameter controls requirements for
usage of lowercase letters in a password. When set to a negative number, any password will be required to
contain that many lowercase characters. When set to a positive number, pam_pwquality will grant +1 additional
length credit for each lowercase character. Modify the lcredit setting in
/etc/security/pwquality.conf to require the use of a lowercase character in passwords. | | Rationale: | Use of a complex password helps to increase the time and resources required
to compromise the password. Password complexity, or strength, is a measure of
the effectiveness of a password in resisting attempts at guessing and brute-force
attacks.
Password complexity is one factor of several that determines how long it takes
to crack a password. The more complex the password, the greater the number of
possble combinations that need to be tested before the password is compromised.
Requiring a minimum number of lowercase characters makes password guessing attacks
more difficult by ensuring a larger search space. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_lcredit | | Identifiers and References | References:
CCI-000193, IA-5(c), IA-5(1)(a), CM-6(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, FMT_MOF_EXT.1, Req-8.2.3, SRG-OS-000070-GPOS-00038, SRG-OS-000070-VMM-000370, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16, 5 | |
|
Rule
Ensure PAM Enforces Password Requirements - Authentication Retry Prompts Permitted Per-Session
[ref] | To configure the number of retry prompts that are permitted per-session:
Edit the pam_pwquality.so statement in /etc/pam.d/system-auth to
show retry=3, or a lower value if
site policy is more restrictive.
The DoD requirement is a maximum of 3 prompts per session.
Considering the usability of the community release of openEuler in different scenarios,
the values of retry are not configured in the openEuler release by default.
Please set it based on the site requirements. | | Rationale: | Setting the password retry prompts that are permitted on a per-session basis to a low value
requires some software, such as SSH, to re-connect. This can slow down and
draw additional attention to some types of password-guessing attacks. Note that this
is different from account lockout, which is provided by the pam_faillock module. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_retry | | Identifiers and References | References:
6.3.2, 5.5.3, CCI-000366, CM-6(a), AC-7(a), IA-5(4), PR.AC-1, PR.AC-6, PR.AC-7, PR.IP-1, FMT_MOF_EXT.1, SRG-OS-000480-GPOS-00225, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 7.6, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, 1, 11, 12, 15, 16, 3, 5, 9 | |
|
| Group
Set Lockouts for Failed Password Attempts
Group contains 4 rules |
[ref]
The pam_faillock PAM module provides the capability to
lock out user accounts after a number of failed login attempts. Its
documentation is available in
/usr/share/doc/pam-VERSION/txts/README.pam_faillock.
Warning:
Locking out user accounts presents the
risk of a denial-of-service attack. The lockout policy
must weigh whether the risk of such a
denial-of-service attack outweighs the benefits of thwarting
password guessing attacks. |
Rule
Set Lockout Time for Failed Password Attempts
[ref] | To configure the system to lock out accounts after a number of incorrect login
attempts and require an administrator to unlock the account using pam_faillock.so,
modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:
- add the following line immediately
before the pam_unix.so statement in the AUTH section:
auth required pam_faillock.so preauth silent deny=3 unlock_time=300 fail_interval=900 - add the following line immediately
after the pam_unix.so statement in the AUTH section:
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=300 fail_interval=900 - add the following line immediately
before the pam_unix.so statement in the ACCOUNT section:
account required pam_faillock.so
If unlock_time is set to 0, manual intervention by an administrator is required to unlock a user. | | Rationale: | Locking out user accounts after a number of incorrect attempts
prevents direct password guessing attacks. Ensuring that an administrator is
involved in unlocking locked accounts draws appropriate attention to such
situations. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_unlock_time | | Identifiers and References | References:
5.3.2, 5.5.3, 3.1.8, CCI-002238, CM-6(a), AC-7(b), PR.AC-7, FMT_MOF_EXT.1, Req-8.1.7, SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005, SRG-OS-000329-VMM-001180, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, DSS05.04, DSS05.10, DSS06.10, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16 | |
|
Rule
Set Deny For Failed Password Attempts
[ref] | To configure the system to lock out accounts after a number of incorrect login
attempts using pam_faillock.so, modify the content of both
/etc/pam.d/system-auth and /etc/pam.d/password-auth as follows:
- add the following line immediately
before the pam_unix.so statement in the AUTH section:
auth required pam_faillock.so preauth silent deny=3 unlock_time=300 fail_interval=900 - add the following line immediately
after the pam_unix.so statement in the AUTH section:
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=300 fail_interval=900 - add the following line immediately
before the pam_unix.so statement in the ACCOUNT section:
account required pam_faillock.so
Considering the usability of the community release of openEuler in different scenarios,
the openEuler release does not provide this security function by default.
Please configure the default number of failures and lockout duration based on
the actual application scenario and requirements. | | Rationale: | Locking out user accounts after a number of incorrect attempts
prevents direct password guessing attacks. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny | | Identifiers and References | References:
5.3.2, 5.5.3, 3.1.8, CCI-002238, CCI-000044, CM-6(a), AC-7(a), PR.AC-7, FMT_MOF_EXT.1, Req-8.1.6, SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005, SRG-OS-000021-VMM-000050, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, DSS05.04, DSS05.10, DSS06.10, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16 | |
|
Rule
Limit Password Reuse
[ref] | Do not allow users to reuse recent passwords. This can be
accomplished by using the remember option for the pam_unix
or pam_pwhistory PAM modules.
In the file /etc/pam.d/system-auth, append remember=5
to the line which refers to the pam_unix.so or pam_pwhistory.somodule, as shown below:
The DoD STIG requirement is 5 passwords.
Considering the usability of the community release of openEuler in different scenarios,
the openEuler release does not disable historical passwords by default.
Please configure historical passwords based on the site requirements. | | Rationale: | Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_password_pam_unix_remember | | Identifiers and References | References:
5.3.3, 5.6.2.1.1, 3.5.8, CCI-000200, IA-5(f), IA-5(1)(e), PR.AC-1, PR.AC-6, PR.AC-7, Req-8.2.5, SRG-OS-000077-GPOS-00045, SRG-OS-000077-VMM-000440, SR 1.1, SR 1.10, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, A.18.1.4, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16, 5 | |
|
Rule
Configure the root Account for Failed Password Attempts
[ref] | To configure the system to lock out the root account after a
number of incorrect login attempts using pam_faillock.so, modify
the content of both /etc/pam.d/system-auth and
/etc/pam.d/password-auth as follows:
| | Rationale: | By limiting the number of failed logon attempts, the risk of unauthorized system access via user password
guessing, otherwise known as brute-forcing, is reduced. Limits are imposed by locking the account. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny_root | | Identifiers and References | References:
CCI-002238, CM-6(a), AC-7(b), IA-5(c), PR.AC-7, FMT_MOF_EXT.1, SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, DSS05.04, DSS05.10, DSS06.10, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16 | |
|
Rule
Accounts Name Should Not Be Contained In Password
[ref] | Accounts name should not be contained in password.
There is no usercheck=0. | | Rationale: | If the passowrd contains substring of accounts name, it is a risk. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_no_name_contained_in_password | | Identifiers and References | | |
|
Rule
Accounts Password Should Be Verified When Changing
[ref] | Accounts password should be verified when it is modifying.
It is done by pam_unix.so. | | Rationale: | Anyone can change the password if no verifying. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_verify_owner_password | | Identifiers and References | | |
|
| Group
Secure Session Configuration Files for Login Accounts
Group contains 1 group and 3 rules |
[ref]
When a user logs into a Unix account, the system
configures the user's session by reading a number of files. Many of
these files are located in the user's home directory, and may have
weak permissions as a result of user error or misconfiguration. If
an attacker can modify or even read certain types of account
configuration information, they can often gain full access to the
affected user's account. Therefore, it is important to test and
correct configuration file permissions for interactive accounts,
particularly those of privileged users such as root or system
administrators. |
| Group
Ensure that Users Have Sensible Umask Values
Group contains 1 rule |
[ref]
The umask setting controls the default permissions
for the creation of new files.
With a default umask setting of 077, files and directories
created by users will not be readable by any other user on the
system. Users who wish to make specific files group- or
world-readable can accomplish this by using the chmod command.
Additionally, users can make all their files readable to their
group by default by setting a umask of 027 in their shell
configuration files. If default per-user groups exist (that is, if
every user has a default group whose name is the same as that
user's username and whose only member is the user), then it may
even be safe for users to select a umask of 007, making it very
easy to intentionally share files with groups of which the user is
a member.
|
Rule
Ensure the Default Bash Umask is Set Correctly
[ref] | To ensure the default umask for users of the Bash shell is set properly,
add or correct the umask setting in /etc/bashrc to read
as follows:
umask 077
After UMASK is set to 077, the default permission on the created file is 600,
and the default permission on the directory is 700.
Considering the usability of the community release of openEuler in different scenarios,
the openEuler release does not configure the UMASK by default.
Please configure the UMASK based on the site requirements. | | Rationale: | The umask value influences the permissions assigned to files when they are created.
A misconfigured umask value could result in files with excessive permissions that can be read or
written to by unauthorized users. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_umask_etc_bashrc | | Identifiers and References | References:
5.4.4, CCI-000366, AC-6(1), CM-6(a), PR.IP-2, 4.3.4.3.3, APO13.01, BAI03.01, BAI03.02, BAI03.03, A.14.1.1, A.14.2.1, A.14.2.5, A.6.1.5, 18, SRG-OS-000480-GPOS-00228 | |
|
Rule
Set Interactive Session Timeout
[ref] | Setting the TMOUT option in /etc/profile ensures that
all user sessions will terminate based on inactivity. The TMOUT
setting in /etc/profile should read as follows:
TMOUT=300
Considering the usability of the community release of openEuler in different scenarios,
the session timeout interval is not configured by default in the openEuler release.
Please configure the session timeout interval based on the site requirements. | | Rationale: | Terminating an idle session within a short time period reduces
the window of opportunity for unauthorized personnel to take control of a
management session enabled on the console or console port that has been
left unattended. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_tmout | | Identifiers and References | References:
3.1.11, CCI-001133, CCI-000361, AC-12, SC-10, AC-2(5), CM-6(a), PR.AC-7, FMT_MOF_EXT.1, SRG-OS-000163-GPOS-00072, SRG-OS-000163-VMM-000700, SRG-OS-000279-VMM-001010, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, DSS05.04, DSS05.10, DSS06.10, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16, NT28(R29) | |
|
Rule
All Interactive Users Home Directories Must Exist
[ref] | Create home directories to all interactive users that currently do not
have a home directory assigned. Use the following commands to create the user
home directory assigned in /etc/passwd:
$ sudo mkdir /home/USER | | Rationale: | If a local interactive user has a home directory defined that does not exist,
the user may be given access to the / directory as the current working directory
upon logon. This could create a Denial of Service because the user would not be
able to access their logon configuration files, and it may give them visibility
to system files they normally would not be able to access. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_accounts_user_interactive_home_directory_exists | | Identifiers and References | References:
CCI-000366, SRG-OS-000480-GPOS-00227 | |
|
| Group
Configure Syslog
Group contains 3 groups and 13 rules |
[ref]
The syslog service has been the default Unix logging mechanism for
many years. It has a number of downsides, including inconsistent log format,
lack of authentication for received messages, and lack of authentication,
encryption, or reliable transport for messages sent over a network. However,
due to its long history, syslog is a de facto standard which is supported by
almost all Unix applications.
In openEuler 22.03 LTS, rsyslog has replaced ksyslogd as the
syslog daemon of choice, and it includes some additional security features
such as reliable, connection-oriented (i.e. TCP) transmission of logs, the
option to log to database formats, and the encryption of log data en route to
a central logging server.
This section discusses how to configure rsyslog for
best effect, and how to use tools provided with the system to maintain and
monitor logs. |
| Group
Configure rsyslogd to Accept Remote Messages If Acting as a Log Server
Group contains 2 rules |
[ref]
By default, rsyslog does not listen over the network
for log messages. If needed, modules can be enabled to allow
the rsyslog daemon to receive messages from other systems and for the system
thus to act as a log server.
If the system is not a log server, then lines concerning these modules
should remain commented out.
|
Rule
Enable rsyslog to Accept Messages via TCP, if Acting As Log Server
[ref] | The rsyslog daemon should not accept remote messages
unless the system acts as a log server.
If the system needs to act as a central log server, add the following lines to
/etc/rsyslog.conf to enable reception of messages over TCP:
$ModLoad imtcp
$InputTCPServerRun 514
It can not be scanned automatically, please check it manually.
| | Rationale: | If the system needs to act as a log server, this ensures that it can receive
messages over a reliable TCP connection. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_accept_remote_messages_tcp | | Identifiers and References | References:
4.2.1.5, CM-6(a), AU-6(3), AU-6(4), SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, 1, 14, 15, 16, 3, 5, 6, PR.PT-1 | |
|
Rule
Enable rsyslog to Accept Messages via UDP, if Acting As Log Server
[ref] | The rsyslog daemon should not accept remote messages
unless the system acts as a log server.
If the system needs to act as a central log server, add the following lines to
/etc/rsyslog.conf to enable reception of messages over UDP:
$ModLoad imudp
$UDPServerRun 514
It can not be scanned automatically, please check it manually.
| | Rationale: | Many devices, such as switches, routers, and other Unix-like systems, may only support
the traditional syslog transmission over UDP. If the system must act as a log server,
this enables it to receive their messages as well. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_accept_remote_messages_udp | | Identifiers and References | References:
4.2.1.5, CM-6(a), AU-6(3), AU-6(4), SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, 1, 14, 15, 16, 3, 5, 6, PR.PT-1 | |
|
| Group
Rsyslog Logs Sent To Remote Host
Group contains 1 rule |
[ref]
If system logs are to be useful in detecting malicious
activities, it is necessary to send logs to a remote server. An
intruder who has compromised the root account on a system may
delete the log entries which indicate that the system was attacked
before they are seen by an administrator.
However, it is recommended that logs be stored on the local
host in addition to being sent to the loghost, especially if
rsyslog has been configured to use the UDP protocol to send
messages over a network. UDP does not guarantee reliable delivery,
and moderately busy sites will lose log messages occasionally,
especially in periods of high traffic which may be the result of an
attack. In addition, remote rsyslog messages are not
authenticated in any way by default, so it is easy for an attacker to
introduce spurious messages to the central log server. Also, some
problems cause loss of network connectivity, which will prevent the
sending of messages to the central server. For all of these reasons, it is
better to store log messages both centrally and on each host, so
that they can be correlated if necessary. |
Rule
Ensure Logs Sent To Remote Host
[ref] | To configure rsyslog to send logs to a remote log server,
open /etc/rsyslog.conf and read and understand the last section of the file,
which describes the multiple directives necessary to activate remote
logging.
Along with these other directives, the system can be configured
to forward its logs to a particular log server by
adding or correcting one of the following lines,
substituting logcollector appropriately.
The choice of protocol depends on the environment of the system;
although TCP and RELP provide more reliable message delivery,
they may not be supported in all environments.
To use UDP for log message delivery:
*.* @logcollector
To use TCP for log message delivery:
*.* @@logcollector
To use RELP for log message delivery:
*.* :omrelp:logcollector
There must be a resolvable DNS CNAME or Alias record set to " logcollector" for logs to be sent correctly to the centralized logging utility. | | Rationale: | A log server (loghost) receives syslog messages from one or more
systems. This data can be used as an additional log source in the event a
system is compromised and its local logs are suspect. Forwarding log messages
to a remote loghost also provides system administrators with a centralized
place to view the status of multiple hosts within the enterprise. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_remote_loghost | | Identifiers and References | References:
NT28(R7), NT28(R43), NT12(R5), 4.2.1.4, CCI-000366, CCI-001348, CCI-000136, CCI-001851, 164.308(a)(1)(ii)(D), 164.308(a)(5)(ii)(B), 164.308(a)(5)(ii)(C), 164.308(a)(6)(ii), 164.308(a)(8), 164.310(d)(2)(iii), 164.312(b), 164.314(a)(2)(i)(C), 164.314(a)(2)(iii), A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.17.2.1, CM-6(a), AU-4(1), AU-9(2), PR.DS-4, PR.PT-1, FAU_GEN.1.1.c, SRG-OS-000480-GPOS-00227, SRG-OS-000032-VMM-000130, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 7.1, SR 7.2, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO11.04, APO13.01, BAI03.05, BAI04.04, DSS05.04, DSS05.07, MEA02.01, 1, 13, 14, 15, 16, 2, 3, 5, 6 | |
|
| Group
Ensure Proper Configuration of Log Files
Group contains 2 rules |
[ref]
The file /etc/rsyslog.conf controls where log message are written.
These are controlled by lines called rules, which consist of a
selector and an action.
These rules are often customized depending on the role of the system, the
requirements of the environment, and whatever may enable
the administrator to most effectively make use of log data.
The default rules in openEuler 22.03 LTS are:
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* -/var/log/maillog
cron.* /var/log/cron
*.emerg *
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log
See the man page rsyslog.conf(5) for more information.
Note that the rsyslog daemon can be configured to use a timestamp format that
some log processing programs may not understand. If this occurs,
edit the file /etc/rsyslog.conf and add or edit the following line:
$ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat |
Rule
Ensure System Log Files Have Correct Permissions
[ref] | Log files record system operations. The log tool rsyslog can record logs
to specified files. When the specified log file does not exist in the system,
rsyslog can create a new log file. You can set the permission on new log files
in the rsyslog configuration file. You can set the default file permission to
ensure that new log files have proper and secure permissions. Run the following command to manually check whether the log permission is properly set: $ ls -l LOGFILE If the permissions are not 600 or more restrictive, run the following
command to correct this: $ sudo chmod 0600 LOGFILE " | | Rationale: | Log files can contain valuable information regarding system
configuration. If the system log files are not protected unauthorized
users could change the logged data, eliminating their forensic value. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_files_permissions_oe | | Identifiers and References | | |
|
Rule
Ensure cron Is Logging To Rsyslog
[ref] | Cron logging must be implemented to spot intrusions or trace
cron job status. If cron is not logging to rsyslog, it
can be implemented by adding the following to the RULES section of
/etc/rsyslog.conf:
cron.* /var/log/cron | | Rationale: | Cron logging can be used to trace the successful or unsuccessful execution
of cron jobs. It can also be used to spot intrusions into the use of the cron
facility by unauthorized and malicious users. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_rsyslog_cron_logging | | Identifiers and References | References:
CCI-000366, CM-6(a), ID.SC-4, PR.PT-1, FAU_GEN.1.1.c, SRG-OS-000480-GPOS-00227, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.15.2.1, A.15.2.2, 1, 14, 15, 16, 3, 5, 6 | |
|
Rule
Enable rsyslog Service
[ref] | The rsyslog service provides syslog-style logging by default on openEuler 22.03 LTS.
The rsyslog service can be enabled with the following command:
$ sudo systemctl enable rsyslog.service | | Rationale: | The rsyslog service must be running in order to provide
logging services, which are essential to system administration. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_service_rsyslog_enabled | | Identifiers and References | References:
NT28(R5), NT28(R46), 4.2.1.1, CCI-001311, CCI-001312, CCI-001557, CCI-001851, 164.312(a)(2)(ii), A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.14.2.7, A.15.2.1, A.15.2.2, A.17.2.1, CM-6(a), AU-4(1), DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.DS-4, PR.PT-1, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, SR 6.2, SR 7.1, SR 7.2, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO13.01, BAI03.05, BAI04.04, DSS01.03, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, 1, 12, 13, 14, 15, 16, 2, 3, 5, 6, 7, 8, 9 | |
|
Rule
Each service logging should be configured correctly
[ref] | Configure logging so that important system behaviors and security-related information will
be recorded using rsyslog. The configuration files /etc/rsyslog.conf and /etc/rsyslog.d/*.conf
can specify logging rules and which files will be used to record specific types of logs.
If logging is not configured, system behavior cannot be recorded, and problem location and
auditing cannot be performed when problems occur.
It can not be scanned automatically, please check it manually.
| | Rationale: | After logging is configured, if the logs are not cleared in time, the logs may fill up the current partition, causing the
risk of other processes or system failures. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_service_logging | | Identifiers and References | | |
|
Rule
Ensure that the account is forced to change the password when logging in for the first time
[ref] | Passwords that are not set by users themselves, such as passwords reset by
administrators, if not modified in a timely manner in the business environment,
can easily cause low-cost attacks. Therefore, users are required to forcibly change
their passwords when logging in to their accounts for the first time. Except for
the root password.
It can not be scanned automatically, please check it manually.
| | Rationale: | none. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_first_logging_change_password | | Identifiers and References | | |
|
Rule
Ensure that Rsyslog log rotate is configured
[ref] | rsyslog is responsible for collecting log records from the system into files, and logrotate
is responsible for regularly or quantitatively copying and compressing log files to ensure
that excessive hard disk resources are not occupied due to excessive log file size, or that
the log files are even unmaintainable.
By default, openEuler has configured the rsyslog rotate policy in the /etc/logrotate.d/rsyslog
file as follows:.
rotate log file:
/var/log/cron
/var/log/maillog
/var/log/messages
/var/log/secure
/var/log/spooler
The maximum retention period of log files is 365 days;
A maximum of 30 log files can be retained;
Log files are retained in a compressed manner;
The log file reaches 4MB, perform rotate operation.
It can not be scanned automatically, please check it manually.
| | Rationale: | If the rotate policy is not configured, the log file will continue to grow, which may
eventually lead to the exhaustion of space on the hard disk partition where the log is
located, which may affect log recording at best, or may cause the system and business to be
unable to continue to execute normally. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_rsyslog_log_rotate | | Identifiers and References | | |
|
Rule
Make sure rsyslog dump journald log is configured
[ref] |
The system uses journald to collect logs. The logs may be stored on
volatile storage devices or on persistent storage devices. If there
are problems such as log loss or logs filling up the disk, the logs
must be dumped in a timely manner to ensure that the logs are more
consistent with the system. Safety.
Check whether the relevant fields have been configured in the /etc/rsyslog.conf file:
$ grep "^kernel.sysrq" /etc/sysctl.conf /etc/sysctl.d/* | | Rationale: | If there is a volatile storage device for the log, failure to dump
the log in time may result in log loss. If there is a persistent
storage device, the amount of logs may be very large. If the logs
are not dumped in time, the logs may fill up the current partition,
causing the risk of other processes or system failures. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_dump_journald_log | | Identifiers and References | | |
|
Rule
Ensure Warning Banners contain reasonable information
[ref] | Warning Banners include warning information added to the system login
interface, which identifies the system's security warnings for all
users who log in to the system. Security warnings can include the
organization to which the system belongs, monitoring or recording of
login behaviors, and unauthorized logins based on business scenarios. Or
the legal sanctions that will be imposed upon intrusion. Inappropriate
security warning information may increase the risk of system attacks
or violate local laws and regulations.
Warning Banners should not expose the system version, application server
type, functions, etc. to users to prevent attackers from obtaining system
information and carrying out attacks. In addition to this, file ownership
needs to be configured correctly, otherwise unauthorized users may modify
files with incorrect or misleading information.
It can not be scanned automatically, please check it manually.
- You can check it by the following method:
Use the cat command to check whether the warning information in the three files /etc/motd, /etc/issue, and /etc/issue.net is reasonable, and whether there is system version, application server type, function and other information;
- or:
Use the ll command to check whether the permissions of the three files /etc/motd, /etc/issue, and /etc/issue.net are 644;
| | Rationale: | none. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_warning_banners_contain_reasonable_information | | Identifiers and References | | |
|
Rule
Prevent root users from accessing the system locally
[ref] | Root is a super-privileged user in a Linux system and has access to all
Linux system resources. If you are allowed to directly use the root account
to log in to the Linux system to operate the system, it will bring many
potential security risks. In order to avoid the risks caused by this, it
should be prohibited to directly use the root account to log in to the
operating system, and only use other technologies when necessary. Methods
(such as: sudo or su) indirectly use the root account.
Since the root account has the highest authority, logging in directly with
root has the following risks:
High-risk misoperations may directly cause server paralysis, such as accidentally
deleting or modifying key system files;
If multiple people need root privileges to operate, the root password will be
kept by multiple people, which can easily lead to password leakage and increase
password maintenance costs.
openEuler is not configured by default. If there is no need to log in locally using
the root account in actual scenarios, it is recommended to disable local login
with the root account.
The checking method is as follows:
- Check whether the account type pam_access.so module is added to the /etc/pam.d/system-auth file, and the module must be loaded before the sufficient control line:
$ cat /etc/pam.d/system-auth
- Then, check whether restrictions on root user login to tty1 are set in the /etc/security/access.conf file:
$ grep "^\-:root" /etc/security/access.conf
- Finally, use the serial port to try to log in to the root account and confirm whether the login is denied. If login is refused, the serial port prints the following information:
Authorized users only. All activities may be monitored and reported.
localhost login: root
Password:
Permission denied
| | Rationale: | The root account cannot access the system locally. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_diasable_root_accessing_system | | Identifiers and References | | |
|
Rule
Ensure that system authentication related event logs are recorded
[ref] |
Events related to system authentication must be recorded to help
analyze user logins, use of root privileges, and monitor suspicious
system actions.
|-
Check whether auth-related fields have been configured in the /etc/rsyslog.conf file:
$ grep auth /etc/rsyslog.conf | grep -v "^#" | | Rationale: | Failure to record system authentication-related event logs will
result in the inability to analyze suspicious attack actions from
the logs, such as login actions performed by attackers trying to
guess administrator passwords. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_recorded_authentication_related_event | | Identifiers and References | | |
|
| Group
Network Configuration and Firewalls
Group contains 15 groups and 41 rules |
[ref]
Most systems must be connected to a network of some
sort, and this brings with it the substantial risk of network
attack. This section discusses the security impact of decisions
about networking which must be made when configuring a system.
This section also discusses firewalls, network access
controls, and other network security frameworks, which allow
system-level rules to be written that can limit an attackers' ability
to connect to your system. These rules can specify that network
traffic should be allowed or denied from certain IP addresses,
hosts, and networks. The rules can also specify which of the
system's network services are available to particular hosts or
networks. |
| Group
Uncommon Network Protocols
Group contains 2 rules |
[ref]
The system includes support for several network protocols which are not commonly used.
Although security vulnerabilities in kernel networking code are not frequently discovered,
the consequences can be dramatic. Ensuring uncommon network protocols are disabled
reduces the system's risk to attacks targeted at its implementation of those protocols. Warning:
Although these protocols are not commonly used, avoid disruption
in your network environment by ensuring they are not needed
prior to disabling them. |
Rule
Disable SCTP Support
[ref] | The Stream Control Transmission Protocol (SCTP) is a
transport layer protocol, designed to support the idea of
message-oriented communication, with several streams of messages
within one connection.
To configure the system to prevent the sctp
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d:
install sctp /bin/true | | Rationale: | Disabling SCTP protects
the system against exploitation of any flaws in its implementation. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_sctp_disabled | | Identifiers and References | References:
3.5.2, 5.10.1, 3.4.6, CM-7(a), CM-7(b), CM-6(a), PR.IP-1, PR.PT-3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2, 11, 14, 3, 9, SRG-OS-000095-GPOS-00049 | |
|
Rule
Disable TIPC Support
[ref] | The Transparent Inter-Process Communication (TIPC) protocol
is designed to provide communications between nodes in a
cluster.
To configure the system to prevent the tipc
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d:
install tipc /bin/true Warning:
This configuration baseline was created to deploy the base operating system for general purpose
workloads. When the operating system is configured for certain purposes, such as
a node in High Performance Computing cluster, it is expected that
the tipc kernel module will be loaded. | | Rationale: | Disabling TIPC protects
the system against exploitation of any flaws in its implementation. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_tipc_disabled | | Identifiers and References | References:
CM-7(a), CM-7(b), CM-6(a), PR.IP-1, PR.PT-3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2, 11, 14, 3, 9, FMT_SMF_EXT.1, SRG-OS-000095-GPOS-00049 | |
|
| Group
nftables
Group contains 6 rules |
[ref]
nftables is a subsystem of the Linux kernel that provides filtering
and classification of network packets. nftables replaces the iptables
part of Netfilter. Compared with iptables, nftable is easier to extend
to new protocols, and nftables will replace iptables in the future.
In addition, nftables is different from firewalld and iptables. The
operating system does not configure any policies by default and
requires manual configuration by the administrator. |
Rule
Verify nftables Enabled
[ref] | The nftables service can be enabled with the following command: $ sudo systemctl enable nftables.service | | Rationale: | If multiple firewall services are enabled, business
interruption may occur due to inconsistent policy configurations. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_service_nftables_enabled | | Identifiers and References | | |
|
Rule
Configure nftables loopback policy
[ref] | The loopback address is a special address on the server, represented by 127.0.0.0/8. It
has nothing to do with the network card. It is mainly used for inter-process communication
on this machine. Packets with the source address 127.0.0.0/8 should not be received from
the network card. Such messages should be discarded.
The server needs to set a policy to allow receiving and processing the loopback address
packets of the lo interface, but reject the packets received from the network card.
It can not be scanned automatically, please check it manually.
- You can use below cli command to check whether the loopback address policy has been configured:
$ nft list ruleset
| | Rationale: | If the loopback address policy is
set incorrectly, inter-process communication on the local machine may fail, or spoofed
packets may be received from the network card. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_nftables_loopback_policy_configured_corrently | | Identifiers and References | | |
|
Rule
Configure nftables default deny policy
[ref] | From a security perspective, the nftables basic chain is similar to
iptables. (Input, output, forward) you need to configure the rejection
policy for all packets, and then add the allow policy to the basic
chain to open related services and ports.
If the basic chain is not configured, or the hook rules of the basic
chain are not specified, the packet will not be captured by nftables,
and filtering will not be possible.
It can not be scanned automatically, please check it manually.
- You can use below cli command to check whether the DROP policy of input, output and forward is configured:
$ nft list ruleset
| | Rationale: | If the basic chain is not configured with a DROP or REJECT policy, the
packets will be ACCEPT by default, which may easily lead to security
risks due to omission of the rejection policy. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_nftables_configure_default_deny_policy | | Identifiers and References | | |
|
Rule
Ensure that the nftables input and output association policies configuration is correct
[ref] | Although it is possible to configure packet policies for incoming and outgoing servers to the
input and output chains by configuring protocols, IPs, and ports, in some cases it may be more
complex. For example, if the client accesses the server through a certain port, the server may
not necessarily return the response message from the original port, and may use a random source
port. In this case, it is difficult to configure accurate policies through the sport parameter.
At this point, it is necessary to consider using association links to configure the strategy.
If an outgoing message belongs to an existing network link, it will be directly released; If a
received message belongs to an existing network link, it is also directly released. Because
these existing links must have been filtered and checked by other policies, otherwise they
cannot be established.
It can not be scanned automatically, please check it manually.
- You can use below cli command to check if the input and output chains are configured with associated policies:
$ nft list ruleset
| | Rationale: | If the policy is not configured through associated links, it is necessary to analyze all possible
link situations and configure corresponding policies. If the configuration is too loose, it may
cause security risks, and if the configuration is too strict, it may cause business interruption. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_nftables_association_policy_configured_corrently | | Identifiers and References | | |
|
Rule
Configure nftables output strategy
[ref] | There are two main situations when the server sends outbound messages. One
is when the host process actively connects to an external server, such as
http access, or sends outgoing data to a log server, etc. The other is when
the host process externally accesses local services and the local machine
responds arts.
It can not be scanned automatically, please check it manually.
| | Rationale: | If no output policy is configured, all outgoing packets from the server will
be discarded because the default policy is DROP. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_nftables_output_policy_configured_corrently | | Identifiers and References | | |
|
Rule
Configure nftables input strategy
[ref] | The function of the input chain is to filter messages received from the
outside. Any externally provided service needs to configure the
corresponding input policy and open the relevant port so that external
clients can access the service through the port.
It can not be scanned automatically, please check it manually.
| | Rationale: | If not configured, since the default policy is configured as DROP, all
external packets trying to access related services will be dropped. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_nftables_input_policy_configured_corrently | | Identifiers and References | | |
|
| Group
Kernel Parameters Which Affect Networking
Group contains 2 groups and 18 rules |
[ref]
The sysctl utility is used to set
parameters which affect the operation of the Linux kernel. Kernel parameters
which affect networking and have security implications are described here. |
| Group
Network Parameters for Hosts Only
Group contains 6 rules |
[ref]
If the system is not going to be used as a router, then setting certain
kernel parameters ensure that the host will not perform routing
of network traffic. |
Rule
Disable Kernel Parameter for TCP Timestamps
[ref] | To set the runtime status of the net.ipv4.tcp_timestamps kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.tcp_timestamps=0
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.tcp_timestamps = 0 | | Rationale: | After this function is enabled, packages with invalid addresses is recorded into kernel logs, which may cause logs overwrite. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_tcp_timestamps | | Identifiers and References | | |
|
Rule
Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfaces by Default
[ref] | To set the runtime status of the net.ipv4.conf.default.send_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.send_redirects=0
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.default.send_redirects = 0 | | Rationale: | ICMP redirect messages are used by routers to inform hosts that a more
direct route exists for a particular destination. These messages contain information
from the system's route table possibly revealing portions of the network topology.
The ability to send ICMP redirects is only appropriate for systems acting as routers. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_send_redirects | | Identifiers and References | References:
NT28(R22), 3.1.2, 5.10.1.1, 3.1.20, CCI-000366, CM-7(a), CM-7(b), SC-5CM-6(a), SC-7(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000480-GPOS-00227, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3, APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | |
|
Rule
Disable Kernel Parameter for IP Forwarding on IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.ip_forward kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.ip_forward=0
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.ip_forward = 0 Warning:
Certain technologies such as virtual machines, containers, etc. rely on IPv4 forwarding to enable and use networking.
Disabling IPv4 forwarding would cause those technologies to stop working. Therefore, this rule should not be used in
profiles or benchmarks that target usage of IPv4 forwarding. | | Rationale: | Routing protocol daemons are typically used on routers to exchange
network topology information with other routers. If this capability is used when
not required, system network information may be unnecessarily transmitted across
the network. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_ip_forward | | Identifiers and References | References:
NT28(R22), 3.1.1, 3.1.20, CCI-000366, CM-7(a), CM-7(b), SC-5CM-6(a), SC-7(a), DE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000480-GPOS-00227, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.9.1.2, 1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9 | |
|
Rule
Disable Kernel Parameter for Sending ICMP Redirects on all IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.send_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.send_redirects=0
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.send_redirects = 0 | | Rationale: | ICMP redirect messages are used by routers to inform hosts that a more
direct route exists for a particular destination. These messages contain information
from the system's route table possibly revealing portions of the network topology.
The ability to send ICMP redirects is only appropriate for systems acting as routers. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_send_redirects | | Identifiers and References | References:
NT28(R22), 3.1.2, 5.10.1.1, 3.1.20, CCI-000366, CM-7(a), CM-7(b), SC-5CM-6(a), SC-7(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000480-GPOS-00227, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3, APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | |
|
Rule
Set Kernel Parameter for TCP SYN_RECV
[ref] | To set the runtime status of the net.ipv4.tcp_max_syn_backlog kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.tcp_max_syn_backlog=256
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.tcp_max_syn_backlog = 256 | | Rationale: | Suggested value is 256.
For security purposes, you are advised to set this parameter to a large value to mitigate TCP SYN flood attacks.
However, if this parameter is set to a large value, more system resources are consumed. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_tcp_max_syn_backlog | | Identifiers and References | | |
|
Rule
Set Kernel Parameter for TCP TIME_WAIT
[ref] | To set the runtime status of the net.ipv4.tcp_fin_timeout kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.tcp_fin_timeout=60
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.tcp_fin_timeout = 60 | | Rationale: | Suggested value is 60.
If TIME_WAIT is set too long, DoS attacks may occur. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_tcp_fin_timeout | | Identifiers and References | | |
|
| Group
Network Related Kernel Runtime Parameters for Hosts and Routers
Group contains 12 rules |
[ref]
Certain kernel parameters should be set for systems which are
acting as either hosts or routers to improve the system's ability defend
against certain types of IPv4 protocol attacks. |
Rule
Enable Kernel Parameter to Ignore ICMP Broadcast Echo Requests on IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.icmp_echo_ignore_broadcasts kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.icmp_echo_ignore_broadcasts = 1 | | Rationale: | Responding to broadcast (ICMP) echoes facilitates network mapping
and provides a vector for amplification attacks.
Ignoring ICMP echo requests (pings) sent to broadcast or multicast
addresses makes the system slightly more difficult to enumerate on the network. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_icmp_echo_ignore_broadcasts | | Identifiers and References | References:
3.2.5, 5.10.1.1, 3.1.20, CCI-000366, CM-7(a), CM-7(b), SC-5, DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000480-GPOS-00227, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3, APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | |
|
Rule
Set Kernel Parameter for Ignoring All ICMP
[ref] | To set the runtime status of the net.ipv4.icmp_echo_ignore_all kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.icmp_echo_ignore_all=1
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.icmp_echo_ignore_all = 1 | | Rationale: | All ICMP packages are ignored. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_icmp_echo_ignore_all | | Identifiers and References | | |
|
Rule
Disable ARP Proxy
[ref] | ARP proxy allows the system to send a response to an ARP request on another interface on behalf of a host connected to an interface.
Disabling ARP proxy not only prevents authorized information sharing also prevents addressing information leakage between connected network segments.
Therefore, the ARP proxy must be disabled to prevent ARP packet attacks on the system. | | Rationale: | Restricted execution of programs that depend on the ARP proxy. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_disable_arp_proxy | | Identifiers and References | | |
|
Rule
Enable Kernel Paremeter to Log Martian Packets on all IPv4 Interfaces by Default
[ref] | To set the runtime status of the net.ipv4.conf.default.log_martians kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.log_martians=1
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.default.log_martians = 1 | | Rationale: | The presence of "martian" packets (which have impossible addresses)
as well as spoofed packets, source-routed packets, and redirects could be a
sign of nefarious network activity. Logging these packets enables this activity
to be detected. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_log_martians | | Identifiers and References | References:
3.2.4, 3.1.20, CCI-000126, CM-7(a), CM-7(b), SC-5(3)(a), DE.CM-1, PR.AC-3, PR.DS-4, PR.IP-1, PR.PT-3, PR.PT-4, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.04, DSS03.05, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.06, A.11.2.6, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.2.1, A.6.2.2, A.9.1.2, 1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9, SRG-OS-000480-GPOS-00227 | |
|
Rule
Enable Kernel Parameter to Use Reverse Path Filtering on all IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.rp_filter kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.rp_filter=1
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.rp_filter = 1 | | Rationale: | Enabling reverse path filtering drops packets with source addresses
that should not have been able to be received on the interface they were
received on. It should not be used on systems which are routers for
complicated networks, but is helpful for end hosts and routers serving small
networks. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_rp_filter | | Identifiers and References | References:
NT28(R22), 3.2.7, 3.1.20, CCI-001551, CM-7(a), CM-7(b), CM-6(a), SC-7(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.PT-4, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, 4.2.3.4, 4.3.3.4, 4.4.3.3, APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9, SRG-OS-000480-GPOS-00227 | |
|
Rule
Enable Kernel Parameter to Ignore Bogus ICMP Error Responses on IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.icmp_ignore_bogus_error_responses kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.icmp_ignore_bogus_error_responses = 1 | | Rationale: | Ignoring bogus ICMP error responses reduces
log size, although some activity would not be logged. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_icmp_ignore_bogus_error_responses | | Identifiers and References | References:
NT28(R22), 3.2.6, 3.1.20, CM-7(a), CM-7(b), SC-5, DE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 6.2, SR 7.1, SR 7.2, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.9.1.2, 1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9, SRG-OS-000480-GPOS-00227 | |
|
Rule
Configure Kernel Parameter for Accepting Secure Redirects By Default
[ref] | To set the runtime status of the net.ipv4.conf.default.secure_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.default.secure_redirects=0
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.default.secure_redirects = 0 | | Rationale: | Accepting "secure" ICMP redirects (from those gateways listed as
default gateways) has few legitimate uses. It should be disabled unless it is
absolutely required. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_default_secure_redirects | | Identifiers and References | References:
NT28(R22), 3.2.3, 3.1.20, CCI-001551, CM-7(a), CM-7(b), SC-5, SC-7(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3, APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9, SRG-OS-000480-GPOS-00227 | |
|
Rule
Disable Accepting ICMP Redirects for All IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.accept_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.accept_redirects=0
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.accept_redirects = 0 | | Rationale: | ICMP redirect messages are used by routers to inform hosts that a more
direct route exists for a particular destination. These messages modify the
host's route table and are unauthenticated. An illicit ICMP redirect
message could result in a man-in-the-middle attack.
This feature of the IPv4 protocol has few legitimate uses. It should be
disabled unless absolutely required." | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_accept_redirects | | Identifiers and References | References:
NT28(R22), 3.2.2, 5.10.1.1, 3.1.20, CCI-000366, CCI-001503, CCI-001551, CM-7(a), CM-7(b), CM-6(a), SC-7(a), DE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3, SRG-OS-000480-GPOS-00227, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 6.2, SR 7.1, SR 7.2, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.9.1.2, 1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9 | |
|
Rule
Disable Kernel Parameter for Accepting Secure ICMP Redirects on all IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.secure_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.secure_redirects=0
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.secure_redirects = 0 | | Rationale: | Accepting "secure" ICMP redirects (from those gateways listed as
default gateways) has few legitimate uses. It should be disabled unless it is
absolutely required. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_secure_redirects | | Identifiers and References | References:
NT28(R22), 3.2.3, 3.1.20, CCI-001503, CCI-001551, CM-7(a), CM-7(b), CM-6(a), SC-7(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3, APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9, SRG-OS-000480-GPOS-00227 | |
|
Rule
Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.accept_source_route kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.accept_source_route=0
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.accept_source_route = 0 | | Rationale: | Source-routed packets allow the source of the packet to suggest routers
forward the packet along a different path than configured on the router,
which can be used to bypass network security measures. This requirement
applies only to the forwarding of source-routerd traffic, such as when IPv4
forwarding is enabled and the system is functioning as a router.
Accepting source-routed packets in the IPv4 protocol has few legitimate
uses. It should be disabled unless it is absolutely required. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_accept_source_route | | Identifiers and References | References:
NT28(R22), 3.2.1, 3.1.20, CCI-000366, CM-7(a), CM-7(b), SC-5CM-6(a), SC-7(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000480-GPOS-00227, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3, APO01.06, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 2, 3, 4, 6, 7, 8, 9 | |
|
Rule
Enable Kernel Parameter to Use TCP Syncookies on IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.tcp_syncookies kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.tcp_syncookies=1
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.tcp_syncookies = 1 | | Rationale: | A TCP SYN flood attack can cause a denial of service by filling a
system's TCP connection table with connections in the SYN_RCVD state.
Syncookies can be used to track a connection when a subsequent ACK is received,
verifying the initiator is attempting a valid connection and is not a flood
source. This feature is activated when a flood condition is detected, and
enables the system to continue servicing valid connection requests. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_tcp_syncookies | | Identifiers and References | References:
NT28(R22), 3.2.8, 5.10.1.1, 3.1.20, CCI-000366, CM-7(a), CM-7(b), SC-5(1), SC-5(2), SC-5(3)(a), CM-6(a), DE.AE-1, DE.CM-1, ID.AM-3, PR.AC-5, PR.DS-4, PR.DS-5, PR.PT-4, SRG-OS-000480-GPOS-00227, SRG-OS-000420-GPOS-00186, SRG-OS-000142-GPOS-00071, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, 4.2.3.4, 4.3.3.4, 4.4.3.3, APO01.06, APO13.01, BAI04.04, DSS01.03, DSS01.05, DSS03.01, DSS03.05, DSS05.02, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.1.3, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.17.2.1, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 1, 12, 13, 14, 15, 16, 18, 2, 4, 6, 7, 8, 9 | |
|
Rule
Enable Kernel Parameter to Log Martian Packets on all IPv4 Interfaces
[ref] | To set the runtime status of the net.ipv4.conf.all.log_martians kernel parameter, run the following command: $ sudo sysctl -w net.ipv4.conf.all.log_martians=1
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv4.conf.all.log_martians = 1 | | Rationale: | The presence of "martian" packets (which have impossible addresses)
as well as spoofed packets, source-routed packets, and redirects could be a
sign of nefarious network activity. Logging these packets enables this activity
to be detected. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv4_conf_all_log_martians | | Identifiers and References | References:
NT28(R22), 3.2.4, 3.1.20, CCI-000126, CM-7(a), CM-7(b), SC-5(3)(a), DE.CM-1, PR.AC-3, PR.DS-4, PR.IP-1, PR.PT-3, PR.PT-4, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.2, SR 7.1, SR 7.2, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS01.04, DSS03.05, DSS05.02, DSS05.03, DSS05.05, DSS05.07, DSS06.06, A.11.2.6, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.6.2.1, A.6.2.2, A.9.1.2, 1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9, SRG-OS-000480-GPOS-00227 | |
|
| Group
iptables and ip6tables
Group contains 2 groups and 7 rules |
[ref]
A host-based firewall called netfilter is included as
part of the Linux kernel distributed with the system. It is
activated by default. This firewall is controlled by the program
iptables, and the entire capability is frequently referred to by
this name. An analogous program called ip6tables handles filtering
for IPv6.
Unlike TCP Wrappers, which depends on the network server
program to support and respect the rules written, netfilter
filtering occurs at the kernel level, before a program can even
process the data from the network packet. As such, any program on
the system is affected by the rules written.
This section provides basic information about strengthening
the iptables and ip6tables configurations included with the system.
For more complete information that may allow the construction of a
sophisticated ruleset tailored to your environment, please consult
the references at the end of this section. |
| Group
Strengthen the Default Ruleset
Group contains 1 rule |
[ref]
The default rules can be strengthened. The system
scripts that activate the firewall rules expect them to be defined
in the configuration files iptables and ip6tables in the directory
/etc/sysconfig. Many of the lines in these files are similar
to the command line arguments that would be provided to the programs
/sbin/iptables or /sbin/ip6tables - but some are quite
different.
The following recommendations describe how to strengthen the
default ruleset configuration file. An alternative to editing this
configuration file is to create a shell script that makes calls to
the iptables program to load in rules, and then invokes service
iptables save to write those loaded rules to
/etc/sysconfig/iptables.
The following alterations can be made directly to
/etc/sysconfig/iptables and /etc/sysconfig/ip6tables.
Instructions apply to both unless otherwise noted. Language and address
conventions for regular iptables are used throughout this section;
configuration for ip6tables will be either analogous or explicitly
covered. Warning:
The program system-config-securitylevel
allows additional services to penetrate the default firewall rules
and automatically adjusts /etc/sysconfig/iptables. This program
is only useful if the default ruleset meets your security
requirements. Otherwise, this program should not be used to make
changes to the firewall configuration because it re-writes the
saved configuration file. |
Rule
Ensure that the iptables default deny policy should be configured correctly
[ref] | The function of the Input chain is to filter packets received from external sources. Any
externally provided service requires configuring the corresponding Input policy and opening
the relevant port, so that external clients can access the service through that port.
It can not be scanned automatically, please check it manually.
Check if the policy configured for the reject chain meets business needs.
| | Rationale: | If not configured, all external attempts to access related services will be discarded due to
the default policy configuration being DROP. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_ipatbles_rule_refuse | | Identifiers and References | | |
|
| Group
Inspect and Activate Default Rules
Group contains 2 rules |
[ref]
View the currently-enforced iptables rules by running
the command:
$ sudo iptables -nL --line-numbers
The command is analogous for ip6tables.
If the firewall does not appear to be active (i.e., no rules
appear), activate it and ensure that it starts at boot by issuing
the following commands (and analogously for ip6tables):
$ sudo service iptables restart
The default iptables rules are:
Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
5 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
1 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
The ip6tables default rules are essentially the same. |
Rule
Verify iptables Enabled
[ref] | The iptables service can be enabled with the following command: $ sudo systemctl enable iptables.service | | Rationale: | The iptables service provides the system's host-based firewalling
capability for IPv4 and ICMP. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_service_iptables_enabled | | Identifiers and References | References:
AC-4, CM-7(b), CA-3(5), SC-7(21), CM-6(a), DE.AE-1, ID.AM-3, PR.AC-5, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3, APO01.06, APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 3, 4, 6, 8, 9 | |
|
Rule
Verify ip6tables Enabled if Using IPv6
[ref] | The ip6tables service can be enabled with the following command: $ sudo systemctl enable ip6tables.service | | Rationale: | The ip6tables service provides the system's host-based firewalling
capability for IPv6 and ICMPv6. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_service_ip6tables_enabled | | Identifiers and References | References:
AC-4, CM-7(b), CA-3(5), SC-7(21), CM-6(a), DE.AE-1, ID.AM-3, PR.AC-5, PR.DS-5, PR.IP-1, PR.PT-3, PR.PT-4, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, 4.2.3.4, 4.3.3.4, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, 4.4.3.3, APO01.06, APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.06, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 3, 4, 6, 8, 9 | |
|
Rule
Ensure that the iptables loopback policy configuration is correct
[ref] | The loopback address is a special address on the server, represented by 127.0.0.0/8,which is
not related to the network card and is mainly used for communication between local processes.
Messages with a source address of 127.0.0.0/8 should not be received from the network card,
and such messages should be discarded.
It can not be scanned automatically, please check it manually.
Check if the loopback address policy has been correctly configured.
- You can use below cli command to check the input chain of IPv4:
$ iptables -L INPUT -v -n
- Or check the output chain of IPv4:
$ iptables -L OUTPUT -v -n
- Or check the input chain of IPv6:
$ ip6tables -L INPUT -v -n
- Or check the output chain of IPv6:
$ ip6tables -L OUTPUT -v -n
| | Rationale: | If the loopback address policy is not set correctly, it may cause communication failure between
local processes or receive spoofing messages from the network card. The server needs to set
policies that allow receiving and processing loopback address messages from the lo interface,
but reject messages received from the network card. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_iptables_loopback_policy_configured_corrently | | Identifiers and References | | |
|
Rule
Ensure that the iptables output policy configuration is correct
[ref] | There are two main situations for server outgoing messages: one is when the host process
actively connects to an external server, such as HTTP access, or sends data to a log server,
etc.; the other is when the host process accesses the local service externally and the local
machine responds to the message.
It can not be scanned automatically, please check it manually.
Check if the policy configured for the output chain meets business needs.
| | Rationale: | If the OUTPUT policy is not configured, all outgoing messages from the server will be discarded
due to the default policy being DROP. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_iptables_output_policy_configured_corrently | | Identifiers and References | | |
|
Rule
Ensure that the iptables input and output association policies configuration is correct
[ref] | Although it is possible to configure packet policies for incoming and outgoing servers to the
Input and OUTPUT chains by configuring protocols, IP, and ports, in some cases it may be more
complex. For example, if the client accesses the server through a certain port, the server may
not necessarily return the response packet from the original port, and may use a random source
port. In this case, it is difficult to configure accurate policies through the sport parameter.
At this point, it is necessary to consider using association links to configure the strategy.
If an outgoing message belongs to an existing network link, it will be directly released; If a
received message belongs to an existing network link, it is also directly released. Because
these existing links must have been filtered and checked by other policies, otherwise they cannot
be established.
It can not be scanned automatically, please check it manually.
Check if the input and output chains are configured with associated policies.
- You can use below cli command to check if the input and output chains of IPv4 are configured with associated policies:
$ iptables -L
- You can use below cli command to check if the input and output chains of IPv6 are configured with associated policies:
$ ip6tables -L
| | Rationale: | If the policy is not configured through associated links, it is necessary to analyze all possible
link situations and configure corresponding policies. If the configuration is too loose, it may
cause security risks, and if the configuration is too strict, it may cause business interruption. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_iptables_association_policy_configured_corrently | | Identifiers and References | | |
|
Rule
Ensure that the iptables input policy configuration is correct
[ref] | The function of the Input chain is to filter packets received from external sources. Any
externally provided service requires configuring the corresponding Input policy and opening
the relevant port, so that external clients can access the service through that port.
It can not be scanned automatically, please check it manually.
Check if the policy configured for the input chain meets business needs.
| | Rationale: | If not configured, all external attempts to access related services will be discarded due to
the default policy configuration being DROP. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_iptables_input_policy_configured_corrently | | Identifiers and References | | |
|
| Group
firewalld
Group contains 2 groups and 3 rules |
[ref]
The dynamic firewall daemon firewalld provides a
dynamically managed firewall with support for network “zones” to assign
a level of trust to a network and its associated connections and interfaces.
It has support for IPv4 and IPv6 firewall settings. It supports Ethernet
bridges and has a separation of runtime and permanent configuration options.
It also has an interface for services or applications to add firewall rules
directly.
A graphical configuration tool, firewall-config, is used to configure
firewalld, which in turn uses iptables tool to communicate
with Netfilter in the kernel which implements packet filtering.
The firewall service provided by firewalld is dynamic rather than
static because changes to the configuration can be made at anytime and are
immediately implemented. There is no need to save or apply the changes. No
unintended disruption of existing network connections occurs as no part of
the firewall has to be reloaded. |
| Group
Inspect and Activate Default firewalld Rules
Group contains 1 rule |
[ref]
Firewalls can be used to separate networks into different zones
based on the level of trust the user has decided to place on the devices and
traffic within that network. NetworkManager informs firewalld to which
zone an interface belongs. An interface's assigned zone can be changed by
NetworkManager or via the firewall-config tool.
The zone settings in /etc/firewalld/ are a range of preset settings
which can be quickly applied to a network interface. These are the zones
provided by firewalld sorted according to the default trust level of the
zones from untrusted to trusted:
drop
Any incoming network packets are dropped, there is no
reply. Only outgoing network connections are possible. block
Any incoming network connections are rejected with an
icmp-host-prohibited message for IPv4 and icmp6-adm-prohibited
for IPv6. Only network connections initiated from within the system are
possible. public
For use in public areas. You do not trust the other
computers on the network to not harm your computer. Only selected incoming
connections are accepted. external
For use on external networks with masquerading enabled
especially for routers. You do not trust the other computers on the network to
not harm your computer. Only selected incoming connections are accepted. dmz
For computers in your demilitarized zone that are
publicly-accessible with limited access to your internal network. Only selected
incoming connections are accepted. work
For use in work areas. You mostly trust the other computers
on networks to not harm your computer. Only selected incoming connections are
accepted. home
For use in home areas. You mostly trust the other computers
on networks to not harm your computer. Only selected incoming connections are
accepted. internal
For use on internal networks. You mostly trust the
other computers on the networks to not harm your computer. Only selected
incoming connections are accepted. trusted
All network connections are accepted.
It is possible to designate one of these zones to be the default zone. When
interface connections are added to NetworkManager, they are assigned
to the default zone. On installation, the default zone in firewalld is set to
be the public zone.
To find out all the settings of a zone, for example the public zone,
enter the following command as root:
# firewall-cmd --zone=public --list-all
Example output of this command might look like the following:
# firewall-cmd --zone=public --list-all
public
interfaces:
services: mdns dhcpv6-client ssh
ports:
forward-ports:
icmp-blocks: source-quench
To view the network zones currently active, enter the following command as root:
# firewall-cmd --get-service
The following listing displays the result of this command
on common openEuler 22.03 LTS system:
# firewall-cmd --get-service
amanda-client bacula bacula-client dhcp dhcpv6 dhcpv6-client dns ftp
high-availability http https imaps ipp ipp-client ipsec kerberos kpasswd
ldap ldaps libvirt libvirt-tls mdns mountd ms-wbt mysql nfs ntp openvpn
pmcd pmproxy pmwebapi pmwebapis pop3s postgresql proxy-dhcp radius rpc-bind
samba samba-client smtp ssh telnet tftp tftp-client transmission-client
vnc-server wbem-https
Finally to view the network zones that will be active after the next firewalld
service reload, enter the following command as root:
# firewall-cmd --get-service --permanent |
Rule
Verify firewalld Enabled
[ref] | The firewalld service can be enabled with the following command: $ sudo systemctl enable firewalld.service | | Rationale: | Access control methods provide the ability to enhance system security posture
by restricting services and known good IP addresses and address ranges. This
prevents connections from unknown hosts and protocols. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_service_firewalld_enabled | | Identifiers and References | References:
4.7, 3.1.3, 3.4.7, CCI-000366, AC-4, CM-7(b), CA-3(5), SC-7(21), CM-6(a), PR.IP-1, FMT_MOF_EXT.1, SRG-OS-000480-GPOS-00227, SR 7.6, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, 11, 3, 9 | |
|
| Group
Strengthen the Default Ruleset
Group contains 2 rules |
[ref]
The default rules can be strengthened. The system
scripts that activate the firewall rules expect them to be defined
in configuration files under the /etc/firewalld/services
and /etc/firewalld/zones directories.
The following recommendations describe how to strengthen the
default ruleset configuration file. An alternative to editing this
configuration file is to create a shell script that makes calls to
the firewall-cmd program to load in rules under the /etc/firewalld/services
and /etc/firewalld/zones directories.
Instructions apply to both unless otherwise noted. Language and address
conventions for regular firewalld rules are used throughout this section. Warning:
The program firewall-config
allows additional services to penetrate the default firewall rules
and automatically adjusts the firewalld ruleset(s). |
Rule
Set Default firewalld Zone for Incoming Packets
[ref] | To set the default zone to drop for
the built-in default zone which processes incoming IPv4 and IPv6 packets,
modify the following line in
/etc/firewalld/firewalld.conf to be:
DefaultZone=drop Warning:
To prevent denying any access to the system, automatic remediation
of this control is not available. Remediation must be automated as
a component of machine provisioning, or followed manually as outlined
above. | | Rationale: | In firewalld the default zone is applied only after all
the applicable rules in the table are examined for a match. Setting the
default zone to drop implements proper design for a firewall, i.e.
any packets which are not explicitly permitted should not be
accepted. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_set_firewalld_default_zone | | Identifiers and References | References:
5.10.1, 3.1.3, 3.4.7, 3.13.6, CCI-000366, CA-3(5), CM-7(b), SC-7(23), CM-6(a), PR.IP-1, PR.PT-3, FMT_MOF_EXT.1, SRG-OS-000480-GPOS-00227, SRG-OS-000480-VMM-002000, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2, 11, 14, 3, 9 | |
|
Rule
Disable Unnecessary Services and Ports on Firewalld
[ref] | Configure the firewalld services and ports to allow approved
services to have the right to access to the system. To configure firewalld
to open/remove ports, run the following command:
$ sudo firewall-cmd --permanent --add-port/--remove-port=port_number/tcp
or
$ sudo firewall-cmd --permanent --add-service/--remove-service=service_name
Whether the port configuration is correct depends on the application scenario. Therefore, automatic check is not suitable. | | Rationale: | In order to prevent unauthorized connection of devices, unauthorized
transfer of information, or unauthorized tunneling (i.e., embedding of data
types within data types), organizations must disable or restrict unused or
unnecessary physical and logical ports/protocols on information systems.
Operating systems are capable of providing a wide variety of functions and
services. Some of the functions and services provided by default may not be
necessary to support essential organizational operations.
Additionally, it is sometimes convenient to provide multiple services from
a single component (e.g., VPN and IPS); however, doing so increases risk
over limiting the services provided by any one component.
To support the requirements and principles of least functionality, the
operating system must support the organizational requirements, providing
only essential capabilities and limiting the use of ports, protocols,
and/or services to only those required, authorized, and approved to conduct
official business or to address authorized quality of life issues. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_disable_unnecessary_service_and_ports | | Identifiers and References | | |
|
| Group
Wireless Networking
Group contains 1 group and 1 rule |
[ref]
Wireless networking, such as 802.11
(WiFi) and Bluetooth, can present a security risk to sensitive or
classified systems and networks. Wireless networking hardware is
much more likely to be included in laptop or portable systems than
in desktops or servers.
Removal of hardware provides the greatest assurance that the wireless
capability remains disabled. Acquisition policies often include provisions to
prevent the purchase of equipment that will be used in sensitive spaces and
includes wireless capabilities. If it is impractical to remove the wireless
hardware, and policy permits the device to enter sensitive spaces as long
as wireless is disabled, efforts should instead focus on disabling wireless capability
via software. |
| Group
Disable Wireless Through Software Configuration
Group contains 1 rule |
[ref]
If it is impossible to remove the wireless hardware
from the device in question, disable as much of it as possible
through software. The following methods can disable software
support for wireless networking, but note that these methods do not
prevent malicious software or careless users from re-activating the
devices. |
Rule
Deactivate Wireless Network Interfaces
[ref] | Deactivating wireless network interfaces should prevent
normal usage of the wireless capability.
Configure the system to disable all wireless network interfaces with the
following command:
$ sudo nmcli radio wifi off | | Rationale: | The use of wireless networking can introduce many different attack vectors into
the organization's network. Common attack vectors such as malicious association
and ad hoc networks will allow an attacker to spoof a wireless access point
(AP), allowing validated systems to connect to the malicious AP and enabling the
attacker to monitor and record network traffic. These malicious APs can also
serve to create a man-in-the-middle attack or be used to create a denial of
service to valid network resources. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_wireless_disable_interfaces | | Identifiers and References | References:
4.3.1, 3.1.16, CCI-000085, CCI-002418, AC-18(a), AC-18(3), CM-7(a), CM-7(b), CM-6(a), MP-7, PR.AC-3, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000424-GPOS-00188, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.04, DSS05.02, DSS05.03, DSS05.05, DSS06.06, A.11.2.6, A.12.1.2, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.2.1, A.6.2.2, A.9.1.2, 11, 12, 14, 15, 3, 8, 9 | |
|
| Group
IPv6
Group contains 1 group and 3 rules |
[ref]
The system includes support for Internet Protocol
version 6. A major and often-mentioned improvement over IPv4 is its
enormous increase in the number of available addresses. Another
important feature is its support for automatic configuration of
many network settings. |
| Group
Configure IPv6 Settings if Necessary
Group contains 3 rules |
[ref]
A major feature of IPv6 is the extent to which systems
implementing it can automatically configure their networking
devices using information from the network. From a security
perspective, manually configuring important configuration
information is preferable to accepting it from the network
in an unauthenticated fashion. |
Rule
Disable Kernel Parameter for Accepting Source-Routed Packets on all IPv6 Interfaces
[ref] | To set the runtime status of the net.ipv6.conf.all.accept_source_route kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.all.accept_source_route=0
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv6.conf.all.accept_source_route = 0 | | Rationale: | Source-routed packets allow the source of the packet to suggest routers
forward the packet along a different path than configured on the router, which can
be used to bypass network security measures. This requirement applies only to the
forwarding of source-routerd traffic, such as when IPv6 forwarding is enabled and
the system is functioning as a router.
Accepting source-routed packets in the IPv6 protocol has few legitimate
uses. It should be disabled unless it is absolutely required. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_source_route | | Identifiers and References | References:
NT28(R22), 3.1.20, CCI-000366, CM-7(a), CM-7(b), CM-6(a), DE.AE-1, ID.AM-3, PR.AC-5, PR.DS-5, PR.PT-4, SRG-OS-000480-GPOS-00227, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, 4.2.3.4, 4.3.3.4, 4.4.3.3, APO01.06, APO13.01, DSS01.05, DSS03.01, DSS05.02, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.1, A.12.1.2, A.13.1.1, A.13.1.2, A.13.1.3, A.13.2.1, A.13.2.2, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 1, 12, 13, 14, 15, 16, 18, 4, 6, 8, 9 | |
|
Rule
Disable Kernel Parameter for IPv6 Forwarding
[ref] | To set the runtime status of the net.ipv6.conf.all.forwarding kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.all.forwarding=0
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv6.conf.all.forwarding = 0 | | Rationale: | IP forwarding permits the kernel to forward packets from one network
interface to another. The ability to forward packets between two networks is
only appropriate for systems acting as routers. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_forwarding | | Identifiers and References | References:
CCI-000366, CM-7(a), CM-7(b), CM-6(a), DE.CM-1, PR.DS-4, PR.IP-1, PR.PT-3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 6.2, SR 7.1, SR 7.2, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, APO13.01, BAI04.04, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.03, DSS03.05, DSS05.02, DSS05.05, DSS05.07, DSS06.06, A.12.1.2, A.12.1.3, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.17.2.1, A.9.1.2, 1, 11, 12, 13, 14, 15, 16, 2, 3, 7, 8, 9 | |
|
Rule
Disable Accepting ICMP Redirects for All IPv6 Interfaces
[ref] | To set the runtime status of the net.ipv6.conf.all.accept_redirects kernel parameter, run the following command: $ sudo sysctl -w net.ipv6.conf.all.accept_redirects=0
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: net.ipv6.conf.all.accept_redirects = 0 | | Rationale: | An illicit ICMP redirect message could result in a man-in-the-middle attack. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_net_ipv6_conf_all_accept_redirects | | Identifiers and References | References:
NT28(R22), 3.3.2, 3.1.20, CCI-001551, CM-7(a), CM-7(b), CM-6(a), PR.IP-1, PR.PT-3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2, 11, 14, 3, 9, SRG-OS-000480-GPOS-00227 | |
|
Rule
Ensure the network interface is bound to the correct area
[ref] | Different firewall regions can develop different filtering strategies. If the server network
is complex and has multiple interfaces, and different interfaces undertake different business
functions, it is recommended to configure the interfaces to different regions and develop
different firewall strategies. For example, the external network business interface does not
allow SSH access, while the internal network management interface can open SSH access.
It can not be scanned automatically, please check it manually.
Check the interface configuration of each region:
$ firewall-cmd --get-active-zones | | Rationale: | If all interfaces are configured in one area, firewall policies are not conducive to configuring
different interfaces differently, increasing management complexity, and reducing the filtering
efficiency of firewall security protection. Due to configuration issues, messages that should
not be received may not be rejected or discarded. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_network_interface_binding_corrently | | Identifiers and References | | |
|
| Group
GRUB2 bootloader configuration
Group contains 3 rules |
[ref]
During the boot process, the boot loader is
responsible for starting the execution of the kernel and passing
options to it. The boot loader allows for the selection of
different kernels - possibly on different partitions or media.
The default openEuler 22.03 LTS boot loader for x86 systems is called GRUB2.
Options it can pass to the kernel include single-user mode, which
provides root access without any authentication, and the ability to
disable SELinux. To prevent local users from modifying the boot
parameters and endangering security, protect the boot loader configuration
with a password and ensure its configuration file's permissions
are set properly. |
Rule
Ensure SMAP is not disabled during boot
[ref] | The SMAP is used to prevent the supervisor mode from unintentionally reading/writing into
memory pages in the user space, it is enabled by default since Linux kernel 3.7.
But it could be disabled through kernel boot parameters.
Ensure that Supervisor Mode Access Prevention (SMAP) is not disabled by
the nosmap boot paramenter option.
Check that the line GRUB_CMDLINE_LINUX="..." within /etc/default/grub
doesn't contain the argument nosmap.
Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --remove-args="nosmap" | | Rationale: | Disabling SMAP can facilitate exploitation of vulnerabilities caused by unintended access and
manipulation of data in the user space. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_nosmap_argument_absent | | Identifiers and References | | |
|
Rule
Set the UEFI Boot Loader Password
[ref] | The grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
To do so, select a superuser account name and password and and modify the
/etc/grub.d/01_users configuration file with the new account name.
Since plaintext passwords are a security risk, generate a hash for the pasword
by running the following command:
$ grub2-setpassword
When prompted, enter the password that was selected.
NOTE: It is recommended not to use common administrator account names like root,
admin, or administrator for the grub2 superuser account.
Change the superuser to a different username (The default is 'root').
$ sed -i s/root/bootuser/g /etc/grub.d/01_users
To meet FISMA Moderate, the bootloader superuser account and password MUST
differ from the root account and password.
Once the superuser account and password have been added,
update the
grub.cfg file by running:
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
NOTE: Do NOT manually add the superuser account and password to the
grub.cfg file as the grub2-mkconfig command overwrites this file. Warning:
To prevent hard-coded passwords, automatic remediation of this control is not available. Remediation
must be automated as a component of machine provisioning, or followed manually as outlined above. | | Rationale: | Password protection on the boot loader configuration ensures
users with physical access cannot trivially alter
important bootloader settings. These include which kernel to use,
and whether to enter single-user mode. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_uefi_password | | Identifiers and References | References:
1.4.2, 3.4.5, CCI-000213, 164.308(a)(1)(ii)(B), 164.308(a)(7)(i), 164.308(a)(7)(ii)(A), 164.310(a)(1), 164.310(a)(2)(i), 164.310(a)(2)(ii), 164.310(a)(2)(iii), 164.310(b), 164.310(c), 164.310(d)(1), 164.310(d)(2)(iii), CM-6(a), PR.AC-4, PR.AC-6, PR.PT-3, FIA_AFL.1, SRG-OS-000080-GPOS-00048, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.03, DSS06.06, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 11, 12, 14, 15, 16, 18, 3, 5, NT28(R17) | |
|
Rule
Ensure SMEP is not disabled during boot
[ref] | The SMEP is used to prevent the supervisor mode from executing user space code,
it is enabled by default since Linux kernel 3.0. But it could be disabled through
kernel boot parameters.
Ensure that Supervisor Mode Execution Prevention (SMEP) is not disabled by
the nosmep boot paramenter option.
Check that the line GRUB_CMDLINE_LINUX="..." within /etc/default/grub
doesn't contain the argument nosmep.
Run the following command to update command line for already installed kernels:
# grubby --update-kernel=ALL --remove-args="nosmep" | | Rationale: | Disabling SMEP can facilitate exploitation of certain vulnerabilities because it allows
the kernel to unintentionally execute code in less privileged memory space. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_nosmep_argument_absent | | Identifiers and References | | |
|
| Group
Installing and Maintaining Software
Group contains 9 groups and 15 rules |
[ref]
The following sections contain information on
security-relevant choices during the initial operating system
installation process and the setup of software
updates. |
| Group
Polkit
Group contains 1 rule |
[ref]
Polkit, which provides privilege escalation capabilities. |
Rule
Ensure Only Root Can Run The Command of Pkexec
[ref] | The pkexec command enables a common user to have the rights of the super user or other users.
After the authentication is successful, the command is executed with the rights of the super user.
Pkexec provides a convenient path for users to change their identities, unconstrained use of the pkexec command can bring potential security risks.
The permission to access the root account using pkexec is restricted.
By default, the password of the root user must be verified when uses pkexec. Only the root user can obtain the system administrator rights. | | Rationale: | Low-privilege users can not use pkexec. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_only_root_can_run_pkexec | | Identifiers and References | | |
|
| Group
System and Software Integrity
Group contains 3 groups and 4 rules |
[ref]
System and software integrity can be gained by installing antivirus, increasing
system encryption strength with FIPS, verifying installed software, enabling SELinux,
installing an Intrusion Prevention System, etc. However, installing or enabling integrity
checking tools cannot prevent intrusions, but they can detect that an intrusion
may have occurred. Requirements for integrity checking may be highly dependent on
the environment in which the system will be used. Snapshot-based approaches such
as AIDE may induce considerable overhead in the presence of frequent software updates. |
| Group
System Cryptographic Policies
Group contains 2 rules |
[ref]
Linux has the capability to centrally configure cryptographic polices. The command
update-crypto-policies is used to set the policy applicable for the various
cryptographic back-ends, such as SSL/TLS libraries. The configured cryptographic
policies will be the default policy used by these backends unless the application
user configures them otherwise. When the system has been configured to use the
centralized cryptographic policies, the administrator is assured that any application
that utilizes the supported backends will follow a policy that adheres to the
configured profile.
Currently the supported backends are:
- GnuTLS library
- OpenSSL library
- NSS library
- OpenJDK
- Libkrb5
- BIND
- OpenSSH
Applications and languages which rely on any of these backends will follow the
system policies as well. Examples are apache httpd, nginx, php, and others. |
Rule
Configure SSH to use System Crypto Policy
[ref] | Crypto Policies provide a centralized control over crypto algorithms usage of many packages.
SSH is supported by crypto policy, but the SSH configuration may be
set up to ignore it.
To check that Crypto Policies settings are configured correctly, ensure that
the CRYPTO_POLICY variable is either commented or not set at all
in the /etc/sysconfig/sshd. | | Rationale: | Overriding the system crypto policy makes the behavior of the SSH service violate expectations,
and makes system configuration more fragmented. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_ssh_crypto_policy | | Identifiers and References | References:
AC-17(a), AC-17(2), CM-6(a), MA-4(6), SC-13 | |
|
Rule
Configure System Cryptography Policy
[ref] | To configure the system cryptography policy to use ciphers only from the DEFAULT
policy, run the following command:
$ sudo update-crypto-policies --set DEFAULT
The rule checks if settings for selected crypto policy are configured as expected. Configuration files in the /etc/crypto-policies/back-ends are either symlinks to correct files provided by Crypto-policies package or they are regular files in case crypto policy customizations are applied.
Crypto policies may be customized by crypto policy modules, in which case it is delimited from the base policy using a colon. Warning:
The system needs to be rebooted for these changes to take effect. Warning:
System Crypto Modules must be provided by a vendor that undergoes
FIPS-140 certifications.
FIPS-140 is applicable to all Federal agencies that use
cryptographic-based security systems to protect sensitive information
in computer and telecommunication systems (including voice systems) as
defined in Section 5131 of the Information Technology Management Reform
Act of 1996, Public Law 104-106. This standard shall be used in
designing and implementing cryptographic modules that Federal
departments and agencies operate or are operated for them under
contract. See https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf
To meet this, the system has to have cryptographic software provided by
a vendor that has undergone this certification. This means providing
documentation, test results, design information, and independent third
party review by an accredited lab. While open source software is
capable of meeting this, it does not meet FIPS-140 unless the vendor
submits to this process. | | Rationale: | Centralized cryptographic policies simplify applying secure ciphers across an operating system and
the applications that run on that operating system. Use of weak or untested encryption algorithms
undermines the purposes of utilizing encryption to protect data. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_configure_crypto_policy | | Identifiers and References | References:
AC-17(a), AC-17(2), CM-6(a), MA-4(6), SC-13, SC-12(2), SC-12(3), SRG-OS-000396-GPOS-00176, SRG-OS-000393-GPOS-00173, SRG-OS-000394-GPOS-00174 | |
|
| Group
Software Integrity Checking
Group contains 1 group and 2 rules |
[ref]
Both the AIDE (Advanced Intrusion Detection Environment)
software and the RPM package management system provide
mechanisms for verifying the integrity of installed software.
AIDE uses snapshots of file metadata (such as hashes) and compares these
to current system files in order to detect changes.
The RPM package management system can conduct integrity
checks by comparing information in its metadata database with
files installed on the system. |
| Group
Verify Integrity with AIDE
Group contains 1 rule |
[ref]
AIDE conducts integrity checks by comparing information about
files with previously-gathered information. Ideally, the AIDE database is
created immediately after initial system configuration, and then again after any
software update. AIDE is highly configurable, with further configuration
information located in /usr/share/doc/aide-VERSION. |
Rule
aide intrusion detection should be enabled
[ref] | aide (advanced intrusion detection environment) is an intrusion detection tool that
can be used to check the integrity of files and directories in the system and identify
files or directories that have been maliciously tampered with. The principle of the
integrity check is to first construct a baseline database, which contains some attributes
of the file or directory such as permissions, users, etc. When performing the integrity
check, the current system status is compared with the baseline database to obtain the
check results. Finally, the file or directory changes of the current system are reported,
that is, the inspection report.
Enabling aide intrusion detection can effectively identify malicious tampering with files
or directories, thereby improving system integrity and security. The files or directories
that need to be checked can be configured as needed, which is highly flexible. Users only
need to query the check report to determine whether there is malicious tampering.
It can not be scanned automatically, please check it manually.
Check if the loopback address policy has been correctly configured.
| | Rationale: | The more files that need to be checked, the longer the checking process will take. If users
enable aide, they should configure the inspection strategy appropriately based on their own
business scenarios. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_enable_aide_detection | | Identifiers and References | | |
|
Rule
IMA metrics should be enabled
[ref] | IMA (Integrity Measurement Architecture) is an integrity protection function provided
by the kernel. When IMA is turned on, it can provide integrity measurements for
important files in the system based on user-defined policies. The measurement results
can be used locally and remotely. Proof of integrity.
When the IMA measurement function is not enabled in the system, summary information
of key files cannot be recorded in real time, and tampering with file contents or
attributes cannot be identified. Functions such as local attestation and remote
attestation that protect system integrity rely on the summary value provided by IMA
metrics, so they cannot be used, or the integrity protection is incomplete.
IMA global policy configuration is related to the specific environment. Normally,
integrity protection is only targeted at immutable files (such as executable files,
dynamic libraries, etc.). If the policy is improperly configured, it may lead to
excessive performance and memory overhead. It is recommended that users use their
own The situation determines whether to enable IMA and configure the correct policy.
Note: Since IMA is only the measurement part of the global integrity protection
mechanism, complete use requires TPM 2.0 and remote attestation services. This
specification only explains and recommends the measurement part of IMA. If the
system does not integrate TPM 2.0 and remote attestation services, the IMA measurement
function should not be enabled.
IMA measurement does not support container environments and virtual machine
environments, requires UEFI startup, and does not support Legacy mode.
Use the following command to check whether the current system has IMA measurement enabled.
| | Rationale: | Turning on IMA metrics will cause a slight increase in system startup time and file
access time.
If the policy is improperly configured (such as measuring real-time changing log files,
temporary files, etc.), the measurement log may grow too fast and occupy too much system
memory, and the memory occupied by the measurement log will not be released before the
next restart of the system. , thus affecting the normal operation of the business. In
addition, because the measured files are constantly changing, the measurement value changes,
and the remote certification baseline value cannot be updated synchronously, causing the
remote certification to fail and losing the meaning of integrity protection. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_ima_verification | | Identifiers and References | | |
|
| Group
Updating Software
Group contains 1 rule |
[ref]
The dnf command line tool is used to install and
update software packages. The system also provides a graphical
software update tool in the System menu, in the Administration submenu,
called Software Update.
openEuler 22.03 LTS systems contain an installed software catalog called
the RPM database, which records metadata of installed packages. Consistently using
dnf or the graphical Software Update for all software installation
allows for insight into the current inventory of installed software on the system.
|
Rule
Ensure gpgcheck Enabled for All dnf Package Repositories
[ref] | To ensure signature checking is not disabled for
any repos, remove any lines from files in /etc/yum.repos.d of the form:
gpgcheck=0 | | Rationale: | Verifying the authenticity of the software prior to installation validates
the integrity of the patch or upgrade received from a vendor. This ensures
the software has not been tampered with and that it has been provided by a
trusted vendor. Self-signed certificates are disallowed by this
requirement. Certificates used to verify the software must be from an
approved Certificate Authority (CA)." | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_gpgcheck_never_disabled | | Identifiers and References | References:
SRG-OS-000366-GPOS-00153, SRG-OS-000366-VMM-001430, SRG-OS-000370-VMM-001460, SRG-OS-000404-VMM-001650, 5.10.4.1, 3.4.8, CCI-001749, 164.308(a)(1)(ii)(D), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i), CM-5(3), SI-7, SC-12, SC-12(3), CM-6(a), SA-12, SA-12(10), CM-11(a), CM-11(b), PR.DS-6, PR.DS-8, PR.IP-1, FAU_GEN.1.1.c, Req-6.2, SR 3.1, SR 3.3, SR 3.4, SR 3.8, SR 7.6, 4.3.4.3.2, 4.3.4.3.3, 4.3.4.4.4, APO01.06, BAI03.05, BAI06.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS06.02, A.11.2.4, A.12.1.2, A.12.2.1, A.12.5.1, A.12.6.2, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, 11, 2, 3, 9, NT28(R15) | |
|
| Group
Su
Group contains 2 rules |
[ref]
Su, which provides the ability to switch to root or other users. |
Rule
Ensure Only Users of Wheel Group Can Use SU
[ref] | The su command enables a common user to have the rights of the super user or other users.
It is often used to switch from a common user account to the system root account.
The su command provides a convenient way for users to change their identities.
However, unconstrained use of the su command brings potential risks to the system.
The permission to access the root account using the su command is restricted.
Allows only common users in the wheel group to use the su command, which improves the security of system. | | Rationale: | Users outside the wheel group cannot run the su command. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_su_only_for_wheel | | Identifiers and References | | |
|
Rule
Ensure Always Set Path is Set to YES
[ref] | The su command enables a common user to have the rights of the super user or other users.
It is often used to switch from a low-privilege user account to the system root account.
The su command provides a convenient way for users to change their identities.
However, using the su command without restrictions brings potential risks to the system.
The path is not automatically set for the user when the user is changed by using su.
If the system automatically initializes the environment variable PATH after you run the su command to switch users,
you can effectively prevent the privilege escalation which caused by inheriting the environment variable PATH. | | Rationale: | None | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_su_always_set_path | | Identifiers and References | | |
|
| Group
Sudo
Group contains 2 rules |
[ref]
Sudo, which stands for "su 'do'", provides the ability to delegate authority
to certain users, groups of users, or system administrators. When configured for system
users and/or groups, Sudo can allow a user or group to execute privileged commands
that normally only root is allowed to execute.
For more information on Sudo and addition Sudo configuration options, see
https://www.sudo.ws. |
Rule
Ensure Not All Users Can Use Sudo In All Commands
[ref] | The sudo command enables a common user to execute certain programs with the root permission.
Most system management commands need to be executed as root.
Properly authorizing other users can reduce the burden of the system administrator,
but directly granting the root password to the common user will bring security risks.
Using sudo can avoid this problem.
You can use the sudo mechanism to avoid using the root user for privileged programs that need to be run by the root user.
If so, the security is improved.
However, ensure that NOT all low-privilege users can run all commands. | | Rationale: | Low-privilege users maybe can not run privileged programs. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sudo_not_for_all_users | | Identifiers and References | | |
|
Rule
Make sure sudoers cannot configure scripts writable by low-privileged users
[ref] | sudo can enable the set ordinary user to execute certain specific programs with root privileges,
and the corresponding configuration file is /etc/sudoers. Administrator users can configure
corresponding rules to make certain scripts or binary files run with root permissions. Therefore,
the scripts configured by sudo should only be writable by root. Scripts that can be written by
low-privilege users cannot be configured. If low-privilege users are configured, they can be written
by root. script, the user can perform privilege escalation operations by modifying the script.
It can not be scanned automatically, please check it manually.
Check related configuration.
| | Rationale: | none. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sudoers_disable_low_privileged_configure | | Identifiers and References | | |
|
| Group
System Tooling / Utilities
Group contains 2 rules |
[ref]
The following checks evaluate the system for recommended base packages -- both for installation
and removal. |
Rule
Uninstall All Python2 Packages
[ref] | The python2 package can be removed with the following command:
$ sudo dnf erase python2 | | Rationale: | python2 related packages should be removed. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_package_python2_removed | | Identifiers and References | | |
|
Rule
Disable use of SysRq key
[ref] |
SysRq allows users with physical access to access dangerous system-level commands
in the computer, and the use of SysRq functions needs to be restricted.
If the SysRq key is not disabled, the SysRq call can be triggered through the
keyboard, which may cause commands to be sent directly to the kernel, affecting
the system.
openEuler prohibits the use of SysRq keys by default.
Check whether the system prohibits the use of the SysRq key:
| | Rationale: | SysRq related commands cannot be used in the system. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_disabled_SysRq | | Identifiers and References | | |
|
Rule
seccomp should be enabled
[ref] | seccomp (full name: secure computing mode), when it was first introduced into the
Linux kernel, limited the system calls available to the process to four types: read,
write, _exit, sigreturn. In the original whitelisting method, in addition to the
four system calls allowed by the open file descriptor, if other system calls are
attempted, the kernel will use SIGKILL or SIGSYS to terminate the process.
The whitelist method is too restrictive and has little practical effect. In practical
applications, more precise restrictions are needed. In order to solve this problem,
BPF was introduced. The combination of seccomp and BPF rules allows users to filter
system calls using configurable policies. The policy is implemented using Berkeley
Packet Filter rules, which can filter any system calls and their parameters.
The openEuler kernel already provides seccomp function support by default, and also
provides the libseccomp peripheral package to help user-mode programs conveniently
set seccomp rules.
It can not be scanned automatically, please check it manually.
Check whether the target process has seccomp mode enabled. Here we take checking the test_seccomp process as an example.
| | Rationale: | seccomp cannot set the opening, closing or rules globally, but is specific to each
process. That is, the process can set and enable seccomp by itself, which affects
itself and all child threads, but does not affect other processes.
If seccomp is enabled in a process, there will be a performance loss when making
system calls. Users need to determine whether the performance loss is acceptable
based on actual business scenarios. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_enabled_seccomp | | Identifiers and References | | |
|
Rule
Uninstall development and compilation tools
[ref] | If the business environment contains compilation tools, they can
easily be used by attackers to edit, tamper with, and reverse analyze
key files in the environment to carry out attacks. Therefore, it is
strictly prohibited to install various compilation, decompilation,
and binary analysis tools in the production environment, including
but not limited to: compilation tools, decompilation tools, compilation
environments, etc. Common third-party development and compilation tools
include: gcc, cpp, mcpp, flex, cmake, make, rpm-build, ld, ar, etc.
If the business environment relies on interpreters such as python, lua,
and perl during deployment or operation, the interpreter running
environment can be retained.
It can not be scanned automatically, please check it manually.
Use keyword scanning to determine whether debugging tools exist in the business environment or mirror environment.
- First, check whether the relevant rpm package is installed:
$ rpm -qa | grep -iE "^(gcc-|cpp-|mcpp-|flex-|cmake-|make-|rpm-build-|binutils-extra|elfutils-extra|llvm-|rpcgen-|gcc-c++)"; rpm -qa libtool
- Then,check whether the relevant commands are installed:
$ files=`find / -type f \( -name "gcc" -o -name "g++" -o -name "c++" -o -name "cpp" -o -name "mcpp" -o -name "flex" -o -name "lex" -o -name "cmake" -o -name "make" -o -name "rpmbuild" -o -name "ld" -o -name "ar" -o -name "llc" -o -name "rpcgen" -o -name "libtool" -o -name "javac" -o -name "objdump" -o -name "eu-objdump" -o -name "eu-readelf" -o -name "nm" \) 2> /dev/null`; for f in $files; do if [ -n "$f" ]; then file $f | grep -i "ELF"; fi; done
| | Rationale: | none. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_uninstall_development_and_compliation_tools | | Identifiers and References | | |
|
Rule
uninstall debugging tools
[ref] | If the business environment contains debugging scripts and tools, they can
easily be exploited and attacked by attackers. Therefore, it is strictly
prohibited to install various debugging tools and files in the production
environment, including but not limited to: code debugging tools, privilege
escalation commands, scripts, and tools used for debugging functions, certificates,
and keys used in the debugging phase. Perf tools, point management and piling
tools for performance testing, attack scripts and tool scripts for verifying
security issues such as CVE, etc. Common open source third-party debugging tools
include: strace, gdb, readelf, perf, etc.
It can not be scanned automatically, please check it manually.
Use keyword scanning to determine whether debugging tools exist in the business environment or mirror environment.
| | Rationale: | none. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_uninstall_debugging_tools | | Identifiers and References | | |
|
| Group
System Accounting with auditd
Group contains 7 groups and 41 rules |
[ref]
The audit service provides substantial capabilities
for recording system activities. By default, the service audits about
SELinux AVC denials and certain types of security-relevant events
such as system logins, account modifications, and authentication
events performed by programs such as sudo.
Under its default configuration, auditd has modest disk space
requirements, and should not noticeably impact system performance.
NOTE: The Linux Audit daemon auditd can be configured to use
the augenrules program to read audit rules files ( *.rules)
located in /etc/audit/rules.d location and compile them to create
the resulting form of the /etc/audit/audit.rules configuration file
during the daemon startup (default configuration). Alternatively, the auditd
daemon can use the auditctl utility to read audit rules from the
/etc/audit/audit.rules configuration file during daemon startup,
and load them into the kernel. The expected behavior is configured via the
appropriate ExecStartPost directive setting in the
/usr/lib/systemd/system/auditd.service configuration file.
To instruct the auditd daemon to use the augenrules program
to read audit rules (default configuration), use the following setting:
ExecStartPost=-/sbin/augenrules --load
in the /usr/lib/systemd/system/auditd.service configuration file.
In order to instruct the auditd daemon to use the auditctl
utility to read audit rules, use the following setting:
ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
in the /usr/lib/systemd/system/auditd.service configuration file.
Refer to [Service] section of the /usr/lib/systemd/system/auditd.service
configuration file for further details.
Government networks often have substantial auditing
requirements and auditd can be configured to meet these
requirements.
Examining some example audit records demonstrates how the Linux audit system
satisfies common requirements.
The following example from Fedora Documentation available at
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/sect-Security-Enhanced_Linux-Troubleshooting-Fixing_Problems.html#sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages
shows the substantial amount of information captured in a
two typical "raw" audit messages, followed by a breakdown of the most important
fields. In this example the message is SELinux-related and reports an AVC
denial (and the associated system call) that occurred when the Apache HTTP
Server attempted to access the /var/www/html/file1 file (labeled with
the samba_share_t type):
type=AVC msg=audit(1226874073.147:96): avc: denied { getattr } for pid=2465 comm="httpd"
path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0
tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file
type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13
a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48
gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd"
exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
msg=audit(1226874073.147:96)- The number in parentheses is the unformatted time stamp (Epoch time)
for the event, which can be converted to standard time by using the
date command.
{ getattr }- The item in braces indicates the permission that was denied.
getattr
indicates the source process was trying to read the target file's status information.
This occurs before reading files. This action is denied due to the file being
accessed having the wrong label. Commonly seen permissions include getattr,
read, and write.
comm="httpd"- The executable that launched the process. The full path of the executable is
found in the
exe= section of the system call (SYSCALL) message,
which in this case, is exe="/usr/sbin/httpd".
path="/var/www/html/file1"- The path to the object (target) the process attempted to access.
scontext="unconfined_u:system_r:httpd_t:s0"- The SELinux context of the process that attempted the denied action. In
this case, it is the SELinux context of the Apache HTTP Server, which is running
in the
httpd_t domain.
tcontext="unconfined_u:object_r:samba_share_t:s0"- The SELinux context of the object (target) the process attempted to access.
In this case, it is the SELinux context of
file1. Note: the samba_share_t
type is not accessible to processes running in the httpd_t domain.
- From the system call (
SYSCALL) message, two items are of interest:
success=no: indicates whether the denial (AVC) was enforced or not.
success=no indicates the system call was not successful (SELinux denied
access). success=yes indicates the system call was successful - this can
be seen for permissive domains or unconfined domains, such as initrc_t
and kernel_t.
exe="/usr/sbin/httpd": the full path to the executable that launched
the process, which in this case, is exe="/usr/sbin/httpd".
|
| Group
Configure auditd Data Retention
Group contains 9 rules |
[ref]
The audit system writes data to /var/log/audit/audit.log. By default,
auditd rotates 5 logs by size (6MB), retaining a maximum of 30MB of
data in total, and refuses to write entries when the disk is too
full. This minimizes the risk of audit data filling its partition
and impacting other services. This also minimizes the risk of the audit
daemon temporarily disabling the system if it cannot write audit log (which
it can be configured to do).
For a busy
system or a system which is thoroughly auditing system activity, the default settings
for data retention may be
insufficient. The log file size needed will depend heavily on what types
of events are being audited. First configure auditing to log all the events of
interest. Then monitor the log size manually for awhile to determine what file
size will allow you to keep the required data for the correct time period.
Using a dedicated partition for /var/log/audit prevents the
auditd logs from disrupting system functionality if they fill, and,
more importantly, prevents other activity in /var from filling the
partition and stopping the audit trail. (The audit logs are size-limited and
therefore unlikely to grow without bound unless configured to do so.) Some
machines may have requirements that no actions occur which cannot be audited.
If this is the case, then auditd can be configured to halt the machine
if it runs out of space. Note: Since older logs are rotated,
configuring auditd this way does not prevent older logs from being
rotated away before they can be viewed.
If your system is configured to halt when logging cannot be performed, make
sure this can never happen under normal circumstances! Ensure that
/var/log/audit is on its own partition, and that this partition is
larger than the maximum amount of data auditd will retain
normally. |
Rule
Configure auditd admin_space_left on Low Disk Space
[ref] | The auditd service can be configured to take an action
when disk space is running low but prior to running out of space completely.
Edit the file /etc/audit/auditd.conf. Add or modify the following line,
substituting ACTION appropriately:
admin_space_left_action = ACTION
Set this value to single to cause the system to switch to single user
mode for corrective action. Acceptable values also include suspend and
halt. For certain systems, the need for availability
outweighs the need to log all actions, and a different setting should be
determined. Details regarding all possible values for ACTION are described in the
auditd.conf man page. | | Rationale: | Administrators should be made aware of an inability to record
audit records. If a separate partition or logical volume of adequate size
is used, running low on space for audit records should never occur. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_data_retention_admin_space_left | | Identifiers and References | References:
5.2.1.2, 5.4.1.1, 3.3.1, CCI-000140, CCI-001343, 164.312(a)(2)(ii), A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.16.1.4, A.16.1.5, A.16.1.7, A.17.2.1, AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a), DE.AE-3, DE.AE-5, PR.DS-4, PR.PT-1, RS.AN-1, RS.AN-4, Req-10.7, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, SR 7.1, SR 7.2, 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO11.04, APO12.06, APO13.01, BAI03.05, BAI04.04, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, MEA02.01, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8 | |
|
Rule
Configure auditd Max Log File Size
[ref] | Determine the amount of audit data (in megabytes)
which should be retained in each log file. Edit the file
/etc/audit/auditd.conf. Add or modify the following line, substituting
the correct value of 6 for STOREMB:
max_log_file = STOREMB
Set the value to 6 (MB) or higher for general-purpose systems.
Larger values, of course,
support retention of even more audit data. | | Rationale: | The total storage for audit log files must be large enough to retain
log information over the period required. This is a function of the maximum
log file size and the number of logs retained. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_data_retention_max_log_file | | Identifiers and References | References:
5.2.1.1, 5.4.1.1, AU-11, CM-6(a), DE.AE-3, DE.AE-5, PR.PT-1, RS.AN-1, RS.AN-4, Req-10.7, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO11.04, APO12.06, BAI03.05, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, MEA02.01, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.16.1.4, A.16.1.5, A.16.1.7, 1, 11, 12, 13, 14, 15, 16, 19, 3, 4, 5, 6, 7, 8 | |
|
Rule
Configure auditd space_left on Low Disk Space
[ref] | The auditd service can be configured to take an action
when disk space is running low but prior to running out of space completely.
Edit the file /etc/audit/auditd.conf. Add or modify the following line,
substituting SIZE_in_MB appropriately:
space_left = SIZE_in_MB
Set this value to the appropriate size in Megabytes cause the system to
notify the user of an issue. | | Rationale: | Notifying administrators of an impending disk space problem may allow them to
take corrective action prior to any disruption. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_data_retention_space_left | | Identifiers and References | References:
CCI-001855, AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a), DE.AE-3, DE.AE-5, PR.DS-4, PR.PT-1, RS.AN-1, RS.AN-4, Req-10.7, SRG-OS-000343-GPOS-00134, SRG-OS-000343-VMM-001240, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, SR 7.1, SR 7.2, 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO11.04, APO12.06, APO13.01, BAI03.05, BAI04.04, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, MEA02.01, A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.16.1.4, A.16.1.5, A.16.1.7, A.17.2.1, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8 | |
|
Rule
Configure auditd space_left Action on Low Disk Space
[ref] | The auditd service can be configured to take an action
when disk space starts to run low.
Edit the file /etc/audit/auditd.conf. Modify the following line,
substituting ACTION appropriately:
space_left_action = ACTION
Possible values for ACTION are described in the auditd.conf man page.
These include:
syslogemailexecsuspendsinglehalt
Set this to email (instead of the default,
which is suspend) as it is more likely to get prompt attention. Acceptable values
also include suspend, single, and halt. | | Rationale: | Notifying administrators of an impending disk space problem may
allow them to take corrective action prior to any disruption. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_data_retention_space_left_action | | Identifiers and References | References:
5.2.1.2, 5.4.1.1, 3.3.1, CCI-001855, 164.312(a)(2)(ii), A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.16.1.4, A.16.1.5, A.16.1.7, A.17.2.1, AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a), DE.AE-3, DE.AE-5, PR.DS-4, PR.PT-1, RS.AN-1, RS.AN-4, Req-10.7, SRG-OS-000343-GPOS-00134, SRG-OS-000343-VMM-001240, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, SR 7.1, SR 7.2, 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO11.04, APO12.06, APO13.01, BAI03.05, BAI04.04, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, MEA02.01, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8 | |
|
Rule
Configure auditd admin_space_left Action on Low Disk Space
[ref] | The auditd service can be configured to take an action
when disk space is running low but prior to running out of space completely.
Edit the file /etc/audit/auditd.conf. Add or modify the following line,
substituting ACTION appropriately:
admin_space_left_action = ACTION
Set this value to single to cause the system to switch to single user
mode for corrective action. Acceptable values also include suspend and
halt. For certain systems, the need for availability
outweighs the need to log all actions, and a different setting should be
determined. Details regarding all possible values for ACTION are described in the
auditd.conf man page. | | Rationale: | Administrators should be made aware of an inability to record
audit records. If a separate partition or logical volume of adequate size
is used, running low on space for audit records should never occur. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_data_retention_admin_space_left_action | | Identifiers and References | References:
5.2.1.2, 5.4.1.1, 3.3.1, CCI-000140, CCI-001343, 164.312(a)(2)(ii), A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.16.1.4, A.16.1.5, A.16.1.7, A.17.2.1, AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a), DE.AE-3, DE.AE-5, PR.DS-4, PR.PT-1, RS.AN-1, RS.AN-4, Req-10.7, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, SR 7.1, SR 7.2, 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO11.04, APO12.06, APO13.01, BAI03.05, BAI04.04, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, MEA02.01, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8 | |
|
Rule
Configure auditd max_log_file_action Upon Reaching Maximum Log Size
[ref] | The default action to take when the logs reach their maximum size
is to rotate the log files, discarding the oldest one. To configure the action taken
by auditd, add or correct the line in /etc/audit/auditd.conf:
max_log_file_action = ACTION
Possible values for ACTION are described in the auditd.conf man
page. These include:
syslogsuspendrotatekeep_logs
Set the ACTION to rotate to ensure log rotation
occurs. This is the default. The setting is case-insensitive. | | Rationale: | Automatically rotating logs (by setting this to rotate)
minimizes the chances of the system unexpectedly running out of disk space by
being overwhelmed with log data. However, for systems that must never discard
log data, or which use external processes to transfer it and reclaim space,
keep_logs can be employed. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_data_retention_max_log_file_action | | Identifiers and References | References:
5.2.1.3, 5.4.1.1, 164.312(a)(2)(ii), A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.16.1.4, A.16.1.5, A.16.1.7, A.17.2.1, AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a), DE.AE-3, DE.AE-5, PR.DS-4, PR.PT-1, RS.AN-1, RS.AN-4, Req-10.7, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, SR 7.1, SR 7.2, 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO11.04, APO12.06, APO13.01, BAI03.05, BAI04.04, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, MEA02.01, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8 | |
|
Rule
Configure auditd Disk Error Action on Disk Error
[ref] | The auditd service can be configured to take an action
when there is a disk error.
Edit the file /etc/audit/auditd.conf. Add or modify the following line,
substituting ACTION appropriately:
disk_error_action = ACTION
Set this value to single to cause the system to switch to single-user
mode for corrective action. Acceptable values also include syslog,
exec, single, 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: | Taking appropriate action in case of disk errors will minimize the possibility of
losing audit records. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_data_disk_error_action | | Identifiers and References | References:
AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a), DE.AE-3, DE.AE-5, PR.DS-4, PR.PT-1, RS.AN-1, RS.AN-4, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, SR 7.1, SR 7.2, 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO11.04, APO12.06, APO13.01, BAI03.05, BAI04.04, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, MEA02.01, A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.16.1.4, A.16.1.5, A.16.1.7, A.17.2.1, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8 | |
|
Rule
Configure auditd Number of Logs Retained
[ref] | Determine how many log files
auditd should retain when it rotates logs.
Edit the file /etc/audit/auditd.conf. Add or modify the following
line, substituting NUMLOGS with the correct value of 5:
num_logs = NUMLOGS
Set the value to 5 for general-purpose systems.
Note that values less than 2 result in no log rotation. | | Rationale: | The total storage for audit log files must be large enough to retain
log information over the period required. This is a function of the maximum log
file size and the number of logs retained. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_data_retention_num_logs | | Identifiers and References | References:
5.4.1.1, 3.3.1, AU-11, CM-6(a), DE.AE-3, DE.AE-5, PR.PT-1, RS.AN-1, RS.AN-4, Req-10.7, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO11.04, APO12.06, BAI03.05, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, MEA02.01, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.16.1.4, A.16.1.5, A.16.1.7, 1, 11, 12, 13, 14, 15, 16, 19, 3, 4, 5, 6, 7, 8 | |
|
Rule
Configure auditd Disk Full Action when Disk Space Is Full
[ref] | The auditd service can be configured to take an action
when disk space is running low but prior to running out of space completely.
Edit the file /etc/audit/auditd.conf. Add or modify the following line,
substituting ACTION appropriately:
disk_full_action = ACTION
Set this value to single to cause the system to switch to single-user
mode for corrective action. Acceptable values also include syslog,
exec, single, 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: | Taking appropriate action in case of a filled audit storage volume will minimize
the possibility of losing audit records. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_auditd_data_disk_full_action | | Identifiers and References | References:
AU-5(b), AU-5(2), AU-5(1), AU-5(4), CM-6(a), DE.AE-3, DE.AE-5, PR.DS-4, PR.PT-1, RS.AN-1, RS.AN-4, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 6.1, SR 7.1, SR 7.2, 4.2.3.10, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO11.04, APO12.06, APO13.01, BAI03.05, BAI04.04, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, MEA02.01, A.12.1.3, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.16.1.4, A.16.1.5, A.16.1.7, A.17.2.1, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8 | |
|
| Group
Configure auditd Rules for Comprehensive Auditing
Group contains 5 groups and 29 rules |
[ref]
The auditd program can perform comprehensive
monitoring of system activity. This section describes recommended
configuration settings for comprehensive auditing, but a full
description of the auditing system's capabilities is beyond the
scope of this guide. The mailing list linux-audit@redhat.com exists
to facilitate community discussion of the auditing system.
The audit subsystem supports extensive collection of events, including:
- Tracing of arbitrary system calls (identified by name or number)
on entry or exit.
- Filtering by PID, UID, call success, system call argument (with
some limitations), etc.
- Monitoring of specific files for modifications to the file's
contents or metadata.
Auditing rules at startup are controlled by the file /etc/audit/audit.rules.
Add rules to it to meet the auditing requirements for your organization.
Each line in /etc/audit/audit.rules represents a series of arguments
that can be passed to auditctl and can be individually tested
during runtime. See documentation in /usr/share/doc/audit-VERSION and
in the related man pages for more details.
If copying any example audit rulesets from /usr/share/doc/audit-VERSION,
be sure to comment out the
lines containing arch= which are not appropriate for your system's
architecture. Then review and understand the following rules,
ensuring rules are activated as needed for the appropriate
architecture.
After reviewing all the rules, reading the following sections, and
editing as needed, the new rules can be activated as follows:
$ sudo service auditd restart |
| Group
Record Attempts to Alter Logon and Logout Events
Group contains 1 rule |
[ref]
The audit system already collects login information for all users
and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d in order to watch for attempted manual
edits of files involved in storing logon events:
-w /var/log/tallylog -p wa -k logins
-w /var/run/faillock/ -p wa -k logins
-w /var/log/lastlog -p wa -k logins
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file in order to watch for unattempted manual
edits of files involved in storing logon events:
-w /var/log/tallylog -p wa -k logins
-w /var/run/faillock/ -p wa -k logins
-w /var/log/lastlog -p wa -k logins |
Rule
Record Attempts to Alter Logon and Logout Events - lastlog
[ref] | The audit system already collects login information for all users
and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d in order to watch for attempted manual
edits of files involved in storing logon events:
-w /var/log/lastlog -p wa -k logins
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file in order to watch for unattempted manual
edits of files involved in storing logon events:
-w /var/log/lastlog -p wa -k logins | | Rationale: | Manual editing of these files may indicate nefarious activity, such
as an attacker attempting to remove evidence of an intrusion. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_login_events_lastlog | | Identifiers and References | References:
5.2.8, 3.1.7, CCI-000172, CCI-002884, CCI-000126, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), AC-6(9), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.2.3, SRG-OS-000392-GPOS-00172, SRG-OS-000470-GPOS-00214, SRG-OS-000473-GPOS-00218, SRG-OS-000473-VMM-001930, SRG-OS-000470-VMM-001900, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
| Group
Records Events that Modify Date and Time Information
Group contains 5 rules |
[ref]
Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time. All changes to the system
time should be audited. |
Rule
Record attempts to alter time through settimeofday
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S settimeofday -F key=audit_time_rules
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S settimeofday -F key=audit_time_rules
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S settimeofday -F key=audit_time_rules
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S settimeofday -F key=audit_time_rules
The -k option allows for the specification of a key in string form that can be
used for better reporting capability through ausearch and aureport. Multiple
system calls can be defined on the same line to save space if desired, but is
not required. See an example of multiple combined syscalls:
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules | | Rationale: | Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time (such as sshd). All changes
to the system time should be audited. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_time_settimeofday | | Identifiers and References | References:
5.2.4, 5.4.1.1, 3.1.7, CCI-001487, CCI-000169, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), AC-6(9), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, Req-10.4.2.b, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Record Attempts to Alter the localtime File
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the default),
add the following line to a file with suffix .rules in the directory
/etc/audit/rules.d:
-w /etc/localtime -p wa -k audit_time_rules
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-w /etc/localtime -p wa -k audit_time_rules
The -k option allows for the specification of a key in string form that can
be used for better reporting capability through ausearch and aureport and
should always be used. | | Rationale: | Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time (such as sshd). All changes
to the system time should be audited. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_time_watch_localtime | | Identifiers and References | References:
5.2.4, 5.4.1.1, 3.1.7, CCI-001487, CCI-000169, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), AC-6(9), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, Req-10.4.2.b, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Record Attempts to Alter Time Through stime
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d for both 32 bit and 64 bit systems:
-a always,exit -F arch=b32 -S stime -F key=audit_time_rules
Since the 64 bit version of the "stime" system call is not defined in the audit
lookup table, the corresponding "-F arch=b64" form of this rule is not expected
to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule
form itself is sufficient for both 32 bit and 64 bit systems). If the
auditd daemon is configured to use the auditctl utility to
read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file for both 32 bit and 64 bit systems:
-a always,exit -F arch=b32 -S stime -F key=audit_time_rules
Since the 64 bit version of the "stime" system call is not defined in the audit
lookup table, the corresponding "-F arch=b64" form of this rule is not expected
to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule
form itself is sufficient for both 32 bit and 64 bit systems). The -k option
allows for the specification of a key in string form that can be used for
better reporting capability through ausearch and aureport. Multiple system
calls can be defined on the same line to save space if desired, but is not
required. See an example of multiple combined system calls:
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules | | Rationale: | Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time (such as sshd). All changes
to the system time should be audited. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_time_stime | | Identifiers and References | References:
5.4.1.1, 3.1.7, CCI-001487, CCI-000169, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), AC-6(9), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, Req-10.4.2.b, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Record Attempts to Alter Time Through clock_settime
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-change
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-change
The -k option allows for the specification of a key in string form that can
be used for better reporting capability through ausearch and aureport.
Multiple system calls can be defined on the same line to save space if
desired, but is not required. See an example of multiple combined syscalls:
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules | | Rationale: | Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time (such as sshd). All changes
to the system time should be audited. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_time_clock_settime | | Identifiers and References | References:
5.2.4, 5.4.1.1, 3.1.7, CCI-001487, CCI-000169, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), AC-6(9), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, Req-10.4.2.b, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Record attempts to alter time through adjtimex
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S adjtimex -F key=audit_time_rules
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S adjtimex -F key=audit_time_rules
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S adjtimex -F key=audit_time_rules
If the system is 64 bit then also add the following line:
-a always,exit -F arch=b64 -S adjtimex -F key=audit_time_rules
The -k option allows for the specification of a key in string form that can be
used for better reporting capability through ausearch and aureport. Multiple
system calls can be defined on the same line to save space if desired, but is
not required. See an example of multiple combined syscalls:
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=audit_time_rules | | Rationale: | Arbitrary changes to the system time can be used to obfuscate
nefarious activities in log files, as well as to confuse network services that
are highly dependent upon an accurate system time (such as sshd). All changes
to the system time should be audited. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_time_adjtimex | | Identifiers and References | References:
5.2.4, 5.4.1.1, 3.1.7, CCI-001487, CCI-000169, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), AC-6(9), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, Req-10.4.2.b, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
| Group
Record Unauthorized Access Attempts Events to Files (unsuccessful)
Group contains 5 rules |
[ref]
At a minimum, the audit system should collect unauthorized file
accesses for all users and root. Note that the "-F arch=b32" lines should be
present even on a 64 bit system. These commands identify system calls for
auditing. Even if the system is 64 bit it can still execute 32 bit system
calls. Additionally, these rules can be configured in a number of ways while
still achieving the desired effect. An example of this is that the "-S" calls
could be split up and placed on separate lines, however, this is less efficient.
Add the following to /etc/audit/audit.rules:
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If your system is 64 bit then these lines should be duplicated and the
arch=b32 replaced with arch=b64 as follows:
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access |
Rule
Record Unsuccessful Access Attempts to Files - openat
[ref] | At a minimum, the audit system should collect unauthorized file
accesses for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S openat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S openat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_openat | | Identifiers and References | References:
5.2.10, 3.1.7, CCI-000172, CCI-002884, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.2.4, Req-10.2.1, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-OS-000392-GPOS-00172, SRG-OS-000458-VMM-001810, SRG-OS-000461-VMM-001830, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Record Unsuccessful Access Attempts to Files - ftruncate
[ref] | At a minimum, the audit system should collect unauthorized file
accesses for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S ftruncate -F exiu=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_ftruncate | | Identifiers and References | References:
5.2.10, 3.1.7, CCI-000172, CCI-002884, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.2.4, Req-10.2.1, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-OS-000392-GPOS-00172, SRG-OS-000458-VMM-001810, SRG-OS-000461-VMM-001830, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Record Unsuccessful Access Attempts to Files - open
[ref] | At a minimum, the audit system should collect unauthorized file
accesses for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S open -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S open -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_open | | Identifiers and References | References:
5.2.10, 3.1.7, CCI-000172, CCI-002884, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.2.4, Req-10.2.1, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-OS-000392-GPOS-00172, SRG-OS-000458-VMM-001810, SRG-OS-000461-VMM-001830, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Record Unsuccessful Access Attempts to Files - creat
[ref] | At a minimum, the audit system should collect unauthorized file
accesses for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d:
-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b32 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If the system is 64 bit then also add the following lines:
-a always,exit -F arch=b64 -S creat -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
-a always,exit -F arch=b64 -S creat -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access Warning:
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient. | | Rationale: | Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing
these events could serve as evidence of potential system compromise. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_creat | | Identifiers and References | References:
5.2.10, 3.1.7, CCI-000172, CCI-002884, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.2.4, Req-10.2.1, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-OS-000392-GPOS-00172, SRG-OS-000458-VMM-001810, SRG-OS-000461-VMM-001830, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Configure file access permissions audit rules
[ref] | File access permission control is the basic permission management in Linux. Different users
are authorized to access different files, preventing the leakage of sensitive information
between users or the tampering of file data. It can also prevent ordinary users from
unauthorized access to high-privilege files or configurations in the system.
It is recommended to audit and monitor system calls that modify file permissions and file
owners in the operating system. If relevant auditing is not configured, if illegal
modification occurs, it will not be conducive to traceability.
openEuler does not configure file access control permission audit rules by default. It is
recommended that users configure corresponding rules based on actual business scenarios.
Check the configuration with the following command:
| | Rationale: | Configuring auditing, because audit logs need to be recorded when file permissions and owners
are modified, will have a slight impact on performance. However, since such operations should
not be performed frequently, it is actually not perceptible to users. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_successful_file_modification | | Identifiers and References | | |
|
| Group
Record File Deletion Events by User
Group contains 4 rules |
[ref]
At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=unset -F key=delete |
Rule
Ensure auditd Collects File Deletion Events by User - rename
[ref] | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S rename -F auid>=1000 -F auid!=unset -F key=delete | | Rationale: | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_rename | | Identifiers and References | References:
5.2.14, 3.1.7, CCI-000366, CCI-000172, CCI-002884, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.MA-2, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.2.7, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00210, SRG-OS-000468-GPOS-00212, SRG-OS-000392-GPOS-00172, SRG-OS-000466-VMM-001870, SRG-OS-000468-VMM-001890, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.4, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.1.1, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Ensure auditd Collects File Deletion Events by User - unlink
[ref] | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S unlink -F auid>=1000 -F auid!=unset -F key=delete | | Rationale: | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_unlink | | Identifiers and References | References:
5.2.14, 3.1.7, CCI-000366, CCI-000172, CCI-002884, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.MA-2, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.2.7, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00210, SRG-OS-000468-GPOS-00212, SRG-OS-000392-GPOS-00172, SRG-OS-000466-VMM-001870, SRG-OS-000468-VMM-001890, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.4, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.1.1, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Ensure auditd Collects File Deletion Events by User - renameat
[ref] | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S renameat -F auid>=1000 -F auid!=unset -F key=delete | | Rationale: | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_renameat | | Identifiers and References | References:
5.2.14, 3.1.7, CCI-000366, CCI-000172, CCI-002884, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.MA-2, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.2.7, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00210, SRG-OS-000468-GPOS-00212, SRG-OS-000392-GPOS-00172, SRG-OS-000466-VMM-001870, SRG-OS-000468-VMM-001890, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.4, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.1.1, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Ensure auditd Collects File Deletion Events by User - unlinkat
[ref] | At a minimum, the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S unlinkat -F auid>=1000 -F auid!=unset -F key=delete | | Rationale: | Auditing file deletions will create an audit trail for files that are removed
from the system. The audit trail could aid in system troubleshooting, as well as, detecting
malicious processes that attempt to delete log files to conceal their presence. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_file_deletion_events_unlinkat | | Identifiers and References | References:
5.2.14, 3.1.7, CCI-000366, CCI-000172, CCI-002884, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.MA-2, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.2.7, SRG-OS-000466-GPOS-00210, SRG-OS-000467-GPOS-00210, SRG-OS-000468-GPOS-00212, SRG-OS-000392-GPOS-00172, SRG-OS-000466-VMM-001870, SRG-OS-000468-VMM-001890, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.4, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.1.1, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
| Group
Record Information on Kernel Modules Loading and Unloading
Group contains 1 rule |
[ref]
To capture kernel module loading and unloading events, use following lines, setting ARCH to
either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:
-a always,exit -F arch=ARCH -S init_module,delete_module -F key=modules
Place to add the lines depends on a way auditd daemon is configured. If it is configured
to use the augenrules program (the default), add the lines to a file with suffix
.rules in the directory /etc/audit/rules.d.
If the auditd daemon is configured to use the auditctl utility,
add the lines to file /etc/audit/audit.rules. |
Rule
Ensure auditd Collects Information on Kernel Module Installing and Removing
[ref] | To capture kernel module installing and removing events.
The place to add the lines depends on a way auditd daemon is configured. If it is configured
to use the augenrules program (the default), add the lines to a file with suffix
.rules in the directory /etc/audit/rules.d.
If the auditd daemon is configured to use the auditctl utility,
add the lines to file /etc/audit/audit.rules.
Here, we only use the first method (augenrules) to check. | | Rationale: | The addition/removal of kernel modules can be used to alter the behavior of
the kernel and potentially introduce malicious code into kernel space. It is important
to have an audit trail of modules that have been introduced into the kernel. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_kernel_module_install_and_remove | | Identifiers and References | | |
|
Rule
Record Events that Modify User/Group Information - /etc/gshadow
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d, in order to capture events that modify
account changes:
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, in order to capture events that modify
account changes:
-w /etc/gshadow -p wa -k audit_rules_usergroup_modification | | Rationale: | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_gshadow | | Identifiers and References | References:
5.2.5, 5.4.1.1, 3.1.7, CCI-000018, CCI-000172, CCI-001403, CCI-001404, CCI-001405, CCI-001683, CCI-001684, CCI-001685, CCI-001686, CCI-002130, CCI-002132, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.2.5, SRG-OS-000004-GPOS-00004, SRG-OS-000004-VMM-000040, SRG-OS-000239-VMM-000810, SRG-OS-000240-VMM-000820, SRG-OS-000241-VMM-000830, SRG-OS-000274-VMM-000960, SRG-OS-000275-VMM-000970, SRG-OS-000276-VMM-000980, SRG-OS-000277-VMM-000990, SRG-OS-000303-VMM-001090, SRG-OS-000304-VMM-001100, SRG-OS-000476-VMM-001960, SR 1.1, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Record Events that Modify User/Group Information - /etc/passwd
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d, in order to capture events that modify
account changes:
-w /etc/passwd -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, in order to capture events that modify
account changes:
-w /etc/passwd -p wa -k audit_rules_usergroup_modification | | Rationale: | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_passwd | | Identifiers and References | References:
5.2.5, 5.4.1.1, 3.1.7, CCI-000018, CCI-000172, CCI-001403, CCI-001404, CCI-001405, CCI-001683, CCI-001684, CCI-001685, CCI-001686, CCI-002130, CCI-002132, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.2.5, SRG-OS-000004-GPOS-00004, SRG-OS-000239-GPOS-00089, SRG-OS-000240-GPOS-00090, SRG-OS-000241-GPOS-00091, SRG-OS-000303-GPOS-00120, SRG-OS-000476-GPOS-00221, SRG-OS-000274-GPOS-00104, SRG-OS-000275-GPOS-00105, SRG-OS-000276-GPOS-00106, SRG-OS-000277-GPOS-00107, SRG-OS-000004-VMM-000040, SRG-OS-000239-VMM-000810, SRG-OS-000240-VMM-000820, SRG-OS-000241-VMM-000830, SRG-OS-000274-VMM-000960, SRG-OS-000275-VMM-000970, SRG-OS-000276-VMM-000980, SRG-OS-000277-VMM-000990, SRG-OS-000303-VMM-001090, SRG-OS-000304-VMM-001100, SRG-OS-000476-VMM-001960, SR 1.1, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Record Events that Modify the System's Mandatory Access Controls
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d:
-w /etc/selinux/ -p wa -k MAC-policy
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-w /etc/selinux/ -p wa -k MAC-policy | | Rationale: | The system's mandatory access policy (SELinux) should not be
arbitrarily changed by anything other than administrator action. All changes to
MAC policy should be audited. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_mac_modification | | Identifiers and References | References:
5.2.7, 5.4.1.1, 3.1.8, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.5.5, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Record Events that Modify User/Group Information - /etc/security/opasswd
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d, in order to capture events that modify
account changes:
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, in order to capture events that modify
account changes:
-w /etc/security/opasswd -p wa -k audit_rules_usergroup_modification | | Rationale: | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_opasswd | | Identifiers and References | References:
5.2.5, 5.4.1.1, 3.1.7, CCI-000018, CCI-000172, CCI-001403, CCI-001404, CCI-001405, CCI-001683, CCI-001684, CCI-001685, CCI-001686, CCI-002130, CCI-002132, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.2.5, SRG-OS-000003-GPOS-00004, SRG-OS-000004-VMM-000040, SRG-OS-000239-VMM-000810, SRG-OS-000240-VMM-000820, SRG-OS-000241-VMM-000830, SRG-OS-000274-VMM-000960, SRG-OS-000275-VMM-000970, SRG-OS-000276-VMM-000980, SRG-OS-000277-VMM-000990, SRG-OS-000303-VMM-001090, SRG-OS-000304-VMM-001100, SRG-OS-000476-VMM-001960, SR 1.1, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Privilege escalation command audit rules should be configured
[ref] | Ordinary users can obtain super administrator privileges by calling privilege
escalation commands (with SUID/SGID set).
It is recommended to audit and monitor privilege escalation commands to facilitate
traceability afterwards.
openEuler does not configure audit rules for privilege escalation commands by
default. It is recommended that users configure corresponding rules based on actual
business scenarios.
It can not be scanned automatically, please check it manually.
| | Rationale: | The use of privilege escalation
commands carries high risks and is often used by attackers to attack the system. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_privilege_escalation_command | | Identifiers and References | | |
|
Rule
Record Events that Modify the System's Network Environment
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S sethostname,setdomainname -F key=audit_rules_networkconfig_modification
-w /etc/issue -p wa -k audit_rules_networkconfig_modification
-w /etc/issue.net -p wa -k audit_rules_networkconfig_modification
-w /etc/hosts -p wa -k audit_rules_networkconfig_modification
-w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S sethostname,setdomainname -F key=audit_rules_networkconfig_modification
-w /etc/issue -p wa -k audit_rules_networkconfig_modification
-w /etc/issue.net -p wa -k audit_rules_networkconfig_modification
-w /etc/hosts -p wa -k audit_rules_networkconfig_modification
-w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modification | | Rationale: | The network environment should not be modified by anything other
than administrator action. Any change to network parameters should be
audited. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_networkconfig_modification | | Identifiers and References | References:
5.2.6, 5.4.1.1, 3.1.7, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), AC-6(9), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, Req-10.5.5, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Record Attempts to Alter Process and Session Initiation Information
[ref] | The audit system already collects process information for all
users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d in order to watch for attempted manual
edits of files involved in storing such process information:
-w /var/run/utmp -p wa -k session
-w /var/log/btmp -p wa -k session
-w /var/log/wtmp -p wa -k session
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file in order to watch for attempted manual
edits of files involved in storing such process information:
-w /var/run/utmp -p wa -k session
-w /var/log/btmp -p wa -k session
-w /var/log/wtmp -p wa -k session | | Rationale: | Manual editing of these files may indicate nefarious activity, such
as an attacker attempting to remove evidence of an intrusion. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_session_events | | Identifiers and References | References:
5.2.9, 5.4.1.1, 3.1.7, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.2.3, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Record Events that Modify User/Group Information - /etc/group
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d, in order to capture events that modify
account changes:
-w /etc/group -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, in order to capture events that modify
account changes:
-w /etc/group -p wa -k audit_rules_usergroup_modification | | Rationale: | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_group | | Identifiers and References | References:
5.2.5, 5.4.1.1, 3.1.7, CCI-000018, CCI-000172, CCI-001403, CCI-001404, CCI-001405, CCI-001683, CCI-001684, CCI-001685, CCI-001686, CCI-002130, CCI-002132, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.2.5, SRG-OS-000004-GPOS-00004, SRG-OS-000004-VMM-000040, SRG-OS-000239-VMM-000810, SRG-OS-000240-VMM-000820, SRG-OS-000241-VMM-000830, SRG-OS-000274-VMM-000960, SRG-OS-000275-VMM-000970, SRG-OS-000276-VMM-000980, SRG-OS-000277-VMM-000990, SRG-OS-000303-VMM-001090, SRG-OS-000304-VMM-001100, SRG-OS-000476-VMM-001960, SR 1.1, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Audit rules for administrator privileged operations should be configured
[ref] |
The sudo extraction command operation log in the openEuler system is recorded
in the /var/log/secure log file by default. Other authentication-related security
logs are also recorded in this file. If the user wants to audit the sudo extraction
command, it is recommended that the sudo related logs be Record separately and
output to /var/log/sudo.log, and then audit and monitor the sudo log file.
openEuler does not configure audit rules for administrator privileged operations
by default. It is recommended that users configure corresponding rules based on
actual business scenarios.
Check the audit rules for administrator privileged operations by running the following command.
| | Rationale: | Sudo
privilege escalation is a high-risk operation and is relatively common in attacks. It
is recommended to configure audit rules for later tracing. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_admin_privilege | | Identifiers and References | | |
|
Rule
Record Events that Modify User/Group Information - /etc/shadow
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d, in order to capture events that modify
account changes:
-w /etc/shadow -p wa -k audit_rules_usergroup_modification
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, in order to capture events that modify
account changes:
-w /etc/shadow -p wa -k audit_rules_usergroup_modification | | Rationale: | In addition to auditing new user and group accounts, these watches
will alert the system administrator(s) to any modifications. Any unexpected
users, groups, or modifications should be investigated for legitimacy. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_usergroup_modification_shadow | | Identifiers and References | References:
5.2.5, 5.4.1.1, 3.1.7, CCI-000018, CCI-000172, CCI-001403, CCI-001404, CCI-001405, CCI-001683, CCI-001684, CCI-001685, CCI-001686, CCI-002130, CCI-002132, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AC-2(4), AU-2(d), AU-12(c), AC-6(9), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.2.5, SRG-OS-000004-GPOS-00004, SRG-OS-000004-VMM-000040, SRG-OS-000239-VMM-000810, SRG-OS-000240-VMM-000820, SRG-OS-000241-VMM-000830, SRG-OS-000274-VMM-000960, SRG-OS-000275-VMM-000970, SRG-OS-000276-VMM-000980, SRG-OS-000277-VMM-000990, SRG-OS-000303-VMM-001090, SRG-OS-000304-VMM-001100, SRG-OS-000476-VMM-001960, SR 1.1, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Ensure auditd Collects Information on Exporting to Media (successful)
[ref] | At a minimum, the audit system should collect media exportation
events for all users and root. If the auditd daemon is configured to
use the augenrules program to read audit rules during daemon startup
(the default), add the following line to a file with suffix .rules in
the directory /etc/audit/rules.d, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=unset -F key=export | | Rationale: | The unauthorized exportation of data to external media could result in an information leak
where classified information, Privacy Act information, and intellectual property could be lost. An audit
trail should be created each time a filesystem is mounted to help identify and guard against information
loss. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_media_export | | Identifiers and References | References:
5.2.13, 5.4.1.1, 3.1.7, CCI-000135, CCI-002884, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AU-2(d), AU-12(c), AC-6(9), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, Req-10.2.7, SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Make the auditd Configuration Immutable
[ref] | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d in order to make the auditd configuration
immutable:
-e 2
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file in order to make the auditd configuration
immutable:
-e 2
With this setting, a reboot will be required to change any audit rules. | | Rationale: | Making the audit configuration immutable prevents accidental as
well as malicious modification of the audit rules, although it may be
problematic if legitimate changes are needed during system
operation | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_immutable | | Identifiers and References | References:
4.1.18, 5.4.1.1, 3.3.1, 3.4.3, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.310(a)(2)(iv), 164.312(d), 164.310(d)(2)(iii), 164.312(b), 164.312(e), AC-6(9), CM-6(a), DE.AE-3, DE.AE-5, ID.SC-4, PR.AC-4, PR.DS-5, PR.PT-1, RS.AN-1, RS.AN-4, Req-10.5.2, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, SR 5.2, SR 6.1, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.7.3, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO01.06, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, BAI03.05, BAI08.02, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.04, DSS05.07, DSS06.02, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 19, 3, 4, 5, 6, 7, 8 | |
|
Rule
Ensure auditd Collects System Administrator Actions
[ref] | At a minimum, the audit system should collect administrator actions
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the default),
add the following line to a file with suffix .rules in the directory
/etc/audit/rules.d:
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions
If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-w /etc/sudoers -p wa -k actions
-w /etc/sudoers.d/ -p wa -k actions | | Rationale: | The actions taken by system administrators should be audited to keep a record
of what was executed on the system, as well as, for accountability purposes. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_audit_rules_sysadmin_actions | | Identifiers and References | References:
5.4.1.1, 3.1.7, CCI-000126, CCI-000130, CCI-000135, CCI-000172, CCI-002884, 164.308(a)(1)(ii)(D), 164.308(a)(3)(ii)(A), 164.308(a)(5)(ii)(C), 164.312(a)(2)(i), 164.312(b), 164.312(d), 164.312(e), AC-2(7)(b), AU-2(d), AU-12(c), AC-6(9), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-1, PR.AC-3, PR.AC-4, PR.AC-6, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, FAU_GEN.1.1.c, Req-10.2.2, Req-10.2.5.b, SRG-OS-000037-GPOS-00015, SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, SRG-OS-000462-GPOS-00206, SRG-OS-000471-GPOS-00215, SRG-OS-000462-VMM-001840, SRG-OS-000471-VMM-001910, SR 1.1, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.2.2, 4.3.3.3.9, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.8, 4.3.3.6.6, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS06.03, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.1.2, A.6.2.1, A.6.2.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Enable auditd Service
[ref] | The auditd service is an essential userspace component of
the Linux Auditing System, as it is responsible for writing audit records to
disk.
The auditd service can be enabled with the following command:
$ sudo systemctl enable auditd.service | | Rationale: | Without establishing what type of events occurred, it would be difficult
to establish, correlate, and investigate the events leading up to an outage or attack.
Ensuring the auditd service is active ensures audit records
generated by the kernel are appropriately recorded.
Additionally, a properly configured audit subsystem ensures that actions of
individual system users can be uniquely traced to those users so they
can be held accountable for their actions. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_service_auditd_enabled | | Identifiers and References | References:
4.1.2, 5.4.1.1, 3.3.1, 3.3.2, 3.3.6, CCI-000126, CCI-000130, CCI-000131, CCI-000132, CCI-000133, CCI-000134, 164.308(a)(1)(ii)(D), 164.308(a)(5)(ii)(C), 164.310(a)(2)(iv), 164.310(d)(2)(iii), 164.312(b), AC-2(g), AU-3, AU-10, AU-2(d), AU-12(c), AU-14(1), AC-6(9), CM-6(a), DE.AE-3, DE.AE-5, DE.CM-1, DE.CM-3, DE.CM-7, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, Req-10.1, SRG-OS-000037-GPOS-00015, SRG-OS-000038-GPOS-00016, SRG-OS-000039-GPOS-00017, SRG-OS-000040-GPOS-00018, SRG-OS-000042-GPOS-00021, SRG-OS-000255-GPOS-00096, SRG-OS-000037-VMM-000150, SRG-OS-000063-VMM-000310, SRG-OS-000038-VMM-000160, SRG-OS-000039-VMM-000170, SRG-OS-000040-VMM-000180, SRG-OS-000041-VMM-000190, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 6.2, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.03, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS03.05, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.7, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 2, 3, 4, 5, 6, 7, 8, 9 | |
|
Rule
Extend Audit Backlog Limit for the Audit Daemon
[ref] | To improve the kernel capacity to queue all log events, even those which occurred
prior to the audit daemon, add the argument audit_backlog_limit=8192 to the default
GRUB 2 command line for the Linux operating system in
/etc/default/grub, in the manner below:
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 audit=1 audit_backlog_limit=8192" Warning:
The GRUB 2 configuration file, grub.cfg,
is automatically updated each time a new kernel is installed. Note that any
changes to /etc/default/grub require rebuilding the grub.cfg
file. To update the GRUB 2 configuration file manually, use the
grub2-mkconfig -o command as follows:
| | Rationale: | audit_backlog_limit sets the queue length for audit events awaiting transfer
to the audit daemon. Until the audit daemon is up and running, all log messages
are stored in this queue. If the queue is overrun during boot process, the action
defined by audit failure flag is taken. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_audit_backlog_limit_argument | | Identifiers and References | References:
SRG-OS-000254-GPOS-00095, CM-6(a) | |
|
Rule
Enable Auditing for Processes Which Start Prior to the Audit Daemon
[ref] | To ensure all processes can be audited, even those which start
prior to the audit daemon, add the argument audit=1 to the default
GRUB 2 command line for the Linux operating system in
/boot/grub2/grubenv, in the manner below:
# grub2-editenv - set "$(grub2-editenv - list | grep kernelopts) audit=1" Warning:
The GRUB 2 configuration file, grub.cfg,
is automatically updated each time a new kernel is installed. Note that any
changes to /etc/default/grub require rebuilding the grub.cfg
file. To update the GRUB 2 configuration file manually, use the
grub2-mkconfig -o command as follows:
| | Rationale: | Each process on the system carries an "auditable" flag which indicates whether
its activities can be audited. Although auditd takes care of enabling
this for all processes which launch after it does, adding the kernel argument
ensures it is set for every process during boot. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_grub2_audit_argument | | Identifiers and References | References:
4.1.3, 5.4.1.1, 3.3.1, CCI-001464, CCI-000130, 164.308(a)(1)(ii)(D), 164.308(a)(5)(ii)(C), 164.310(a)(2)(iv), 164.310(d)(2)(iii), 164.312(b), AC-17(1), AU-14(1), AU-10, CM-6(a), IR-5(1), DE.AE-3, DE.AE-5, ID.SC-4, PR.AC-3, PR.PT-1, PR.PT-4, RS.AN-1, RS.AN-4, SRG-OS-000254-VMM-000880, Req-10.3, SR 1.13, SR 2.10, SR 2.11, SR 2.12, SR 2.6, SR 2.8, SR 2.9, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 6.1, SR 7.1, SR 7.6, 4.2.3.10, 4.3.2.6.7, 4.3.3.3.9, 4.3.3.5.8, 4.3.3.6.6, 4.3.4.4.7, 4.3.4.5.6, 4.3.4.5.7, 4.3.4.5.8, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO10.01, APO10.03, APO10.04, APO10.05, APO11.04, APO12.06, APO13.01, BAI03.05, BAI08.02, DSS01.04, DSS02.02, DSS02.04, DSS02.07, DSS03.01, DSS05.02, DSS05.03, DSS05.04, DSS05.07, MEA01.01, MEA01.02, MEA01.03, MEA01.04, MEA01.05, MEA02.01, A.11.2.6, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, A.13.1.1, A.13.2.1, A.14.1.3, A.15.2.1, A.15.2.2, A.16.1.4, A.16.1.5, A.16.1.7, A.6.2.1, A.6.2.2, 1, 11, 12, 13, 14, 15, 16, 19, 3, 4, 5, 6, 7, 8, SRG-OS-000254-GPOS-00095 | |
|
| Group
File Permissions and Masks
Group contains 7 groups and 40 rules |
[ref]
Traditional Unix security relies heavily on file and
directory permissions to prevent unauthorized users from reading or
modifying files to which they should not have access.
Several of the commands in this section search filesystems
for files or directories with certain characteristics, and are
intended to be run on every local partition on a given system.
When the variable PART appears in one of the commands below,
it means that the command is intended to be run repeatedly, with the
name of each local partition substituted for PART in turn.
The following command prints a list of all xfs partitions on the local
system, which is the default filesystem for openEuler 22.03 LTS
installations:
$ mount -t xfs | awk '{print $3}'
For any systems that use a different
local filesystem type, modify this command as appropriate. |
| Group
Restrict Programs from Dangerous Execution Patterns
Group contains 2 groups and 5 rules |
[ref]
The recommendations in this section are designed to
ensure that the system's features to protect against potentially
dangerous program execution are activated.
These protections are applied at the system initialization or
kernel level, and defend against certain types of badly-configured
or compromised programs. |
| Group
Enable ExecShield
Group contains 2 rules |
[ref]
ExecShield describes kernel features that provide
protection against exploitation of memory corruption errors such as buffer
overflows. These features include random placement of the stack and other
memory regions, prevention of execution in memory that should only hold data,
and special handling of text buffers. These protections are enabled by default
on 32-bit systems and controlled through sysctl variables
kernel.exec-shield and kernel.randomize_va_space. On the latest
64-bit systems, kernel.exec-shield cannot be enabled or disabled with
sysctl. |
Rule
Restrict Exposed Kernel Pointer Addresses Access
[ref] | To set the runtime status of the kernel.kptr_restrict kernel parameter,
run the following command:
$ sudo sysctl -w kernel.kptr_restrict=1
If this is not the system default value, add the following line to a file in the
directory /etc/sysctl.d:
kernel.kptr_restrict = 1
To ensure easy maintenance and location,
the kptr_restrict parameter is set to 0 by default in the openEuler release.
Please set this parameter based on the site requirements. | | Rationale: | Exposing kernel pointers (through procfs or seq_printf()) exposes
kernel writeable structures that can contain functions pointers. If a write vulnereability occurs
in the kernel allowing a write access to any of this structure, the kernel can be compromise. This
option disallow any program withtout the CAP_SYSLOG capability from getting the kernel pointers addresses,
replacing them with 0. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_kptr_restrict | | Identifiers and References | References:
NT28(R23), SC-30, SC-30(2), SC-30(5), CM-6(a), SRG-OS-000132-GPOS-00067 | |
|
Rule
Enable Randomized Layout of Virtual Address Space
[ref] | To set the runtime status of the kernel.randomize_va_space kernel parameter, run the following command: $ sudo sysctl -w kernel.randomize_va_space=2
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: kernel.randomize_va_space = 2 | | Rationale: | Address space layout randomization (ASLR) makes it more difficult for an
attacker to predict the location of attack code they have introduced into a
process's address space during an attempt at exploitation. Additionally,
ASLR makes it more difficult for an attacker to know the location of
existing code in order to re-purpose it using return oriented programming
(ROP) techniques. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_randomize_va_space | | Identifiers and References | References:
1.5.1, 3.1.7, CCI-000366, 164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e), SC-30, SC-30(2), CM-6(a), SRG-OS-000480-GPOS-00227, NT28(R23) | |
|
| Group
Disable Core Dumps
Group contains 1 rule |
[ref]
A core dump file is the memory image of an executable
program when it was terminated by the operating system due to
errant behavior. In most cases, only software developers
legitimately need to access these files. The core dump files may
also contain sensitive information, or unnecessarily occupy large
amounts of disk space.
Once a hard limit is set in /etc/security/limits.conf, a
user cannot increase that limit within his or her own session. If access
to core dumps is required, consider restricting them to only
certain users or groups. See the limits.conf man page for more
information.
The core dumps of setuid programs are further protected. The
sysctl variable fs.suid_dumpable controls whether
the kernel allows core dumps from these programs at all. The default
value of 0 is recommended. |
Rule
Disable Core Dumps for SUID programs
[ref] | To set the runtime status of the fs.suid_dumpable kernel parameter, run the following command: $ sudo sysctl -w fs.suid_dumpable=0
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: fs.suid_dumpable = 0 | | Rationale: | The core dump of a setuid program is more likely to contain
sensitive data, as the program itself runs with greater privileges than the
user who initiated execution of the program. Disabling the ability for any
setuid program to write a core file decreases the risk of unauthorized access
of such data. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_fs_suid_dumpable | | Identifiers and References | References:
1.5.1, 164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e), SI-11(a), SI-11(b), NT28(R23) | |
|
Rule
Restrict Access to Kernel Message Buffer
[ref] | To set the runtime status of the kernel.dmesg_restrict kernel parameter, run the following command: $ sudo sysctl -w kernel.dmesg_restrict=1
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: kernel.dmesg_restrict = 1 | | Rationale: | Unprivileged access to the kernel syslog can expose sensitive kernel
address information. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_dmesg_restrict | | Identifiers and References | References:
3.1.5, CCI-001314, 164.308(a)(1)(ii)(D), 164.308(a)(3), 164.308(a)(4), 164.310(b), 164.310(c), 164.312(a), 164.312(e), SI-11(a), SI-11(b), NT28(R23), SRG-OS-000132-GPOS-00067 | |
|
Rule
Restrict usage of ptrace to descendant processes
[ref] | To set the runtime status of the kernel.yama.ptrace_scope kernel parameter, run the following command: $ sudo sysctl -w kernel.yama.ptrace_scope=1
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: kernel.yama.ptrace_scope = 1 | | Rationale: | Unrestricted usage of ptrace allows compromised binaries to run ptrace
on another processes of the user. Like this, the attacker can steal
sensitive information from the target processes (e.g. SSH sessions, web browser, ...)
without any additional assistance from the user (i.e. without resorting to phishing).
| | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_kernel_yama_ptrace_scope | | Identifiers and References | References:
NT28(R25), SRG-OS-000132-GPOS-00067 | |
|
| Group
Restrict Dynamic Mounting and Unmounting of
Filesystems
Group contains 2 rules |
[ref]
Linux includes a number of facilities for the automated addition
and removal of filesystems on a running system. These facilities may be
necessary in many environments, but this capability also carries some risk -- whether direct
risk from allowing users to introduce arbitrary filesystems,
or risk that software flaws in the automated mount facility itself could
allow an attacker to compromise the system.
This command can be used to list the types of filesystems that are
available to the currently executing kernel:
$ find /lib/modules/`uname -r`/kernel/fs -type f -name '*.ko'
If these filesystems are not required then they can be explicitly disabled
in a configuratio file in /etc/modprobe.d. |
Rule
Ensure that unneeded file system mount is removed
[ref] | The Linux system supports a variety of file systems, which are
loaded into the kernel through ko mode. As a general operating
system platform, openEuler will provide various file systems ko,
which are stored in the /lib/modules/(kernel version)/kernel/fs/
directory and can be loaded through the insmod/modprobe command.
Users should determine which file systems do not need to be supported
based on actual scenarios, and prohibit these file systems from being
mounted through configuration. These file systems usually include:
cramfs、freevxfs、jffs2、hfs、hfsplus、squashfs、udf、vfat、fat、msdos、nfs、ceph、fuse、overlay、xfs
It can not be scanned automatically, please check it manually.
Use the following command to check the file system mounting status, such as cramfs.
| | Rationale: | Disabling mount support for unnecessary file systems can reduce
the attack surface and prevent attackers from attacking the system
by exploiting vulnerabilities in some uncommon file systems. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_removed_unnecessary_file_mount_support | | Identifiers and References | | |
|
Rule
Disable Modprobe Loading of USB Storage Driver
[ref] | To prevent USB storage devices from being used, configure the kernel module loading system
to prevent automatic loading of the USB storage driver.
To configure the system to prevent the usb-storage
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d:
install usb-storage /bin/true
This will prevent the modprobe program from loading the usb-storage
module, but will not prevent an administrator (or another program) from using the
insmod program to load the module manually. | | Rationale: | USB storage devices such as thumb drives can be used to introduce
malicious software. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_kernel_module_usb-storage_disabled | | Identifiers and References | References:
3.1.21, CCI-000366, CCI-000778, CCI-001958, 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.310(d)(1), 164.310(d)(2), 164.312(a)(1), 164.312(a)(2)(iv), 164.312(b), CM-7(a), CM-7(b), CM-6(a), MP-7, PR.AC-1, PR.AC-3, PR.AC-6, PR.AC-7, SRG-OS-000114-GPOS-00059, SRG-OS-000378-GPOS-0016, SRG-OS-000480-GPOS-00227, SR 1.1, SR 1.10, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.6, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, APO13.01, DSS01.04, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, A.11.2.6, A.13.1.1, A.13.2.1, A.18.1.4, A.6.2.1, A.6.2.2, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16, 5 | |
|
| Group
Verify Permissions on Important Files and
Directories
Group contains 1 group and 27 rules |
[ref]
Permissions for many files on a system must be set
restrictively to ensure sensitive information is properly protected.
This section discusses important
permission restrictions which can be verified
to ensure that no harmful discrepancies have
arisen. |
| Group
Verify Permissions on Files with Local Account Information and Credentials
Group contains 12 rules |
[ref]
The default restrictive permissions for files which act as
important security databases such as passwd, shadow,
group, and gshadow files must be maintained. Many utilities
need read access to the passwd file in order to function properly, but
read access to the shadow file allows malicious attacks against system
passwords, and should never be enabled. |
Rule
Verify Permissions on passwd File
[ref] |
To properly set the permissions of /etc/passwd, run the command:
$ sudo chmod 0644 /etc/passwd | | Rationale: | If the /etc/passwd file is writable by a group-owner or the
world the risk of its compromise is increased. The file contains the list of
accounts on the system and associated information, and protection of this file
is critical for system security. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_passwd | | Identifiers and References | References:
6.1.2, 5.5.2.2, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-8.7.c, SR 2.1, SR 5.2, 4.3.3.7.3, APO01.06, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
Rule
Verify User Who Owns shadow File
[ref] | To properly set the owner of /etc/shadow, run the command: $ sudo chown root /etc/shadow | | Rationale: | The /etc/shadow file contains the list of local
system accounts and stores password hashes. Protection of this file is
critical for system security. Failure to give ownership of this file
to root provides the designated owner with access to sensitive information
which could weaken the system security posture. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_shadow | | Identifiers and References | References:
6.1.3, 5.5.2.2, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-8.7.c, SR 2.1, SR 5.2, 4.3.3.7.3, APO01.06, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 12, 13, 14, 15, 16, 18, 3, 5, NT28(R36) | |
|
Rule
Verify Permissions on gshadow File
[ref] |
To properly set the permissions of /etc/gshadow, run the command:
$ sudo chmod 0000 /etc/gshadow | | Rationale: | The /etc/gshadow file contains group password hashes. Protection of this file
is critical for system security. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_gshadow | | Identifiers and References | References:
NT28(R36), 6.1.5, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, SR 2.1, SR 5.2, 4.3.3.7.3, APO01.06, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
Rule
Verify Group Who Owns passwd File
[ref] | To properly set the group owner of /etc/passwd, run the command: $ sudo chgrp root /etc/passwd | | Rationale: | The /etc/passwd file contains information about the users that are configured on
the system. Protection of this file is critical for system security. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_passwd | | Identifiers and References | References:
6.1.2, 5.5.2.2, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-8.7.c, SR 2.1, SR 5.2, 4.3.3.7.3, APO01.06, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
Rule
Verify Group Who Owns shadow File
[ref] | To properly set the group owner of /etc/shadow, run the command: $ sudo chgrp root /etc/shadow | | Rationale: | The /etc/shadow file stores password hashes. Protection of this file is
critical for system security. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_shadow | | Identifiers and References | References:
6.1.3, 5.5.2.2, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-8.7.c, SR 2.1, SR 5.2, 4.3.3.7.3, APO01.06, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
Rule
Verify Permissions on shadow File
[ref] |
To properly set the permissions of /etc/shadow, run the command:
$ sudo chmod 0000 /etc/shadow | | Rationale: | The /etc/shadow file contains the list of local
system accounts and stores password hashes. Protection of this file is
critical for system security. Failure to give ownership of this file
to root provides the designated owner with access to sensitive information
which could weaken the system security posture. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_shadow | | Identifiers and References | References:
NT28(R36), 6.1.3, 5.5.2.2, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-8.7.c, SR 2.1, SR 5.2, 4.3.3.7.3, APO01.06, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
Rule
Verify Group Who Owns group File
[ref] | To properly set the group owner of /etc/group, run the command: $ sudo chgrp root /etc/group | | Rationale: | The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_group | | Identifiers and References | References:
6.1.4, 5.5.2.2, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-8.7.c, SR 2.1, SR 5.2, 4.3.3.7.3, APO01.06, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
Rule
Verify User Who Owns passwd File
[ref] | To properly set the owner of /etc/passwd, run the command: $ sudo chown root /etc/passwd | | Rationale: | The /etc/passwd file contains information about the users that are configured on
the system. Protection of this file is critical for system security. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_passwd | | Identifiers and References | References:
6.1.2, 5.5.2.2, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-8.7.c, SR 2.1, SR 5.2, 4.3.3.7.3, APO01.06, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
Rule
Verify User Who Owns gshadow File
[ref] | To properly set the owner of /etc/gshadow, run the command: $ sudo chown root /etc/gshadow | | Rationale: | The /etc/gshadow file contains group password hashes. Protection of this file
is critical for system security. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_gshadow | | Identifiers and References | References:
6.1.5, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, SR 2.1, SR 5.2, 4.3.3.7.3, APO01.06, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 12, 13, 14, 15, 16, 18, 3, 5, NT28(R36) | |
|
Rule
Verify User Who Owns group File
[ref] | To properly set the owner of /etc/group, run the command: $ sudo chown root /etc/group | | Rationale: | The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_file_owner_etc_group | | Identifiers and References | References:
6.1.4, 5.5.2.2, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-8.7.c, SR 2.1, SR 5.2, 4.3.3.7.3, APO01.06, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
Rule
Verify Permissions on group File
[ref] |
To properly set the permissions of /etc/passwd, run the command:
$ sudo chmod 0644 /etc/passwd | | Rationale: | The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_etc_group | | Identifiers and References | References:
6.1.4, 5.5.2.2, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, Req-8.7.c, SR 2.1, SR 5.2, 4.3.3.7.3, APO01.06, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
Rule
Verify Group Who Owns gshadow File
[ref] | To properly set the group owner of /etc/gshadow, run the command: $ sudo chgrp root /etc/gshadow | | Rationale: | The /etc/gshadow file contains group password hashes. Protection of this file
is critical for system security. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_file_groupowner_etc_gshadow | | Identifiers and References | References:
6.1.5, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, SR 2.1, SR 5.2, 4.3.3.7.3, APO01.06, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
Rule
Opened Files Count Limited
[ref] |
It can not be scanned automatically, please check it manually.
The number of files that can be opened in Linux is limited. If all resources are occupied by a user, other users cannot open the file.
openEuler allows a user to open a maximum of 1024 file handles by default. If the number of file handles exceeds 1024,
new file handles cannot be opened. Low-privilege users can modify the value of 1024, but the upper limit 524288 cannot be exceed.
The root can modify the upper limit.
This parameter is set to a proper value to prevent all processes of a single user from opening too many file handles and exhausting system resources.
You can use below cli command to check the limitation:
- Check current limitation value:
# ulimit -Sn
1024
- Check current upper limitation value:
# ulimit -Hn
524288
| | Rationale: | None | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_opened_files_count_limited | | Identifiers and References | | |
|
Rule
Ensure No World-Writable Files Exist
[ref] | It is generally a good idea to remove global (other) write
access to a file when it is discovered. However, check with
documentation for specific applications before making changes.
Also, monitor for recurring world-writable files, as these may be
symptoms of a misconfigured application or user account. Finally,
this applies to real files and not virtual files that are a part of
pseudo file systems such as sysfs or procfs. | | Rationale: | Data in world-writable files can be modified by any
user on the system. In almost all circumstances, files can be
configured using a combination of user and group permissions to
support whatever legitimate access is needed without the risk
caused by world-writable files. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_unauthorized_world_writable | | Identifiers and References | References:
6.1.10, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, SR 2.1, SR 5.2, 4.3.3.7.3, APO01.06, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
Rule
Ensure All SGID Executables Are Authorized
[ref] | The SGID (set group id) bit should be set only on files that were
installed via authorized means. A straightforward means of identifying
unauthorized SGID files is determine if any were not installed as part of an
RPM package, which is cryptographically verified. Investigate the origin
of any unpackaged SGID files.
This configuration check considers authorized SGID files which were installed via RPM.
It is assumed that when an individual has sudo access to install an RPM
and all packages are signed with an organizationally-recognized GPG key,
the software should be considered an approved package on the system.
Any SGID file not deployed through an RPM will be flagged for further review. | | Rationale: | Executable files with the SGID permission run with the privileges of
the owner of the file. SGID files of uncertain provenance could allow for
unprivileged users to elevate privileges. The presence of these files should be
strictly controlled on the system. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_unauthorized_sgid | | Identifiers and References | References:
NT28(R37), NT28(R38), 6.1.14, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, SR 2.1, SR 5.2, 4.3.3.7.3, APO01.06, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
Rule
Ensure All Files Have Minimum Permission
[ref] |
It can not be scanned automatically, please check it manually.
According to the minimum permission requirements, the minimum access permission must be set for key files in the system,
especially files that contain sensitive information. Users with corresponding permissions can access the directory.
If the file or directory permission is incorrectly configured, the file information may leakage.
For example, if the access permission is set to 644 or greater, any user can access or even tamper with the data.
If the program's access permission is set to 755, as a result, any user can perform the operation,
which leads to privilege escalation risks.
Common types of files or directories that require access permission control are as follows:
- Executable files (binary files and scripts): directory for storing executable files.
Improper permission configuration may lead to privilege escalation attacks.
- Configuration files, key files, log files, data files that store sensitive information,
temporary files generated during system running, and static files.
These files may contain sensitive and private data. Improper permission configuration increases the risk of information leakage.
The basic principles of permission control are as follows:
| File Type | Suggested Permission |
|---|
| Home Directory | 750(rwxr-x---) | | Programs(Include bash, library) | 550(r-xr-x---) | | Programs Directory | 550(r-xr-x---) | | Configuration Files | 640(rw-r-----) | | Configuration Files Directory | 750(rwxr-x---) | | Log Files(Archived) | 440(r--r-----) | | Log Files(Recording) | 640(rw-r-----) | | Log Files Directory | 750(rwxr-x---) | | Debug Files | 640(rw-r-----) | | Debug Files Directory | 750(rwxr-x---) | | Temporary Files Directory | 750(rwxr-x---) | | Upgrading Files Directory | 770(rwxrwx---) | | Data Files | 640(rw-r-----) | | Data Files Directory | 750(rwxr-x---) | | Directory Of Crypto Component, Private Key, Certificate, Encrypted Data | 700(rwx------) | | Crypto Component, Private Key, Certificate, Encrypted Data | 600(rw-------) | | Interface or Shell Files Of Crypto | 500(r-x------) |
Generally, a non-root user is used to perform services. This user needs to access necessary directories in the Linux system and files.
Therefore, permission control can be relaxed for system directories, configuration files, executable files,
and certificate files that the system depends on.
The system is consistent with the general release in the industry. The suggestions are as follows:
| File Type | Suggested Permission |
|---|
| Directory | 755(rwxr-xr-x) | | Programs(Include bash, library) | 755(rwxr-xr-x) | | Configuration Files | 644(rw-r--r--) | | Certificate Files(No Private Key) | 444(r--r--r--) |
| | Rationale: | The permission cannot be too high or too low. For example, if the permission of some system configuration files is set to 600 or 640,
common users cannot read the configuration files, the corresponding program may not be executed
because it does not have the permission to read the configuration. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_ensure_minimum_permission | | Identifiers and References | | |
|
Rule
Ensure All Symlink Files Have Canonical Path
[ref] |
It can not be scanned automatically, please check it manually.
If any symlink files have no camonical path, it should be removed.
- You can use below cli command to find out all symlink files which have no canonical path under current path:
# find ./ -type l -follow
- Or find it under root path bug exclude some dirs:
# find / -path /var -prune -o -path /run -prune -o -path /proc -prune -o -path /sys -prune -o -path /dev -prune -o -type l -follow
- Or find it under the whole disk partition:
# find / -xdev -type l -follow
| | Rationale: | If any symlink files have no camonical path, it should be removed. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_no_empty_symlink_files | | Identifiers and References | | |
|
Rule
Ensure the user PATH variable is strictly defined
[ref] | The PATH variable under Linux defines the search path for executable files
in the current user context. For example, if the user uses the ls command
in any directory, the system will search for the ls command in the directory
specified by the PATH variable and execute it after finding it. The PATH
variable in all user contexts cannot contain the current directory "." .The
directory must be a path that actually exists in the file system and meets
the design expectations of the system. The correct PATH value can effectively
prevent system commands from being replaced by malicious instructions and
ensure that system commands can be executed safely.
So the PATH variable should be defined to the correct value, and the openEuler
system default setting is:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
PATH can be modified according to the actual scenario, but be sure to make sure
it is correct.
It can not be scanned automatically, please check it manually.
Use the echo command to print out the value of PATH in the current user context and check whether it is correct.
- The PATH value in the openEuler root user context is as follows:
$ echo $PATH
- The PATH value in the openEuler ordinary user test context is as follows：
$ echo $PATH
| | Rationale: | none. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_define_path_strictly | | Identifiers and References | | |
|
Rule
Verify that All World-Writable Directories Have Sticky Bits Set
[ref] | When the so-called 'sticky bit' is set on a directory,
only the owner of a given file may remove that file from the
directory. Without the sticky bit, any user with write access to a
directory may remove any file in the directory. Setting the sticky
bit prevents users from removing each other's files. In cases where
there is no reason for a directory to be world-writable, a better
solution is to remove that permission rather than to set the sticky
bit. However, if a directory is used by a particular application,
consult that application's documentation instead of blindly
changing modes.
To set the sticky bit on a world-writable directory DIR, run the
following command:
$ sudo chmod +t DIR | | Rationale: | Failing to set the sticky bit on public directories allows unauthorized
users to delete files in the directory structure.
The only authorized public directories are those temporary directories
supplied with the system, or those designed to be temporary file
repositories. The setting is normally reserved for directories used by the
system, by users for temporary file storage (such as /tmp), and
for directories requiring global read/write access. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_dir_perms_world_writable_sticky_bits | | Identifiers and References | References:
1.1.21, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, SR 2.1, SR 5.2, 4.3.3.7.3, APO01.06, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
Rule
Enable Kernel Parameter to Enforce DAC on Hardlinks
[ref] | To set the runtime status of the fs.protected_hardlinks kernel parameter, run the following command: $ sudo sysctl -w fs.protected_hardlinks=1
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: fs.protected_hardlinks = 1 | | Rationale: | By enabling this kernel parameter, users can no longer create soft or hard links to
files which they do not own. Disallowing such hardlinks mitigate vulnerabilities
based on insecure file system accessed by privileged programs, avoiding an
exploitation vector exploiting unsafe use of open() or creat(). | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_fs_protected_hardlinks | | Identifiers and References | References:
NT28(R23), 1.6.1, CM-6(a), AC-6(1), SRG-OS-000324-GPOS-00125 | |
|
Rule
Disallow globally writable files
[ref] | Globally writable means that all users can write to the file, but usually this
permission is not necessary. If a file is unreasonably set with globally writable
permissions, it can easily be tampered with by attackers, leading to security risks.
Therefore, if the file must have globally writable permissions, the security risks
need to be analyzed based on actual scenarios to ensure that attackers cannot use
this file to carry out attacks.
You can search for globally writable files in the root directory. The exceptions
are: There are a large number of globally writable files in the two system directories
"/sys" and "/proc" when Linux is running, so these two should be excluded when checking
directory to avoid confusion.
It can not be scanned automatically, please check it manually.
Check globally writable files（directories "/sys" and "/proc" have been excluded）.
| | Rationale: | none. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_no_files_globally_writable_files | | Identifiers and References | | |
|
Rule
Ensure All SUID Executables Are Authorized
[ref] | The SUID (set user id) bit should be set only on files that were
installed via authorized means. A straightforward means of identifying
unauthorized SUID files is determine if any were not installed as part of an
RPM package, which is cryptographically verified. Investigate the origin
of any unpackaged SUID files.
This configuration check considers authorized SUID files which were installed via RPM.
It is assumed that when an individual has sudo access to install an RPM
and all packages are signed with an organizationally-recognized GPG key,
the software should be considered an approved package on the system.
Any SUID file not deployed through an RPM will be flagged for further review. | | Rationale: | Executable files with the SUID permission run with the privileges of
the owner of the file. SUID files of uncertain provenance could allow for
unprivileged users to elevate privileges. The presence of these files should be
strictly controlled on the system. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_unauthorized_suid | | Identifiers and References | References:
NT28(R37), NT28(R38), 6.1.13, CM-6(a), AC-6(1), PR.AC-4, PR.DS-5, SR 2.1, SR 5.2, 4.3.3.7.3, APO01.06, DSS05.04, DSS05.07, DSS06.02, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
Rule
Make sure the LD_LIBRARY_PATH variable is defined correctly
[ref] | LD_LIBRARY_PATH is a Linux environment variable. When a program loads a
dynamic link library, it will first obtain it from the path specified by
this environment variable. Normally, this environment variable should
not be set. If it is maliciously set to an incorrect value, the program
may be linked to an incorrect dynamic library when running, resulting in
security risks. Note: The configuration in /etc/ld.so.conf.d will also
affect dynamic library loading, so you need to ensure correct configuration.
openEuler does not set this variable by default. According to the actual
scenario, if LD_LIBRARY_PATH must be set, you need to ensure that the
value is correct in all user contexts.
It can not be scanned automatically, please check it manually.
There are multiple configuration files that can permanently set the LD_LIBRARY_PATH
value, which need to be investigated. These files include: /etc/profile, ~/.bashrc, ~/.bash_profile.
The latter two files are files in the user's home directory. Each user Yes, be
sure not to miss it during inspection.
| | Rationale: | none. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_define_ld_lib_path_correctly | | Identifiers and References | | |
|
Rule
Enable Kernel Parameter to Enforce DAC on Symlinks
[ref] | To set the runtime status of the fs.protected_symlinks kernel parameter, run the following command: $ sudo sysctl -w fs.protected_symlinks=1
If this is not the system default value, add the following line to a file in the directory /etc/sysctl.d: fs.protected_symlinks = 1 | | Rationale: | By enabling this kernel parameter, symbolic links are permitted to be followed
only when outside a sticky world-writable directory, or when the UID of the
link and follower match, or when the directory owner matches the symlink's owner.
Disallowing such symlinks helps mitigate vulnerabilities based on insecure file system
accessed by privileged programs, avoiding an exploitation vector exploiting unsafe use of
open() or creat(). | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sysctl_fs_protected_symlinks | | Identifiers and References | References:
NT28(R23), 1.6.1, CM-6(a), AC-6(1), SRG-OS-000324-GPOS-00125 | |
|
Rule
Ensure All Executable Files are not hidden
[ref] | Find out all hidden executable files from system. | | Rationale: | If a executable file is hidden, it maybe will introduce risks, since it can not be fould easily | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_no_hide_exec_files | | Identifiers and References | | |
|
Rule
Ensure All Files Are Owned by a User
[ref] | If any files are not owned by a user, then the
cause of their lack of ownership should be investigated.
Following this, the files should be deleted or assigned to an
appropriate user. | | 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. The files should be repaired so they
will not cause problems when accounts are created in the future,
and the cause should be discovered and addressed. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_no_files_unowned_by_user | | Identifiers and References | References:
6.1.11, CCI-002165, CM-6(a), AC-6(1), PR.AC-4, PR.AC-6, PR.DS-5, PR.IP-1, PR.PT-3, SRG-OS-000480-GPOS-00227, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 5.2, SR 7.6, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, APO01.06, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.03, DSS06.06, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.2, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 11, 12, 13, 14, 15, 16, 18, 3, 5, 9 | |
|
Rule
Ensure All Files Are Owned by a Group
[ref] | If any files are not owned by a group, then the
cause of their lack of group-ownership should be investigated.
Following this, the files should be deleted or assigned to an
appropriate group. | | 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. The files should be repaired so they
will not cause problems when accounts are created in the future,
and the cause should be discovered and addressed. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_file_permissions_ungroupowned | | Identifiers and References | References:
6.1.12, CCI-002165, CM-6(a), AC-6(1), PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.DS-5, PR.PT-3, SRG-OS-000480-GPOS-00227, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 5.2, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, APO01.06, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.02, DSS06.03, DSS06.06, DSS06.10, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.18.1.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
| Group
Restrict Partition Mount Options
Group contains 6 rules |
[ref]
System partitions can be mounted with certain options
that limit what files on those partitions can do. These options
are set in the /etc/fstab configuration file, and can be
used to make certain types of malicious behavior more difficult. |
Rule
Mounting in nodev mode does not require mounting the device
[ref] | nodev means that device files are not allowed to be mounted, which is used
to reduce the attack surface and increase security. When the directory is
mounted, if the nodev option is set, all block devices, character devices
and other device files in the directory will be parsed into ordinary files
and cannot be operated on device files. If nodev is not set when mounting,
it will lead to security risks. For example, an attacker creates a file system
on the USB flash drive and creates a block device file in it (his own USB flash
drive, with corresponding permissions), and this block The device actually
points to the server hard disk or partition such as /dev/sda. If an attacker
has the opportunity to insert a USB flash drive into the server and the server
loads the USB flash drive, the attacker can access the corresponding file through
this block device file. Hard drive data. If the U disk in the above case is changed
to another hard disk or partition, a similar problem will exist. As long as there
is a maliciously constructed device file on the hard disk or partition, an attack
can be formed.
The following directories are mounted by nodev by default in the openEuler system:
/sys、/proc、/sys/kernel/security、/dev/shm、/run、/sys/fs/cgroup、/sys/fs/cgroup/systemd、
/sys/fs/pstore、/sys/fs/bpf、/sys/fs/cgroup/files、/sys/fs/cgroup/net_cls,net_prio、
/sys/fs/cgroup/devices、/sys/fs/cgroup/freezer、/sys/fs/cgroup/cpu,cpuacct、/sys/fs/cgroup/perf_event、
/sys/fs/cgroup/pids、/sys/fs/cgroup/hugetlb、/sys/fs/cgroup/memory、/sys/fs/cgroup/blkio、
/sys/fs/cgroup/cpuset、/sys/fs/cgroup/rdma、/sys/kernel/config、/sys/kernel/debug、/dev/mqueue、
/tmp、/run/user/0
penEuler has the following directories (some directories vary depending on hard disk partitions
and deployment platforms). These directories are not mounted by nodev by default:
/dev、/dev/pts、/、/sys/fs/selinux、/proc/sys/fs/binfmt_misc、/dev/hugepages、/boot、
/var/lib/nfs/rpc_pipefs、/boot/efi、/home
In actual scenarios, based on business needs, the nodev method is used to mount partitions
that do not require device mounting.
It can not be scanned automatically, please check it manually.
| | Rationale: | | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_partitions_mounted_nodev_mode | | Identifiers and References | | |
|
Rule
Partitions that do not need to be modified are mounted read-only.
[ref] | Mounting file systems that do not require data modification in read-only mode can
avoid unintentional or malicious data tampering and reduce the attack surface.
It can not be scanned automatically, please check it manually.
| | Rationale: | | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_read_only_partitions_no_modified | | Identifiers and References | | |
|
Rule
Make sure the removable partition is mounted in noexec/nodev mode
[ref] | Removable devices themselves are uncertain, and their origin, past usage,
and transportation processes cannot guarantee absolute safety. Therefore,
removable devices are often the main host devices for virus transmission.
Therefore, for removable devices, it is required to mount them in noexec
or nodev mode to improve security and reduce the attack surface.
noexec can prevent files on removable devices from being directly executed,
such as virus files, attack scripts, etc;
nodev prevents incorrect device files on removable devices from being linked
to real devices on the server, leading to attacks;
Common removable devices such as: CD/DVD/USB, etc.
It can not be scanned automatically, please check it manually.
| | Rationale: | | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_partitoin_mounted_noexec_or_nodev | | Identifiers and References | | |
|
Rule
Hard drive data should be managed in partitions
[ref] | When installing the operating system, the operating system data and business data
partitions should be managed according to the characteristics of the actual scenario
to avoid placing all data on one hard disk or partition. Proper planning of hard disk
partitions can avoid or reduce the following risks:
The log file is too large, causing the business or system data disk to become full;
The home directory of ordinary accounts is too large, causing the system or business disk to become full;
The system partition is not independent, causing the basic service of the operating system to fail when the disk is full, causing a full-scale DOS attack;
It is not conducive to minimizing permissions and encrypting data disks;
It is not conducive to system or data recovery after the disk is damaged.
As a general operating system, openEuler installs separate partitions "/boot, /tmp,
/home, /" by default. It is recommended to determine the partition mounting and size
of other directories based on the actual scenario.
It can not be scanned automatically, please check it manually.
| | Rationale: | none. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_partitions_manage_hard_drive_data | | Identifiers and References | | |
|
Rule
Mount a partition without executable files in noexec mode
[ref] | The data disk is only used to save data during system operation. There
is no need to execute relevant commands on the data disk. In this case,
the hard disk or partition must be mounted in noexec mode to improve security
and reduce the attack surface.
It can not be scanned automatically, please check it manually.
| | Rationale: | | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_partitions_mounted_noexec_mode | | Identifiers and References | | |
|
Rule
Make sure partitions that do not require SUID/SGID are mounted in nosuid mode
[ref] | After the SUID bit is set on an executable file, even if the user executing the file
is not the owner of the file, the process will be temporarily granted the permissions
of the file owner during execution. For example, the ordinary user test executes a
program with permissions 755 and owner root. If the program does not set the SUID bit,
the process only has the permissions of the test user; if the SUID is set, the process
has root permissions during execution. . SGID has a similar function, but it only has
the permissions of the group to which the file belongs. For partitions that do not
need SUID/SGID, use the nosuid method to mount them. This can invalidate the S bit of
files with SUID/SGID in the partition, prevent privilege escalation through the
executable files of the partition, and strengthen the security of the partition.
Users need to plan each mounted hard drive and partition and set nosuid mounting items
based on actual scenarios.
It can not be scanned automatically, please check it manually.
| | Rationale: | | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_partitions_mounted_nosuid_mode | | Identifiers and References | | |
|
| Group
Services
Group contains 35 groups and 49 rules |
[ref]
The best protection against vulnerable software is running less software. This section describes how to review
the software which openEuler 22.03 LTS installs on a system and disable software which is not needed. It
then enumerates the software packages installed on a default openEuler 22.03 LTS system and provides guidance about which
ones can be safely disabled.
openEuler 22.03 LTS provides a convenient minimal install option that essentially installs the bare necessities for a functional
system. When building openEuler 22.03 LTS systems, it is highly recommended to select the minimal packages and then build up
the system from there. |
| Group
Obsolete Services
Group contains 3 groups and 5 rules |
[ref]
This section discusses a number of network-visible
services which have historically caused problems for system
security, and for which disabling or severely limiting the service
has been the best available guidance for some time. As a result of
this, many of these services are not installed as part of openEuler 22.03 LTS
by default.
Organizations which are running these services should
switch to more secure equivalents as soon as possible.
If it remains absolutely necessary to run one of
these services for legacy reasons, care should be taken to restrict
the service as much as possible, for instance by configuring host
firewall software such as iptables to restrict access to the
vulnerable service to only those remote hosts which have a known
need to use it. |
| Group
NIS
Group contains 2 rules |
[ref]
The Network Information Service (NIS), also known as 'Yellow
Pages' (YP), and its successor NIS+ have been made obsolete by
Kerberos, LDAP, and other modern centralized authentication
services. NIS should not be used because it suffers from security
problems inherent in its design, such as inadequate protection of
important authentication information. |
Rule
Remove NIS Client
[ref] | The Network Information Service (NIS), formerly known as Yellow Pages,
is a client-server directory service protocol used to distribute system configuration
files. The NIS client (ypbind) was used to bind a system to an NIS server
and receive the distributed configuration files. | | Rationale: | The NIS service is inherently an insecure system that has been vulnerable
to DOS attacks, buffer overflows and has poor authentication for querying
NIS maps. NIS generally has been replaced by such protocols as Lightweight
Directory Access Protocol (LDAP). It is recommended that the service be
removed. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_package_ypbind_removed | | Identifiers and References | References:
2.3.1, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii) | |
|
Rule
Uninstall ypserv Package
[ref] | The ypserv package can be removed with the following command:
$ sudo dnf erase ypserv | | Rationale: | The NIS service provides an unencrypted authentication service which does
not provide for the confidentiality and integrity of user passwords or the
remote session.
Removing the ypserv package decreases the risk of the accidental
(or intentional) activation of NIS or NIS+ services. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_package_ypserv_removed | | Identifiers and References | References:
2.2.16, CCI-000381, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), CM-7(a), CM-7(b), CM-6(a), IA-5(1)(c), PR.AC-3, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000095-GPOS-00049, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.04, DSS05.02, DSS05.03, DSS05.05, DSS06.06, A.11.2.6, A.12.1.2, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.2.1, A.6.2.2, A.9.1.2, 11, 12, 14, 15, 3, 8, 9 | |
|
| Group
Telnet
Group contains 1 rule |
[ref]
The telnet protocol does not provide confidentiality or integrity
for information transmitted on the network. This includes authentication
information such as passwords. Organizations which use telnet should be
actively working to migrate to a more secure protocol. |
Rule
Remove telnet Clients
[ref] | The telnet client allows users to start connections to other systems via
the telnet protocol. | | Rationale: | The telnet protocol is insecure and unencrypted. The use
of an unencrypted transmission medium could allow an unauthorized user
to steal credentials. The ssh package provides an
encrypted session and stronger security and is included in openEuler 22.03 LTS. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_package_telnet_removed | | Identifiers and References | References:
2.3.4, 3.1.13, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), A.8.2.3, A.13.1.1, A.13.2.1, A.13.2.3, A.14.1.2, A.14.1.3 | |
|
| Group
TFTP Server
Group contains 2 rules |
[ref]
TFTP is a lightweight version of the FTP protocol which has
traditionally been used to configure networking equipment. However,
TFTP provides little security, and modern versions of networking
operating systems frequently support configuration via SSH or other
more secure protocols. A TFTP server should be run only if no more
secure method of supporting existing equipment can be
found. |
Rule
Uninstall tftp-server Package
[ref] | The tftp-server package can be removed with the following command: $ sudo dnf erase tftp-server | | Rationale: | Removing the tftp-server package decreases the risk of the accidental
(or intentional) activation of tftp services.
If TFTP is required for operational support (such as transmission of router
configurations), its use must be documented with the Information Systems
Securty Manager (ISSM), restricted to only authorized personnel, and have
access control rules established. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_package_tftp-server_removed | | Identifiers and References | References:
CCI-000318, CCI-000368, CCI-001812, CCI-001813, CCI-001814, CM-7(a), CM-7(b), CM-6(a), PR.AC-3, PR.IP-1, PR.PT-3, PR.PT-4, SRG-OS-000480-GPOS-00227, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, APO13.01, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS01.04, DSS05.02, DSS05.03, DSS05.05, DSS06.06, A.11.2.6, A.12.1.2, A.12.5.1, A.12.6.2, A.13.1.1, A.13.2.1, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.2.1, A.6.2.2, A.9.1.2, 11, 12, 14, 15, 3, 8, 9 | |
|
Rule
Remove tftp Daemon
[ref] | Trivial File Transfer Protocol (TFTP) is a simple file transfer protocol,
typically used to automatically transfer configuration or boot files between systems.
TFTP does not support authentication and can be easily hacked. The package
tftp is a client program that allows for connections to a tftp server. | | Rationale: | It is recommended that TFTP be removed, unless there is a specific need
for TFTP (such as a boot server). In that case, use extreme caution when configuring
the services. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_package_tftp_removed | | Identifiers and References | | |
|
| Group
DHCP
Group contains 1 group and 1 rule |
[ref]
The Dynamic Host Configuration Protocol (DHCP) allows
systems to request and obtain an IP address and other configuration
parameters from a server.
This guide recommends configuring networking on clients by manually editing
the appropriate files under /etc/sysconfig. Use of DHCP can make client
systems vulnerable to compromise by rogue DHCP servers, and should be avoided
unless necessary. If using DHCP is necessary, however, there are best practices
that should be followed to minimize security risk. |
| Group
Disable DHCP Server
Group contains 1 rule |
[ref]
The DHCP server dhcpd is not installed or activated by
default. If the software was installed and activated, but the
system does not need to act as a DHCP server, it should be disabled
and removed. |
Rule
Disable DHCP Service
[ref] | The dhcpd service should be disabled on
any system that does not need to act as a DHCP server.
The dhcpd service can be disabled with the following command:
$ sudo systemctl disable dhcpd.service
The dhcpd service can be masked with the following command:
$ sudo systemctl mask dhcpd.service | | Rationale: | Unmanaged or unintentionally activated DHCP servers may provide faulty information
to clients, interfering with the operation of a legitimate site
DHCP server if there is one. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_service_dhcpd_disabled | | Identifiers and References | References:
2.2.5, CCI-000366, CM-7(a), CM-7(b), CM-6(a), PR.IP-1, PR.PT-3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2, 11, 14, 3, 9 | |
|
| Group
LDAP
Group contains 2 groups and 2 rules |
[ref]
LDAP is a popular directory service, that is, a
standardized way of looking up information from a central database.
openEuler 22.03 LTS includes software that enables a system to act as both
an LDAP client and server. |
| Group
Configure OpenLDAP Server
Group contains 1 rule |
[ref]
This section details some security-relevant settings
for an OpenLDAP server. |
Rule
Uninstall openldap-servers Package
[ref] | The openldap-servers RPM is not installed by default on a openEuler 22.03 LTS
system. It is needed only by the OpenLDAP server, not by the
clients which use LDAP for authentication. If the system is not
intended for use as an LDAP Server it should be removed. | | Rationale: | Unnecessary packages should not be installed to decrease the attack
surface of the system. While this software is clearly essential on an LDAP
server, it is not necessary on typical desktop or workstation systems. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_package_openldap-servers_removed | | Identifiers and References | References:
CCI-000366, CM-7(a), CM-7(b), CM-6(a), PR.IP-1, PR.PT-3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2, 11, 14, 3, 9 | |
|
| Group
Configure OpenLDAP Clients
Group contains 1 rule |
[ref]
This section provides information on which security settings are
important to configure in OpenLDAP clients by manually editing the appropriate
configuration files. openEuler 22.03 LTS provides an automated configuration tool called
authconfig and a graphical wrapper for authconfig called
system-config-authentication. However, these tools do not provide as
much control over configuration as manual editing of configuration files. The
authconfig tools do not allow you to specify locations of SSL certificate
files, which is useful when trying to use SSL cleanly across several protocols.
Installation and configuration of OpenLDAP on openEuler 22.03 LTS is available at Warning:
Before configuring any system to be an
LDAP client, ensure that a working LDAP server is present on the
network. |
Rule
Remove LDAP Client
[ref] | LDAP (Lightweight Directory Access Protocol) is a lightweight directory
access protocol that provides access control and maintains distributed
directory information. | | Rationale: | Providing an LDAP client (openldap-clients) in the system can cause
waste of system resources and expand the scope of attacks. If the business
scenario does not require the use of LDAP services, it is prohibited to
install the LDAP client. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_package_openldap-clients_removed | | Identifiers and References | | |
|
| Group
NFS and RPC
Group contains 4 groups and 2 rules |
[ref]
The Network File System is a popular distributed filesystem for
the Unix environment, and is very widely deployed. This section discusses the
circumstances under which it is possible to disable NFS and its dependencies,
and then details steps which should be taken to secure
NFS's configuration. This section is relevant to systems operating as NFS
clients, as well as to those operating as NFS servers. |
| Group
Configure NFS Clients
Group contains 1 group and 1 rule |
[ref]
The steps in this section are appropriate for systems which operate as NFS clients. |
| Group
Disable NFS Server Daemons
Group contains 1 rule |
[ref]
There is no need to run the NFS server daemons nfs and
rpcsvcgssd except on a small number of properly secured systems
designated as NFS servers. Ensure that these daemons are turned off on
clients. |
Rule
Disable Network File System (nfs) Service
[ref] | Network File System (NFS) is one of the oldest and most widely distributed
file systems in UNIX environments. It provides the system with the ability
to mount other servers' file systems over the network. If the system does
not export NFS shares, it is recommended to disable NFS to reduce the remote
attack surface..
The nfs-server service can be disabled with the following command:
$ sudo systemctl disable nfs-server.service
The nfs-server service can be masked with the following command:
$ sudo systemctl mask nfs-server.service | | Rationale: | 'Disabling NFS affects services and applications on the system that rely on NFS,
as well as existing NFS mount points. Before disabling NFS, you should make sure
you understand the usage on your system and consider whether there are alternatives
to meet your file sharing and data access needs.' | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_service_nfs-server_disabled | | Identifiers and References | | |
|
| Group
Disable All NFS Services if Possible
Group contains 1 group and 1 rule |
[ref]
If there is not a reason for the system to operate as either an
NFS client or an NFS server, follow all instructions in this section to disable
subsystems required by NFS. Warning:
The steps in this section will prevent a system
from operating as either an NFS client or an NFS server. Only perform these
steps on systems which do not need NFS at all. |
| Group
Disable Services Used Only by NFS
Group contains 1 rule |
[ref]
If NFS is not needed, disable the NFS client daemons nfslock, rpcgssd, and rpcidmapd.
All of these daemons run with elevated privileges, and many listen for network
connections. If they are not needed, they should be disabled to improve system
security posture. |
Rule
Disable rpcbind Service
[ref] | The rpcbind utility maps RPC services to the ports on which they listen.
RPC processes notify rpcbind when they start, registering the ports they
are listening on and the RPC program numbers they expect to serve. The
rpcbind service redirects the client to the proper port number so it can
communicate with the requested service. If the system does not require RPC
(such as for NFS servers) then this service should be disabled.
The rpcbind service can be disabled with the following command:
$ sudo systemctl disable rpcbind.service
The rpcbind service can be masked with the following command:
$ sudo systemctl mask rpcbind.service | | Rationale: | | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_service_rpcbind_disabled | | Identifiers and References | References:
2.2.7 | |
|
| Group
SSH Server
Group contains 1 group and 23 rules |
[ref]
The SSH protocol is recommended for remote login and
remote file transfer. SSH provides confidentiality and integrity
for data exchanged between two systems, as well as server
authentication, through the use of public key cryptography. The
implementation included with the system is called OpenSSH, and more
detailed documentation is available from its website,
http://www.openssh.org.
Its server program is called sshd and provided by the RPM package
openssh-server. |
| Group
Configure OpenSSH Server if Necessary
Group contains 23 rules |
[ref]
If the system needs to act as an SSH server, then
certain changes should be made to the OpenSSH daemon configuration
file /etc/ssh/sshd_config. The following recommendations can be
applied to this file. See the sshd_config(5) man page for more
detailed information. |
Rule
Use Only Strong Key Exchange algorithms
[ref] | Limit the Key Exchange to strong algorithms. | | Rationale: | Key exchange is any method in cryptography by which cryptographic keys are exchanged
between two parties, allowing use of a cryptographic algorithm. If the sender and receiver
wish to exchange encrypted messages, each must be equipped to encrypt messages to be
sent and decrypt messages received | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_use_strong_kex | | Identifiers and References | | |
|
Rule
SSH concurrent unauthenticated connections should be configured correctly
[ref] | Attackers can consume system resources by establishing a large number of
concurrent connections with incomplete authentication without knowing the
password.
Use the grep command to view the configuration.
| | Rationale: | The MaxStartups setting specifies the maximum number of concurrent unauthenticated
connections to the SSH daemon. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_concurrent_unauthenticated_connections | | Identifiers and References | | |
|
Rule
Does not allow the use of X11 Forwarding
[ref] | The X11 Forwarding feature of SSH allows for the execution of GUI programs for remote
hosts on the local host. If not required in the business scenario, this feature must
be disabled.
Use the grep command to view the configuration.
| | Rationale: | Enabling the X11 Forwarding function expands the scope of attacks and poses a possibility
of being attacked by other users on the X11 server. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_disable_x11_forwarding | | Identifiers and References | | |
|
Rule
Disable SSH Access via Empty Passwords
[ref] | To explicitly disallow SSH login from accounts with
empty passwords, add or correct the following line in /etc/ssh/sshd_config:
PermitEmptyPasswords no
Any accounts with empty passwords should be disabled immediately, and PAM configuration
should prevent users from being able to assign themselves empty passwords. | | Rationale: | Configuring this setting for the SSH daemon provides additional assurance
that remote login via SSH will require a password, even in the event of
misconfiguration elsewhere. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_disable_empty_passwords | | Identifiers and References | References:
NT007(R17), 5.2.9, 5.5.6, 3.1.1, 3.1.5, CCI-000366, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), AC-17(a), CM-7(a), CM-7(b), CM-6(a), PR.AC-4, PR.AC-6, PR.DS-5, PR.IP-1, PR.PT-3, FIA_AFL.1, SRG-OS-000480-GPOS-00229, SRG-OS-000480-VMM-002000, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 5.2, SR 7.6, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, APO01.06, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.02, DSS06.03, DSS06.06, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.12.1.2, A.12.5.1, A.12.6.2, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.14.2.2, A.14.2.3, A.14.2.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 11, 12, 13, 14, 15, 16, 18, 3, 5, 9 | |
|
Rule
Use Only Strong Ciphers
[ref] | Limit the ciphers to strong algorithms.
Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode.
The following line in /etc/ssh/sshd_config
demonstrates use of those ciphers:
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
The man page sshd_config(5) contains a list of supported ciphers. | | Rationale: | Based on research conducted at various institutions, it was determined that the symmetric
portion of the SSH Transport Protocol (as described in RFC 4253) has security weaknesses
that allowed recovery of up to 32 bits of plaintext from a block of ciphertext that was
encrypted with the Cipher Block Chaining (CBD) method. From that research, new Counter
mode algorithms (as described in RFC4344) were designed that are not vulnerable to these
types of attacks and these algorithms are now recommended for standard use. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_use_strong_ciphers | | Identifiers and References | | |
|
Rule
Prohibit SSH service pre setting authorized_Keys
[ref] | Authorized_ Keys is the public key of the remote host, which users can
store in their home directory $HOME/. ssh/authorized_ In the keys file,
for public key authentication, you can directly log in to the system.
Use the grep command to view the configuration. If the return value is empty, it means authorized_keys is not preset:
| | Rationale: | If authorized is preset in the system_ Keys, and the server has enabled
the login method of public and private key authentication, allowing
attackers to bypass authentication and directly log in to the specified
system to attack it. So authorized cannot be preset in the system_ Keys. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_prohibit_preset_authorized_keys | | Identifiers and References | | |
|
Rule
SSH service interface should be configured correctly
[ref] | Generally, the server has multiple network cards and multiple
IP addresses. IP addresses should be planned for business and
management. Therefore, not every IP address needs to listen for
SSH connections. You can configure to limit SSH connections to
only specified IP addresses to reduce the attack surface.
If the listening address has been configured, you can query the corresponding configuration through the grep command.
| | Rationale: | Unconfigured IP addresses cannot connect to the server through SSH.
It is recommended to plan and configure according to the actual situation. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_configure_correct_interface | | Identifiers and References | | |
|
Rule
Use Only Strong MACs
[ref] | Limit the MACs to strong hash algorithms.
The following line in /etc/ssh/sshd_config demonstrates use
of those MACs:
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160 | | Rationale: | MD5 and 96-bit MAC algorithms are considered weak and have been shown to increase
exploitability in SSH downgrade attacks. Weak algorithms continue to have a great deal of
attention as a weak spot that can be exploited with expanded computing power. An
attacker that breaks the algorithm could take advantage of a MiTM position to decrypt the
SSH tunnel and capture credentials and information | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_use_strong_macs | | Identifiers and References | | |
|
Rule
The allowed number of concurrent sessions for a single SSH connection should be configured correctly
[ref] | SSH allows clients that support multiplexing to establish multiple sessions
based on a single network connection. MaxSessions limits the number of SSH
concurrent sessions allowed for each network connection, which can prevent
system resources from being unlimited occupied by a single or a few connections,
leading to denial of service attacks.
Use the grep command to view the configuration.
| | Rationale: | Setting MaxSessions to 1 will disable session multiplexing, meaning that only
one session is allowed for a connection, while setting it to 0 will block all
connected sessions. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_configure_concurrent_sessions | | Identifiers and References | | |
|
Rule
Use Only Strong Algorithms For Public Key
[ref] | Limit the algorithm of public key to strong algorithms. | | Rationale: | Week algorithms will introduce risks. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_use_strong_pubkey | | Identifiers and References | | |
|
Rule
Not Use User Known Hosts
[ref] | SSH can allow system users to connect to systems if a cache of the remote
systems public keys is available. This should be disabled.
To ensure this behavior is disabled, add or correct the
following line in /etc/ssh/sshd_config:
IgnoreUserKnownHosts yes
Or remove the files of known_hosts from /root and /home directory. | | Rationale: | Configuring this setting for the SSH daemon provides additional
assurance that remove login via SSH will require a password, even
in the event of misconfiguration elsewhere. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_disable_user_known_hosts_ex | | Identifiers and References | | |
|
Rule
LoginGraceTime should be configured correctly
[ref] | LoginGraceTime is used to limit the user's login time. If the user
fails to complete the login action within the time limit specified
by LoginGraceTime, the connection will be automatically disconnected.
Use the grep command to view the configuration.
| | Rationale: | It is recommended to set this value to less than or equal to 60 seconds.
If the value is set too high, attackers can utilize a large number of
incomplete login actions to consume server resources, resulting in normal
administrator login failures. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_configure_correct_LoginGraceTime | | Identifiers and References | | |
|
Rule
Disable SSH Support for .rhosts Files
[ref] | SSH can emulate the behavior of the obsolete rsh
command in allowing users to enable insecure access to their
accounts via .rhosts files.
To ensure this behavior is disabled, add or correct the
following line in /etc/ssh/sshd_config:
IgnoreRhosts yes | | Rationale: | SSH trust relationships mean a compromise on one host
can allow an attacker to move trivially to other hosts. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_disable_rhosts | | Identifiers and References | References:
5.2.6, 5.5.6, 3.1.12, CCI-000366, AC-17(a), CM-7(a), CM-7(b), CM-6(a), PR.AC-4, PR.AC-6, PR.IP-1, PR.PT-3, FIA_AFL.1, SRG-OS-000480-GPOS-00227, SRG-OS-000107-VMM-000530, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.03, DSS06.06, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 11, 12, 14, 15, 16, 18, 3, 5, 9 | |
|
Rule
Does not allow the use of AllowTcpForwarding
[ref] | AllowTcpForwarding allows the SSH server to act as a proxy to forward TCP requests from
clients, similar to establishing an SSH tunnel between the server and the client. This
feature may cause the client to attack other servers from the external network through
the SSH channel.
Make sure SSH's AllowTcpForwarding parameter is configured correctly.
| | Rationale: | If AllowTcpForwarding is configured as yes, attackers can bypass firewall monitoring on
the client through the SSH channel and send attack commands to the intranet server where
the SSH server is located, thereby attacking it. So AllowTcpForwarding must be closed. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_disable_AllowTcpForwardindg | | Identifiers and References | | |
|
Rule
Allow Only SSH Protocol 2
[ref] | Only SSH protocol version 2 connections should be
permitted. The default setting in
/etc/ssh/sshd_config is correct, and can be
verified by ensuring that the following
line appears:
Protocol 2 Warning:
As of openssh-server version 7.4 and above, the only protocol
supported is version 2, and line Protocol 2 in
/etc/ssh/sshd_config is not necessary. | | Rationale: | SSH protocol version 1 is an insecure implementation of the SSH protocol and
has many well-known vulnerability exploits. Exploits of the SSH daemon could provide
immediate root access to the system. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_allow_only_protocol2 | | Identifiers and References | References:
NT007(R1), 5.2.2, 5.5.6, 3.1.13, 3.5.4, CCI-000197, CCI-000366, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), CM-6(a), AC-17(a), AC-17(2), IA-5(1)(c), SC-13, MA-4(6), PR.AC-1, PR.AC-3, PR.AC-6, PR.AC-7, PR.PT-4, SRG-OS-000074-GPOS-00042, SRG-OS-000480-GPOS-00227, SRG-OS-000033-VMM-000140, SR 1.1, SR 1.10, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.6, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.2, 4.3.3.7.4, APO13.01, DSS01.04, DSS05.02, DSS05.03, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.03, DSS06.10, A.11.2.6, A.13.1.1, A.13.2.1, A.14.1.3, A.18.1.4, A.6.2.1, A.6.2.2, A.7.1.1, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16, 5, 8 | |
|
Rule
Enable PAM
[ref] | UsePAM Enables the Pluggable Authentication Module interface. If set to “yes” this will
enable PAM authentication using ChallengeResponseAuthentication and
PasswordAuthentication in addition to PAM account and session module processing for all
authentication types. | | Rationale: | When UsePAM is set to yes, PAM runs through account and session types properly. This is
important if you want to restrict access to services based off of IP, time or other factors of
the account. Additionally, you can make sure users inherit certain environment variables
on login or disallow access to the server. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_enable_pam | | Identifiers and References | | |
|
Rule
Disable Host-Based Authentication
[ref] | SSH's cryptographic host-based authentication is
more secure than .rhosts authentication. However, it is
not recommended that hosts unilaterally trust one another, even
within an organization.
To disable host-based authentication, add or correct the
following line in /etc/ssh/sshd_config:
HostbasedAuthentication no | | Rationale: | SSH trust relationships mean a compromise on one host
can allow an attacker to move trivially to other hosts. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_disable_host_auth | | Identifiers and References | References:
5.2.7, 5.5.6, 3.1.12, CCI-000366, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), AC-3, AC-17(a), CM-7(a), CM-7(b), CM-6(a), PR.AC-4, PR.AC-6, PR.IP-1, PR.PT-3, FIA_AFL.1, SRG-OS-000480-GPOS-00229, SRG-OS-000480-VMM-002000, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS06.03, DSS06.06, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.6.1.2, A.7.1.1, A.9.1.2, A.9.2.1, A.9.2.3, A.9.4.1, A.9.4.4, A.9.4.5, 11, 12, 14, 15, 16, 18, 3, 5, 9 | |
|
Rule
Disable SSH Root Login
[ref] | The root user should never be allowed to login to a
system directly over a network.
To disable root login via SSH, add or correct the following line
in /etc/ssh/sshd_config:
PermitRootLogin no | | Rationale: | Even though the communications channel may be encrypted, an additional layer of
security is gained by extending the policy of not logging directly on as root.
In addition, logging in with a user-specific account provides individual
accountability of actions performed on the system and also helps to minimize
direct attack attempts on root's password. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_disable_root_login | | Identifiers and References | References:
NT28(R19), 5.2.8, 5.5.6, 3.1.1, 3.1.5, CCI-000366, CCI-000770, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), AC-6(2), AC-17(a), IA-2, IA-2(5), CM-7(a), CM-7(b), CM-6(a), PR.AC-1, PR.AC-4, PR.AC-6, PR.AC-7, PR.DS-5, PR.PT-3, FIA_AFL.1, SRG-OS-000480-GPOS-00227, SRG-OS-000109-GPOS-00056, SRG-OS-000480-VMM-002000, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 5.2, 4.3.3.2.2, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, APO01.06, DSS05.02, DSS05.04, DSS05.05, DSS05.07, DSS05.10, DSS06.02, DSS06.03, DSS06.06, DSS06.10, A.10.1.1, A.11.1.4, A.11.1.5, A.11.2.1, A.13.1.1, A.13.1.3, A.13.2.1, A.13.2.3, A.13.2.4, A.14.1.2, A.14.1.3, A.18.1.4, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, A.8.2.2, A.8.2.3, A.9.1.1, A.9.1.2, A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4, A.9.2.6, A.9.3.1, A.9.4.1, A.9.4.2, A.9.4.3, A.9.4.4, A.9.4.5, 1, 11, 12, 13, 14, 15, 16, 18, 3, 5 | |
|
Rule
Set SSH Daemon LogLevel to VERBOSE
[ref] | The VERBOSE parameter configures the SSH daemon to record login and logout activity.
To specify the log level in
SSH, add or correct the following line in the /etc/ssh/sshd_config file:
LogLevel VERBOSE | | Rationale: | SSH provides several logging levels with varying amounts of verbosity. DEBUG is specifically
not recommended other than strictly for debugging SSH communications since it provides
so much data that it is difficult to identify important security information. INFO or
VERBOSE level is the basic level that only records login activity of SSH users. In many
situations, such as Incident Response, it is important to determine when a particular user was active
on a system. The logout record can eliminate those users who disconnected, which helps narrow the
field. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_set_loglevel_verbose | | Identifiers and References | References:
SRG-OS-000032-GPOS-00013, CCI-000067, AC-17(a), AC-17(1), CM-6(a) | |
|
Rule
Disable SSH Support for Rhosts RSA Authentication
[ref] | SSH can allow authentication through the obsolete rsh
command through the use of the authenticating user's SSH keys. This should be disabled.
To ensure this behavior is disabled, add or correct the
following line in /etc/ssh/sshd_config:
RhostsRSAAuthentication no Warning:
As of openssh-server version 7.4 and above,
the RhostsRSAAuthentication option has been deprecated, and the line
RhostsRSAAuthentication no in /etc/ssh/sshd_config is not
necessary. | | Rationale: | Configuring this setting for the SSH daemon provides additional
assurance that remove login via SSH will require a password, even
in the event of misconfiguration elsewhere. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_disable_rhosts_rsa | | Identifiers and References | References:
3.1.12, CCI-000366, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), AC-17(a), CM-7(a), CM-7(b), CM-6(a), PR.IP-1, FIA_AFL.1, SRG-OS-000480-GPOS-00227, SR 7.6, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, 11, 3, 9 | |
|
Rule
Enable SSH Warning Banner
[ref] | To enable the warning banner and ensure it is consistent
across the system, add or correct the following line in /etc/ssh/sshd_config:
Banner /etc/issue
Another section contains information on how to create an
appropriate system-wide warning banner. | | Rationale: | The warning message reinforces policy awareness during the logon process and
facilitates possible legal action against attackers. Alternatively, systems
whose ownership should not be obvious should ensure usage of a banner that does
not provide easy attribution. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_enable_warning_banner | | Identifiers and References | References:
5.2.16, 5.5.6, 3.1.9, CCI-000048, CCI-000050, CCI-001384, CCI-001385, CCI-001386, CCI-001387, CCI-001388, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), AC-8(a), AC-8(c), AC-17(a), CM-6(a), PR.AC-7, FMT_MOF_EXT.1, SRG-OS-000023-GPOS-00006, SRG-OS-000024-GPOS-00007, SRG-OS-000228-GPOS-00088, SRG-OS-000023-VMM-000060, SRG-OS-000024-VMM-000070, SR 1.1, SR 1.10, SR 1.2, SR 1.5, SR 1.7, SR 1.8, SR 1.9, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, DSS05.04, DSS05.10, DSS06.10, A.18.1.4, A.9.2.1, A.9.2.4, A.9.3.1, A.9.4.2, A.9.4.3, 1, 12, 15, 16 | |
|
Rule
Do Not Allow SSH Environment Options
[ref] | To ensure users are not able to override environment
variables of the SSH daemon, add or correct the following line
in /etc/ssh/sshd_config:
PermitUserEnvironment no | | Rationale: | SSH environment options potentially allow users to bypass
access restriction in some configurations. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_do_not_permit_user_env | | Identifiers and References | References:
5.2.10, 5.5.6, 3.1.12, CCI-000366, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), AC-17(a), CM-7(a), CM-7(b), CM-6(a), PR.IP-1, SRG-OS-000480-GPOS-00229, SRG-OS-000480-VMM-002000, SR 7.6, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, 11, 3, 9 | |
|
Rule
Set SSH authentication attempt limit
[ref] | The MaxAuthTries parameter specifies the maximum number of authentication attempts
permitted per connection. Once the number of failures reaches half this value, additional failures are logged.
to set MaxAUthTries edit /etc/ssh/sshd_config as follows:
MaxAuthTries tries | | Rationale: | Setting the MaxAuthTries parameter to a low number will minimize the risk of successful
brute force attacks to the SSH server. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_sshd_set_max_auth_tries | | Identifiers and References | | |
|
| Group
SNMP Server
Group contains 1 group and 1 rule |
[ref]
The Simple Network Management Protocol allows
administrators to monitor the state of network devices, including
computers. Older versions of SNMP were well-known for weak
security, such as plaintext transmission of the community string
(used for authentication) and usage of easily-guessable
choices for the community string. |
| Group
Disable SNMP Server if Possible
Group contains 1 rule |
[ref]
The system includes an SNMP daemon that allows for its remote
monitoring, though it not installed by default. If it was installed and
activated but is not needed, the software should be disabled and removed. |
Rule
Uninstall net-snmp Package
[ref] | The net-snmp package provides the snmpd service.
The net-snmp package can be removed with the following command:
$ sudo dnf erase net-snmp | | Rationale: | If there is no need to run SNMP server software,
removing the package provides a safeguard against its
activation. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_package_net-snmp_removed | | Identifiers and References | | |
|
| Group
Cron and At Daemons
Group contains 3 rules |
[ref]
The cron and at services are used to allow commands to
be executed at a later time. The cron service is required by almost
all systems to perform necessary maintenance tasks, while at may or
may not be required on a given system. Both daemons should be
configured defensively. |
Rule
Enable cron Service
[ref] | The crond service is used to execute commands at
preconfigured times. It is required by almost all systems to perform necessary
maintenance tasks, such as notifying root of system activity.
The crond service can be enabled with the following command:
$ sudo systemctl enable crond.service | | Rationale: | Due to its usage for maintenance and security-supporting tasks,
enabling the cron daemon is essential. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_service_crond_enabled | | Identifiers and References | References:
5.1.1, 164.308(a)(4)(i), 164.308(b)(1), 164.308(b)(3), 164.310(b), 164.312(e)(1), 164.312(e)(2)(ii), CM-6(a), PR.IP-1, PR.PT-3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2, 11, 14, 3, 9 | |
|
Rule
Verify Permissions On The cron And at Files
[ref] | Check permissions on the cron and at files, include: cron.d, crontab, cron.hourly,
cron.daily, cron.weekly, cron.monthly, cron.allow, at.allow. And there are no files of cron.deny and at.deny. | | Rationale: | Strict permission control prevents attacks from low-privileged users. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_cron_and_at_config | | Identifiers and References | | |
|
Rule
Ensure All Commands/Bashes In Crontab File Are Not Writeable By Low-privilege Users
[ref] | It can not be scanned automatically, please check it manually.
Use below cli commands to check if there is any low-privilege users writeable commands/bashes in /etc/crontab
So, the wirteable flag of other users is present(-rwxr wxr wx.) and it is a risk. | | Rationale: | If any symlink files have no camonical path, it should be removed. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_no_lowprivilege_users_writeable_cmds_in_crontab_file | | Identifiers and References | | |
|
| Group
Samba(SMB) Microsoft Windows File Sharing Server
Group contains 1 group and 1 rule |
[ref]
When properly configured, the Samba service allows
Linux systems to provide file and print sharing to Microsoft
Windows systems. There are two software packages that provide
Samba support. The first, samba-client, provides a series of
command line tools that enable a client system to access Samba
shares. The second, simply labeled samba, provides the Samba
service. It is this second package that allows a Linux system to
act as an Active Directory server, a domain controller, or as a
domain member. Only the samba-client package is installed by
default. |
| Group
Disable Samba if Possible
Group contains 1 rule |
[ref]
Even after the Samba server package has been installed, it
will remain disabled. Do not enable this service unless it is
absolutely necessary to provide Microsoft Windows file and print
sharing functionality. |
Rule
Disable Samba
[ref] | The smb service can be disabled with the following command: $ sudo systemctl disable smb.service The smb service can be masked with the following command: $ sudo systemctl mask smb.service | | Rationale: | Running a Samba server provides a network-based avenue of attack, and
should be disabled if not needed. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_service_smb_disabled | | Identifiers and References | References:
2.2.12, CCI-001436 | |
|
| Group
Network Time Protocol
Group contains 2 rules |
[ref]
The Network Time Protocol is used to manage the system
clock over a network. Computer clocks are not very accurate, so
time will drift unpredictably on unmanaged systems. Central time
protocols can be used both to ensure that time is consistent among
a network of systems, and that their time is consistent with the
outside world.
If every system on a network reliably reports the same time, then it is much
easier to correlate log messages in case of an attack. In addition, a number of
cryptographic protocols (such as Kerberos) use timestamps to prevent certain
types of attacks. If your network does not have synchronized time, these
protocols may be unreliable or even unusable.
Depending on the specifics of the network, global time accuracy may be just as
important as local synchronization, or not very important at all. If your
network is connected to the Internet, using a public timeserver (or one
provided by your enterprise) provides globally accurate timestamps which may be
essential in investigating or responding to an attack which originated outside
of your network.
A typical network setup involves a small number of internal systems operating
as NTP servers, and the remainder obtaining time information from those
internal servers.
There is a choice between the daemons ntpd and chronyd, which
are available from the repositories in the ntp and chrony
packages respectively.
The default chronyd daemon can work well when external time references
are only intermittently accesible, can perform well even when the network is
congested for longer periods of time, can usually synchronize the clock faster
and with better time accuracy, and quickly adapts to sudden changes in the rate
of the clock, for example, due to changes in the temperature of the crystal
oscillator. Chronyd should be considered for all systems which are
frequently suspended or otherwise intermittently disconnected and reconnected
to a network. Mobile and virtual systems for example.
The ntpd NTP daemon fully supports NTP protocol version 4 (RFC 5905),
including broadcast, multicast, manycast clients and servers, and the orphan
mode. It also supports extra authentication schemes based on public-key
cryptography (RFC 5906). The NTP daemon ( ntpd) should be considered
for systems which are normally kept permanently on. Systems which are required
to use broadcast or multicast IP, or to perform authentication of packets with
the Autokey protocol, should consider using ntpd.
Refer to
https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/servers/Configuring_NTP_Using_the_chrony_Suite/
for more detailed comparison of features of chronyd
and ntpd daemon features respectively, and for further guidance how to
choose between the two NTP daemons.
The upstream manual pages at
http://chrony.tuxfamily.org/manual.html for
chronyd and
http://www.ntp.org for ntpd provide additional
information on the capabilities and configuration of each of the NTP daemons. |
Rule
Enable the NTP Daemon
[ref] |
Run the following command to determine the current status of the
chronyd service:
$ systemctl is-active chronyd
If the service is running, it should return the following: active
Note: The chronyd daemon is enabled by default.
Run the following command to determine the current status of the
ntpd service:
$ systemctl is-active ntpd
If the service is running, it should return the following: active
Note: The ntpd daemon is not enabled by default. Though as mentioned
in the previous sections in certain environments the ntpd daemon might
be preferred to be used rather than the chronyd one. Refer to:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Configuring_NTP_Using_the_chrony_Suite.html
for guidance which NTP daemon to choose depending on the environment used. | | Rationale: | Enabling some of chronyd or ntpd services ensures
that the NTP daemon will be running and that the system will synchronize its
time to any servers specified. This is important whether the system is
configured to be a client (and synchronize only its own clock) or it is also
acting as an NTP server to other systems. Synchronizing time is essential for
authentication services such as Kerberos, but it is also important for
maintaining accurate logs and auditing possible security breaches.
The chronyd and ntpd NTP daemons offer all of the
functionality of ntpdate, which is now deprecated. Additional
information on this is available at
http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_service_chronyd_or_ntpd_enabled | | Identifiers and References | References:
2.2.1.1, 3.3.7, CCI-000160, CM-6(a), AU-8(1)(a), PR.PT-1, SRG-OS-000356-VMM-001340, Req-10.4, SR 2.10, SR 2.11, SR 2.12, SR 2.8, SR 2.9, 4.3.3.3.9, 4.3.3.5.8, 4.3.4.4.7, 4.4.2.1, 4.4.2.2, 4.4.2.4, APO11.04, BAI03.05, DSS05.04, DSS05.07, MEA02.01, A.12.4.1, A.12.4.2, A.12.4.3, A.12.4.4, A.12.7.1, 1, 14, 15, 16, 3, 5, 6 | |
|
Rule
Correctly configure the ntpd service
[ref] |
In a cluster scenario, it is critical that the server time is accurate and
consistent. For example, when the time is inconsistent, the data generated
between different servers may produce inaccurate results when sorted or
compared based on time.
If a Linux server has been running for a long time, time errors will occur.
Therefore, even if we use the date command to configure all server times to
be consistent initially, as time goes by, the server time will still be
inaccurate and inconsistent. Therefore, in order to ensure that the time of
all machines in the environment is synchronized and accurate, there must be
a time server that can be synchronized, and other servers in the network
will synchronize time to this server.
It can not be scanned automatically, please check it manually.
Check ntpd configure use below command.
- first:
$ service ntpd status 2>&1 | grep Active
- then:
$ grep "^restrict" /etc/ntp.conf
- finally:
$ grep -E "^(server|pool)" /etc/ntp.conf
| | Rationale: |
When using the ntpd service to achieve time synchronization, if the ntpd
service is not configured correctly, the server time may be inaccurate,
resulting in inconsistent times between different servers.
When the server time is inaccurate, there will be big problems for time-sensitive
data such as finance and orders. For example, time inaccuracies may cause a
piece of accounting data to fall into the wrong financial period, resulting in
an uneven balance sheet at the end of the period.
When the time between servers is inconsistent, there will be a deviation
in the time of the packets generated by each host. If there is a certain
processing order of data flows between multiple servers, and the server time
of the latter link is less than the time of the previous server, it may cause
The received packet is discarded because the time is greater than the local
time.
| | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_ntpd_service_configure_correctly | | Identifiers and References | | |
|
| Group
DNS Server
Group contains 1 group and 1 rule |
[ref]
Most organizations have an operational need to run at
least one nameserver. However, there are many common attacks
involving DNS server software, and this server software should
be disabled on any system
on which it is not needed. |
| Group
Disable DNS Server
Group contains 1 rule |
[ref]
DNS software should be disabled on any systems which does not
need to be a nameserver. Note that the BIND DNS server software is
not installed on openEuler 22.03 LTS by default. The remainder of this section
discusses secure configuration of systems which must be
nameservers. |
Rule
Disable named Service
[ref] | The named service can be disabled with the following command: $ sudo systemctl disable named.service The named service can be masked with the following command: $ sudo systemctl mask named.service | | Rationale: | All network services involve some risk of compromise due to
implementation flaws and should be disabled if possible. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_service_named_disabled | | Identifiers and References | References:
2.2.8, CCI-000366, CM-7(a), CM-7(b), CM-6(a), PR.IP-1, PR.PT-3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2, 11, 14, 3, 9 | |
|
| Group
Avahi Server
Group contains 1 group and 1 rule |
[ref]
The Avahi daemon implements the DNS Service Discovery
and Multicast DNS protocols, which provide service and host
discovery on a network. It allows a system to automatically
identify resources on the network, such as printers or web servers.
This capability is also known as mDNSresponder and is a major part
of Zeroconf networking. |
| Group
Disable Avahi Server if Possible
Group contains 1 rule |
[ref]
Because the Avahi daemon service keeps an open network
port, it is subject to network attacks.
Disabling it can reduce the system's vulnerability to such attacks. |
Rule
Disable Avahi Server Software
[ref] | The avahi-daemon service can be disabled with the following command: $ sudo systemctl disable avahi-daemon.service The avahi-daemon service can be masked with the following command: $ sudo systemctl mask avahi-daemon.service | | Rationale: | Because the Avahi daemon service keeps an open network
port, it is subject to network attacks. Its functionality
is convenient but is only appropriate if the local network
can be trusted. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_service_avahi-daemon_disabled | | Identifiers and References | References:
2.2.3, CCI-000366, CM-7(a), CM-7(b), CM-6(a), PR.IP-1, PR.PT-3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2, 11, 14, 3, 9 | |
|
| Group
X Window System
Group contains 1 group and 1 rule |
[ref]
The X Window System implementation included with the
system is called X.org. |
| Group
Disable X Windows
Group contains 1 rule |
[ref]
Unless there is a mission-critical reason for the
system to run a graphical user interface, ensure X is not set to start
automatically at boot and remove the X Windows software packages.
There is usually no reason to run X Windows
on a dedicated server system, as it increases the system's attack surface and consumes
system resources. Administrators of server systems should instead login via
SSH or on the text console. |
Rule
Remove the X Windows Package Group
[ref] | By removing the xorg-x11-server-common package, the system no longer has X Windows
installed. If X Windows is not installed then the system cannot boot into graphical user mode.
This prevents the system from being accidentally or maliciously booted into a graphical.target
mode. To do so, run the following command:
$ sudo yum groupremove "X Window System"
$ sudo yum 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. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_package_xorg-x11-server-common_removed | | Identifiers and References | References:
2.2.2, CCI-000366, CM-7(a), CM-7(b), CM-6(a), PR.AC-3, PR.PT-4, SRG-OS-000480-GPOS-00227, SR 1.13, SR 2.6, SR 3.1, SR 3.5, SR 3.8, SR 4.1, SR 4.3, SR 5.1, SR 5.2, SR 5.3, SR 7.1, SR 7.6, 4.3.3.6.6, APO13.01, DSS01.04, DSS05.02, DSS05.03, A.11.2.6, A.13.1.1, A.13.2.1, A.14.1.3, A.6.2.1, A.6.2.2, 12, 15, 8 | |
|
| Group
FTP Server
Group contains 1 rule |
[ref]
FTP is a common method for allowing remote access to
files. Like telnet, the FTP protocol is unencrypted, which means
that passwords and other data transmitted during the session can be
captured and that the session is vulnerable to hijacking.
Therefore, running the FTP server software is not recommended.
However, there are some FTP server configurations which may
be appropriate for some environments, particularly those which
allow only read-only anonymous access as a means of downloading
data available to the public. |
Rule
Remove ftp Client
[ref] | FTP is a simple file transfer protocol,
it does not support authentication and can be easily hacked. The package
ftp is a client program that allows for connections to a ftp server. | | Rationale: | It is recommended that FTP be removed, unless there is a specific need
for FTP. In that case, use extreme caution when configuring
the services. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_package_ftp_removed | | Identifiers and References | | |
|
| Group
Rsync Server
Group contains 1 rule |
[ref]
The rsync service can be used to synchronize data between
servers or between different Disk partitioning on the server,
but because rsync uses an unencrypted transmission protocol,
there is a risk of information disclosure. |
Rule
Disable Rsync Server Software
[ref] | The rsync service can be disabled with the following command: $ sudo systemctl disable rsync.service The rsync service can be masked with the following command: $ sudo systemctl mask rsync.service | | Rationale: | If the rsync service is enabled and data is transmitted between
different servers through the network, attackers can steal data
by listening to server ports, routers, and switch data packets. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_service_rsyncd_disabled | | Identifiers and References | | |
|
| Group
Base Services
Group contains 1 rule |
[ref]
This section addresses the base services that are installed on a
openEuler 22.03 LTS default installation which are not covered in other
sections. Some of these services listen on the network and
should be treated with particular discretion. Other services are local
system utilities that may or may not be extraneous. In general, system services
should be disabled if not required. |
Rule
Enable haveged service
[ref] | The haveged service provides an easy-to-use, unpredictable random number
generator. The generated random numbers are used to supplement the system
entropy pool, which can solve the problem of low system entropy in some
cases. It is recommended to enable this service in scenarios where encryption,
decryption or key generation is required (such as using openssl and gnutls).
If the haveged service is not turned on, when the process that needs to
generate strong pseudo-random numbers gets values from /dev/random, it will
be stuck in waiting because it cannot get enough values, and will not return
until new random bytes are obtained. | | Rationale: | none. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_service_haveged_enabled | | Identifiers and References | | |
|
| Group
Print Support
Group contains 1 rule |
[ref]
The Common Unix Printing System (CUPS) service provides both local
and network printing support. A system running the CUPS service can accept
print jobs from other systems, process them, and send them to the appropriate
printer. It also provides an interface for remote administration through a web
browser. The CUPS service is installed and activated by default. The project
homepage and more detailed documentation are available at
http://www.cups.org.
|
Rule
Disable the CUPS Service
[ref] | The cups service can be disabled with the following command: $ sudo systemctl disable cups.service The cups service can be masked with the following command: $ sudo systemctl mask cups.service | | Rationale: | Turn off unneeded services to reduce attack surface. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_service_cups_disabled | | Identifiers and References | References:
2.2.4, CM-7(a), CM-7(b), CM-6(a), PR.IP-1, PR.PT-3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2, 11, 14, 3, 9 | |
|
| Group
Web Server
Group contains 1 group and 1 rule |
[ref]
The web server is responsible for providing access to
content via the HTTP protocol. Web servers represent a significant
security risk because:
- The HTTP port is commonly probed by malicious sources
- Web server software is very complex, and includes a long
history of vulnerabilities
- The HTTP protocol is unencrypted and vulnerable to passive
monitoring
The system's default web server software is Apache 2 and is
provided in the RPM package httpd. |
| Group
Disable Apache if Possible
Group contains 1 rule |
[ref]
If Apache was installed and activated, but the system
does not need to act as a web server, then it should be disabled
and removed from the system. |
Rule
Uninstall httpd Package
[ref] | The httpd package can be removed with the following command: $ sudo dnf erase httpd | | Rationale: | If there is no need to make the web server software available,
removing it provides a safeguard against its activation. | | Severity: | low | | Rule ID: | xccdf_org.ssgproject.content_rule_package_httpd_removed | | Identifiers and References | References:
CM-7(a), CM-7(b), CM-6(a), PR.IP-1, PR.PT-3, SR 1.1, SR 1.10, SR 1.11, SR 1.12, SR 1.13, SR 1.2, SR 1.3, SR 1.4, SR 1.5, SR 1.6, SR 1.7, SR 1.8, SR 1.9, SR 2.1, SR 2.2, SR 2.3, SR 2.4, SR 2.5, SR 2.6, SR 2.7, SR 7.6, 4.3.3.5.1, 4.3.3.5.2, 4.3.3.5.3, 4.3.3.5.4, 4.3.3.5.5, 4.3.3.5.6, 4.3.3.5.7, 4.3.3.5.8, 4.3.3.6.1, 4.3.3.6.2, 4.3.3.6.3, 4.3.3.6.4, 4.3.3.6.5, 4.3.3.6.6, 4.3.3.6.7, 4.3.3.6.8, 4.3.3.6.9, 4.3.3.7.1, 4.3.3.7.2, 4.3.3.7.3, 4.3.3.7.4, 4.3.4.3.2, 4.3.4.3.3, BAI10.01, BAI10.02, BAI10.03, BAI10.05, DSS05.02, DSS05.05, DSS06.06, A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, A.14.2.3, A.14.2.4, A.9.1.2, 11, 14, 3, 9 | |
|
| Group
Do not install some software packages.
Group contains 1 rule |
|
Rule
Uninstall network sniffing Package
[ref] | If the production environment contains network sniffing tools, attackers
can easily use these tools to conduct network analysis and assist network
attacks. Therefore, installation of various network sniffing and packet
capture analysis tools, such as tcpdump, ethereal, wireshark, etc., should
be prohibited in the production environment.
It can not be scanned automatically,please check it manually.
check the network_sniffing_tools,such as wireshark,netcat,tcpdump,namp,ethereal:
$ rpm -qa | grep -iE "^(wireshark-|netcat-|tcpdump-|nmap-|ethereal-)" | | Rationale: | There is no need to install various network sniffing and packet capture
analysis tools in the production environment. | | Severity: | high | | Rule ID: | xccdf_org.ssgproject.content_rule_network_sniffing_tools | | Identifiers and References | | |
|