Guide to the Secure Configuration of Red Hat Enterprise Linux 7
with profile PCI-DSS v3 Control Baseline for Red Hat Enterprise Linux 7This is a *draft* profile for PCI-DSS v3
Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG for Red Hat Enterprise Linux 7 is one example of a baseline created from this guidance.
This benchmark is a direct port of a SCAP Security Guide benchmark developed for Red Hat Enterprise Linux. It has been modified through an automated process to remove specific dependencies on Red Hat Enterprise Linux and to function with Scientifc Linux. The result is a generally useful SCAP Security Guide benchmark with the following caveats:
- Scientifc Linux is not an exact copy of Red Hat Enterprise Linux. Scientific Linux is a Linux distribution produced by Fermi National Accelerator Laboratory. It is a free and open source operating system based on Red Hat Enterprise Linux and aims to be "as close to the commercial enterprise distribution as we can get it." There may be configuration differences that produce false positives and/or false negatives. If this occurs please file a bug report.
- Scientifc Linux is derived from the free and open source software made available by Red Hat, but it is not produced, maintained or supported by Red Hat. Scientifc Linux has its own build system, compiler options, patchsets, and is a community supported, non-commercial operating system. Scientifc Linux does not inherit certifications or evaluations from Red Hat Enterprise Linux. As such, some configuration rules (such as those requiring FIPS 140-2 encryption) will continue to fail on Scientifc Linux.
Members of the Scientifc Linux community are invited to participate in OpenSCAP and SCAP Security Guide development. Bug reports and patches can be sent to GitHub: https://github.com/OpenSCAP/scap-security-guide. The mailing list is at https://fedorahosted.org/mailman/listinfo/scap-security-guide.
Profile Title | PCI-DSS v3 Control Baseline for Red Hat Enterprise Linux 7 |
---|---|
Profile ID | xccdf_org.ssgproject.content_profile_pci-dss |
Revision History
Current version: 0.1.29
- draft (as of 2016-05-05)
Platforms
- cpe:/o:redhat:enterprise_linux:7
- cpe:/o:scientificlinux:scientificlinux:7
- cpe:/o:redhat:enterprise_linux:7::client
- cpe:/o:redhat:enterprise_linux:7::computenode
Table of Contents
- System Settings
- Installing and Maintaining Software
- File Permissions and Masks
- Account and Access Control
- Network Configuration and Firewalls
- Configure Syslog
- System Accounting with auditd
- Services
Checklist
contains 94 rules |
System SettingsgroupContains rules that check correct system settings. |
contains 90 rules |
Installing and Maintaining SoftwaregroupThe following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates. |
contains 15 rules |
Updating SoftwaregroupThe |
contains 4 rules |
Ensure Red Hat GPG Key InstalledruleTo ensure the system can cryptographically verify base software packages come from Red Hat (and to connect to the Red Hat Network to receive them), the Red Hat GPG key must properly be installed. To install the Red Hat GPG key, run: $ sudo rhn_registerIf the system is not connected to the Internet or an RHN Satellite, then install the Red Hat GPG key from trusted media such as the Red Hat installation CD-ROM or DVD. Assuming the disc is mounted in /media/cdrom , use the following command as the root user to import
it into the keyring:
$ sudo rpm --import /media/cdrom/RPM-GPG-KEYRationale: Changes to software components can have significant effects on the overall security of the operating system. This requirement ensures the software has not been tampered with and that it has been provided by a trusted vendor. The Red Hat GPG key is necessary to cryptographically verify packages are from Red Hat. identifiers: CCE-26957-1 references: CM-5(3), SI-7, MA-1(b), 1749, 366, Req-6.2, 1.2.2, Test attestation on 20150407 by sdw
|
Ensure gpgcheck Enabled In Main Yum ConfigurationruleThe gpgcheck=1Rationale:
Changes to any software components can have significant effects on the overall security
of the operating system. This requirement ensures the software has not been tampered with
and that it has been provided by a trusted vendor.
identifiers: CCE-26989-4 references: CM-5(3), SI-7, MA-1(b), 1749, SRG-OS-000366-GPOS-00153, 020150, Req-6.2, 1.2.3, Test attestation on 20150407 by sdw
|
Ensure gpgcheck Enabled For All Yum Package RepositoriesruleTo ensure signature checking is not disabled for
any repos, remove any lines from files in gpgcheck=0Rationale: 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). identifiers: CCE-26876-3 references: CM-5(3), SI-7, MA-1(b), 1749, 366, Req-6.2, Test attestation on 20150407 by sdw
|
Ensure Software Patches InstalledruleIf the system is joined to the Red Hat Network, a Red Hat Satellite Server, or a yum server, run the following command to install updates: $ sudo yum updateIf the system is not configured to use one of these sources, updates (in the form of RPM packages) can be manually downloaded from the Red Hat Network and installed using rpm .
Rationale:Installing software updates is a fundamental mitigation against the exploitation of publicly-known vulnerabilities. identifiers: CCE-26895-3 references: SI-2, MA-1(b), http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-6.2, 1.7, Test attestation on 20120928 by MM
|
Software Integrity Checkinggroup
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.
|
contains 7 rules |
Verify Integrity with AIDEgroupAIDE 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 |
contains 4 rules |
Install AIDEruleInstall the AIDE package with the command: $ sudo yum install aideRationale: The AIDE package must be installed if it is to be available for integrity checking. identifiers: CCE-27096-7 references: CM-3(d), CM-3(e), CM-6(d), CM-6(3), SC-28, SI-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-11.5, 1.3.1, Test attestation on 20121024 by DS
|
Disable Prelinkingrule
The prelinking feature changes binaries in an attempt to decrease their startup
time. In order to disable it, change or add the following line inside the file
PRELINKING=noNext, run the following command to return binaries to a normal, non-prelinked state: $ sudo /usr/sbin/prelink -uaRationale: The prelinking feature can interfere with the operation of AIDE, because it changes binaries. Remediation script:
|
Build and Test AIDE DatabaseruleRun the following command to generate a new database: $ sudo /usr/sbin/aide --initBy default, the database will be written to the file /var/lib/aide/aide.db.new.gz .
Storing the database, the configuration file /etc/aide.conf , and the binary
/usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity.
The newly-generated database can be installed as follows:
$ sudo cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gzTo initiate a manual check, run the following command: $ sudo /usr/sbin/aide --checkIf this check produces any unexpected output, investigate. Rationale: For AIDE to be effective, an initial database of "known-good" information about files must be captured and it should be able to be verified against the installed files. Remediation script:
|
Configure Periodic Execution of AIDErule
To implement a daily execution of AIDE at 4:05am using cron, add the following line to 05 4 * * * root /usr/sbin/aide --checkAIDE can be executed periodically through other means; this is merely one example. Rationale: By default, AIDE does not install itself for periodic execution. Periodically running AIDE is necessary to reveal unexpected changes in installed files. identifiers: CCE-26952-2 references: CM-3(d), CM-3(e), CM-6(d), CM-6(3), SC-28, SI-7, 374, 416, 1069, 1263, 1297, 1589, Req-11.5, 1.3.1
|
Verify Integrity with RPMgroupThe RPM package management system includes the ability to verify the integrity of installed packages by comparing the installed files with information about the files taken from the package metadata stored in the RPM database. Although an attacker could corrupt the RPM database (analogous to attacking the AIDE database as described above), this check can still reveal modification of important files. To list which files on the system differ from what is expected by the RPM database: $ rpm -qVaSee the man page for rpm to see a complete explanation of each column.
|
contains 2 rules |
Verify and Correct File Permissions with RPMruleDiscretionary access control is weakened if a user or group has access permissions to system files and directories greater than the default. The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. Verify that the file permissions, ownership, and gruop membership of system files and commands match vendor values. Check the file permissions, ownership, and group membership with the following command: $ sudo rpm -Va | grep '^.M'Output indicates files that do not match vendor defaults. After locating a file with incorrect permissions, run the following command to determine which package owns it: $ rpm -qf FILENAMENext, run the following command to reset its permissions to the correct values: $ sudo rpm --setperms PACKAGENAME warning
Note: Due to a bug in the gdm package, the
RPM verify command may continue to fail even after file permissions have been
correctly set on /var/log/gdm . This is being tracked in Red Hat
Bugzilla #1275532.
Permissions on system binaries and configuration files that are too generous could allow an unauthorized user to gain privileges that they should not have. The permissions set by the vendor should be maintained. Any deviations from this baseline should be investigated. identifiers: CCE-27209-6 references: AC-6, CM-6(d), CM-6(3), 1493, 1494, 1495, Req-11.5, 1.2.6, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, 6.2.3, 010010
|
Verify File Hashes with RPMruleWithout cryptographic integrity protections, system executables and files can be altered by unauthorized users without detection. The RPM package management system can check the hashes of installed software packages, including many that are important to system security. To verify that the cryptographic hash of system files and commands match vendor values, run the following command to list which files on the system have hashes that differ from what is expected by the RPM database: $ rpm -Va | grep '^..5'A "c" in the second column indicates that a file is a configuration file, which may appropriately be expected to change. If the file was not expected to change, investigate the cause of the change using audit logs or other means. The package can then be reinstalled to restore the file. Run the following command to determine which package owns the file: $ rpm -qf FILENAMEThe package can be reinstalled from a yum repository using the command: $ sudo yum reinstall PACKAGENAMEAlternatively, the package can be reinstalled from trusted media using the command: $ sudo rpm -Uvh PACKAGENAMERationale: The hashes of important files like system executables should match the information given by the RPM database. Executables with erroneous hashes could be a sign of nefarious activity on the system. |
Additional Security SoftwaregroupAdditional security software that is not provided or supported by Red Hat can be installed to provide complementary or duplicative security capabilities to those provided by the base platform. Add-on software may not be appropriate for some specialized systems. |
contains 1 rule |
Install Intrusion Detection SoftwareruleThe base Red Hat platform already includes a sophisticated auditing system that can detect intruder activity, as well as SELinux, which provides host-based intrusion prevention capabilities by confining privileged programs and user sessions which may become compromised. warning
Note in DoD environments, supplemental intrusion
detection tools, such as the McAfee Host-based Security System, are available
to integrate with existing infrastructure. When these supplemental tools
interfere with proper functioning of SELinux, SELinux takes precedence. Host-based intrusion detection tools provide a system-level defense when an intruder gains access to a system or network. |
GNOME Desktop Environmentgroup
GNOME is a graphical desktop environment bundled with many Linux distributions that
allow users to easily interact with the operating system graphically rather than
textually. The GNOME Graphical Display Manager (GDM) provides login, logout, and user
switching contexts as well as display server management.
|
contains 4 rules |
Configure GNOME Screen LockinggroupIn the default GNOME3 desktop, the screen can be locked
by selecting the user name in the far right corner of the main panel and
selecting Lock.
|
contains 4 rules |
Set GNOME3 Screensaver Inactivity Timeoutrule
The idle time-out value for inactivity in the GNOME3 desktop is configured via the [org/gnome/desktop/session] idle-delay=900Once the setting has been added, add a lock to /etc/dconf/db/local.d/locks/00-security-settings-lock to prevent user modification.
For example:
/org/gnome/desktop/session/idle-delayAfter the settings have been set, run dconf update .
Rationale:A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, GNOME3 can be configured to identify when a user's session has idled and take action to initiate a session lock. identifiers: CCE-RHEL7-CCE-TBD references: AC-11(a), 57, Req-8.1.8, SRG-OS-000029-GPOS-00010, 010070
|
Enable GNOME3 Screensaver Idle Activationrule
To activate the screensaver in the GNOME3 desktop after a period of inactivity,
add or set [org/gnome/desktop/screensaver] idle_activation_enabled=trueOnce the setting has been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification.
For example:
/org/gnome/desktop/screensaver/idle-activation-enabledAfter the settings have been set, run dconf update .
Rationale:A session time-out lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operating system session prior to vacating the vicinity, GNOME desktops can be configured to identify when a user's session has idled and take action to initiate the session lock. Enabling idle activation of the screensaver ensures the screensaver will be activated after the idle delay. Applications requiring continuous, real-time screen display (such as network management products) require the login session does not have administrator rights and the display station is located in a controlled-access area. identifiers: CCE-RHEL7-CCE-TBD references: AC-11(a), 57, SRG-OS-000029-GPOS-00010, 010073, Req-8.1.8
|
Enable GNOME3 Screensaver Lock After Idle Periodrule
To activate locking of the screensaver in the GNOME3 desktop when it is activated,
add or set [org/gnome/desktop/screensaver] lock-enabled=true lock-delay=0Once the settings have been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification.
For example:
/org/gnome/desktop/screensaver/lock-enabled /org/gnome/desktop/screensaver/lock-delayAfter the settings have been set, run dconf update .
Rationale:A session lock is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not want to logout because of the temporary nature of the absense. identifiers: CCE-RHEL7-CCE-TBD references: AC-11(b), 56, Req-8.1.8, SRG-OS-000028-GPOS-00009, OS-SRG-000030-GPOS-00011, 010060
|
Implement Blank Screensaverrule
To set the screensaver mode in the GNOME3 desktop to a blank screen,
add or set [org/gnome/desktop/screensaver] picture-uri=''Once the settings have been added, add a lock to /etc/dconf/db/gdm.d/locks/00-security-settings-lock to prevent user modification.
For example:
/org/gnome/desktop/screensaver/picture-uriAfter the settings have been set, run dconf update .
Rationale:Setting the screensaver mode to blank-only conceals the contents of the display from passersby. Remediation script:
|
File Permissions and MasksgroupTraditional 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.
$ mount -t xfs | awk '{print $3}'For any systems that use a different local filesystem type, modify this command as appropriate. |
contains 9 rules |
Verify Permissions on Important Files and DirectoriesgroupPermissions 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. |
contains 9 rules |
Verify Permissions on Files with Local Account Information and CredentialsgroupThe default restrictive permissions for files which act as
important security databases such as |
contains 9 rules |
Verify User Who Owns shadow Filerule
To properly set the owner of $ sudo chown root /etc/shadowRationale: The identifiers: CCE-26795-5 references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-8.7.c, Test attestation on 20121026 by DS
|
Verify Group Who Owns shadow Filerule
To properly set the group owner of $ sudo chgrp root /etc/shadowRationale: The identifiers: CCE-27125-4 references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-8.7.c, Test attestation on 20121026 by DS
|
Verify Permissions on shadow Filerule
To properly set the permissions of $ sudo chmod 0000 /etc/shadowRationale: The identifiers: CCE-27100-7 references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-8.7.c, Test attestation on 20121026 by DS
|
Verify User Who Owns group Filerule
To properly set the owner of $ sudo chown root /etc/groupRationale: The identifiers: CCE-26933-2 references: AC-6, Req-8.7.c, Test attestation on 20121026 by DS
|
Verify Group Who Owns group Filerule
To properly set the group owner of $ sudo chgrp root /etc/groupRationale: The identifiers: CCE-27037-1 references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-8.7.c, Test attestation on 20121026 by DS
|
Verify Permissions on group Filerule
To properly set the permissions of $ sudo chmod 644 /etc/groupRationale: The identifiers: CCE-26949-8 references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-8.7.c, Test attestation on 20121026 by DS
|
Verify User Who Owns passwd Filerule
To properly set the owner of $ sudo chown root /etc/passwdRationale: The identifiers: CCE-27138-7 references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-8.7.c, Test attestation on 20121026 by DS
|
Verify Group Who Owns passwd Filerule
To properly set the group owner of $ sudo chgrp root /etc/passwdRationale: The identifiers: CCE-26639-5 references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-8.7.c, Test attestation on 20121026 by DS
|
Verify Permissions on passwd Filerule
To properly set the permissions of $ sudo chmod 0644 /etc/passwdRationale: If the identifiers: CCE-26887-0 references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-8.7.c, Test attestation on 20121026 by DS
|
Account and Access ControlgroupIn traditional Unix security, if an attacker gains shell access to a certain login account, they can perform any action or access any file to which that account has access. Therefore, making it more difficult for unauthorized people to gain shell access to accounts, particularly to privileged accounts, is a necessary part of securing a system. This section introduces mechanisms for restricting access to accounts under Red Hat Enterprise Linux 7. |
contains 20 rules |
Protect Accounts by Restricting Password-Based LogingroupConventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the |
contains 6 rules |
Verify Proper Storage and Existence of Password Hashesgroup
By default, password hashes for local accounts are stored
in the second field (colon-separated) in
|
contains 3 rules |
Prevent Log In to Accounts With Empty PasswordruleIf an account is configured for password authentication
but does not have an assigned password, it may be possible to log
into the account without authentication. Remove any instances of the If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments. identifiers: CCE-27286-4 references: AC-6, IA-5(b), IA-5(c), IA-5(1)(a), 366, SRG-OS-000480-GPOS-00227, 010260, Req-8.2.3, Test attestation on 20121024 by DS
|
Verify All Account Password Hashes are Shadowedrule
If any password hashes are stored in
The hashes for all user account passwords should be stored in
the file identifiers: CCE-27352-4 references: IA-5(h), http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-8.2.1, Test attestation on 20121024 by DS |
All GIDs referenced in /etc/passwd must be defined in /etc/groupruleAdd 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. identifiers: CCE-27503-2 references: IA-2, 764, SRG-OS-000104-GPOS-00051, 020300, Req-8.5.a, Test attestation on 20121024 by DS |
Set Password Expiration ParametersgroupThe file $ sudo chage -M 180 -m 7 -W 7 USER |
contains 1 rule |
Set Password Maximum AgeruleTo specify password maximum age for new accounts,
edit the file PASS_MAX_DAYS DAYSA value of 180 days is sufficient for many environments. The DoD requirement is 60. 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. identifiers: CCE-27051-2 references: IA-5(f), IA-5(g), IA-5(1)(d), 199, SRG-OS-000076-GPOS-00044, Req-8.2.4, 7.1.1, 010220, Test attestation on 20121026 by DS
|
Set Account Expiration ParametersgroupAccounts 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 $ sudo chage -I NUM_DAYS USERAccounts, 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.
|
contains 2 rules |
Set Account Expiration Following InactivityruleTo specify the number of days after a password expires (which
signifies inactivity) until an account is permanently disabled, add or correct
the following lines in INACTIVE=UNDEFINED_SUBA value of 35 is recommended. If a password is currently on the verge of expiration, then 35 days remain until the account is automatically disabled. However, if the password will not expire for another 60 days, then 95 days could elapse until the account would be automatically disabled. See the useradd man page for more information. Determining the inactivity
timeout must be done with careful consideration of the length of a "normal"
period of inactivity for users in the particular environment. Setting
the timeout too low incurs support costs and also has the potential to impact
availability of the system to legitimate users.
Rationale:Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials. identifiers: CCE-27355-7 references: AC-2(2), AC-2(3), IA-4(e), 795, SRG-OS-000118-GPOS-00060, 010280, Req-8.1.4
|
Ensure All Accounts on the System Have Unique NamesruleChange usernames, or delete accounts, so each has a unique name. Rationale:Unique usernames allow for accountability on the system. |
Protect Accounts by Configuring PAMgroupPAM, 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.
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. warning
Running authconfig or
system-config-authentication will re-write the PAM configuration
files, destroying any manually made changes and replacing them with
a series of system defaults. One reference to the configuration
file syntax can be found at
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-configuration-file.html. |
contains 11 rules |
Set Password Quality RequirementsgroupThe default |
contains 4 rules |
Set Password Quality Requirements with pam_pwqualitygroupThe 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 = 3The arguments can be modified to ensure compliance with your organization's security policy. Discussion of each parameter follows. warning
Note that the password quality
requirements are not enforced for the root account for some
reason. |
contains 4 rules |
Set Password Strength Minimum Digit CharactersruleThe pam_pwquality module's 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 digits makes password guessing attacks more difficult by ensuring a larger search space. identifiers: CCE-27214-6 references: IA-5(1)(a), IA-5(b), IA-5(c), 194, 194, SRG-OS-000071-GPOS-00039, Req-8.2.3, 6.3.2, 010110, Test attestation on 20121024 by DS
|
Set Password Minimum LengthruleThe pam_pwquality module's
The shorter the password, the lower the number of possible combinations
that need to be tested before the password is compromised.
identifiers: CCE-27293-0 references: IA-5(1)(a), 205, SRG-OS-000078-GPOS-00046, Req-8.2.3, 6.3.2, 010250, Test attestation on 20140928 by swells
|
Set Password Strength Minimum Uppercase CharactersruleThe pam_pwquality module's
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.
identifiers: CCE-27200-5 references: IA-5(b), IA-5(c), IA-5(1)(a), 192, SRG-OS-000069-GPOS-00037, 010090, Req-8.2.3, 6.3.2, Test attestation on 20121024 by DS
|
Set Password Strength Minimum Lowercase CharactersruleThe pam_pwquality module's 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. identifiers: CCE-27345-8 references: IA-5(b), IA-5(c), IA-5(1)(a), 193, SRG-OS-000070-GPOS-00038, Req-8.2.3, 010100, Test attestation on 20121024 by DS
|
Set Lockouts for Failed Password AttemptsgroupThe 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. |
contains 3 rules |
Set Deny For Failed Password Attemptsrule
To configure the system to lock out accounts after a number of incorrect login
attempts using
Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks. identifiers: CCE-27350-8 references: AC-7(b), 2238, SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005, 010370, Req-8.1.6, 6.3.3
|
Set Lockout Time For Failed Password Attemptsrule
To configure the system to lock out accounts after a number of incorrect login
attempts and require an administrator to unlock the account using
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. identifiers: CCE-26884-7 references: AC-7(b), 002238, SRG-OS-000329-GPOS-00128, SRG-OS-000021-GPOS-00005, 010371, Req-8.1.7, 6.3.3
|
Limit Password ReuseruleDo not allow users to reuse recent passwords. This can be
accomplished by using the
Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user. identifiers: CCE-26923-3 references: IA-5(f), IA-5(1)(e), 200, SRG-OS-000077-GPOS-00045, 010240, Req-8.2.5, 6.3.4, Test attestation on 20121024 by DS
|
Set Password Hashing AlgorithmgroupThe system's default algorithm for storing password hashes in
|
contains 3 rules |
Set PAM's Password Hashing Algorithmrule
The PAM system service can be configured to only store encrypted representations of passwords.
In 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 identifiers: CCE-27104-9 references: IA-5(b), IA-5(c), IA-5(1)(c), IA-7, 196, SRG-OS-000073-GPOS-00041, 010170, Req-8.2.1, 6.3.1, Test attestation on 20121024 by DS
|
Set Password Hashing Algorithm in /etc/login.defsrule
In ENCRYPT_METHOD SHA512Rationale: Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. Passwords that are encrypted with a weak algorithm are no more protected than if they are kept in plain text. Using a stronger hashing algorithm makes password cracking attacks more difficult. identifiers: CCE-27124-7 references: IA-5(b), IA-5(c), IA-5(1)(c), IA-7, 196, SRG-OS-000073-GPOS-00041, 010180, Req-8.2.1, 6.3.1, Test attestation on 20121024 by DS
|
Set Password Hashing Algorithm in /etc/libuser.confrule
In crypt_style = sha512Rationale:
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 identifiers: CCE-27053-8 references: IA-5(b), IA-5(c), IA-5(1)(c), IA-7, 196, SRG-OS-000073-GPOS-00041, 010190, Req-8.2.1, Test attestation on 20121026 by DS |
Set Last Logon/Access NotificationruleTo configure the system to notify users of last logon/access
using session [success=1 default=ignore] pam_succeed_if.so service !~ gdm* service !~ su* quiet session [default=1] pam_lastlog.so nowtmp showfailed session optional pam_lastlog.so silent noupdate showfailedRationale: Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of unsuccessful attempts that were made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. identifiers: CCE-27275-7 references: 53, Req-10.2.4
|
Protect Physical Console AccessgroupIt 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. |
contains 3 rules |
Set Boot Loader PasswordgroupDuring the boot process, the boot loader is responsible for starting the execution of the kernel and passing options to it. The boot loader allows for the selection of different kernels - possibly on different partitions or media. The default Red Hat Enterprise Linux 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. |
contains 2 rules |
Verify /boot/grub2/grub.cfg User OwnershipruleThe file $ sudo chown root /boot/grub2/grub.cfgRationale: Only root should be able to modify important boot parameters. identifiers: CCE-26860-7 references: AC-6(7), 225, Req-7.1, 1.5.1, Test attestation on 20121026 by DS
|
Verify /boot/grub2/grub.cfg Group OwnershipruleThe file $ sudo chgrp root /boot/grub2/grub.cfgRationale:
The identifiers: CCE-26812-8 references: AC-6(7), 225, Req-7.1, 1.5.1, Test attestation on 20121026 by DS
|
Configure Screen LockinggroupWhen a user must temporarily leave an account
logged-in, screen locking should be employed to prevent passersby
from abusing the account. User education and training is
particularly important for screen locking to be effective, and policies
can be implemented to reinforce this.
|
contains 1 rule |
Hardware Tokens for AuthenticationgroupThe use of hardware tokens such as smart cards for system login provides stronger, two-factor authentication than using a username and password. In Red Hat Enterprise Linux servers and workstations, hardware token login is not enabled by default and must be enabled in the system settings. |
contains 1 rule |
Enable Smart Card LoginruleTo enable smart card authentication, consult the documentation at:
Smart card login provides two-factor authentication stronger than that provided by a username and password combination. Smart cards leverage PKI (public key infrastructure) in order to provide and verify credentials. Remediation script:
|
Network Configuration and FirewallsgroupMost machines 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.
|
contains 1 rule |
IPSec SupportgroupSupport for Internet Protocol Security (IPsec) is provided in Red Hat Enterprise Linux 7 with Libreswan. |
contains 1 rule |
Install libreswan PackageruleThe Libreswan package provides an implementation of IPsec
and IKE, which permits the creation of secure tunnels over
untrusted networks.
The $ sudo yum install libreswanRationale: Providing the ability for remote users or systems to initiate a secure VPN connection protects information when it is transmitted over a wide area network. Remediation script:
|
Configure SysloggroupThe 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.
|
contains 4 rules |
Ensure Proper Configuration of Log Filesgroup
The file *.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.logSee 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 |
contains 3 rules |
Ensure Log Files Are Owned By Appropriate UserruleThe owner of all log files written by
$ ls -l LOGFILEIf the owner is not root , run the following command to
correct this:
$ sudo chown root LOGFILERationale: The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access. identifiers: CCE-RHEL7-CCE-TBD references: AC-6, SI-11, 1314, Req-10.5.1, Req-10.5.2, Test attestation on 20121024 by DS |
Ensure Log Files Are Owned By Appropriate GroupruleThe group-owner of all log files written by
$ ls -l LOGFILEIf the owner is not root , run the following command to
correct this:
$ sudo chgrp root LOGFILERationale: The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access. identifiers: CCE-RHEL7-CCE-TBD references: AC-6, SI-11, 1314, Req-10.5.1, Req-10.5.2, Test attestation on 20121024 by DS |
Ensure System Log Files Have Correct PermissionsruleThe file permissions for all log files written by
$ ls -l LOGFILEIf the permissions are not 600 or more restrictive, run the following command to correct this: $ sudo chmod 0600 LOGFILERationale: 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. identifiers: CCE-RHEL7-CCE-TBD references: SI-11, 1314, Req-10.5.1, Req-10.5.2, 5.1.4, Test attestation on 20121024 by DS
|
Ensure All Logs are Rotated by logrotategroupEdit the file /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler \ /var/log/boot.log /var/log/cron {Edit this line so that it contains a one-space-separated listing of each log file referenced in /etc/rsyslog.conf .
All logs in use on a system must be rotated regularly, or the log files will consume disk space over time, eventually interfering with system operation. The file /etc/logrotate.d/syslog is the
configuration file used by the logrotate program to maintain all
log files written by syslog . By default, it rotates logs weekly and
stores four archival copies of each log. These settings can be
modified by editing /etc/logrotate.conf , but the defaults are
sufficient for purposes of this guide.
Note that logrotate is run nightly by the cron job
/etc/cron.daily/logrotate . If particularly active logs need to be
rotated more often than once a day, some other mechanism must be
used. |
contains 1 rule |
Ensure Logrotate Runs PeriodicallyruleThe # rotate log files frequency dailyRationale: Log files that are not properly rotated run the risk of growing so large that they fill up the /var/log partition. Valuable logging information could be lost if the /var/log partition becomes full. |
System Accounting with auditdgroupThe 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, ExecStartPost=-/sbin/augenrules --loadin 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.rulesin 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)
|
contains 41 rules |
Configure auditd Data Retentiongroup
The audit system writes data to |
contains 7 rules |
Configure auditd Number of Logs RetainedruleDetermine how many log files
num_logs = NUMLOGSSet 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. identifiers: CCE-27348-2 references: AU-1(b), AU-11, IR-5, Req-10.7, Test attestation on 20121024 by DS
|
Configure auditd Max Log File SizeruleDetermine the amount of audit data (in megabytes)
which should be retained in each log file. Edit the file
max_log_file = STOREMBSet 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. identifiers: CCE-27319-3 references: AU-1(b), AU-11, IR-5, Req-10.7, 5.2.1.1, Test attestation on 20121024 by DS
|
Configure auditd max_log_file_action Upon Reaching Maximum Log Sizerule 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 max_log_file_action = ACTIONPossible values for ACTION are described in the auditd.conf man
page. These include:
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 identifiers: CCE-27231-0 references: AU-1(b), AU-4, AU-11, IR-5, Req-10.7, 5.2.1.3, Test attestation on 20121024 by DS
|
Configure auditd space_left Action on Low Disk SpaceruleThe space_left_action = ACTIONPossible values for ACTION are described in the auditd.conf man page.
These include:
email (instead of the default,
which is suspend ) as it is more likely to get prompt attention. Acceptable values
also include suspend , single , and halt .
Rationale:Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption. identifiers: CCE-27375-5 references: AU-1(b), AU-4, AU-5(b), IR-5, 140, 143, Req-10.7, 5.2.1.2, Test attestation on 20121024 by DS
|
Configure auditd admin_space_left Action on Low Disk SpaceruleThe admin_space_left_action = ACTIONSet 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. identifiers: CCE-27370-6 references: AU-1(b), AU-4, AU-5(b), IR-5, 140, 1343, Req-10.7, 5.2.1.2, Test attestation on 20121024 by DS
|
Configure auditd mail_acct Action on Low Disk SpaceruleThe action_mail_acct = rootRationale: Email sent to the root account is typically aliased to the administrators of the system, who can take appropriate action. Remediation script:
|
Configure auditd to use audispd's syslog pluginruleTo configure the $ sudo service auditd restartRationale: The auditd service does not include the ability to send audit records to a centralized server for management directly. It does, however, include a plug-in for audit event multiplexor (audispd) to pass audit records to the local syslog server identifiers: CCE-27341-7 references: AU-1(b), AU-3(2), IR-5, 136, Req-10.5.3
|
Configure auditd Rules for Comprehensive AuditinggroupThe
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 |
contains 32 rules |
Records Events that Modify Date and Time InformationgroupArbitrary 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. |
contains 5 rules |
Record attempts to alter time through adjtimexruleIf the -a always,exit -F arch=b32 -S adjtimex -k audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S adjtimex -k audit_time_rulesIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S adjtimex -k audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S adjtimex -k audit_time_rulesThe -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rulesRationale: 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. identifiers: CCE-27290-6 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 5.2.4, Req-10.4.2.b, 1487, 169
|
Record attempts to alter time through settimeofdayruleIf the -a always,exit -F arch=b32 -S settimeofday -k audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S settimeofday -k audit_time_rulesIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S settimeofday -k audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S settimeofday -k audit_time_rulesThe -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rulesRationale: 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. identifiers: CCE-27216-1 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 5.2.4, Req-10.4.2.b, 1487, 169
|
Record Attempts to Alter Time Through stimeruleIf the -a always,exit -F arch=b32 -S stime -k audit_time_rulesSince the 64 bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32 bit and 64 bit systems). If the auditd daemon is configured to use the auditctl utility to
read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file for both 32 bit and 64 bit systems:
-a always,exit -F arch=b32 -S stime -k audit_time_rulesSince the 64 bit version of the "stime" system call is not defined in the audit lookup table, the corresponding "-F arch=b64" form of this rule is not expected to be defined on 64 bit systems (the aforementioned "-F arch=b32" stime rule form itself is sufficient for both 32 bit and 64 bit systems). The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined system calls: -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rulesRationale: 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. identifiers: CCE-27299-7 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, Req-10.4.2.b, 1487, 169
|
Record Attempts to Alter Time Through clock_settimeruleIf the -a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-changeIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-changeIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-changeIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-changeThe -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rulesRationale: 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. identifiers: CCE-27219-5 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 5.2.4, Req-10.4.2.b, 1487, 169
|
Record Attempts to Alter the localtime FileruleIf the -w /etc/localtime -p wa -k audit_time_rulesIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-w /etc/localtime -p wa -k audit_time_rulesThe -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport 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. identifiers: CCE-27310-2 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(b), IR-5, 5.2.4, Req-10.4.2.b, 1487, 169
|
Record Events that Modify the System's Discretionary Access ControlsgroupAt a minimum the audit system should collect file permission
changes for all users and root. Note that the "-F arch=b32" lines should be
present even on a 64 bit system. These commands identify system calls for
auditing. Even if the system is 64 bit it can still execute 32 bit system
calls. Additionally, these rules can be configured in a number of ways while
still achieving the desired effect. An example of this is that the "-S" calls
could be split up and placed on separate lines, however, this is less efficient.
Add the following to -a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf your system is 64 bit then these lines should be duplicated and the arch=b32 replaced with arch=b64 as follows: -a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod |
contains 13 rules |
Record Events that Modify the System's Discretionary Access Controls - chmodruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27339-1 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - chownruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27364-9 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - fchmodruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27393-8 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - fchmodatruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27388-8 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - fchownruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27356-5 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - fchownatruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27387-0 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - fremovexattrruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27353-2 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - fsetxattrruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27389-6 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - lchownruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27083-5 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - lremovexattrruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27410-0 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - lsetxattrruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27280-7 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - removexattrruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27367-2 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - setxattrruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27213-8 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify User/Group InformationruleIf the -w /etc/group -p wa -k audit_rules_usergroup_modification -w /etc/passwd -p wa -k audit_rules_usergroup_modification -w /etc/gshadow -p wa -k audit_rules_usergroup_modification -w /etc/shadow -p wa -k audit_rules_usergroup_modification -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/group -p wa -k audit_rules_usergroup_modification -w /etc/passwd -p wa -k audit_rules_usergroup_modification -w /etc/gshadow -p wa -k audit_rules_usergroup_modification -w /etc/shadow -p wa -k audit_rules_usergroup_modification -w /etc/security/opasswd -p wa -k audit_rules_usergroup_modificationRationale: 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. identifiers: CCE-27192-4 references: AC-2(4), AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 18, 172, 1403, 2130, 030710, Req-10.2.5, 5.2.5, SRG–OS–000004–GPOS–00004, SRG–OS–000239–GPOS–00089, SRG–OS–000241–GPOS–00090, SRG–OS–000241–GPOS–00091, SRG–OS–000303–GPOS–00120, SRG–OS–000476–GPOS–00221
|
Record Events that Modify the System's Network EnvironmentruleIf the -a always,exit -F arch=ARCH -S sethostname -S setdomainname -k audit_rules_networkconfig_modification -w /etc/issue -p wa -k audit_rules_networkconfig_modification -w /etc/issue.net -p wa -k audit_rules_networkconfig_modification -w /etc/hosts -p wa -k audit_rules_networkconfig_modification -w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modificationIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S sethostname -S setdomainname -k 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_modificationRationale: The network environment should not be modified by anything other than administrator action. Any change to network parameters should be audited. identifiers: CCE-27076-9 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, Req-10.5.5, 5.2.6
|
System Audit Logs Must Have Mode 0640 or Less Permissiverule
If $ sudo chmod 0640 audit_file Otherwise, change the mode of the audit log files with the following command: $ sudo chmod 0600 audit_fileRationale: If users can write to audit logs, audit trails can be modified or destroyed. identifiers: CCE-27205-4 references: AC-6, AU-1(b), AU-9, IR-5, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-10.5, Test attestation on 20121024 by DS
|
System Audit Logs Must Be Owned By Rootrule
To properly set the owner of $ sudo chown root /var/logRationale: Unauthorized disclosure of audit records can reveal system and configuration data to attackers, thus compromising its confidentiality. identifiers: CCE-RHEL7-CCE-TBD references: AC-6, AU-1(b), AU-9, IR-5, 163, SRG-OS-000058-GPOS-00028, 030120, Req-10.5.1, Test attestation on 20121024 by DS
|
Record Events that Modify the System's Mandatory Access ControlsruleIf the -w /etc/selinux/ -p wa -k MAC-policyIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-w /etc/selinux/ -p wa -k MAC-policyRationale: 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. identifiers: CCE-27168-4 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, Req-10.5.5, 5.2.7
|
Record Attempts to Alter Logon and Logout EventsruleThe audit system already collects login information for all users
and root. If the -w /var/log/tallylog -p wa -k logins -w /var/run/faillock/ -p wa -k logins -w /var/log/lastlog -p wa -k loginsIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules 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 loginsRationale: Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. identifiers: CCE-27204-7 references: AC-17(7), AU-1(b), AU-12(a), AU-12(c), IR-5, 172, 2884, SRG-OS-000392-GPOS-00172, SRG-OS-000470-GPOS-00214, SRG-OS-000473-GPOS-00218, 030490, Req-10.2.3, 5.2.8
|
Record Attempts to Alter Process and Session Initiation InformationruleThe audit system already collects process information for all
users and root. If the -w /var/run/utmp -p wa -k session -w /var/log/btmp -p wa -k session -w /var/log/wtmp -p wa -k sessionIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file in order to watch for attempted manual
edits of files involved in storing such process information:
-w /var/run/utmp -p wa -k session -w /var/log/btmp -p wa -k session -w /var/log/wtmp -p wa -k sessionRationale: Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. identifiers: CCE-27301-1 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, Req-10.2.3, 5.2.9
|
Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful)ruleAt a minimum the audit system should collect unauthorized file
accesses for all users and root. If the -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k accessIf the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k accessIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k accessIf the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k accessRationale: 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. identifiers: CCE-27347-4 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 172, 2884, SRG-OS-000064-GPOS-00033, SRG-OS-000458-GPOS-00203, SRG-OS-000461-GPOS-00205, SRG-OS-000392-GPOS-00172, 030420, Req-10.2.4, Req-10.2.1, 5.2.10
|
Ensure auditd Collects Information on the Use of Privileged CommandsruleAt a minimum the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid / setgid programs, run the following command for each local partition PART: $ sudo find PART -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/nullIf the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add a line of
the following form to a file with suffix .rules in the directory
/etc/audit/rules.d for each setuid / setgid program on the system,
replacing the SETUID_PROG_PATH part with the full path of that setuid /
setgid program in the list:
-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=4294967295 -k privilegedIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add a line of the following
form to /etc/audit/audit.rules for each setuid / setgid program on the
system, replacing the SETUID_PROG_PATH part with the full path of that
setuid / setgid program in the list:
-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=4294967295 -k privilegedRationale: Misuse of privileged functions, either intentionally or unintentionally by
authorized users, or by unauthorized external entities that have compromised system accounts,
is a serious and ongoing concern and can have significant adverse impacts on organizations.
Auditing the use of privileged functions is one way to detect such misuse and identify
the risk from insider and advanced persistent threast.
identifiers: CCE-27437-3 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-2(4), AU-6(9), AU-12(a), AU-12(c), IR-5, 2234, SRG-OS-000327-GPOS-00127, 030310, Req-10.2.2, 5.2.10, Test attestation on 20121024 by DS
|
Ensure auditd Collects Information on Exporting to Media (successful)ruleAt a minimum the audit system should collect media exportation
events for all users and root. If the -a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=4294967295 -k exportIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=4294967295 -k exportRationale: 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. identifiers: CCE-27447-2 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-3(1), AU-12(a), AU-12(c), IR-5, 135, 2884, SRG-OS-000042-GPOS-00020, SRG-OS-000392-GPOS-00172, 030530, Req-10.2.7, 5.2.13, Test attestation on 20121024 by DS
|
Ensure auditd Collects File Deletion Events by UserruleAt a minimum the audit system should collect file deletion events
for all users and root. If the -a always,exit -F arch=ARCH -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k deleteIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k deleteRationale: 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. identifiers: CCE-27206-2 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 366, SRG-OS-000480-GPOS-00227, 030750, Req-10.2.7, 5.2.14
|
Ensure auditd Collects System Administrator ActionsruleAt a minimum the audit system should collect administrator actions
for all users and root. If the -w /etc/sudoers -p wa -k actionsIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-w /etc/sudoers -p wa -k actionsRationale: 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. identifiers: CCE-27461-3 references: AC-2(7)(b), AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.2.2, Req-10.2.5.b, Test attestation on 20121024 by DS
|
Ensure auditd Collects Information on Kernel Module Loading and UnloadingruleIf the -w /usr/sbin/insmod -p x -k modules -w /usr/sbin/rmmod -p x -k modules -w /usr/sbin/modprobe -p x -k modules -a always,exit -F arch=ARCH -S init_module -S delete_module -k modulesIf the auditd daemon is configured to use the auditctl utility to read audit
rules during daemon startup, add the following lines to /etc/audit/audit.rules file
in order to capture kernel module loading and unloading events, setting ARCH to either b32 or
b64 as appropriate for your system:
-w /usr/sbin/insmod -p x -k modules -w /usr/sbin/rmmod -p x -k modules -w /usr/sbin/modprobe -p x -k modules -a always,exit -F arch=ARCH -S init_module -S delete_module -k modulesRationale: 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. identifiers: CCE-27129-6 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 172, SRG-OS-000471-GPOS-00216, SRG-OS-000477, GPOS-00222, 030670, Req-10.2.7, 5.2.17
|
Make the auditd Configuration ImmutableruleIf the -e 2If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file in order to make the auditd configuration
immutable:
-e 2With this setting, a reboot will be required to change any audit rules. Rationale: Making the audit configuration immutable prevents accidental as well as malicious modification of the audit rules, although it may be problematic if legitimate changes are needed during system operation identifiers: CCE-27097-5 references: AC-6, AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, Req-10.5.2, 5.2.18
|
Enable auditd ServiceruleThe $ sudo systemctl enable auditd.serviceRationale: 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.
identifiers: CCE-27407-6 references: AU-3, AC-17(1), AU-1(b), AU-10, AU-12(a), AU-12(c), AU-14(1), IR-5, 126, 131, SRG-OS-000038-GPOS-00016, SRG-OS-000039-GPOS-00017, SRG-OS-000042-GPOS-00021, SRG-OS-000254-GPOS-00095, SRG-OS-000255-GPOS-00096, 030010, Req-10, 5.2.2, Test attestation on 20121024 by DS
|
Enable Auditing for Processes Which Start Prior to the Audit DaemonruleTo ensure all processes can be audited, even those which start
prior to the audit daemon, add the argument GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 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 -ocommand as follows:
Each process on the system carries an "auditable" flag which indicates whether
its activities can be audited. Although identifiers: CCE-27212-0 references: AC-17(1), AU-14(1), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-10, IR-5, 1464, 130, Req-10.3, 5.2.3
|
Servicesgroup
The best protection against vulnerable software is running less software. This section describes how to review
the software which Red Hat Enterprise Linux 7 installs on a system and disable software which is not needed. It
then enumerates the software packages installed on a default Red Hat Enterprise Linux 7 system and provides guidance about which
ones can be safely disabled.
|
contains 4 rules |
SSH ServergroupThe 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 |
contains 1 rule |
Configure OpenSSH Server if NecessarygroupIf the system needs to act as an SSH server, then
certain changes should be made to the OpenSSH daemon configuration
file |
contains 1 rule |
Set SSH Idle Timeout IntervalruleSSH allows administrators to set an idle timeout
interval.
After this interval has passed, the idle user will be
automatically logged out.
ClientAliveInterval intervalThe timeout interval is given in seconds. To have a timeout of 10 minutes, set interval to 600. If a shorter timeout has already been set for the login shell, that value will preempt any SSH setting made here. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle. Rationale: Terminating an idle ssh session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been let unattended. identifiers: CCE-27433-2 references: AC-2(5), SA-8(i), AC-12, 1133, 2361, SRG-OS-000163-GPOS-00072, SRG-OS-000279-GPOS-00109, 040190, Req-8.1.8, 6.2.12, Test attestation on 20121024 by DS
|
Network Time ProtocolgroupThe 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 machines, and that their time is consistent with the
outside world.
|
contains 3 rules |
Enable the NTP Daemonrule
The $ sudo systemctl enable chronyd.serviceNote: The chronyd daemon is enabled by default.
The ntpd service can be enabled with the following command:
$ sudo systemctl enable ntpd.serviceNote: 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 identifiers: CCE-27444-9 references: AU-8(1), 160, Req-10.4, 3.6, Test attestation on 20121024 by DS
|
Specify a Remote NTP ServerruleDepending on specific functional requirements of a concrete
production environment, the Red Hat Enterprise Linux 7 Server system can be
configured to utilize the services of the
server ntpserverThis instructs the NTP software to contact that remote server to obtain time data. Rationale: Synchronizing with an NTP server makes it possible to collate system logs from multiple sources or correlate computer events with real time events. identifiers: CCE-27278-1 references: AU-8(1), 160, Req-10.4.1, Req-10.4.3, 3.6, Test attestation on 20121024 by DS
|
Specify Additional Remote NTP ServersruleDepending on specific functional requirements of a concrete
production environment, the Red Hat Enterprise Linux 7 Server system can be
configured to utilize the services of the
server ntpserverRationale: Specifying additional NTP servers increases the availability of accurate time data, in the event that one of the specified servers becomes unavailable. This is typical for a system acting as an NTP server for other systems. identifiers: CCE-27012-4 references: AU-8(1), Req-10.4.3
|