Guide to the Secure Configuration of Red Hat Enterprise Linux 7
with profile Draft PCI-DSS v3 Control Baseline for Red Hat Enterprise Linux 7
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 CentOS. The result is a generally useful SCAP Security Guide benchmark with the following caveats:
- CentOS is not an exact copy of Red Hat Enterprise Linux. There may be configuration differences that produce false positives and/or false negatives. If this occurs please file a bug report.
- CentOS has its own build system, compiler options, patchsets, and is a community supported, non-commercial operating system. CentOS 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 CentOS.
Members of the CentOS 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 | Draft 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.9
- draft (as of 2015-12-07)
Platforms
- cpe:/o:redhat:enterprise_linux:7
- cpe:/o:centos:centos:7
- cpe:/o:redhat:enterprise_linux:7::client
Table of Contents
- Introduction
- System Settings
- Installing and Maintaining Software
- File Permissions and Masks
- SELinux
- Account and Access Control
- Network Configuration and Firewalls
- Configure Syslog
- System Accounting with auditd
- Services
- Obsolete Services
- Base Services
- Cron and At Daemons
- SSH Server
- X Window System
- Avahi Server
- Print Support
- DHCP
- Network Time Protocol
- Mail Server Software
- LDAP
- NFS and RPC
- DNS Server
- FTP Server
- Web Server
- IMAP and POP3 Server
- Samba(SMB) Microsoft Windows File Sharing Server
- Proxy Server
- SNMP Server
- Documentation to Support DISA OS SRG Mapping
Checklist
contains 75 rules |
System Settingsgroup |
contains 73 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 8 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, Test attestation on 20150407 by sdw Remediation script:
|
Ensure gpgcheck Enabled In Main Yum ConfigurationruleThe gpgcheck=1Rationale: 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-26989-4 references: CM-5(3), SI-7, MA-1(b), 1749, 366, 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, 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-26853-2 references: SI-2, MA-1(b), http://iase.disa.mil/stigs/cci/Pages/index.aspx, 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 4 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 3 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-26741-9 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, Test attestation on 20121024 by DS Remediation script:
|
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. identifiers: CCE-RHEL7-CCE-TBD references: CM-6(d), CM-6(3), SC-28, SI-7 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-RHEL7-CCE-TBD references: CM-3(d), CM-3(e), CM-6(d), CM-6(3), SC-28, SI-7, 374, 416, 1069, 1263, 1297, 1589 Remediation script:
|
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 1 rule |
Verify File Hashes with RPMruleThe RPM package management system can check the hashes of installed software packages, including many that are important to system security. 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. identifiers: CCE-RHEL7-CCE-TBD |
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, Test attestation on 20121026 by DS Remediation script:
|
Verify Group Who Owns shadow Filerule
To properly set the group owner of $ sudo chgrp root xsl:value-of select="@file"/>Rationale: The identifiers: CCE-27125-4 references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:
|
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, Test attestation on 20121026 by DS Remediation script:
|
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, Test attestation on 20121026 by DS Remediation script:
|
Verify Group Who Owns group Filerule
To properly set the group owner of $ sudo chgrp root xsl:value-of select="@file"/>Rationale: The identifiers: CCE-27037-1 references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:
|
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, Test attestation on 20121026 by DS Remediation script:
|
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, Test attestation on 20121026 by DS Remediation script:
|
Verify Group Who Owns passwd Filerule
To properly set the group owner of $ sudo chgrp root xsl:value-of select="@file"/>Rationale: The identifiers: CCE-26639-5 references: AC-6, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121026 by DS Remediation script:
|
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, Test attestation on 20121026 by DS Remediation script:
|
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 16 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 4 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 2 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-27010-8 references: IA-5(b), IA-5(c), IA-5(1)(a), Test attestation on 20121024 by DS Remediation script:
|
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-27144-5 references: IA-5(h), http://iase.disa.mil/stigs/cci/Pages/index.aspx, 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: Setting the password maximum age ensures users are required to periodically change their passwords. This could possibly decrease the utility of a stolen password. 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), 180, 199, 76, Test attestation on 20121026 by DS Remediation script:
|
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 1 rule |
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-TBD references: AC-2(2), AC-2(3), 16, 17, 795 Remediation script:
|
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 10 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 Requiring digits makes password guessing attacks more difficult by ensuring a larger search space. identifiers: CCE-27163-5 references: IA-5(b), IA-5(c), 194, 194, 71, Test attestation on 20121024 by DS Remediation script:
|
Set Password Minimum LengthruleThe pam_pwquality module's Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password. identifiers: CCE-26615-5 references: IA-5(1)(a), 205, 78, Test attestation on 20140928 by swells Remediation script:
|
Set Password Strength Minimum Uppercase CharactersruleThe pam_pwquality module's Requiring a minimum number of uppercase characters makes password guessing attacks more difficult by ensuring a larger search space. identifiers: CCE-26988-6 references: IA-5(b), IA-5(c), IA-5(1)(a), 192, 69, Test attestation on 20121024 by DS Remediation script:
|
Set Password Strength Minimum Lowercase CharactersruleThe pam_pwquality module's Requiring a minimum number of lowercase characters makes password guessing attacks more difficult by ensuring a larger search space. identifiers: CCE-27111-4 references: IA-5(b), IA-5(c), IA-5(1)(a), 193, 70, Test attestation on 20121024 by DS Remediation script:
|
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 2 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-26891-2 Remediation script:
|
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 Remediation script:
|
Set Password Hashing AlgorithmgroupThe system's default algorithm for storing password hashes in
|
contains 3 rules |
Set Password Hashing Algorithm in /etc/pam.d/system-authrule
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: Using a stronger hashing algorithm makes password cracking attacks more difficult. identifiers: CCE-27104-9 references: IA-5(b), IA-5(c), IA-5(1)(c), IA-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:
|
Set Password Hashing Algorithm in /etc/login.defsrule
In ENCRYPT_METHOD SHA512Rationale: 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, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:
|
Set Password Hashing Algorithm in /etc/libuser.confrule
In crypt_style = sha512Rationale: Using a stronger hashing algorithm makes password cracking attacks more difficult. identifiers: CCE-27053-8 references: IA-5(b), IA-5(c), IA-5(1)(c), IA-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, 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-RHEL7-CCE-TBD references: 53 |
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 2 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, Test attestation on 20121026 by DS Remediation script:
|
Verify /boot/grub2/grub.cfg Group OwnershipruleThe file $ sudo chgrp root xsl:value-of select="@file"/>Rationale:
The identifiers: CCE-26812-8 references: AC-6(7), 225, Test attestation on 20121026 by DS 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. identifiers: CCE-RHEL7-CCE-TBD references: AC-17, MA-4, SC-9, 1130, 1131 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 1 rule |
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. identifiers: CCE-RHEL7-CCE-TBD |
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 38 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-RHEL7-CCE-TBD references: AU-1(b), AU-11, IR-5, 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-RHEL7-CCE-TBD references: AU-1(b), AU-11, IR-5, 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-RHEL7-CCE-TBD references: AU-1(b), AU-4, AU-11, IR-5, 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-RHEL7-CCE-TBD references: AU-1(b), AU-4, AU-5(b), IR-5, 140, 143, Test attestation on 20121024 by DS Remediation script:
|
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-RHEL7-CCE-TBD references: AU-1(b), AU-4, AU-5(b), IR-5, 140, 1343, Test attestation on 20121024 by DS Remediation script:
|
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. identifiers: CCE-RHEL7-CCE-TBD |
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-RHEL7-CCE-TBD references: AU-1(b), AU-3(2), IR-5, 136 Remediation script:
|
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 29 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 -S clock_settime -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-RHEL7-CCE-TBD references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 1487, 169 Remediation script:
|
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 -S clock_settime -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-RHEL7-CCE-TBD references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 1487, 169 Remediation script:
|
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 -S clock_settime -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-RHEL7-CCE-TBD references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 1487, 169 Remediation script:
|
Record Attempts to Alter Time Through clock_settimeruleIf the -a always,exit -F arch=b32 -S clock_settime -k audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S clock_settime -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 clock_settime -k audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S clock_settime -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 -S clock_settime -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-RHEL7-CCE-TBD references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 1487, 169 Remediation script:
|
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-RHEL7-CCE-TBD references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(b), IR-5, 1487, 169 Remediation script:
|
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-RHEL7-CCE-TBD 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 Remediation script:
|
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-RHEL7-CCE-TBD 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 Remediation script:
|
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-RHEL7-CCE-TBD 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 Remediation script:
|
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-RHEL7-CCE-TBD 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 Remediation script:
|
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-RHEL7-CCE-TBD 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 Remediation script:
|
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-RHEL7-CCE-TBD 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 Remediation script:
|
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-RHEL7-CCE-TBD 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 Remediation script:
|
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-RHEL7-CCE-TBD 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 Remediation script:
|
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-RHEL7-CCE-TBD 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 Remediation script:
|
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-RHEL7-CCE-TBD 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 Remediation script:
|
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-RHEL7-CCE-TBD 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 Remediation script:
|
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-RHEL7-CCE-TBD 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 Remediation script:
|
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-RHEL7-CCE-TBD 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 Remediation script:
|
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_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, 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, 1404, 1405, 1684, 1683, 1685, 1686, 476, 239 Remediation script:
|
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-RHEL7-CCE-TBD references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5 Remediation script:
|
System Audit Logs Must Have Mode 0640 or Less PermissiveruleChange the mode of the audit log files with the following command: $ sudo chmod 0640 audit_fileRationale: If users can write to audit logs, audit trails can be modified or destroyed. identifiers: CCE-27004-1 references: AC-6, AU-1(b), AU-9, IR-5, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:
|
System Audit Logs Must Be Owned By Rootrule
To properly set the owner of $ sudo chown root /var/logRationale: Failure to give ownership of the audit log files to root allows the designated owner, and unauthorized users, potential access to sensitive information. identifiers: CCE-RHEL7-CCE-TBD references: AC-6, AU-1(b), AU-9, IR-5, 166, 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-RHEL7-CCE-TBD references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5 Remediation script:
|
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 Remediation script:
|
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-RHEL7-CCE-TBD 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 Remediation script:
|
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-RHEL7-CCE-TBD 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, Test attestation on 20121024 by DS Remediation script:
|
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, 172, 468 Remediation script:
|
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-RHEL7-CCE-TBD 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, Test attestation on 20121024 by DS Remediation script:
|
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, 477 Remediation script:
|
Enable auditd ServiceruleThe $ sudo systemctl enable auditdRationale: Ensuring the identifiers: CCE-RHEL7-CCE-TBD references: AC-17(1), AU-1(b), AU-10, AU-12(a), AU-12(c), IR-5, 347, 157, 172, 880, 1353, 1462, 1487, 1115, 1454, 067, 158, 831, 1190, 1312, 1263, 130, 120, 1589, Test attestation on 20121024 by DS Remediation script:
|
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-RHEL7-CCE-TBD 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 Remediation script:
|
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 2 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 15 minutes, set interval to 900. 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: Causing idle users to be automatically logged out guards against compromises one system leading trivially to compromises on another. identifiers: CCE-26611-4 references: AC-2(5), SA-8, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS Remediation script:
|
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 1 rule |
Enable the NTP Daemonrule
The $ sudo systemctl enable chronydNote: The chronyd daemon is enabled by default.
The ntpd service can be enabled with the following command:
$ sudo systemctl enable ntpdNote: 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-RHEL7-CCE-TBD references: AU-8(1), 160, Test attestation on 20121024 by DS |