Guide to the Secure Configuration of Red Hat Enterprise Linux 6
with profile PCI-DSS v3 Control Baseline for Red Hat Enterprise Linux 6
scap-security-guide
package which is developed at
http://fedorahosted.org/scap-security-guide.
Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in any operational scenario. 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 RHEL 6, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.
Profile Title | PCI-DSS v3 Control Baseline for Red Hat Enterprise Linux 6 |
---|---|
Profile ID | xccdf_org.ssgproject.content_profile_pci-dss |
Revision History
Current version: 0.9
- draft (as of 2015-07-30)
Platforms
- cpe:/o:redhat:enterprise_linux:6
- cpe:/o:redhat:enterprise_linux:6::client
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 Settingsgroup |
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 11 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: The Red Hat GPG key is necessary to cryptographically verify packages are from Red Hat. identifiers: CCE-26506-6, DISA FSO RHEL-06-000008 references: SI-7, MA-1(b), 351, Test attestation on 20120928 by MM Remediation script:
|
Ensure gpgcheck Enabled In Main Yum ConfigurationruleThe gpgcheck=1Rationale: Ensuring the validity of packages' cryptographic signatures prior to installation ensures the authenticity of the software and protects against malicious tampering. identifiers: CCE-26709-6, DISA FSO RHEL-06-000013 references: SI-7, MA-1(b), 352, 663, Test attestation on 20120928 by MM |
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: Ensuring all packages' cryptographic signatures are valid prior to installation ensures the authenticity of the software and protects against malicious tampering. identifiers: CCE-26647-8, DISA FSO RHEL-06-000015 references: SI-7, MA-1(b), 352, 663, Test attestation on 20120928 by MM |
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-27635-2, DISA FSO RHEL-06-000011 references: SI-2, MA-1(b), 1227, 1233, 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-27024-9, DISA FSO RHEL-06-000016 references: CM-3(d), CM-3(e), CM-6(d), SC-28, SI-7, 1069, 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-27221-1 references: CM-6(d), SC-28, SI-7 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. identifiers: CCE-27135-3, DISA FSO RHEL-06-000018 references: CM-3(d), CM-3(e), CM-6(d), SC-28, SI-7, 374, 416, 1069, 1263, 1297, 1589 |
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-27222-9, DISA FSO RHEL-06-000306 references: CM-3(d), CM-3(e), CM-6(d), 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 2 rules |
Verify and Correct File Permissions with RPMruleThe RPM package management system can check file access permissions of installed software packages, including many that are important to system security. 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 PACKAGENAMERationale: 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-26731-0, DISA FSO RHEL-06-000518 |
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-27223-7, DISA FSO RHEL-06-000519 |
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 Softwarerule
The 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. Host-based intrusion detection tools provide a system-level defense when an intruder gains access to a system or network. identifiers: CCE-27409-2, DISA FSO RHEL-06-000285 |
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 ext4 | 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-26947-2, DISA FSO RHEL-06-000033 references: AC-6, 225, Test attestation on 20121026 by DS Remediation script:
|
Verify Group Who Owns shadow Filerule
To properly set the group owner of $ sudo chgrp root /etc/shadowRationale: The identifiers: CCE-26967-0, DISA FSO RHEL-06-000034 references: AC-6, 225, 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-26992-8, DISA FSO RHEL-06-000035 references: AC-6, 225, 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-26822-7, DISA FSO RHEL-06-000042 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 /etc/groupRationale: The identifiers: CCE-26930-8, DISA FSO RHEL-06-000043 references: AC-6, 225, 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-26954-8, DISA FSO RHEL-06-000044 references: AC-6, 225, 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-26953-0, DISA FSO RHEL-06-000039 references: AC-6, 225, Test attestation on 20121026 by DS Remediation script:
|
Verify Group Who Owns passwd Filerule
To properly set the group owner of $ sudo chgrp root /etc/passwdRationale: The identifiers: CCE-26856-5, DISA FSO RHEL-06-000040 references: AC-6, 225, 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-26868-0, DISA FSO RHEL-06-000041 references: AC-6, 225, 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 RHEL 6. |
contains 24 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
onto 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-27038-9, DISA FSO RHEL-06-000030 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-26476-2, DISA FSO RHEL-06-000031 references: IA-5(h), 201, 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:
Inconsistency in GIDs between identifiers: CCE-27379-7, DISA FSO RHEL-06-000294 references: 366, 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 90A 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-26985-2, DISA FSO RHEL-06-000053 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 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=NUM_DAYSA 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-27283-1, DISA FSO RHEL-06-000334 references: AC-2(2), AC-2(3), 16, 17, 795 Remediation script:
|
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. identifiers: CCE-27609-7, DISA FSO RHEL-06-000296 |
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, if using pam_cracklibgroupThe password requisite pam_cracklib.so try_first_pass retry=3and then alter it to read: password required pam_cracklib.so try_first_pass retry=3 maxrepeat=3 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 difok=4If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth .
The 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_cracklib module's Requiring digits makes password guessing attacks more difficult by ensuring a larger search space. identifiers: CCE-26374-9, DISA FSO RHEL-06-000056 references: IA-5(b), IA-5(c), 194, 194, Test attestation on 20121024 by DS Remediation script:
|
Set Password Minimum LengthruleThe pam_cracklib 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 |
Set Password Strength Minimum Uppercase CharactersruleThe pam_cracklib module's Requiring a minimum number of uppercase characters makes password guessing attacks more difficult by ensuring a larger search space. identifiers: CCE-26601-5, DISA FSO RHEL-06-000057 references: IA-5(b), IA-5(c), IA-5(1)(a), 192, Test attestation on 20121024 by DS Remediation script:
|
Set Password Strength Minimum Lowercase CharactersruleThe pam_cracklib module's Requiring a minimum number of lowercase characters makes password guessing attacks more difficult by ensuring a larger search space. identifiers: CCE-26631-2, DISA FSO RHEL-06-000059 references: IA-5(b), IA-5(c), IA-5(1)(a), 193, 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 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-26844-1, DISA FSO RHEL-06-000061 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-27110-6, DISA FSO RHEL-06-000356 Remediation script:
|
Limit Password ReuseruleDo not allow users to reuse recent passwords. This can
be accomplished by using the password sufficient pam_unix.so existing_options remember=4The DoD STIG requirement is 5 passwords.Rationale: Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user. identifiers: CCE-26741-9, DISA FSO RHEL-06-000274 references: IA-5(f), IA-5(1)(e), 200, Test attestation on 20121024 by DS 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-26303-8, DISA FSO RHEL-06-000062 references: IA-5(b), IA-5(c), IA-5(1)(c), IA-7, 803, 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-27228-6, DISA FSO RHEL-06-000063 references: IA-5(b), IA-5(c), IA-5(1)(c), IA-7, 803, 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-27229-4, DISA FSO RHEL-06-000064 references: IA-5(b), IA-5(c), IA-5(1)(c), IA-7, 803, Test attestation on 20121026 by DS |
Set Last Login/Access NotificationruleTo configure the system to notify users of last login/access
using session required pam_lastlog.so 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-27291-4, DISA FSO RHEL-06-000372 references: 366 Remediation script:
|
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 7 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 RHEL boot loader for x86 systems is called GRUB. 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 /etc/grub.conf User OwnershipruleThe file $ sudo chown root /etc/grub.confRationale: Only root should be able to modify important boot parameters. identifiers: CCE-26995-1, DISA FSO RHEL-06-000065 references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 225, Test attestation on 20121026 by DS Remediation script:
|
Verify /etc/grub.conf Group OwnershipruleThe file $ sudo chgrp root /etc/grub.confRationale:
The identifiers: CCE-27022-3, DISA FSO RHEL-06-000066 references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 225, Test attestation on 20121026 by DS Remediation script:
|
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 5 rules |
Configure GUI Screen LockinggroupIn the default GNOME desktop, the screen can be locked
by choosing Lock Screen from the System menu.
|
contains 4 rules |
Set GNOME Login Inactivity TimeoutruleRun the following command to set the idle time-out value for inactivity in the GNOME desktop to 15 minutes: $ sudo gconftool-2 \ --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type int \ --set /desktop/gnome/session/idle_delay 15Rationale: Setting the idle delay controls when the screensaver will start, and can be combined with screen locking to prevent access from passersby. identifiers: CCE-26828-4, DISA FSO RHEL-06-000257 Remediation script:
|
GNOME Desktop Screensaver Mandatory UseruleRun the following command to activate the screensaver in the GNOME desktop after a period of inactivity: $ sudo gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type bool \ --set /apps/gnome-screensaver/idle_activation_enabled trueRationale: 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-26600-7, DISA FSO RHEL-06-000258 Remediation script:
|
Enable Screen Lock Activation After Idle PeriodruleRun the following command to activate locking of the screensaver in the GNOME desktop when it is activated: $ sudo gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type bool \ --set /apps/gnome-screensaver/lock_enabled trueRationale: Enabling the activation of the screen lock after an idle period ensures password entry will be required in order to access the system, preventing access by passersby. identifiers: CCE-26235-2, DISA FSO RHEL-06-000259 Remediation script:
|
Implement Blank ScreensaverruleRun the following command to set the screensaver mode in the GNOME desktop to a blank screen: $ sudo gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type string \ --set /apps/gnome-screensaver/mode blank-onlyRationale: Setting the screensaver mode to blank-only conceals the contents of the display from passersby. identifiers: CCE-26638-7, DISA FSO RHEL-06-000260 Remediation script:
|
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. identifiers: CCE-27440-7, DISA FSO RHEL-06-000349 |
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 RHEL 6 with Openswan. |
contains 1 rule |
Install openswan PackageruleThe Openswan package provides an implementation of IPsec
and IKE, which permits the creation of secure tunnels over
untrusted networks.
The $ sudo yum install openswanRationale: 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-27626-1, DISA FSO RHEL-06-000321 references: AC-17, MA-4, SC-8, 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 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-26812-8, DISA FSO RHEL-06-000133 references: AC-6, 1314, 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-26821-9, DISA FSO RHEL-06-000134 references: AC-6, 1314, 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-27190-8, DISA FSO RHEL-06-000135 references: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf, 1314, 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. identifiers: CCE-27014-0, DISA FSO RHEL-06-000138 |
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, 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-27522-2, DISA FSO RHEL-06-000159 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-27550-3, DISA FSO RHEL-06-000160 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-27237-7, DISA FSO RHEL-06-000161 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-27238-5, DISA FSO RHEL-06-000005 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-27239-3 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-27241-9, DISA FSO RHEL-06-000313 |
Configure auditd to use audispd 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 an audit event multiplexor plugin (audispd) to pass audit records to the local syslog server identifiers: CCE-26933-2, DISA FSO RHEL-06-000509 |
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 adjtimexruleOn a 32-bit system, add the following to # audit_time_rules -a always,exit -F arch=b32 -S adjtimex -k audit_time_rulesOn a 64-bit system, add the following to /etc/audit/audit.rules :
# audit_time_rules -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-26242-8, DISA FSO RHEL-06-000165 references: AC-3(10), 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 settimeofdayruleOn a 32-bit system, add the following to # audit_time_rules -a always,exit -F arch=b32 -S settimeofday -k audit_time_rulesOn a 64-bit system, add the following to /etc/audit/audit.rules :
# audit_time_rules -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-27203-9, DISA FSO RHEL-06-000167 references: AC-3(10), 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 stimeruleOn a 32-bit system, add the following to # audit_time_rules -a always,exit -F arch=b32 -S stime -k audit_time_rulesOn a 64-bit system, the "-S stime" is not necessary. The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a always,exit -F arch=b64 -S adjtimex -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-27169-2, DISA FSO RHEL-06-000169 references: AC-3(10), 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_settimeruleOn a 32-bit system, add the following to # audit_time_rules -a always,exit -F arch=b32 -S clock_settime -k audit_time_rulesOn a 64-bit system, add the following to /etc/audit/audit.rules :
# audit_time_rules -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-27170-0, DISA FSO RHEL-06-000171 references: AC-3(10), 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 FileruleAdd the following to -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-27172-6, DISA FSO RHEL-06-000173 references: AC-3(10), 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 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>=500 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -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>=500 -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>=500 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -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>=500 -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. Add the following to
-a always,exit -F arch=b32 -S chmod -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S chmod -F auid>=500 -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-26280-8, DISA FSO RHEL-06-000184 references: AC-3(10), 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. Add the following to
-a always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S chown -F auid>=500 -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-27173-4, DISA FSO RHEL-06-000185 references: AC-3(10), 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. Add the following to
-a always,exit -F arch=b32 -S fchmod -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S fchmod -F auid>=500 -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-27174-2, DISA FSO RHEL-06-000186 references: AC-3(10), 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. Add the following to
-a always,exit -F arch=b32 -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S fchmodat -F auid>=500 -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-27175-9, DISA FSO RHEL-06-000187 references: AC-3(10), 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. Add the following to
-a always,exit -F arch=b32 -S fchown -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S fchown -F auid>=500 -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-27177-5, DISA FSO RHEL-06-000188 references: AC-3(10), 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. Add the following to
-a always,exit -F arch=b32 -S fchownat -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S fchownat -F auid>=500 -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-27178-3, DISA FSO RHEL-06-000189 references: AC-3(10), 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. Add the following to
-a always,exit -F arch=b32 -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S fremovexattr -F auid>=500 -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-27179-1, DISA FSO RHEL-06-000190 references: AC-3(10), 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. Add the following to
-a always,exit -F arch=b32 -S fsetxattr -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S fsetxattr -F auid>=500 -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-27180-9, DISA FSO RHEL-06-000191 references: AC-3(10), 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. Add the following to
-a always,exit -F arch=b32 -S lchown -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S lchown -F auid>=500 -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-27181-7, DISA FSO RHEL-06-000192 references: AC-3(10), 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. Add the following to
-a always,exit -F arch=b32 -S lremovexattr -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S lremovexattr -F auid>=500 -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-27182-5, DISA FSO RHEL-06-000193 references: AC-3(10), 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. Add the following to
-a always,exit -F arch=b32 -S lsetxattr -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S lsetxattr -F auid>=500 -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-27183-3, DISA FSO RHEL-06-000194 references: AC-3(10), 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. Add the following to
-a always,exit -F arch=b32 -S removexattr -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S removexattr -F auid>=500 -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-27184-1, DISA FSO RHEL-06-000195 references: AC-3(10), 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. Add the following to
-a always,exit -F arch=b32 -S setxattr -F auid>=500 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S setxattr -F auid>=500 -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-27185-8, DISA FSO RHEL-06-000196 references: AC-3(10), 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 InformationruleAdd the following to # audit_rules_usergroup_modification -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-26664-3, DISA FSO RHEL-06-000174 references: AC-2(4), AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 18, 1403, 1404, 1405, 1684, 1683, 1685, 1686 Remediation script:
|
Record Events that Modify the System's Network EnvironmentruleAdd the following to # audit_rules_networkconfig_modification -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-26648-6, DISA FSO RHEL-06-000182 references: AC-3(10), 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-27243-5, DISA FSO RHEL-06-000383 references: AC-6, AU-1(b), AU-9, IR-5, 166, 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-27244-3, DISA FSO RHEL-06-000384 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 ControlsruleAdd the following to -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-26657-7, DISA FSO RHEL-06-000183 references: AC-3(10), 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 Login and Logout Eventsrule
The audit system already collects login info for all users and root. To watch for attempted manual edits of
files involved in storing login events, add the following to -w /var/log/faillog -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-26691-6 |
Record Attempts to Alter Process and Session Initiation Informationrule The audit system already collects process information for all
users and root. To watch for attempted manual edits of files involved in
storing such process information, add the following to
-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-26610-6 references: AC-3(10), 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. Add the following
to -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>=500 -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>=500 -F auid!=4294967295 -k accessIf the system is 64 bit then also add the following: -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>=500 -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>=500 -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-26712-0, DISA FSO RHEL-06-000197 references: AC-3(10), 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 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/nullThen, for each setuid / setgid program on the system, add a line of the following form to /etc/audit/audit.rules , where
SETUID_PROG_PATH is the full path to each setuid / setgid program
in the list:
-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=500 -F auid!=4294967295 -k privilegedRationale: Privileged programs are subject to escalation-of-privilege attacks, which attempt to subvert their normal role of providing some necessary but limited capability. As such, motivation exists to monitor these programs for unusual activity. identifiers: CCE-26457-2, DISA FSO RHEL-06-000198 references: AC-3(10)), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AC-6(9), AU-12(a), AU-12(c), IR-5, 40, Test attestation on 20140703 by JL 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. Add the following to
-a always,exit -F arch=ARCH -S mount -F auid>=500 -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-26573-6, DISA FSO RHEL-06-000199 references: AC-3(10), 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. Add the following to
-a always,exit -F arch=ARCH -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -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-26651-0, DISA FSO RHEL-06-000200 references: AC-3(10), 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 System Administrator ActionsruleAt a minimum the audit system should collect
administrator actions for all users and root. Add the following to
-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-26662-7, DISA FSO RHEL-06-000201 references: AC-2(7)(b), AC-3(10), 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 UnloadingruleAdd the following to -w /sbin/insmod -p x -k modules -w /sbin/rmmod -p x -k modules -w /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-26611-4, DISA FSO RHEL-06-000202 references: AC-3(10), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126 Remediation script:
|
Make the auditd Configuration ImmutableruleAdd the following to -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-26612-2 references: AC-6, AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5 Remediation script:
|
Enable auditd ServiceruleThe $ sudo chkconfig --level 2345 auditd onRationale: Ensuring the identifiers: CCE-27058-7, DISA FSO RHEL-06-000145 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
kernel /vmlinuz-version ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet audit=1Rationale:
Each process on the system carries an "auditable" flag which
indicates whether its activities can be audited. Although identifiers: CCE-26785-6, DISA FSO RHEL-06-000525 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 6 installs on a system and disable software which is not needed. It
then enumerates the software packages installed on a default RHEL 6 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 15The 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-26919-1, DISA FSO RHEL-06-000230 references: AC-2(5), SA-8, 879, 1133, 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 3 rules |
Enable the NTP Daemonrule
The $ sudo chkconfig --level 2345 ntpd onRationale: Enabling the identifiers: CCE-27093-4, DISA FSO RHEL-06-000247 references: AU-8(1), 160, Test attestation on 20121024 by DS Remediation script:
|
Specify a Remote NTP ServerruleTo specify a remote NTP server for time synchronization, edit
the file 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-27098-3, DISA FSO RHEL-06-000248 references: AU-8(1), 160, Test attestation on 20121024 by DS |
Specify Additional Remote NTP ServersruleAdditional NTP servers can be specified for time synchronization
in the file 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-26958-9 references: AU-8(1) |