draft This guide presents a catalog of security-relevant configuration settings for Red Hat Enterprise Linux 6 formatted in the eXtensible Configuration Checklist Description Format (XCCDF). 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 RHEL 6 is one example of a baseline created from this guidance. Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. The creators of this guidance assume no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic. The SCAP Security Guide Projecthttps://fedorahosted.org/scap-security-guide Red Hat and Red Hat Enterprise Linux are either registered trademarks or trademarks of Red Hat, Inc. in the United States and other countries. All other names are registered trademarks or trademarks of their respective companies. 0.9 This is a *draft* SCAP profile for Red Hat Certified Cloud Providers This is a *draft* SCAP profile for Red Hat Certified Cloud Providers This profile is for testing. This profile contains items common to general-purpose desktop and server installations. This profile contains items common to general-purpose desktop and server installations.This profile is for a desktop installation of RHEL 6. This profile contains items common to general-purpose desktop and server installations.This profile is for RHEL 6 acting as a server. This profile contains items common to general-purpose desktop and server installations.This profile is for RHEL 6 acting as a server.This profile is for FTP servers. This profile contains items common to general-purpose desktop and server installations.This profile is being developed under the DoD consensus model to become a STIG in coordination with DISA FSO. A conditional clause for check statements. This is a placeholder. Description for Addl RHT CCP Checks. 1 This was checked in previous CCP image certification processes The purpose of this guidance is to provide security configuration recommendations and baselines for the Red Hat Enterprise Linux (RHEL) 6 operating system. The guidance provided here should be applicable to all variants (Desktop, Server, Advanced Platform) of the product. Recommended settings for the basic operating system are provided, as well as for many network services that the system can provide to other systems. The guide is intended for system administrators. Readers are assumed to possess basic system administration skills for Unix-like systems, as well as some familiarity with Red Hat's documentation and administration conventions. Some instructions within this guide are complex. All directions should be followed completely and with understanding of their effects in order to avoid serious adverse effects on the system and its security. The following general principles motivate much of the advice in this guide and should also influence any configuration decisions that are not explicitly covered. Data transmitted over a network, whether wired or wireless, is susceptible to passive monitoring. Whenever practical solutions for encrypting such data exist, they should be applied. Even if data is expected to be transmitted only over a local network, it should still be encrypted. Encrypting authentication data, such as passwords, is particularly important. Networks of RHEL 6 machines can and should be configured so that no unencrypted authentication data is ever transmitted between machines. The simplest way to avoid vulnerabilities in software is to avoid installing that software. On RHEL, the RPM Package Manager (originally Red Hat Package Manager, abbreviated RPM) allows for careful management of the set of software packages installed on a system. Installed software contributes to system vulnerability in several ways. Packages that include setuid programs may provide local attackers a potential path to privilege escalation. Packages that include network services may give this opportunity to network-based attackers. Packages that include programs which are predictably executed by local users (e.g. after graphical login) may provide opportunities for trojan horses or other attack code to be run undetected. The number of software packages installed on a system can almost always be significantly pruned to include only the software for which there is an environmental or operational need. Whenever possible, a server should be dedicated to serving exactly one network service. This limits the number of other services that can be compromised in the event that an attacker is able to successfully exploit a software flaw in one network service. Several tools exist which can be effectively used to improve a system's resistance to and detection of unknown attacks. These tools can improve robustness against attack at the cost of relatively little configuration effort. In particular, this guide recommends and discusses the use of Iptables for host-based firewalling, SELinux for protection against vulnerable services, and a logging and auditing infrastructure for detection of problems. Grant the least privilege necessary for user accounts and software to perform tasks. For example, sudo can be implemented to limit authorization to super user accounts on the system only to designated personnel. Another example is to limit logins on server systems to only those administrators who need to log into them in order to perform administration tasks. Using SELinux also follows the principle of least privilege: SELinux policy can confine software to perform only actions on the system that are specifically allowed. This can be far more restrictive than the actions permissible by the traditional Unix permissions model. Readers should heed the following points when using the guide. Each section may build on information and recommendations discussed in prior sections. Each section should be read and understood completely; instructions should never be blindly applied. Relevant discussion may occur after instructions for an action. This guidance should always be tested in a non-production environment before deployment. This test environment should simulate the setup in which the system will be deployed as closely as possible. Most of the actions listed in this document are written with the assumption that they will be executed by the root user running the /bin/bash shell. Commands preceded with a hash mark (#) assume that the administrator will execute the commands as root, i.e. apply the command via sudo whenever possible, or use su to gain root privileges if sudo cannot be used. Commands which can be executed as a non-root user are are preceded by a dollar sign ($) prompt. Commands intended for shell execution, as well as configuration file text, are featured in a monospace font. Italics are used to indicate instances where the system administrator must substitute the appropriate information into a command or configuration file. A system reboot is implicitly required after some actions in order to complete the reconfiguration of the system. In many cases, the changes will not take effect until a reboot is performed. In order to ensure that changes are applied properly and to test functionality, always reboot the system after applying a set of recommendations from this guide. The following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates. To 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 /, /boot, and swap. If starting with any of the default layouts, check the box to "Review and modify partitioning." This allows for the easy creation of additional logical volumes inside the volume group already created, though it may require making /'s logical volume smaller to create space. In general, using logical volumes is preferable to using partitions because they can be more easily adjusted later.If creating a custom layout, create the partitions mentioned in the previous paragraph (which the installer will require anyway), as well as separate ones described in the following sections. If a system has already been installed, and the default partitioning scheme was used, it is possible but nontrivial to modify it to create separate logical volumes for the directories listed above. The Logical Volume Manager (LVM) makes this possible. See the LVM HOWTO at http://tldp.org/HOWTO/LVM-HOWTO/ for more detailed information on LVM. The /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. 1208 MM 20120928 The /tmp partition is used as temporary storage by many programs. Placing /tmp in its own partition enables the setting of more restrictive mount options, which can help protect programs which use it. CCE-26435-8 Run the following command to determine if /tmp is on its own partition or logical volume: $ mount | grep "on /tmp " If /tmp has its own partition or volume group, a line will be returned. The /var directory is used by daemons and other system services to store frequently-changing data. Ensure that /var has its own partition or logical volume at installation time, or migrate it using LVM. 1208 MM 20120928 Ensuring that /var is mounted on its own partition enables the setting of more restrictive mount options. This helps protect system services such as daemons or other programs which use it. It is not uncommon for the /var directory to contain world-writable directories, installed by other software packages. CCE-26639-5 Run the following command to determine if /var is on its own partition or logical volume: $ mount | grep "on /var " If /var has its own partition or volume group, a line will be returned. 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. AU-9 1208 MM 20120928 Placing /var/log in its own partition enables better separation between log files and other files in /var/. CCE-26215-4 Run the following command to determine if /var/log is on its own partition or logical volume: $ mount | grep "on /var/log " If /var/log has its own partition or volume group, a line will be returned. Audit logs are stored in the /var/log/audit directory. Ensure that it has its own partition or logical volume at installation time, or migrate it later using LVM. Make absolutely certain that it is large enough to store all audit logs that will be created by the auditing daemon. AU-4 AU-9 137 138 1208 MM 20120928 Placing /var/log/audit in its own partition enables better separation between audit files and other files, and helps ensure that auditing cannot be halted due to the partition running out of space. CCE-26436-6 Run the following command to determine if /var/log/audit is on its own partition or logical volume: $ mount | grep "on /var/log/audit " If /var/log/audit has its own partition or volume group, a line will be returned. If user home directories will be stored locally, create a separate partition for /home at installation time (or migrate it later using LVM). If /home will be mounted from another system such as an NFS server, then creating a separate partition is not necessary at installation time, and the mountpoint can instead be configured later. 1208 MM 20120928 Ensuring that /home is mounted on its own partition enables the setting of more restrictive mount options, and also helps ensure that users cannot trivially fill partitions used for log or audit data storage. CCE-26557-9 Run the following command to determine if /home is on its own partition or logical volume: $ mount | grep "on /home " If /home has its own partition or volume group, a line will be returned. Red Hat Enterprise Linux 6 natively supports partition encryption through the Linux Unified Key Setup-on-disk-format (LUKS) technology. The easiest way to encrypt a partition is during installation time. For manual installations, select the Encrypt checkbox during partition creation to encrypt the partition. When this option is selected the system will prompt for a passphrase to use in decrypting the partition. The passphrase will subsequently need to be entered manually every time the system boots. For automated/unattended installations, it is possible to use Kickstart by adding the --encrypted and --passphrase= options to the definition of each partition to be encrypted. For example, the following line would encrypt the root partition: part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=PASSPHRASE Any PASSPHRASE is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly. Omitting the --passphrase= option from the partition definition will cause the installer to pause and interactively ask for the passphrase during installation. Detailed information on encrypting partitions using LUKS can be found on the Red Had Documentation web site: https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html SC-13 SC-28 1019 1199 1200 The risk of a system's physical compromise, particularly mobile systems such as laptops, places its data at risk of compromise. Encrypting this data mitigates the risk of its loss if the system is lost. Determine if encryption must be used to protect data on the system. The yum command line tool is used to install and update software packages. The system also provides a graphical software update tool in the System menu, in the Administration submenu, called Software Update. Red Hat Enterprise Linux systems contain an installed software catalog called the RPM database, which records metadata of installed packages. Tools such as yum or the graphical Software Update ensure usage of RPM packages for software installation. This allows for insight into the current inventory of installed software on the system, and is highly recommended. 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 if desired), the Red Hat GPG key must properly be installed. To ensure the GPG key is installed, run: # rhn_register If the system is not connected to the internet, or a local RHN Satellite, then install the Red Hat GPG key from a secure, static location, such as the Red Hat installation CD-ROM or DVD. Assuming the disc is mounted in /mnt/cdrom, use the following command as the root user to import it into the keyring: # rpm --import /mnt/cdrom/RPM-GPG-KEY SI-7 MA-1(b) 351 MM 20120928 This key is necessary to cryptographically verify packages are from Red Hat. CCE-26506-6 To ensure that the GPG key is installed, run: $ rpm -q --queryformat "%{SUMMARY}\n" gpg-pubkey The command should return the string below: gpg(Red Hat, Inc. (release key 2) <security@redhat.com> The gpgcheck option should be used to ensure checking of an RPM package's signature always occurs prior to its installation. To configure yum to check package signatures before installing them, ensure the following line appears in /etc/yum.conf in the [main] section: gpgcheck=1 SI-7 MA-1(b) 352 663 MM 20120928 Ensuring the validity of packages' cryptographic signatures prior to installation ensures the provenance of the software and protects against malicious tampering. CCE-26709-6 To determine whether yum is configured to use gpgcheck, inspect /etc/yum.conf and ensure the following appears in the [main] section: gpgcheck=1 A value of 1 indicates that gpgcheck is enabled. Absence of a gpgcheck line or a setting of 0 indicates that it is disabled. To ensure signature checking is not disabled for any repos, remove any lines from files in /etc/yum.repos.d of the form: gpgcheck=0 SI-7 MA-1(b) 352 663 MM 20120928 Ensuring all packages' cryptographic signatures are valid prior to installation ensures the provenance of the software and protects against malicious tampering. CCE-26647-8 To determine whether yum has been configured to disable gpgcheck for any repos, inspect all files in /etc/yum.repos.d and ensure the following does not appear in any sections: gpgcheck=0 A value of 0 indicates that gpgcheck has been disabled for that repo. If 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: # yum update If 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. SI-2 MA-1(b) 1227 1233 MM 20120928 Installing software updates is a fundamental mitigation against the exploitation of publicly-known vulnerabilities. If the system is joined to the Red Hat Network, a Red Hat Satellite Server, or a yum server which provides updates, invoking the following command will indicate if updates are available: # yum check-update If the system is not configured to update from one of these sources, run the following command to list when each package was last updated: $ rpm -qa -last Compare this to Red Hat Security Advisories (RHSA) listed at https://access.redhat.com/security/updates/active/ to determine if the system is missing applicable updates. 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. Integrity checking cannot prevent intrusions into your system, but can detect that they have occurred. Requirements for software integrity checking may be highly dependent on the environment in which the system will be used. Snapshot-based approaches such as AIDE may induce considerable overhead in the presence of frequent software updates. AIDE conducts integrity checks by comparing information about files with previously-gathered information. Ideally, the AIDE database should be created immediately after your system is built, and then again after any software update. AIDE is highly configurable, with further configuration information located in /usr/share/doc/aide-VERSION. Install the AIDE package with the command: # yum install aide CM-3(d) CM-3(e) CM-6(d) CM-6(3) SC-28 SI-7 1069 DS 20121024 The AIDE package must be installed if it is to be available for integrity checking. CCE-27024-9 yum -y install aide Run the following command to determine if the aide package is installed: # rpm -q aide 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=no Next, run the following command to return binaries to a normal, non-prelinked state: # /usr/sbin/prelink -ua CM-6(d) CM-6(3) SC-28 SI-7 The prelinking feature can interfere with the operation of AIDE, because it changes binaries. CCE-27221-1 Run the following command to generate a new database: # /usr/sbin/aide --init By default, the database will be written to the file /var/lib/aide/aide.db.new.gz. Storing the database, the configuration file /etc/aide.conf, and the binary /usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity. The newly-generated database can be installed as follows: # cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz To initiate a manual check, run the following command: # /usr/sbin/aide --check If this check produces any unexpected output, investigate. CM-3(d) CM-3(e) CM-6(d) CM-6(3) SC-28 SI-7 For AIDE to be effective, an initial database of "known-good" information about files must be captured and it should be able to be verified against the installed files. AIDE should be executed on a periodic basis to check for changes. To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab: 05 4 * * * root /usr/sbin/aide --check AIDE can be executed periodically through other means; this is merely one example. CM-3(d) CM-3(e) CM-6(d) CM-6(3) SC-28 SI-7 374 416 1069 1263 1297 1589 By default, AIDE does not install itself for periodic execution. Periodically running AIDE may reveal unexpected changes in installed files. CCE-27222-9 To determine that periodic AIDE execution has been scheduled, run the following command: # grep aide /etc/crontab The 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 -qVa See the man page for rpm to see a complete explanation of each column. The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. The following command will reset permissions to their expected values: # rpm --setperms package AC-6 CM-6(d) CM-6(3) 1493 1494 1495 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. CCE-26731-0 The following command will list which files on the system have permissions different from what is expected by the RPM database: # rpm -Va | grep '^.M' The 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 that has changed was not expected to then refresh from distribution media or online repositories. rpm -Uvh affected_package OR yum reinstall affected_package CM-6(d) CM-6(3) SI-7 1496 The hash on 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. CCE-27223-7 The following command will list which files on the system have file hashes different from what is expected by the RPM database. # rpm -Va | grep '$1 ~ /..5/ && $2 != "c"' Additional security software that is not provided or supported by Red Hat can be installed to provide complementary or duplicative security capabilities to those provided by the base platform. Add-on software may not be appropriate for some specialized systems. The base Red Hat platform already includes a sophisticated auditing system that can detect intruder activity, as well as SELinux, which provides host-based intrusion prevention capabilities by confining privileged programs and user sessions which may become compromised. Install an additional intrusion detection tool to provide complementary or duplicative monitoring, reporting, and reaction capabilities to those of the base platform. For DoD systems, the McAfee Host Based Security System is provided to fulfill this role. SC-7 1263 Adding host-based intrusion detection tools can provide the capability to automatically take actions in response to malicious behavior, which can provide additional agility in reacting to network threats. These tools also often include a reporting capability to provide network awareness of system, which may not otherwise exist in an organization's systems management regime. Inspect the system to determine if intrusion detection software has been installed. Verify the intrusion detection software is active. Install virus scanning software, which uses signatures to search for the presence of viruses on the filesystem. The McAfee uvscan virus scanning tool is provided for DoD systems. Ensure virus definition files are no older than 7 days, or their last release. Configure the virus scanning software to perform scans dynamically on all accessed files. If this is not possible, configure the system to scan all altered files on the system on a daily basis. If the system processes inbound SMTP mail, configure the virus scanner to scan all received mail. SC-28 SI-3 1239 1668 Virus scanning software can be used to detect if a system has been compromised by computer viruses, as well as to limit their spread to other systems. Inspect the system for a cron job or system service which executes a virus scanning tool regularly. To verify the McAfee command line scan tool (uvscan) is scheduled for regular execution, run the following command to check for a cron job: # grep uvscan /etc/cron* /var/spool/cron/* This will reveal if and when the uvscan program will be run. To check on the age of uvscan virus definition files, run the following command: # cd /usr/local/uvscan # ls -la avvscan.dat avvnames.dat avvclean.dat Traditional 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. Adhere to the principle of least privilege - configure each file, directory, and filesystem to allow only the access needed in order for that file to serve its purpose. Note: Several of the commands in this section search filesystems for files or directories with certain characteristics, and are intended to be run on every local partition on a given machine. When the variable PART appears in one of the commands below, it means that the command is intended to be run repeatedly, with the name of each local partition substituted for PART in turn. The following command prints a list of ext4 partitions on the local machine, which is the default filesystem for Red Hat Enterprise Linux 6 installations: $ mount -t ext4 | awk '{print $3}' If your site uses a local filesystem type other than ext4, you will need to modify this command. System partitions can be mounted with certain options that limit what files on those partitions can do. These options are set in the /etc/fstab configuration file, and can be used to make certain types of malicious behavior more difficult. This value is used by the checks mount_option_nodev_removable_partitions, mount_option_nodev_removable_partitions, and mount_option_nodev_removable_partitions to ensure that the correct mount options are set on partitions mounted from removable media such as CD-ROMs, USB keys, and floppy drives. This value should be modified to reflect any removable partitions that are required on the local system. /dev/cdrom 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. CM-7 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. CCE-27045-4 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. AC-19(a) AC-19(d) AC-19(e) CM-7 MP-2 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. CCE-26860-7 The noexec mount option prevents the direct execution of binaries on the mounted filesystem. Users should not be allowed to execute binaries that exist on partitions mounted from removable media (such as a USB key). The noexec option prevents code from being executed directly from the media itself, and may therefore provide a line of defense against certain types of worms or malicious code. Add the noexec option to the fourth column of /etc/fstab for the line which controls mounting of any removable media partitions. AC-19(a) AC-19(d) AC-19(e) CM-7 MP-2 87 Allowing users to execute binaries from removable media such as USB keys exposes the system to potential compromise. CCE-27196-5 To verify that binaries cannot be directly executed from removable media, run the following command: # grep -v noexec /etc/fstab The resulting output will show partitions which do not have the noexec flag. Verify all partitions in the output are not removable media. The nosuid mount option prevents set-user-identifier (suid) and set-group-identifier (sgid) permissions from taking effect. These permissions allow users to execute binaries with the same permissions as the owner and group of the file respectively. Users should not be allowed to introduce suid and guid files into the system via partitions mounted from removeable media. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of any removable media partitions. AC-19(a) AC-19(d) AC-19(e) CM-7 MP-2 The presence of suid and sgid executables should be tightly controlled. Users should not be able to execute suid or sgid binaries from partitions mounted off of removable media. CCE-27056-1 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. CM-7 MP-2 The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails. CCE-26499-4 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. CM-7 MP-2 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. CCE-26720-3 The nosuid mount option can be used to prevent execution of setuid programs in /tmp. The suid/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. CM-7 MP-2 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. CCE-26762-5 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. CM-7 MP-2 The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails. CCE-26778-1 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. CM-7 MP-2 Allowing users to execute binaries from world-writable directories such as /dev/shm can expose the system to potential compromise. CCE-26622-1 The nosuid mount option can be used to prevent execution of setuid programs in /dev/shm. The suid/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. CM-7 MP-2 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. CCE-26486-1 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 0 See the mount(8) man page for further explanation of bind mounting. CM-7 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. CCE-26582-7 Linux includes a number of facilities for the automated addition and removal of filesystems on a running system. These facilities may increase convenience, but they all bring some risk -- whether direct risk from allowing unprivileged users to introduce arbitrary filesystems to a machine, or risk that software flaws in the automated mount facility itself will allow an attacker to compromise the system. This command can be used to list the types of filesystems that are available to the currently executing kernel: # find /lib/modules/`uname -r`/kernel/fs -type f -name '*.ko' If these filesystems are not required then they should be explicitly disabled in the appropriate /etc/modprobe.d configuration file. Use caution when enabling any such facility, and find out whether better configuration management or user education might solve the same problem with less risk. To prevent USB storage devices from being used, configure the kernel module loading system to prevent automatic loading of the USB storage driver. To configure the system to prevent the usb-storage kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d: install usb-storage /bin/false This will prevent the modprobe program from loading the usb-storage module, but will not prevent an administrator (or another program) from using the insmod program to load the module manually. AC-19(a) AC-19(d) AC-19(e) 1250 85 USB storage devices such as thumb drives can be used to introduce unauthorized software and other vulnerabilities. Support for these devices should be disabled and the devices themselves should be tightly controlled. CCE-27016-5 If the system is configured to prevent the loading of the usb-storage kernel module, it will contain lines inside any file in /etc/modprobe.d or the deprecated/etc/modprobe.conf. These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event. Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf: $ grep -r usb-storage /etc/modprobe.conf /etc/modprobe.d Another means of disabling USB storage is to disable all USB support provided by the operating system. This can be accomplished by adding the nousb argument to the kernel's boot loader configuration. To disable kernel support for USB, append "nousb" to the kernel line in /etc/grub.conf as follows: kernel /vmlinuz-VERSION ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet nousb WARNING: Disabling all kernel support for USB will cause problems for systems with USB-based keyboards, mice, or printers. This guidance is inappropriate for systems which require USB connectivity. AC-19(a) AC-19(d) AC-19(e) 1250 85 Disabling the USB subsystem within the Linux kernel at system boot will also disable USB storage devices if they are plugged into the system. Support for these devices should be disabled and the devices themselves should be tightly controlled. CCE-27011-6 An attacker with physical access could try to boot the system from a USB flash drive and then access any data on the system's hard drive, circumventing the normal operating system's access controls. To prevent this, configure the BIOS to disallow booting from USB drives. Also configure the BIOS or firmware password as described in the section titled "Set BIOS Password" to prevent unauthorized configuration changes. AC-19(a) AC-19(d) AC-19(e) 1250 85 Booting a system from a USB device would allow an attacker to circumvent any security measures offered by the native OS. Attackers could mount partitions and modify the configuration of the native OS. The BIOS should be configured to disallow booting from USB media. The autofs daemon mounts and unmounts filesystems, such as user home directories shared via NFS, on demand. In addition, autofs can be used to handle removable media, and the default configuration provides the cdrom device as /misc/cd. However, this method of providing access to removable media is not common, so autofs can almost always be disabled if NFS is not in use. Even if NFS is required, it is almost always possible to configure filesystem mounts statically by editing /etc/fstab rather than relying on the automounter. If the autofs service is not needed to dynamically mount NFS filesystems or removable media, disable the service for all runlevels: # chkconfig --level 0123456 autofs off Stop the service if it is already running: # service autofs stop AC-19(a) AC-19(d) AC-19(e) 1250 85 All filesystems that are required for the successful operation of the system should be explicitly listed in /etc/fstab by and administrator. New filesystems should not be arbitrarily introduced via the automounter. CCE-26976-1 To verify the autofs service is disabled, run the following command: chkconfig --list autofs If properly configured, the output should be the following: autofs 0:off 1:off 2:off 3:off 4:off 5:off 6:off The system's default desktop environment, GNOME, will mount devices and removable media (such as DVDs, CDs and USB flash drives) whenever they are inserted into the system. Disable automount and autorun within GNOME by running the following: # gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type bool \ --set /apps/nautilus/preferences/media_automount false # gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type bool \ --set /apps/nautilus/preferences/media_autorun_never true These settings can be verified by running the following: $ gconftool-2 --direct \ --config-source xml:read:/etc/gconf/gconf.xml.mandatory \ --get /apps/nautilus/preferences/media_automount $ gconftool-2 --direct \ --config-source xml:read:/etc/gconf/gconf.xml.mandatory \ --get /apps/nautilus/preferences/media_autorun_never AC-19(a) AC-19(d) AC-19(e) 1250 85 The system's capabilities for automatic mounting should be configured to match whatever is defined by security policy. Disabling USB storage as described in the USB section will prevent the use of USB storage devices, but this step should also be taken as an additional layer of protection to prevent automatic mounting of CDs and DVDs. CCE-27035-5 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/false This effectively prevents usage of this uncommon filesystem. CM-7 Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. CCE-26340-0 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/false This effectively prevents usage of this uncommon filesystem. CM-7 Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. CCE-26544-7 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/false This effectively prevents usage of this uncommon filesystem. CM-7 Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. CCE-26670-0 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/false This effectively prevents usage of this uncommon filesystem. CM-7 Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. CCE-26800-3 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/false This effectively prevents usage of this uncommon filesystem. CM-7 Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. CCE-26361-6 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/false This effectively prevents usage of this uncommon filesystem. CM-7 Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. CCE-26404-4 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/false This effectively prevents usage of this uncommon filesystem. CM-7 Linux kernel modules which implement filesystems that are not needed by the local system should be disabled. CCE-26677-5 The system's default desktop environment, GNOME, uses a number of different thumbnailer programs to generate thumbnails for any new or modified content in an opened folder. The following command can disable the execution of these thumbnail applications: # gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type bool \ --set /desktop/gnome/thumbnailers/disable_all true This effectively prevents an attacker from gaining access to a system through a flaw in GNOME's Nautilus thumbnail creators. CM-7 An attacker with knowledge of a flaw in a GNOME thumbnailer application could craft a malicious file to exploit this flaw. Assuming the attacker could place the malicious file on the local filesystem (via a web upload for example) and assuming a user browses the same location using Nautilus, the malicious file would exploit the thumbnailer with the potential for malicious code execution. It is best to disable these thumbnailer applications unless they are explicitly required. CCE-27224-5 Permissions 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. The default restrictive permissions for files which act as important security databases such as passwd, shadow, group, and gshadow files must be maintained. Many utilities need read access to the passwd file in order to function properly, but read access to the shadow file allows malicious attacks against system passwords, and should never be enabled. To properly set the owner of /etc/shadow, run the command: # chown root /etc/shadow AC-6 225 DS 20121026 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. CCE-26947-2 To check the ownership of /etc/shadow, run the command: $ ls -lL /etc/shadow If properly configured, the output should indicate the following owner: root To properly set the group owner of /etc/shadow, run the command: # chgrp root /etc/shadow AC-6 225 DS 20121026 The /etc/shadow file stores password hashes. Protection of this file is critical for system security. CCE-26967-0 To check the group ownership of /etc/shadow, run the command: $ ls -lL /etc/shadow If properly configured, the output should indicate the following group-owner. root To properly set the permissions of /etc/shadow, run the command: # chmod 0000 /etc/shadow AC-6 225 DS 20121026 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. CCE-26992-8 To check the permissions of /etc/shadow, run the command: $ ls -l /etc/shadow If properly configured, the output should indicate the following permissions: ---------- To properly set the owner of /etc/group, run the command: # chown root /etc/group AC-6 DS 20121026 The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security. CCE-26822-7 To check the ownership of /etc/group, run the command: $ ls -lL /etc/group If properly configured, the output should indicate the following owner: root To properly set the group owner of /etc/group, run the command: # chgrp root /etc/group AC-6 225 DS 20121026 The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security. CCE-26930-8 To check the group ownership of /etc/group, run the command: $ ls -lL /etc/group If properly configured, the output should indicate the following group-owner. root To properly set the permissions of /etc/group, run the command: # chmod 644 /etc/group AC-6 225 DS 20121026 The /etc/group file contains information regarding groups that are configured on the system. Protection of this file is important for system security. CCE-26954-8 To check the permissions of /etc/group, run the command: $ ls -l /etc/group If properly configured, the output should indicate the following permissions: -rw-r--r-- To properly set the owner of /etc/gshadow, run the command: # chown root /etc/gshadow AC-6 225 DS 20121026 The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security. CCE-27026-4 To check the ownership of /etc/gshadow, run the command: $ ls -lL /etc/gshadow If properly configured, the output should indicate the following owner: root To properly set the group owner of /etc/gshadow, run the command: # chgrp root /etc/gshadow AC-6 225 DS 20121026 The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security. CCE-26975-3 To check the group ownership of /etc/gshadow, run the command: $ ls -lL /etc/gshadow If properly configured, the output should indicate the following group-owner. root To properly set the permissions of /etc/gshadow, run the command: # chmod 0000 /etc/gshadow AC-6 225 DS 20121026 The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security. CCE-26951-4 To check the permissions of /etc/gshadow, run the command: $ ls -l /etc/gshadow If properly configured, the output should indicate the following permissions: ---------- To properly set the owner of /etc/passwd, run the command: # chown root /etc/passwd AC-6 225 DS 20121026 The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security. CCE-26953-0 To check the ownership of /etc/passwd, run the command: $ ls -lL /etc/passwd If properly configured, the output should indicate the following owner: root To properly set the group owner of /etc/passwd, run the command: # chgrp root /etc/passwd AC-6 225 DS 20121026 The /etc/passwd file contains information about the users that are configured on the system. Protection of this file is critical for system security. CCE-26856-5 To check the group ownership of /etc/passwd, run the command: $ ls -lL /etc/passwd If properly configured, the output should indicate the following group-owner. root To properly set the permissions of /etc/passwd, run the command: # chmod 0644 /etc/passwd AC-6 225 DS 20121026 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. CCE-26868-0 To check the permissions of /etc/passwd, run the command: $ ls -l /etc/passwd If properly configured, the output should indicate the following permissions: -rw-r--r-- Some directories contain files whose confidentiality or integrity is notably important and may also be susceptible to misconfiguration over time, particularly if unpackaged software is installed. As such, an argument exists to verify that files' permissions within these directories remain configured correctly and restrictively. System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: /lib /lib64 /usr/lib /usr/lib64 Kernel modules, which can be added to the kernel during runtime, are stored in /lib/modules. All files in these directories should not be group-writable or world-writable. If any file in these directories is found to be group-writable or world-writable, correct its permission with the following command: # chmod go-w FILE AC-6 1499 DS 20121026 Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Restrictive permissions are necessary to protect the integrity of the system. Shared libraries are stored in the following directories: /lib /lib64 /usr/lib /usr/lib64 To find shared libraries that are group-writable or world-writable, run the following command for each directory DIR which contains shared libraries: $ find DIR -perm /022 -type f System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: /lib /lib64 /usr/lib /usr/lib64 Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be owned by the root user. If any file in these directories is found to be owned by a user other than root, correct its ownership with the following command: # chown root FILE AC-6 1499 Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership is necessary to protect the integrity of the system. Shared libraries are stored in the following directories: /lib /lib64 /usr/lib /usr/lib64 For each of these directories, run the following command to find files not owned by root: $ find DIR \! -user root -type f System executables are stored in the following directories by default: /bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin All files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command: # chmod go-w FILE AC-6 1499 System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted. System executables are stored in the following directories by default: /bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin To find system executables that are group-writable or world-writable, run the following command for each directory DIR which contains system executables: $ find DIR -perm /022 System executables are stored in the following directories by default: /bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin All files in these directories should be owned by the root user. If any file FILE in these directories is found to be owned by a user other than root, correct its ownership with the following command: # chown root FILE AC-6 1499 System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted. System executables are stored in the following directories by default: /bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin To find system executables that are not owned by root, run the following command for each directory DIR which contains system executables: $ find DIR \! -user root 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: # chmod +t DIR AC-6 swells 20120929 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. CCE-26840-9 To find world-writable directories that lack the sticky bit, run the following command: # find / -xdev -type d -perm 002 ! -perm 1000 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. AC-6 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. CCE-26910-0 To find world-writable files, run the following command: # find / -xdev -type f -perm -002 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. CCE-26769-0 To find world-writable files, run the following command: # find / -xdev -type f -perm -002 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. CCE-26497-8 To find world-writable files, run the following command: # find / -xdev -type f -perm -002 If any files are not owned by a user, then the cause of their lack of ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate user. AC-6 224 Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed. CCE-27032-2 The following command will discover and print any files on local partitions which do not belong to a valid user. Run it once for each local partition PART: # find PART -xdev -nouser -print If any files are not owned by a group, then the cause of their lack of group-ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate group. AC-6 224 Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed. CCE-26872-2 The following command will discover and print any files on local partitions which do not belong to a valid group. Run it once for each local partition PART: # find PART -xdev -nogroup -print All directories in local partitions which are world-writable should be owned by root or another system account. If any world-writable directories are not owned by a system account, this should be investigated. Following this, the files should be deleted or assigned to an appropriate group. AC-6 swells 20120929 Allowing a user account to own a world-writable directory is undesirable because it allows the owner of that directory to remove or replace any files that may be placed in the directory by other users. CCE-26642-9 The following command will discover and print world-writable directories that are not owned by a system account, given the assumption that only system accounts have a uid lower than 500. Run it once for each local partition PART: # find PART -xdev -type d -perm 0002 -uid +500 -print The 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. The 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. Enter umask for daemons 022 022 027 The file /etc/init.d/functions includes initialization parameters for most or all daemons started at boot time. The default umask of 022 prevents creation of group- or world-writable files. To set the default umask for daemons, edit the following line, inserting 022 or 027 for UMASK appropriately: umask UMASK Setting 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. AC-6 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. CCE-27031-4 To check the value of the umask, run the following command: $ grep umask /etc/init.d/functions The output should show either 022 or 027. A 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. Once a hard limit is set in /etc/security/limits.conf, a user cannot increase that limit within his or her own session. If access to core dumps is required, consider restricting them to only certain users or groups. See the limits.conf man page for more information. The core dumps of setuid programs are further protected. The sysctl variable fs.suid_dumpable controls whether the kernel allows core dumps from these programs at all. The default value of 0 is recommended. To disable core dumps for all users, add the following line to /etc/security/limits.conf: * hard core 0 SC-5 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. CCE-27033-0 To verify that core dumps are disabled for all users, run the following command: $ grep core /etc/security/limits.conf The output should be: * hard core 0 To set the runtime status of the fs.suid_dumpable kernel parameter, run the following command: # sysctl -w fs.suid_dumpable=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: fs.suid_dumpable = 0 SI-11 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. CCE-27044-7 The status of the fs.suid_dumpable kernel parameter can be queried by running the following command: $ sysctl fs.suid_dumpable The output of the command should indicate a value of 0. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. ExecShield 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 and controlled through sysctl variables kernel.exec-shield and kernel.randomize_va_space. To set the runtime status of the kernel.exec-shield kernel parameter, run the following command: # sysctl -w kernel.exec-shield=1 If this is not the system's default value, add the following line to /etc/sysctl.conf: kernel.exec-shield = 1 DS 20121024 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. CCE-27007-4 The status of the kernel.exec-shield kernel parameter can be queried by running the following command: $ sysctl kernel.exec-shield The output of the command should indicate a value of 1. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. To set the runtime status of the kernel.randomize_va_space kernel parameter, run the following command: # sysctl -w kernel.randomize_va_space=2 If this is not the system's default value, add the following line to /etc/sysctl.conf: kernel.randomize_va_space = 2 DS 20121024 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. CCE-26999-3 The status of the kernel.randomize_va_space kernel parameter can be queried by running the following command: $ sysctl kernel.randomize_va_space The output of the command should indicate a value of 2. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. Recent processors in the x86 family support the ability to prevent code execution on a per memory page basis. Generically and on AMD processors, this ability is called No Execute (NX), while on Intel processors it is called Execute Disable (XD). This ability can help prevent exploitation of buffer overflow vulnerabilities and should be activated whenever possible. Extra steps must be taken to ensure that this protection is enabled, particularly on 32-bit x86 systems. Other processors, such as Itanium and POWER, have included such support since inception and the standard kernel for those platforms supports the feature. Systems that are using the 64-bit x86 kernel package do not need to install the kernel-PAE package because the 64-bit x86 kernel already includes this support. However, if the system is 32-bit and also supports the PAE and NX features as determined in the previous section, the kernel-PAE package should be installed to enable XD or NX support: # yum install kernel-PAE The installation process should also have configured the bootloader to load the new kernel at boot. Verify this at reboot and modify /etc/grub.conf if necessary. The kernel-PAE package should not be installed on older systems that do not support the XD or NX bit, as this may prevent them from booting. On 32-bit systems that support the XD or NX bit, the vendor-supplied PAE kernel is required to enable either Execute Disable (XD) or No Execute (NX) support. CCE-27010-8 Reboot the system and enter the BIOS or Setup configuration menu. Navigate the BIOS configuration menu and make sure that the option is enabled. The setting may be located under a Security section. Look for Execute Disable (XD) on Intel-based systems and No Execute (NX) on AMD-based systems. Computers with the ability to prevent this type of code execution frequently put an option in the BIOS that will allow users to turn the feature on or off at will. SELinux 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. The default SELinux policy, as configured on RHEL 6, has been sufficiently developed and debugged that it should be usable on almost any Red Hat machine with minimal configuration and a small amount of system administrator training. This policy prevents system services - including most of the common network-visible services such as mail servers, FTP servers, and DNS servers - from accessing files which those services have no valid reason to access. This action alone prevents a huge amount of possible damage from network attacks against services, from trojaned software, and so forth. This guide recommends that SELinux be enabled using the default (targeted) policy on every Red Hat system, unless that system has requirements which make a stronger policy appropriate. Edit the file /etc/selinux/config. Add or correct the following lines: SELINUX=enforcing SELINUXTYPE=targeted Edit the file /etc/grub.conf. Ensure that the following arguments DO NOT appear on any kernel command line in the file: selinux=0 enforcing=0 The directive SELINUX=enforcing enables SELinux at boot time. If SELinux is suspected of involvement with boot-time problems (unlikely), it is possible to boot into the warning-only mode SELINUX=permissive for debugging purposes. Make certain to change the mode back to enforcing after debugging, set the filesystems to be relabeled for consistency using the command touch /.autorelabel, and reboot. However, the RHEL 6 default SELinux configuration should be sufficiently reasonable that most systems will boot without serious problems. Some applications that require deep or unusual system privileges, such as virtual machine software, may not be compatible with SELinux in its default configuration. However, this should be uncommon, and SELinux's application support continues to improve. In other cases, SELinux may reveal unusual or insecure program behavior by design. The directive SELINUXTYPE=targeted configures SELinux to use the default targeted policy. The SELinux boot mode specified in /etc/selinux/config can be overridden by command-line arguments passed to the kernel. It is necessary to check grub.conf to ensure that this has not been done and to protect the boot process. enforcing - SELinux security policy is enforced. permissive - SELinux prints warnings instead of enforcing. disabled - SELinux is fully disabled. enforcing enforcing permissive disabled Type of policy in use. Possible values are: targeted - Only targeted network daemons are protected. strict - Full SELinux protection. mls - Multiple levels of security targeted targeted mls SELinux can be disabled at boot time by an argument in /etc/grub.conf. Remove any instances of selinux=0 from the kernel arguments in that file to prevent SELinux from being disabled at boot. AC-3 AC-3(3) AC-6 AU-9 22 32 DS 20121024 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. CCE-26956-3 Inspect /etc/grub.conf for any instances of selinux=0 in the kernel boot arguments. Presence of selinux=0 indicates that SELinux is disabled at boot time. The SELinux state should be set to enforcing at system boot time. In the file /etc/selinux/config, add or correct the following line to configure the system to boot into enforcing mode: SELINUX=enforcing AC-3 AC-3(3) AC-4 AC-6 AU-9 22 32 26 DS 20121024 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. CCE-26969-6 Check the file /etc/selinux/config and ensure the following line appears: SELINUX=enforcing The SELinux targeted policy is appropriate for general-purpose desktops and servers, as well as systems in many other roles. To configure the system to use this policy, add or correct the following line in /etc/selinux/config: SELINUXTYPE=targeted Other policies, such as mls, provide additional security labeling and greater confinement but are not compatible with many general-purpose use cases. AC-3 AC-3(3) AC-4 AC-6 AU-9 22 32 DS 20121024 Setting the SELinux policy to targeted or a more specialized policy ensures the system will confine processes that are likely to be targeted for exploitation, such as network or system services. CCE-26875-5 Check the file /etc/selinux/config and ensure the following line appears: SELINUXTYPE=targeted The restorecond service utilizes inotify to look for the creation of new files listed in the /etc/selinux/restorecond.conf configuration file. When a file is created, restorecond ensures the file receives the proper SELinux security context. The restorecond service can be enabled with the following command: # chkconfig --level 2345 restorecond on AC-3 AC-3(3) AC-4 AC-6 AU-9 The restorecond service helps ensure that the default SELinux file context is applied to files. This allows automatic correction of file contexts created by some programs. CCE-26991-0 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: # 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. AC-6 AU-9 CM-7 Daemons which run with the initrc_t context may cause AVC denials, or allow privileges that the daemon does not require. Device files, which are used for communication with important system resources, should be labeled with proper SELinux types. If any device files carry the SELinux type unlabeled_t, investigate the cause and correct the file's context. AC-6 AU-9 CM-7 22 32 DS 20121024 If a device file carries the SELinux type unlabeled_t, then SELinux cannot properly restrict access to the device file. CCE-26774-0 To check for unlabeled device files, run the following command: # ls -RZ /dev | grep unlabeled_t It should produce no output in a well-configured system. In traditional Unix security, if an attacker gains shell access to a certain login account, they can perform any action or access any file to which that account has access. Therefore, making it more difficult for unauthorized people to gain shell access to accounts, particularly to privileged accounts, is a necessary part of securing a system. This section introduces mechanisms for restricting access to accounts under RHEL 6. Conventionally, Unix shell accounts are accessed by providing a username and password to a login program, which tests these values for correctness using the /etc/passwd and /etc/shadow files. Password-based login is vulnerable to guessing of weak passwords, and to sniffing and man-in-the-middle attacks against passwords entered over a network or at an insecure console. Therefore, mechanisms for accessing accounts by entering usernames and passwords should be restricted to those which are operationally necessary. 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 su or sudo to execute privileged commands. Discouraging administrators from accessing the root account directly ensures an audit trail in organizations with multiple administrators. Locking down the channels through which root can connect directly also reduces opportunities for password-guessing against the root account. The login program uses the file /etc/securetty to determine which interfaces should allow root logins. The virtual devices /dev/console and /dev/tty* represent the system consoles (accessible via the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default installation). The default securetty file also contains /dev/vc/*. These are likely to be deprecated in most environments, but may be retained for compatibility. Root should also be prohibited from connecting via network protocols. Other sections of this document include guidance describing how to prevent root from logging in via SSH. To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/secuetty 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 thesyste, whether via the console or a raw network interface. This is dangerous as as user can login to his machine as root via Telnet, which sends the passowrd 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 machine. 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: echo > /etc/securetty IA-2(1) DS 20121024 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. To ensure root may not directly login to the system over physical consoles, run the following command: cat /etc/securetty If any output is returned, this is a finding. To restrict root logins through the (deprecated) virtual console devices, ensure lines of this form do not appear in /etc/securetty: vc/1 vc/2 vc/3 vc/4 AC-6(2) 770 DS 20121024 Preventing direct root login to virtual console devices helps ensure accountability for actions taken on the system using the root account. CCE-26855-7 To check for virtual console entries which permit root login, run the following command: # grep ^vc/[0-9] /etc/securetty If any output is returned, then root logins over virtual console devices is permitted. To restrict root logins on serial ports, ensure lines of this form do not appear in /etc/securetty: ttyS0 ttyS1 AC-6(2) 770 DS 20121024 Preventing direct root login to serial port interfaces helps ensure accountability for actions taken on the systems using the root account. CCE-27047-0 To check for serial port entries which permit root login, run the following command: # grep ^ttyS/[0-9] /etc/securetty If any output is returned, then root login over serial ports is permitted. Enforce policy requiring administrative accounts use web browsers only for local service administration. If a browser vulnerability is exploited while running with administrative privileges, the entire system could be compromised. Specific exceptions for local service administration should be documented in site-defined policy. Check the root home directory for a .mozilla directory. If one exists, ensure browsing is limited to local service administration. 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 500. 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: # usermod -s /sbin/nologin SYSACCT Do not perform the steps in this section on the root account. Doing so might cause the system to become inaccessible. 178 DS 20121024 Ensuring shells are not given to system accounts upon login makes it more difficult for attackers to make use of system accounts. CCE-26966-2 To obtain a listing of all users, their UIDs, and their shells, run the command: $ awk -F: '{print $1 ":" $3 ":" $7}' /etc/passwd Identify the system accounts from this listing. These will primarily be the accounts with UID numbers less than 500, other than root. If any account other than root has a UID of 0, this misconfiguration should be investigated and the accounts other than root should be removed or have their UID changed. AC-6 IA-2(1) 366 DS 20121024 An account has root authority if it has a UID of 0. Multiple accounts with a UID of 0 afford more opportunity for potential intruders to guess a password for a privileged account. Proper configuration of sudo is recommended to afford multiple system administrators access to root privileges in an accountable manner. CCE-26971-2 To list all password file entries for accounts with UID 0, run the following command: # awk -F: '($3 == "0") {print}' /etc/passwd This should print only one line, for the user root. Assuming root shell is bash, edit the following files: ~/.profile ~/.bashrc Change any PATH variables to the vendor default for root and remove any empty PATH entries or references to relative paths. DS 20121024 The root account's executable search path must be the vendor default, and must contain only absolute paths. To view the root user's PATH, run the following command: # env | grep PATH If correctly configured, the PATH must: use vendor default settings, have no empty entries, and have no entries beginning with a character other than a slash (/). By default, password hashes for local accounts are stored in the second field (colon-separated) in /etc/shadow. This file should be readable only by processes running with root credentials, preventing users from casually accessing others' password hashes and attempting to crack them. However, it remains possible to misconfigure the system and store password hashes in world-readable files such as /etc/passwd, or to even store passwords themselves in plaintext on the system. Using system-provided tools for password change/creation should allow administrators to avoid such misconfiguration. If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. Remove any instances of the nullok option in /etc/pam.d/system-auth to prevent logins with empty passwords. IA-5(b) IA-5(c) IA-5(1)(a) DS 20121024 If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments. CCE-27038-9 To verify that null passwords cannot be used, run the following command: # grep nullok /etc/pam.d/system-auth If this produces any output, it may be possible to log into accounts with empty passwords. If any password hashes are stored in /etc/passwd (in the second field, instead of an x), the cause of this misconfiguration should be investigated. The account should have its password reset and the hash should be properly stored, or the account should be deleted entirely. IA-5(h) 201 DS 20121024 The hashes for all user account passwords should be stored in the file /etc/shadow and never in /etc/passwd, which is readable by all users. CCE-26476-2 To check that no password hashes are stored in /etc/passwd, run the following command: # awk -F: '($2 != "x") {print}' /etc/passwd If it produces any output, then a password hash is stored in /etc/passwd. Add a group to the system for each GID referenced without a corresponding group. 366 DS 20121024 Inconsistency in GIDs between /etc/passwd and /etc/group could lead to a user having unintended rights. To ensure all GIDs referenced in /etc/passwd are defined in /etc/group, run the following command: # pwck -qr There should be no output. The .netrc files contain login information used to auto-login into FTP servers and reside in the user's home directory. These files may contain unencrypted passwords to remote FTP servers making them susceptible to access by unauthorized users and should not be used. Any .netrc files should be removed. IA-5(h) 196 Unencrypted passwords for remote FTP servers may be stored in .netrc files. DoD policy requires passwords be encrypted in storage and not used in access scripts. CCE-27225-2 To check the system for the existence of any .netrc files, run the following command: # find /home -xdev -name .netrc The file /etc/login.defs controls several password-related settings. Programs such as passwd, su, and login consult /etc/login.defs to determine behavior with regard to password aging, expiration warnings, and length. See the man page login.defs(5) for more information. Users should be forced to change their passwords, in order to decrease the utility of compromised passwords. However, the need to change passwords often should be balanced against the risk that users will reuse or write down passwords if forced to change them too often. Forcing password changes every 90-360 days, depending on the environment, is recommended. Set the appropriate value as PASS_MAX_DAYS and apply it to existing accounts with the -M flag. The PASS_MIN_DAYS (-m) setting prevents password changes for 7 days after the first change, to discourage password cycling. If you use this setting, train users to contact an administrator for an emergency password change in case a new password becomes compromised. The PASS_WARN_AGE (-W) setting gives users 7 days of warnings at login time that their passwords are about to expire. For example, for each existing human user USER, expiration parameters could be adjusted to a 180 day maximum password age, 7 day minimum password age, and 7 day warning period with the following command: # chage -M 180 -m 7 -W 7 USER Minimum number of characters in password This will only check new passwords 14 6 8 10 12 14 Maximum age of password in days This will only apply to newly created accounts 60 60 90 120 180 Minimum age of password in days This will only apply to newly created accounts 7 7 5 1 2 0 The number of days' warning given before a password expires. This will only apply to newly created accounts 7 0 7 14 To specify password length requirements for new accounts, edit the file /etc/login.defs and add or correct the following lines: PASS_MIN_LEN 14 The DoD requirement is 14. The FISMA requirement is 12. If a program consults /etc/login.defs and also another PAM module (such as pam_cracklib) during a password change operation, then the most restrictive must be satisfied. See PAM section for more information about enforcing password quality requirements. IA-5(f) IA-5(1)(a) 205 DS 20121026 Requiring a minimum password length makes password cracking attacks more difficult by ensuring a larger search space. However, any security benefit from an onerous requirement must be carefully weighed against usability problems, support costs, or counterproductive behavior that may result. CCE-27002-5 To check the minimum password length, run the command: $ grep PASS_MIN_LEN /etc/login.defs The DoD requirement is 14. To specify password minimum age for new accounts, edit the file /etc/login.defs and add or correct the following line, replacing DAYS appropriately: PASS_MIN_DAYS DAYS A value of 1 day is considered for sufficient for many environments. The DoD requirement is 1. IA-5(f) IA-5(1)(d) 198 DS 20121026 Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement. CCE-27013-2 To check the minimum password age, run the command: $ grep PASS_MIN_DAYS /etc/login.defs The DoD and FISMA requirement is 1. To specify password maximum age for new accounts, edit the file /etc/login.defs and add or correct the following line, replacing DAYS appropriately: PASS_MAX_DAYS DAYS A value of 180 days is sufficient for many environments. The DoD requirement is 60. IA-5(f) IA-5(g) IA-5(1)(d) 180 199 DS 20121026 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. CCE-26985-2 To check the maximum password age, run the command: $ grep PASS_MAX_DAYS /etc/login.defs The DoD and FISMA requirement is 60. A value of 180 days is sufficient for many environments. To specify how many days prior to password expiration that a warning will be issued to users, edit the file /etc/login.defs and add or correct the following line, replacing DAYS appropriately: PASS_WARN_AGE DAYS The DoD requirement is 7. IA-5(f) DS 20121026 Setting the password warning age enables users to make the change at a practical time. CCE-26988-6 To check the password warning age, run the command: $ grep PASS_WARN_AGE /etc/login.defs The DoD requirement is 7. Accounts can be configured to be automatically disabled after a certain time period, meaning that they will require administrator interaction to become usable again. Expiration of accounts after inactivity can be set for all accounts by default and also on a per-account basis, such as for accounts that are known to be temporary. To configure automatic expiration of an account following the expiration of its password (that is, after the password has expired and not been changed), run the following command, substituting NUM_DAYS and USER appropriately: # chage -I NUM_DAYS USER Accounts, such as temporary accounts, can also be configured to expire on an explicitly-set date with the -E option. The file /etc/default/useradd controls default settings for all newly-created accounts created with the system's normal command line utilities. The number of days to wait after a password expires, until the account will be permanently disabled. This will only apply to newly created accounts 35 30 35 60 90 180 To specify the number of days after a password expires (which signifies inactivity) until an account is permanently disabled, add or correct the following lines in /etc/default/useradd, substituting NUM_DAYS appropriately: INACTIVE=NUM_DAYS A value of 35 is recommended. If a password is currently on the verge of expiration, then 35 days remain until the account is automatically disabled. However, if the password will not expire for another 60 days, then 95 days could elapse until the account would be automatically disabled. See the useradd man page for more information. Determining the inactivity timeout must be done with careful consideration of the length of a "normal" period of inactivity for users in the particular environment. Setting the timeout too low incurs support costs and also has the potential to impact availability of the system to legitimate users. AC-2(2) AC-2(3) 16 17 795 Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials. CCE-27283-1 To verify the INACTIVE setting, run the following command: grep "INACTIVE" /etc/default/useradd The output should indicate the INACTIVE configuration option is set to an appropriate integer as shown in the example below: # grep "INACTIVE" /etc/default/useradd INACTIVE=35 Change usernames, or delete accounts, so each has a unique name. 770 804 Unique usernames allow for accountability on the system. CCE-27609-7 Run the following command to check for duplicate account names: # pwck -qr If there are no duplicate names, no line will be returned. In the event temporary or emergency accounts are required, configure the system to terminate them after a documented time period. For every temporary and emergency account, run the following command to set an expiration date on it, substituting USER and YYYY-MM-DD appropriately: # chage -E YYYY-MM-DD USER YYYY-MM-DD indicates the documented expiration date for the account. AC-2(2) AC-2(3) 16 1682 When temporary and emergency accounts are created, there is a risk they may remain in place and active after the need for them no longer exists. Account expiration greatly reduces the risk of accounts being misused or hijacked. For every temporary and emergency account, run the following command to obtain its account aging and expiration information: # chage -l USER Verify each of these accounts has an expiration date set as documented. PAM, 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. PAM is implemented as a set of shared objects which are loaded and invoked whenever an application wishes to authenticate a user. Typically, the application must be running as root in order to take advantage of PAM, because PAM's modules often need to be able to access sensitive stores of account information, such as /etc/shadow. Traditional privileged network listeners (e.g. sshd) or SUID programs (e.g. sudo) already meet this requirement. An SUID root application, userhelper, is provided so that programs which are not SUID or privileged themselves can still take advantage of PAM. PAM looks in the directory /etc/pam.d for application-specific configuration information. For instance, if the program login attempts to authenticate a user, then PAM's libraries follow the instructions in the file /etc/pam.d/login to determine what actions should be taken. One very important file in /etc/pam.d is /etc/pam.d/system-auth. This file, which is included by many other PAM configuration files, defines 'default' system authentication measures. Modifying this file is a good way to make far-reaching authentication changes, for instance when implementing a centralized authentication service. 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. 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. The last n passwords for each user are saved in /etc/security/opasswd in order to force password change history and keep the user from alternating between the same password too frequently. 24 0 5 10 24 To configure the system to notify users of last logon/access using pam_lastlog, add the following line immediately after session required pam_limits.so: session required pam_lastlog.so showfailed 53 Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of unsuccessful attempts that were made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators. CCE-27291-4 To ensure that last logon/access notification is configured correctly, run the following command: # grep pam_lastlog.so /etc/pam.d/system-auth The output should show output showfailed. The default pam_cracklib PAM module provides strength checking for passwords. It performs a number of checks, such as making sure passwords are not similar to dictionary words, are of at least a certain length, are not the previous password reversed, and are not simply a change of case from the previous password. It can also require passwords to be in certain character classes. The pam_passwdqc PAM module also provides the ability to enforce stringent password strength requirements. It is provided in an RPM of the same name. The man pages pam_cracklib(8) and pam_passwdqc(8) provide information on the capabilities and configuration of each. The pam_cracklib PAM module can be configured to meet requirements for a variety of policies. For example, to configure pam_cracklib to require at least one uppercase character, lowercase character, digit, and other (special) character, locate the following line in /etc/pam.d/system-auth: password requisite pam_cracklib.so try_first_pass retry=3 and then alter it to read: password required pam_cracklib.so try_first_pass retry=3 maxrepeat=3 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 difok=4 If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth. The arguments can be modified to ensure compliance with your organization's security policy. Discussion of each parameter follows. Note that the password quality requirements are not enforced for the root account for some reason. Number of retry attempts before erroring out 3 1 2 3 Minimum number of characters in password 14 6 8 10 12 14 15 Minimum number of digits in password -1 -2 -1 0 Minimum number of other (special characters) in password -1 -2 -1 0 Minimum number of lower case in password -1 -2 -1 0 Minimum number of upper case in password -1 -2 -1 0 Minimum number of characters not present in old password Keep this high for short passwords 4 2 3 4 5 Number of failed login attempts before account lockout 3 3 5 10 Seconds before automatic unlocking after excessive failed logins 604800 900 1800 3600 86400 604800 Interval for counting failed login attempts before account lockout 900 900 1800 3600 86400 100000000 To configure the number of retry prompts that are permitted per-session: Edit the pam_cracklib.so statement in /etc/pam.d/system-auth to show retry=3, or a lower value if site policy is more restrictive. The DoD requirement is a maximum of 3 prompts per session. IA-5(c) 1092 DS 20121024 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. CCE-27123-9 To check how many retry attempts are permitted on a per-session basis, run the following command: $ grep pam_cracklib /etc/pam.d/system-auth The retry parameter will indicate how many attempts are permitted. The DoD required value is less than or equal to 3. This would appear as retry=3, or a lower value. The pam_cracklib module's maxrepeat parameter controls requirements for consecutive repeating characters. When set to a positive number, it will reject passwords which contain more than that number of consecutive characters. Add maxrepeat=3 after pam_cracklib.so to prevent a run of four or more identical characters. IA-5(c) 366 Passwords with excessive repeating characters may be more vulnerable to password-guessing attacks. CCE-27227-8 To check the maximum value for consecutive repeating characters, run the following command: $ grep pam_cracklib /etc/pam.d/system-auth Look for the value of the maxrepeat parameter. The DoD requirement is 3. The pam_cracklib module's dcredit parameter controls requirements for usage of digits in a password. When set to a negative number, any password will be required to contain that many digits. When set to a positive number, pam_cracklib will grant +1 additional length credit for each digit. Add dcredit=-1 after pam_cracklib.so to require use of a digit in passwords. IA-5(b) IA-5(c) 194 194 DS 20121024 Requiring digits makes password guessing attacks more difficult by ensuring a larger search space. CCE-26374-9 To check how many digits are required in a password, run the following command: $ grep pam_cracklib /etc/pam.d/system-auth The dcredit parameter (as a negative number) will indicate how many digits are required. The DoD requires at least one digit in a password. This would appear as dcredit=-1. The pam_cracklib module's ucredit= parameter controls requirements for usage of uppercase letters in a password. When set to a negative number, any password will be required to contain that many uppercase characters. When set to a positive number, pam_cracklib will grant +1 additional length credit for each uppercase character. Add ucredit=-1 after pam_cracklib.so to require use of an upper case character in passwords. IA-5(b) IA-5(c) IA-5(1)(a) 192 DS 20121024 Requiring a minimum number of uppercase characters makes password guessing attacks more difficult by ensuring a larger search space. CCE-26601-5 To check how many uppercase characters are required in a password, run the following command: $ grep pam_cracklib /etc/pam.d/system-auth The ucredit parameter (as a negative number) will indicate how many uppercase characters are required. The DoD and FISMA require at least one uppercase character in a password. This would appear as ucredit=-1. The pam_cracklib module's ocredit= parameter controls requirements for usage of special (or ``other'') characters in a password. When set to a negative number, any password will be required to contain that many special characters. When set to a positive number, pam_cracklib will grant +1 additional length credit for each special character. Add ocredit=-1 after pam_cracklib.so to require use of a special character in passwords. IA-5(b) IA-5(c) IA-5(1)(a) 1619 DS 20121024 Requiring a minimum number of special characters makes password guessing attacks more difficult by ensuring a larger search space. CCE-26409-3 To check how many special characters are required in a password, run the following command: $ grep pam_cracklib /etc/pam.d/system-auth The ocredit parameter (as a negative number) will indicate how many special characters are required. The DoD and FISMA require at least one special character in a password. This would appear as ocredit=-1. The pam_cracklib module's lcredit= parameter controls requirements for usage of lowercase letters in a password. When set to a negative number, any password will be required to contain that many lowercase characters. When set to a positive number, pam_cracklib will grant +1 additional length credit for each lowercase character. Add lcredit=-1 after pam_cracklib.so to require use of a lowercase character in passwords. IA-5(b) IA-5(c) IA-5(1)(a) 193 DS 20121024 Requiring a minimum number of lowercase characters makes password guessing attacks more difficult by ensuring a larger search space. CCE-26631-2 To check how many lowercase characters are required in a password, run the following command: $ grep pam_cracklib /etc/pam.d/system-auth The lcredit parameter (as a negative number) will indicate how many special characters are required. The DoD and FISMA require at least one lowercase character in a password. This would appear as lcredit=-1. The pam_cracklib module's difok parameter controls requirements for usage of different characters during a password change. Add difok=NUM after pam_cracklib.so to require differing characters when changing passwords, substituting NUM appropriately. The DoD requirement is 4. IA-5(b) IA-5(c) IA-5(1)(b) 195 DS 20121024 Requiring a minimum number of different characters during password changes ensures that newly changed passwords should not resemble previously compromised ones. Note that passwords which are changed on compromised systems will still be compromised, however. CCE-26615-5 To check how many characters must differ during a password change, run the following command: $ grep pam_cracklib /etc/pam.d/system-auth The difok parameter will indicate how many characters must differ. The DoD requires four characters differ during a password change. This would appear as difok=4. The pam_faillock PAM module provides the capability to lock out user accounts after a number of failed login attempts. Its documentation is available in /usr/share/doc/pam-VERSION/txts/README.pam_faillock. 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. To configure the system to lock out accounts after a number of incorrect login attempts using pam_faillock.so: Add the following lines immediately below the pam_unix.so statement in AUTH section of /etc/pam.d/system-auth: auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 fail_interval=900 auth required pam_faillock.so authsucc deny=3 unlock_time=604800 fail_interval=900 AC-7(a) 44 Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks. CCE-26844-1 To ensure the failed password attempt policy is configured correctly, run the following command: # grep pam_faillock /etc/pam.d/system-auth The output should show deny=3. To configure the system to lock out accounts after a number of incorrect login attempts and require an administrator to unlock the account using pam_faillock.so: Add the following lines immediately below the pam_env.so statement in /etc/pam.d/system-auth: auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 fail_interval=900 auth required pam_faillock.so authsucc deny=3 unlock_time=604800 fail_interval=900 AC-7(b) 47 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. CCE-27110-6 To ensure the failed password attempt policy is configured correctly, run the following command: # grep pam_faillock /etc/pam.d/system-auth The output should show unlock_time=<some-large-number>. To configure the system to lock out accounts after a number of incorrect login attempts within a 15 minute interval using pam_faillock.so: Add the following lines immediately below the pam_env.so statement in /etc/pam.d/system-auth: auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 fail_interval=900 auth required pam_faillock.so authsucc deny=3 unlock_time=604800 fail_interval=900 AC-7(a) 1452 Locking out user accounts after a number of incorrect attempts within a specific period of time prevents direct password guessing attacks. CCE-27215-3 To ensure the failed password attempt policy is configured correctly, run the following command: # grep pam_faillock /etc/pam.d/system-auth The output should show fail_interval=<interval-in-seconds> where interval-in-seconds is 900 (15 minutes) or greater. If the fail_interval parameter is not set, the default setting of 900 seconds is acceptable. Do not allow users to reuse recent passwords. This can be accomplished by using the remember option for the pam_unix PAM module. In the file /etc/pam.d/system-auth, append remember=24 to the line which refers to the pam_unix.so module, as shown: password sufficient pam_unix.so existing_options remember=24 The DoD and FISMA requirement is 24 passwords. IA-5(f) IA-5(1)(e) 200 DS 20121024 Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user. CCE-26741-9 To verify the password reuse setting is compliant, run the following command: $ grep remember /etc/pam.d/system-auth The output should show the following at the end of the line: remember=24 The system's default algorithm for storing password hashes in /etc/shadow is SHA-512. This can be configured in several locations. In /etc/pam.d/system-auth, the password section of the file controls which PAM modules execute during a password change. Set the pam_unix.so module in the password section to include the argument sha512, as shown below: 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. IA-5(b) IA-5(c) IA-5(1)(c) IA-7 803 DS 20121024 Using a stronger hashing algorithm makes password cracking attacks more difficult. CCE-26303-8 Inspect the password section of /etc/pam.d/system-auth and ensure that the pam_unix.so module includes the argument sha512: $ grep sha512 /etc/pam.d/system-auth In /etc/login.defs, add or correct the following line to ensure the system will use SHA-512 as the hashing algorithm: ENCRYPT_METHOD SHA512 IA-5(b) IA-5(c) IA-5(1)(c) IA-7 803 DS 20121024 Using a stronger hashing algorithm makes password cracking attacks more difficult. CCE-27228-6 Inspect /etc/login.defs and ensure the following line appears: ENCRYPT_METHOD SHA512 In /etc/libuser.conf, add or correct the following line in its [defaults] section to ensure the system will use the SHA-512 algorithm for password hashing: crypt_style = sha512 IA-5(b) IA-5(c) IA-5(1)(c) IA-7 803 DS 20121026 Using a stronger hashing algorithm makes password cracking attacks more difficult. CCE-27229-4 Inspect /etc/libuser.conf and ensure the following line appears in the [default] section: crypt_style = sha512 When a user logs into a Unix account, the system configures the user's session by reading a number of files. Many of these files are located in the user's home directory, and may have weak permissions as a result of user error or misconfiguration. If an attacker can modify or even read certain types of account configuration information, they can often gain full access to the affected user's account. Therefore, it is important to test and correct configuration file permissions for interactive accounts, particularly those of privileged users such as root or system administrators. Maximum number of concurrent sessions by a user 1 1 5 10 15 20 Limiting the number of allowed users and sessions per user can limit risks related to Denial of Service attacks. This addresses concurrent sessions for a single account and does not address concurrent sessions by a single user via multiple accounts. The DoD requirement is 10. To set the number of concurrent sessions per user add the following line in /etc/security/limits.conf: * hard maxlogins 10 AC-10 54 Limiting simultaneous user logins can insulate the system from denial of service problems caused by excessive logins. Automated login processes operating improperly or maliciously may result in an exceptional number of simultaneous login sessions. CCE-27457-1 Run the following command to ensure the maxlogins value is configured for all users on the system: # grep "maxlogins" /etc/security/limits.conf You should receive output similar to the following: * hard maxlogins 10 The active path of the root account can be obtained by starting a new root shell and running: # echo $PATH This will produce a colon-separated list of directories in the path. Certain path elements could be considered dangerous, as they could lead to root executing unknown or untrusted programs, which could contain malicious code. Since root may sometimes work inside untrusted directories, the . character, which represents the current directory, should never be in the root path, nor should any directory which can be written to by an unprivileged or semi-privileged (system) user. It is a good practice for administrators to always execute privileged commands by typing the full path to the command. Ensure that none of the directories in root's path is equal to a single . character, or that it contains any instances that lead to relative path traversal, such as .. or beginning a path without the slash (/) character. Also ensure that there are no "empty" elements in the path, such as in these examples: PATH=:/bin PATH=/bin: PATH=/bin::/sbin These empty elements have the same effect as a single . character. Including these entries increases the risk that root could execute code from an untrusted location. CCE-26826-8 For each element in root's path, run: # ls -ld DIR and ensure that write permissions are disabled for group and other. Such entries increase the risk that root could execute code provided by unprivileged users, and potentially malicious code. CCE-26768-2 To ensure write permissions are disabled for group and other for each element in root's path, run the following command: # ls -ld DIR For each human user of the system, view the permissions of the user's home directory: # ls -ld /home/USER Ensure that the directory is not group-writable and that it is not world-readable. If necessary, repair the permissions: # chmod g-w /home/USER # chmod o-rwx /home/USER This action may involve modifying user home directories. Notify your user community, and solicit input if appropriate, before making this type of change. User home directories contain many configuration files which affect the behavior of a user's account. No user should ever have write permission to another user's home directory. Group shared directories can be configured in sub-directories or elsewhere in the filesystem if they are needed. Typically, user home directories should not be world-readable, as it would disclose file names to other users. If a subset of users need read access to one another's home directories, this can be provided using groups or ACLs. CCE-26981-1 To ensure the user home directory is not group-writable or world-readable, run the following: # ls -ld /home/USER The umask setting controls the default permissions for the creation of new files. With a default umask setting of 077, files and directories created by users will not be readable by any other user on the system. Users who wish to make specific files group- or world-readable can accomplish this by using the chmod command. Additionally, users can make all their files readable to their group by default by setting a umask of 027 in their shell configuration files. If default per-user groups exist (that is, if every user has a default group whose name is the same as that user's username and whose only member is the user), then it may even be safe for users to select a umask of 007, making it very easy to intentionally share files with groups of which the user is a member. Enter default user umask 027 007 022 027 077 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 077 366 swells 20120929 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. CCE-26917-5 Verify the umask setting is configured correctly in the /etc/bashrc file by running the following command: # grep "umask" /etc/bashrc All output must show the value of umask set to 077, as shown below: # grep "umask" /etc/bashrc umask 077 umask 077 To ensure the default umask for users of the C shell is set properly, add or correct the umask setting in /etc/csh.cshrc to read as follows: umask 077 366 swells 20120929 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. CCE-27034-8 Verify the umask setting is configured correctly in the /etc/csh.cshrc file by running the following command: # grep "umask" /etc/csh.cshrc All output must show the value of umask set to 077, as shown in the below: # grep "umask" /etc/csh.cshrc umask 077 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 077 366 swells 20120929 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. CCE-26669-2 Verify the umask setting is configured correctly in the /etc/profile file by running the following command: # grep "umask" /etc/profile All output must show the value of umask set to 077, as shown in the below: # grep "umask" /etc/profile umask 077 To ensure the default umask controlled by /etc/login.defs is set properly, add or correct the UMASK setting in /etc/login.defs to read as follows: UMASK 077 366 swells 20120929 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 and written to by unauthorized users. CCE-26371-5 Verify the UMASK setting is configured correctly in the /etc/login.defs file by running the following command: # grep -i "UMASK" /etc/login.defs All output must show the value of umask set to 077, as shown in the below: # grep -i "UMASK" /etc/login.defs umask 077 It 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. During the boot process, the boot loader is responsible for starting the execution of the kernel and passing options to it. The boot loader allows for the selection of different kernels - possibly on different partitions or media. The default RHEL boot loader for x86 systems is called GRUB. Options it can pass to the kernel include single-user mode, which provides root access without any authentication, and the ability to disable SELinux. To prevent local users from modifying the boot parameters and endangering security, protect the boot loader configuration with a password and ensure its configuration file's permissions are set properly. The file /etc/grub.conf should be owned by the root user to prevent destruction or modification of the file. To properly set the owner of /etc/grub.conf, run the command: # chown root /etc/grub.conf 225 DS 20121026 Only root should be able to modify important boot parameters. CCE-26995-1 To check the ownership of /etc/grub.conf, run the command: $ ls -lL /etc/grub.conf If properly configured, the output should indicate the following owner: root The file /etc/grub.conf should be group-owned by the root group to prevent destruction or modification of the file. To properly set the group owner of /etc/grub.conf, run the command: # chgrp root /etc/grub.conf 225 DS 20121026 The root group is a highly-privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway. CCE-27022-3 To check the group ownership of /etc/grub.conf, run the command: $ ls -lL /etc/grub.conf If properly configured, the output should indicate the following group-owner. root File permissions for /boot/grub/grub.conf should be set to 600, which is the default. To properly set the permissions of /boot/grub/grub.conf, run the command: # chmod 600 /boot/grub/grub.conf 225 DS 20121026 Proper permissions ensure that only the root user can modify important boot parameters. CCE-26949-8 To check the permissions of /etc/grub.conf, run the command: # ls -lL /etc/grub.conf If properly configured, the output should indicate the following permissions: -rw------- The grub boot loader should have password protection enabled to protect boot-time settings. To do so, select a password and then generate a hash from it by running the following command: # grub-crypt --sha-512 When prompted to enter a password, insert the following line into /etc/grub.conf immediately after the header comments. (Use the output from grub-crypt as the value of password-hash): password --encrypted password-hash NOTE: To meet FISMA Moderate, the bootloader password MUST differ from the root password. IA-2(1) IA-5(e) 213 DS 20121026 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. CCE-26911-8 To verify the boot loader password has been set and encrypted, run the following command: # grep password /etc/grub.conf The output should show the following: password --encrypted password-hash 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. To require entry of the root password even if the system is started in single-user mode, add or correct the following line in the file /etc/sysconfig/init: SINGLE=/sbin/sulogin IA-2(1) 213 DS 20121024 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. CCE-27040-5 To check if authentication is required for single-user mode, run the following command: $ grep SINGLE /etc/sysconfig/init The output should be the following: SINGLE=/sbin/sulogin By default, the system includes the following line in /etc/init/control-alt-delete.conf to reboot the system when the Ctrl-Alt-Del key sequence is pressed: exec /sbin/shutdown -r now "Control-Alt-Delete pressed" To configure the system to log a message instead of rebooting the system, alter that line to read as follows: exec /usr/bin/logger -p security.info "Control-Alt-Delete pressed" A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. In the GNOME graphical environment, risk of unintentional reboot from the Ctrl-Alt-Del sequence is reduced because the user will be prompted before any action is taken. To ensure the system is configured to log a message instead of rebooting the system when Ctrl-Alt-Del is pressed, ensure the following line is in /etc/init/control-alt-delete.conf: exec /usr/bin/logger -p security.info "Control-Alt-Delete pressed" To disable the ability for users to perform interactive startups, edit the file /etc/sysconfig/init. Add or correct the line: PROMPT=no The PROMPT option allows the console user to perform an interactive system startup, in which it is possible to select the set of services which are started on boot. SC-2 213 DS 20121024 Using interactive boot, the console user could disable auditing, firewalls, or other services, weakening system security. CCE-27043-9 To check whether interactive boot is disabled, run the following command: $ grep PROMPT /etc/sysconfig/init If interactive boot is disabled, the output will show: PROMPT=no When a user must temporarily leave an account logged-in, screen locking should be employed to prevent passersby from abusing the account. User education and training is particularly important for screen locking to be effective, and policies can be implemented to reinforce this. Automatic screen locking is only meant as a safeguard for those cases where a user forgot to lock the screen. In the default GNOME desktop, the screen can be locked by choosing Lock Screen from the System menu. The gconftool-2 program can be used to enforce mandatory screen locking settings for the default GNOME environment. The following sections detail commands to enforce idle activation of the screen saver, screen locking, a blank-screen screensaver, and an idle activation time. Because users should be trained to lock the screen when they step away from the computer, the automatic locking feature is only meant as a backup. The Lock Screen icon from the System menu can also be dragged to the taskbar in order to facilitate even more convenient screen-locking. The root account cannot be screen-locked, but this should have no practical effect as the root account should never be used to log into an X Windows environment, and should only be used to for direct login via console in emergency circumstances. For more information about configuring GNOME screensaver, see http://live.gnome.org/GnomeScreensaver. For more information about enforcing preferences in the GNOME environment using the GConf configuration system, see http://projects.gnome.org/gconf and the man page gconftool-2(1). Choose allowed duration of inactive SSH connections, shells, and X sessions 15 5 10 15 Run the following command to set the idle time-out value for inactivity in the GNOME desktop to 15 minutes: # gconftool-2 \ --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type int \ --set /apps/gnome-screensaver/idle_delay 15 AC-11(a) 57 Setting the idle delay controls when the screensaver will start, and can be combined with screen locking to prevent access from passersby. CCE-26828-4 To check the current idle time-out value, run the following command: $ gconftool-2 -g /apps/gnome-screensaver/idle_delay If properly configured, the output should be 15. Run the following command to activate the screensaver in the GNOME desktop after a period of inactivity: # gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type bool \ --set /apps/gnome-screensaver/idle_activation_enabled true AC-11(a) 57 Enabling idle activation of the screen saver ensures the screensaver will be activated after the idle delay. Applications requiring continuous, real-time screen display (such as network management products) require the login session does not have administrator rights and the display station is located in a controlled-access area. CCE-26600-7 To check the screensaver mandatory use status, run the following command: $ gconftool-2 -g /apps/gnome-screensaver/idle_activation_enabled If properly configured, the output should be true. Run the following command to activate locking of the screensaver in the GNOME desktop when it is activated: # gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type bool \ --set /apps/gnome-screensaver/lock_enabled true AC-11(a) 57 Enabling the activation of the screen lock after an idle period ensures password entry will be required in order to access the system, preventing access by passersby. CCE-26235-2 To check the status of the idle screen lock activation, run the following command: $ gconftool-2 -g /apps/gnome-screensaver/lock_enabled If properly configured, the output should be true. Run the following command to set the screensaver mode in the GNOME desktop to a blank screen: # gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type string \ --set /apps/gnome-screensaver/mode blank-only AC-11(b) 60 Setting the screensaver mode to blank-only conceals the contents of the display from passersby. CCE-26638-7 To ensure the screensaver is configured to be blank, run the following command: $ gconftool-2 -g /apps/gnome-screensaver/mode If properly configured, the output should be blank-only A console screen locking mechanism is provided in the screen package, which is not installed by default. To enable console screen locking, install the screen package: # yum install screen Instruct users to begin new terminal sessions with the following command: $ screen The console can now be locked with the following key combination: ctrl+a x 58 DS 20121026 Installing screen ensures a console locking capability is available for users who may need to suspend console logins. CCE-26940-7 yum -y install screen Run the following command to determine if the screen package is installed: # rpm -q screen The use of hardware tokens such as smart cards for system login provides stronger, two-factor authentication than using a username/password. In Red Hat Enterprise Linux servers and workstations, hardware token login is not enabled by default and must be enabled in the system settings. To enable smart card authentication, consult the documentation at: https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html 765 766 767 768 771 772 884 Smart card login provides two-factor authentication stronger than that provided by a username/password combination. Smart cards leverage a PKI (public key infrastructure) in order to provide and verify credentials. Interview the SA to determine if all accounts not exempted by policy are using CAC authentication. For DoD systems, the following systems and accounts are exempt from using smart card (CAC) authentication: SIPRNET systemsStandalone systemsApplication accountsTemporary employee accounts, such as students or interns, who cannot easily receive a CAC or PIVOperational tactical locations that are not collocated with RAPIDS workstations to issue CAC or ALTTest systems, such as those with an Interim Approval to Test (IATT) and use a separate VPN, firewall, or security measure preventing access to network and system components from outside the protection boundary documented in the IATT. Each system should expose as little information about itself as possible. System banners, which are typically displayed just before a login prompt, give out information about the service or the host's operating system. This might include the distribution name and the system kernel version, and the particular version of a network service. This information can assist intruders in gaining access to the system as it can reveal whether the system is running vulnerable software. Most network services can be configured to limit what information is displayed. Many organizations implement security policies that require a system banner provide notice of the system's ownership, provide warning to unauthorized users, and remind authorized users of their consent to monitoring. Enter an appropriate login banner for your organization. Please note that new lines must be expressed by the '\n' character and special characters like parentheses and quotation marks must be escaped with '\'. -- WARNING --[\s\n]*This system is for the use of authorized users only. Individuals[\s\n]*using this computer system without authority or in excess of their[\s\n]*authority are subject to having all their activities on this system[\s\n]*monitored and recorded by system personnel. Anyone using this[\s\n]*system expressly consents to such monitoring and is advised that[\s\n]*if such monitoring reveals possible evidence of criminal activity[\s\n]*system personal may provide the evidence of such monitoring to law[\s\n]*enforcement officials. You[\s\n]+are[\s\n]+accessing[\s\n]+a[\s\n]+U.S.[\s\n]+Government[\s\n]+\(USG\)[\s\n]+Information[\s\n]+System[\s\n]+\(IS\)[\s\n]+that[\s\n]+is[\s\n]+provided[\s\n]+for[\s\n]+USG-authorized[\s\n]+use[\s\n]+only.[\s\n]*By[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+\(which[\s\n]+includes[\s\n]+any[\s\n]+device[\s\n]+attached[\s\n]+to[\s\n]+this[\s\n]+IS\),[\s\n]+you[\s\n]+consent[\s\n]+to[\s\n]+the[\s\n]+following[\s\n]+conditions\:[\s\n]*-[\s\n]*The[\s\n]+USG[\s\n]+routinely[\s\n]+intercepts[\s\n]+and[\s\n]+monitors[\s\n]+communications[\s\n]+on[\s\n]+this[\s\n]+IS[\s\n]+for[\s\n]+purposes[\s\n]+including,[\s\n]+but[\s\n]+not[\s\n]+limited[\s\n]+to,[\s\n]+penetration[\s\n]+testing,[\s\n]+COMSEC[\s\n]+monitoring,[\s\n]+network[\s\n]+operations[\s\n]+and[\s\n]+defense,[\s\n]+personnel[\s\n]+misconduct[\s\n]+\(PM\),[\s\n]+law[\s\n]+enforcement[\s\n]+\(LE\),[\s\n]+and[\s\n]+counterintelligence[\s\n]+\(CI\)[\s\n]+investigations.[\s\n]*-[\s\n]*At[\s\n]+any[\s\n]+time,[\s\n]+the[\s\n]+USG[\s\n]+may[\s\n]+inspect[\s\n]+and[\s\n]+seize[\s\n]+data[\s\n]+stored[\s\n]+on[\s\n]+this[\s\n]+IS.[\s\n]*-[\s\n]*Communications[\s\n]+using,[\s\n]+or[\s\n]+data[\s\n]+stored[\s\n]+on,[\s\n]+this[\s\n]+IS[\s\n]+are[\s\n]+not[\s\n]+private,[\s\n]+are[\s\n]+subject[\s\n]+to[\s\n]+routine[\s\n]+monitoring,[\s\n]+interception,[\s\n]+and[\s\n]+search,[\s\n]+and[\s\n]+may[\s\n]+be[\s\n]+disclosed[\s\n]+or[\s\n]+used[\s\n]+for[\s\n]+any[\s\n]+USG-authorized[\s\n]+purpose.[\s\n]*-[\s\n]*This[\s\n]+IS[\s\n]+includes[\s\n]+security[\s\n]+measures[\s\n]+\(e.g.,[\s\n]+authentication[\s\n]+and[\s\n]+access[\s\n]+controls\)[\s\n]+to[\s\n]+protect[\s\n]+USG[\s\n]+interests[\s\n]+--[\s\n]+not[\s\n]+for[\s\n]+your[\s\n]+personal[\s\n]+benefit[\s\n]+or[\s\n]+privacy.[\s\n]*-[\s\n]*Notwithstanding[\s\n]+the[\s\n]+above,[\s\n]+using[\s\n]+this[\s\n]+IS[\s\n]+does[\s\n]+not[\s\n]+constitute[\s\n]+consent[\s\n]+to[\s\n]+PM,[\s\n]+LE[\s\n]+or[\s\n]+CI[\s\n]+investigative[\s\n]+searching[\s\n]+or[\s\n]+monitoring[\s\n]+of[\s\n]+the[\s\n]+content[\s\n]+of[\s\n]+privileged[\s\n]+communications,[\s\n]+or[\s\n]+work[\s\n]+product,[\s\n]+related[\s\n]+to[\s\n]+personal[\s\n]+representation[\s\n]+or[\s\n]+services[\s\n]+by[\s\n]+attorneys,[\s\n]+psychotherapists,[\s\n]+or[\s\n]+clergy,[\s\n]+and[\s\n]+their[\s\n]+assistants.[\s\n]+Such[\s\n]+communications[\s\n]+and[\s\n]+work[\s\n]+product[\s\n]+are[\s\n]+private[\s\n]+and[\s\n]+confidential.[\s\n]+See[\s\n]+User[\s\n]+Agreement[\s\n]+for[\s\n]+details. I\'ve read \& consent to terms in IS user agreem\'t. To configure the system login banner: Edit /etc/issue. Replace the default text with a message compliant with the local site policy or a legal disclaimer. The DoD required text is either: You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests -- not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details. OR: I've read & consent to terms in IS user agreem't. AC-8(a) AC-8(b) AC-8(c) 48 1384 1385 1386 1387 1388 DS 20121026 An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. CCE-26974-6 login_banner_text="_{" cat <<EOF >/etc/issue $login_banner_text EOF} To check if the system login banner is compliant, run the following command: $ cat /etc/issue In the default graphical environment, users logging directly into the system are greeted with a login screen provided by the GNOME Display Manager (GDM). The warning banner should be displayed in this graphical environment for these users. The following sections describe how to configure the GDM login banner. To enable displaying a login warning banner in the GNOME Display Manager's login screen, run the following command: sudo -u gdm gconftool-2 \ --type bool \ --set /apps/gdm/simple-greeter/banner_message_enable true To display a banner, this setting must be enabled and then banner text must also be set. AC-8(a) AC-8(b) AC-8(c) 48 50 An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. CCE-27195-7 To ensure a login warning banner is enabled, run the following: $ gconftool-2 -g /apps/gdm/simple-greeter/banner_message_enable Search for the banner_message_enable schema. If properly configured, the default value should be true. To set the text shown by the GNOME Display Manager in the login screen, run the following command: sudo -u gdm gconftool-2 \ --type string \ --set /apps/gdm/simple-greeter/banner_message_text \ "Text of the warning banner here" When entering a warning banner that spans several lines, remember to begin and end the string with ". This command writes directly to the file /var/lib/gdm/.gconf/apps/gdm/simple-greeter/%gconf.xml, and this file can later be edited directly if necessary. AC-8(a) AC-8(b) AC-8(c) 48 1384 1385 1386 1387 1388 An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers. CCE-27017-3 To ensure the login warning banner text is properly set, run the following: $ gconftool-2 -g /apps/gdm/simple-greeter/banner_message_text If properly configured, the proper banner text will appear within this schema. In the default graphical environment, users logging directly into the system are greeted with a login screen that displays all known users. This functionality should be disabled. Run the following command to disable the user list: sudo -u gdm gconftool-2 \ --type bool \ --set /apps/gdm/simple-greeter/disable_user_list true AC-23 Leaving the user list enabled is a security risk since it allows anyone with physical access to the system to quickly enumerate known user accounts without logging in. CCE-27230-2 To ensure the user list is disabled, run the following command: $ gconftool-2 -g /apps/gdm/simple-greeter/disable_user_list The output should be true. Most 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. This section also discusses firewalls, network access controls, and other network security frameworks, which allow system-level rules to be written that can limit an attackers' ability to connect to your system. These rules can specify that network traffic should be allowed or denied from certain IP addresses, hosts, and networks. The rules can also specify which of the system's network services are available to particular hosts or networks. Network interfaces expand the attack surface of the system. Unused interfaces are not monitored or controlled, and should be disabled. If the system does not require network communications but still needs to use the loopback interface, remove all files of the form ifcfg-interface except for ifcfg-lo from /etc/sysconfig/network-scripts: # rm /etc/sysconfig/network-scripts/ifcfg-interface If the system is a standalone machine with no need for network access or even communication over the loopback device, then disable this service. The network service can be disabled with the following command: # chkconfig network off Zeroconf networking allows the system to assign itself an IP address and engage in IP communication without a statically-assigned address or even a DHCP server. Automatic address assignment via Zeroconf (or DHCP) is not recommended. To disable Zeroconf automatic route assignment in the 169.245.0.0 subnet, add or correct the following line in /etc/sysconfig/network: NOZEROCONF=yes CM-7 Zeroconf addresses are in the network 169.254.0.0. The networking scripts add entries to the system's routing table for these addresses. Zeroconf address assignment commonly occurs when the system is configured to use DHCP but fails to receive an address assignment from the DHCP server. CCE-27151-0 The system should not be acting as a network sniffer, which can capture all traffic on the network to which it is connected. Run the following to determine if any interface is running in promiscuous mode: $ ip link | grep PROMISC CM-7 MA-3 If any results are returned, then a sniffing process (such as tcpdump or Wireshark) is likely to be using the interface and this should be investigated. CCE-27152-8 The sysctl utility is used to set parameters which affect the operation of the Linux kernel. Kernel parameters which affect networking and have security implications are described here. If 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. To set the runtime status of the net.ipv4.conf.default.send_redirects kernel parameter, run the following command: # sysctl -w net.ipv4.conf.default.send_redirects=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.default.send_redirects = 0 AC-4 CM-7 SC-5 SC-7 1551 DS 20121024 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. CCE-27001-7 The status of the net.ipv4.conf.default.send_redirects kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.default.send_redirects The output of the command should indicate a value of 0. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. To set the runtime status of the net.ipv4.conf.all.send_redirects kernel parameter, run the following command: # sysctl -w net.ipv4.conf.all.send_redirects=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.all.send_redirects = 0 CM-7 1551 DS 20121024 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. CCE-27004-1 The status of the net.ipv4.conf.all.send_redirects kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.all.send_redirects The output of the command should indicate a value of 0. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. To set the runtime status of the net.ipv4.ip_forward kernel parameter, run the following command: # sysctl -w net.ipv4.ip_forward=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.ip_forward = 0 CM-7 SC-5 366 DS 20121024 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. CCE-26866-4 The status of the net.ipv4.ip_forward kernel parameter can be queried by running the following command: $ sysctl net.ipv4.ip_forward The output of the command should indicate a value of 0. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. The ability to forward packets is only appropriate for routers. Certain 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. Trackers could be using source-routed packets to generate traffic that seems to be intra-net, but actually was created outside and has been redirected. 0 1 0 Disable ICMP Redirect Acceptance 0 1 0 Enable to prevent hijacking of routing path by only allowing redirects from gateways known in routing table. 1 1 0 Disable so you don't Log Spoofed Packets, Source Routed Packets, Redirect Packets 0 1 0 Disable IP source routing? 0 1 0 Disable ICMP Redirect Acceptance? 0 1 0 Log packets with impossible addresses to kernel log? 1 1 0 Ignore all ICMP ECHO and TIMESTAMP requests sent to it via broadcast/multicast 1 1 0 Enable to prevent unnecessary logging 1 1 0 Enable to turn on TCP SYN Cookie Protection 1 1 0 Enable to enforce sanity checking, also called ingress filtering or egress filtering. The point is to drop a packet if the source and destination IP addresses in the IP header do not make sense when considered in light of the physical interface on which it arrived. 1 1 0 Enables source route verification 1 1 0 To set the runtime status of the net.ipv4.conf.all.accept_source_route kernel parameter, run the following command: # sysctl -w net.ipv4.conf.all.accept_source_route=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.all.accept_source_route = 0 CM-7 1551 DS 20121024 Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required. CCE-27037-1 # # Set runtime for net.ipv4.conf.all.accept_source_route # sysctl -q -n -w net.ipv4.conf.all.accept_source_route=0 # # If net.ipv4.conf.all.accept_source_route present in /etc/sysctl.conf, change value to "0" # else, add "net.ipv4.conf.all.accept_source_route = 0" to /etc/sysctl.conf # if grep --silent ^net.ipv4.conf.all.accept_source_route /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.all.accept_source_route.*/net.ipv4.conf.all.accept_source_route = 0/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.all.accept_source_route to 0 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.all.accept_source_route = 0" >> /etc/sysctl.conf fi The status of the net.ipv4.conf.all.accept_source_route kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.all.accept_source_route The output of the command should indicate a value of 0. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. To set the runtime status of the net.ipv4.conf.all.accept_redirects kernel parameter, run the following command: # sysctl -w net.ipv4.conf.all.accept_redirects=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.all.accept_redirects = 0 CM-7 1503 1551 DS 20121024 Accepting ICMP redirects has few legitimate uses. It should be disabled unless it is absolutely required. CCE-27027-2 # # Set runtime for net.ipv4.conf.all.accept_redirects # sysctl -q -n -w net.ipv4.conf.all.accept_redirects=0 # # If net.ipv4.conf.all.accept_redirects present in /etc/sysctl.conf, change value to "0" # else, add "net.ipv4.conf.all.accept_redirects = 0" to /etc/sysctl.conf # if grep --silent ^net.ipv4.conf.all.accept_redirects /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.all.accept_redirects.*/net.ipv4.conf.all.accept_redirects = 0/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.all.accept_redirects to 0 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.all.accept_redirects = 0" >> /etc/sysctl.conf fi The status of the net.ipv4.conf.all.accept_redirects kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.all.accept_redirects The output of the command should indicate a value of 0. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. To set the runtime status of the net.ipv4.conf.all.secure_redirects kernel parameter, run the following command: # sysctl -w net.ipv4.conf.all.secure_redirects=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.all.secure_redirects = 0 AC-4 CM-7 1503 1551 DS 20121024 Accepting "secure" ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required. CCE-26854-0 # # Set runtime for net.ipv4.conf.all.secure_redirects # sysctl -q -n -w net.ipv4.conf.all.secure_redirects=0 # # If net.ipv4.conf.all.secure_redirects present in /etc/sysctl.conf, change value to "0" # else, add "net.ipv4.conf.all.secure_redirects = 0" to /etc/sysctl.conf # if grep --silent ^net.ipv4.conf.all.secure_redirects /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.all.secure_redirects.*/net.ipv4.conf.all.secure_redirects = 0/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.all.secure_redirects to 0 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.all.secure_redirects = 0" >> /etc/sysctl.conf fi The status of the net.ipv4.conf.all.secure_redirects kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.all.secure_redirects The output of the command should indicate a value of 0. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. To set the runtime status of the net.ipv4.conf.all.log_martians kernel parameter, run the following command: # sysctl -w net.ipv4.conf.all.log_martians=1 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.all.log_martians = 1 AC-17(7) CM-7 126 DS 20121024 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. CCE-27066-0 # # Set runtime for net.ipv4.conf.all.log_martians # sysctl -q -n -w net.ipv4.conf.all.log_martians=1 # # If net.ipv4.conf.all.log_martians present in /etc/sysctl.conf, change value to "1" # else, add "net.ipv4.conf.all.log_martians = 1" to /etc/sysctl.conf # if grep --silent ^net.ipv4.conf.all.log_martians /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.all.log_martians.*/net.ipv4.conf.all.log_martians = 1/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.all.log_martians to 1 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.all.log_martians = 1" >> /etc/sysctl.conf fi The status of the net.ipv4.conf.all.log_martians kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.all.log_martians The output of the command should indicate a value of 1. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. To set the runtime status of the net.ipv4.conf.default.accept_source_route kernel parameter, run the following command: # sysctl -w net.ipv4.conf.default.accept_source_route=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.default.accept_source_route = 0 AC-4 CM-7 SC-5 SC-7 1551 DS 20121024 Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required. CCE-26983-7 # # Set runtime for net.ipv4.conf.default.accept_source_route # sysctl -q -n -w net.ipv4.conf.default.accept_source_route=0 # # If net.ipv4.conf.default.accept_source_route present in /etc/sysctl.conf, change value to "0" # else, add "net.ipv4.conf.default.accept_source_route = 0" to /etc/sysctl.conf # if grep --silent ^net.ipv4.conf.default.accept_source_route /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.default.accept_source_route.*/net.ipv4.conf.default.accept_source_route = 0/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.default.accept_source_route to 0 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.default.accept_source_route = 0" >> /etc/sysctl.conf fi The status of the net.ipv4.conf.default.accept_source_route kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.default.accept_source_route The output of the command should indicate a value of 0. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. To set the runtime status of the net.ipv4.conf.default.accept_redirects kernel parameter, run the following command: # sysctl -w net.ipv4.conf.default.accept_redirects=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.default.accept_redirects = 0 AC-4 CM-7 SC-5 SC-7 1551 DS 20121024 This feature of the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required. CCE-27015-7 # # Set runtime for net.ipv4.conf.default.accept_redirects # sysctl -q -n -w net.ipv4.conf.default.accept_redirects=0 # # If net.ipv4.conf.default.accept_redirects present in /etc/sysctl.conf, change value to "0" # else, add "net.ipv4.conf.default.accept_redirects = 0" to /etc/sysctl.conf # if grep --silent ^net.ipv4.conf.default.accept_redirects /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.default.accept_redirects.*/net.ipv4.conf.default.accept_redirects = 0/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.default.accept_redirects to 0 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.default.accept_redirects = 0" >> /etc/sysctl.conf fi The status of the net.ipv4.conf.default.accept_redirects kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.default.accept_redirects The output of the command should indicate a value of 0. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. To set the runtime status of the net.ipv4.conf.default.secure_redirects kernel parameter, run the following command: # sysctl -w net.ipv4.conf.default.secure_redirects=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.default.secure_redirects = 0 AC-4 CM-7 SC-5 SC-7 1551 DS 20121024 Accepting "secure" ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required. CCE-26831-8 # # Set runtime for net.ipv4.conf.default.secure_redirects # sysctl -q -n -w net.ipv4.conf.default.secure_redirects=0 # # If net.ipv4.conf.default.secure_redirects present in /etc/sysctl.conf, change value to "0" # else, add "net.ipv4.conf.default.secure_redirects = 0" to /etc/sysctl.conf # if grep --silent ^net.ipv4.conf.default.secure_redirects /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.default.secure_redirects.*/net.ipv4.conf.default.secure_redirects = 0/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.default.secure_redirects to 0 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.default.secure_redirects = 0" >> /etc/sysctl.conf fi The status of the net.ipv4.conf.default.secure_redirects kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.default.secure_redirects The output of the command should indicate a value of 0. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. To set the runtime status of the net.ipv4.icmp_echo_ignore_broadcasts kernel parameter, run the following command: # sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.icmp_echo_ignore_broadcasts = 1 CM-7 SC-5 1551 DS 20121024 Ignoring ICMP echo requests (pings) sent to broadcast or multicast addresses makes the system slightly more difficult to enumerate on the network. CCE-26883-9 # # Set runtime for net.ipv4.icmp_echo_ignore_broadcasts # sysctl -q -n -w net.ipv4.icmp_echo_ignore_broadcasts=1 # # If net.ipv4.icmp_echo_ignore_broadcasts present in /etc/sysctl.conf, change value to "1" # else, add "net.ipv4.icmp_echo_ignore_broadcasts = 1" to /etc/sysctl.conf # if grep --silent ^net.ipv4.icmp_echo_ignore_broadcasts /etc/sysctl.conf ; then sed -i 's/^net.ipv4.icmp_echo_ignore_broadcasts.*/net.ipv4.icmp_echo_ignore_broadcasts = 1/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.icmp_echo_ignore_broadcasts to 1 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.icmp_echo_ignore_broadcasts = 1" >> /etc/sysctl.conf fi The status of the net.ipv4.icmp_echo_ignore_broadcasts kernel parameter can be queried by running the following command: $ sysctl net.ipv4.icmp_echo_ignore_broadcasts The output of the command should indicate a value of 1. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. To set the runtime status of the net.ipv4.icmp_ignore_bogus_error_responses kernel parameter, run the following command: # sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.icmp_ignore_bogus_error_responses = 1 CM-7 SC-5 DS 20121024 Ignoring bogus ICMP error responses reduces log size, although some activity would not be logged. CCE-26993-6 # # Set runtime for net.ipv4.icmp_ignore_bogus_error_responses # sysctl -q -n -w net.ipv4.icmp_ignore_bogus_error_responses=1 # # If net.ipv4.icmp_ignore_bogus_error_responses present in /etc/sysctl.conf, change value to "1" # else, add "net.ipv4.icmp_ignore_bogus_error_responses = 1" to /etc/sysctl.conf # if grep --silent ^net.ipv4.icmp_ignore_bogus_error_responses /etc/sysctl.conf ; then sed -i 's/^net.ipv4.icmp_ignore_bogus_error_responses.*/net.ipv4.icmp_ignore_bogus_error_responses = 1/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.icmp_ignore_bogus_error_responses to 1 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.icmp_ignore_bogus_error_responses = 1" >> /etc/sysctl.conf fi The status of the net.ipv4.icmp_ignore_bogus_error_responses kernel parameter can be queried by running the following command: $ sysctl net.ipv4.icmp_ignore_bogus_error_responses The output of the command should indicate a value of 1. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. To set the runtime status of the net.ipv4.tcp_syncookies kernel parameter, run the following command: # sysctl -w net.ipv4.tcp_syncookies=1 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.tcp_syncookies = 1 AC-4 1092 1095 DS 20121024 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. CCE-27053-8 # # Set runtime for net.ipv4.tcp_syncookies # sysctl -q -n -w net.ipv4.tcp_syncookies=1 # # If net.ipv4.tcp_syncookies present in /etc/sysctl.conf, change value to "1" # else, add "net.ipv4.tcp_syncookies = 1" to /etc/sysctl.conf # if grep --silent ^net.ipv4.tcp_syncookies /etc/sysctl.conf ; then sed -i 's/^net.ipv4.tcp_syncookies.*/net.ipv4.tcp_syncookies = 1/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.tcp_syncookies to 1 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf fi The status of the net.ipv4.tcp_syncookies kernel parameter can be queried by running the following command: $ sysctl net.ipv4.tcp_syncookies The output of the command should indicate a value of 1. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. To set the runtime status of the net.ipv4.conf.all.rp_filter kernel parameter, run the following command: # sysctl -w net.ipv4.conf.all.rp_filter=1 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.all.rp_filter = 1 AC-4 SC-5 SC-7 1551 DS 20121024 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. CCE-26979-5 # # Set runtime for net.ipv4.conf.all.rp_filter # sysctl -q -n -w net.ipv4.conf.all.rp_filter=1 # # If net.ipv4.conf.all.rp_filter present in /etc/sysctl.conf, change value to "1" # else, add "net.ipv4.conf.all.rp_filter = 1" to /etc/sysctl.conf # if grep --silent ^net.ipv4.conf.all.rp_filter /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.all.rp_filter.*/net.ipv4.conf.all.rp_filter = 1/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.all.rp_filter to 1 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.all.rp_filter = 1" >> /etc/sysctl.conf fi The status of the net.ipv4.conf.all.rp_filter kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.all.rp_filter The output of the command should indicate a value of 1. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. To set the runtime status of the net.ipv4.conf.default.rp_filter kernel parameter, run the following command: # sysctl -w net.ipv4.conf.default.rp_filter=1 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv4.conf.default.rp_filter = 1 AC-4 SC-5 SC-7 DS 20121024 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. CCE-26915-9 # # Set runtime for net.ipv4.conf.default.rp_filter # sysctl -q -n -w net.ipv4.conf.default.rp_filter=1 # # If net.ipv4.conf.default.rp_filter present in /etc/sysctl.conf, change value to "1" # else, add "net.ipv4.conf.default.rp_filter = 1" to /etc/sysctl.conf # if grep --silent ^net.ipv4.conf.default.rp_filter /etc/sysctl.conf ; then sed -i 's/^net.ipv4.conf.default.rp_filter.*/net.ipv4.conf.default.rp_filter = 1/g' /etc/sysctl.conf else echo "" >> /etc/sysctl.conf echo "# Set net.ipv4.conf.default.rp_filter to 1 per security requirements" >> /etc/sysctl.conf echo "net.ipv4.conf.default.rp_filter = 1" >> /etc/sysctl.conf fi The status of the net.ipv4.conf.default.rp_filter kernel parameter can be queried by running the following command: $ sysctl net.ipv4.conf.default.rp_filter The output of the command should indicate a value of 1. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. Wireless 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 desktops or servers. Removal of hardware provides the greatest assurance that the wireless capability remains disabled. Acquisition policies often include provisions to prevent the purchase of equipment that will be used in sensitive spaces and includes wireless capabilities. If it is impractical to remove the wireless hardware, and policy permits the device to enter sensitive spaces as long as wireless is disabled, efforts should instead focus on disabling wireless capability via software. If 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. Some systems that include built-in wireless support offer the ability to disable the device through the BIOS. This is system-specific; consult your hardware manual or explore the BIOS setup during boot. AC-17(8) AC-18(a) AC-18(d) AC-18(3) CM-7 85 Disabling wireless support in the BIOS prevents easy activation of the wireless interface, generally requiring administrators to reboot the system first. CCE-26878-9 Deactivating wireless network interfaces should prevent normal usage of the wireless capability. First, identify the interfaces available with the command: # ifconfig -a Additionally,the following command may also be used to determine whether wireless support ('extensions') is included for a particular interface, though this may not always be a clear indicator: # iwconfig After identifying any wireless interfaces (which may have names like wlan0, ath0, wifi0, em1 or eth0), deactivate the interface with the command: # ifdown interface These 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: # rm /etc/sysconfig/network-scripts/ifcfg-interface AC-17(8) AC-18(a) AC-18(d) AC-18(3) CM-7 85 DS 20121025 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. CCE-27057-9 The bluetooth service can be disabled with the following command: # chkconfig bluetooth off # service bluetooth stop AC-17(8) AC-18(a) AC-18(d) AC-18(3) CM-7 85 1551 DS 20121025 Disabling the bluetooth service prevents the system from attempting connections to Bluetooth devices, which entails some security risk. Nevertheless, variation in this risk decision may be expected due to the utility of Bluetooth connectivity and its limited range. CCE-27081-9 To check that the bluetooth service is disabled in system boot configuration, run the following command: # chkconfig bluetooth --list Output should indicate the bluetooth service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig bluetooth --list bluetooth 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify bluetooth is disabled through current runtime configuration: # service bluetooth status If the service is disabled the command will return the following output: bluetooth is stopped The kernel's module loading system can be configured to prevent loading of the Bluetooth module. Add the following to the appropriate /etc/modprobe.d configuration file to prevent the loading of the Bluetooth module: install net-pf-31 /bin/false install bluetooth /bin/false AC-17(8) AC-18(a) AC-18(d) AC-18(3) CM-7 85 1551 DS 20121025 If Bluetooth functionality must be disabled, preventing the kernel from loading the kernel module provides an additional safeguard against its activation. CCE-26763-3 If the system is configured to prevent the loading of the bluetooth kernel module, it will contain lines inside any file in /etc/modprobe.d or the deprecated/etc/modprobe.conf. These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event. Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf: $ grep -r bluetooth /etc/modprobe.conf /etc/modprobe.d If the system is configured to prevent the loading of the net-pf-31 kernel module, it will contain lines inside any file in /etc/modprobe.d or the deprecated/etc/modprobe.conf. These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event. Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf: $ grep -r net-pf-31 /etc/modprobe.conf /etc/modprobe.d The 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. Despite 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. To prevent the IPv6 kernel module (ipv6) from loading the IPv6 networking stack, add the following line to /etc/modprobe.d/disabled.conf (or another file in /etc/modprobe.d): options ipv6 disable=1 This permits the IPv6 module to be loaded (and thus satisfy other modules that depend on it), while disabling support for the IPv6 protocol. CM-7 1551 DS 20121024 Any unnecessary network stacks - including IPv6 - should be disabled, to reduce the vulnerability to exploitation. CCE-27153-6 If the system uses IPv6, this is not applicable. If the system is configured to prevent the loading of the ipv6 kernel module, it will contain a line of the form: options ipv6 disable=1 Such lines may be inside any file in /etc/modprobe.d or the deprecated/etc/modprobe.conf. This permits insertion of the IPv6 kernel module (which other parts of the system expect to be present), but otherwise keeps it inactive. Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf: $ grep -r ipv6 /etc/modprobe.conf /etc/modprobe.d RPC services for NFSv4 try to load transport modules for udp6 and tcp6 by default, even if IPv6 has been disabled in /etc/modprobe.d. To prevent RPC services such as rpc.mountd from attempting to start IPv6 network listeners, remove or comment out the following two lines in /etc/netconfig: udp6 tpi_clts v inet6 udp - - tcp6 tpi_cots_ord v inet6 tcp - - CM-7 CCE-27232-8 A 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. Disable the system's acceptance of router advertisements and redirects by adding or correcting the following line in /etc/sysconfig/network (note that this does not disable sending router solicitations): IPV6_AUTOCONF=no Toggle global IPv6 auto-configuration (only, if global forwarding is disabled) no yes no Accept default router advertisements? 0 1 0 Toggle ICMP Redirect Acceptance 0 1 0 To set the runtime status of the net.ipv6.conf.default.accept_ra kernel parameter, run the following command: # sysctl -w net.ipv6.conf.default.accept_ra=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv6.conf.default.accept_ra = 0 CM-7 An illicit router advertisement message could result in a man-in-the-middle attack. CCE-27164-3 The status of the net.ipv6.conf.default.accept_ra kernel parameter can be queried by running the following command: $ sysctl net.ipv6.conf.default.accept_ra The output of the command should indicate a value of 0. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. To set the runtime status of the net.ipv6.conf.default.accept_redirects kernel parameter, run the following command: # sysctl -w net.ipv6.conf.default.accept_redirects=0 If this is not the system's default value, add the following line to /etc/sysctl.conf: net.ipv6.conf.default.accept_redirects = 0 CM-7 1551 An illicit ICMP redirect message could result in a man-in-the-middle attack. CCE-27166-8 The status of the net.ipv6.conf.default.accept_redirects kernel parameter can be queried by running the following command: $ sysctl net.ipv6.conf.default.accept_redirects The output of the command should indicate a value of 0. If this value is not the default value, investigate how it could have been adjusted at runtime, and verify it is not set improperly in /etc/sysctl.conf. To manually assign an IP address for an interface, edit the file /etc/sysconfig/network-scripts/ifcfg-interface. Add or correct the following line (substituting the correct IPv6 address): IPV6ADDR=2001:0DB8::ABCD/64 Manually assigning an IP address is preferable to accepting one from routers or from the network otherwise. The example address here is an IPv6 address reserved for documentation purposes, as defined by RFC3849. CCE-27233-6 To introduce randomness into the automatic generation of IPv6 addresses, add or correct the following line in /etc/sysconfig/network-scripts/ifcfg-interface: IPV6_PRIVACY=rfc3041 Automatically-generated IPv6 addresses are based on the underlying hardware (e.g. Ethernet) address, and so it becomes possible to track a piece of hardware over its lifetime using its traffic. If it is important for a system's IP address to not trivially reveal its hardware address, this setting should be applied. CCE-27154-4 Edit the file /etc/sysconfig/network-scripts/ifcfg-interface, and add or correct the following line (substituting your gateway IP as appropriate): IPV6_DEFAULTGW=2001:0DB8::0001 Router addresses should be manually set and not accepted via any auto-configuration or router advertisement. CCE-27234-4 To limit the configuration information requested from other systems and accepted from the network on a system that uses statically-configured IPv6 addresses, add the following lines to /etc/sysctl.conf: net.ipv6.conf.default.router_solicitations = 0 net.ipv6.conf.default.accept_ra_rtr_pref = 0 net.ipv6.conf.default.accept_ra_pinfo = 0 net.ipv6.conf.default.accept_ra_defrtr = 0 net.ipv6.conf.default.autoconf = 0 net.ipv6.conf.default.dad_transmits = 0 net.ipv6.conf.default.max_addresses = 1 The router_solicitations setting determines how many router solicitations are sent when bringing up the interface. If addresses are statically assigned, there is no need to send any solicitations. The accept_ra_pinfo setting controls whether the system will accept prefix info from the router. The accept_ra_defrtr setting controls whether the system will accept Hop Limit settings from a router advertisement. Setting it to 0 prevents a router from changing your default IPv6 Hop Limit for outgoing packets. The autoconf setting controls whether router advertisements can cause the system to assign a global unicast address to an interface. The dad_transmits setting determines how many neighbor solicitations to send out per address (global and link-local) when bringing up an interface to ensure the desired address is unique on the network. The max_addresses setting determines how many global unicast IPv6 addresses can be assigned to each interface. The default is 16, but it should be set to exactly the number of statically configured global addresses required. A host-based firewall called Netfilter is included as part of the Linux kernel distributed with the system. It is activated by default. This firewall is controlled by the program iptables, and the entire capability is frequently referred to by this name. An analogous program called ip6tables handles filtering for IPv6. Unlike TCP Wrappers, which depends on the network server program to support and respect the rules written, Netfilter filtering occurs at the kernel level, before a program can even process the data from the network packet. As such, any program on the system is affected by the rules written. This section provides basic information about strengthening the iptables and ip6tables configurations included with the system. For more complete information that may allow the construction of a sophisticated ruleset tailored to your environment, please consult the references at the end of this section. View the currently-enforced iptables rules by running the command: # iptables -nL --line-numbers The command is analogous for the ip6tables program. If the firewall does not appear to be active (i.e., no rules appear), activate it and ensure that it starts at boot by issuing the following commands (and analogously for ip6tables): # service iptables restart The default iptables rules are: Chain INPUT (policy ACCEPT) num target prot opt source destination 1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 5 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) num target prot opt source destination 1 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) num target prot opt source destination The ip6tables default rules are essentially the same. The ip6tables service can be enabled with the following command: # chkconfig --level 2345 ip6tables on AC-4 CA-3(c) CM-7 32 66 1115 1118 1092 1117 1098 1100 1097 1414 DS 20121024 The ip6tables service provides the system's host-based firewalling capability for IPv6 and ICMPv6. CCE-27006-6 If IPv6 is disabled, this is not applicable. Run the following command to determine the current status of the ip6tables service: # service ip6tables status If the service is enabled, it should return the following: ip6tables is running... To set the default policy to DROP (instead of ACCEPT) for the built-in INPUT chain which processes incoming packets, add or correct the following line in /etc/sysconfig/ip6tables: :INPUT DROP [0:0] CM-7 66 1109 1154 1414 In ip6tables the default policy is applied only after all the applicable rules in the table are examined for a match. Setting the default policy to DROP implements proper design for a firewall, i.e. any packets which are not explicitly permitted should not be accepted. CCE-27317-7 If IPv6 is disabled, this is not applicable. Inspect the file /etc/sysconfig/ip6tables to determine the default policy for the INPUT chain. It should be set to DROP: # grep ":INPUT" /etc/sysconfig/ip6tables The iptables service can be enabled with the following command: # chkconfig --level 2345 iptables on AC-4 CA-3(c) CM-7 32 66 1115 1118 1092 1117 1098 1100 1097 1414 DS 20121024 The iptables service provides the system's host-based firewalling capability for IPv4 and ICMP. CCE-27018-1 Run the following command to determine the current status of the iptables service: # service iptables status If the service is enabled, it should return the following: iptables is running... The default rules can be strengthened. The system scripts that activate the firewall rules expect them to be defined in the configuration files iptables and ip6tables in the directory /etc/sysconfig. Many of the lines in these files are similar to the command line arguments that would be provided to the programs /sbin/iptables or /sbin/ip6tables - but some are quite different. The following recommendations describe how to strengthen the default ruleset configuration file. An alternative to editing this configuration file is to create a shell script that makes calls to the iptables program to load in rules, and then invokes service iptables save to write those loaded rules to /etc/sysconfig/iptables. The following alterations can be made directly to /etc/sysconfig/iptables and /etc/sysconfig/ip6tables. Instructions apply to both unless otherwise noted. Language and address conventions for regular iptables are used throughout this section; configuration for ip6tables will be either analogous or explicitly covered. The program system-config-securitylevel allows additional services to penetrate the default firewall rules and automatically adjusts /etc/sysconfig/iptables. This program is only useful if the default ruleset meets your security requirements. Otherwise, this program should not be used to make changes to the firewall configuration because it re-writes the saved configuration file. To set the default policy to DROP (instead of ACCEPT) for the built-in INPUT chain which processes incoming packets, add or correct the following line in /etc/sysconfig/iptables: :INPUT DROP [0:0] CM-7 66 1109 1154 1414 In iptables the default policy is applied only after all the applicable rules in the table are examined for a match. Setting the default policy to DROP implements proper design for a firewall, i.e. any packets which are not explicitly permitted should not be accepted. CCE-26444-0 Inspect the file /etc/sysconfig/iptables to determine the default policy for the INPUT chain. It should be set to DROP: # grep ":INPUT" /etc/sysconfig/iptables To set the default policy to DROP (instead of ACCEPT) for the built-in FORWARD chain which processes packets that will be forwarded from one interface to another, add or correct the following line in /etc/sysconfig/iptables: :FORWARD DROP [0:0] CM-7 1109 In iptables the default policy is applied only after all the applicable rules in the table are examined for a match. Setting the default policy to DROP implements proper design for a firewall, i.e. any packets which are not explicitly permitted should not be accepted. CCE-27186-6 Run the following command to ensure the default FORWARD policy is DROP: grep ":FORWARD" /etc/sysconfig/iptables The output should be similar to the following: # grep ":FORWARD" /etc/sysconfig/iptables :FORWARD DROP [0:0 In /etc/sysconfig/iptables, the accepted ICMP messages types can be restricted. To accept only ICMP echo reply, destination unreachable, and time exceeded messages, remove the line: -A INPUT -p icmp --icmp-type any -j ACCEPT and insert the lines: -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT To allow the system to respond to pings, also insert the following line: -A INPUT -p icmp --icmp-type echo-request -j ACCEPT Ping responses can also be limited to certain networks or hosts by using the -s option in the previous rule. Because IPv6 depends so heavily on ICMPv6, it is preferable to deny the ICMPv6 packets you know you don't need (e.g. ping requests) in /etc/sysconfig/ip6tables, while letting everything else through: -A INPUT -p icmpv6 --icmpv6-type echo-request -j DROP If you are going to statically configure the machine's address, it should ignore Router Advertisements which could add another IPv6 address to the interface or alter important network settings: -A INPUT -p icmpv6 --icmpv6-type router-advertisement -j DROP Restricting ICMPv6 message types in /etc/sysconfig/ip6tables is not recommended because the operation of IPv6 depends heavily on ICMPv6. Thus, great care must be taken if any other ICMPv6 types are blocked. Restricting ICMP messages may make a system slightly less discoverable to an unsophisticated attacker but is not appropriate for many general-purpose use cases and can also make troubleshooting more difficult. Packets with non-routable source addresses should be rejected, as they may indicate spoofing. Because the modified policy will reject non-matching packets, you only need to add these rules if you are interested in also logging these spoofing or suspicious attempts before they are dropped. If you do choose to log various suspicious traffic, add identical rules with a target of DROP after each LOG. To log and then drop these IPv4 packets, insert the following rules in /etc/sysconfig/iptables (excepting any that are intentionally used): -A INPUT -s 10.0.0.0/8 -j LOG --log-prefix "IP DROP SPOOF A: " -A INPUT -s 172.16.0.0/12 -j LOG --log-prefix "IP DROP SPOOF B: " -A INPUT -s 192.168.0.0/16 -j LOG --log-prefix "IP DROP SPOOF C: " -A INPUT -s 224.0.0.0/4 -j LOG --log-prefix "IP DROP MULTICAST D: " -A INPUT -s 240.0.0.0/5 -j LOG --log-prefix "IP DROP SPOOF E: " -A INPUT -d 127.0.0.0/8 -j LOG --log-prefix "IP DROP LOOPBACK: " Similarly, you might wish to log packets containing some IPv6 reserved addresses if they are not expected on your network: -A INPUT -i eth0 -s ::1 -j LOG --log-prefix "IPv6 DROP LOOPBACK: " -A INPUT -s 2002:E000::/20 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: " -A INPUT -s 2002:7F00::/24 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: " -A INPUT -s 2002:0000::/24 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: " -A INPUT -s 2002:FF00::/24 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: " -A INPUT -s 2002:0A00::/24 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: " -A INPUT -s 2002:AC10::/28 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: " -A INPUT -s 2002:C0A8::/32 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: " If you are not expecting to see site-local multicast or auto-tunneled traffic, you can log those: -A INPUT -s FF05::/16 -j LOG --log-prefix "IPv6 SITE-LOCAL MULTICAST: " -A INPUT -s ::0.0.0.0/96 -j LOG --log-prefix "IPv4 COMPATIBLE IPv6 ADDR: " If you wish to block multicasts to all link-local nodes (e.g. if you are not using router auto-configuration and do not plan to have any services that multicast to the entire local network), you can block the link-local all-nodes multicast address (before accepting incoming ICMPv6): -A INPUT -d FF02::1 -j LOG --log-prefix "Link-local All-Nodes Multicast: " However, if you're going to allow IPv4 compatible IPv6 addresses (of the form ::0.0.0.0/96), you should then consider logging the non-routable IPv4-compatible addresses: -A INPUT -s ::0.0.0.0/104 -j LOG --log-prefix "IP NON-ROUTABLE ADDR: " -A INPUT -s ::127.0.0.0/104 -j LOG --log-prefix "IP DROP LOOPBACK: " -A INPUT -s ::224.0.0.0.0/100 -j LOG --log-prefix "IP DROP MULTICAST D: " -A INPUT -s ::255.0.0.0/104 -j LOG --log-prefix "IP BROADCAST: " If you are not expecting to see any IPv4 (or IPv4-compatible) traffic on your network, consider logging it before it gets dropped: -A INPUT -s ::FFFF:0.0.0.0/96 -j LOG --log-prefix "IPv4 MAPPED IPv6 ADDR: " -A INPUT -s 2002::/16 -j LOG --log-prefix "IPv6 6to4 ADDR: " The following rule will log all traffic originating from a site-local address, which is deprecated address space: -A INPUT -s FEC0::/10 -j LOG --log-prefix "SITE-LOCAL ADDRESS TRAFFIC: " The Secure Sockets Layer (SSL) protocol provides encrypted and authenticated network communications, and many network services include support for it. Using SSL is recommended, especially to avoid any plaintext transmission of sensitive data, even over a local network. The SSL implementation included with the system is called OpenSSL. Recent implementations of SSL may also be referred to as Transport Layer Security (TLS). SSL uses public key cryptography to provide authentication and encryption. Public key cryptography involves two keys, one called the public key and the other called the private key. These keys are mathematically related such that data encrypted with one key can only be decrypted by the other, and vice versa. As their names suggest, public keys can be distributed to anyone while a private key must remain known only to its owner. SSL uses certificates, which are files that hold cryptographic data: a public key, and a signature of that public key. In SSL authentication, a server presents a client with its certificate as a means of demonstrating that it is who it claims it is. If everything goes correctly, the client can verify the server's certificate by determining that the signature inside the certificate could only have been generated by a third party whom the client trusts. This third party is called a Certificate Authority (CA). Each client system should also have certificates from trusted CAs, and the client uses these CA certificates to verify the authenticity of the server's certificate. After authenticating a server using its certificate and a CA certificate, SSL provides encryption by using the server certificate to securely negotiate a shared secret key. If your server must communicate using SSL with systems that might not be able to securely accept a new CA certificate prior to any SSL communication, then paying an established CA (whose certificates your clients already have) to sign your server certificates is recommended. The steps for doing this vary by vendor. Once the signed certificates have been obtained, configuration of the services is the same whether they were purchased from a vendor or signed by your own CA. For setting up an internal network and encrypting local traffic, creating your own CA to sign SSL certificates can be appropriate. The major steps in this process are: Create a CA to sign certificatesCreate SSL certificates for servers using that CAEnable client support by distributing the CA's certificate The following instructions apply to OpenSSL since it is included with the system, but creating a CA is possible with any standards-compliant SSL toolkit. The security of certificates depends on the security of the CA that signed them, so performing these steps on a secure machine is critical. The system used as a CA should be physically secure and not connected to any network. It should receive any certificate signing requests (CSRs) via removable media and output certificates onto removable media. The script /etc/pki/tls/misc/CA is included to assist in the process of setting up a CA. This script uses many settings in /etc/pki/tls/openssl.cnf. The settings in this file can be changed to suit your needs and allow easier selection of default settings, particularly in the [req distinguished name] section. To create the CA: # cd /etc/pki/tls/misc # ./CA -newca When prompted, press enter to create a new CA key with the default name cakey.pem. When prompted, enter a password that will protect the private key, then enter the same password again to verify it. At the prompts, fill out as much of the CA information as is relevant for your site. You must specify a common name, or generation of the CA certificate will fail. Next, you will be prompted for the password, so that the script can re-open the private key in order to write the certificate. This step performs the following actions: creates the directory /etc/pki/CA (by default), which contains files necessary for the operation of a certificate authority. These are: serial, which contains the current serial number for certificates signed by the CAindex.txt, which is a text database file that contains information about certificates signedcrl, which is a directory for holding revoked certificatesprivate, a directory which stores the CA's private keycreates a public-private key pair for the CA in the file /etc/pki/CA/private/cakey.pem. The private key must be kept private in order to ensure the security of the certificates the CA will later sign.signs the public key (using the corresponding private key, in a process called self-signing) to create the CA certificate, which is then stored in /etc/pki/CA/cacert.pem. When the CA later signs a server certificate using its private key, it means that it is vouching for the authenticity of that server. A client can then use the CA's certificate (which contains its public key) to verify the authenticity of the server certificate. Creating an SSL certificate for a server involves the following steps: A public-private key pair for the server must be generated.A certificate signing request (CSR) must be created from the key pair.The CSR must be signed by a certificate authority (CA) to create the server certificate. If a CA has been set up as described earlier, it can sign the CSR.The server certificate and keys must be installed on the server. Instructions on how to generate and sign SSL certificates are provided for the following common services can be found in the applicable sections of this guide: PostfixDovecotApache Survey the certificate authorities trusted by Firefox, Thunderbird, Evolution, or other network clients. The list of certificate authorities for each program can be found via GUI, as described in the previous sections. Remove the certificate authorities which are not appropriate for your network connectivity needs. This may only make sense for some environments, and may create operational problems for a general purpose Internet-connected system. The 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. Although these protocols are not commonly used, avoid disruption in your network environment by ensuring they are not needed prior to disabling them. 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/false CM-7 382 DS 20121024 Disabling DCCP protects the system against exploitation of any flaws in its implementation. CCE-26448-1 If the system is configured to prevent the loading of the dccp kernel module, it will contain lines inside any file in /etc/modprobe.d or the deprecated/etc/modprobe.conf. These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event. Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf: $ grep -r dccp /etc/modprobe.conf /etc/modprobe.d 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/false CM-7 382 DS 20121024 Disabling SCTP protects the system against exploitation of any flaws in its implementation. CCE-26410-1 If the system is configured to prevent the loading of the sctp kernel module, it will contain lines inside any file in /etc/modprobe.d or the deprecated/etc/modprobe.conf. These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event. Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf: $ grep -r sctp /etc/modprobe.conf /etc/modprobe.d 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 rds kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d: install rds /bin/false CM-7 382 DS 20121024 Disabling RDS protects the system against exploitation of any flaws in its implementation. CCE-26239-4 If the system is configured to prevent the loading of the rds kernel module, it will contain lines inside any file in /etc/modprobe.d or the deprecated/etc/modprobe.conf. These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event. Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf: $ grep -r rds /etc/modprobe.conf /etc/modprobe.d The Transparent Inter-Process Communication (TIPC) protocol is designed to provide communications between nodes in a cluster. To configure the system to prevent the tipc kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d: install tipc /bin/false CM-7 382 DS 20121024 Disabling TIPC protects the system against exploitation of any flaws in its implementation. CCE-26696-5 If the system is configured to prevent the loading of the tipc kernel module, it will contain lines inside any file in /etc/modprobe.d or the deprecated/etc/modprobe.conf. These lines instruct the module loading system to run another program (such as /bin/false) upon a module install event. Run the following command to search for such lines in all files in /etc/modprobe.d and the deprecated /etc/modprobe.conf: $ grep -r tipc /etc/modprobe.conf /etc/modprobe.d Support for Internet Protocol Security (IPsec) is provided in RHEL 6 with Openswan. The Openswan package provides an implementation of IPsec and IKE, which permits the creation of secure tunnels over untrusted networks. The openswan package can be installed with the following command: # yum install openswan AC-17 MA-4 SC-9 1130 1131 Providing the ability for remote users or systems to initiate a secure VPN connection protects information when it is transmitted over a wide area network. CCE-27626-1 Run the following command to determine if the openswan package is installed: # rpm -q openswan The 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. In RHEL 6, rsyslog has replaced ksyslogd as the syslog daemon of choice, and it includes some additional security features such as reliable, connection-oriented (i.e. TCP) transmission of logs, the option to log to database formats, and the encryption of log data en route to a central logging server. This section discusses how to configure rsyslog for best effect, and how to use tools provided with the system to maintain and monitor logs. Rsyslog is installed by default. The rsyslog package can be installed with the following command: # yum install rsyslog AU-9(2) 1311 1312 DS 20121024 The rsyslog package provides the rsyslog daemon, which provides system logging services. CCE-26809-4 Run the following command to determine if the rsyslog package is installed: # rpm -q rsyslog The rsyslog service provides syslog-style logging by default on RHEL 6. The rsyslog service can be enabled with the following command: # chkconfig --level 2345 rsyslog on AU-12 1557 1312 1311 DS 20121024 The rsyslog service must be running in order to provide logging services, which are essential to system administration. CCE-26807-8 Run the following command to determine the current status of the rsyslog service: # service rsyslog status If the service is enabled, it should return the following: rsyslog is running... The file /etc/rsyslog.conf controls where log message are written. These are controlled by lines called rules, which consist of a selector and an action. These rules are often customized depending on the role of the system, the requirements of the environment, and whatever may enable the administrator to most effectively make use of log data. The default rules in RHEL 6 are: *.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.log See 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 Specify user owner of all logfiles specified in /etc/rsyslog.conf. root Specify group owner of all logfiles specified in /etc/rsyslog.conf. root The owner of all log files written by rsyslog should be root. 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 owner: $ ls -l LOGFILE If the owner is not root, run the following command to correct this: # chown root LOGFILE AC-6 1314 DS 20121024 The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access. CCE-26812-8 The owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. To see the owner of a given log file, run the following command: $ ls -l LOGFILE The group-owner of all log files written by rsyslog should be root. 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 group owner: $ ls -l LOGFILE If the owner is not root, run the following command to correct this: # chgrp root LOGFILE AC-6 1314 DS 20121024 The log files generated by rsyslog contain valuable information regarding system configuration, user authentication, and other such information. Log files should be protected from unauthorized access. CCE-26821-9 The group-owner of all log files written by rsyslog should be root. These log files are determined by the second part of each Rule line in /etc/rsyslog.conf and typically all appear in /var/log. To see the group-owner of a given log file, run the following command: $ ls -l LOGFILE 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 LOGFILE If the permissions are not 600 or more restrictive, run the following command to correct this: # chmod 0600 LOGFILE 1314 DS 20121024 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. CCE-27190-8 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. To see the permissions of a given log file, run the following command: $ ls -l LOGFILE The permissions should be 600, or more restrictive. If system logs are to be useful in detecting malicious activities, it is necessary to send logs to a remote server. An intruder who has compromised the root account on a machine may delete the log entries which indicate that the system was attacked before they are seen by an administrator. However, it is recommended that logs be stored on the local host in addition to being sent to the loghost, especially if rsyslog has been configured to use the UDP protocol to send messages over a network. UDP does not guarantee reliable delivery, and moderately busy sites will lose log messages occasionally, especially in periods of high traffic which may be the result of an attack. In addition, remote rsyslog messages are not authenticated in any way by default, so it is easy for an attacker to introduce spurious messages to the central log server. Also, some problems cause loss of network connectivity, which will prevent the sending of messages to the central server. For all of these reasons, it is better to store log messages both centrally and on each host, so that they can be correlated if necessary. To configure rsyslog to send logs to a remote log server, open /etc/rsyslog.conf and read and understand the last section of the file, which describes the multiple directives necessary to activate remote logging. Along with these other directives, the system can be configured to forward its logs to a particular log server by adding or correcting one of the following lines, substituting loghost.example.com appropriately. The choice of protocol depends on the environment of the system; although TCP and RELP provide more reliable message delivery, they may not be supported in all environments. To use UDP for log message delivery: *.* @loghost.example.com To use TCP for log message delivery: *.* @@loghost.example.com To use RELP for log message delivery: *.* :omrelp:loghost.example.com AU-3(2) AU-9 1348 136 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. CCE-26801-1 To ensure logs are sent to a remote host, examine the file /etc/rsyslog.conf. If using UDP, a line similar to the following should be present: *.* @loghost.example.com If using TCP, a line similar to the following should be present: *.* @@loghost.example.com If using RELP, a line similar to the following should be present: *.* :omrelp:loghost.example.com By default, rsyslog does not listen over the network for log messages. If needed, modules can be enabled to allow the rsyslog daemon to receive messages from other systems and for the system thus to act as a log server. If the machine is not a log server, then lines concerning these modules should remain commented out. The rsyslog daemon should not accept remote messages unless the system acts as a log server. To ensure that it is not listening on the network, ensure the following lines are not found in /etc/rsyslog.conf: $ModLoad imtcp.so $InputTCPServerRun port $ModLoad imudp.so $InputUDPServerRun port $ModLoad imrelp.so $InputRELPServerRun port AU-9(2) Any process which receives messages from the network incurs some risk of receiving malicious messages. This risk can be eliminated for rsyslog by configuring it not to listen on the network. CCE-26803-7 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.so $InputTCPServerRun 514 AU-9 If the system needs to act as a log server, this ensures that it can receive messages over a reliable TCP connection. CCE-27235-1 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.so $InputUDPServerRun 514 AU-9 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. CCE-27236-9 Edit the file /etc/logrotate.d/syslog. Find the first line, which should look like this (wrapped for clarity): /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler \ /var/log/boot.log /var/log/cron { Edit this line so that it contains a one-space-separated listing of each log file referenced in /etc/rsyslog.conf. All logs in use on a system must be rotated regularly, or the log files will consume disk space over time, eventually interfering with system operation. The file /etc/logrotate.d/syslog is the configuration file used by the logrotate program to maintain all log files written by syslog. By default, it rotates logs weekly and stores four archival copies of each log. These settings can be modified by editing /etc/logrotate.conf, but the defaults are sufficient for purposes of this guide. Note that logrotate is run nightly by the cron job /etc/cron.daily/logrotate. If particularly active logs need to be rotated more often than once a day, some other mechanism must be used. The logrotate service should be enabled. AU-9 366 Log files that are not properly rotated run the risk of growing so large that they fill up the /var/log partition. Valuable logging information could be lost if the /var/log partition becomes full. CCE-27014-0 Run the following command to determine the current status of the logrotate service: # service logrotate status If the service is enabled, it should return the following: logrotate is running... Is this machine the central log server? If so, edit the file /etc/logwatch/conf/logwatch.conf as shown below. On a central logserver, you want Logwatch to summarize all syslog entries, including those which did not originate on the logserver itself. The HostLimit setting tells Logwatch to report on all hosts, not just the one on which it is running. HostLimit = no CCE-27197-3 If SplitHosts is set, Logwatch will separate entries by hostname. This makes the report longer but significantly more usable. If it is not set, then Logwatch will not report which host generated a given log entry, and that information is almost always necessary SplitHosts = yes CCE-27069-4 Does your site have a central logserver which has been configured to report on logs received from all systems? If so: # rm /etc/cron.daily/0logwatch If no logserver exists, it will be necessary for each machine to run Logwatch individually. Using a central logserver provides the security and reliability benefits discussed earlier, and also makes monitoring logs easier and less time-intensive for administrators. The 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, auditd has modest disk space requirements, and should not noticeably impact system performance. 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 http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages.html 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) msg=audit(1226874073.147:96)The number in parentheses is the unformatted time stamp (Epoch time) for the event, which can be converted to standard time by using the date command. { getattr }The item in braces indicates the permission that was denied. getattr indicates the source process was trying to read the target file's status information. This occurs before reading files. This action is denied due to the file being accessed having the wrong label. Commonly seen permissions include getattr, read, and write.comm="httpd"The executable that launched the process. The full path of the executable is found in the exe= section of the system call (SYSCALL) message, which in this case, is exe="/usr/sbin/httpd". path="/var/www/html/file1"The path to the object (target) the process attempted to access. scontext="unconfined_u:system_r:httpd_t:s0"The SELinux context of the process that attempted the denied action. In this case, it is the SELinux context of the Apache HTTP Server, which is running in the httpd_t domain. tcontext="unconfined_u:object_r:samba_share_t:s0"The SELinux context of the object (target) the process attempted to access. In this case, it is the SELinux context of file1. Note: the samba_share_t type is not accessible to processes running in the httpd_t domain. From the system call (SYSCALL) message, two items are of interest: success=no: indicates whether the denial (AVC) was enforced or not. success=no indicates the system call was not successful (SELinux denied access). success=yes indicates the system call was successful - this can be seen for permissive domains or unconfined domains, such as initrc_t and kernel_t. exe="/usr/sbin/httpd": the full path to the executable that launched the process, which in this case, is exe="/usr/sbin/httpd". The auditd service is an essential userspace component of the Linux Auditing System, as it is responsible for writing audit records to disk. The auditd service can be enabled with the following command: # chkconfig --level 2345 auditd on 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 DS 20121024 Ensuring the auditd service is active ensures audit records generated by the kernel can be written to disk, or that appropriate actions will be taken if other obstacles exist. CCE-27058-7 Run the following command to determine the current status of the auditd service: # service auditd status If the service is enabled, it should return the following: auditd is running... To ensure all processes can be audited, even those which start prior to the audit daemon, add the argument audit=1 to the kernel line in /etc/grub.conf, in the manner below: kernel /vmlinuz-version ro vga=ext root=/dev/VolGroup00/LogVol00 rhgb quiet audit=1 AC-17(1) AU-1(b) AU-2(a) AU-2(c) AU-2(d) AU-10 IR-5 1464 130 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. CCE-26785-6 Inspect the kernel boot arguments (which follow the word kernel) in /etc/grub.conf. If they include audit=1, then auditing is enabled at boot time. The audit system writes data to /var/log/audit/audit.log. By default, auditd rotates 5 logs by size (6MB), retaining a maximum of 30MB of data in total, and refuses to write entries when the disk is too full. This minimizes the risk of audit data filling its partition and impacting other services. This also minimizes the risk of the audit daemon temporarily disabling the system if it cannot write audit log (which it can be configured to do). For a busy system or a system which is thoroughly auditing system activity, the default settings for data retention may be insufficient. The log file size needed will depend heavily on what types of events are being audited. First configure auditing to log all the events of interest. Then monitor the log size manually for awhile to determine what file size will allow you to keep the required data for the correct time period. Using a dedicated partition for /var/log/audit prevents the auditd logs from disrupting system functionality if they fill, and, more importantly, prevents other activity in /var from filling the partition and stopping the audit trail. (The audit logs are size-limited and therefore unlikely to grow without bound unless configured to do so.) Some machines may have requirements that no actions occur which cannot be audited. If this is the case, then auditd can be configured to halt the machine if it runs out of space. Note: Since older logs are rotated, configuring auditd this way does not prevent older logs from being rotated away before they can be viewed. If your system is configured to halt when logging cannot be performed, make sure this can never happen under normal circumstances! Ensure that /var/log/audit is on its own partition, and that this partition is larger than the maximum amount of data auditd will retain normally. AU-11 138 The setting for num_logs in /etc/audit/auditd.conf 5 5 4 3 2 1 0 The setting for max_log_size in /etc/audit/auditd.conf 6 20 10 6 5 1 The setting for max_log_file_action in /etc/audit/auditd.conf rotate ignore syslog suspend rotate keep_logs The setting for space_left_action in /etc/audit/auditd.conf email ignore syslog email exec suspend single halt The setting for space_left_action in /etc/audit/auditd.conf single ignore syslog email exec suspend single halt The setting for action_mail_acct in /etc/audit/auditd.conf root root admin Determine how many log files auditd should retain when it rotates logs. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting NUMLOGS with the correct value: num_logs = NUMLOGS Set the value to 5 for general-purpose systems. Note that values less than 2 result in no log rotation. AU-1(b) AU-11 IR-5 DS 20121024 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. Inspect /etc/audit/auditd.conf and locate the following line to determine how many logs the system is configured to retain after rotation: # grep num_logs /etc/audit/auditd.conf num_logs = 5 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 for STOREMB: max_log_file = STOREMB Set the value to 6 (MB) or higher for general-purpose systems. Larger values, of course, support retention of even more audit data. AU-1(b) AU-11 IR-5 DS 20121024 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. Inspect /etc/audit/auditd.conf and locate the following line to determine how much data the system will retain in each audit log file: # grep max_log_file /etc/audit/auditd.conf max_log_file = 6 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 = ACTION Possible values for ACTION are described in the auditd.conf man page. These include: ignoresyslogsuspendrotatekeep_logs Set the ACTION to rotate to ensure log rotation occurs. This is the default. The setting is case-insensitive. AU-1(b) AU-4 AU-11 IR-5 DS 20121024 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. CCE-27237-7 Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured to rotate logs when they reach their maximum size: # grep max_log_file_action /etc/audit/auditd.conf max_log_file_action rotate 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 = ACTION Possible values for ACTION are described in the auditd.conf man page. These include: ignoresyslogemailexecsuspendsinglehalt Set this to 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. AU-1(b) AU-4 AU-5(b) IR-5 140 143 DS 20121024 Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption. CCE-27238-5 Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured to email the administrator when disk space is starting to run low: # grep space_left_action /etc/audit/auditd.conf space_left_action Acceptable values are email, suspend, single, and halt. The auditd service can be configured to take an action when disk space is running low but prior to running out of space completely. Edit the file /etc/audit/auditd.conf. Add or modify the following line, substituting ACTION appropriately: admin_space_left_action = ACTION Possible values for ACTION are described in the auditd.conf man page. These include: ignoresyslogemailexecsuspendsinglehalt Set 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. AU-1(b) AU-4 AU-5(b) IR-5 140 1343 DS 20121024 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. CCE-27239-3 Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured to either suspend, switch to single user mode, or halt when disk space has run low: admin_space_left_action single The auditd service can be configured to send email to a designated account in certain situations. Add or correct the following line in /etc/audit/auditd.conf to ensure that administrators are notified via email for those situations: action_mail_acct = root AU-1(b) AU-4 AU-5(a) IR-5 139 144 Email sent to the root account is typically aliased to the administrators of the system, who can take appropriate action. CCE-27241-9 Inspect /etc/audit/auditd.conf and locate the following line to determine if the system is configured to send email to an account when it needs to notify an administrator: action_mail_acct = root To configure the auditd service to use the audispd plugin, set the active line in /etc/audisp/plugins.d/syslog.conf to yes. Restart the auditdservice: # service auditd restart AU-1(b) AU-3(2) IR-5 136 The auditd service does not include the ability to send audit records to a centralized server for management directly. It does, however, include an audit event multiplexor plugin (audispd) to pass audit records to the local syslog server To verify the audispd plugin is active, run the following command: # grep active /etc/audisp/plugins.d/syslog.conf If the plugin is active, the output will show yes. The auditd program can perform comprehensive monitoring of system activity. This section describes recommended configuration settings for comprehensive auditing, but a full description of the auditing system's capabilities is beyond the scope of this guide. The mailing list linux-audit@redhat.com exists to facilitate community discussion of the auditing system. The audit subsystem supports extensive collection of events, including: Tracing of arbitrary system calls (identified by name or number) on entry or exit.Filtering by PID, UID, call success, system call argument (with some limitations), etc.Monitoring of specific files for modifications to the file's contents or metadata. 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: # service auditd restart 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. All changes to the system time should be audited. On a 32-bit system, add the following to /etc/audit/audit.rules: # audit_time_rules -a always,exit -F arch=b32 -S adjtimex -k audit_time_rules On a 64-bit system, add the following to /etc/audit/audit.rules: # audit_time_rules -a always,exit -F arch=b64 -S adjtimex -k audit_time_rules The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k audit_time_rules AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 1487 169 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. CCE-26242-8 To determine if the system is configured to audit calls to the adjtimex system call, run the following command: # auditctl -l | grep syscall | grep adjtimex If the system is configured to audit this activity, it will return a line. On a 32-bit system, add the following to /etc/audit/audit.rules: # audit_time_rules -a always,exit -F arch=b32 -S settimeofday -k audit_time_rules On a 64-bit system, add the following to /etc/audit/audit.rules: # audit_time_rules -a always,exit -F arch=b64 -S settimeofday -k audit_time_rules The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k audit_time_rules AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 1487 169 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. CCE-27203-9 To determine if the system is configured to audit calls to the settimeofday system call, run the following command: # auditctl -l | grep syscall | grep settimeofday If the system is configured to audit this activity, it will return a line. On a 32-bit system, add the following to /etc/audit/audit.rules: # audit_time_rules -a always,exit -F arch=b32 -S stime -k audit_time_rules On a 64-bit system, the "-S time" is not necessary. The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k audit_time_rules AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 1487 169 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. CCE-27169-2 To determine if the system is configured to audit calls to the stime system call, run the following command: # auditctl -l | grep syscall | grep stime If the system is configured to audit this activity, it will return a line. On a 32-bit system, add the following to /etc/audit/audit.rules: # audit_time_rules -a always,exit -F arch=b32 -S clock_settime -k audit_time_rules On a 64-bit system, add the following to /etc/audit/audit.rules: # audit_time_rules -a always,exit -F arch=b64 -S clock_settime -k audit_time_rules The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport. Multiple system calls can be defined on the same line to save space if desired, but is not required. See an example of multiple combined syscalls: -a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k audit_time_rules AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 1487 169 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. CCE-27170-0 To determine if the system is configured to audit calls to the clock_settime system call, run the following command: # auditctl -l | grep syscall | grep clock_settime If the system is configured to audit this activity, it will return a line. Add the following to /etc/audit/audit.rules: -w /etc/localtime -p wa -k audit_time_rules The -k option allows for the specification of a key in string form that can be used for better reporting capability through ausearch and aureport and should always be used. AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 1487 169 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. CCE-27172-6 To determine if the system is configured to audit attempts to alter time via the /etc/localtime file, run the following command: # auditctl -l | grep "watch=/etc/localtime" If the system is configured to audit this activity, it will return a line. Add the following to /etc/audit/audit.rules, in order to capture events that modify account changes: # audit_account_changes -w /etc/group -p wa -k audit_account_changes -w /etc/passwd -p wa -k audit_account_changes -w /etc/gshadow -p wa -k audit_account_changes -w /etc/shadow -p wa -k audit_account_changes -w /etc/security/opasswd -p wa -k audit_account_changes AC-2(4) AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 18 1403 1404 1405 1684 1683 1685 1686 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. CCE-26664-3 To determine if the system is configured to audit account changes, run the following command: auditctl -l | egrep '(/etc/passwd|/etc/shadow|/etc/group|/etc/gshadow|/etc/security/opasswd)' If the system is configured to watch for account changes, lines should be returned for each file specified (and with perm=wa for each). Add the following to /etc/audit/audit.rules, setting ARCH to either b32 or b64 as appropriate for your system: # audit_network_modifications -a exit,always -F arch=ARCH -S sethostname -S setdomainname -k audit_network_modifications -w /etc/issue -p wa -k audit_network_modifications -w /etc/issue.net -p wa -k audit_network_modifications -w /etc/hosts -p wa -k audit_network_modifications -w /etc/sysconfig/network -p wa -k audit_network_modifications AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 The network environment should not be modified by anything other than administrator action. Any change to network parameters should be audited. CCE-26648-6 To determine if the system is configured to audit changes to its network configuration, run the following command: auditctl -l | egrep '(/etc/issue|/etc/issue.net|/etc/hosts|/etc/sysconfig/network)' If the system is configured to watch for network configuration changes, a line should be returned for each file specified (and perm=wa should be indicated for each). Change the mode of the audit log files with the following command: # chmod 0640 audit_file AC-6 AU-1(b) AU-9 IR-5 166 DS 20121024 If users can write to audit logs, audit trails can be modified or destroyed. CCE-27243-5 Run the following command to check the mode of the system audit logs: ls -l /var/log/audit Audit logs must be mode 0640 or less permissive. To properly set the owner of /var/log, run the command: # chown root /var/log AC-6 AU-1(b) AU-9 IR-5 166 DS 20121024 Failure to give ownership of the audit log files to root allows the designated owner, and unauthorized users, potential access to sensitive information. CCE-27244-3 To check the ownership of /var/log, run the command: $ ls -lL /var/log If properly configured, the output should indicate the following owner: root Add the following to /etc/audit/audit.rules: -w /etc/selinux/ -p wa -k MAC-policy AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 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. CCE-26657-7 To determine if the system is configured to audit changes to its SELinux configuration files, run the following command: # auditctl -l | grep "dir=/etc/selinux" If the system is configured to watch for changes to its SELinux configuration, a line should be returned (including perm=wa indicating permissions that are watched). At 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 /etc/audit/audit.rules: -a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat \ -F auid>=500 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S chown -S fchown -S fchownat \ -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S setxattr -S lsetxattr \ -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr \ -F auid>=500 -F auid!=4294967295 -k perm_mod If your system is 64 bit then these lines should be duplicated and the arch=b32 replaced with arch=b64 as follows: -a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat \ -F auid>=500 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S chown -S fchown -S fchownat \ -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S setxattr -S lsetxattr \ -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr \ -F auid>=500 -F auid!=4294967295 -k perm_mod 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. At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b32 -S chmod -F auid>=500 -F auid!=4294967295 \ -k perm_mod If the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S chmod -F auid>=500 -F auid!=4294967295 \ -k perm_mod 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. AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 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. CCE-26280-8 To determine if the system is configured to audit calls to the chmod system call, run the following command: # auditctl -l | grep syscall | grep chmod If the system is configured to audit this activity, it will return a line. At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b32 -S chown -F auid>=500 -F auid!=4294967295 \ -k perm_mod If the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S chown -F auid>=500 -F auid!=4294967295 \ -k perm_mod 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. AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 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. CCE-27173-4 To determine if the system is configured to audit calls to the chown system call, run the following command: # auditctl -l | grep syscall | grep chown If the system is configured to audit this activity, it will return a line. At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b32 -S fchmod -F auid>=500 -F auid!=4294967295 \ -k perm_mod If the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S fchmod -F auid>=500 -F auid!=4294967295 \ -k perm_mod 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. AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 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. CCE-27174-2 To determine if the system is configured to audit calls to the fchmod system call, run the following command: # auditctl -l | grep syscall | grep fchmod If the system is configured to audit this activity, it will return a line. At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b32 -S fchmodat -F auid>=500 -F auid!=4294967295 \ -k perm_mod If the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S fchmodat -F auid>=500 -F auid!=4294967295 \ -k perm_mod 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. AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 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. CCE-27175-9 To determine if the system is configured to audit calls to the fchmodat system call, run the following command: # auditctl -l | grep syscall | grep fchmodat If the system is configured to audit this activity, it will return a line. At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b32 -S fchown -F auid>=500 -F auid!=4294967295 \ -k perm_mod If the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S fchown -F auid>=500 -F auid!=4294967295 \ -k perm_mod 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. AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 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. CCE-27177-5 To determine if the system is configured to audit calls to the fchown system call, run the following command: # auditctl -l | grep syscall | grep fchown If the system is configured to audit this activity, it will return a line. At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b32 -S fchownat -F auid>=500 -F auid!=4294967295 \ -k perm_mod If the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S fchownat -F auid>=500 -F auid!=4294967295 \ -k perm_mod 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. AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 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. CCE-27178-3 To determine if the system is configured to audit calls to the fchownat system call, run the following command: # auditctl -l | grep syscall | grep fchownat If the system is configured to audit this activity, it will return a line. At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b32 -S fremovexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod If the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S fremovexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod 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. AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 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. CCE-27179-1 To determine if the system is configured to audit calls to the fremovexattr system call, run the following command: # auditctl -l | grep syscall | grep fremovexattr If the system is configured to audit this activity, it will return a line. At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b32 -S fsetxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod If the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S fsetxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod 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. AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 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. CCE-27180-9 To determine if the system is configured to audit calls to the fsetxattr system call, run the following command: # auditctl -l | grep syscall | grep fsetxattr If the system is configured to audit this activity, it will return a line. At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b32 -S lchown -F auid>=500 -F auid!=4294967295 \ -k perm_mod If the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S lchown -F auid>=500 -F auid!=4294967295 \ -k perm_mod 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. AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 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. CCE-27181-7 To determine if the system is configured to audit calls to the lchown system call, run the following command: # auditctl -l | grep syscall | grep lchown If the system is configured to audit this activity, it will return a line. At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b32 -S lremovexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod If the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S lremovexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod 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. AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 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. CCE-27182-5 To determine if the system is configured to audit calls to the lremovexattr system call, run the following command: # auditctl -l | grep syscall | grep lremovexattr If the system is configured to audit this activity, it will return a line. At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b32 -S lsetxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod If the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S lsetxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod 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. AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 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. CCE-27183-3 To determine if the system is configured to audit calls to the lsetxattr system call, run the following command: # auditctl -l | grep syscall | grep lsetxattr If the system is configured to audit this activity, it will return a line. At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b32 -S removexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod If the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S removexattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod 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. AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 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. CCE-27184-1 To determine if the system is configured to audit calls to the removexattr system call, run the following command: # auditctl -l | grep syscall | grep removexattr If the system is configured to audit this activity, it will return a line. At a minimum the audit system should collect file permission changes for all users and root. Add the following to /etc/audit/audit.rules: -a always,exit -F arch=b32 -S setxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod If the system is 64 bit then also add the following: -a always,exit -F arch=b64 -S setxattr -F auid>=500 -F auid!=4294967295 \ -k perm_mod 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. AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 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. CCE-27185-8 To determine if the system is configured to audit calls to the setxattr system call, run the following command: # auditctl -l | grep syscall | grep setxattr If the system is configured to audit this activity, it will return a line. The audit system already collects login info for all users and root. To watch for attempted manual edits of files involved in storing logon events, add the following to /etc/audit/audit.rules: -w /var/log/faillog -p wa -k logins -w /var/log/lastlog -p wa -k logins AC-17(7) AU-1(b) IR-5 Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. CCE-26691-6 The audit system already collects process information for all users and root. To watch for attempted manual edits of files involved in storing such process information, add the following to /etc/audit/audit.rules: -w /var/run/utmp -p wa -k session -w /var/log/btmp -p wa -k session -w /var/log/wtmp -p wa -k session AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion. CCE-26610-6 At a minimum the audit system should collect unauthorized file accesses for all users and root. Add the following to /etc/audit/audit.rules, setting ARCH to either b32 or b64 as appropriate for your system: -a always,exit -F arch=ARCH -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EACCES -F auid>=500 -F auid!=4294967295 -k access -a always,exit -F arch=ARCH -S creat -S open -S openat -S truncate \ -S ftruncate -F exit=-EPERM -F auid>=500 -F auid!=4294967295 -k access AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 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. CCE-26712-0 To verify that the audit system collects unauthorized file accesses, run the following commands: # grep EACCES /etc/audit/audit.rules # grep EPERM /etc/audit/audit.rules At a minimum the audit system should collect the execution of privileged commands for all users and root. To find the relevant setuid programs: # find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null Then, for each setuid program on the system, add a line of the following form to /etc/audit/audit.rules, where SETUID_PROG_PATH is the full path to each setuid program in the list: -a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) AU-2(4) IR-5 40 DS 20121024 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. CCE-26457-2 To verify that auditing of privileged command use is configured, run the following command to find relevant setuid programs: # find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null Run the following command to verify entries in the audit rules for all programs found with the previous command: # grep path /etc/audit/audit.rules It should be the case that all relevant setuid programs have a line in the audit rules. At a minimum the audit system should collect media exportation events for all users and root. Add the following to /etc/audit/audit.rules, setting ARCH to either b32 or b64 as appropriate for your system: -a always,exit -F arch=ARCH -S mount -F auid>=500 -F auid!=4294967295 -k export AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 DS 20121024 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. CCE-26573-6 To verify that auditing is configured for all media exportation events, run the following command: # auditctl -l | grep syscall | grep mount At a minimum the audit system should collect file deletion events for all users and root. Add the following to /etc/audit/audit.rules, setting ARCH to either b32 or b64 as appropriate for your system: -a always,exit -F arch=ARCH -S unlink -S unlinkat -S rename -S renameat \ -F auid>=500 -F auid!=4294967295 -k delete AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 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. CCE-26651-0 To determine if the system is configured to audit calls to the unlink system call, run the following command: # auditctl -l | grep syscall | grep unlink If the system is configured to audit this activity, it will return a line. To determine if the system is configured to audit calls to the rename system call, run the following command: # auditctl -l | grep syscall | grep rename If the system is configured to audit this activity, it will return a line. At a minimum the audit system should collect administrator actions for all users and root. Add the following to /etc/audit/audit.rules: -w /etc/sudoers -p wa -k actions AC-2(7)(b) AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 DS 20121024 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. CCE-26662-7 To verify that auditing is configured for system administrator actions, run the following command: # auditctl -l | grep "watch=/etc/sudoers" Add the following to /etc/audit/audit.rules in order to capture kernel module loading and unloading events, setting ARCH to either b32 or b64 as appropriate for your system: -w /sbin/insmod -p x -k modules -w /sbin/rmmod -p x -k modules -w /sbin/modprobe -p x -k modules -a always,exit -F arch=ARCH -S init_module -S delete_module -k modules AC-17(7) AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 126 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. CCE-26611-4 To determine if the system is configured to audit calls to the init_module system call, run the following command: # auditctl -l | grep syscall | grep init_module If the system is configured to audit this activity, it will return a line. To determine if the system is configured to audit calls to the delete_module system call, run the following command: # auditctl -l | grep syscall | grep delete_module If the system is configured to audit this activity, it will return a line. Add the following to /etc/audit/audit.rules in order to make the configuration immutable: -e 2 With this setting, a reboot will be required to change any audit rules. AC-6 AU-1(b) AU-2(a) AU-2(c) AU-2(d) IR-5 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 CCE-26612-2 The best protection against vulnerable software is running less software. This section describes how to review the software which Red Hat Enterprise Linux 6 installs on a system and disable software which is not needed. It then enumerates the software packages installed on a default RHEL 6 system and provides guidance about which ones can be safely disabled. RHEL 6 provides a convenient minimal install option that essentially installs the bare necessities for a functional system. When building RHEL 6 servers, it is highly recommended to select the minimal packages and then build up the system from there. This 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 RHEL 6 by default. Organizations which are running these services should switch to more secure equivalents as soon as possible. If it remains absolutely necessary to run one of these services for legacy reasons, care should be taken to restrict the service as much as possible, for instance by configuring host firewall software such as iptables to restrict access to the vulnerable service to only those remote hosts which have a known need to use it. The xinetd service acts as a dedicated listener for some network services (mostly, obsolete ones) and can be used to provide access controls and perform some logging. It has been largely obsoleted by other features, and it is not installed by default. The older Inetd service is not even available as part of RHEL 6. The xinetd service can be disabled with the following command: # chkconfig xinetd off AC-17(8) CM-7 305 DS 20121026 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. CCE-27046-2 If network services are using the xinetd service, this is not applicable. To check that the xinetd service is disabled in system boot configuration, run the following command: # chkconfig xinetd --list Output should indicate the xinetd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig xinetd --list xinetd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify xinetd is disabled through current runtime configuration: # service xinetd status If the service is disabled the command will return the following output: xinetd is stopped The xinetd package can be uninstalled with the following command: # yum erase xinetd AC-17(8) CM-7 305 DS 20121026 Removing the xinetd package decreases the risk of the xinetd service's accidental (or intentional) activation. CCE-27005-8 if rpm -qa | grep -q xinetd; then yum -y remove xinetd fi If network services are using the xinetd service, this is not applicable. Run the following command to determine if the xinetd package is installed: # rpm -q xinetd The 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. The telnet service can be disabled with the following command: # chkconfig telnet off AC-17(8) CM-7 IA-5(1)(c) 68 1436 197 877 888 DS 20121026 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. CCE-26836-7 To check that the telnet service is disabled in system boot configuration, run the following command: # chkconfig telnet --list Output should indicate the telnet service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig telnet --list telnet 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify telnet is disabled through current runtime configuration: # service telnet status If the service is disabled the command will return the following output: telnet is stopped The telnet-server package can be uninstalled with the following command: # yum erase telnet-server AC-17(8) CM-7 305 381 DS 20121026 Removing the telnet-server package decreases the risk of the telnet service's accidental (or intentional) activation. CCE-27073-6 if rpm -qa | grep -q telnet-server; then yum -y remove telnet-server fi Run the following command to determine if the telnet-server package is installed: # rpm -q telnet-server The Berkeley r-commands are legacy services which allow cleartext remote access and have an insecure trust model. The rsh-server package can be uninstalled with the following command: # yum erase rsh-server AC-17(8) CM-7 305 381 DS 20121026 The rsh-server package provides several obsolete and insecure network services. Removing it decreases the risk of those services' accidental (or intentional) activation. CCE-27062-9 Run the following command to determine if the rsh-server package is installed: # rpm -q rsh-server The rexec service, which is available with the rsh-server package and runs as a service through xinetd, should be disabled. The rexec service can be disabled with the following command: # chkconfig rexec off AC-17(8) CM-7 68 1436 DS 20121026 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. CCE-27208-8 To check that the rexec service is disabled in system boot configuration, run the following command: # chkconfig rexec --list Output should indicate the rexec service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig rexec --list rexec 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify rexec is disabled through current runtime configuration: # service rexec status If the service is disabled the command will return the following output: rexec is stopped The rsh service, which is available with the rsh-server package and runs as a service through xinetd, should be disabled. The rsh service can be disabled with the following command: # chkconfig rsh off AC-17(8) CM-7 IA-5(1)(c) 68 1436 DS 20121026 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. CCE-26994-4 To check that the rsh service is disabled in system boot configuration, run the following command: # chkconfig rsh --list Output should indicate the rsh service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig rsh --list rsh 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify rsh is disabled through current runtime configuration: # service rsh status If the service is disabled the command will return the following output: rsh is stopped The rlogin service, which is available with the rsh-server package and runs as a service through xinetd, should be disabled. The rlogin service can be disabled with the following command: # chkconfig rlogin off AC-17(8) CM-7 IA-5(1)(c) 1436 DS 20121026 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. CCE-26865-6 To check that the rlogin service is disabled in system boot configuration, run the following command: # chkconfig rlogin --list Output should indicate the rlogin service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig rlogin --list rlogin 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify rlogin is disabled through current runtime configuration: # service rlogin status If the service is disabled the command will return the following output: rlogin is stopped 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: # rm /etc/hosts.equiv $ rm ~/.rhosts AC-17(8) CM-7 1436 DS 20121026 Trust files are convenient, but when used in conjunction with the R-services, they can allow unauthenticated access to a system. CCE-27270-8 The existence of the file /etc/hosts.equiv or a file named .rhosts inside a user home directory indicates the presence of an Rsh trust relationship. The 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. The ypserv package can be uninstalled with the following command: # yum erase ypserv AC-17(8) CM-7 305 381 DS 20121026 Removing the ypserv package decreases the risk of the accidental (or intentional) activation of NIS or NIS+ services. CCE-27079-3 if rpm -qa | grep -q ypserv; then yum -y remove ypserv fi Run the following command to determine if the ypserv package is installed: # rpm -q ypserv The ypbind service, which allows the system to act as a client in a NIS or NIS+ domain, should be disabled. The ypbind service can be disabled with the following command: # chkconfig ypbind off AC-17(8) CM-7 305 DS 20121026 Disabling the ypbind service ensures the system is not acting as a client in a NIS or NIS+ domain. CCE-26894-6 To check that the ypbind service is disabled in system boot configuration, run the following command: # chkconfig ypbind --list Output should indicate the ypbind service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig ypbind --list ypbind 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify ypbind is disabled through current runtime configuration: # service ypbind status If the service is disabled the command will return the following output: ypbind is stopped TFTP 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. The tftp service should be disabled. The tftp service can be disabled with the following command: # chkconfig tftp off AC-17(8) CM-7 1436 DS 20121026 Disabling the tftp service ensures the system is not acting as a tftp server, which does not provide encryption or authentication. CCE-27055-3 To check that the tftp service is disabled in system boot configuration, run the following command: # chkconfig tftp --list Output should indicate the tftp service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig tftp --list tftp 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify tftp is disabled through current runtime configuration: # service tftp status If the service is disabled the command will return the following output: tftp is stopped The tftp-server package can be removed with the following command: # yum erase tftp-server AC-17(8) CM-7 305 DS 20121026 Removing the tftp-server package decreases the risk of the accidental (or intentional) activation of tftp services. CCE-26946-4 Run the following command to determine if the tftp-server package is installed: # rpm -q tftp-server If running the tftp service is necessary, it should be configured to change its root directory at startup. To do so, ensure /etc/xinetd.d/tftp includes -s as a command line argument, as shown in the following example (which is also the default): server_args = -s /var/lib/tftpboot AC-17(8) CM-7 366 Using the -s option causes the TFTP service to only serve files from the given directory. Serving files from an intentionally-specified directory reduces the risk of sharing files which should remain private. CCE-27272-4 If TFTP is not installed, this is not applicable. To determine if TFTP is installed, run the following command: # rpm -qa | grep tftp Verify tftp is configured by with the -s option by running the following command: grep "server_args" /etc/xinetd.d/tftp The output should indicate the server_args variable is configured with the -s flag, matching the example below: # grep "server_args" /etc/xinetd.d/tftp server_args = -s /var/lib/tftpboot This section addresses the base services that are installed on a RHEL 6 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. The Automatic Bug Reporting Tool (abrtd) daemon collects and reports crash data when an application crash is detected. Using a variety of plugins, abrtd can email crash reports to system administrators, log crash reports to files, or forward crash reports to a centralized issue tracking system such as RHTSupport. The abrtd service can be disabled with the following command: # chkconfig abrtd off AC-17(8) CM-7 381 Mishandling crash data could expose sensitive information about vulnerabilities in software executing on the local machine, as well as sensitive information from within a process's address space or registers. CCE-27247-6 To check that the abrtd service is disabled in system boot configuration, run the following command: # chkconfig abrtd --list Output should indicate the abrtd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig abrtd --list abrtd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify abrtd is disabled through current runtime configuration: # service abrtd status If the service is disabled the command will return the following output: abrtd is stopped The Advanced Configuration and Power Interface Daemon (acpid) dispatches ACPI events (such as power/reset button depressed) to userspace programs. The acpid service can be disabled with the following command: # chkconfig acpid off CM-7 ACPI support is highly desirable for systems in some network roles, such as laptops or desktops. For other systems, such as servers, it may permit accidental or trivially achievable denial of service situations and disabling it is appropriate. CCE-27061-1 To check that the acpid service is disabled in system boot configuration, run the following command: # chkconfig acpid --list Output should indicate the acpid service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig acpid --list acpid 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify acpid is disabled through current runtime configuration: # service acpid status If the service is disabled the command will return the following output: acpid is stopped Certmonger is a D-Bus based service that attempts to simplify interaction with certifying authorities on networks which use public-key infrastructure. It is often combined with Red Hat's IPA (Identity Policy Audit) security information management solution to aid in the management of certificates. The certmonger service can be disabled with the following command: # chkconfig certmonger off CM-7 The services provided by certmonger may be essential for systems fulfilling some roles a PKI infrastructure, but its functionality is not necessary for many other use cases. CCE-27267-4 To check that the certmonger service is disabled in system boot configuration, run the following command: # chkconfig certmonger --list Output should indicate the certmonger service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig certmonger --list certmonger 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify certmonger is disabled through current runtime configuration: # service certmonger status If the service is disabled the command will return the following output: certmonger is stopped Control groups allow an administrator to allocate system resources (such as CPU, memory, network bandwidth, etc) among a defined group (or groups) of processes executing on a system. The cgconfig daemon starts at boot and establishes the predefined control groups. The cgconfig service can be disabled with the following command: # chkconfig cgconfig off CM-7 Unless control groups are used to manage system resources, running the cgconfig service is not necessary. CCE-27250-0 To check that the cgconfig service is disabled in system boot configuration, run the following command: # chkconfig cgconfig --list Output should indicate the cgconfig service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig cgconfig --list cgconfig 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify cgconfig is disabled through current runtime configuration: # service cgconfig status If the service is disabled the command will return the following output: cgconfig is stopped The cgred service moves tasks into control groups according to parameters set in the /etc/cgrules.conf configuration file. The cgred service can be disabled with the following command: # chkconfig cgred off CM-7 Unless control groups are used to manage system resources, running the cgred service service is not necessary. CCE-27252-6 To check that the cgred service is disabled in system boot configuration, run the following command: # chkconfig cgred --list Output should indicate the cgred service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig cgred --list cgred 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify cgred is disabled through current runtime configuration: # service cgred status If the service is disabled the command will return the following output: cgred is stopped The cpuspeed service can adjust the clock speed of supported CPUs based upon the current processing load thereby conserving power and reducing heat. The cpuspeed service can be disabled with the following command: # chkconfig cpuspeed off CM-7 The cpuspeed service is only necessary if adjusting the CPU clock speed provides benefit. Traditionally this has included laptops (to enhance battery life), but may also apply to server or desktop environments where conserving power is highly desirable or necessary. CCE-26973-8 To check that the cpuspeed service is disabled in system boot configuration, run the following command: # chkconfig cpuspeed --list Output should indicate the cpuspeed service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig cpuspeed --list cpuspeed 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify cpuspeed is disabled through current runtime configuration: # service cpuspeed status If the service is disabled the command will return the following output: cpuspeed is stopped The Hardware Abstraction Layer Daemon (haldaemon) collects and maintains information about the system's hardware configuration. This service is required on a workstation running a desktop environment, and may be necessary on any system which deals with removable media or devices. The haldaemon service can be disabled with the following command: # chkconfig haldaemon off CM-7 The haldaemon provides essential functionality on systems that use removable media or devices, but can be disabled for systems that do not require these. CCE-27086-8 To check that the haldaemon service is disabled in system boot configuration, run the following command: # chkconfig haldaemon --list Output should indicate the haldaemon service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig haldaemon --list haldaemon 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify haldaemon is disabled through current runtime configuration: # service haldaemon status If the service is disabled the command will return the following output: haldaemon is stopped The irqbalance service optimizes the balance between power savings and performance through distribution of hardware interrupts across multiple processors. The irqbalance service can be enabled with the following command: # chkconfig --level 2345 irqbalance on CM-7 In an environment with multiple processors (now common), the irqbalance service provides potential speedups for handling interrupt requests. CCE-26990-2 To check that the irqbalance service is disabled in system boot configuration, run the following command: # chkconfig irqbalance --list Output should indicate the irqbalance service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig irqbalance --list irqbalance 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify irqbalance is disabled through current runtime configuration: # service irqbalance status If the service is disabled the command will return the following output: irqbalance is stopped The kdump service provides a kernel crash dump analyzer. It uses the kexec system call to boot a secondary kernel ("capture" kernel) following a system crash, which can load information from the crashed kernel for analysis. The kdump service can be disabled with the following command: # chkconfig kdump off AC-17(8) CM-7 Unless the system is used for kernel development or testing, there is little need to run the kdump service. CCE-26850-8 To check that the kdump service is disabled in system boot configuration, run the following command: # chkconfig kdump --list Output should indicate the kdump service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig kdump --list kdump 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify kdump is disabled through current runtime configuration: # service kdump status If the service is disabled the command will return the following output: kdump is stopped The mdmonitor service is used for monitoring a software RAID (hardware RAID setups do not use this service). The mdmonitor service can be disabled with the following command: # chkconfig mdmonitor off CM-7 If software RAID monitoring is not required (and it is uncommon), there is no need to run the service. CCE-27193-2 To check that the mdmonitor service is disabled in system boot configuration, run the following command: # chkconfig mdmonitor --list Output should indicate the mdmonitor service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig mdmonitor --list mdmonitor 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify mdmonitor is disabled through current runtime configuration: # service mdmonitor status If the service is disabled the command will return the following output: mdmonitor is stopped D-Bus provides an IPC mechanism used by a growing list of programs, such as those used for Gnome, Bluetooth, and Avahi. Due to these dependencies, disabling D-Bus may not be practical for many systems. The messagebus service can be disabled with the following command: # chkconfig messagebus off CM-7 If no services which require D-Bus are needed, then it can be disabled. As a broker for IPC between processes of different privilege levels, it could be a target for attack. However, disabling D-Bus is likely to be impractical for any system which needs to provide a graphical login session. CCE-26913-4 To check that the messagebus service is disabled in system boot configuration, run the following command: # chkconfig messagebus --list Output should indicate the messagebus service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig messagebus --list messagebus 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify messagebus is disabled through current runtime configuration: # service messagebus status If the service is disabled the command will return the following output: messagebus is stopped The netconsole service is responsible for loading the netconsole kernel module, which logs kernel printk messages over UDP to a syslog server. This allows debugging of problems where disk logging fails and serial consoles are impractical. The netconsole service can be disabled with the following command: # chkconfig netconsole off AC-17(8) CM-7 381 The netconsole service is not necessary unless there is a need to debug kernel panics, which is not common. CCE-27254-2 To check that the netconsole service is disabled in system boot configuration, run the following command: # chkconfig netconsole --list Output should indicate the netconsole service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig netconsole --list netconsole 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify netconsole is disabled through current runtime configuration: # service netconsole status If the service is disabled the command will return the following output: netconsole is stopped The ntpdate service sets the local hardware clock by polling NTP servers when the system boots. It synchronizes to the NTP servers listed in /etc/ntp/step-tickers or /etc/ntp.conf and then sets the local hardware clock to the newly synchronized system time. The ntpdate service can be disabled with the following command: # chkconfig ntpdate off AC-17(8) CM-7 382 DS 20121024 The ntpdate service may only be suitable for systems which are rebooted frequently enough that clock drift does not cause problems between reboots. In any event, the functionality of the ntpdate service is now available in the ntpd program and should be considered deprecated. CCE-27256-7 To check that the ntpdate service is disabled in system boot configuration, run the following command: # chkconfig ntpdate --list Output should indicate the ntpdate service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig ntpdate --list ntpdate 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify ntpdate is disabled through current runtime configuration: # service ntpdate status If the service is disabled the command will return the following output: ntpdate is stopped The oddjobd service exists to provide an interface and access control mechanism through which specified privileged tasks can run tasks for unprivileged client applications. Communication with oddjobd through the system message bus. The oddjobd service can be disabled with the following command: # chkconfig oddjobd off CM-7 381 DS 20121024 The oddjobd service may provide necessary functionality in some environments but it can be disabled if it is not needed. Execution of tasks by privileged programs, on behalf of unprivileged ones, has traditionally been a source of privilege escalation security issues. CCE-27257-5 To check that the oddjobd service is disabled in system boot configuration, run the following command: # chkconfig oddjobd --list Output should indicate the oddjobd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig oddjobd --list oddjobd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify oddjobd is disabled through current runtime configuration: # service oddjobd status If the service is disabled the command will return the following output: oddjobd is stopped The portreserve service is a TCP port reservation utility that can be used to prevent portmap from binding to well known TCP ports that are required for other services. The portreserve service can be disabled with the following command: # chkconfig portreserve off AC-17(8) CM-7 DS 20121024 The portreserve service provides helpful functionality by preventing conflicting usage of ports in the reserved port range, but it can be disabled if not needed. CCE-27258-3 To check that the portreserve service is disabled in system boot configuration, run the following command: # chkconfig portreserve --list Output should indicate the portreserve service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig portreserve --list portreserve 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify portreserve is disabled through current runtime configuration: # service portreserve status If the service is disabled the command will return the following output: portreserve is stopped The process accounting service (psacct) works with programs including acct and ac to allow system administrators to view user activity, such as commands issued by users of the system. The psacct service can be enabled with the following command: # chkconfig --level 2345 psacct on AU-12 CM-7 DS 20121024 The psacct service can provide administrators a convenient view into some user activities. However, it should be noted that the auditing system and its audit records provide more authoritative and comprehensive records. CCE-27259-1 To check that the psacct service is disabled in system boot configuration, run the following command: # chkconfig psacct --list Output should indicate the psacct service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig psacct --list psacct 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify psacct is disabled through current runtime configuration: # service psacct status If the service is disabled the command will return the following output: psacct is stopped The qpidd service provides high speed, secure, guaranteed delivery services. It is an implementation of the Advanced Message Queuing Protocol. By default the qpidd service will bind to port 5672 and listen for connection attempts. The qpidd service can be disabled with the following command: # chkconfig qpidd off AC-17(8) CM-7 382 The qpidd service is automatically installed when the "base" package selection is selected during installation. The qpidd service listens for network connections which increases the attack surface of the system. If the system is not intended to receive AMQP traffic then the qpidd service is not needed and should be disabled or removed. CCE-26928-2 To check that the qpidd service is disabled in system boot configuration, run the following command: # chkconfig qpidd --list Output should indicate the qpidd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig qpidd --list qpidd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify qpidd is disabled through current runtime configuration: # service qpidd status If the service is disabled the command will return the following output: qpidd is stopped The quota_nld service provides notifications to users of disk space quota violations. It listens to the kernel via a netlink socket for disk quota violations and notifies the appropriate user of the violation using D-Bus or by sending a message to the terminal that the user has last accessed. The quota_nld service can be disabled with the following command: # chkconfig quota_nld off CM-7 DS 20121024 If disk quotas are enforced on the local system, then the quota_nld service likely provides useful functionality and should remain enabled. However, if disk quotas are not used or user notification of disk quota violation is not desired then there is no need to run this service. CCE-27260-9 To check that the quota_nld service is disabled in system boot configuration, run the following command: # chkconfig quota_nld --list Output should indicate the quota_nld service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig quota_nld --list quota_nld 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify quota_nld is disabled through current runtime configuration: # service quota_nld status If the service is disabled the command will return the following output: quota_nld is stopped The rdisc service implements the client side of the ICMP Internet Router Discovery Protocol (IRDP), which allows discovery of routers on the local subnet. If a router is discovered then the local routing table is updated with a corresponding default route. By default this daemon is disabled. The rdisc service can be disabled with the following command: # chkconfig rdisc off AC-17(8) AC-4 CM-7 382 DS 20121024 General-purpose systems typically have their network and routing information configured statically by a system administrator. Workstations or some special-purpose systems often use DHCP (instead of IRDP) to retrieve dynamic network configuration information. CCE-27261-7 To check that the rdisc service is disabled in system boot configuration, run the following command: # chkconfig rdisc --list Output should indicate the rdisc service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig rdisc --list rdisc 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify rdisc is disabled through current runtime configuration: # service rdisc status If the service is disabled the command will return the following output: rdisc is stopped 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: # chkconfig rhnsd off AC-17(8) CM-7 382 DS 20121024 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. CCE-26846-6 To check that the rhnsd service is disabled in system boot configuration, run the following command: # chkconfig rhnsd --list Output should indicate the rhnsd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig rhnsd --list rhnsd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify rhnsd is disabled through current runtime configuration: # service rhnsd status If the service is disabled the command will return the following output: rhnsd is stopped The Red Hat Subscription Manager (rhsmcertd) periodically checks for changes in the entitlement certificates for a registered system and updates it accordingly. The rhsmcertd service can be disabled with the following command: # chkconfig rhsmcertd off CM-7 DS 20121024 The rhsmcertd service can provide administrators with some additional control over which of their systems are entitled to particular subscriptions. However, for systems that are managed locally or which are not expected to require remote changes to their subscription status, it is unnecessary and can be disabled. CCE-27262-5 To check that the rhsmcertd service is disabled in system boot configuration, run the following command: # chkconfig rhsmcertd --list Output should indicate the rhsmcertd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig rhsmcertd --list rhsmcertd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify rhsmcertd is disabled through current runtime configuration: # service rhsmcertd status If the service is disabled the command will return the following output: rhsmcertd is stopped The saslauthd service handles plaintext authentication requests on behalf of the SASL library. The service isolates all code requiring superuser privileges for SASL authentication into a single process, and can also be used to provide proxy authentication services to clients that do not understand SASL based authentication. The saslauthd service can be disabled with the following command: # chkconfig saslauthd off AC-17(8) CM-7 DS 20121024 The saslauthd service provides essential functionality for performing authentication in some directory environments, such as those which use Kerberos and LDAP. For others, however, in which only local files may be consulted, it is not necessary and should be disabled. CCE-27263-3 To check that the saslauthd service is disabled in system boot configuration, run the following command: # chkconfig saslauthd --list Output should indicate the saslauthd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig saslauthd --list saslauthd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify saslauthd is disabled through current runtime configuration: # service saslauthd status If the service is disabled the command will return the following output: saslauthd is stopped SMART (Self-Monitoring, Analysis, and Reporting Technology) is a feature of hard drives that allows them to detect symptoms of disk failure and relay an appropriate warning. The smartd service can be disabled with the following command: # chkconfig smartd off CM-7 DS 20121024 SMART can help protect against denial of service due to failing hardware. Nevertheless, if it is not needed or the system's drives are not SMART-capable (such as solid state drives), it can be disabled. CCE-26853-2 To check that the smartd service is disabled in system boot configuration, run the following command: # chkconfig smartd --list Output should indicate the smartd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig smartd --list smartd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify smartd is disabled through current runtime configuration: # service smartd status If the service is disabled the command will return the following output: smartd is stopped The sysstat service resets various I/O and CPU performance statistics to zero in order to begin counting from a fresh state at boot time. The sysstat service can be disabled with the following command: # chkconfig sysstat off CM-7 DS 20121024 By default the sysstat service merely runs a program at boot to reset the statistics, which can be retrieved using programs such as sar and sadc. These may provide useful insight into system operation, but unless used this service can be disabled. CCE-27265-8 To check that the sysstat service is disabled in system boot configuration, run the following command: # chkconfig sysstat --list Output should indicate the sysstat service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig sysstat --list sysstat 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify sysstat is disabled through current runtime configuration: # service sysstat status If the service is disabled the command will return the following output: sysstat is stopped The 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. 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: # chkconfig --level 2345 crond on CM-7 DS 20121024 Due to its usage for maintenance and security-supporting tasks, enabling the cron daemon is essential. CCE-27070-2 Run the following command to determine the current status of the crond service: # service crond status If the service is enabled, it should return the following: crond is running... The cronie-anacron package which provides anacron functionality is installed by default. To disable anacron support, run the following commands: # yum install cronie-noanacron # yum erase cronie-anacron The anacron service provides cron functionality for systems such as laptops and workstations that may be shut down during the normal times that cron jobs are scheduled to run. On systems which do not require this additional functionality, anacron could needlessly increase the possible attack surface for an intruder. CM-7 The at and batch commands can be used to schedule tasks that are meant to be executed only once. This allows delayed execution in a manner similar to cron, except that it is not recurring. The daemon atd keeps track of tasks scheduled via at and batch, and executes them at the specified time. The atd service can be disabled with the following command: # chkconfig atd off CM-7 381 The atd service could be used by an unsophisticated insider to carry out activities outside of a normal login session, which could complicate accountability. Furthermore, the need to schedule tasks with at or batch is not common. CCE-27249-2 To check that the atd service is disabled in system boot configuration, run the following command: # chkconfig atd --list Output should indicate the atd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig atd --list atd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify atd is disabled through current runtime configuration: # service atd status If the service is disabled the command will return the following output: atd is stopped The /etc/cron.allow and /etc/at.allow files contain lists of users who are allowed to use cron and at to delay execution of processes. If these files exist and if the corresponding files /etc/cron.deny and /etc/at.deny do not exist, then only users listed in the relevant allow files can run the crontab and at commands to submit jobs to be run at scheduled intervals. On many systems, only the system administrator needs the ability to schedule jobs. Note that even if a given user is not listed in cron.allow, cron jobs can still be run as that user. The cron.allow file controls only administrative access to the crontab command for scheduling and modifying cron jobs. To restrict at and cron to only authorized users: Remove the cron.deny file:# rm /etc/cron.denyEdit /etc/cron.allow, adding one line for each user allowed to use the crontab command to create cron jobs.Remove the at.deny file:# rm /etc/at.denyEdit /etc/at.allow, adding one line for each user allowed to use the at command to create at jobs. The 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 sshd and provided by the RPM package openssh-server. Specify duration of allowed idle time. 300 300 600 The SSH server service, sshd, is commonly needed. However, if it can be disabled, do so. The sshd service can be disabled with the following command: # chkconfig sshd off This is unusual, as SSH is a common method for encrypted and authenticated remote access. DS 20121024 CCE-27054-6 By default, inbound connections to SSH's port are allowed. If the SSH server is not being used, this exception should be removed from the firewall configuration. Edit the files /etc/sysconfig/iptables and /etc/sysconfig/ip6tables (if IPv6 is in use). In each file, locate and delete the line: -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT This is unusual, as SSH is a common method for encrypted and authenticated remote access. If inbound SSH connections are not expected, disallowing access to the SSH port will avoid possible exploitation of the port by an attacker. CCE-27060-3 If the system needs to act as an SSH server, then certain changes should be made to the OpenSSH daemon configuration file /etc/ssh/sshd_config. The following recommendations can be applied to this file. See the sshd_config(5) man page for more detailed information. 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 AC-17(7) IA-5(1)(c) 776 774 1436 DS 20121024 SSH protocol version 1 suffers from design flaws that result in security vulnerabilities and should not be used. CCE-27072-8 To check which SSH protocol version is allowed, run the following command: # grep Protocol /etc/ssh/sshd_config If configured properly, output should be Protocol 2 By 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 /etc/ssh/sshd_config file: DenyUsers USER1 USER2 Where USER1 and USER2 are valid user names. Specifying which accounts are allowed SSH access into the system reduces the possibility of unauthorized access to the system. 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 interval The 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. 879 1133 DS 20121024 Causing idle users to be automatically logged out guards against compromises one system leading trivially to compromises on another. CCE-26919-1 Run the following command to see what the timeout interval is: # grep ClientAliveInterval /etc/ssh/sshd_config If properly configured, the output should be: ClientAliveInterval 900 To ensure the SSH idle timeout occurs precisely when the ClientAliveCountMax is set, edit /etc/ssh/sshd_config as follows: ClientAliveCountMax 0 879 1133 DS 20121024 This ensures a user login will be terminated as soon as the ClientAliveCountMax is reached. CCE-26282-4 To ensure the SSH idle timeout will occur when the ClientAliveCountMax is set, run the following command: # grep ClientAliveCountMax /etc/ssh/sshd_config If properly configured, output should be: ClientAliveCountMax 0 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 765 766 SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. CCE-27124-7 To determine how the SSH daemon's IgnoreRhosts option is set, run the following command: # grep -i IgnoreRhosts /etc/ssh/sshd_config If no line, a commented line, or a line indicating the value yes is returned, then the required value is set. SSH's cryptographic host-based authentication is more secure than .rhosts authentication, since hosts are cryptographically authenticated. 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 765 766 DS 20121024 SSH trust relationships mean a compromise on one host can allow an attacker to move trivially to other hosts. CCE-27091-8 To determine how the SSH daemon's HostbasedAuthentication option is set, run the following command: # grep -i HostbasedAuthentication /etc/ssh/sshd_config If no line, a commented line, or a line indicating the value no is returned, then the required value is set. 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 AC-6(2) IA-2(1) 770 DS 20121024 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. CCE-27100-7 To determine how the SSH daemon's PermitRootLogin option is set, run the following command: # grep -i PermitRootLogin /etc/ssh/sshd_config If a line indicating no is returned, then the required value is set. To explicitly disallow remote 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. 765 766 DS 20121024 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. CCE-26887-0 To determine how the SSH daemon's PermitEmptyPasswords option is set, run the following command: # grep -i PermitEmptyPasswords /etc/ssh/sshd_config If no line, a commented line, or a line indicating the value no is returned, then the required value is set. 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/issue Another section contains information on how to create an appropriate system-wide warning banner. 48 DS 20121024 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. CCE-27112-2 To determine how the SSH daemon's Banner option is set, run the following command: # grep -i Banner /etc/ssh/sshd_config If a line indicating /etc/issue is returned, then the required value is set. To ensure users are not able to present environment options to the SSH daemon, add or correct the following line in /etc/ssh/sshd_config: PermitUserEnvironment no 1414 DS 20121024 SSH environment options potentially allow users to bypass access restriction in some configurations. CCE-27201-3 To ensure users are not able to present environment daemons, run the following command: # grep PermitUserEnvironment /etc/ssh/sshd_config If properly configured, output should be: PermitUserEnvironment no 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-approved ciphers: Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc The man page sshd_config(5) contains a list of supported ciphers. AC-3 AC-17(2) AU-10(5) IA-5(1)(c) IA-7 803 1144 1145 1146 DS 20121024 Approved algorithms should impart some level of confidence in their implementation. These are also required for compliance. CCE-26555-3 Only FIPS-approved ciphers should be used. To verify that only FIPS-approved ciphers are in use, run the following command: # grep Ciphers /etc/ssh/sshd_config The output should contain only those ciphers which are FIPS-approved, namely, the AES and 3DES ciphers. If the SSH server is expected to only receive connections from the local network, then strengthen the default firewall rule for the SSH service to only accept connections from the appropriate network segment(s). Determine an appropriate network block, netwk, and network mask, mask, representing the machines on your network which will be allowed to access this SSH server. Edit the files etc/sysconfig/iptables and /etc/sysconfig/ip6tables (if IPv6 is in use). In each file, locate the line: -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT and replace it with: -A INPUT -s netwk/mask -m state --state NEW -p tcp --dport 22 -j ACCEPT Restricting SSH access to only trusted network segments reduces exposure of the SSH server to attacks from unauthorized networks. The X Window System implementation included with the system is called X.org. Unless 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. Setting the system's runlevel to 3 will prevent automatic startup of the X server. To do so, ensure the following line in /etc/inittab features a 3 as shown: id:3:initdefault: 366 DS 20121025 Unnecessary services should be disabled to decrease the attack surface of the system. CCE-27119-7 To verify the default runlevel is 3, run the following command: # grep initdefault /etc/inittab The output should show the following: id:3:initdefault: Removing all packages which constitute the X Window System ensures users or malicious software cannot start X. To do so, run the following command: # yum groupremove "X Window System" 366 DS 20121025 Unnecessary packages should not be installed to decrease the attack surface of the system. CCE-27198-1 To ensure the X Windows package group is removed, run the following command: $ rpm -qi xorg-x11-server-common The output should be: package xorg-x11-server-common is not installed The 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. Because 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. The avahi-daemon service can be disabled with the following command: # chkconfig avahi-daemon off CM-7 366 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. CCE-27087-6 To check that the avahi-daemon service is disabled in system boot configuration, run the following command: # chkconfig avahi-daemon --list Output should indicate the avahi-daemon service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig avahi-daemon --list avahi-daemon 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify avahi-daemon is disabled through current runtime configuration: # service avahi-daemon status If the service is disabled the command will return the following output: avahi-daemon is stopped If your system requires the Avahi daemon, its configuration can be restricted to improve security. The Avahi daemon configuration file is /etc/avahi/avahi-daemon.conf. The following security recommendations should be applied to this file: See the avahi-daemon.conf(5) man page, or documentation at http://www.avahi.org, for more detailed information about the configuration options. If you are using only IPv4, edit /etc/avahi/avahi-daemon.conf and ensure the following line exists in the [server] section: use-ipv6=no Similarly, if you are using only IPv6, disable IPv4 sockets with the line: use-ipv4=no CM-7 To make Avahi ignore packets unless the TTL field is 255, edit /etc/avahi/avahi-daemon.conf and ensure the following line appears in the [server] section: check-response-ttl=yes CM-7 This helps to ensure that only mDNS responses from the local network are processed, because the TTL field in a packet is decremented from its initial value of 255 whenever it is routed from one network to another. Although a properly-configured router or firewall should not allow mDNS packets into the local network at all, this option provides another check to ensure they are not permitted. To prevent other mDNS stacks from running, edit /etc/avahi/avahi-daemon.conf and ensure the following line appears in the [server] section: disallow-other-stacks=yes CM-7 This helps ensure that only Avahi is responsible for mDNS traffic coming from that port on the system. To prevent other mDNS stacks from running, edit /etc/avahi/avahi-daemon.conf and ensure the following line appears in the [server] section: disallow-other-stacks=yes CM-7 This helps ensure that only Avahi is responsible for mDNS traffic coming from that port on the system. If it is necessary to publish some information to the network, it should not be joined by any extraneous information, or by information supplied by a non-trusted source on the system. Prevent user applications from using Avahi to publish services by adding or correcting the following line in the [publish] section: disable-user-service-publishing=yes Implement as many of the following lines as possible, to restrict the information published by Avahi. publish-addresses=no publish-hinfo=no publish-workstation=no publish-domain=no Inspect the files in the directory /etc/avahi/services/. Unless there is an operational need to publish information about each of these services, delete the corresponding file. CM-7 These options prevent publishing attempts from succeeding, and can be applied even if publishing is disabled entirely via disable-publishing. Alternatively, these can be used to restrict the types of published information in the event that some information must be published. The 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. The cups service can be disabled with the following command: # chkconfig cups off CM-7 Turn off unneeded services to reduce attack surface. CCE-26899-5 To check that the cups service is disabled in system boot configuration, run the following command: # chkconfig cups --list Output should indicate the cups service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig cups --list cups 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify cups is disabled through current runtime configuration: # service cups status If the service is disabled the command will return the following output: cups is stopped CUPS provides the ability to easily share local printers with other machines over the network. It does this by allowing machines to share lists of available printers. Additionally, each machine that runs the CUPS service can potentially act as a print server. Whenever possible, the printer sharing and print server capabilities of CUPS should be limited or disabled. The following recommendations should demonstrate how to do just that. By default, CUPS listens on the network for printer list broadcasts on UDP port 631. This functionality is called printer browsing. To disable printer browsing entirely, edit the CUPS configuration file, located at /etc/cups/cupsd.conf, to include the following: Browsing Off CM-7 The CUPS print service can be configured to broadcast a list of available printers to the network. Other machines on the network, also running the CUPS print service, can be configured to listen to these broadcasts and add and configure these printers for immediate use. By disabling this browsing capability, the machine will no longer generate or receive such broadcasts. CCE-27108-0 To prevent remote users from potentially connecting to and using locally configured printers, disable the CUPS print server sharing capabilities. To do so, limit how the server will listen for print jobs by removing the more generic port directive from /etc/cups/cupsd.conf: Port 631 and replacing it with the Listen directive: Listen localhost:631 This will prevent remote users from printing to locally configured printers while still allowing local users on the machine to print normally. CM-7 By default, locally configured printers will not be shared over the network, but if this functionality has somehow been enabled, these recommendations will disable it again. Be sure to disable outgoing printer list broadcasts, or remote users will still be able to see the locally configured printers, even if they cannot actually print to them. To limit print serving to a particular set of users, use the Policy directive. CCE-27107-2 The Dynamic Host Configuration Protocol (DHCP) allows systems to request and obtain an IP address and other configuration parameters from a server. In general, sites use DHCP either to allow a large pool of mobile or unknown machines to share a limited number of IP addresses, or to standardize installations by avoiding static, individual IP address configuration on hosts. It is recommended that sites avoid DHCP as much as possible. Since DHCP authentication is not well-supported, DHCP clients are open to attacks from rogue DHCP servers. Such servers can give clients incorrect information (e.g. malicious DNS server addresses) which could lead to their compromise. If a machine must act as a DHCP client or server, configure it defensively using the guidance in this section. This guide recommends configuring networking on clients by manually editing the appropriate files under /etc/sysconfig. It is also possible to use the graphical front-end programs system-config-network and system-config-network-tui, but these programs rewrite configuration files from scratch based on their defaults - destroying any manual changes - and should therefore be used with caution. The DHCP server dhcpd is not installed or activated by default. If the software was installed and activated, but the system does not need to act as a DHCP server, it should be disabled and removed. 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: # chkconfig dhcpd off CM-7 366 DS 20121024 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. CCE-27074-4 To check that the dhcpd service is disabled in system boot configuration, run the following command: # chkconfig dhcpd --list Output should indicate the dhcpd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig dhcpd --list dhcpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify dhcpd is disabled through current runtime configuration: # service dhcpd status If the service is disabled the command will return the following output: dhcpd is stopped If the system does not need to act as a DHCP server, the dhcp package can be uninstalled. The dhcp package can be removed with the following command: # yum erase dhcp CM-7 366 DS 20121024 Removing the DHCP server ensures that it cannot be easily or accidentally reactivated and disrupt network operation. CCE-27120-5 Run the following command to determine if the dhcp package is installed: # rpm -q dhcp If the system must act as a DHCP server, the configuration information it serves should be minimized. Also, support for other protocols and DNS-updating schemes should be explicitly disabled unless needed. The configuration file for dhcpd is called /etc/dhcpd.conf. The file begins with a number of global configuration options. The remainder of the file is divided into sections, one for each block of addresses offered by dhcpd, each of which contains configuration options specific to that address block. To prevent the DHCP server from receiving DNS information from clients, edit /etc/dhcpd.conf, and add or correct the following global option: ddns-update-style none; The ddns-update-style option controls only whether the DHCP server will attempt to act as a Dynamic DNS client. As long as the DNS server itself is correctly configured to reject DDNS attempts, an incorrect ddns-update-style setting on the client is harmless (but should be fixed as a best practice). CM-7 The Dynamic DNS protocol is used to remotely update the data served by a DNS server. DHCP servers can use Dynamic DNS to publish information about their clients. This setup carries security risks, and its use is not recommended. If Dynamic DNS must be used despite the risks it poses, it is critical that Dynamic DNS transactions be protected using TSIG or some other cryptographic authentication mechanism. See dhcpd.conf(5) for more information about protecting the DHCP server from passing along malicious DNS data from its clients. CCE-27049-6 Edit /etc/dhcpd.conf and add or correct the following global option to prevent the DHCP server from responding the DHCPDECLINE messages, if possible: deny declines; CM-7 The DHCPDECLINE message can be sent by a DHCP client to indicate that it does not consider the lease offered by the server to be valid. By issuing many DHCPDECLINE messages, a malicious client can exhaust the DHCP server's pool of IP addresses, causing the DHCP server to forget old address allocations. CCE-27106-4 Unless your network needs to support older BOOTP clients, disable support for the bootp protocol by adding or correcting the global option: deny bootp; CM-7 The bootp option tells dhcpd to respond to BOOTP queries. If support for this simpler protocol is not needed, it should be disabled to remove attack vectors against the DHCP server. CCE-27077-7 Edit /etc/dhcpd.conf. Examine each address range section within the file, and ensure that the following options are not defined unless there is an operational need to provide this information via DHCP: option domain-name option domain-name-servers option nis-domain option nis-servers option ntp-servers option routers option time-offset By default, the RHEL client installation uses DHCP to request much of the above information from the DHCP server. In particular, domain-name, domain-name-servers, and routers are configured via DHCP. These settings are typically necessary for proper network functionality, but are also usually static across machines at a given site. CM-7 Because the configuration information provided by the DHCP server could be maliciously provided to clients by a rogue DHCP server, the amount of information provided via DHCP should be minimized. Remove these definitions from the DHCP server configuration to ensure that legitimate clients do not unnecessarily rely on DHCP for this information. Ensure that the following line exists in /etc/syslog.conf: daemon.* /var/log/daemon.log Configure logwatch or other log monitoring tools to summarize error conditions reported by the dhcpd process. By default, dhcpd logs notices to the daemon facility. Sending all daemon messages to a dedicated log file is part of the syslog configuration outlined in the Logging and Auditing section CCE-26898-7 DHCP is the default network configuration method provided by the system installer, and common on many networks. Nevertheless, manual management of IP addresses for systems implies a greater degree of management and accountability for network activity. For each interface on the system (e.g. eth0), edit /etc/sysconfig/network-scripts/ifcfg-interface and make the following changes: Correct the BOOTPROTO line to read: BOOTPROTO=static Add or correct the following lines, substituting the appropriate values based on your site's addressing scheme: NETMASK=255.255.255.0 IPADDR=192.168.1.2 GATEWAY=192.168.1.1 CM-7 366 DS 20121024 DHCP relies on trusting the local network. If the local network is not trusted, then it should not be used. However, the automatic configuration provided by DHCP is commonly used and the alternative, manual configuration, presents an unacceptable burden in many circumstances. CCE-27021-5 To verify that DHCP is not being used, examine the following file for each interface: # /etc/sysconfig/network-scripts/ifcfg-interface Look for the following: BOOTPROTO=static and the following, substituting the appropriate values based on your site's addressing scheme: NETMASK=255.255.255.0 IPADDR=192.168.1.2 GATEWAY=192.168.1.1 If DHCP must be used, then certain configuration changes can minimize the amount of information it receives and applies from the network, and thus the amount of incorrect information a rogue DHCP server could successfully distribute. For more information on configuring dhclient, see the dhclient(8) and dhclient.conf(5) man pages. Create the file /etc/dhclient.conf, and add an appropriate setting for each of the ten configuration settings which can be obtained via DHCP. For each setting, do one of the following: If the setting should not be configured remotely by the DHCP server, select an appropriate static value, and add the line: supersede setting value; If the setting should be configured remotely by the DHCP server, add the lines: request setting; require setting; For example, suppose the DHCP server should provide only the IP address itself and the subnet mask. Then the entire file should look like: supersede domain-name "example.com"; supersede domain-name-servers 192.168.1.2; supersede nis-domain ""; supersede nis-servers ""; supersede ntp-servers "ntp.example.com "; supersede routers 192.168.1.1; supersede time-offset -18000; request subnet-mask; require subnet-mask; In this example, the options nis-servers and nis-domain are set to empty strings, on the assumption that the deprecated NIS protocol is not in use. It is necessary to supersede settings for unused services so that they cannot be set by a hostile DHCP server. If an option is set to an empty string, dhclient will typically not attempt to configure the service. By default, the DHCP client program, dhclient, requests and applies ten configuration options (in addition to the IP address) from the DHCP server. subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, nis-domain, nis-servers, and ntp-servers. Many of the options requested and applied by dhclient may be the same for every system on a network. It is recommended that almost all configuration options be assigned statically, and only options which must vary on a host-by-host basis be assigned via DHCP. This limits the damage which can be done by a rogue DHCP server. If appropriate for your site, it is also possible to supersede the host-name directive in /etc/dhclient.conf, establishing a static hostname for the machine. However, dhclient does not use the host name option provided by the DHCP server (instead using the value provided by a reverse DNS lookup). The 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. Local time synchronization is recommended for all networks. If every machine on your network reliably reports the same time as every other machine, then it is much easier to correlate log messages in case of an attack. In addition, a number of cryptographic protocols (such as Kerberos) use timestamps to prevent certain types of attacks. If your network does not have synchronized time, these protocols may be unreliable or even unusable. Depending on the specifics of the network, global time accuracy may be just as important as local synchronization, or not very important at all. If your network is connected to the Internet, it is recommended that you make use of a public timeserver or one provided by your enterprise or agency, since globally accurate timestamps may be necessary if you need to investigate or respond to an attack which originated outside of your network. A typical network setup involves a small number of internal systems operating as NTP servers, and the remainder obtaining time information from those internal servers. More information on how to configure the NTP server software, including configuration of cryptographic authentication for time data, is available at http://www.ntp.org. The ntpd service can be enabled with the following command: # chkconfig --level 2345 ntpd on AU-8(1) 160 DS 20121024 Enabling the ntpd service ensures that the ntpd service 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 NTP daemon offers 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 CCE-27093-4 Run the following command to determine the current status of the ntpd service: # service ntpd status If the service is enabled, it should return the following: ntpd is running... To specify a remote NTP server for time synchronization, edit the file /etc/ntp.conf. Add or correct the following lines, substituting the IP or hostname of a remote NTP server for ntpserver: server ntpserver This instructs the NTP software to contact that remote server to obtain time data. AU-8(1) 160 DS 20121024 Synchronizing with an NTP server makes it possible to collate system logs from multiple sources or correlate computer events with real time events. Using a trusted NTP server provided by your organization is recommended. CCE-27098-3 A remote NTP server should be configured for time synchronization. To verify one is configured, open the following file: /etc/ntp.conf In the file, there should be a section similar to the following: # --- OUR TIMESERVERS ----- server ntpserver Additional NTP servers can be specified for time synchronization in the file /etc/ntp.conf. To do so, add additional lines of the following form, substituting the IP address or hostname of a remote NTP server for ntpserver: server ntpserver AU-8(1) Specifying additional NTP servers increases the availability of accurate time data, in the event that one of the specified servers becomes unavailable. This is typical for a system acting as an NTP server for other systems. 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. Very few systems at any site should be configured to directly receive email over the network. Users should instead use mail client programs to retrieve email from a central server that supports protocols such as IMAP or POP3. However, it is normal for most systems to be independently capable of sending email, for instance so that cron jobs can report output to an administrator. Most MTAs, including Postfix, support a submission-only mode in which mail can be sent from the local system to a central site MTA (or directly delivered to a local account), but the system still cannot receive mail directly over a network. The alternatives program in RHEL permits selection of other mail server software (such as Sendmail), but Postfix is the default and is preferred. Postfix was coded with security in mind and can also be more effectively contained by SELinux as its modular design has resulted in separate processes performing specific actions. More information is available on its website, http://www.postfix.org. The Postfix mail transfer agent is used for local mail delivery within the system. The default configuration only listens for connections to the default SMTP port (port 25) on the loopback interface (127.0.0.1). It is recommended to leave this service enabled for local mail delivery. The postfix service can be enabled with the following command: # chkconfig --level 2345 postfix on DS 20121024 Local mail delivery is essential to some system maintenance and notification tasks. CCE-26325-1 Run the following command to determine the current status of the postfix service: # service postfix status If the service is enabled, it should return the following: postfix is running... Sendmail is not the default mail transfer agent and is not installed by default. The sendmail package can be removed with the following command: # yum erase sendmail CM-7 DS 20121024 The sendmail software was not developed with security in mind and its design prevents it from being effectively contained by SELinux. Postfix should be used instead. CCE-27515-6 Run the following command to determine if the sendmail package is installed: # rpm -q sendmail This section discusses settings for Postfix in a submission-only e-mail configuration. Edit the file /etc/postfix/main.cf to ensure that only the following inet_interfaces line appears: inet_interfaces = localhost CM-7 382 DS 20121024 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. CCE-26780-7 Run the following command to ensure postfix accepts mail messages from only the local system: $ grep inet_interfaces /etc/postfix/main.cf If properly configured, the output should show only localhost. The guidance in this section is appropriate for any host which is operating as a site MTA, whether the mail server runs using Sendmail, Postfix, or some other software. If SMTP AUTH is to be used, the use of SSL to protect credentials in transit is strongly recommended. There are also configurations for which it may be desirable to encrypt all mail in transit from one MTA to another, though such configurations are beyond the scope of this guide. In either event, the steps for creating and installing an SSL certificate are independent of the MTA in use, and are described here. Create the PKI directory for mail certificates, if it does not already exist: # mkdir /etc/pki/tls/mail # chown root:root /etc/pki/tls/mail # chmod 755 /etc/pki/tls/mail Using removable media or some other secure transmission format, install the files generated in the previous step onto the mail server: /etc/pki/tls/mail/serverkey.pem: the private key mailserverkey.pem /etc/pki/tls/mail/servercert.pem: the certificate file mailservercert.pem Verify the ownership and permissions of these files: # chown root:root /etc/pki/tls/mail/serverkey.pem # chown root:root /etc/pki/tls/mail/servercert.pem # chmod 600 /etc/pki/tls/mail/serverkey.pem # chmod 644 /etc/pki/tls/mail/servercert.pem Verify that the CA's public certificate file has been installed as /etc/pki/tls/CA/cacert.pem, and has the correct permissions: # chown root:root /etc/pki/tls/CA/cacert.pem # chmod 644 /etc/pki/tls/CA/cacert.pem Postfix stores its configuration files in the directory /etc/postfix by default. The primary configuration file is /etc/postfix/main.cf. Edit /etc/postfix/main.cf, and add or correct the following line, substituting some other wording for the banner information if you prefer: smtpd_banner = $myhostname ESMTP AC-22 AU-13 The default greeting banner discloses that the listening mail process is Postfix. When remote mail senders connect to the MTA on port 25, they are greeted by an initial banner as part of the SMTP dialogue. This banner is necessary, but it frequently gives away too much information, including the MTA software which is in use, and sometimes also its version number. Remote mail senders do not need this information in order to send mail, so the banner should be changed to reveal only the hostname (which is already known and may be useful) and the word ESMTP, to indicate that the modern SMTP protocol variant is supported. Edit /etc/postfix/main.cf. Edit the following lines to configure the amount of system resources Postfix can consume: default_process_limit = 100 smtpd_client_connection_count_limit = 10 smtpd_client_connection_rate_limit = 30 queue_minfree = 20971520 header_size_limit = 51200 message_size_limit = 10485760 smtpd_recipient_limit = 100 The values here are examples. Note: The values given here are examples, and may need to be modified for any particular site. By default, the Postfix anvil process gathers mail receipt statistics. To get information about about what connection rates are typical at your site, look in /var/log/maillog for lines with the daemon name postfix/anvil. These configuration options serve to make it more difficult for attackers to consume resources on the MTA host. The default_process_limit parameter controls how many smtpd processes can exist at a time, while smtpd_client_connection_count_limit controls the number of those which can be occupied by any one remote sender, and smtpd_client_connection_rate_limit controls the number of connections any one client can make per minute. By default, local hosts (those in mynetworks) are exempted from per-client rate limiting. The queue_minfree parameter establishes a free space threshold, in order to stop e-mail receipt before the queue filesystem is entirely full. The header_size_limit, message_size_limit, and smtpd_recipient_limit parameters place bounds on the legal sizes of messages received via SMTP. Postfix's mail relay controls are implemented with the help of the smtpd recipient restrictions option, which controls the restrictions placed on the SMTP dialogue once the sender and recipient envelope addresses are known. The guidance in the following sections should be applied to all machines. If there are machines which must be allowed to relay mail, but which cannot be trusted to relay unconditionally, configure SMTP AUTH with SSL support. Edit /etc/postfix/main.cf, and configure the contents of the mynetworks variable in one of the following ways: If any machine in the subnet containing the MTA may be trusted to relay messages, add or correct the following line: mynetworks_style = subnet This is also the default setting, and is in effect if all my_networks_style directives are commented.If only the MTA host itself is trusted to relay messages, add or correct the following line: mynetworks_style = hostIf the set of machines which can relay is more complicated, manually specify an entry for each netblock or IP address which is trusted to relay by setting the mynetworks variable directly: mynetworks = 10.0.0.0/16, 192.168.1.0/24, 127.0.0.1 The mynetworks variable must contain only the set of machines for which this MTA should unconditionally relay mail. This is a trust relationship - if spammers gain access to these machines, your site will effectively become an open relay. It is recommended that only machines which are managed by you or by another trusted organization be placed in mynetworks, and users of all other machines be required to use SMTP AUTH to send mail. To configure Postfix to restrict addresses to which it will send mail, see: http://www.postfix.org/SMTPD_ACCESS_README.html#danger The full contents of smtpd_recipient_restrictions will vary by site, since this is a common place to put spam restrictions and other site-specific options. The permit_mynetworks option allows all mail to be relayed from the machines in mynetworks. Then, the reject_unauth_destination option denies all mail whose destination address is not local, preventing any other machines from relaying. These two options should always appear in this order, and should usually follow one another immediately unless SMTP AUTH is used. To configure Postfix to restrict addresses to which it will send mail, see: http://www.postfix.org/SMTPD_ACCESS_README.html#danger The full contents of smtpd_recipient_restrictions will vary by site, since this is a common place to put spam restrictions and other site-specific options. The permit_mynetworks option allows all mail to be relayed from the machines in mynetworks. Then, the reject_unauth_destination option denies all mail whose destination address is not local, preventing any other machines from relaying. These two options should always appear in this order, and should usually follow one another immediately unless SMTP AUTH is used. SMTP authentication allows remote clients to relay mail safely by requiring them to authenticate before submitting mail. Postfix's SMTP AUTH uses an authentication library called SASL, which is not part of Postfix itself. To enable the use of SASL authentication, see http://www.postfix.org/SASL_README.html Postfix provides options to use TLS for certificate-based authentication and encrypted sessions. An encrypted session protects the information that is transmitted with SMTP mail or with SASL authentication. To configure Postfix to protect all SMTP AUTH transactions using TLS, see http://www.postfix.org/TLS_README.html. LDAP is a popular directory service, that is, a standardized way of looking up information from a central database. RHEL 6 includes software that enables a system to act as both an LDAP client and server. This section provides information on which security settings are important to configure in OpenLDAP clients by manually editing the appropriate configuration files. RHEL 6 provides an automated configuration tool called authconfig and a graphical wrapper for authconfig called system-config-authentication. However, these tools do not provide as much control over configuration as manual editing of configuration files. The authconfig tools do not allow you to specify locations of SSL certificate files, which is useful when trying to use SSL cleanly across several protocols. Installation and configuration of OpenLDAP on RHEL 6 is available at https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Directory_Servers.html. Before configuring any system to be an LDAP client, ensure that a working LDAP server is present on the network. Configure LDAP to enforce TLS use. First, edit the file /etc/pam_ldap.conf, and add or correct the following lines: ssl start_tls Then review the LDAP server and ensure TLS has been configured. CM-7 776 778 1453 DS 20121024 The ssl directive specifies whether to use ssl or not. If not specified it will default to no. It should be set to start_tls rather than doing LDAP over SSL. CCE-26690-8 To ensure LDAP is configured to use TLS for all transactions, run the following command: $ grep start_tls /etc/pam_ldap.conf Ensure a copy of a trusted CA certificate has been placed in the file /etc/pki/tls/CA/cacert.pem. Configure LDAP to enforce TLS use and to trust certificates signed by that CA. First, edit the file /etc/pam_ldap.conf, and add or correct either of the following lines: tls_cacertdir /etc/pki/tls/CA or tls_cacertfile /etc/pki/tls/CA/cacert.pem Then review the LDAP server and ensure TLS has been configured. CM-7 776 778 1453 DS 20121024 The tls_cacertdir or tls_cacertfile directives are required when tls_checkpeer is configured (which is the default for openldap versions 2.1 and up). These directives define the path to the trust certificates signed by the site CA. CCE-27189-0 To ensure TLS is configured with trust certificates, run the following command: # grep cert /etc/pam_ldap.conf This section details some security-relevant settings for an OpenLDAP server. Installation and configuration of OpenLDAP on RHEL 6 is available at: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/ch-Directory_Servers.html. The openldap-servers package should be removed if not in use. Is this machine the OpenLDAP server? If not, remove the package. # yum erase openldap-servers The openldap-servers RPM is not installed by default on RHEL 6 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. CM-7 366 DS 20121024 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. CCE-26858-1 To verify the openldap-servers package is not installed, run the following command: $ rpm -q openldap-servers The output should show the following: package openldap-servers is not installed Create the PKI directory for LDAP certificates if it does not already exist: # mkdir /etc/pki/tls/ldap # chown root:root /etc/pki/tls/ldap # chmod 755 /etc/pki/tls/ldap Using removable media or some other secure transmission format, install the certificate files onto the LDAP server: /etc/pki/tls/ldap/serverkey.pem: the private key ldapserverkey.pem/etc/pki/tls/ldap/servercert.pem: the certificate file ldapservercert.pem Verify the ownership and permissions of these files: # chown root:ldap /etc/pki/tls/ldap/serverkey.pem # chown root:ldap /etc/pki/tls/ldap/servercert.pem # chmod 640 /etc/pki/tls/ldap/serverkey.pem # chmod 640 /etc/pki/tls/ldap/servercert.pem Verify that the CA's public certificate file has been installed as /etc/pki/tls/CA/cacert.pem, and has the correct permissions: # mkdir /etc/pki/tls/CA # chown root:root /etc/pki/tls/CA/cacert.pem # chmod 644 /etc/pki/tls/CA/cacert.pem As a result of these steps, the LDAP server will have access to its own private certificate and the key with which that certificate is encrypted, and to the public certificate file belonging to the CA. Note that it would be possible for the key to be protected further, so that processes running as ldap could not read it. If this were done, the LDAP server process would need to be restarted manually whenever the server rebooted. The 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. If 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. 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. If NFS is not needed, disable the NFS client daemons nfslock, rpcgssd, and rpcidmapd. All of these daemons run with elevated privileges, and many listen for network connections. If they are not needed, they should be disabled to improve system security posture. The 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 nfslock service can be disabled with the following command: # chkconfig nfslock off CCE-27104-9 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 rpcgssd service can be disabled with the following command: # chkconfig rpcgssd off CCE-26864-9 The 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 rpcidmapd service can be disabled with the following command: # chkconfig rpcidmapd off CCE-26870-6 To determine if any network filesystems handled by netfs are currently mounted on the system execute the following command: # mount -t nfs,nfs4,smbfs,cifs,ncpfs If the command did not return any output then disable netfs. The netfs script manages the boot-time mounting of several types of networked filesystems, of which NFS and Samba are the most common. If these filesystem types are not in use, the script can be disabled, protecting the system somewhat against accidental or malicious changes to /etc/fstab and against flaws in the netfs script itself. The netfs service can be disabled with the following command: # chkconfig netfs off CCE-27137-9 The steps in this section are appropriate for all machines which run NFS, whether they operate as clients or as servers. If NFS must be used, it should be deployed in the simplest configuration possible to avoid maintainability problems which may lead to unnecessary security exposure. Due to the reliability and security problems caused by NFS (specially NFSv3 and NFSv2), it is not a good idea for machines which act as NFS servers to also mount filesystems via NFS. At the least, crossed mounts (the situation in which each of two servers mounts a filesystem from the other) should never be used. Firewalling should be done at each host and at the border firewalls to protect the NFS daemons from remote access, since NFS servers should never be accessible from outside the organization. However, by default for NFSv3 and NFSv2, the RPC Bind service assigns each NFS service to a port dynamically at service startup time. Dynamic ports cannot be protected by port filtering firewalls such as iptables. Therefore, restrict each service to always use a given port, so that firewalling can be done effectively. Note that, because of the way RPC is implemented, it is not possible to disable the RPC Bind service even if ports are assigned statically to all RPC services. In NFSv4, the mounting and locking protocols have been incorporated into the protocol, and the server listens on the the well-known TCP port 2049. As such, NFSv4 does not need to interact with the rpcbind, lockd, and rpc.statd daemons, which can and should be disabled in a pure NFSv4 environment. The rpc.mountd daemon is still required on the NFS server to setup exports, but is not involved in any over-the-wire operations. Configure the lockd daemon to use a static TCP port as opposed to letting the RPC Bind service dynamically assign a port. Edit the file /etc/sysconfig/nfs. Add or correct the following line: LOCKD_TCPPORT=lockd-port Where lockd-port is a port which is not used by any other service on your network. Restrict service to always use a given port, so that firewalling can be done effectively. CCE-27149-4 Configure the lockd daemon to use a static UDP port as opposed to letting the RPC Bind service dynamically assign a port. Edit the file /etc/sysconfig/nfs. Add or correct the following line: LOCKD_UDPPORT=lockd-port Where lockd-port is a port which is not used by any other service on your network. Restricting services to always use a given port enables firewalling to be done more effectively. CCE-27063-7 Configure the statd daemon to use a static port as opposed to letting the RPC Bind service dynamically assign a port. Edit the file /etc/sysconfig/nfs. Add or correct the following line: STATD_PORT=statd-port Where statd-port is a port which is not used by any other service on your network. Restricting services to always use a given port enables firewalling to be done more effectively. CCE-26889-6 Configure the mountd daemon to use a static port as opposed to letting the RPC Bind service dynamically assign a port. Edit the file /etc/sysconfig/nfs. Add or correct the following line: MOUNTD_PORT=statd-port Where mountd-port is a port which is not used by any other service on your network. Restricting services to always use a given port enables firewalling to be done more effectively. CCE-27114-8 The steps in this section are appropriate for machines which operate as NFS clients. There is no need to run the NFS server daemons nfs and rpcsvcgssd except on a small number of properly secured machines designated as NFS servers. Ensure that these daemons are turned off on clients. The Network File System (NFS) service allows remote hosts to mount and interact with shared filesystems on the local machine. If the local machine is not designated as a NFS server then this service should be disabled. The nfs service can be disabled with the following command: # chkconfig nfs off DS 20121025 Unnecessary services should be disabled to decrease the attack surface of the system. CCE-27199-9 It is prudent to ensure the nfs service is disabled in system boot, as well as not currently running. First, run the following to verify the service is stopped: $ service nfs status If the service is stopped or disabled, it will return the following: rpc.svcgssd is stopped rpc.mountd is stopped nfsd is stopped rpc.rquotad is stopped To verify that the nfs service is disabled, run the following command: $ chkconfig --list nfs If properly configured, the output should look like: nfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off The 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 rpcsvcgssd service can be disabled with the following command: # chkconfig rpcsvcgssd off DS 20121025 Unnecessary services should be disabled to decrease the attack surface of the system. CCE-27122-1 To check that the rpcsvcgssd service is disabled in system boot configuration, run the following command: # chkconfig rpcsvcgssd --list Output should indicate the rpcsvcgssd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig rpcsvcgssd --list rpcsvcgssd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify rpcsvcgssd is disabled through current runtime configuration: # service rpcsvcgssd status If the service is disabled the command will return the following output: rpcsvcgssd is stopped Edit the file /etc/fstab. For each filesystem whose type (column 3) is nfs or nfs4, add the text ,nodev,nosuid to the list of mount options in column 4. If appropriate, also add ,noexec. See the section titled "Restrict Partition Mount Options" for a description of the effects of these options. In general, execution of files mounted via NFS should be considered risky because of the possibility that an adversary could intercept the request and substitute a malicious file. Allowing setuid files to be executed from remote servers is particularly risky, both for this reason and because it requires the clients to extend root-level trust to the NFS server. Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts. DS 20121025 Legitimate device files should only exist in the /dev directory. NFS mounts should not present device files to users. CCE-27090-0 To verify the nodev option is configured for all NFS mounts, run the following command: $ mount | grep nfs All NFS mounts should show the nodev setting in parentheses. This is not applicable if NFS is not implemented. Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts. DS 20121025 NFS mounts should not present suid binaries to users. Only vendor-supplied suid executables should be installed to their default location on the local filesystem. CCE-26972-0 To verify the nosuid option is configured for all NFS mounts, run the following command: $ mount | grep nfs All NFS mounts should show the nosuid setting in parentheses. This is not applicable if NFS is not implemented. The steps in this section are appropriate for machines which operate as NFS servers. Linux's NFS implementation uses the file /etc/exports to control what filesystems and directories may be accessed via NFS. (See the exports(5) manpage for more information about the format of this file.) The syntax of the exports file is not necessarily checked fully on reload, and syntax errors can leave your NFS configuration more open than intended. Therefore, exercise caution when modifying the file. The syntax of each line in /etc/exports is: /DIR host1(opt1,opt2) host2(opt3) where /DIR is a directory or filesystem to export, hostN is an IP address, netblock, hostname, domain, or netgroup to which to export, and optN is an option. When configuring NFS exports, ensure that each export line in /etc/exports contains a list of hosts which are allowed to access that export. If no hosts are specified on an export line, then that export is available to any remote host which requests it. All lines of the exports file should specify the hosts (or subnets, if needed) which are allowed to access the exported directory, so that unknown or remote hosts will be denied. Authorized hosts can be specified in several different formats: Name or alias that is recognized by the resolverFully qualified domain nameIP addressIP subnets in the format address/netmask or address/CIDR If a filesystem is being exported so that users can view the files in a convenient fashion, but there is no need for users to edit those files, exporting the filesystem read-only removes an attack vector against the server. The default filesystem export mode is ro, so do not specify rw without a good reason. If a filesystem is exported using root squashing, requests from root on the client are considered to be unprivileged (mapped to a user such as nobody). This provides some mild protection against remote abuse of an NFS server. Root squashing is enabled by default, and should not be disabled. Ensure that no line in /etc/exports contains the option no_root_squash. If the NFS server allows root access to local file systems from remote hosts, this access could be used to compromise the system. CCE-27138-7 By default, the server NFS implementation requires that all client requests be made from ports less than 1024. If your organization has control over machines connected to its network, and if NFS requests are prohibited at the border firewall, this offers some protection against malicious requests from unprivileged users. Therefore, the default should not be changed. To ensure that the default has not been changed, ensure no line in /etc/exports contains the option insecure. Allowing client requests to be made from ports higher than 1024 could allow a unprivileged user to initiate an NFS connection. If the unprivileged user account has been compromised, an attacker could gain access to data on the NFS server. CCE-27121-3 By default the NFS server requires secure file-lock requests, which require credentials from the client in order to lock a file. Most NFS clients send credentials with file lock requests, however, there are a few clients that do not send credentials when requesting a file-lock, allowing the client to only be able to lock world-readable files. To get around this, the insecure_locks option can be used so these clients can access the desired export. This poses a security risk by potentially allowing the client access to data for which it does not have authorization. Remove any instances of the insecure_locks option from the file /etc/exports. 764 Allowing insecure file locking could allow for sensitive data to be viewed or edited by an unauthorized user. CCE-27167-6 To verify insecure file locking has been disabled, run the following command: # grep insecure_locks /etc/exports Most 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. DNS 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 RHEL 6 by default. The remainder of this section discusses secure configuration of machines which must be nameservers. The named service can be disabled with the following command: # chkconfig named off CM-7 366 All network services involve some risk of compromise due to implementation flaws and should be disabled if possible. CCE-26873-0 To check that the named service is disabled in system boot configuration, run the following command: # chkconfig named --list Output should indicate the named service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig named --list named 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify named is disabled through current runtime configuration: # service named status If the service is disabled the command will return the following output: named is stopped To remove the bind package, which contains the named service, run the following command: # yum erase bind CM-7 366 If there is no need to make DNS server software available, removing it provides a safeguard against its activation. CCE-27030-6 Run the following command to determine if the bind package is installed: # rpm -q bind This section discusses mechanisms for preventing the DNS server from interfering with other services. This is done both to protect the remainder of the network should a nameserver be compromised, and to make direct attacks on nameservers more difficult. Since DNS is a high-risk service which must frequently be made available to the entire Internet, it is strongly recommended that no other services be offered by machines which act as organizational DNS servers. Install the bind-chroot package: # yum install bind-chroot Place a valid named.conf file inside the chroot jail: # cp /etc/named.conf /var/named/chroot/etc/named.conf # chown root:root /var/named/chroot/etc/named.conf # chmod 644 /var/named/chroot/etc/named.conf Create and populate an appropriate zone directory within the jail, based on the options directive. If your named.conf includes: options { directory "/path/to/DIRNAME "; ... } then copy that directory and its contents from the original zone directory: # cp -r /path/to/DIRNAME /var/named/chroot/DIRNAME Add or correct the following line within /etc/sysconfig/named: ROOTDIR=/var/named/chroot If you are running BIND in a chroot jail, then you should use the jailed named.conf as the primary nameserver configuration file. That is, when this guide recommends editing /etc/named.conf, you should instead edit /var/named/chroot/etc/named.conf. Chroot jails are not foolproof. However, they serve to make it more difficult for a compromised program to be used to attack the entire host. They do this by restricting a program's ability to traverse the directory upward, so that files outside the jail are not visible to the chrooted process. Since RHEL supports a standard mechanism for placing BIND in a chroot jail, you should take advantage of this feature. This section discusses DNS configuration options which make it more difficult for attackers to gain access to private DNS data or to modify DNS data. Is it possible to run external and internal nameservers on separate machines? If so, follow the configuration guidance in this section. On the external nameserver, edit /etc/named.conf to add or correct the following directives: options { allow-query { any; }; recursion no; ... }; zone "example.com " IN { ... }; On the internal nameserver, edit /etc/named.conf. Add or correct the following directives, where SUBNET is the numerical IP representation of your organization in the form xxx.xxx.xxx.xxx/xx: acl internal { SUBNET ; localhost; }; options { allow-query { internal; }; ... }; zone "internal.example.com " IN { ... }; Enterprise nameservers generally serve two functions. One is to provide public information about the machines in a domain for the benefit of outside users who wish to contact those machines, for instance in order to send mail to users in the enterprise, or to visit the enterprise's external web page. The other is to provide nameservice to client machines within the enterprise. Client machines require both private information about enterprise machines (which may be different from the public information served to the rest of the world) and public information about machines outside the enterprise, which is used to send mail or visit websites outside of the organization. In order to provide the public nameservice function, it is necessary to share data with untrusted machines which request it - otherwise, the enterprise cannot be conveniently contacted by outside users. However, internal data should be protected from disclosure, and serving irrelevant public name queries for outside domains leaves the DNS server open to cache poisoning and other attacks. Therefore, local network nameservice functions should not be provided to untrusted machines. Separate machines should be used to fill these two functions whenever possible. If it is not possible to run external and internal nameservers on separate physical machines, run BIND9 and simulate this feature using views. Edit /etc/named.conf. Add or correct the following directives (where SUBNET is the numerical IP representation of your organization in the form xxx.xxx.xxx.xxx/xx): acl internal { SUBNET ; localhost; }; view "internal-view" { match-clients { internal; }; zone "." IN { type hint; file "db.cache"; }; zone "internal.example.com " IN { ... }; }; view "external-view" { match-clients { any; }; recursion no; zone "example.com " IN { ... }; }; As shown in the example, database files which are required for recursion, such as the root hints file, must be available to any clients which are allowed to make recursive queries. Under typical circumstances, this includes only the internal clients which are allowed to use this server as a general-purpose nameserver. The view feature is provided by BIND9 as a way to allow a single nameserver to make different sets of data available to different sets of clients. If possible, it is always better to run external and internal nameservers on separate machines, so that even complete compromise of the external server cannot be used to obtain internal data or confuse internal DNS clients. However, this is not always feasible, and use of a feature like views is preferable to leaving internal DNS data entirely unprotected. Is it necessary for a secondary nameserver to receive zone data via zone transfer from the primary server? If not, follow the instructions in this section. If so, see the next section for instructions on protecting zone transfers. Add or correct the following directive within /etc/named.conf: options { allow-transfer { none; }; ... } If both the primary and secondary nameserver are under your control, or if you have only one nameserver, it may be possible to use an external configuration management mechanism to distribute zone updates. In that case, it is not necessary to allow zone transfers within BIND itself, so they should be disabled to avoid the potential for abuse. If it is necessary for a secondary nameserver to receive zone data via zone transfer from the primary server, follow the instructions here. Use dnssec-keygen to create a symmetric key file in the current directory: # cd /tmp # dnssec-keygen -a HMAC-MD5 -b 128 -n HOST dns.example.com Kdns.example.com .+aaa +iiiii This output is the name of a file containing the new key. Read the file to find the base64-encoded key string: # cat Kdns.example.com .+NNN +MMMMM .key dns.example.com IN KEY 512 3 157 base64-key-string Add the directives to /etc/named.conf on the primary server: key zone-transfer-key { algorithm hmac-md5; secret "base64-key-string "; }; zone "example.com " IN { type master; allow-transfer { key zone-transfer-key; }; ... }; Add the directives below to /etc/named.conf on the secondary nameserver: key zone-transfer-key { algorithm hmac-md5; secret "base64-key-string "; }; server IP-OF-MASTER { keys { zone-transfer-key; }; }; zone "example.com " IN { type slave; masters { IP-OF-MASTER ; }; ... }; The purpose of the dnssec-keygen command is to create the shared secret string base64-key-string. Once this secret has been obtained and inserted into named.conf on the primary and secondary servers, the key files Kdns.example.com .+NNN +MMMMM .key and Kdns.example.com .+NNN +MMMMM .private are no longer needed, and may safely be deleted. CM-7 The BIND transaction signature (TSIG) functionality allows primary and secondary nameservers to use a shared secret to verify authorization to perform zone transfers. This method is more secure than using IP-based limiting to restrict nameserver access, since IP addresses can be easily spoofed. However, if you cannot configure TSIG between your servers because, for instance, the secondary nameserver is not under your control and its administrators are unwilling to configure TSIG, you can configure an allow-transfer directive with numerical IP addresses or ACLs as a last resort. Is there a mission-critical reason to enable the risky dynamic update functionality? If not, edit /etc/named.conf. For each zone specification, correct the following directive if necessary: zone "example.com " IN { allow-update { none; }; ... }; Dynamic updates allow remote servers to add, delete, or modify any entries in your zone file. Therefore, they should be considered highly risky, and disabled unless there is a very good reason for their use. If dynamic updates must be allowed, IP-based ACLs are insufficient protection, since they are easily spoofed. Instead, use TSIG keys (see the previous section for an example), and consider using the update-policy directive to restrict changes to only the precise type of change needed. CCE-27105-6 FTP 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. However, there are some FTP server configurations which may be appropriate for some environments, particularly those which allow only read-only anonymous access as a means of downloading data available to the public. The vsftpd service can be disabled with the following command: # chkconfig vsftpd off CM-7 1436 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. CCE-26948-0 if service vsftpd status >/dev/null; then service vsftpd stop fi To check that the vsftpd service is disabled in system boot configuration, run the following command: # chkconfig vsftpd --list Output should indicate the vsftpd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig vsftpd --list vsftpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify vsftpd is disabled through current runtime configuration: # service vsftpd status If the service is disabled the command will return the following output: vsftpd is stopped The vsftpd package can be removed with the following command: # yum erase vsftpd CM-7 1436 Removing the vsftpd package decreases the risk of its accidental activation. CCE-26687-4 Run the following command to determine if the vsftpd package is installed: # rpm -q vsftpd If this machine must operate as an FTP server, install the vsftpd package via the standard channels. # yum install vsftpd CM-7 After RHEL 2.1, Red Hat switched from distributing wu-ftpd with RHEL to distributing vsftpd. For security and for consistency with future Red Hat releases, the use of vsftpd is recommended. CCE-27187-4 The primary vsftpd configuration file is /etc/vsftpd.conf, if that file exists, or /etc/vsftpd/vsftpd.conf if it does not. Add or correct the following configuration options within the vsftpd configuration file, located at /etc/vsftpd/vsftpd.conf: xferlog_enable=YES xferlog_std_format=NO log_ftp_protocol=YES If verbose logging to vsftpd.log is done, sparse logging of downloads to /var/log/xferlog will not also occur. However, the information about what files were downloaded is included in the information logged to vsftpd.log To trace malicious activity facilitated by the FTP service, it must be configured to ensure that all commands sent to the FTP server are logged using the verbose vsftpd log format. The default vsftpd log file is /var/log/vsftpd.log. CCE-27142-9 Find if logging is applied to the FTP daemon. Procedures: If vsftpd is started by xinetd the following command will indicate the xinetd.d startup file: # grep vsftpd /etc/xinetd.d/* # grep server_args vsftpd xinetd.d startup file This will indicate the vsftpd config file used when starting through xinetd. If the server_args line is missing or does not include the vsftpd configuration file, then the default config file (/etc/vsftpd/vsftpd.conf) is used. # grep xferlog_enable vsftpd config file Edit the vsftpd configuration file, which resides at /etc/vsftpd/vsftpd.conf by default. Add or correct the following configuration options: banner_file=/etc/issue 48 This setting will cause the system greeting banner to be used for FTP connections as well. CCE-27145-2 If FTP services are not installed, this is not applicable. To verify this configuration, run the following command: grep "banner_file" /etc/vsftpd/vsftpd.conf The output should show the value of banner_file is set to /etc/issue, an example of which is shown below: # grep "banner_file" /etc/vsftpd/vsftpd.conf banner_file=/etc/issue This section describes how to disable non-anonymous (password-based) FTP logins, or, if it is not possible to do this entirely due to legacy applications, how to restrict insecure FTP login to only those users who have an identified need for this access. Is there a mission-critical reason for users to transfer files to/from their own accounts using FTP, rather than using a secure protocol like SCP/SFTP? If not, edit the vsftpd configuration file. Add or correct the following configuration option: local_enable=NO If non-anonymous FTP logins are necessary, follow the guidance in the remainder of this section to secure these logins as much as possible. The use of non-anonymous FTP logins is strongly discouraged. Since SSH clients and servers are widely available, and since SSH provides support for a transfer mode which resembles FTP in user interface, there is no good reason to allow password-based FTP access. CCE-27115-5 If there is a mission-critical reason for users to access their accounts via the insecure FTP protocol, limit the set of users who are allowed this access. Edit the vsftpd configuration file. Add or correct the following configuration options: userlist_enable=YES userlist_file=/etc/vsftp.ftpusers userlist_deny=NO Edit the file /etc/vsftp.ftpusers. For each user USERNAME who should be allowed to access the system via FTP, add a line containing that user's name: USERNAME If anonymous access is also required, add the anonymous usernames to /etc/vsftp.ftpusers as well. anonymous ftp Historically, the file /etc/ftpusers contained a list of users who were not allowed to access the system via FTP. It was used to prevent system users such as the root user from logging in via the insecure FTP protocol. However, when the configuration option userlist deny=NO is set, vsftpd interprets ftpusers as the set of users who are allowed to login via FTP. Since it should be possible for most users to access their accounts via secure protocols, it is recommended that this setting be used, so that non-anonymous FTP access can be limited to legacy users who have been explicitly identified. Is there a mission-critical reason for users to upload files via FTP? If not, edit the vsftpd configuration file to add or correct the following configuration options: write_enable=NO If FTP uploads are necessary, follow the guidance in the remainder of this section to secure these transactions as much as possible. Anonymous FTP can be a convenient way to make files available for universal download. However, it is less common to have a need to allow unauthenticated users to place files on the FTP server. If this must be done, it is necessary to ensure that files cannot be uploaded and downloaded from the same directory. CCE-27117-1 By default, the anonymous FTP root is the home directory of the FTP user account. The df command can be used to verify that this directory is on its own partition. If there is a mission-critical reason for anonymous users to upload files, precautions must be taken to prevent these users from filling a disk used by other services. By default, iptables blocks access to the ports used by the web server. To configure iptables to allow port 21 traffic one must edit /etc/sysconfig/iptables and /etc/sysconfig/ip6tables (if IPv6 is in use). Add the following line, ensuring that it appears before the final LOG and DROP lines for the INPUT chain: -A INPUT -m state --state NEW -p tcp --dport 21 -j ACCEPT Edit the file /etc/sysconfig/iptables-config. Ensure that the space-separated list of modules contains the FTP connection tracking module: IPTABLES_MODULES="ip_conntrack_ftp" These settings configure iptables to allow connections to an FTP server. The first line allows initial connections to the FTP server port. FTP is an older protocol which is not very compatible with firewalls. During the initial FTP dialogue, the client and server negotiate an arbitrary port to be used for data transfer. The ip_conntrack_ftp module is used by iptables to listen to that dialogue and allow connections to the data ports which FTP negotiates. This allows an FTP server to operate on a machine which is running a firewall. The web server is responsible for providing access to content via the HTTP protocol. Web servers represent a significant security risk because: The HTTP port is commonly probed by malicious sourcesWeb server software is very complex, and includes a long history of vulnerabilitiesThe HTTP protocol is unencrypted and vulnerable to passive monitoring The system's default web server software is Apache 2 and is provided in the RPM package httpd. If 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. The httpd service can be disabled with the following command: # chkconfig httpd off CM-7 Running web server software provides a network-based avenue of attack, and should be disabled if not needed. CCE-27075-1 To check that the httpd service is disabled in system boot configuration, run the following command: # chkconfig httpd --list Output should indicate the httpd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig httpd --list httpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify httpd is disabled through current runtime configuration: # service httpd status If the service is disabled the command will return the following output: httpd is stopped The httpd package can be removed with the following command: # yum erase httpd CM-7 If there is no need to make the web server software available, removing it provides a safeguard against its activation. CCE-27133-8 Run the following command to determine if the httpd package is installed: # rpm -q httpd If httpd was not installed and activated, but the system needs to act as a web server, then it should be installed on the system. Follow these guidelines to install it defensively. The httpd package can be installed with the following command: # yum install httpd This method of installation is recommended over installing the "Web Server" package group during the system installation process. The Web Server package group includes many packages which are likely extraneous, while the command-line method installs only the required httpd package itself. The default httpd installation minimizes the number of modules that are compiled directly into the binary (core prefork http_core mod_so). This minimizes risk by limiting the capabilities allowed by the web server. Query the set of compiled-in modules using the following command: $ httpd -l If the number of compiled-in modules is significantly larger than the aforementioned set, this guide recommends re-installing httpd with a reduced configuration. Minimizing the number of modules that are compiled into the httpd binary, reduces risk by limiting the capabilities allowed by the webserver. The httpd configuration file is /etc/httpd/conf/httpd.conf. Apply the recommendations in the remainder of this section to this file. The ServerTokens and ServerSignature directives determine how much information the web server discloses about the configuration of the system. ServerTokens Prod restricts information in page headers, returning only the word "Apache." Add or correct the following directive in /etc/httpd/conf/httpd.conf: ServerTokens Prod CM-7 Information disclosed to clients about the configuration of the web server and system could be used to plan an attack on the given system. This information disclosure should be restricted to a minimum. ServerSignature Off restricts httpd from displaying server version number on error pages. Add or correct the following directive in /etc/httpd/conf/httpd.conf: ServerSignature Off CM-7 Information disclosed to clients about the configuration of the web server and system could be used to plan an attack on the given system. This information disclosure should be restricted to a minimum. A default installation of httpd includes a plethora of dynamically shared objects (DSO) that are loaded at run-time. Unlike the aforementioned compiled-in modules, a DSO can be disabled in the configuration file by removing the corresponding LoadModule directive. Note: A DSO only provides additional functionality if associated directives are included in the httpd configuration file. It should also be noted that removing a DSO will produce errors on httpd startup if the configuration file contains directives that apply to that module. Refer to http://httpd.apache.org/docs/ for details on which directives are associated with each DSO. Following each DSO removal, the configuration can be tested with the following command to check if everything still works: # service httpd configtest The purpose of each of the modules loaded by default will now be addressed one at a time. If none of a module's directives are being used, remove it. These modules comprise a basic subset of modules that are likely needed for base httpd functionality; ensure they are not commented out in /etc/httpd/conf/httpd.conf: LoadModule auth_basic_module modules/mod_auth_basic.so LoadModule authn_default_module modules/mod_authn_default.so LoadModule authz_host_module modules/mod_authz_host.so LoadModule authz_user_module modules/mod_authz_user.so LoadModule authz_groupfile_module modules/mod_authz_groupfile.so LoadModule authz_default_module modules/mod_authz_default.so LoadModule log_config_module modules/mod_log_config.so LoadModule logio_module modules/mod_logio.so LoadModule setenvif_module modules/mod_setenvif.so LoadModule mime_module modules/mod_mome.so LoadModule autoindex_module modules/mod_autoindex.so LoadModule negotiation_module modules/mod_negotiation.so LoadModule dir_module modules/mod_dir.so LoadModule alias_module modules/mod_alias.so Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server. The following modules are necessary if this web server will provide content that will be restricted by a password. Authentication can be performed using local plain text password files (authn_file), local DBM password files (authn_dbm) or an LDAP directory. The only module required by the web server depends on your choice of authentication. Comment out the modules you don't need from the following: LoadModule authn_file_module modules/mod_authn_file.so LoadModule authn_dbm_module modules/mod_authn_dbm.so authn_alias allows for authentication based on aliases. authn_anon allows anonymous authentication similar to that of anonymous ftp sites. authz_owner allows authorization based on file ownership. authz_dbm allows for authorization based on group membership if the web server is using DBM authentication. If the above functionality is unnecessary, comment out the related module: #LoadModule authn_alias_module modules/mod_authn_alias.so #LoadModule authn_anon_module modules/mod_authn_anon.so #LoadModule authz_owner_module modules/mod_authz_owner.so #LoadModule authz_dbm_module modules/mod_authz_dbm.so The auth_digest module provides encrypted authentication sessions. If this functionality is unnecessary, comment out the related module: #LoadModule auth_digest_module modules/mod_auth_digest.so Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server. The mod_rewrite module is very powerful and can protect against certain classes of web attacks. However, it is also very complex and has a significant history of vulnerabilities itself. If its functionality is unnecessary, comment out the related module: #LoadModule rewrite_module modules/mod_rewrite.so Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server. The ldap module provides HTTP authentication via an LDAP directory. If its functionality is unnecessary, comment out the related modules: #LoadModule ldap_module modules/mod_ldap.so #LoadModule authnz_ldap_module modules/mod_authnz_ldap.so If LDAP is to be used, SSL encryption should be used as well. Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server. Server Side Includes provide a method of dynamically generating web pages through the insertion of server-side code. However, the technology is also deprecated and introduces significant security concerns. If this functionality is unnecessary, comment out the related module: #LoadModule include_module modules/mod_include.so If there is a critical need for Server Side Includes, they should be enabled with the option IncludesNoExec to prevent arbitrary code execution. Additionally, user supplied data should be encoded to prevent cross-site scripting vulnerabilities. Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server. The mime_magic module provides a second layer of MIME support that in most configurations is likely extraneous. If its functionality is unnecessary, comment out the related module: #LoadModule mime_magic_module modules/mod_mime_magic.so Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server. WebDAV is an extension of the HTTP protocol that provides distributed and collaborative access to web content. If its functionality is unnecessary, comment out the related modules: #LoadModule dav_module modules/mod_dav.so #LoadModule dav_fs_module modules/mod_dav_fs.so If there is a critical need for WebDAV, extra care should be taken in its configuration. Since DAV access allows remote clients to manipulate server files, any location on the server that is DAV enabled should be protected by access controls. Minimizing the number of loadable modules available to the web server, reduces risk by limiting the capabilities allowed by the web server. The status module provides real-time access to statistics on the internal operation of the web server. This may constitute an unnecessary information leak and should be disabled unless necessary. To do so, comment out the related module: #LoadModule status_module modules/mod_status.so If there is a critical need for this module, ensure that access to the status page is properly restricted to a limited set of hosts in the status handler configuration. Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server. The info module creates a web page illustrating the configuration of the web server. This can create an unnecessary security leak and should be disabled. If its functionality is unnecessary, comment out the module: #LoadModule info_module modules/mod_info.so If there is a critical need for this module, use the Location directive to provide an access control list to restrict access to the information. Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server. The speling module attempts to find a document match by allowing one misspelling in an otherwise failed request. If this functionality is unnecessary, comment out the module: #LoadModule speling_module modules/mod_speling.so This functionality weakens server security by making site enumeration easier. Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server. The proxy module provides proxying support, allowing httpd to forward requests and serve as a gateway for other servers. If its functionality is unnecessary, comment out the module: #LoadModule proxy_module modules/mod_proxy.so If proxy support is needed, load mod_proxy and the appropriate proxy protocol handler module (one of mod_proxy_http, mod_proxy_ftp, or mod_proxy_connect). Additionally, make certain that a server is secure before enabling proxying, as open proxy servers are a security risk. mod_proxy_balancer enables load balancing, but requires that mod status be enabled. Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server. The cache module allows httpd to cache data, optimizing access to frequently accessed content. However, it introduces potential security flaws such as the possibility of circumventing Allow and Deny directives. If this functionality is unnecessary, comment out the module: #LoadModule cache_module modules/mod_cache.so If caching is required, it should not be enabled for any limited-access content. Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server. The cgi module allows HTML to interact with the CGI web programming language. If this functionality is unnecessary, comment out the module: #LoadModule cgi_module modules/mod_cgi.so If the web server requires the use of CGI, enable mod_cgi. Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server. The following modules perform very specific tasks, sometimes providing access to just a few additional directives. If such functionality is not required (or if you are not using these directives), comment out the associated module: External filtering (response passed through external program prior to client delivery) #LoadModule ext_filter_module modules/mod_ext_filter.soUser-specified Cache Control and Expiration #LoadModule expires_module modules/mod_expires.soCompression Output Filter (provides content compression prior to client delivery) #LoadModule deflate_module modules/mod_deflate.soHTTP Response/Request Header Customization #LoadModule headers_module modules/mod_headers.soUser activity monitoring via cookies #LoadModule usertrack_module modules/mod_usertrack.soDynamically configured mass virtual hosting #LoadModule vhost_alias_module modules/mod_vhost_alias.so Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server. The Include directive directs httpd to load supplementary configuration files from a provided path. The default configuration loads all files that end in .conf from the /etc/httpd/conf.d directory. To restrict excess configuration, the following line should be commented out and replaced with Include directives that only reference required configuration files: #Include conf.d/*.conf If the above change was made, ensure that the SSL encryption remains loaded by explicitly including the corresponding configuration file: Include conf.d/ssl.conf If PHP is necessary, a similar alteration must be made: Include conf.d/php.conf Explicitly listing the configuration files to be loaded during web server start-up avoids the possibility of unwanted or malicious configuration files to be automatically included as part of the server's running configuration. The Directory tags in the web server configuration file allow finer grained access control for a specified directory. All web directories should be configured on a case-by-case basis, allowing access only where needed. The httpd root directory should always have the most restrictive configuration enabled. <Directory / > Options None AllowOverride None Order allow,deny </Directory> The Web Server's root directory content should be protected from unauthorized access by web clients. The default configuration for the web (/var/www/html) Directory allows directory indexing (Indexes) and the following of symbolic links (FollowSymLinks). Neither of these is recommended. The /var/www/html directory hierarchy should not be viewable via the web, and symlinks should only be followed if the owner of the symlink also owns the linked file. Ensure that this policy is adhered to by altering the related section of the configuration: <Directory "/var/www/html"> # ... Options SymLinksIfOwnerMatch # ... </Directory> Access to the web server's directory hierarchy could allow access to unauthorized files by web clients. Following symbolic links could also allow such access. All accessible web directories should be configured with similarly restrictive settings. The Options directive should be limited to necessary functionality and the AllowOverride directive should be used only if needed. The Order and Deny access control tags should be used to deny access by default, allowing access only where necessary. Directories accessible from a web client should be configured with the least amount of access possible in order to avoid unauthorized access to restricted content or server information. Web server methods are defined in section 9 of RFC 2616 (http://www.ietf.org/rfc/rfc2616.txt). If a web server does not require the implementation of all available methods, they should be disabled. Note: GET and POST are the most common methods. A majority of the others are limited to the WebDAV protocol. <Directory /var/www/html> # ... # Only allow specific methods (this command is case-sensitive!) <LimitExcept GET POST> Order allow,deny </LimitExcept> # ... </Directory> Minimizing the number of available methods to the web client reduces risk by limiting the capabilities allowed by the web server. Among the modules available for httpd are several whose use may improve the security of the web server installation. This section recommends and discusses the deployment of security-relevant modules. Because HTTP is a plain text protocol, all traffic is susceptible to passive monitoring. If there is a need for confidentiality, SSL should be configured and enabled to encrypt content. Note: mod_nss is a FIPS 140-2 certified alternative to mod_ssl. The modules share a considerable amount of code and should be nearly identical in functionality. If FIPS 140-2 validation is required, then mod_nss should be used. If it provides some feature or its greater compatibility is required, then mod_ssl should be used. Install the mod_ssl module: # yum install mod_ssl mod_ssl provides encryption capabilities for the httpd Web server. Unencrypted content is transmitted in plain text which could be passively monitored and accessed by unauthorized parties. CCE-27403-5 The security module provides an application level firewall for httpd. Following its installation with the base ruleset, specific configuration advice can be found at http://www.modsecurity.org/ to design a policy that best matches the security needs of the web applications. Usage of mod_security is highly recommended for some environments, but it should be noted this module does not ship with Red Hat Enterprise Linux itself, and instead is provided via Extra Packages for Enterprise Linux (EPEL). For more information on EPEL please refer to http://fedoraproject.org/wiki/EPEL. Install the security module: # yum install mod_security mod_security provides an additional level of protection for the web server by enabling the administrator to implement content access policies and filters at the application layer. CCE-27525-5 Denial-of-service attacks are difficult to detect and prevent while maintaining acceptable access to authorized users. However, some traffic-shaping modules can be used to address the problem. Well-known DoS protection modules include: mod_cband mod_bwshare mod_limitipconn mod_evasive Denial-of-service prevention should be implemented for a web server if such a threat exists. However, specific configuration details are very dependent on the environment and often best left at the discretion of the administrator. PHP is a widely-used and often misconfigured server-side scripting language. It should be used with caution, but configured appropriately when needed. Review /etc/php.ini and make the following changes if possible: # Do not expose PHP error messages to external users display_errors = Off # Enable safe mode safe_mode = On # Only allow access to executables in isolated directory safe_mode_exec_dir = php-required-executables-path # Limit external access to PHP environment safe_mode_allowed_env_vars = PHP_ # Restrict PHP information leakage expose_php = Off # Log all errors log_errors = On # Do not register globals for input data register_globals = Off # Minimize allowable PHP post size post_max_size = 1K # Ensure PHP redirects appropriately cgi.force_redirect = 0 # Disallow uploading unless necessary file_uploads = Off # Disallow treatment of file requests as fopen calls allow_url_fopen = Off # Enable SQL safe mode sql.safe_mode = On The following configuration steps should be taken on the machine which hosts the web server, in order to provide as safe an environment as possible for the web server. Minimize access to critical httpd files and directories. Ensure that the permissions on the web server log directory is set to 700: # chmod 700 /var/log/httpd/ This is its default setting. CM-7 Access to the web server's log files may allow an unauthorized user or attacker to access information about the web server or alter the server's log files. CCE-27150-2 Set permissions on the web server configuration directory to 750: # chmod 750 /etc/httpd/conf/ Access to the web server's configuration files may allow an unauthorized user or attacker to access information about the web server or alter the server's configuration files. Set permissions on the web server configuration files to 640: # chmod 640 /etc/httpd/conf/* CM-7 Access to the web server's configuration files may allow an unauthorized user or attacker to access information about the web server or to alter the server's configuration files. By default, iptables blocks access to the ports used by the web server. To configure iptables to allow port 80 traffic one must edit /etc/sysconfig/iptables and /etc/sysconfig/ip6tables (if IPv6 is in use). Add the following line, ensuring that it appears before the final LOG and DROP lines for the INPUT chain: -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT To configure iptables to allow port 443 traffic one must edit /etc/sysconfig/iptables and /etc/sysconfig/ip6tables (if IPv6 is in use). Add the following line, ensuring that it appears before the final LOG and DROP lines for the INPUT chain: -A INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT Running httpd inside a chroot jail is designed to isolate the web server process to a small section of the filesystem, limiting the damage if it is compromised. Versions of Apache greater than 2.2.10 (such as the one included with RHEL 6) provide the ChrootDir directive. To run Apache inside a chroot jail in /chroot/apache, add the following line to /etc/httpd/conf/httpd.conf: ChrootDir /chroot/apache This necessitates placing all files required by httpd inside /chroot/apache , including httpd's binaries, modules, configuration files, and served web pages. The details of this configuration are beyond the scope of this guide. This may also require additional SELinux configuration. Dovecot 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. If the system does not need to operate as an IMAP or POP3 server, the dovecot software should be disabled and removed. The dovecot service can be disabled with the following command: # chkconfig dovecot off Running an IMAP or POP3 server provides a network-based avenue of attack, and should be disabled if not needed. CCE-26922-5 To check that the dovecot service is disabled in system boot configuration, run the following command: # chkconfig dovecot --list Output should indicate the dovecot service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig dovecot --list dovecot 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify dovecot is disabled through current runtime configuration: # service dovecot status If the service is disabled the command will return the following output: dovecot is stopped The dovecot package can be uninstalled with the following command: # yum erase dovecot If there is no need to make the Dovecot software available, removing it provides a safeguard against its activation. CCE-27039-7 Run the following command to determine if the dovecot package is installed: # rpm -q dovecot If the system will operate as an IMAP or POP3 server, the dovecot software should be configured securely by following the recommendations below. Dovecot supports the IMAP and POP3 protocols, as well as SSL-protected versions of those protocols. Configure the Dovecot server to support only the protocols needed by your site. Edit /etc/dovecot/dovecot.conf. Add or correct the following lines, replacing PROTOCOL with only the subset of protocols (imap, imaps, pop3, pop3s) required: protocols = PROTOCOL If possible, require SSL protection for all transactions. The SSL protocol variants listen on alternate ports (995 instead of 110 for pop3s, and 993 instead of 143 for imaps), and require SSL-aware clients. An alternate approach is to listen on the standard port and require the client to use the STARTTLS command before authenticating. Configuring Dovecot to only support the protocols the protocols needed by your site reduces the risk of an attacker using one of the unused protocols to base an attack. SSL should be used to encrypt network traffic between the Dovecot server and its clients. Users must authenticate to the Dovecot server in order to read their mail, and passwords should never be transmitted in clear text. In addition, protecting mail as it is downloaded is a privacy measure, and clients may use SSL certificates to authenticate the server, preventing another system from impersonating the server. To allow clients to make encrypted connections the ssl flag in Dovecot's configuration file needs to be set to yes. Edit /etc/dovecot/conf.d/10-ssl.conf and add or correct the following line: ssl = yes SSL encrypt network traffic between the Dovecot server and its clients protecting user credentials, mail as it is downloaded, and clients may use SSL certificates to authenticate the server, preventing another system from impersonating the server. CCE-27571-9 This option tells Dovecot where to find the the mail server's SSL Certificate. Edit /etc/dovecot/conf.d/10-ssl.conf and add or correct the following line (note: the path below is the default path set by the Dovecot installation. If you are using a different path, ensure you reference the appropriate file): ssl_cert = </etc/pki/dovecot/certs/dovecot.pem SSL certificates are used by the client to authenticate the identity of the server, as well as to encrypt credentials and message traffic. Not using SSL to encrypt mail server traffic could allow unauthorized access to credentials and mail messages since they are sent in plain text over the network. CCE-27459-7 This option tells Dovecot where to find the the mail server's SSL Key. Edit /etc/dovecot/conf.d/10-ssl.conf and add or correct the following line (note: the path below is the default path set by the Dovecot installation. If you are using a different path, ensure you reference the appropriate file): ssl_key = </etc/pki/dovecot/private/dovecot.pem SSL certificates are used by the client to authenticate the identity of the server, as well as to encrypt credentials and message traffic. Not using SSL to encrypt mail server traffic could allow unauthorized access to credentials and mail messages since they are sent in plain text over the network. CCE-27633-7 To prevent Dovecot from attempting plaintext authentication of clients, edit /etc/dovecot/conf.d/10-auth.conf and add or correct the following line: disable_plaintext_auth = yes Using plain text authentication to the mail server could allow an attacker access to credentials by monitoring network traffic. CCE-27144-5 The default iptables configuration does not allow inbound access to any services. This modification will allow remote hosts to initiate connections to the IMAP daemon, while keeping all other ports on the server in their default protected state. To configure iptables to allow port 143 traffic one must edit /etc/sysconfig/iptables and /etc/sysconfig/ip6tables (if IPv6 is in use). Add the following line, ensuring that it appears before the final LOG and DROP lines for the INPUT chain: -A INPUT -m state --state NEW -p tcp --dport 143 -j ACCEPT When 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, samba-client, provides a series of command line tools that enable a client machine to access Samba shares. The second, simply labeled samba, provides the Samba service. It is this second package that allows a Linux machine to act as an Active Directory server, a domain controller, or as a domain member. Only the samba-client package is installed by default. Even 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. The smb service can be disabled with the following command: # chkconfig smb off 1436 Running a Samba server provides a network-based avenue of attack, and should be disabled if not needed. CCE-27143-7 To check that the smb service is disabled in system boot configuration, run the following command: # chkconfig smb --list Output should indicate the smb service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig smb --list smb 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify smb is disabled through current runtime configuration: # service smb status If the service is disabled the command will return the following output: smb is stopped All settings for the Samba daemon can be found in /etc/samba/smb.conf. Settings are divided between a [global] configuration section and a series of user created share definition sections meant to describe file or print shares on the system. By default, Samba will operate in user mode and allow client machines to access local home directories and printers. It is recommended that these settings be changed or that additional limitations be set in place. Only users with local user accounts will be able to log in to Samba shares by default. Shares can be limited to particular users or network addresses. Use the hosts allow and hosts deny directives accordingly, and consider setting the valid users directive to a limited subset of users or to a group of users. Separate each address, user, or user group with a space as follows for a particular share or global: [share] hosts allow = 192.168.1. 127.0.0.1 valid users = userone usertwo @usergroup It is also possible to limit read and write access to particular users with the read list and write list options, though the permissions set by the system itself will override these settings. Set the read only attribute for each share to ensure that global settings will not accidentally override the individual share settings. Then, as with the valid users directive, separate each user or group of users with a space: [share] read only = yes write list = userone usertwo @usergroup The Samba service is only required for sharing files and printers with Microsoft Windows workstations, and even then, other options may exist. Administrators should not use administrator accounts to access Samba file and printer shares. Disable the root user and the wheel administrator group: [share] invalid users = root @wheel If administrator accounts cannot be disabled, ensure that local machine passwords and Samba service passwords do not match. Typically, administrator access is required when Samba must create user and machine accounts and shares. Domain member servers and standalone servers may not need administrator access at all. If that is the case, add the invalid users parameter to [global] instead. To require samba clients running smbclient to use packet signing, add the following to the [global] section of the Samba configuration file, /etc/samba/smb.conf: client signing = mandatory Requiring samba clients such as smbclient to use packet signing ensures they can only communicate with servers that support packet signing. Packet signing can prevent man-in-the-middle attacks which modify SMB packets in transit. CCE-26328-5 To verify that Samba clients running smbclient must use packet signing, run the following command: # grep signing /etc/samba/smb.conf The output should show: client signing = mandatory Require packet signing of clients who mount Samba shares using the mount.cifs program (e.g., those who specify shares in /etc/fstab). To do so, ensure signing options (either sec=krb5i or sec=ntlmv2i) are used. See the mount.cifs(8) man page for more information. A Samba client should only communicate with servers who can support SMB packet signing. Packet signing can prevent man-in-the-middle attacks which modify SMB packets in transit. CCE-26792-2 To verify that Samba clients using mount.cifs must use packet signing, run the following command: # grep sec /etc/fstab The output should show either krb5i or ntlmv2i in use. By default, Samba utilizes the CUPS printing service to enable printer sharing with Microsoft Windows workstations. If there are no printers on the local machine, or if printer sharing with Microsoft Windows is not required, disable the printer sharing capability by commenting out the following lines, found in /etc/samba/smb.conf: [global] load printers = yes cups options = raw [printers] comment = All Printers path = /usr/spool/samba browseable = no guest ok = no writable = no printable = yes There may be other options present, but these are the only options enabled and uncommented by default. Removing the [printers] share should be enough for most users. If the Samba printer sharing capability is needed, consider disabling the Samba network browsing capability or restricting access to a particular set of users or network addresses. Set the valid users parameter to a small subset of users or restrict it to a particular group of users with the shorthand @. Separate each user or group of users with a space. For example, under the [printers] share: [printers] valid users = user @printerusers The Samba service is only required for sharing files and printers with Microsoft Windows workstations, and even then, other options may exist. Do not use the Samba service to share files between Unix or Linux machines. A 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. If Squid was installed and activated, but the system does not need to act as a proxy server, then it should be disabled and removed. The squid service can be disabled with the following command: # chkconfig squid off Running proxy server software provides a network-based avenue of attack, and should be removed if not needed. CCE-27146-0 To check that the squid service is disabled in system boot configuration, run the following command: # chkconfig squid --list Output should indicate the squid service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig squid --list squid 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify squid is disabled through current runtime configuration: # service squid status If the service is disabled the command will return the following output: squid is stopped The squid package can be removed with the following command: # yum erase squid If there is no need to make the proxy server software available, removing it provides a safeguard against its activation. CCE-26977-9 Run the following command to determine if the squid package is installed: # rpm -q squid The 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. The 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. The snmpd service can be disabled with the following command: # chkconfig snmpd off Running SNMP software provides a network-based avenue of attack, and should be disabled if not needed. CCE-26906-8 To check that the snmpd service is disabled in system boot configuration, run the following command: # chkconfig snmpd --list Output should indicate the snmpd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig snmpd --list snmpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify snmpd is disabled through current runtime configuration: # service snmpd status If the service is disabled the command will return the following output: snmpd is stopped The net-snmp package provides the snmpd service. The net-snmpd package can be removed with the following command: # yum erase net-snmpd If there is no need to run SNMP server software, removing the package provides a safeguard against its activation. CCE-26332-7 Run the following command to determine if the net-snmpd package is installed: # rpm -q net-snmpd If it is necessary to run the snmpd agent on the system, some best practices should be followed to minimize the security risk from the installation. The multiple security models implemented by SNMP cannot be fully covered here so only the following general configuration advice can be offered: use only SNMP version 3 security models and enable the use of authentication and encryptionwrite access to the MIB (Management Information Base) should be allowed only if necessaryall access to the MIB should be restricted following a principle of least privilegenetwork access should be limited to the maximum extent possible including restricting to expected network addresses both in the configuration files and in the system firewall rulesensure SNMP agents send traps only to, and accept SNMP queries only from, authorized management stationsensure that permissions on the snmpd.conf configuration file (by default, in /etc/snmp) are 640 or more restrictiveensure that any MIB files' permissions are also 640 or more restrictive Edit /etc/snmp/snmpd.conf, removing any references to v1, v2c, or com2sec. Upon doing that, restart the SNMP service: # service snmpd restart Earlier versions of SNMP are considered insecure, as they potentially allow unauthorized access to detailed system management information. To ensure only SNMPv3 or newer is used, run the following command: # grep 'v1\|v2c\|com2sec' /etc/snmp/snmpd.conf | grep -v "^#" There should be no output. Edit /etc/snmp/snmpd.conf, remove default community string public. Upon doing that, restart the SNMP service: # service snmpd restart MAN 20121214 Presence of the default SNMP password enables querying of different system aspects and could result in unauthorized knowledge of the system. To ensure the default password is not set, run the following command: # grep -v "^#" /etc/snmp/snmpd.conf| grep public There should be no output.