Guide to the Secure Configuration of Red Hat Enterprise Linux 7
with profile Standard System Security ProfileThis profile contains rules to ensure standard security baseline of Red Hat Enterprise Linux 7 system. Regardless of your system's workload all of these checks should pass.
https://www.open-scap.org/security-policies/scap-security-guide
scap-security-guide
package which is developed at
https://www.open-scap.org/security-policies/scap-security-guide.
Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG for Red Hat Enterprise Linux 7, which provides required settings for US Department of Defense systems, 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 | Standard System Security Profile |
---|---|
Profile ID | xccdf_org.ssgproject.content_profile_standard |
Revision History
Current version: 0.1.31
- draft (as of 2017-03-31)
Platforms
- cpe:/o:redhat:enterprise_linux:7
- cpe:/o:centos:centos:7
- cpe:/o:redhat:enterprise_linux:7::client
- cpe:/o:redhat:enterprise_linux:7::computenode
Table of Contents
Checklist
contains 13 rules | ||||||||||||
System Settings [ref]groupContains rules that check correct system settings. | ||||||||||||
contains 13 rules | ||||||||||||
Installing and Maintaining Software [ref]groupThe following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates. | ||||||||||||
contains 5 rules | ||||||||||||
Updating Software [ref]groupThe | ||||||||||||
contains 3 rules | ||||||||||||
Ensure Red Hat GPG Key Installed [ref]ruleTo 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. Severity: high
| ||||||||||||
Ensure gpgcheck Enabled In Main Yum Configuration [ref]ruleThe gpgcheck=1Rationale:
Changes to any software components can have significant effects on the overall security
of the operating system. This requirement ensures the software has not been tampered with
and that it has been provided by a trusted vendor.
Severity: high
| ||||||||||||
Ensure Software Patches Installed [ref]ruleIf 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 .
NOTE: U.S. Defense systems are required to be patched within 30 days or sooner as local policy dictates. Rationale: Installing software updates is a fundamental mitigation against the exploitation of publicly-known vulnerabilities. If the most recent security patches and updates are not installed, unauthorized users may take advantage of weaknesses in the unpatched software. The lack of prompt attention to patching could result in a system compromise. Severity: high
| ||||||||||||
System and Software Integrity [ref]groupSystem and software integrity can be gained by installing antivirus, increasing system encryption strength with FIPS, verifying installed software, enabling SELinux, installing an Intrusion Prevention System, etc. However, installing or enabling integrity checking tools cannot prevent intrusions, but they can detect that an intrusion may have occurred. Requirements for integrity checking may be highly dependent on the environment in which the system will be used. Snapshot-based approaches such as AIDE may induce considerable overhead in the presence of frequent software updates. | ||||||||||||
contains 2 rules | ||||||||||||
Software Integrity Checking [ref]group
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.
| ||||||||||||
contains 2 rules | ||||||||||||
Verify Integrity with RPM [ref]groupThe 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 RPM [ref]ruleDiscretionary access control is weakened if a user or group has access permissions to system files and directories greater than the default. The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. Verify that the file permissions, ownership, and gruop membership of system files and commands match vendor values. Check the file permissions, ownership, and group membership with the following command: $ sudo rpm -Va | grep '^.M'Output indicates files that do not match vendor defaults. After locating a file with incorrect permissions, run the following command to determine which package owns it: $ rpm -qf FILENAME Next, run the following command to reset its permissions to the correct values: $ sudo rpm --setperms PACKAGENAME Warning:
Note: Due to a bug in the gdm package, the
RPM verify command may continue to fail even after file permissions have been
correctly set on /var/log/gdm . This is being tracked in Red Hat
Bugzilla #1275532.
Permissions on system binaries and configuration files that are too generous could allow an unauthorized user to gain privileges that they should not have. The permissions set by the vendor should be maintained. Any deviations from this baseline should be investigated. Severity: high References: AC-6, AU-9(1), AU-9(3), CM-6(d), CM-6(3), 1494, 1496, Req-11.5, 1.2.6, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, 6.2.3, SRG-OS-000257-GPOS-00098, SRG-OS-000278-GPOS-00108, 5.10.4.1, 3.3.8, 3.4.1
| ||||||||||||
Verify File Hashes with RPM [ref]ruleWithout cryptographic integrity protections, system executables and files can be altered by unauthorized users without detection. The RPM package management system can check the hashes of installed software packages, including many that are important to system security. To verify that the cryptographic hash of system files and commands match vendor values, run the following command to list which files on the system have hashes that differ from what is expected by the RPM database: $ rpm -Va | grep '^..5'A "c" in the second column indicates that a file is a configuration file, which may appropriately be expected to change. If the file was not expected to change, investigate the cause of the change using audit logs or other means. The package can then be reinstalled to restore the file. Run the following command to determine which package owns the file: $ rpm -qf FILENAMEThe package can be reinstalled from a yum repository using the command: $ sudo yum reinstall PACKAGENAMEAlternatively, the package can be reinstalled from trusted media using the command: $ sudo rpm -Uvh PACKAGENAMERationale: The hashes of important files like system executables should match the information given by the RPM database. Executables with erroneous hashes could be a sign of nefarious activity on the system. Severity: high References: CM-6(d), CM-6(3), SI-7(1), 663, Req-11.5, 1.2.6, SRG-OS-000480-GPOS-00227, 5.10.4.1, 3.3.8, 3.4.1
| ||||||||||||
File Permissions and Masks [ref]groupTraditional 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 6 rules | ||||||||||||
Restrict Partition Mount Options [ref]groupSystem partitions can be mounted with certain options
that limit what files on those partitions can do. These options
are set in the | ||||||||||||
contains 2 rules | ||||||||||||
Add nodev Option to /dev/shm [ref]ruleThe The only legitimate location for device files is the Severity: low | ||||||||||||
Add nosuid Option to /dev/shm [ref]ruleThe The presence of SUID and SGID executables should be tightly controlled. Users should not be able to execute SUID or SGID binaries from temporary storage partitions. Severity: low | ||||||||||||
Verify Permissions on Important Files and Directories [ref]groupPermissions 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 4 rules | ||||||||||||
Verify that All World-Writable Directories Have Sticky Bits Set [ref]ruleWhen the so-called 'sticky bit' is set on a directory,
only the owner of a given file may remove that file from the
directory. Without the sticky bit, any user with write access to a
directory may remove any file in the directory. Setting the sticky
bit prevents users from removing each other's files. In cases where
there is no reason for a directory to be world-writable, a better
solution is to remove that permission rather than to set the sticky
bit. However, if a directory is used by a particular application,
consult that application's documentation instead of blindly
changing modes.
$ sudo chmod +t DIRRationale:
Failing to set the sticky bit on public directories allows unauthorized users to delete files in the directory structure.
Severity: low | ||||||||||||
Ensure No World-Writable Files Exist [ref]ruleIt is generally a good idea to remove global (other) write access to a file when it is discovered. However, check with documentation for specific applications before making changes. Also, monitor for recurring world-writable files, as these may be symptoms of a misconfigured application or user account. Rationale:Data in world-writable files can be modified by any user on the system. In almost all circumstances, files can be configured using a combination of user and group permissions to support whatever legitimate access is needed without the risk caused by world-writable files. Severity: medium References: AC-6 | ||||||||||||
Ensure All SGID Executables Are Authorized [ref]ruleThe SGID (set group id) bit should be set only on files that were installed via authorized means. A straightforward means of identifying unauthorized SGID files is determine if any were not installed as part of an RPM package, which is cryptographically verified. Investigate the origin of any unpackaged SGID files. Rationale:Executable files with the SGID permission run with the privileges of the owner of the file. SGID files of uncertain provenance could allow for unprivileged users to elevate privileges. The presence of these files should be strictly controlled on the system. Severity: low References: AC-6(1) | ||||||||||||
Ensure All SUID Executables Are Authorized [ref]ruleThe SUID (set user id) bit should be set only on files that were installed via authorized means. A straightforward means of identifying unauthorized SGID files is determine if any were not installed as part of an RPM package, which is cryptographically verified. Investigate the origin of any unpackaged SUID files. Rationale:Executable files with the SUID permission run with the privileges of the owner of the file. SUID files of uncertain provenance could allow for unprivileged users to elevate privileges. The presence of these files should be strictly controlled on the system. Severity: low References: AC-6(1) | ||||||||||||
Account and Access Control [ref]groupIn 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 2 rules | ||||||||||||
Protect Accounts by Restricting Password-Based Login [ref]groupConventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the | ||||||||||||
contains 1 rule | ||||||||||||
Verify Proper Storage and Existence of Password Hashes [ref]group
By default, password hashes for local accounts are stored
in the second field (colon-separated) in
| ||||||||||||
contains 1 rule | ||||||||||||
Prevent Log In to Accounts With Empty Password [ref]ruleIf 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. Severity: high References: AC-6, IA-5(b), IA-5(c), IA-5(1)(a), 366, SRG-OS-000480-GPOS-00227, Req-8.2.3, 5.5.2, 3.1.1, 3.1.5
| ||||||||||||
Secure Session Configuration Files for Login Accounts [ref]groupWhen a user logs into a Unix account, the system configures the user's session by reading a number of files. Many of these files are located in the user's home directory, and may have weak permissions as a result of user error or misconfiguration. If an attacker can modify or even read certain types of account configuration information, they can often gain full access to the affected user's account. Therefore, it is important to test and correct configuration file permissions for interactive accounts, particularly those of privileged users such as root or system administrators. | ||||||||||||
contains 1 rule | ||||||||||||
Ensure that No Dangerous Directories Exist in Root's Path [ref]groupThe active path of the root account can be obtained by starting a new root shell and running: # echo $PATHThis will produce a colon-separated list of directories in the path. Certain path elements could be considered dangerous, as they could lead to root executing unknown or untrusted programs, which could contain malicious code. Since root may sometimes work inside untrusted directories, the . character, which represents the
current directory, should never be in the root path, nor should any
directory which can be written to by an unprivileged or
semi-privileged (system) user.
It is a good practice for administrators to always execute privileged commands by typing the full path to the command. | ||||||||||||
contains 1 rule | ||||||||||||
Ensure that Root's Path Does Not Include World or Group-Writable Directories [ref]ruleFor each element in root's path, run: # ls -ld DIRand ensure that write permissions are disabled for group and other. Rationale: Such entries increase the risk that root could execute code provided by unprivileged users, and potentially malicious code. Severity: low
|