Guide to the Secure Configuration of Red Hat Enterprise Linux 7
with profile C2S for Red Hat Enterprise Linux 7This profile demonstrates compliance against the U.S. Government Commercial Cloud Services (C2S) baseline. This baseline was inspired by the Center for Internet Security (CIS) Red Hat Enterprise Linux 7 Benchmark, v1.1.0 - 04-02-2015. For the SCAP Security Guide project to remain in compliance with CIS' terms and conditions, specifically Restrictions(8), note there is no representation or claim that the C2S profile will ensure a system is in compliance or consistency with the CIS baseline.
Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG for Red Hat Enterprise Linux 7 is one example of a baseline created from this guidance.
Profile Title | C2S for Red Hat Enterprise Linux 7 |
---|---|
Profile ID | xccdf_org.ssgproject.content_profile_C2S |
Revision History
Current version: 0.1.28
- draft (as of 2018-06-21)
Platforms
- cpe:/o:redhat:enterprise_linux:7
- cpe:/o:redhat:enterprise_linux:7::client
- cpe:/o:redhat:enterprise_linux:7::computenode
Table of Contents
- System Settings
- Installing and Maintaining Software
- File Permissions and Masks
- SELinux
- Account and Access Control
- Network Configuration and Firewalls
- Configure Syslog
- System Accounting with auditd
- Services
Checklist
contains 170 rules |
System Settings [ref]group |
contains 126 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 12 rules |
Disk Partitioning [ref]groupTo ensure separation and protection of data, there
are top-level system directories which should be placed on their
own physical partition or logical volume. The installer's default
partitioning scheme creates separate logical volumes for
|
contains 5 rules |
Ensure /tmp Located On Separate Partition [ref]rule
The
The identifiers: CCE-27173-4 references: SC-32, 1.1.1, Test attestation on 20120928 by MM |
Ensure /var Located On Separate Partition [ref]ruleThe
Ensuring that identifiers: CCE-26404-4 references: SC-32, 1.1.5, Test attestation on 20120928 by MM |
Ensure /var/log Located On Separate Partition [ref]rule
System logs are stored in the
Placing identifiers: CCE-26967-0 references: AU-9, SC-32, http://iase.disa.mil/stigs/cci/Pages/index.aspx, 1.1.7, Test attestation on 20120928 by MM |
Ensure /var/log/audit Located On Separate Partition [ref]rule
Audit logs are stored in the
Placing identifiers: CCE-26971-2 references: AU-4, AU-9, SC-32, http://iase.disa.mil/stigs/cci/Pages/index.aspx, 1.1.8, Test attestation on 20120928 by MM |
Ensure /home Located On Separate Partition [ref]rule
If user home directories will be stored locally, create a separate partition
for
Ensuring that identifiers: CCE-RHEL7-CCE-TBD references: SC-32, 1208, 1.1.9, Test attestation on 20120928 by MM |
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. identifiers: CCE-26957-1 references: CM-5(3), SI-7, MA-1(b), 1749, 366, Req-6.2, 1.2.2, Test attestation on 20150407 by sdw
|
Ensure gpgcheck Enabled In Main Yum Configuration [ref]ruleThe gpgcheck=1Rationale: Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. Certificates used to verify the software must be from an approved Certificate Authority (CA). identifiers: CCE-26989-4 references: CM-5(3), SI-7, MA-1(b), 1749, 366, Req-6.2, 1.2.3, Test attestation on 20150407 by sdw
|
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 .
Rationale:Installing software updates is a fundamental mitigation against the exploitation of publicly-known vulnerabilities. identifiers: CCE-26895-3 references: SI-2, MA-1(b), http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-6.2, 1.7, Test attestation on 20120928 by MM
|
Software Integrity 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.
The RPM package management system can conduct integrity
checks by comparing information in its metadata database with
files installed on the system.
|
contains 4 rules |
Verify Integrity with AIDE [ref]groupAIDE 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 2 rules |
Install AIDE [ref]ruleInstall the AIDE package with the command: $ sudo yum install aideRationale: The AIDE package must be installed if it is to be available for integrity checking. identifiers: CCE-27096-7 references: CM-3(d), CM-3(e), CM-6(d), CM-6(3), SC-28, SI-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-11.5, 1.3.1, Test attestation on 20121024 by DS
|
Configure Periodic Execution of AIDE [ref]rule
To implement a daily execution of AIDE at 4:05am using cron, add the following line to 05 4 * * * root /usr/sbin/aide --checkAIDE can be executed periodically through other means; this is merely one example. Rationale: By default, AIDE does not install itself for periodic execution. Periodically running AIDE is necessary to reveal unexpected changes in installed files. identifiers: CCE-26952-2 references: CM-3(d), CM-3(e), CM-6(d), CM-6(3), SC-28, SI-7, 374, 416, 1069, 1263, 1297, 1589, Req-11.5, 1.3.1
|
Verify Integrity with 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]ruleThe 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 PACKAGENAME warning
Note: Due to a bug in the gdm package, the
RPM verify command may continue to fail even after file permissions have been
correctly set on /var/log/gdm . This is being tracked in Red Hat
Bugzilla #1275532.
Permissions on system binaries and configuration files that are too generous could allow an unauthorized user to gain privileges that they should not have. The permissions set by the vendor should be maintained. Any deviations from this baseline should be investigated. identifiers: CCE-27209-6 references: AC-6, CM-6(d), CM-6(3), 1493, 1494, 1495, Req-11.5, 1.2.6, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, 6.2.3
|
Verify File Hashes with RPM [ref]ruleThe 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. |
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 23 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 11 rules |
Add nodev Option to Non-Root Local Partitions [ref]ruleThe The |
Add nodev Option to Removable Media Partitions [ref]ruleThe The only legitimate location for device files is the |
Add noexec Option to Removable Media Partitions [ref]ruleThe Allowing users to execute binaries from removable media such as USB keys exposes the system to potential compromise. |
Add nosuid Option to Removable Media Partitions [ref]ruleThe The presence of SUID and SGID executables should be tightly controlled. Allowing users to introduce SUID or SGID binaries from partitions mounted off of removable media would allow them to introduce their own highly-privileged programs. |
Add nodev Option to /tmp [ref]rule
The The only legitimate location for device files is the |
Add noexec Option to /tmp [ref]ruleThe Allowing users to execute binaries from world-writable directories
such as |
Add nosuid Option to /tmp [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. |
Add nodev Option to /dev/shm [ref]ruleThe The only legitimate location for device files is the |
Add noexec Option to /dev/shm [ref]ruleThe Allowing users to execute binaries from world-writable directories
such as |
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. |
Bind Mount /var/tmp To /tmp [ref]ruleThe /tmp /var/tmp none rw,nodev,noexec,nosuid,bind 0 0See the mount(8) man page for further explanation of bind mounting.
Rationale:Having multiple locations for temporary storage is not required. Unless absolutely
necessary to meet requirements, the storage location |
Restrict Dynamic Mounting and Unmounting of Filesystems [ref]groupLinux includes a number of facilities for the automated addition
and removal of filesystems on a running system. These facilities may be
necessary in many environments, but this capability also carries some risk -- whether direct
risk from allowing users to introduce arbitrary filesystems,
or risk that software flaws in the automated mount facility itself could
allow an attacker to compromise the system.
$ find /lib/modules/`uname -r`/kernel/fs -type f -name '*.ko'If these filesystems are not required then they can be explicitly disabled in a configuratio file in /etc/modprobe.d .
|
contains 7 rules |
Disable Mounting of cramfs [ref]rule
To configure the system to prevent the install cramfs /bin/trueThis effectively prevents usage of this uncommon filesystem. Rationale: Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Remediation Shell script: (show)
|
Disable Mounting of freevxfs [ref]rule
To configure the system to prevent the install freevxfs /bin/trueThis effectively prevents usage of this uncommon filesystem. Rationale: Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Remediation Shell script: (show)
|
Disable Mounting of jffs2 [ref]rule
To configure the system to prevent the install jffs2 /bin/trueThis effectively prevents usage of this uncommon filesystem. Rationale: Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Remediation Shell script: (show)
|
Disable Mounting of hfs [ref]rule
To configure the system to prevent the install hfs /bin/trueThis effectively prevents usage of this uncommon filesystem. Rationale: Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Remediation Shell script: (show)
|
Disable Mounting of hfsplus [ref]rule
To configure the system to prevent the install hfsplus /bin/trueThis effectively prevents usage of this uncommon filesystem. Rationale: Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Remediation Shell script: (show)
|
Disable Mounting of squashfs [ref]rule
To configure the system to prevent the install squashfs /bin/trueThis effectively prevents usage of this uncommon filesystem. Rationale: Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Remediation Shell script: (show)
|
Disable Mounting of udf [ref]rule
To configure the system to prevent the install udf /bin/trueThis effectively prevents usage of this uncommon filesystem. Rationale: Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. Remediation Shell script: (show)
|
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 1 rule |
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.
identifiers: CCE-RHEL7-CCE-TBD references: AC-6, 1.1.17, Test attestation on 20120929 by swells |
Restrict Programs from Dangerous Execution Patterns [ref]groupThe recommendations in this section are designed to ensure that the system's features to protect against potentially dangerous program execution are activated. These protections are applied at the system initialization or kernel level, and defend against certain types of badly-configured or compromised programs. |
contains 4 rules |
Daemon Umask [ref]groupThe umask is a per-process setting which limits the default permissions for creation of new files and directories. The system includes initialization scripts which set the default umask for system daemons. |
contains 1 rule |
Set Daemon Umask [ref]ruleThe file umask 027Setting the umask to too restrictive a setting can cause serious errors at runtime. Many daemons on the system already individually restrict themselves to a umask of 077 in their own init scripts. Rationale: The umask influences the permissions assigned to files created by a process at run time. An unnecessarily permissive umask could result in files being created with insecure permissions. identifiers: CCE-27068-6 references: AC-6, 3.1, Test attestation on 20140912 by JL
|
Disable Core Dumps [ref]groupA core dump file is the memory image of an executable
program when it was terminated by the operating system due to
errant behavior. In most cases, only software developers
legitimately need to access these files. The core dump files may
also contain sensitive information, or unnecessarily occupy large
amounts of disk space.
|
contains 2 rules |
Disable Core Dumps for All Users [ref]ruleTo disable core dumps for all users, add the following line to
* hard core 0Rationale: A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems. Remediation Shell script: (show)
|
Disable Core Dumps for SUID programs [ref]rule
To set the runtime status of the $ sudo sysctl -w fs.suid_dumpable=0If this is not the system's default value, add the following line to /etc/sysctl.conf :
fs.suid_dumpable = 0Rationale: The core dump of a setuid program is more likely to contain sensitive data, as the program itself runs with greater privileges than the user who initiated execution of the program. Disabling the ability for any setuid program to write a core file decreases the risk of unauthorized access of such data. Remediation Shell script: (show)
|
Enable ExecShield [ref]groupExecShield describes kernel features that provide
protection against exploitation of memory corruption errors such as buffer
overflows. These features include random placement of the stack and other
memory regions, prevention of execution in memory that should only hold data,
and special handling of text buffers. These protections are enabled by default
on 32-bit systems and controlled through |
contains 1 rule |
Enable Randomized Layout of Virtual Address Space [ref]rule
To set the runtime status of the $ sudo sysctl -w kernel.randomize_va_space=2If this is not the system's default value, add the following line to /etc/sysctl.conf :
kernel.randomize_va_space = 2Rationale: Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code they have introduced into a process's address space during an attempt at exploitation. Additionally, ASLR makes it more difficult for an attacker to know the location of existing code in order to re-purpose it using return oriented programming (ROP) techniques. identifiers: CCE-27127-0 references: SC-30(2), 1.6.1, Test attestation on 20121024 by DS
|
SELinux [ref]groupSELinux is a feature of the Linux kernel which can be
used to guard against misconfigured or compromised programs.
SELinux enforces the idea that programs should be limited in what
files they can access and what actions they can take.
|
contains 6 rules |
Ensure SELinux Not Disabled in /etc/grub.conf [ref]ruleSELinux can be disabled at boot time by an argument in
Disabling a major host protection feature, such as SELinux, at boot time prevents it from confining system services at boot time. Further, it increases the chances that it will remain off during system operation. identifiers: CCE-26961-3 references: AC-3, AC-3(3), AC-6, AU-9, 22, 32, 1.4.1, Test attestation on 20121024 by DS
|
Ensure SELinux State is Enforcing [ref]ruleThe SELinux state should be set to SELINUX=enforcingRationale: Setting the SELinux state to enforcing ensures SELinux is able to confine potentially compromised processes to the security policy, which is designed to prevent them from causing damage to the system or further elevating their privileges. identifiers: CCE-27334-2 references: AC-3, AC-3(3), AC-4, AC-6, AU-9, http://iase.disa.mil/stigs/cci/Pages/index.aspx, 1.4.2, Test attestation on 20121024 by DS
|
Configure SELinux Policy [ref]ruleThe SELinux SELINUXTYPE=targetedOther policies, such as mls , provide additional security labeling
and greater confinement but are not compatible with many general-purpose
use cases.
Rationale:
Setting the SELinux policy to identifiers: CCE-27279-9 references: AC-3, AC-3(3), AC-4, AC-6, AU-9, http://iase.disa.mil/stigs/cci/Pages/index.aspx, 1.4.3, Test attestation on 20121024 by DS
|
Uninstall setroubleshoot Package [ref]ruleThe SETroubleshoot service notifies desktop users of SELinux
denials. The service provides information around configuration errors,
unauthorized intrusions, and other potential errors.
The $ sudo yum erase setroubleshootRationale: The SETroubleshoot service is an unnecessary daemon to have running on a server identifiers: CCE- references: 1.4.4 |
Uninstall mcstrans Package [ref]ruleThe $ sudo yum erase mcstransRationale: Since this service is not used very often, disable it to reduce the amount of potentially vulnerable code running on the system. NOTE: This rule was added in support of the CIS RHEL6 v1.2.0 benchmark. Please note that Red Hat does not feel this rule is security relevant. identifiers: CCE- |
Ensure No Daemons are Unconfined by SELinux [ref]rule
Daemons for which the SELinux policy does not contain rules will inherit the
context of the parent process. Because daemons are launched during
startup and descend from the $ sudo ps -eZ | egrep "initrc" | egrep -vw "tr|ps|egrep|bash|awk" | tr ':' ' ' | awk '{ print $NF }'It should produce no output in a well-configured system. Rationale:
Daemons which run with the |
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 16 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 2 rules |
Restrict Root Logins [ref]group
Direct root logins should be allowed only for emergency use.
In normal situations, the administrator should access the system
via a unique unprivileged account, and then use |
contains 1 rule |
Direct root Logins Not Allowed [ref]ruleTo further limit access to the $ sudo echo > /etc/securettyRationale: Disabling direct root logins ensures proper accountability and multifactor authentication to privileged accounts. Users will first login, then escalate to privileged (root) access via su / sudo. This is required for FISMA Low and FISMA Moderate systems. identifiers: CCE-27294-8 references: IA-2(1), 6.4, Test attestation on 20121024 by DS
|
Set Password Expiration Parameters [ref]groupThe file $ sudo chage -M 180 -m 7 -W 7 USER |
contains 1 rule |
Set Password Maximum Age [ref]ruleTo specify password maximum age for new accounts,
edit the file PASS_MAX_DAYS DAYSA value of 180 days is sufficient for many environments. The DoD requirement is 60. Rationale: Setting the password maximum age ensures users are required to periodically change their passwords. This could possibly decrease the utility of a stolen password. Requiring shorter password lifetimes increases the risk of users writing down the password in a convenient location subject to physical compromise. identifiers: CCE-27051-2 references: IA-5(f), IA-5(g), IA-5(1)(d), 180, 199, 76, Req-8.2.4, 7.1.1, Test attestation on 20121026 by DS
|
Protect Accounts by Configuring PAM [ref]groupPAM, or Pluggable Authentication Modules, is a system
which implements modular authentication for Linux programs. PAM provides
a flexible and configurable architecture for authentication, and it should be configured
to minimize exposure to unnecessary risk. This section contains
guidance on how to accomplish that.
warning
Be careful when making changes to PAM's
configuration files. The syntax for these files is complex, and
modifications can have unexpected consequences. The default
configurations shipped with applications should be sufficient for
most users. warning
Running authconfig or
system-config-authentication will re-write the PAM configuration
files, destroying any manually made changes and replacing them with
a series of system defaults. One reference to the configuration
file syntax can be found at
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-configuration-file.html. |
contains 10 rules |
Set Password Quality Requirements [ref]groupThe default |
contains 5 rules |
Set Password Quality Requirements with pam_pwquality [ref]groupThe password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth .
Next, modify the settings in /etc/security/pwquality.conf to match the following:
difok = 4 minlen = 14 dcredit = -1 ucredit = -1 lcredit = -1 ocredit = -1 maxrepeat = 3The arguments can be modified to ensure compliance with your organization's security policy. Discussion of each parameter follows. warning
Note that the password quality
requirements are not enforced for the root account for some
reason. |
contains 5 rules |
Set Password Retry Prompts Permitted Per-Session [ref]ruleTo configure the number of retry prompts that are permitted per-session:
Setting the password retry prompts that are permitted on a per-session basis to a low value requires some software, such as SSH, to re-connect. This can slow down and draw additional attention to some types of password-guessing attacks. Note that this is different from account lockout, which is provided by the pam_faillock module. identifiers: CCE-27160-1 references: IA-5(c), http://iase.disa.mil/stigs/cci/Pages/index.aspx, 6.3.2, Test attestation on 20140925 by swells
|
Set Password Strength Minimum Digit Characters [ref]ruleThe pam_pwquality module's Requiring digits makes password guessing attacks more difficult by ensuring a larger search space. identifiers: CCE-27214-6 references: IA-5(b), IA-5(c), 194, 194, 71, Req-8.2.3, 6.3.2, Test attestation on 20121024 by DS
|
Set Password Minimum Length [ref]ruleThe pam_pwquality module's Password length is one factor of several that helps to determine strength and how long it takes to crack a password. Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password. identifiers: CCE-27293-0 references: IA-5(1)(a), 205, 78, Req-8.2.3, 6.3.2, Test attestation on 20140928 by swells
|
Set Password Strength Minimum Uppercase Characters [ref]ruleThe pam_pwquality module's Requiring a minimum number of uppercase characters makes password guessing attacks more difficult by ensuring a larger search space. identifiers: CCE-27200-5 references: IA-5(b), IA-5(c), IA-5(1)(a), 192, 69, Req-8.2.3, 6.3.2, Test attestation on 20121024 by DS
|
Set Password Strength Minimum Special Characters [ref]ruleThe pam_pwquality module's Requiring a minimum number of special characters makes password guessing attacks more difficult by ensuring a larger search space. identifiers: CCE-27360-7 references: IA-5(b), IA-5(c), IA-5(1)(a), 1619, 266, Test attestation on 20121024 by DS
|
Set Lockouts for Failed Password Attempts [ref]groupThe 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 Attempts [ref]rule
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. Remediation Shell script: (show)
|
Set Lockout Time For Failed Password Attempts [ref]rule
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. Remediation Shell script: (show)
|
Limit Password Reuse [ref]ruleDo not allow users to reuse recent passwords. This can be
accomplished by using the
Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user. identifiers: CCE-26923-3 references: IA-5(f), IA-5(1)(e), 200, 77, Req-8.2.5, 6.3.4, Test attestation on 20121024 by DS
|
Set Password Hashing Algorithm [ref]groupThe system's default algorithm for storing password hashes in
|
contains 2 rules |
Set Password Hashing Algorithm in /etc/pam.d/system-auth [ref]rule
In password sufficient pam_unix.so sha512 other arguments...This will help ensure when local users change their passwords, hashes for the new passwords will be generated using the SHA-512 algorithm. This is the default. Rationale: Using a stronger hashing algorithm makes password cracking attacks more difficult. identifiers: CCE-27104-9 references: IA-5(b), IA-5(c), IA-5(1)(c), IA-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-8.2.1, 6.3.1, Test attestation on 20121024 by DS
|
Set Password Hashing Algorithm in /etc/login.defs [ref]rule
In ENCRYPT_METHOD SHA512Rationale: Using a stronger hashing algorithm makes password cracking attacks more difficult. identifiers: CCE-27124-7 references: IA-5(b), IA-5(c), IA-5(1)(c), IA-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-8.2.1, 6.3.1, Test attestation on 20121024 by DS
|
Protect Physical Console Access [ref]groupIt 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 4 rules |
Set Boot Loader Password [ref]groupDuring the boot process, the boot loader is responsible for starting the execution of the kernel and passing options to it. The boot loader allows for the selection of different kernels - possibly on different partitions or media. The default Red Hat Enterprise Linux boot loader for x86 systems is called GRUB2. Options it can pass to the kernel include single-user mode, which provides root access without any authentication, and the ability to disable SELinux. To prevent local users from modifying the boot parameters and endangering security, protect the boot loader configuration with a password and ensure its configuration file's permissions are set properly. |
contains 4 rules |
Verify /boot/grub2/grub.cfg User Ownership [ref]ruleThe file $ sudo chown root /boot/grub2/grub.cfgRationale: Only root should be able to modify important boot parameters. identifiers: CCE-26860-7 references: AC-6(7), 225, Req-7.1, 1.5.1, Test attestation on 20121026 by DS
|
Verify /boot/grub2/grub.cfg Group Ownership [ref]ruleThe file $ sudo chgrp root /boot/grub2/grub.cfgRationale:
The identifiers: CCE-26812-8 references: AC-6(7), 225, Req-7.1, 1.5.1, Test attestation on 20121026 by DS
|
Verify /boot/grub2/grub.cfg Permissions [ref]ruleFile permissions for $ sudo chmod 600 /boot/grub2/grub.cfgRationale: Proper permissions ensure that only the root user can modify important boot parameters. identifiers: CCE-27054-6 references: AC-6(7), 225, 1.5.2, Test attestation on 20121026 by DS
|
Set Boot Loader Password [ref]ruleThe grub2 boot loader should have a superuser account and password
protection enabled to protect boot-time settings.
$ grub2-mkpasswd-pbkdf2When prompted, enter the password that was selected and insert the returned password hash into the appropriate grub2 configuration file(s) under /etc/grub.d immediately after the superuser account.
(Use the output from grub2-mkpasswd-pbkdf2 as the value of
password-hash):
password_pbkdf2 superusers-account password-hashNOTE: It is recommended not to use common administrator account names like root, admin, or administrator for the grub2 superuser account. To meet FISMA Moderate, the bootloader superuser account and password MUST differ from the root account and password. Once the superuser account and password have been added, update the grub.cfg file by running:
grub2-mkconfig -o /boot/grub2/grub.cfgNOTE: Do NOT manually add the superuser account and password to the grub.cfg file as the grub2-mkconfig command overwrites this file.
Rationale:Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode. For more information on how to configure the grub2 superuser account and password, please refer to
identifiers: CCE-27309-4 references: IA-2(1), IA-5(e), AC-3, http://iase.disa.mil/stigs/cci/Pages/index.aspx, 1.5.3, Test attestation on 20121026 by DS |
Network Configuration and Firewalls [ref]groupMost 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 27 rules |
Kernel Parameters Which Affect Networking [ref]groupThe |
contains 16 rules |
Network Parameters for Hosts Only [ref]groupIf the system is not going to be used as a router, then setting certain kernel parameters ensure that the host will not perform routing of network traffic. |
contains 3 rules |
Disable Kernel Parameter for Sending ICMP Redirects by Default [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv4.conf.default.send_redirects=0If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.conf.default.send_redirects = 0Rationale: Sending ICMP redirects permits the system to instruct other systems to update their routing information. The ability to send ICMP redirects is only appropriate for systems acting as routers. identifiers: CCE-RHEL7-CCE-TBD references: AC-4, CM-7, SC-5, SC-7, 1551, 4.1.2, Test attestation on 20121024 by DS
|
Disable Kernel Parameter for Sending ICMP Redirects for All Interfaces [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv4.conf.all.send_redirects=0If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.conf.all.send_redirects = 0Rationale: Sending ICMP redirects permits the system to instruct other systems to update their routing information. The ability to send ICMP redirects is only appropriate for systems acting as routers. identifiers: CCE-RHEL7-CCE-TBD references: CM-7, SC-5(1), 1551, 4.1.2, Test attestation on 20121024 by DS
|
Disable Kernel Parameter for IP Forwarding [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv4.ip_forward=0If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.ip_forward = 0Rationale: IP forwarding permits the kernel to forward packets from one network interface to another. The ability to forward packets between two networks is only appropriate for systems acting as routers. identifiers: CCE-RHEL7-CCE-TBD references: CM-7, SC-5, 366, 4.1.1, Test attestation on 20121024 by DS
|
Network Related Kernel Runtime Parameters for Hosts and Routers [ref]groupCertain kernel parameters should be set for systems which are acting as either hosts or routers to improve the system's ability defend against certain types of IPv4 protocol attacks. |
contains 13 rules |
Configure Kernel Parameter for Accepting Source-Routed Packets for All Interfaces [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv4.conf.all.accept_source_route=0If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.conf.all.accept_source_route = 0Rationale: Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required. identifiers: CCE-RHEL7-CCE-TBD references: CM-7, SC-5, 1551, 4.2.1, Test attestation on 20121024 by DS
|
Configure Kernel Parameter for Accepting ICMP Redirects for All Interfaces [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv4.conf.all.accept_redirects=0If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.conf.all.accept_redirects = 0Rationale: Accepting ICMP redirects has few legitimate uses. It should be disabled unless it is absolutely required. identifiers: CCE-RHEL7-CCE-TBD references: CM-7, SC-5, 1503, 1551, 4.2.2, Test attestation on 20121024 by DS
|
Configure Kernel Parameter for Accepting Secure Redirects for All Interfaces [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv4.conf.all.secure_redirects=0If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.conf.all.secure_redirects = 0Rationale: Accepting "secure" ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required. identifiers: CCE-RHEL7-CCE-TBD references: AC-4, CM-7, SC-5, 1503, 1551, 4.2.3, Test attestation on 20121024 by DS
|
Configure Kernel Parameter to Log Martian Packets [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv4.conf.all.log_martians=1If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.conf.all.log_martians = 1Rationale: The presence of "martian" packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. Logging these packets enables this activity to be detected. identifiers: CCE-RHEL7-CCE-TBD references: AC-17(7), CM-7, SC-5(3), 126, 4.2.4, Test attestation on 20121024 by DS
|
Configure Kernel Parameter to Log Martian Packets By Default [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv4.conf.default.log_martians=1If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.conf.default.log_martians = 1Rationale: The presence of "martian" packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. Logging these packets enables this activity to be detected. Remediation Shell script: (show)
|
Configure Kernel Parameter for Accepting Source-Routed Packets By Default [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv4.conf.default.accept_source_route=0If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.conf.default.accept_source_route = 0Rationale: Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required. identifiers: CCE-RHEL7-CCE-TBD references: AC-4, CM-7, SC-5, SC-7, 1551, 4.2.1, Test attestation on 20121024 by DS
|
Configure Kernel Parameter for Accepting ICMP Redirects By Default [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv4.conf.default.accept_redirects=0If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.conf.default.accept_redirects = 0Rationale: This feature of the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required. identifiers: CCE-RHEL7-CCE-TBD references: AC-4, CM-7, SC-5, SC-7, 1551, 4.2.2, Test attestation on 20121024 by DS
|
Configure Kernel Parameter for Accepting Secure Redirects By Default [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv4.conf.default.secure_redirects=0If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.conf.default.secure_redirects = 0Rationale: Accepting "secure" ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required. identifiers: CCE-RHEL7-CCE-TBD references: AC-4, CM-7, SC-5, SC-7, 1551, 4.2.3, Test attestation on 20121024 by DS
|
Configure Kernel Parameter to Ignore ICMP Broadcast Echo Requests [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.icmp_echo_ignore_broadcasts = 1Rationale: Ignoring ICMP echo requests (pings) sent to broadcast or multicast addresses makes the system slightly more difficult to enumerate on the network. identifiers: CCE-RHEL7-CCE-TBD references: CM-7, SC-5, 1551, 4.2.5, Test attestation on 20121024 by DS
|
Configure Kernel Parameter to Ignore Bogus ICMP Error Responses [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.icmp_ignore_bogus_error_responses = 1Rationale: Ignoring bogus ICMP error responses reduces log size, although some activity would not be logged. identifiers: CCE-RHEL7-CCE-TBD references: CM-7, SC-5, 4.2.6, Test attestation on 20121024 by DS
|
Configure Kernel Parameter to Use TCP Syncookies [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv4.tcp_syncookies=1If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.tcp_syncookies = 1Rationale: A TCP SYN flood attack can cause a denial of service by filling a system's TCP connection table with connections in the SYN_RCVD state. Syncookies can be used to track a connection when a subsequent ACK is received, verifying the initiator is attempting a valid connection and is not a flood source. This feature is activated when a flood condition is detected, and enables the system to continue servicing valid connection requests. identifiers: CCE-RHEL7-CCE-TBD references: AC-4, SC-5(2), SC-5(3), 1092, 1095, 4.2.8, Test attestation on 20121024 by DS
|
Configure Kernel Parameter to Use Reverse Path Filtering for All Interfaces [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv4.conf.all.rp_filter=1If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.conf.all.rp_filter = 1Rationale: Enabling reverse path filtering drops packets with source addresses that should not have been able to be received on the interface they were received on. It should not be used on systems which are routers for complicated networks, but is helpful for end hosts and routers serving small networks. identifiers: CCE-RHEL7-CCE-TBD references: AC-4, SC-5, SC-7, 1551, 4.2.7, Test attestation on 20121024 by DS
|
Configure Kernel Parameter to Use Reverse Path Filtering by Default [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv4.conf.default.rp_filter=1If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv4.conf.default.rp_filter = 1Rationale: Enabling reverse path filtering drops packets with source addresses that should not have been able to be received on the interface they were received on. It should not be used on systems which are routers for complicated networks, but is helpful for end hosts and routers serving small networks. identifiers: CCE-RHEL7-CCE-TBD references: AC-4, SC-5, SC-7, 4.2.7, Test attestation on 20121024 by DS
|
Wireless Networking [ref]groupWireless networking, such as 802.11
(WiFi) and Bluetooth, can present a security risk to sensitive or
classified systems and networks. Wireless networking hardware is
much more likely to be included in laptop or portable systems than
in desktops or servers.
|
contains 1 rule |
Disable Wireless Through Software Configuration [ref]groupIf it is impossible to remove the wireless hardware from the device in question, disable as much of it as possible through software. The following methods can disable software support for wireless networking, but note that these methods do not prevent malicious software or careless users from re-activating the devices. |
contains 1 rule |
Deactivate Wireless Network Interfaces [ref]ruleDeactivating wireless network interfaces should prevent
normal usage of the wireless capability.
$ ifconfig -aAdditionally, the following command may be used to determine whether wireless support is included for a particular interface, though this may not always be a clear indicator: $ iwconfigAfter identifying any wireless interfaces (which may have names like wlan0 , ath0 , wifi0 , em1 or
eth0 ), deactivate the interface with the command:
$ sudo ifdown interfaceThese changes will only last until the next reboot. To disable the interface for future boots, remove the appropriate interface file from /etc/sysconfig/network-scripts :
$ sudo rm /etc/sysconfig/network-scripts/ifcfg-interfaceRationale: Wireless networking allows attackers within physical proximity to launch network-based attacks against systems, including those against local LAN protocols which were not designed with security in mind. |
IPv6 [ref]groupThe system includes support for Internet Protocol version 6. A major and often-mentioned improvement over IPv4 is its enormous increase in the number of available addresses. Another important feature is its support for automatic configuration of many network settings. |
contains 5 rules |
Disable Support for IPv6 Unless Needed [ref]groupDespite configuration that suggests support for IPv6 has been disabled, link-local IPv6 address auto-configuration occurs even when only an IPv4 address is assigned. The only way to effectively prevent execution of the IPv6 networking stack is to instruct the system not to activate the IPv6 kernel module. |
contains 1 rule |
Disable IPv6 Networking Support Automatic Loading [ref]ruleTo disable support for ( net.ipv6.conf.all.disable_ipv6 = 1This disables IPv6 on all network interfaces as other services and system functionality require the IPv6 stack loaded to work. Rationale: Any unnecessary network stacks - including IPv6 - should be disabled, to reduce the vulnerability to exploitation. identifiers: CCE-RHEL7-CCE-TBD references: CM-7, 1551, 4.4.2, Test attestation on 20121024 by DS
|
Configure IPv6 Settings if Necessary [ref]groupA major feature of IPv6 is the extent to which systems implementing it can automatically configure their networking devices using information from the network. From a security perspective, manually configuring important configuration information is preferable to accepting it from the network in an unauthenticated fashion. |
contains 4 rules |
Disable Automatic Configuration [ref]groupDisable the system's acceptance of router
advertisements and redirects by adding or correcting the following
line in IPV6_AUTOCONF=no |
contains 4 rules |
Configure Accepting IPv6 Router Advertisements [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv6.conf.all.accept_ra=0If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv6.conf.all.accept_ra = 0Rationale: An illicit router advertisement message could result in a man-in-the-middle attack. Remediation Shell script: (show)
|
Configure Accepting IPv6 Router Advertisements [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv6.conf.default.accept_ra=0If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv6.conf.default.accept_ra = 0Rationale: An illicit router advertisement message could result in a man-in-the-middle attack. Remediation Shell script: (show)
|
Configure Accepting IPv6 Redirects By Default [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv6.conf.all.accept_redirects=0If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv6.conf.all.accept_redirects = 0Rationale: An illicit ICMP redirect message could result in a man-in-the-middle attack. Remediation Shell script: (show)
|
Configure Accepting IPv6 Redirects By Default [ref]rule
To set the runtime status of the $ sudo sysctl -w net.ipv6.conf.default.accept_redirects=0If this is not the system's default value, add the following line to /etc/sysctl.conf :
net.ipv6.conf.default.accept_redirects = 0Rationale: An illicit ICMP redirect message could result in a man-in-the-middle attack. Remediation Shell script: (show)
|
firewalld [ref]groupThe dynamic firewall daemon |
contains 1 rule |
Inspect and Activate Default firewalld Rules [ref]groupFirewalls can be used to separate networks into different zones
based on the level of trust the user has decided to place on the devices and
traffic within that network.
It is possible to designate one of these zones to be the default zone. When interface connections are added to NetworkManager , they are assigned
to the default zone. On installation, the default zone in firewalld is set to
be the public zone.
To find out all the settings of a zone, for example the public zone,
enter the following command as root:
# firewall-cmd --zone=public --list-allExample output of this command might look like the following: # firewall-cmd --zone=public --list-all public interfaces: services: mdns dhcpv6-client ssh ports: forward-ports: icmp-blocks: source-quenchTo view the network zones currently active, enter the following command as root: # firewall-cmd --get-serviceThe following listing displays the result of this command on common Red Hat Enterprise Linux 7 Server system: # firewall-cmd --get-service amanda-client bacula bacula-client dhcp dhcpv6 dhcpv6-client dns ftp high-availability http https imaps ipp ipp-client ipsec kerberos kpasswd ldap ldaps libvirt libvirt-tls mdns mountd ms-wbt mysql nfs ntp openvpn pmcd pmproxy pmwebapi pmwebapis pop3s postgresql proxy-dhcp radius rpc-bind samba samba-client smtp ssh telnet tftp tftp-client transmission-client vnc-server wbem-httpsFinally to view the network zones that will be active after the next firewalld service reload, enter the following command as root: # firewall-cmd --get-service --permanent |
contains 1 rule |
Verify firewalld Enabled [ref]rule
The $ sudo systemctl enable firewalld.serviceRationale:
The dynamic firewall daemon identifiers: CCE-27361-5 references: 4.7
|
Uncommon Network Protocols [ref]groupThe system includes support for several network protocols which are not commonly used. Although security vulnerabilities in kernel networking code are not frequently discovered, the consequences can be dramatic. Ensuring uncommon network protocols are disabled reduces the system's risk to attacks targeted at its implementation of those protocols. warning
Although these protocols are not commonly used, avoid disruption
in your network environment by ensuring they are not needed
prior to disabling them.
|
contains 4 rules |
Disable DCCP Support [ref]rule
The Datagram Congestion Control Protocol (DCCP) is a
relatively new transport layer protocol, designed to support
streaming media and telephony.
To configure the system to prevent the install dccp /bin/trueRationale: Disabling DCCP protects the system against exploitation of any flaws in its implementation. identifiers: CCE-26828-4 references: CM-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, 4.6.1, Test attestation on 20121024 by DS
|
Disable SCTP Support [ref]rule
The Stream Control Transmission Protocol (SCTP) is a
transport layer protocol, designed to support the idea of
message-oriented communication, with several streams of messages
within one connection.
To configure the system to prevent the install sctp /bin/trueRationale: Disabling SCTP protects the system against exploitation of any flaws in its implementation. identifiers: CCE-27106-4 references: CM-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, 4.6.2, Test attestation on 20121024 by DS
|
Disable RDS Support [ref]rule
The Reliable Datagram Sockets (RDS) protocol is a transport
layer protocol designed to provide reliable high- bandwidth,
low-latency communications between nodes in a cluster.
To configure the system to prevent the install rds /bin/trueRationale: Disabling RDS protects the system against exploitation of any flaws in its implementation. identifiers: CCE-RHEL7-CCE-TBD references: CM-7, 382, 4.6.3, Test attestation on 20121024 by DS
|
Disable TIPC Support [ref]rule
The Transparent Inter-Process Communication (TIPC) protocol
is designed to provide communications between nodes in a
cluster.
To configure the system to prevent the install tipc /bin/trueRationale: Disabling TIPC protects the system against exploitation of any flaws in its implementation. identifiers: CCE-RHEL7-CCE-TBD references: CM-7, 382, 4.6.4, Test attestation on 20121024 by DS
|
Configure Syslog [ref]groupThe 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 6 rules |
Ensure Proper Configuration of Log Files [ref]group
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 1 rule |
Ensure System Log Files Have Correct Permissions [ref]ruleThe file permissions for all log files written by
$ ls -l LOGFILEIf the permissions are not 600 or more restrictive, run the following command to correct this: $ sudo chmod 0600 LOGFILERationale: Log files can contain valuable information regarding system configuration. If the system log files are not protected unauthorized users could change the logged data, eliminating their forensic value. identifiers: CCE-RHEL7-CCE-TBD references: SI-11, 1314, Req-10.5.1, Req-10.5.2, 5.1.4, Test attestation on 20121024 by DS
|
contains 1 rule |
Ensure Logs Sent To Remote Host [ref]rule
To configure rsyslog to send logs to a remote log server,
open *.* @loghost.example.com To use TCP for log message delivery: *.* @@loghost.example.com To use RELP for log message delivery: *.* :omrelp:loghost.example.comRationale: A log server (loghost) receives syslog messages from one or more systems. This data can be used as an additional log source in the event a system is compromised and its local logs are suspect. Forwarding log messages to a remote loghost also provides system administrators with a centralized place to view the status of multiple hosts within the enterprise. |
contains 2 rules |
Ensure rsyslog is Installed [ref]rule
Rsyslog is installed by default.
The $ sudo yum install rsyslogRationale: The rsyslog package provides the rsyslog daemon, which provides system logging services. identifiers: CCE-RHEL7-CCE-TBD references: AU-9(2), 1311, 1312, 5.1.1, Test attestation on 20121024 by DS
|
Enable rsyslog Service [ref]ruleThe $ sudo systemctl enable rsyslog.serviceRationale: The identifiers: CCE-RHEL7-CCE-TBD references: AU-4(1), AU-12, 1311, 1312, 1557, 1851, 5.1.2, Test attestation on 20121024 by DS
|
System Accounting with auditd [ref]groupThe audit service provides substantial capabilities
for recording system activities. By default, the service audits about
SELinux AVC denials and certain types of security-relevant events
such as system logins, account modifications, and authentication
events performed by programs such as sudo.
Under its default configuration, ExecStartPost=-/sbin/augenrules --loadin the /usr/lib/systemd/system/auditd.service configuration file.
In order to instruct the auditd daemon to use the auditctl
utility to read audit rules, use the following setting:
ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rulesin the /usr/lib/systemd/system/auditd.service configuration file.
Refer to [Service] section of the /usr/lib/systemd/system/auditd.service
configuration file for further details.
Government networks often have substantial auditing requirements and auditd can be configured to meet these
requirements.
Examining some example audit records demonstrates how the Linux audit system
satisfies common requirements.
The following example from Fedora Documentation available at
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/sect-Security-Enhanced_Linux-Troubleshooting-Fixing_Problems.html#sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages
shows the substantial amount of information captured in a
two typical "raw" audit messages, followed by a breakdown of the most important
fields. In this example the message is SELinux-related and reports an AVC
denial (and the associated system call) that occurred when the Apache HTTP
Server attempted to access the /var/www/html/file1 file (labeled with
the samba_share_t type):
type=AVC msg=audit(1226874073.147:96): avc: denied { getattr } for pid=2465 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13 a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
|
contains 36 rules |
Configure auditd Data Retention [ref]group
The audit system writes data to |
contains 5 rules |
Configure auditd Max Log File Size [ref]ruleDetermine the amount of audit data (in megabytes)
which should be retained in each log file. Edit the file
max_log_file = STOREMBSet the value to 6 (MB) or higher for general-purpose systems.
Larger values, of course,
support retention of even more audit data.Rationale:The total storage for audit log files must be large enough to retain log information over the period required. This is a function of the maximum log file size and the number of logs retained. identifiers: CCE-27319-3 references: AU-1(b), AU-11, IR-5, Req-10.7, 5.2.1.1, Test attestation on 20121024 by DS
|
Configure auditd max_log_file_action Upon Reaching Maximum Log Size [ref]rule The default action to take when the logs reach their maximum size
is to rotate the log files, discarding the oldest one. To configure the action taken
by max_log_file_action = ACTIONPossible values for ACTION are described in the auditd.conf man
page. These include:
ACTION to rotate to ensure log rotation
occurs. This is the default. The setting is case-insensitive.
Rationale:Automatically rotating logs (by setting this to identifiers: CCE-27231-0 references: AU-1(b), AU-4, AU-11, IR-5, Req-10.7, 5.2.1.3, Test attestation on 20121024 by DS
|
Configure auditd space_left Action on Low Disk Space [ref]ruleThe space_left_action = ACTIONPossible values for ACTION are described in the auditd.conf man page.
These include:
email (instead of the default,
which is suspend ) as it is more likely to get prompt attention. Acceptable values
also include suspend , single , and halt .
Rationale:Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption. identifiers: CCE-27375-5 references: AU-1(b), AU-4, AU-5(b), IR-5, 140, 143, Req-10.7, 5.2.1.2, Test attestation on 20121024 by DS
|
Configure auditd admin_space_left Action on Low Disk Space [ref]ruleThe admin_space_left_action = ACTIONSet this value to single to cause the system to switch to single user
mode for corrective action. Acceptable values also include suspend and
halt . For certain systems, the need for availability
outweighs the need to log all actions, and a different setting should be
determined. Details regarding all possible values for ACTION are described in the
auditd.conf man page.
Rationale:Administrators should be made aware of an inability to record audit records. If a separate partition or logical volume of adequate size is used, running low on space for audit records should never occur. identifiers: CCE-27370-6 references: AU-1(b), AU-4, AU-5(b), IR-5, 140, 1343, Req-10.7, 5.2.1.2, Test attestation on 20121024 by DS
|
Configure auditd mail_acct Action on Low Disk Space [ref]ruleThe action_mail_acct = rootRationale: Email sent to the root account is typically aliased to the administrators of the system, who can take appropriate action. Remediation Shell script: (show)
|
Configure auditd Rules for Comprehensive Auditing [ref]groupThe
Auditing rules at startup are controlled by the file /etc/audit/audit.rules .
Add rules to it to meet the auditing requirements for your organization.
Each line in /etc/audit/audit.rules represents a series of arguments
that can be passed to auditctl and can be individually tested
during runtime. See documentation in /usr/share/doc/audit-VERSION and
in the related man pages for more details.
If copying any example audit rulesets from /usr/share/doc/audit-VERSION ,
be sure to comment out the
lines containing arch= which are not appropriate for your system's
architecture. Then review and understand the following rules,
ensuring rules are activated as needed for the appropriate
architecture.
After reviewing all the rules, reading the following sections, and editing as needed, the new rules can be activated as follows: $ sudo service auditd restart |
contains 29 rules |
Records Events that Modify Date and Time Information [ref]groupArbitrary 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 4 rules |
Record attempts to alter time through adjtimex [ref]ruleIf the -a always,exit -F arch=b32 -S adjtimex -k audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S adjtimex -k audit_time_rulesIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S adjtimex -k audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S adjtimex -k audit_time_rulesThe -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rulesRationale: Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited. identifiers: CCE-27290-6 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 5.2.4, Req-10.4.2.b, 1487, 169
|
Record attempts to alter time through settimeofday [ref]ruleIf the -a always,exit -F arch=b32 -S settimeofday -k audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S settimeofday -k audit_time_rulesIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S settimeofday -k audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S settimeofday -k audit_time_rulesThe -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rulesRationale: Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited. identifiers: CCE-27216-1 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 5.2.4, Req-10.4.2.b, 1487, 169
|
Record Attempts to Alter Time Through clock_settime [ref]ruleIf the -a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-changeIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-changeIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S clock_settime -F a0=0x0 -F key=time-changeIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S clock_settime -F a0=0x0 -F key=time-changeThe -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k audit_time_rulesRationale: Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited. identifiers: CCE-27219-5 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 5.2.4, Req-10.4.2.b, 1487, 169
|
Record Attempts to Alter the localtime File [ref]ruleIf the -w /etc/localtime -p wa -k audit_time_rulesIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-w /etc/localtime -p wa -k audit_time_rulesThe -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport and should always be used. Rationale: Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited. identifiers: CCE-27310-2 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(b), IR-5, 5.2.4, Req-10.4.2.b, 1487, 169
|
Record Events that Modify the System's Discretionary Access Controls [ref]groupAt a minimum the audit system should collect file permission
changes for all users and root. Note that the "-F arch=b32" lines should be
present even on a 64 bit system. These commands identify system calls for
auditing. Even if the system is 64 bit it can still execute 32 bit system
calls. Additionally, these rules can be configured in a number of ways while
still achieving the desired effect. An example of this is that the "-S" calls
could be split up and placed on separate lines, however, this is less efficient.
Add the following to -a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf your system is 64 bit then these lines should be duplicated and the arch=b32 replaced with arch=b64 as follows: -a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod |
contains 13 rules |
Record Events that Modify the System's Discretionary Access Controls - chmod [ref]ruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S chmod -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27339-1 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - chown [ref]ruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27364-9 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - fchmod [ref]ruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchmod -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27393-8 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - fchmodat [ref]ruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27388-8 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - fchown [ref]ruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchown -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27356-5 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - fchownat [ref]ruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fchownat -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27387-0 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - fremovexattr [ref]ruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27353-2 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - fsetxattr [ref]ruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S fsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27389-6 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - lchown [ref]ruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27083-5 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - lremovexattr [ref]ruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27410-0 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - lsetxattr [ref]ruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S lsetxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27280-7 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - removexattr [ref]ruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S removexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27367-2 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify the System's Discretionary Access Controls - setxattr [ref]ruleAt a minimum the audit system should collect file permission
changes for all users and root. If the -a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S setxattr -F auid>=1000 -F auid!=4294967295 -k perm_mod warning
Note that these rules can be configured in a
number of ways while still achieving the desired effect. Here the system calls
have been placed independent of other system calls. Grouping these system
calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users. identifiers: CCE-27213-8 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.5.5, 5.2.10
|
Record Events that Modify User/Group Information [ref]ruleIf the -w /etc/group -p wa -k audit_rules_usergroup_modification -w /etc/passwd -p wa -k audit_rules_usergroup_modification -w /etc/gshadow -p wa -k audit_rules_usergroup_modification -w /etc/shadow -p wa -k audit_rules_usergroup_modification -w /etc/security/opasswd -p wa -k audit_rules_usergroup_modificationIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, in order to capture events that modify
account changes:
-w /etc/group -p wa -k audit_rules_usergroup_modification -w /etc/passwd -p wa -k audit_rules_usergroup_modification -w /etc/gshadow -p wa -k audit_rules_usergroup_modification -w /etc/shadow -p wa -k audit_rules_usergroup_modification -w /etc/security/opasswd -p wa -k audit_rules_usergroup_modificationRationale: In addition to auditing new user and group accounts, these watches will alert the system administrator(s) to any modifications. Any unexpected users, groups, or modifications should be investigated for legitimacy. identifiers: CCE-27192-4 references: AC-2(4), AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 18, 172, 1403, 1404, 1405, 1684, 1683, 1685, 1686, 476, 239, Req-10.2.5, 5.2.5
|
Record Events that Modify the System's Network Environment [ref]ruleIf the -a always,exit -F arch=ARCH -S sethostname -S setdomainname -k audit_rules_networkconfig_modification -w /etc/issue -p wa -k audit_rules_networkconfig_modification -w /etc/issue.net -p wa -k audit_rules_networkconfig_modification -w /etc/hosts -p wa -k audit_rules_networkconfig_modification -w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modificationIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S sethostname -S setdomainname -k audit_rules_networkconfig_modification -w /etc/issue -p wa -k audit_rules_networkconfig_modification -w /etc/issue.net -p wa -k audit_rules_networkconfig_modification -w /etc/hosts -p wa -k audit_rules_networkconfig_modification -w /etc/sysconfig/network -p wa -k audit_rules_networkconfig_modificationRationale: The network environment should not be modified by anything other than administrator action. Any change to network parameters should be audited. identifiers: CCE-27076-9 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, Req-10.5.5, 5.2.6
|
Record Events that Modify the System's Mandatory Access Controls [ref]ruleIf the -w /etc/selinux/ -p wa -k MAC-policyIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-w /etc/selinux/ -p wa -k MAC-policyRationale: The system's mandatory access policy (SELinux) should not be arbitrarily changed by anything other than administrator action. All changes to MAC policy should be audited. identifiers: CCE-27168-4 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, Req-10.5.5, 5.2.7
|
Record Attempts to Alter Logon and Logout Events [ref]ruleThe audit system already collects login information for all users
and root. If the -w /var/log/tallylog -p wa -k logins -w /var/run/faillock/ -p wa -k logins -w /var/log/lastlog -p wa -k loginsIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file in order to watch for unattempted manual
edits of files involved in storing logon events:
-w /var/log/tallylog -p wa -k logins -w /var/run/faillock/ -p wa -k logins -w /var/log/lastlog -p wa -k loginsRationale: Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. Remediation Shell script: (show)
|
Record Attempts to Alter Process and Session Initiation Information [ref]ruleThe audit system already collects process information for all
users and root. If the -w /var/run/utmp -p wa -k session -w /var/log/btmp -p wa -k session -w /var/log/wtmp -p wa -k sessionIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file in order to watch for attempted manual
edits of files involved in storing such process information:
-w /var/run/utmp -p wa -k session -w /var/log/btmp -p wa -k session -w /var/log/wtmp -p wa -k sessionRationale: Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. identifiers: CCE-27301-1 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, Req-10.2.3, 5.2.9
|
Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) [ref]ruleAt a minimum the audit system should collect unauthorized file
accesses for all users and root. If the -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k accessIf the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k accessIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file:
-a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k accessIf the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -k access -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -k accessRationale: Unsuccessful attempts to access files could be an indicator of malicious activity on a system. Auditing these events could serve as evidence of potential system compromise. identifiers: CCE-27347-4 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.2.4, Req-10.2.1, 5.2.10
|
Ensure auditd Collects Information on the Use of Privileged Commands [ref]ruleAt a minimum the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid / setgid programs, run the following command for each local partition PART: $ sudo find PART -xdev -type f -perm -4000 -o -type f -perm -2000 2>/dev/nullIf the auditd daemon is configured to use the augenrules
program to read audit rules during daemon startup (the default), add a line of
the following form to a file with suffix .rules in the directory
/etc/audit/rules.d for each setuid / setgid program on the system,
replacing the SETUID_PROG_PATH part with the full path of that setuid /
setgid program in the list:
-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=4294967295 -k privilegedIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add a line of the following
form to /etc/audit/audit.rules for each setuid / setgid program on the
system, replacing the SETUID_PROG_PATH part with the full path of that
setuid / setgid program in the list:
-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=1000 -F auid!=4294967295 -k privilegedRationale: 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-27437-3 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-2(4), AU-12(a), AU-12(c), IR-5, 40, Req-10.2.2, 5.2.10, Test attestation on 20121024 by DS
|
Ensure auditd Collects Information on Exporting to Media (successful) [ref]ruleAt a minimum the audit system should collect media exportation
events for all users and root. If the -a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=4294967295 -k exportIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S mount -F auid>=1000 -F auid!=4294967295 -k exportRationale: The unauthorized exportation of data to external media could result in an information leak where classified information, Privacy Act information, and intellectual property could be lost. An audit trail should be created each time a filesystem is mounted to help identify and guard against information loss. identifiers: CCE-27447-2 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.2.7, 5.2.13, Test attestation on 20121024 by DS
|
Ensure auditd Collects File Deletion Events by User [ref]ruleAt a minimum the audit system should collect file deletion events
for all users and root. If the -a always,exit -F arch=ARCH -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k deleteIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S rmdir -S unlink -S unlinkat -S rename -S renameat -F auid>=1000 -F auid!=4294967295 -k deleteRationale: Auditing file deletions will create an audit trail for files that are removed from the system. The audit trail could aid in system troubleshooting, as well as, detecting malicious processes that attempt to delete log files to conceal their presence. identifiers: CCE-27206-2 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 172, 468, Req-10.2.7, 5.2.14
|
Ensure auditd Collects System Administrator Actions [ref]ruleAt a minimum the audit system should collect administrator actions
for all users and root. If the -w /etc/sudoers -p wa -k actionsIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file:
-w /etc/sudoers -p wa -k actionsRationale: The actions taken by system administrators should be audited to keep a record of what was executed on the system, as well as, for accountability purposes. identifiers: CCE-27461-3 references: AC-2(7)(b), AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 126, Req-10.2.2, Req-10.2.5.b, Test attestation on 20121024 by DS
|
Ensure auditd Collects Information on Kernel Module Loading and Unloading [ref]ruleIf the -w /usr/sbin/insmod -p x -k modules -w /usr/sbin/rmmod -p x -k modules -w /usr/sbin/modprobe -p x -k modules -a always,exit -F arch=ARCH -S init_module -S delete_module -k modulesIf the auditd daemon is configured to use the auditctl utility to read audit
rules during daemon startup, add the following lines to /etc/audit/audit.rules file
in order to capture kernel module loading and unloading events, setting ARCH to either b32 or
b64 as appropriate for your system:
-w /usr/sbin/insmod -p x -k modules -w /usr/sbin/rmmod -p x -k modules -w /usr/sbin/modprobe -p x -k modules -a always,exit -F arch=ARCH -S init_module -S delete_module -k modulesRationale: The addition/removal of kernel modules can be used to alter the behavior of the kernel and potentially introduce malicious code into kernel space. It is important to have an audit trail of modules that have been introduced into the kernel. identifiers: CCE-27129-6 references: AC-17(7), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-12(a), AU-12(c), IR-5, 172, 477, Req-10.2.7, 5.2.17
|
Make the auditd Configuration Immutable [ref]ruleIf the -e 2If the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file in order to make the auditd configuration
immutable:
-e 2With this setting, a reboot will be required to change any audit rules. Rationale: Making the audit configuration immutable prevents accidental as well as malicious modification of the audit rules, although it may be problematic if legitimate changes are needed during system operation identifiers: CCE-27097-5 references: AC-6, AU-1(b), AU-2(a), AU-2(c), AU-2(d), IR-5, Req-10.5.2, 5.2.18
|
Enable auditd Service [ref]ruleThe $ sudo systemctl enable auditd.serviceRationale: Ensuring the identifiers: CCE-27407-6 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, Req-10, 5.2.2, Test attestation on 20121024 by DS
|
Enable Auditing for Processes Which Start Prior to the Audit Daemon [ref]ruleTo ensure all processes can be audited, even those which start
prior to the audit daemon, add the argument GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 audit=1" warning
The GRUB 2 configuration file, grub.cfg ,
is automatically updated each time a new kernel is installed. Note that any
changes to /etc/default/grub require rebuilding the grub.cfg
file. To update the GRUB 2 configuration file manually, use the
grub2-mkconfig -ocommand as follows:
Each process on the system carries an "auditable" flag which indicates whether
its activities can be audited. Although identifiers: CCE-27212-0 references: AC-17(1), AU-14(1), AU-1(b), AU-2(a), AU-2(c), AU-2(d), AU-10, IR-5, 1464, 130, Req-10.3, 5.2.3
|
Services [ref]group
The best protection against vulnerable software is running less software. This section describes how to review
the software which Red Hat Enterprise Linux 7 installs on a system and disable software which is not needed. It
then enumerates the software packages installed on a default Red Hat Enterprise Linux 7 system and provides guidance about which
ones can be safely disabled.
|
contains 44 rules |
Obsolete Services [ref]groupThis section discusses a number of network-visible
services which have historically caused problems for system
security, and for which disabling or severely limiting the service
has been the best available guidance for some time. As a result of
this, many of these services are not installed as part of Red Hat Enterprise Linux 7
by default.
|
contains 11 rules |
Xinetd [ref]groupThe |
contains 1 rule |
Uninstall xinetd Package [ref]ruleThe $ sudo yum erase xinetdRationale:
Removing the identifiers: CCE-27354-0 references: AC-17(8), CM-7, 305, 2.1.11, Test attestation on 20121026 by DS
|
Telnet [ref]groupThe telnet protocol does not provide confidentiality or integrity for information transmitted on the network. This includes authentication information such as passwords. Organizations which use telnet should be actively working to migrate to a more secure protocol. |
contains 2 rules |
Uninstall telnet-server Package [ref]ruleThe $ sudo yum erase telnet-serverRationale:
Removing the identifiers: CCE-27165-0 references: AC-17(8), CM-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, 2.1.1, Test attestation on 20121026 by DS
|
Remove telnet Clients [ref]ruleThe telnet client allows users to start connections to other systems via the telnet protocol. Rationale:The identifiers: CCE-27305-2 references: 2.1.2
|
Rlogin, Rsh, and Rexec [ref]groupThe Berkeley r-commands are legacy services which allow cleartext remote access and have an insecure trust model. |
contains 2 rules |
Uninstall rsh-server Package [ref]ruleThe $ sudo yum erase rsh-serverRationale: The identifiers: CCE-27342-5 references: AC-17(8), CM-7, 305, 381, 2.1.3, Test attestation on 20121026 by DS
|
Uninstall rsh Package [ref]ruleThe These legacy clients contain numerous security exposures and have
been replaced with the more secure SSH package. Even if the server is removed,
it is best to ensure the clients are also removed to prevent users from
inadvertently attempting to use these commands and therefore exposing
their credentials. Note that removing the identifiers: CCE-27274-0 references: 2.1.4, Test attestation on 20140530 by JL
|
NIS [ref]groupThe Network Information Service (NIS), also known as 'Yellow Pages' (YP), and its successor NIS+ have been made obsolete by Kerberos, LDAP, and other modern centralized authentication services. NIS should not be used because it suffers from security problems inherent in its design, such as inadequate protection of important authentication information. |
contains 2 rules |
Uninstall ypserv Package [ref]ruleThe $ sudo yum erase ypservRationale: Removing the identifiers: CCE-27399-5 references: AC-17(8), CM-7, 305, 381, 2.1.6, Test attestation on 20121026 by DS
|
Remove NIS Client [ref]ruleThe Network Information Service (NIS), formerly known as Yellow Pages,
is a client-server directory service protocol used to distribute system configuration
files. The NIS client ( The NIS service is inherently an insecure system that has been vulnerable to DOS attacks, buffer overflows and has poor authentication for querying NIS maps. NIS generally has been replaced by such protocols as Lightweight Directory Access Protocol (LDAP). It is recommended that the service be removed. identifiers: CCE-27396-1 references: 2.1.5
|
TFTP Server [ref]groupTFTP is a lightweight version of the FTP protocol which has traditionally been used to configure networking equipment. However, TFTP provides little security, and modern versions of networking operating systems frequently support configuration via SSH or other more secure protocols. A TFTP server should be run only if no more secure method of supporting existing equipment can be found. |
contains 2 rules |
Uninstall tftp-server Package [ref]rule
The $ sudo yum erase tftp-serverRationale:
Removing the identifiers: CCE-RHEL7-CCE-TBD references: AC-17(8), CM-7, 305, 2.1.8, Test attestation on 20121026 by DS
|
Remove tftp [ref]ruleTrivial File Transfer Protocol (TFTP) is a simple file transfer protocol,
typically used to automatically transfer configuration or boot files between machines.
TFTP does not support authentication and can be easily hacked. The package
It is recommended that TFTP be remvoed, unless there is a specific need for TFTP (such as a boot server). In that case, use extreme caution when configuring the services. identifiers: CCE- references: 2.1.7 |
Chat/Messaging Services [ref]groupThe talk software makes it possible for users to send and receive messages across systems through a terminal session. |
contains 2 rules |
Uninstall talk-server Package [ref]rule
The $ sudo yum erase talk-serverRationale:
The talk software presents a security risk as it uses unencrypted protocols
for communications. Removing the identifiers: CCE-27210-4 references: 2.1.10, Test attestation on 20140625 by JL
|
Uninstall talk Package [ref]ruleThe $ sudo yum erase talkRationale:
The talk software presents a security risk as it uses unencrypted protocols
for communications. Removing the identifiers: CCE-27432-4 references: 2.1.9, Test attestation on 20140625 by JL
|
Base Services [ref]groupThis section addresses the base services that are installed on a Red Hat Enterprise Linux 7 default installation which are not covered in other sections. Some of these services listen on the network and should be treated with particular discretion. Other services are local system utilities that may or may not be extraneous. In general, system services should be disabled if not required. |
contains 1 rule |
Disable Red Hat Network Service (rhnsd) [ref]ruleThe Red Hat Network service automatically queries Red Hat Network
servers to determine whether there are any actions that should be executed,
such as package updates. This only occurs if the system was registered to an
RHN server or satellite and managed as such.
The $ sudo systemctl disable rhnsd.serviceRationale: Although systems management and patching is extremely important to
system security, management by a system outside the enterprise enclave is not
desirable for some environments. However, if the system is being managed by RHN or
RHN Satellite Server the identifiers: CCE-RHEL7-CCE-TBD references: AC-17(8), CM-7, 382, 1.2.4, Test attestation on 20121024 by DS
|
Cron and At Daemons [ref]groupThe cron and at services are used to allow commands to be executed at a later time. The cron service is required by almost all systems to perform necessary maintenance tasks, while at may or may not be required on a given system. Both daemons should be configured defensively. |
contains 1 rule |
Enable cron Service [ref]ruleThe $ sudo systemctl enable crond.serviceRationale: Due to its usage for maintenance and security-supporting tasks, enabling the cron daemon is essential. identifiers: CCE-27323-5 references: CM-7, 6.1.2, Test attestation on 20121024 by DS
|
SSH Server [ref]groupThe 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 11 rules |
Configure OpenSSH Server if Necessary [ref]groupIf the system needs to act as an SSH server, then
certain changes should be made to the OpenSSH daemon configuration
file |
contains 11 rules |
Allow Only SSH Protocol 2 [ref]ruleOnly SSH protocol version 2 connections should be
permitted. The default setting in
Protocol 2Rationale: SSH protocol version 1 suffers from design flaws that result in security vulnerabilities and should not be used. identifiers: CCE-27320-1 references: AC-17(7), IA-5(1)(c), http://iase.disa.mil/stigs/cci/Pages/index.aspx, 6.2.1, Test attestation on 20121024 by DS
|
Limit Users' SSH Access [ref]ruleBy default, the SSH configuration allows any user with an account
to access the system. In order to specify the users that are allowed to login
via SSH and deny all other users, add or correct the following line in the
DenyUsers USER1 USER2Where USER1 and USER2 are valid user names.
Rationale:Specifying which accounts are allowed SSH access into the system reduces the possibility of unauthorized access to the system. identifiers: CCE-RHEL7-CCE-TBD references: AC-3 |
Set SSH Idle Timeout Interval [ref]ruleSSH allows administrators to set an idle timeout
interval.
After this interval has passed, the idle user will be
automatically logged out.
ClientAliveInterval intervalThe timeout interval is given in seconds. To have a timeout of 15 minutes, set interval to 900. If a shorter timeout has already been set for the login shell, that value will preempt any SSH setting made here. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle. Rationale: Causing idle users to be automatically logged out guards against compromises one system leading trivially to compromises on another. identifiers: CCE-27433-2 references: AC-2(5), SA-8, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Req-8.1.8, 6.2.12, Test attestation on 20121024 by DS
|
Set SSH Client Alive Count [ref]ruleTo ensure the SSH idle timeout occurs precisely when the ClientAliveCountMax 0Rationale:
This ensures a user login will be terminated as soon as the identifiers: CCE-27082-7 references: AC-2(5), SA-8, http://iase.disa.mil/stigs/cci/Pages/index.aspx, 6.2.12, Test attestation on 20121024 by DS
|
Disable SSH Support for .rhosts Files [ref]ruleSSH can emulate the behavior of the obsolete rsh
command in allowing users to enable insecure access to their
accounts via IgnoreRhosts yesRationale: SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. identifiers: CCE-27377-1 references: AC-3, http://iase.disa.mil/stigs/cci/Pages/index.aspx, 6.2.6
|
Disable Host-Based Authentication [ref]ruleSSH's cryptographic host-based authentication is
more secure than HostbasedAuthentication noRationale: SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. identifiers: CCE-27413-4 references: AC-3, http://iase.disa.mil/stigs/cci/Pages/index.aspx, 6.2.7, Test attestation on 20121024 by DS
|
Disable SSH Root Login [ref]ruleThe root user should never be allowed to login to a
system directly over a network.
To disable root login via SSH, add or correct the following line
in PermitRootLogin noRationale: Permitting direct root login reduces auditable information about who ran privileged commands on the system and also allows direct attack attempts on root's password. identifiers: CCE-27445-6 references: AC-3, AC-6(2), IA-2(1), http://iase.disa.mil/stigs/cci/Pages/index.aspx, 6.2.8, Test attestation on 20121024 by DS
|
Disable SSH Access via Empty Passwords [ref]ruleTo explicitly disallow remote login from accounts with
empty passwords, add or correct the following line in
PermitEmptyPasswords noAny accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords. Rationale: Configuring this setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere. identifiers: CCE-27471-2 references: AC-3, http://iase.disa.mil/stigs/cci/Pages/index.aspx, Test attestation on 20121024 by DS
|
Enable SSH Warning Banner [ref]rule
To enable the warning banner and ensure it is consistent
across the system, add or correct the following line in Banner /etc/issueAnother section contains information on how to create an appropriate system-wide warning banner. Rationale: The warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. Alternatively, systems whose ownership should not be obvious should ensure usage of a banner that does not provide easy attribution. identifiers: CCE-27314-4 references: AC-8(a), AC-8(c)(1), AC-8(c)(2), AC-8(c)(3), 1384, 1385, 1386, 1387, 1388, 228, 6.2.14, Test attestation on 20121024 by DS
|
Do Not Allow SSH Environment Options [ref]ruleTo ensure users are not able to present
environment options to the SSH daemon, add or correct the following line
in PermitUserEnvironment noRationale: SSH environment options potentially allow users to bypass access restriction in some configurations. identifiers: CCE-27363-1 references: http://iase.disa.mil/stigs/cci/Pages/index.aspx, 6.2.10, Test attestation on 20121024 by DS
|
Use Only Approved Ciphers [ref]ruleLimit the ciphers to those algorithms which are FIPS-approved.
Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode.
The following line in Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbcThe man page sshd_config(5) contains a list of supported ciphers.
Rationale:Approved algorithms should impart some level of confidence in their implementation. These are also required for compliance. identifiers: CCE-27295-5 references: AC-3, AC-17(2), AU-10(5), IA-5(1)(c), IA-7, http://iase.disa.mil/stigs/cci/Pages/index.aspx, 6.2.11, Test attestation on 20121024 by DS
|
X Window System [ref]groupThe X Window System implementation included with the system is called X.org. |
contains 1 rule |
Disable X Windows [ref]groupUnless there is a mission-critical reason for the system to run a graphical user interface, ensure X is not set to start automatically at boot and remove the X Windows software packages. There is usually no reason to run X Windows on a dedicated server machine, as it increases the system's attack surface and consumes system resources. Administrators of server systems should instead login via SSH or on the text console. |
contains 1 rule |
Remove the X Windows Package Group [ref]ruleRemoving all packages which constitute the X Window System ensures users or malicious software cannot start X. To do so, run the following command: $ sudo yum groupremove "X Window System"Rationale: Unnecessary packages should not be installed to decrease the attack surface of the system. identifiers: CCE-RHEL7-CCE-TBD references: 366, 3.2, Test attestation on 20121025 by DS |
Avahi Server [ref]groupThe Avahi daemon implements the DNS Service Discovery and Multicast DNS protocols, which provide service and host discovery on a network. It allows a system to automatically identify resources on the network, such as printers or web servers. This capability is also known as mDNSresponder and is a major part of Zeroconf networking. |
contains 1 rule |
Disable Avahi Server if Possible [ref]groupBecause the Avahi daemon service keeps an open network port, it is subject to network attacks. Disabling it can reduce the system's vulnerability to such attacks. |
contains 1 rule |
Disable Avahi Server Software [ref]rule
The $ sudo systemctl disable avahi-daemon.serviceRationale: Because the Avahi daemon service keeps an open network port, it is subject to network attacks. Its functionality is convenient but is only appropriate if the local network can be trusted. Remediation Shell script: (show)
|
Print Support [ref]groupThe Common Unix Printing System (CUPS) service provides both local
and network printing support. A system running the CUPS service can accept
print jobs from other systems, process them, and send them to the appropriate
printer. It also provides an interface for remote administration through a web
browser. The CUPS service is installed and activated by default. The project
homepage and more detailed documentation are available at http://www.cups.org.
|
contains 1 rule |
Disable the CUPS Service [ref]rule
The $ sudo systemctl disable cups.serviceRationale: Turn off unneeded services to reduce attack surface. Remediation Shell script: (show)
|
DHCP [ref]groupThe Dynamic Host Configuration Protocol (DHCP) allows
systems to request and obtain an IP address and other configuration
parameters from a server.
|
contains 1 rule |
Disable DHCP Server [ref]group
The DHCP server |
contains 1 rule |
Uninstall DHCP Server Package [ref]ruleIf the system does not need to act as a DHCP server,
the dhcp package can be uninstalled.
The $ sudo yum erase dhcpRationale: Removing the DHCP server ensures that it cannot be easily or accidentally reactivated and disrupt network operation. identifiers: CCE-RHEL7-CCE-TBD references: CM-7, 366, 3.5, Test attestation on 20121024 by DS
|
Network Time Protocol [ref]groupThe 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 2 rules |
Enable the NTP Daemon [ref]rule
The $ sudo systemctl enable chronyd.serviceNote: The chronyd daemon is enabled by default.
The ntpd service can be enabled with the following command:
$ sudo systemctl enable ntpd.serviceNote: The ntpd daemon is not enabled by default. Though as mentioned
in the previous sections in certain environments the ntpd daemon might
be preferred to be used rather than the chronyd one. Refer to:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Configuring_NTP_Using_the_chrony_Suite.html
for guidance which NTP daemon to choose depending on the environment used.
Rationale:Enabling some of identifiers: CCE-27444-9 references: AU-8(1), 160, Req-10.4, 3.6, Test attestation on 20121024 by DS
|
Specify a Remote NTP Server [ref]ruleDepending on specific functional requirements of a concrete
production environment, the Red Hat Enterprise Linux 7 Server system can be
configured to utilize the services of the
server ntpserverThis instructs the NTP software to contact that remote server to obtain time data. Rationale: Synchronizing with an NTP server makes it possible to collate system logs from multiple sources or correlate computer events with real time events. identifiers: CCE-27278-1 references: AU-8(1), 160, Req-10.4.1, Req-10.4.3, 3.6, Test attestation on 20121024 by DS
|
Mail Server Software [ref]group
Mail servers are used to send and receive email over the network.
Mail is a very common service, and Mail Transfer Agents (MTAs) are obvious
targets of network attack.
Ensure that machines are not running MTAs unnecessarily,
and configure needed MTAs as defensively as possible.
|
contains 1 rule |
Configure SMTP For Mail Clients [ref]groupThis section discusses settings for Postfix in a submission-only e-mail configuration. |
contains 1 rule |
Disable Postfix Network Listening [ref]rule
Edit the file inet_interfaces = localhostRationale:
This ensures identifiers: CCE-RHEL7-CCE-TBD references: CM-7, 382, 3.16, Test attestation on 20121024 by DS |
LDAP [ref]groupLDAP is a popular directory service, that is, a standardized way of looking up information from a central database. Red Hat Enterprise Linux 7 includes software that enables a system to act as both an LDAP client and server. |
contains 1 rule |
Configure OpenLDAP Server [ref]groupThis section details some security-relevant settings for an OpenLDAP server. Installation and configuration of OpenLDAP on Red Hat Enterprise Linux 7 is available at: https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Directory_Servers.html. |
contains 1 rule |
Uninstall openldap-servers Package [ref]ruleThe $ sudo yum erase openldap-serversThe openldap-servers RPM is not installed by default on Red Hat Enterprise Linux 7 machines. It is needed only by the OpenLDAP server, not by the clients which use LDAP for authentication. If the system is not intended for use as an LDAP Server it should be removed. Rationale: Unnecessary packages should not be installed to decrease the attack surface of the system. While this software is clearly essential on an LDAP server, it is not necessary on typical desktop or workstation systems. identifiers: CCE-RHEL7-CCE-TBD references: CM-7, 366, 3.7, Test attestation on 20121024 by DS |
NFS and RPC [ref]groupThe Network File System is a popular distributed filesystem for the Unix environment, and is very widely deployed. This section discusses the circumstances under which it is possible to disable NFS and its dependencies, and then details steps which should be taken to secure NFS's configuration. This section is relevant to machines operating as NFS clients, as well as to those operating as NFS servers. |
contains 5 rules |
Disable All NFS Services if Possible [ref]groupIf there is not a reason for the system to operate as either an NFS client or an NFS server, follow all instructions in this section to disable subsystems required by NFS. warning
The steps in this section will prevent a machine
from operating as either an NFS client or an NFS server. Only perform these
steps on machines which do not need NFS at all. |
contains 4 rules |
Disable Services Used Only by NFS [ref]groupIf NFS is not needed, disable the NFS client daemons nfslock, rpcgssd, and rpcidmapd.
|
contains 4 rules |
Disable Network File System Lock Service (nfslock) [ref]ruleThe Network File System Lock (nfslock) service starts the required
remote procedure call (RPC) processes which allow clients to lock files on the
server. If the local machine is not configured to mount NFS filesystems then
this service should be disabled.
The $ sudo systemctl disable nfslock.service identifiers: CCE-RHEL7-CCE-TBD references: 3.8
|
Disable Secure RPC Client Service (rpcgssd) [ref]rule
The rpcgssd service manages RPCSEC GSS contexts required to secure protocols
that use RPC (most often Kerberos and NFS). The rpcgssd service is the
client-side of RPCSEC GSS. If the system does not require secure RPC then this
service should be disabled.
The $ sudo systemctl disable rpcgssd.service identifiers: CCE-RHEL7-CCE-TBD references: 3.8
|
Disable rpcbind Service [ref]rule
The rpcbind utility maps RPC services to the ports on which they listen. RPC
processes notify rpcbind when they start, registering the ports they are
listening on and the RPC program numbers they expect to serve. The rpcbind
service redirects the client to the proper port number so it can communicate
with the requested service. If the system does not require RPC (such as for NFS
servers) then this service should be disabled.
The $ sudo systemctl disable rpcbind.service identifiers: CCE-RHEL7-CCE-TBD references: 3.8 |
Disable RPC ID Mapping Service (rpcidmapd) [ref]ruleThe rpcidmapd service is used to map user names and groups to UID
and GID numbers on NFSv4 mounts. If NFS is not in use on the local system then
this service should be disabled.
The $ sudo systemctl disable rpcidmapd.service identifiers: CCE-RHEL7-CCE-TBD references: 3.8
|
Configure NFS Clients [ref]groupThe steps in this section are appropriate for machines which operate as NFS clients. |
contains 1 rule |
Disable NFS Server Daemons [ref]group
There is no need to run the NFS server daemons |
contains 1 rule |
Disable Secure RPC Server Service (rpcsvcgssd) [ref]ruleThe rpcsvcgssd service manages RPCSEC GSS contexts required to
secure protocols that use RPC (most often Kerberos and NFS). The rpcsvcgssd
service is the server-side of RPCSEC GSS. If the system does not require secure
RPC then this service should be disabled.
The $ sudo systemctl disable rpcsvcgssd.serviceRationale: Unnecessary services should be disabled to decrease the attack surface of the system. identifiers: CCE-RHEL7-CCE-TBD references: Test attestation on 20121025 by DS
|
DNS Server [ref]groupMost organizations have an operational need to run at least one nameserver. However, there are many common attacks involving DNS server software, and this server software should be disabled on any system on which it is not needed. |
contains 1 rule |
Disable DNS Server [ref]groupDNS software should be disabled on any machine which does not need to be a nameserver. Note that the BIND DNS server software is not installed on Red Hat Enterprise Linux 7 by default. The remainder of this section discusses secure configuration of machines which must be nameservers. |
contains 1 rule |
Uninstall bind Package [ref]ruleTo remove the $ sudo yum erase bindRationale: If there is no need to make DNS server software available, removing it provides a safeguard against its activation. Remediation Shell script: (show)
|
FTP Server [ref]groupFTP is a common method for allowing remote access to
files. Like telnet, the FTP protocol is unencrypted, which means
that passwords and other data transmitted during the session can be
captured and that the session is vulnerable to hijacking.
Therefore, running the FTP server software is not recommended.
|
contains 1 rule |
Disable vsftpd if Possible [ref]group |
contains 1 rule |
Uninstall vsftpd Package [ref]rule
The $ sudo yum erase vsftpdRationale: Removing the vsftpd package decreases the risk of its accidental activation. Remediation Shell script: (show)
|
Web Server [ref]groupThe web server is responsible for providing access to
content via the HTTP protocol. Web servers represent a significant
security risk because:
The system's default web server software is Apache 2 and is provided in the RPM package httpd . |
contains 1 rule |
Disable Apache if Possible [ref]groupIf Apache was installed and activated, but the system does not need to act as a web server, then it should be disabled and removed from the system. |
contains 1 rule |
Uninstall httpd Package [ref]rule
The $ sudo yum erase httpdRationale: If there is no need to make the web server software available, removing it provides a safeguard against its activation. Remediation Shell script: (show)
|
IMAP and POP3 Server [ref]groupDovecot provides IMAP and POP3 services. It is not installed by default. The project page at http://www.dovecot.org contains more detailed information about Dovecot configuration. |
contains 1 rule |
Disable Dovecot [ref]groupIf the system does not need to operate as an IMAP or POP3 server, the dovecot software should be disabled and removed. |
contains 1 rule |
Uninstall dovecot Package [ref]ruleThe $ sudo yum erase dovecotRationale: If there is no need to make the Dovecot software available, removing it provides a safeguard against its activation. identifiers: CCE-RHEL7-CCE-TBD references: 3.12
|
Samba(SMB) Microsoft Windows File Sharing Server [ref]groupWhen properly configured, the Samba service allows
Linux machines to provide file and print sharing to Microsoft
Windows machines. There are two software packages that provide
Samba support. The first, |
contains 1 rule |
Disable Samba if Possible [ref]groupEven after the Samba server package has been installed, it will remain disabled. Do not enable this service unless it is absolutely necessary to provide Microsoft Windows file and print sharing functionality. |
contains 1 rule |
Uninstall Samba Package [ref]ruleThe $ sudo yum erase sambaRationale: If there is no need to make the Samba software available, removing it provides a safeguard against its activation. identifiers: CCE-RHEL7-CCE-TBD references: 3.13
|
Proxy Server [ref]groupA proxy server is a very desirable target for a potential adversary because much (or all) sensitive data for a given infrastructure may flow through it. Therefore, if one is required, the machine acting as a proxy server should be dedicated to that purpose alone and be stored in a physically secure location. The system's default proxy server software is Squid, and provided in an RPM package of the same name. |
contains 1 rule |
Disable Squid if Possible [ref]groupIf Squid was installed and activated, but the system does not need to act as a proxy server, then it should be disabled and removed. |
contains 1 rule |
Uninstall squid Package [ref]rule
The $ sudo yum erase squidRationale: If there is no need to make the proxy server software available, removing it provides a safeguard against its activation. identifiers: CCE-RHEL7-CCE-TBD references: 3.14
|
SNMP Server [ref]groupThe Simple Network Management Protocol allows administrators to monitor the state of network devices, including computers. Older versions of SNMP were well-known for weak security, such as plaintext transmission of the community string (used for authentication) and usage of easily-guessable choices for the community string. |
contains 1 rule |
Disable SNMP Server if Possible [ref]groupThe system includes an SNMP daemon that allows for its remote monitoring, though it not installed by default. If it was installed and activated but is not needed, the software should be disabled and removed. |
contains 1 rule |
Uninstall net-snmp Package [ref]ruleThe $ sudo yum erase net-snmpRationale: If there is no need to run SNMP server software, removing the package provides a safeguard against its activation. identifiers: CCE-RHEL7-CCE-TBD references: 3.15
|