Reference (cis) | Rule Title | Description | Rationale | Variable Setting |
1.1.7 | Ensure /var/tmp Located On Separate Partition |
The /var/tmp directory is a world-writable directory used
for temporary file storage. Ensure it has its own partition or
logical volume at installation time, or migrate it using LVM.
|
The /var/tmp partition is used as temporary storage by many programs.
Placing /var/tmp in its own partition enables the setting of more
restrictive mount options, which can help protect programs which use it.
|
|
1.1.11 | Ensure /var/log Located On Separate Partition |
System logs are stored in the /var/log directory.
Ensure that it has its own partition or logical
volume at installation time, or migrate it using LVM.
|
Placing /var/log in its own partition
enables better separation between log files
and other files in /var/ .
|
|
1.2.3 | Ensure Red Hat GPG Key Installed |
To 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 subscription-manager 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-KEY |
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. | |
1.5.4 | Disable Prelinking |
The prelinking feature changes binaries in an attempt to decrease their startup
time. In order to disable it, change or add the following line inside the file
/etc/sysconfig/prelink :
PRELINKING=noNext, run the following command to return binaries to a normal, non-prelinked state: $ sudo /usr/sbin/prelink -ua |
Because the prelinking feature changes binaries, it can interfere with the operation of certain software and/or modes such as AIDE, FIPS, etc. | |
1.3.1 | Install AIDE |
Install the AIDE package with the command:
$ sudo yum install aide |
The AIDE package must be installed if it is to be available for integrity checking. | |
1.1.11 | Add nodev Option to Non-Root Local Partitions | The nodev mount option prevents files from being
interpreted as character or block devices.
Legitimate character and block devices should exist only in
the /dev directory on the root partition or within chroot
jails built for system services.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
any non-root local partitions.
|
The nodev mount option prevents files from being
interpreted as character or block devices. The only legitimate location
for device files is the /dev directory located on the root partition.
The only exception to this is chroot jails, for which it is not advised
to set nodev on these filesystems. |
|
1.1.18 | Add nodev Option to Removable Media Partitions | The nodev mount option prevents files from being
interpreted as character or block devices.
Legitimate character and block devices should exist only in
the /dev directory on the root partition or within chroot
jails built for system services.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
any removable media partitions.
|
The only legitimate location for device files is the /dev directory
located on the root partition. An exception to this is chroot jails, and it is
not advised to set nodev on partitions which contain their root
filesystems. |
|
1.1.20 | Add noexec Option to Removable Media Partitions | The noexec mount option prevents the direct
execution of binaries on the mounted filesystem.
Preventing the direct execution of binaries from removable media (such as a USB
key) provides a defense against malicious software that may be present on such
untrusted media.
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
any removable media partitions.
|
Allowing users to execute binaries from removable media such as USB keys exposes the system to potential compromise. | |
1.1.3 | Add nodev Option to /tmp |
The nodev mount option can be used to prevent device files from
being created in /tmp .
Legitimate character and block devices should not exist
within temporary directories like /tmp .
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/tmp .
|
The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. |
|
1.1.5 | Add noexec Option to /tmp | The noexec mount option can be used to prevent binaries
from being executed out of /tmp .
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/tmp .
|
Allowing users to execute binaries from world-writable directories
such as /tmp should never be necessary in normal operation and
can expose the system to potential compromise. |
|
1.1.4 | Add nosuid Option to /tmp | The nosuid mount option can be used to prevent
execution of setuid programs in /tmp . The SUID and SGID permissions
should not be required in these world-writable directories.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/tmp .
|
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. | |
1.1.14 | Add nodev Option to /home | The nodev mount option can be used to prevent device files from
being created in /home .
Legitimate character and block devices should exist only in
the /dev directory on the root partition or within chroot
jails built for system services.
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/home .
|
The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. |
|
1.1.15 | Add nodev Option to /dev/shm | The nodev mount option can be used to prevent creation
of device files in /dev/shm .
Legitimate character and block devices should not exist
within temporary directories like /dev/shm .
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/dev/shm .
|
The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. |
|
1.1.17 | Add noexec Option to /dev/shm | The noexec mount option can be used to prevent binaries
from being executed out of /dev/shm .
It can be dangerous to allow the execution of binaries
from world-writable temporary storage directories such as /dev/shm .
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/dev/shm .
|
Allowing users to execute binaries from world-writable directories
such as /dev/shm can expose the system to potential compromise. |
|
1.1.16 | Add nosuid Option to /dev/shm | The nosuid mount option can be used to prevent execution
of setuid programs in /dev/shm . The SUID and SGID permissions should not
be required in these world-writable directories.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/dev/shm .
|
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. | |
1.1.6 | Bind Mount /var/tmp To /tmp | The /var/tmp directory is a world-writable directory.
Bind-mount it to /tmp in order to consolidate temporary storage into
one location protected by the same techniques as /tmp . To do so, edit
/etc/fstab and add the following line:
/tmp /var/tmp none rw,nodev,noexec,nosuid,bind 0 0See the mount(8) man page for further explanation of bind mounting.
|
Having multiple locations for temporary storage is not required. Unless absolutely
necessary to meet requirements, the storage location /var/tmp should be bind mounted to
/tmp and thus share the same protections. |
|
1.1.8 | Add nodev Option to /var/tmp |
The nodev mount option can be used to prevent device files from
being created in /var/tmp .
Legitimate character and block devices should not exist
within temporary directories like /var/tmp .
Add the nodev option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/tmp .
|
The only legitimate location for device files is the /dev directory
located on the root partition. The only exception to this is chroot jails. |
|
1.1.10 | Add noexec Option to /var/tmp | The noexec mount option can be used to prevent binaries
from being executed out of /var/tmp .
Add the noexec option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/tmp .
|
Allowing users to execute binaries from world-writable directories
such as /var/tmp should never be necessary in normal operation and
can expose the system to potential compromise. |
|
1.1.9 | Add nosuid Option to /var/tmp | The nosuid mount option can be used to prevent
execution of setuid programs in /var/tmp . The SUID and SGID permissions
should not be required in these world-writable directories.
Add the nosuid option to the fourth column of
/etc/fstab for the line which controls mounting of
/var/tmp .
|
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. | |
1.1.1.1 | Disable Mounting of cramfs |
To configure the system to prevent the cramfs
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install cramfs /bin/trueThis effectively prevents usage of this uncommon filesystem. |
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. | |
1.1.1.2 | Disable Mounting of freevxfs |
To configure the system to prevent the freevxfs
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install freevxfs /bin/trueThis effectively prevents usage of this uncommon filesystem. |
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. | |
1.1.1.3 | Disable Mounting of jffs2 |
To configure the system to prevent the jffs2
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install jffs2 /bin/trueThis effectively prevents usage of this uncommon filesystem. |
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. | |
1.1.1.4 | Disable Mounting of hfs |
To configure the system to prevent the hfs
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install hfs /bin/trueThis effectively prevents usage of this uncommon filesystem. |
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. | |
1.1.1.5 | Disable Mounting of hfsplus |
To configure the system to prevent the hfsplus
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install hfsplus /bin/trueThis effectively prevents usage of this uncommon filesystem. |
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. | |
1.1.1.6 | Disable Mounting of squashfs |
To configure the system to prevent the squashfs
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install squashfs /bin/trueThis effectively prevents usage of this uncommon filesystem. |
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. | |
1.1.1.7 | Disable Mounting of udf |
To configure the system to prevent the udf
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install udf /bin/trueThis effectively prevents usage of this uncommon filesystem. |
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. | |
6.1.3 | Verify User Who Owns shadow File |
To properly set the owner of /etc/shadow , run the command:
$ sudo chown root /etc/shadow |
The /etc/shadow file contains the list of local
system accounts and stores password hashes. Protection of this file is
critical for system security. Failure to give ownership of this file
to root provides the designated owner with access to sensitive information
which could weaken the system security posture. |
|
6.1.3 | Verify Group Who Owns shadow File |
To properly set the group owner of /etc/shadow , run the command:
$ sudo chgrp root /etc/shadow |
The /etc/shadow file stores password hashes. Protection of this file is
critical for system security. |
|
6.1.3 | Verify Permissions on shadow File |
To properly set the permissions of /etc/shadow , run the command:
$ sudo chmod 0000 /etc/shadow |
The /etc/shadow file contains the list of local
system accounts and stores password hashes. Protection of this file is
critical for system security. Failure to give ownership of this file
to root provides the designated owner with access to sensitive information
which could weaken the system security posture. |
|
6.1.4 | Verify User Who Owns group File |
To properly set the owner of /etc/group , run the command:
$ sudo chown root /etc/group |
The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. |
|
6.1.4 | Verify Group Who Owns group File |
To properly set the group owner of /etc/group , run the command:
$ sudo chgrp root /etc/group |
The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. |
|
6.1.4 | Verify Permissions on group File |
To properly set the permissions of /etc/group , run the command:
$ sudo chmod 644 /etc/group |
The /etc/group file contains information regarding groups that are configured
on the system. Protection of this file is important for system security. |
|
6.1.5 | Verify User Who Owns gshadow File |
To properly set the owner of /etc/gshadow , run the command:
$ sudo chown root /etc/gshadow |
The /etc/gshadow file contains group password hashes. Protection of this file
is critical for system security. |
|
6.1.5 | Verify Group Who Owns gshadow File |
To properly set the group owner of /etc/gshadow , run the command:
$ sudo chgrp root /etc/gshadow |
The /etc/gshadow file contains group password hashes. Protection of this file
is critical for system security. |
|
6.1.5 | Verify Permissions on gshadow File |
To properly set the permissions of /etc/gshadow , run the command:
$ sudo chmod 0000 /etc/gshadow |
The /etc/gshadow file contains group password hashes. Protection of this file
is critical for system security. |
|
6.1.2 | Verify User Who Owns passwd File |
To properly set the owner of /etc/passwd , run the command:
$ sudo chown root /etc/passwd |
The /etc/passwd file contains information about the users that are configured on
the system. Protection of this file is critical for system security. |
|
6.1.2 | Verify Group Who Owns passwd File |
To properly set the group owner of /etc/passwd , run the command:
$ sudo chgrp root /etc/passwd |
The /etc/passwd file contains information about the users that are configured on
the system. Protection of this file is critical for system security. |
|
6.1.2 | Verify Permissions on passwd File |
To properly set the permissions of /etc/passwd , run the command:
$ sudo chmod 0644 /etc/passwd |
If the /etc/passwd file is writable by a group-owner or the
world the risk of its compromise is increased. The file contains the list of
accounts on the system and associated information, and protection of this file
is critical for system security. |
|
1.1.21 | Verify that All World-Writable Directories Have Sticky Bits Set | When 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.
To set the sticky bit on a world-writable directory DIR, run the following command: $ sudo chmod +t DIR |
Failing to set the sticky bit on public directories allows unauthorized users to delete files in the directory structure.
The only authorized public directories are those temporary directories supplied with the system, or those designed to be temporary file repositories. The setting is normally reserved for directories used by the system, by users for temporary file storage (such as /tmp ), and for directories
requiring global read/write access.
|
|
6.1.10 | Ensure No World-Writable Files Exist | It is generally a good idea to remove global (other) write
access to a file when it is discovered. However, check with
documentation for specific applications before making changes.
Also, monitor for recurring world-writable files, as these may be
symptoms of a misconfigured application or user account. Finally,
this applies to real files and not virtual files that are a part of
pseudo file systems such as sysfs or procfs . |
Data in world-writable files can be modified by any user on the system. In almost all circumstances, files can be configured using a combination of user and group permissions to support whatever legitimate access is needed without the risk caused by world-writable files. | |
6.1.14 | Ensure All SGID Executables Are Authorized | The SGID (set group id) bit should be set only on files that were installed via authorized means. A straightforward means of identifying unauthorized SGID files is determine if any were not installed as part of an RPM package, which is cryptographically verified. Investigate the origin of any unpackaged SGID files. | Executable files with the SGID permission run with the privileges of the owner of the file. SGID files of uncertain provenance could allow for unprivileged users to elevate privileges. The presence of these files should be strictly controlled on the system. | |
6.1.13 | Ensure All SUID Executables Are Authorized | The SUID (set user id) bit should be set only on files that were installed via authorized means. A straightforward means of identifying unauthorized SGID files is determine if any were not installed as part of an RPM package, which is cryptographically verified. Investigate the origin of any unpackaged SUID files. | Executable files with the SUID permission run with the privileges of the owner of the file. SUID files of uncertain provenance could allow for unprivileged users to elevate privileges. The presence of these files should be strictly controlled on the system. | |
1.5.1 | Disable Core Dumps for All Users | To disable core dumps for all users, add the following line to
/etc/security/limits.conf :
* hard core 0 |
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. | |
1.5.1 | Disable Core Dumps for SUID programs |
To set the runtime status of the fs.suid_dumpable kernel parameter,
run the following command:
$ 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 = 0 |
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. | |
1.5.2 | Enable ExecShield | By default on Red Hat Enterprise Linux 7 64-bit systems, ExecShield
is enabled and can only be disabled if the hardware does not support ExecShield
or is disabled in /etc/default/grub . For Red Hat Enterprise Linux 7
32-bit systems, sysctl can be used to enable ExecShield. |
ExecShield uses the segmentation feature on all x86 systems to prevent execution in memory higher than a certain address. It writes an address as a limit in the code segment descriptor, to control where code can be executed, on a per-process basis. When the kernel places a process's memory regions such as the stack and heap higher than this address, the hardware prevents execution in that address range. This is enabled by default on the latest Red Hat and Fedora systems if supported by the hardware. | |
1.5.1 | Enable Randomized Layout of Virtual Address Space |
To set the runtime status of the kernel.randomize_va_space kernel parameter,
run the following command:
$ 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 = 2 |
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. | |
1.6.1.1 | Ensure SELinux Not Disabled in /etc/default/grub | SELinux can be disabled at boot time by an argument in
/etc/default/grub .
Remove any instances of selinux=0 from the kernel arguments in that
file to prevent SELinux from being disabled at boot.
|
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. | |
1.6.1.4 | Uninstall setroubleshoot Package | The SETroubleshoot service notifies desktop users of SELinux
denials. The service provides information around configuration errors,
unauthorized intrusions, and other potential errors.
The setroubleshoot package can be removed with the following command:
$ sudo yum erase setroubleshoot |
The SETroubleshoot service is an unnecessary daemon to have running on a server | |
1.6.1.5 | Uninstall mcstrans Package | The mcstransd daemon provides category label information
to client processes requesting information. The label translations are defined
in /etc/selinux/targeted/setrans.conf .
The mcstrans package can be removed with the following command:
$ sudo yum erase mcstrans |
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. | |
1.6.1.6 | Ensure No Daemons are Unconfined by SELinux |
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 init process, they inherit the initrc_t context.
To check for unconfined daemons, run the following command: $ 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. |
Daemons which run with the initrc_t context may cause AVC denials,
or allow privileges that the daemon does not require.
|
|
5.5 | Direct root Logins Not Allowed | To further limit access to the root account, administrators
can disable root logins at the console by editing the /etc/securetty file.
This file lists all devices the root user is allowed to login to. If the file does
not exist at all, the root user can login through any communication device on the
system, whether via the console or via a raw network interface. This is dangerous
as user can login to the system as root via Telnet, which sends the password in
plain text over the network. By default, Red Hat Enteprise Linux's
/etc/securetty file only allows the root user to login at the console
physically attached to the system. To prevent root from logging in, remove the
contents of this file. To prevent direct root logins, remove the contents of this
file by typing the following command:
$ sudo echo > /etc/securetty |
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. | |
5.4.2 | Ensure that System Accounts Do Not Run a Shell Upon Login |
Some accounts are not associated with a human user of the system, and exist to
perform some administrative function. Should an attacker be able to log into
these accounts, they should not be granted access to a shell.
The login shell for each local account is stored in the last field of each line in /etc/passwd . System accounts are those user accounts with a user ID
less than UID_MIN, where value of UID_MIN directive is set in
/etc/login.defs configuration file. In the default configuration UID_MIN is set
to 1000, thus system accounts are those user accounts with a user ID less than
1000. The user ID is stored in the third field. If any system account
SYSACCT (other than root) has a login shell, disable it with the
command: $ sudo usermod -s /sbin/nologin SYSACCT |
Ensuring shells are not given to system accounts upon login makes it more difficult for attackers to make use of system accounts. | |
5.4.4 | Ensure the Default Bash Umask is Set Correctly |
To ensure the default umask for users of the Bash shell is set properly,
add or correct the umask setting in /etc/bashrc to read
as follows:
umask |
The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users. | |
5.4.4 | Ensure the Default Umask is Set Correctly in /etc/profile |
To ensure the default umask controlled by /etc/profile is set properly,
add or correct the umask setting in /etc/profile to read as follows:
umask |
The umask value influences the permissions assigned to files when they are created. A misconfigured umask value could result in files with excessive permissions that can be read or written to by unauthorized users. | |
1.4.1 | Verify /boot/grub2/grub.cfg User Ownership | The file /boot/grub2/grub.cfg should
be owned by the root user to prevent destruction
or modification of the file.
To properly set the owner of /boot/grub2/grub.cfg , run the command:
$ sudo chown root /boot/grub2/grub.cfg |
Only root should be able to modify important boot parameters. | |
1.4.1 | Verify /boot/grub2/grub.cfg Group Ownership | The file /boot/grub2/grub.cfg should
be group-owned by the root group to prevent
destruction or modification of the file.
To properly set the group owner of /boot/grub2/grub.cfg , run the command:
$ sudo chgrp root /boot/grub2/grub.cfg |
The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway.
|
|
1.4.1 | Verify /boot/grub2/grub.cfg Permissions | File permissions for /boot/grub2/grub.cfg should be set to 600.
To properly set the permissions of /boot/grub2/grub.cfg , run the command:
$ sudo chmod 600 /boot/grub2/grub.cfg |
Proper permissions ensure that only the root user can modify important boot parameters. | |
1.4.1 | Verify /boot/efi/EFI/redhat/grub.cfg User Ownership | The file /boot/efi/EFI/redhat/grub.cfg should
be owned by the root user to prevent destruction
or modification of the file.
To properly set the owner of /boot/efi/EFI/redhat/grub.cfg , run the command:
$ sudo chown root /boot/efi/EFI/redhat/grub.cfg |
Only root should be able to modify important boot parameters. | |
1.4.1 | Verify /boot/efi/EFI/redhat/grub.cfg Group Ownership | The file /boot/efi/EFI/redhat/grub.cfg should
be group-owned by the root group to prevent
destruction or modification of the file.
To properly set the group owner of /boot/efi/EFI/redhat/grub.cfg , run the command:
$ sudo chgrp root /boot/efi/EFI/redhat/grub.cfg |
The root group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway.
|
|
1.4.1 | Verify /boot/efi/EFI/redhat/grub.cfg Permissions | File permissions for /boot/efi/EFI/redhat/grub.cfg should be set to 600.
To properly set the permissions of /boot/efi/EFI/redhat/grub.cfg , run the command:
$ sudo chmod 700 /boot/efi/EFI/redhat/grub.cfg |
Proper permissions ensure that only the root user can modify important boot parameters. | |
1.4.3 | Require Authentication for Single User Mode | Single-user mode is intended as a system recovery
method, providing a single user root access to the system by
providing a boot option at startup. By default, no authentication
is performed if single-user mode is selected.
By default, single-user mode is protected by requiring a password and is set in /usr/lib/systemd/system/rescue.service .
|
This prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password. | |
3.2.3 | Configure Kernel Parameter for Accepting Secure Redirects for All Interfaces |
To set the runtime status of the net.ipv4.conf.all.secure_redirects kernel parameter,
run the following command:
$ 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 = 0 |
Accepting "secure" ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required. | |
3.2.4 | Configure Kernel Parameter to Log Martian Packets |
To set the runtime status of the net.ipv4.conf.all.log_martians kernel parameter,
run the following command:
$ 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 = 1 |
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. | |
3.2.4 | Configure Kernel Parameter to Log Martian Packets By Default |
To set the runtime status of the net.ipv4.conf.default.log_martians kernel parameter,
run the following command:
$ 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 = 1 |
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. | |
3.2.3 | Configure Kernel Parameter for Accepting Secure Redirects By Default |
To set the runtime status of the net.ipv4.conf.default.secure_redirects kernel parameter,
run the following command:
$ 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 = 0 |
Accepting "secure" ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required. | |
3.2.6 | Configure Kernel Parameter to Ignore Bogus ICMP Error Responses |
To set the runtime status of the net.ipv4.icmp_ignore_bogus_error_responses kernel parameter,
run the following command:
$ 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 = 1 |
Ignoring bogus ICMP error responses reduces log size, although some activity would not be logged. | |
3.2.8 | Configure Kernel Parameter to Use TCP Syncookies |
To set the runtime status of the net.ipv4.tcp_syncookies kernel parameter,
run the following command:
$ 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 = 1 |
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. | |
3.2.7 | Configure Kernel Parameter to Use Reverse Path Filtering for All Interfaces |
To set the runtime status of the net.ipv4.conf.all.rp_filter kernel parameter,
run the following command:
$ 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 = 1 |
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. | |
3.2.7 | Configure Kernel Parameter to Use Reverse Path Filtering by Default |
To set the runtime status of the net.ipv4.conf.default.rp_filter kernel parameter,
run the following command:
$ 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 = 1 |
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. | |
4.3.1 | Deactivate Wireless Network Interfaces |
Deactivating wireless network interfaces should prevent
normal usage of the wireless capability.
Configure the system to disable all wireless network interfaces with the following command: $ sudo nmcli radio wifi off |
The use of wireless networking can introduce many different attack vectors into the organization's network. Common attack vectors such as malicious association and ad hoc networks will allow an attacker to spoof a wireless access point (AP), allowing validated systems to connect to the malicious AP and enabling the attacker to monitor and record network traffic. These malicious APs can also serve to create a man-in-the-middle attack or be used to create a denial of service to valid network resources. | |
3.3.3 | Disable IPv6 Networking Support Automatic Loading | To disable support for (ipv6 ) add the following line to
/etc/sysctl.d/ipv6.conf (or another file in
/etc/sysctl.d ):
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. |
Any unnecessary network stacks - including IPv6 - should be disabled, to reduce the vulnerability to exploitation. | |
3.3.1 | Configure Accepting IPv6 Router Advertisements |
To set the runtime status of the net.ipv6.conf.all.accept_ra kernel parameter,
run the following command:
$ 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 = 0 |
An illicit router advertisement message could result in a man-in-the-middle attack. | |
3.3.1 | Configure Accepting IPv6 Router Advertisements |
To set the runtime status of the net.ipv6.conf.default.accept_ra kernel parameter,
run the following command:
$ 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 = 0 |
An illicit router advertisement message could result in a man-in-the-middle attack. | |
3.3.2 | Configure Accepting IPv6 Redirects By Default |
To set the runtime status of the net.ipv6.conf.all.accept_redirects kernel parameter,
run the following command:
$ 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 = 0 |
An illicit ICMP redirect message could result in a man-in-the-middle attack. | |
3.3.2 | Configure Accepting IPv6 Redirects By Default |
To set the runtime status of the net.ipv6.conf.default.accept_redirects kernel parameter,
run the following command:
$ 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 = 0 |
An illicit ICMP redirect message could result in a man-in-the-middle attack. | |
3.5.1 | Disable DCCP Support |
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 dccp
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install dccp /bin/true |
Disabling DCCP protects the system against exploitation of any flaws in its implementation. | |
3.5.2 | Disable SCTP Support |
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 sctp
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d :
install sctp /bin/true |
Disabling SCTP protects the system against exploitation of any flaws in its implementation. | |
4.2.3 | Ensure rsyslog is Installed |
Rsyslog is installed by default.
The rsyslog package can be installed with the following command:
$ sudo yum install rsyslog |
The rsyslog package provides the rsyslog daemon, which provides system logging services. | |
4.2.1.1 | Enable rsyslog Service | The rsyslog service provides syslog-style logging by default on Red Hat Enterprise Linux 7.
The rsyslog service can be enabled with the following command:
$ sudo systemctl enable rsyslog.service |
The rsyslog service must be running in order to provide
logging services, which are essential to system administration.
|
|
4.2.1.3 | Ensure System Log Files Have Correct Permissions | The file permissions for all log files written by
rsyslog should be set to 600, or more restrictive.
These log files are determined by the second part of each Rule line in
/etc/rsyslog.conf and typically all appear in /var/log .
For each log file LOGFILE referenced in /etc/rsyslog.conf ,
run the following command to inspect the file's permissions:
$ ls -l LOGFILEIf the permissions are not 600 or more restrictive, run the following command to correct this: $ sudo chmod 0600 LOGFILE |
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. | |
4.2.1.5 | Enable rsyslog to Accept Messages via TCP, if Acting As Log Server | The rsyslog daemon should not accept remote messages
unless the system acts as a log server.
If the system needs to act as a central log server, add the following lines to
/etc/rsyslog.conf to enable reception of messages over TCP:
$ModLoad imtcp $InputTCPServerRun 514 |
If the system needs to act as a log server, this ensures that it can receive messages over a reliable TCP connection. | |
4.2.1.5 | Enable rsyslog to Accept Messages via UDP, if Acting As Log Server | The rsyslog daemon should not accept remote messages
unless the system acts as a log server.
If the system needs to act as a central log server, add the following lines to
/etc/rsyslog.conf to enable reception of messages over UDP:
$ModLoad imudp $UDPServerRun 514 |
Many devices, such as switches, routers, and other Unix-like systems, may only support the traditional syslog transmission over UDP. If the system must act as a log server, this enables it to receive their messages as well. | |
4.1.3 | Enable Auditing for Processes Which Start Prior to the Audit Daemon | To ensure all processes can be audited, even those which start
prior to the audit daemon, add the argument audit=1 to the default
GRUB 2 command line for the Linux operating system in
/etc/default/grub , in the manner below:
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/LogVol06 rd.lvm.lv=VolGroup/lv_swap rhgb quiet rd.shell=0 audit=1" |
Each process on the system carries an "auditable" flag which indicates whether
its activities can be audited. Although auditd takes care of enabling
this for all processes which launch after it does, adding the kernel argument
ensures it is set for every process during boot.
|
|
5.2.1.1 | Configure auditd Max Log File Size | Determine the amount of audit data (in megabytes)
which should be retained in each log file. Edit the file
/etc/audit/auditd.conf . Add or modify the following line, substituting
the correct value of 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. |
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. | |
5.2.1.3 | Configure auditd max_log_file_action Upon Reaching Maximum Log Size | 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 auditd , add or correct the line in /etc/audit/auditd.conf :
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.
|
Automatically rotating logs (by setting this to rotate )
minimizes the chances of the system unexpectedly running out of disk space by
being overwhelmed with log data. However, for systems that must never discard
log data, or which use external processes to transfer it and reclaim space,
keep_logs can be employed. |
|
5.2.1.2 | Configure auditd space_left Action on Low Disk Space | The auditd service can be configured to take an action
when disk space starts to run low.
Edit the file /etc/audit/auditd.conf . Modify the following line,
substituting ACTION appropriately:
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 .
|
Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption. | |
5.2.4 | Record attempts to alter time through adjtimex | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S adjtimex -F key=audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S adjtimex -F key=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 -F key=audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S adjtimex -F key=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,settimeofday -F key=audit_time_rules |
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. | |
5.2.4 | Record attempts to alter time through settimeofday | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S settimeofday -F key=audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S settimeofday -F key=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 -F key=audit_time_rulesIf the system is 64 bit then also add the following line: -a always,exit -F arch=b64 -S settimeofday -F key=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,settimeofday -F key=audit_time_rules |
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. | |
5.2.4 | Record Attempts to Alter Time Through clock_settime | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d :
-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,settimeofday -F key=audit_time_rules |
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. | |
5.2.4 | Record Attempts to Alter the localtime File | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the default),
add the following line to a file with suffix .rules in the directory
/etc/audit/rules.d :
-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. |
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. | |
5.2.6 | Record Events that Modify the System's Network Environment | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d , setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S sethostname,setdomainname -F key=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,setdomainname -F key=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_modification |
The network environment should not be modified by anything other than administrator action. Any change to network parameters should be audited. | |
5.2.7 | Record Events that Modify the System's Mandatory Access Controls | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d :
-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-policy |
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. | |
5.2.8 | Record Attempts to Alter Logon and Logout Events | The audit system already collects login information for all users
and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d in order to watch for attempted 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 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 logins |
Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. | |
5.2.9 | Record Attempts to Alter Process and Session Initiation Information | The audit system already collects process information for all
users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following lines to a file with suffix .rules in the
directory /etc/audit/rules.d 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 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 session |
Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. | |
5.2.10 | Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful) | At a minimum the audit system should collect unauthorized file
accesses for all users and root. If the auditd daemon is configured
to use the augenrules program to read audit rules during daemon
startup (the default), add the following lines to a file with suffix
.rules in the directory /etc/audit/rules.d :
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -F key=access -a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -F key=accessIf the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -F key=access -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -F key=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,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -F key=access -a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -F key=accessIf the system is 64 bit then also add the following lines: -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -F key=access -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -F key=access |
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. | |
5.2.14 | Ensure auditd Collects File Deletion Events by User | At a minimum the audit system should collect file deletion events
for all users and root. If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d , setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S rmdiri,unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=4294967295 -F key=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,unlink,unlinkat,rename -S renameat -F auid>=1000 -F auid!=4294967295 -F key=delete |
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. | |
5.2.17 | Ensure auditd Collects Information on Kernel Module Loading and Unloading | To capture kernel module loading and unloading events, use following lines, setting ARCH to
either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:
-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,delete_module -F key=modulesPlace to add the lines depends on a way auditd daemon is configured. If it is configured
to use the augenrules program (the default), add the lines to a file with suffix
.rules in the directory /etc/audit/rules.d .
If the auditd daemon is configured to use the auditctl utility,
add the lines to file /etc/audit/audit.rules .
|
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. | |
4.1.18 | Make the auditd Configuration Immutable | If the auditd daemon is configured to use the
augenrules program to read audit rules during daemon startup (the
default), add the following line to a file with suffix .rules in the
directory /etc/audit/rules.d in order to make the auditd configuration
immutable:
-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. |
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 | |
2.1.7 | Disable xinetd Service |
The xinetd service can be disabled with the following command:
$ sudo systemctl disable xinetd.service |
The xinetd service provides a dedicated listener service for some programs, which is no longer necessary for commonly-used network services. Disabling it ensures that these uncommon services are not running, and also prevents attacks against xinetd itself. | |
2.2.18 | Disable telnet Service |
The telnet service configuration file /etc/xinetd.d/telnet
is not created automatically. If it was created manually, check the
/etc/xinetd.d/telnet file and ensure that disable = no
is changed to read disable = yes as follows below:
# description: The telnet server serves telnet sessions; it uses \\ # unencrypted username/password pairs for authentication. service telnet { flags = REUSE socket_type = stream wait = no user = root server = /usr/sbin/in.telnetd log_on_failure += USERID disable = yes }If the /etc/xinetd.d/telnet file does not exist, make sure that
the activation of the telnet service on system boot is disabled
via the following command:
The rexec socket can be disabled with the following command:
$ sudo systemctl disable rexec.socket |
The telnet protocol uses unencrypted network communication, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network. The telnet protocol is also subject to man-in-the-middle attacks. | |
2.3.4 | Remove telnet Clients | The telnet client allows users to start connections to other systems via the telnet protocol. | The telnet protocol is insecure and unencrypted. The use
of an unencrypted transmission medium could allow an unauthorized user
to steal credentials. The ssh package provides an
encrypted session and stronger security and is included in Red Hat
Enterprise Linux. |
|
2.2.17 | Disable rexec Service | The rexec service, which is available with
the rsh-server package and runs as a service through xinetd or separately
as a systemd socket, should be disabled.
If using xinetd, set disable to yes in /etc/xinetd.d/rexec .
If using systemd,
The rexec socket can be disabled with the following command:
$ sudo systemctl disable rexec.socket |
The rexec service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network. | |
2.2.17 | Disable rsh Service | The rsh service, which is available with
the rsh-server package and runs as a service through xinetd or separately
as a systemd socket, should be disabled.
If using xinetd, set disable to yes in /etc/xinetd.d/rsh .
If using systemd,
The rsh socket can be disabled with the following command:
$ sudo systemctl disable rsh.socket |
The rsh service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network. | |
2.3.2 | Uninstall rsh Package | The rsh package contains the client commands
for the rsh services |
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 rsh package removes
the clients for rsh ,rcp , and rlogin .
|
|
2.2.17 | Disable rlogin Service | The rlogin service, which is available with
the rsh-server package and runs as a service through xinetd or separately
as a systemd socket, should be disabled.
If using xinetd, set disable to yes in /etc/xinetd.d/rlogin .
If using systemd,
The rlogin socket can be disabled with the following command:
$ sudo systemctl disable rlogin.socket |
The rlogin service uses unencrypted network communications, which means that data from the login session, including passwords and all other information transmitted during the session, can be stolen by eavesdroppers on the network. | |
6.2.14 | Remove Rsh Trust Files | The files /etc/hosts.equiv and ~/.rhosts (in
each user's home directory) list remote hosts and users that are trusted by the
local system when using the rshd daemon.
To remove these files, run the following command to delete them from any
location:
$ sudo rm /etc/hosts.equiv $ rm ~/.rhosts |
Trust files are convenient, but when used in conjunction with the R-services, they can allow unauthenticated access to a system. | |
2.3.1 | Remove NIS Client | The 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 (ypbind ) was used to bind a system to an NIS server
and receive the distributed configuration files. |
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. | |
2.1.6 | Disable tftp Service | The tftp service should be disabled.
The tftp service can be disabled with the following command:
$ sudo systemctl disable tftp.service |
Disabling the tftp service ensures the system is not acting
as a TFTP server, which does not provide encryption or authentication.
|
|
2.2.21 | Uninstall talk-server Package |
The talk-server package can be removed with the following command:
$ sudo yum erase talk-server |
The talk software presents a security risk as it uses unencrypted protocols
for communications. Removing the talk-server package decreases the
risk of the accidental (or intentional) activation of talk services.
|
|
2.3.3 | Uninstall talk Package | The talk package contains the client program for the
Internet talk protocol, which allows the user to chat with other users on
different systems. Talk is a communication program which copies lines from one
terminal to the terminal of another user.
The talk package can be removed with the following command:
$ sudo yum erase talk |
The talk software presents a security risk as it uses unencrypted protocols
for communications. Removing the talk package decreases the
risk of the accidental (or intentional) activation of talk client program.
|
|
1.2.5 | Disable Red Hat Network Service (rhnsd) | The 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 rhnsd service can be disabled with the following command:
$ sudo systemctl disable rhnsd.service |
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 rhnsd daemon can remain on. |
|
5.1.1 | Enable cron Service | The crond service is used to execute commands at
preconfigured times. It is required by almost all systems to perform necessary
maintenance tasks, such as notifying root of system activity.
The crond service can be enabled with the following command:
$ sudo systemctl enable crond.service |
Due to its usage for maintenance and security-supporting tasks, enabling the cron daemon is essential. | |
5.2.2 | Allow Only SSH Protocol 2 | Only SSH protocol version 2 connections should be
permitted. The default setting in
/etc/ssh/sshd_config is correct, and can be
verified by ensuring that the following
line appears:
Protocol 2 |
SSH protocol version 1 is an insecure implementation of the SSH protocol and has many well-known vulnerability exploits. Exploits of the SSH daemon could provide immediate root access to the system. | |
5.2.3 | Set LogLevel to INFO | The INFO parameter specifices that record login and logout activity will be logged.
To specify the log level in
SSH, add or correct the following line in the /etc/ssh/sshd_config file:
LogLevel INFO |
SSH provides several logging levels with varying amounts of verbosity. DEBUG is specifically
not recommended other than strictly for debugging SSH communications since it provides
so much data that it is difficult to identify important security information. INFO level is the
basic level that only records login activity of SSH users. In many situations, such as Incident
Response, it is important to determine when a particular user was active on a system. The
logout record can eliminate those users who disconnected, which helps narrow the field.
|
|
5.2.12 | Set SSH Idle Timeout Interval | SSH allows administrators to set an idle timeout
interval.
After this interval has passed, the idle user will be
automatically logged out.
To set an idle timeout interval, edit the following line in /etc/ssh/sshd_config as
follows:
ClientAliveInterval intervalThe timeout interval is given in seconds. To have a timeout of 10 minutes, set interval to 600. If a shorter timeout has already been set for the login shell, that value will preempt any SSH setting made here. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle. |
Terminating an idle ssh session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been let unattended. | |
5.2.12 | Set SSH Client Alive Count | To ensure the SSH idle timeout occurs precisely when the ClientAliveCountMax is set,
edit /etc/ssh/sshd_config as follows:
ClientAliveCountMax 0 |
This ensures a user login will be terminated as soon as the ClientAliveCountMax
is reached.
|
|
5.2.5 | Set SSH authentication attempt limit | The MaxAuthTries parameter specifies the maximum number of authentication attempts
permitted per connection. Once the number of failures reaches half this value, additional failures are logged.
to set MaxAUthTries edit /etc/ssh/sshd_config as follows:
MaxAuthTries tries |
Setting the MaxAuthTries parameter to a low number will minimize the risk of successful brute force attacks to the SSH server. | |
5.2.6 | Disable SSH Support for .rhosts Files | SSH can emulate the behavior of the obsolete rsh
command in allowing users to enable insecure access to their
accounts via .rhosts files.
To ensure this behavior is disabled, add or correct the following line in /etc/ssh/sshd_config :
IgnoreRhosts yes |
SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. | |
5.2.7 | Disable Host-Based Authentication | SSH's cryptographic host-based authentication is
more secure than .rhosts authentication. However, it is
not recommended that hosts unilaterally trust one another, even
within an organization.
To disable host-based authentication, add or correct the following line in /etc/ssh/sshd_config :
HostbasedAuthentication no |
SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. | |
5.2.4 | Enable Encrypted X11 Forwarding | By default, remote X11 connections are not encrypted when initiated
by users. SSH has the capability to encrypt remote X11 connections when SSH's
X11Forwarding option is enabled.
To enable X11 Forwarding, add or correct the following line in /etc/ssh/sshd_config :
X11Forwarding yes |
Open X displays allow an attacker to capture keystrokes and to execute commands remotely. | |
5.2.8 | Disable SSH Root Login | The 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 /etc/ssh/sshd_config :
PermitRootLogin no |
Even though the communications channel may be encrypted, an additional layer of security is gained by extending the policy of not logging directly on as root. In addition, logging in with a user-specific account provides individual accountability of actions performed on the system and also helps to minimize direct attack attempts on root's password. | |
5.2.9 | Disable SSH Access via Empty Passwords | To explicitly disallow SSH login from accounts with
empty passwords, add or correct the following line in /etc/ssh/sshd_config :
PermitEmptyPasswords no Any accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords. |
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. | |
5.2.16 | Enable SSH Warning Banner |
To enable the warning banner and ensure it is consistent
across the system, add or correct the following line in /etc/ssh/sshd_config :
Banner /etc/issueAnother section contains information on how to create an appropriate system-wide warning banner. |
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. | |
5.2.10 | Do Not Allow SSH Environment Options | To ensure users are not able to override environment
options to the SSH daemon, add or correct the following line
in /etc/ssh/sshd_config :
PermitUserEnvironment no |
SSH environment options potentially allow users to bypass access restriction in some configurations. | |
5.2.10 | Use Only FIPS 140-2 Validated Ciphers | Limit 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 /etc/ssh/sshd_config demonstrates use of
FIPS 140-2 validated ciphers:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr The following ciphers are FIPS 140-2 certified on RHEL 7: - aes128-ctr - aes192-ctr - aes256-ctr - aes128-cbc - aes192-cbc - aes256-cbc - 3des-cbc - rijndael-cbc@lysator.liu.se Any combination of the above ciphers will pass this check. Official FIPS 140-2 paperwork for RHEL7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf. |
Unapproved mechanisms that are used for authentication to the cryptographic module are not verified and therefore
cannot be relied upon to provide confidentiality or integrity, and system data may be compromised.
Operating systems utilizing encryption are required to use FIPS-compliant mechanisms for authenticating to cryptographic modules. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets industry and government requirements. For government systems, this allows Security Levels 1, 2, 3, or 4 for use on Red Hat Enterprise Linux. |
|
5.2.12 | Use Only FIPS 140-2 Validated MACs | Limit the MACs to those hash algorithms which are FIPS-approved.
The following line in /etc/ssh/sshd_config demonstrates use
of FIPS-approved MACs:
MACs hmac-sha2-512,hmac-sha2-256 Only the following message authentication codes are FIPS 140-2 certified on RHEL 7: - hmac-sha1 - hmac-sha2-256 - hmac-sha2-512 - hmac-sha1-etm@openssh.com - hmac-sha2-256-etm@openssh.com - hmac-sha2-512-etm@openssh.com Any combination of the above MACs will pass this check. Official FIPS 140-2 paperwork for RHEL7 can be found at http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2630.pdf. |
DoD Information Systems are required to use FIPS-approved cryptographic hash functions. The only SSHv2 hash algorithms meeting this requirement is SHA2. | |
2.2.3 | Disable Avahi Server Software |
The avahi-daemon service can be disabled with the following command:
$ sudo systemctl disable avahi-daemon.service |
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. | |
2.2.4 | Disable the CUPS Service |
The cups service can be disabled with the following command:
$ sudo systemctl disable cups.service |
Turn off unneeded services to reduce attack surface. | |
2.2.5 | Disable DHCP Service | The dhcpd service should be disabled on
any system that does not need to act as a DHCP server.
The dhcpd service can be disabled with the following command:
$ sudo systemctl disable dhcpd.service |
Unmanaged or unintentionally activated DHCP servers may provide faulty information to clients, interfering with the operation of a legitimate site DHCP server if there is one. | |
2.2.1.1 | Enable the NTP Daemon |
The chronyd service can be enabled with the following command:
$ 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.
|
Enabling some of chronyd or ntpd services ensures
that the NTP daemon will be running and that the system will synchronize its
time to any servers specified. This is important whether the system is
configured to be a client (and synchronize only its own clock) or it is also
acting as an NTP server to other systems. Synchronizing time is essential for
authentication services such as Kerberos, but it is also important for
maintaining accurate logs and auditing possible security breaches.
The chronyd and ntpd NTP daemons offer all of the
functionality of ntpdate , which is now deprecated. Additional
information on this is available at
http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
|
|
3.6 | Specify a Remote NTP Server | Depending 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 chronyd NTP daemon (the
default), or services of the ntpd NTP daemon. 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 more detailed comparison of the features of both of the choices, and for
further guidance how to choose between the two NTP daemons.
To specify a remote NTP server for time synchronization, perform the following:
server ntpserverThis instructs the NTP software to contact that remote server to obtain time data. |
Synchronizing with an NTP server makes it possible to collate system logs from multiple sources or correlate computer events with real time events. | |
2.2.15 | Disable Postfix Network Listening |
Edit the file /etc/postfix/main.cf to ensure that only the following
inet_interfaces line appears:
inet_interfaces = localhost |
This ensures postfix accepts mail messages
(such as cron job reports) from the local system only,
and not from the network, which protects it from network attack.
|
|
2.2.7 | Disable rpcbind Service |
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 rpcbind service can be disabled with the following command:
$ sudo systemctl disable rpcbind.service |
||
2.2.7 | Disable Network File System (nfs) | The Network File System (NFS) service allows remote hosts to mount
and interact with shared filesystems on the local system. If the local system
is not designated as a NFS server then this service should be disabled.
The nfs service can be disabled with the following command:
$ sudo systemctl disable nfs.service |
Unnecessary services should be disabled to decrease the attack surface of the system. | |
2.2.8 | Disable DNS Server |
The named service can be disabled with the following command:
$ sudo systemctl disable named.service |
All network services involve some risk of compromise due to implementation flaws and should be disabled if possible. | |
2.2.9 | Disable vsftpd Service |
The vsftpd service can be disabled with the following command:
$ sudo systemctl disable vsftpd.service |
Running FTP server software provides a network-based avenue of attack, and should be disabled if not needed. Furthermore, the FTP protocol is unencrypted and creates a risk of compromising sensitive information. | |
2.2.10 | Disable httpd Service |
The httpd service can be disabled with the following command:
$ sudo systemctl disable httpd.service |
Running web server software provides a network-based avenue of attack, and should be disabled if not needed. | |
2.2.11 | Disable Dovecot Service |
The dovecot service can be disabled with the following command:
$ sudo systemctl disable dovecot.service |
Running an IMAP or POP3 server provides a network-based avenue of attack, and should be disabled if not needed. | |
2.2.12 | Disable Samba |
The smb service can be disabled with the following command:
$ sudo systemctl disable smb.service |
Running a Samba server provides a network-based avenue of attack, and should be disabled if not needed. | |
2.2.13 | Disable Squid |
The squid service can be disabled with the following command:
$ sudo systemctl disable squid.service |
Running proxy server software provides a network-based avenue of attack, and should be removed if not needed. | |
2.2.14 | Disable snmpd Service |
The snmpd service can be disabled with the following command:
$ sudo systemctl disable snmpd.service |
Running SNMP software provides a network-based avenue of attack, and should be disabled if not needed. | |
2.1.12 | Rule Compliance through Removal of xinetd | The upstream CIS guidance is incorrect, stating that xinetd services can be managed through systemctl. The proper way to disable xinetd services, such as chargen-dgram, is to create a /etc/xinetd.d/SERVICE file which disables the service. Regardless, these rules are inherently compliant with C2S/CIS policies through the removal of xinetd itself. |
These rules are inherently compliant when xinetd is removed from the system | |
2.1.13 | Rule Compliance through Removal of xinetd | The upstream CIS guidance is incorrect, stating that xinetd services can be managed through systemctl. The proper way to disable xinetd services, such as chargen-dgram, is to create a /etc/xinetd.d/SERVICE file which disables the service. Regardless, these rules are inherently compliant with C2S/CIS policies through the removal of xinetd itself. |
These rules are inherently compliant when xinetd is removed from the system | |
2.1.14 | Rule Compliance through Removal of xinetd | The upstream CIS guidance is incorrect, stating that xinetd services can be managed through systemctl. The proper way to disable xinetd services, such as chargen-dgram, is to create a /etc/xinetd.d/SERVICE file which disables the service. Regardless, these rules are inherently compliant with C2S/CIS policies through the removal of xinetd itself. |
These rules are inherently compliant when xinetd is removed from the system | |
2.1.15 | Rule Compliance through Removal of xinetd | The upstream CIS guidance is incorrect, stating that xinetd services can be managed through systemctl. The proper way to disable xinetd services, such as chargen-dgram, is to create a /etc/xinetd.d/SERVICE file which disables the service. Regardless, these rules are inherently compliant with C2S/CIS policies through the removal of xinetd itself. |
These rules are inherently compliant when xinetd is removed from the system | |
2.1.16 | Rule Compliance through Removal of xinetd | The upstream CIS guidance is incorrect, stating that xinetd services can be managed through systemctl. The proper way to disable xinetd services, such as chargen-dgram, is to create a /etc/xinetd.d/SERVICE file which disables the service. Regardless, these rules are inherently compliant with C2S/CIS policies through the removal of xinetd itself. |
These rules are inherently compliant when xinetd is removed from the system | |
2.1.17 | Rule Compliance through Removal of xinetd | The upstream CIS guidance is incorrect, stating that xinetd services can be managed through systemctl. The proper way to disable xinetd services, such as chargen-dgram, is to create a /etc/xinetd.d/SERVICE file which disables the service. Regardless, these rules are inherently compliant with C2S/CIS policies through the removal of xinetd itself. |
These rules are inherently compliant when xinetd is removed from the system | |
2.1.18 | Rule Compliance through Removal of xinetd | The upstream CIS guidance is incorrect, stating that xinetd services can be managed through systemctl. The proper way to disable xinetd services, such as chargen-dgram, is to create a /etc/xinetd.d/SERVICE file which disables the service. Regardless, these rules are inherently compliant with C2S/CIS policies through the removal of xinetd itself. |
These rules are inherently compliant when xinetd is removed from the system |