SCAP: Guide To The Secure Configuration of Red Hat Enterprise Linux 5

This guide has been created to assist IT professionals, in effectively securing systems with Red Hat Enterprise Linux 5.

RED HAT ENTERPRISE LINUX 5 SECURITY CHECKLIST

Table of Contents

1 - Introduction

The purpose of this guide is to provide security configuration recommendations for the Red Hat Enterprise Linux (RHEL) 5 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 commonly-used services that the system can host in a network environment. 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.

1.1 - General Principles

The following general principles motivate much of the advice in this guide and should also influence any configuration decisions that are not explicitly covered.

1.1.1 - Encrypt Transmitted Data Whenever Possible

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 RHEL5 machines can and should be configured so that no unencrypted authentication data is ever transmitted between machines.

1.1.2 - Minimize Software to Minimize Vulnerability

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.

1.1.3 - Run Different Network Services on Separate Systems

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.

1.1.4 - Configure Security Tools to Improve System Robustness

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.

1.2 - How to Use This Guide

Readers should heed the following points when using the guide.

1.2.1 - Read Sections Completely and in Order

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 will occur after instructions for an action. The system-level configuration guidance in Chapter 2 must be applied to all machines. The guidance for individual services in Chapter 3 must be considered for all machines as well: apply the guidance if the machine is either a server or a client for that service, and ensure that the service is disabled according to the instructions provided if the machine is neither a server nor a client.

1.2.2 - Test in Non-Production Environment

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.

1.2.3 - Root Shell Environment Assumed

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. Any 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.

1.2.4 - Formatting Conventions

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.

1.2.5 - Reboot Required

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.

2 - System-wide Configuration

2.1 - Installing and Maintaining Software

The following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates.

2.1.1 - Initial Installation Recommendations

The recommendations here apply to a clean installation of the system, where any previous installations are wiped out. The sections presented here are in the same order that the installer presents, but only installation choices with security implications are covered. Many of the configuration choices presented here can also be applied after the system is installed. The choices can also be automatically applied via Kickstart files, as covered in [8].

2.1.1.1 - Disk Partitioning

If using any of the default layouts, check the box to “Review and modify partitioning.” The default layout does not create separate partitions or logical volumes for /var and /tmp. Add logical volumes or partitions for at least /var and /tmp. Adding logical volumes or partitions for /var/log and /var/log/audit may also be necessary, depending on system requirements. (See Section 2.6 for more information about logging and auditing). If user home directories will be stored locally, create a separate partition for /home as well. If creating a custom layout, create the partitions mentioned in the previous paragraph, as well as separate ones for /, /boot and swap space. You may need to make the / logical volume smaller to create space for the additional partitions.

2.1.1.2 - Boot Loader Configuration

Check the box to “Use a boot loader password” and create a password. Once this password is set, anyone who wishes to change the boot loader configuration will need to enter it. More information is available in Section 2.3.5.2. Assigning a boot loader password prevents a local user with physical access from altering the boot loader configuration at system startup.

2.1.1.3 - Network Devices

The default network device configuration uses DHCP, which is not recommended. Unless use of DHCP is absolutely necessary, click the “Edit” button and: * Uncheck “Use Dynamic IP configuration (DHCP).” * Uncheck “Enable IPv4 Support” if the system does not require IPv4. (This is uncommon.) * Uncheck “Enable IPv6 Support” if the system does not require IPv6. * Enter appropriate IPv4 and IPv6 addresses and prefixes as required. With the DHCP setting disabled, the hostname, gateway, and DNS servers should then be assigned on the main screen. Sections 3.9.1 and 3.9.2 contain more information on network configuration and the use of DHCP.

2.1.1.4 - Root Password

The security of the entire system depends on the strength of the root password. The password should be at least 12 characters long, and should include a mix of capitalized and lowercase letters, special characters, and numbers. It should also not be based on any dictionary word.

2.1.1.5 - Software Packages

Uncheck all package groups, including the package groups “Software Development” and “Web Server,” unless there is a specific requirement to install software using the system installer. If the machine will be used as a web server, it is preferable to manually install the necessary RPMs instead of installing the full “Web Server” package group. See Section 3.16 for installation and configuration details. Use the “Customize now” radio box to prune package groups as much as possible. This brings up a two-column view of categories and package groups. If appropriate, uncheck “X Window System” in the “Base System” category to avoid installing X entirely. Any other package groups not necessary for system operation should also be unchecked. Much finer-grained package selection is possible via Kickstart as described in [8].

2.1.1.6 - First-boot Configuration

The system presents more configuration options during the first boot after installation. For the screens listed, implement the security-related recommendations: Screen Recommendation Firewall Leave set to “Enabled.” Only check the “Trusted Services” that this system needs to serve. Uncheck the default selection of SSH if the system does not need to serve SSH. SELinux Leave SELinux set to “Enforcing” mode. Kdump Leave Kdump off unless the feature is required, such as for kernel development and testing. Screen Recommendation Set Up Software Updates If the system is connected to the Internet now, click “Yes, I’d like to register now.” This will require a connection to either the Red Hat Network servers or their proxies or satellites. This can also be configured later as described in Section 2.1.2.1. Create User If the system will require a local user account, it can be created here. Even if the system will be using a network-wide authentication system as described in Section 2.3.6, do not click on the “Use Network Login...” button. Manually applying configuration later is preferable.

2.1.2 - Updating Software

The yum command line tool is used to install and update software packages. Yum replaces the up2date utility used in previous system releases. The system also provides two graphical package managers, pirut and pup. The pirut tool is a graphical front-end for yum that allows users to install and update packages while pup is a simple update tool for packages that are already installed. In the Applications menu, pirut is labeled Add/Remove Software and pup is labeled Software Updater. It is recommended that these tools be used to keep systems up to date with the latest security patches.

2.1.2.1 - Configure Connection to the RHN RPM Repositories

The first step in configuring a system for updates is to register with the Red Hat Network (RHN). For most systems, this is done during the initial installation. Successfully registered systems will appear on the RHN web site. If the system is not listed, run the Red Hat Network Registration tool, which can be found in the Applications menu under System Tools or on the command line: # rhn register Follow the prompts on the screen. If successful, the system will appear on the RHN web site and be subscribed to one or more software update channels. Additionally, a new daemon, rhnsd, will be enabled. If the system will not have access to the Internet, it will not be able to directly subscribe to the RHN update repository. Updates will have to be downloaded from the RHN web site manually. The command line tool yum and the graphical front-ends pirut and pup can be configured to handle this situation.

2.1.2.2 - Disable the rhnsd Daemon

The rhnsd daemon polls the Red Hat Network web site for scheduled actions. Unless it is actually necessary to schedule updates remotely through the RHN website, it is recommended that the service be disabled. # chkconfig rhnsd off The rhnsd daemon is enabled by default, but until the system has been registered with the Red Hat Network, it will not run. However, once the registration process is complete, the rhnsd daemon will run in the background and periodically call the rhn check utility. It is the rhn check utility that communicates with the Red Hat Network web site. This utility is not required for the system to be able to access and install system updates. Once the system has been registered, either use the provided yum-updatesd service or create a cron job to automatically apply updates.

2.1.2.3 - Obtain Software Package Updates with yum

The yum update utility can be run by hand from the command line, called through one of the provided front-end tools, or configured to run automatically at specified intervals.

2.1.2.3.1 - Manually Update Packages Where Appropriate

The following command prints a list of packages that need to be updated: # yum check-update To actually install these updates, run: # yum update

2.1.2.3.2 - Configure Automatic Update Retrieval and Installation with Cron

The yum-updatesd service is not mature enough for an enterprise environment, and the service may introduce unnecessary overhead. When possible, replace this service with a cron job that calls yum directly. Disable the yum-updatesd service: # chkconfig yum-updatesd off Create the file yum.cron, make it executable, and place it in /etc/cron.daily: #!/bin/sh /usr/bin/yum -R 120 -e 0 -d 0 -y update yum /usr/bin/yum -R 10 -e 0 -d 0 -y update This particular script instructs yum to update any packages it finds. Placing the script in /etc/cron.daily ensures its daily execution. To only apply updates once a week, place the script in /etc/cron.weekly instead.

2.1.3 - Software Integrity Checking

The AIDE (Advanced Intrusion Detection Environment) software is included with the system to provide software integrity checking. It is designed to be a replacement for the well-known Tripwire integrity checker. Integrity checking cannot prevent intrusions into your system, but can detect that they have occurred. Any integrity checking software should be configured before the system is deployed and able to provides services to users. Ideally, the integrity checking database would be built before the system is connected to any network, though this may prove impractical due to registration and software updates.

2.1.3.1 - Configure AIDE

Requirements for software integrity checking should be defined by policy, and this is highly dependent on the environment in which the system will be used. As such, a general strategy for implementing integrity checking is provided, but precise recommendations (such as to check a particular file) cannot be. Documentation for AIDE, including the quick-start on which this advice is based, is available in /usr/share/doc/aide-0.12.

2.1.3.1.1 - Install AIDE

AIDE is not installed by default. Install it with the command: # yum install aide

2.1.3.1.2 - Customize Configuration File

Customize /etc/aide.conf to meet your requirements. The default configuration is acceptable for many environments. The man page aide.conf(5) provides detailed information about the configuration file format.

2.1.3.1.3 - Build, Store, and Test Database

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. The database, as well as the configuration file /etc/aide.conf and the binary /usr/sbin/aide (or hashes of these files) should be copied and stored in a secure location. Storing these copies or hashes on read-only media may provide further confidence that they will not be altered. Install the newly-generated database: # cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz Run a manual check: # /usr/sbin/aide --check If this check produces any unexpected output, investigate.

2.1.3.1.4 - Implement Periodic Execution of Integrity Checking

By default, AIDE does not install itself for periodic execution. Implement checking with whatever frequency is required by your security policy. A once-daily check may be suitable for many environments. For example, to implement a daily execution of AIDE at 4:05am, add the following line to /etc/crontab: 05 4 * * * root /usr/sbin/aide --check AIDE output may be an indication of an attack against your system, or it may be the result of something innocuous such as an administrator’s configuration change or a software update. The steps in Section 2.1.3.1.3 should be repeated when configuration changes or software updates necessitate. This will certainly be necessary after applying guidance later in this guide.

2.1.3.1.5 - Manually Verify Integrity of AIDE

Because integrity checking is a means of intrusion detection and not intrusion prevention, it cannot be guaranteed that the AIDE binaries, configuration files, or database have not been tampered with. An attacker could disable or alter these files after a successful intrusion. Because of this, manual and frequent checks on these files is recommended. The safely stored copies (or hashes) of the database, binary, and configuration file were created earlier for this purpose. Manually verify the integrity of the AIDE binaries, configuration file, and database. Possibilities for doing so include: 1. Use sha1sum or md5sum to generate checksums on the files and then visually compare them to those generated from the safely stored versions. This does not, of course, preclude the possibility that such output could also be faked. 2. Mount the stored versions on read-only media and run /bin/diff to verify that there are no differences between the files. 3. Copying the files to another system and performing the hash or file comparisons there may impart additional confidence that the manual verification process is not being interfered with.

2.2 - File Permissions and Masks

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. However, Linux systems contain a large number of files, so it is often prohibitively time-consuming to ensure that every file on a machine has exactly the permissions needed. This section introduces several permission restrictions which are almost always appropriate for system security, and which are easy to test and correct. 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 ext2 or ext3 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 ext2 and ext3 partitions on a given machine: $ mount -t ext2,ext3 | awk '{print $3}' If your site uses a local filesystem type other than ext2 or ext3, you will need to modify this command.

2.2.1 - Restrict Partition Mount Options

System partitions can be mounted with certain options which limit what files on those partitions can do. These options are set in the file /etc/fstab, and can be used to make certain types of malicious behavior more difficult.

2.2.1.1 - Add nodev Option to Non-Root Local Partitions

Edit the file /etc/fstab. The important columns for purposes of this section are column 2 (mount point), column 3 (filesystem type), and column 4 (mount options). For any line which satisfies all of the conditions: * The filesystem type is ext2 or ext3 * The mount point is not / add the text “,nodev” to the list of mount options in column 4. The nodev option prevents users from mounting unauthorized devices on any partition which is known not to contain any authorized devices. The root partition typically contains the /dev partition, which is the primary location for authorized devices, so this option should not be set on /. However, if system programs are being run in chroot jails, this advice may need to be modified further, since it is often necessary to create device files inside the chroot directory for use by the restricted program.

2.2.1.2 - Add nodev, nosuid, and noexec Options to Removable Media Partitions

Edit the file /etc/fstab. Filesystems which represent removable media can be located by finding lines whose mount points contain strings like floppy or cdrom, or whose types are iso9660, vfat, or msdos. For each line representing a removable media mountpoint, add the text ,nodev,nosuid to the list of mount options in column 4. If appropriate, also add the text ,noexec. Users should not be allowed to introduce arbitrary devices or setuid programs to a system. These options are used to prevent that. In addition, while users are usually allowed to add executable programs to a system, 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.

2.2.2 - Restrict Dynamic Mounting and Unmounting of Filesystems

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. 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.

2.2.2.1 - Restrict Console Device Access

The default system configuration grants the console user enhanced privileges normally reserved for the root user, including temporary ownership of most system devices. If not necessary, these privileges should be removed and restricted to root only. Restrict device ownership to root only. Edit /etc/security/console.perms.d/50-default.perms and locate the section prefaced by the following comment: # permission definitions Prepend a # symbol to comment out each line in that section which starts with <console> or <xconsole>: #<console> 0660 <floppy> 0660 root.floppy #<console> 0600 <sound> 0600 root ... #<xconsole> 0600 /dev/console 0600 root.root #<console> 0600 <dri> 0600 root Edit /etc/security/console.perms and make the following changes: <console>=tty[0-9][0-9]* vc/[0-9][0-9]* :0\.[0-9] :0 <xconsole>=:0\.[0-9] :0

2.2.2.2 - Disable USB Device Support

USB flash or hard drives allow an attacker with physical access to a system to quickly copy an enormous amount of data from it.

2.2.2.2.1 - Disable Modprobe Loading of USB Storage Driver

If USB storage devices should not be used, the modprobe program used for automatic kernel module loading should be configured to not load the USB storage driver upon demand. Add the following line to /etc/modprobe.conf to prevent loading of the usb-storage kernel module: install usb-storage : 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.

2.2.2.2.2 - Remove USB Storage Driver

If your system never requires the use of USB storage devices, then the supporting driver can be removed. Though more effective (as USB storage certainly cannot be used if the driver is not available at all), this is less elegant than the method described in Section 2.2.2.2.1. To remove the USB storage driver from the system: rm /lib/modules/kernelversion(s) /kernel/drivers/usb/storage/usb-storage.ko This command will need to be repeated every time the kernel is updated. This command will also cause the command rpm -q --verify kernel to fail, which may be an undesirable side effect. Note that this guidance will not prevent USB storage devices from being mounted if a custom kernel (i.e., not the one supplied with the system) with built-in USB support is used.

2.2.2.2.3 - Disable Kernel Support for USB via Bootloader Configuration

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. 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. 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

2.2.2.2.4 - Disable Booting from USB Devices

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 Section 2.3.5.1 to prevent unauthorized configuration changes.

2.2.2.3 - Disable the Automounter if Possible

If the autofs service is not needed to dynamically mount NFS filesystems or removable media, disable the service: # chkconfig autofs off 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.

2.2.2.4 - Disable GNOME Automounting if Possible

The system’s default desktop environment, GNOME, runs the program gnome-volume-manager to mount devices and removable media (such as DVDs, CDs and USB flash drives) whenever they are inserted into the system. Execute the following commands to prevent gnome-volume-manager from automatically mounting devices and media: # gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type bool \ --set /desktop/gnome/volume_manager/automount_media false # gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type bool \ --set /desktop/gnome/volume_manager/automount_drives false Verify the changes by executing the following command, which should return a list of settings: # gconftool-2 -R /desktop/gnome/volume_manager The automount drives and automount media settings should be set to false. Survey the list for any other options that should be adjusted. The system’s capabilities for automatic mounting should be configured to match whatever is defined by security policy. Disabling USB storage as described in Section 2.2.2.2.1 will prevent the use of USB storage devices, but this step can also be taken as an additional layer of prevention and to prevent automatic mounting of CDs and DVDs if required. Particularly for kiosk-style systems, where users should have extremely limited access to the system, more detailed information can be found in Red Hat Desktop: Deployment Guide [5]. The gconf-editor program, available in an RPM of the same name, can be used to explore other settings available in the GNOME environment.

2.2.3 - Verify Permissions on Important Files and Directories

Permissions for many files on a system should be set to conform to system policy. This section discusses important permission restrictions gshadow which should be checked on a regular basis to ensure that no harmful discrepancies have arisen.

2.2.3.1 - Verify Permissions on passwd, shadow, group and gshadow Files

# cd /etc # chown root:root passwd shadow group gshadow # chmod 644 passwd group # chmod 400 shadow gshadow These are the default permissions for these files. 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.

2.2.3.2 - Verify that All World-Writable Directories Have Sticky Bits Set

Locate any directories in local partitions which are world-writable and do not have their sticky bits set. The following command will discover and print these. Run it once for each local partition PART: # find PART -xdev -type d \( -perm -0002 -a ! -perm -1000 \) -print If this command produces any output, fix each reported directory /dir using the command: # chmod +t /dir 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.

2.2.3.3 - Find Unauthorized World-Writable Files

The following command discovers and prints any world-writable files in local partitions. Run it once for each local partition PART: # find PART -xdev -type f -perm -0002 -print If this command produces any output, fix each reported file file using the command: # chmod o-w file 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. 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.

2.2.3.4 - Find Unauthorized SUID/SGID System Executables

The following command discovers and prints any setuid or setgid files on local partitions. Run it once for each local partition PART: # find PART -xdev \( -perm -4000 -o -perm -2000 \) -type f -print If the file does not require a setuid or setgid bit as discussed below, then these bits can be removed with the command: # chmod -s file The following table contains all setuid and setgid files which are expected to be on a stock system. The setuid or setgid bit on these files may be disabled to reduce system risk if only an administrator requires their functionality. The table indicates those files which may not be needed. Note: Several of these files are used for applications which are unlikely to be relevant to most production environments, such as ISDN networking, SSH hostbased authentication, or modification of network interfaces by unprivileged users. It is extremely likely that your site can disable a subset of these files with no loss of functionality. Any files found by the above command which are not in the table should be examined. If the files are not authorized, they should have permissions removed, and further investigation may be warranted. File Set-ID Subsystem/Ref Disable? /bin/mount uid root filesystems no /bin/ping uid root net (3.3.9) no /bin/ping6 uid root net (3.3.9),IPv6 (2.5.3) unless IPv6 is used /bin/su uid root auth (2.3.1.2) no /bin/umount uid root filesystems no /sbin/mount.nfs uid root NFS (3.13) unless NFS is used /sbin/mount.nfs4 uid root NFS (3.13) unless NFSv4 is used /sbin/netreport gid root net (3.3.9) unless users must modify interfaces /sbin/pam timestamp check uid root PAM auth (2.3.3) no /sbin/umount.nfs uid root NFS (3.13) unless NFS is used /sbin/umount.nfs4 uid root NFS (3.13) unless NFSv4 is used /sbin/unix chkpwd uid root PAM auth (2.3.3) no /usr/bin/at uid root cron/at (3.4) no /usr/bin/chage uid root passwd expiry (2.3.1.7) unless users must view expiry info /usr/bin/chfn uid root user info unless users must change finger info /usr/bin/chsh uid root user info unless users must change shells /usr/bin/crontab uid/gid root cron/at (3.4) unless users must use cron /usr/bin/gpasswd uid root group auth no /usr/bin/locate gid slocate locate database no /usr/bin/lockfile gid mail procmail unless procmail is used /usr/bin/newgrp uid root group auth no /usr/bin/passwd uid root passwd auth no /usr/bin/rcp uid root rsh (3.2.3) yes (rsh is obsolete) /usr/bin/rlogin uid root rsh (3.2.3) yes (rsh is obsolete) /usr/bin/rsh uid root rsh (3.2.3) yes (rsh is obsolete) /usr/bin/ssh-agent gid nobody SSH (3.5) no /usr/bin/sudo uid root sudo (2.3.1.3) no /usr/bin/sudoedit uid root sudo (2.3.1.3) no /usr/bin/wall gid tty console messaging unless console messaging is used /usr/bin/write gid tty console messaging unless console messaging is used /usr/bin/Xorg uid root X11 (3.6) unless X11 is used /usr/kerberos/bin/ksu uid root Kerberos auth (2.3.6) unless Kerberos is used /usr/libexec/openssh/ssh-keysign uid root SSH (3.5) unless sshd uses hostbased auth /usr/libexec/utempter/utempter gid utmp terminal support no /usr/lib/squid/pam auth uid root squid (3.19) unless squid is used /usr/lib/squid/ncsa auth uid root squid (3.19) unless squid is used /usr/lib/vte/gnome-pty-helper gid utmp X11, Gnome (3.6) unless X11 is used /usr/sbin/ccreds validate uid root PAM auth (2.3.3) unless PAM auth caching is used /usr/sbin/lockdev gid lock filesystems no /usr/sbin/sendmail.sendmail gid smmsp sendmail client (3.11.2) no /usr/sbin/suexec uid root apache (3.16) unless apache is used /usr/sbin/userhelper uid root PAM auth (2.3.3.4) restrict (see section) /usr/sbin/userisdnctl uid root ISDN unless ISDN is used /usr/sbin/usernetctl uid root user network control unless users must modify interfaces

2.2.3.5 - Find and Repair Unowned Files

The following command will discover and print any files on local partitions which do not belong to a valid user and a valid group. Run it once for each local partition PART: # find PART -xdev \( -nouser -o -nogroup \) -print If this command prints any results, investigate each reported file and either assign it to an appropriate user and group or remove it. Unowned files are not directly exploitable, but they are generally a sign that something is wrong with some system process. They may be caused by an intruder, by incorrect software installation or incomplete software removal, or by failure to remove all files belonging to a deleted account. The files should be repaired so that they will not cause problems when accounts are created in the future, and the problem which led to unowned files should be discovered and addressed.

2.2.4 - Restrict Programs from Dangerous Execution Patterns

The recommendations in this section provide broad protection against information disclosure or other misbehavior. These protections are applied at the system initialization or kernel level, and defend against certain types of badly-configured or compromised programs.

2.2.4.1 - Set Daemon umask

Edit the file /etc/sysconfig/init, and add or correct the following line: umask 027 The settings file /etc/sysconfig/init contains settings which apply to all processes started at boot time. The system umask must be set to at least 022, or daemon processes may create world-writable files. The more restrictive setting 027 protects files, including temporary files and log files, from unauthorized reading by unprivileged users on the system. If a particular daemon needs a less restrictive umask, consider editing the startup script or sysconfig file of that daemon to make a specific exception.

2.2.4.2 - Disable Core Dumps

To disable core dumps for all users, add or correct the following line in /etc/security/limits.conf: * hard core 0 In addition, to ensure that core dumps can never be made by setuid programs, edit /etc/sysctl.conf and add or correct the line: fs.suid_dumpable = 0 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 would legitimately need to access these files. The core dump files may also contain sensitive information, or unnecessarily occupy large amounts of disk space. By default, the system sets a soft limit to stop the creation of core dump files for all users. This is accomplished in /etc/profile with the line: ulimit -S -c 0 > /dev/null 2>&1 However, compliance with this limit is voluntary; it is a default intended only to protect users from the annoyance of generating unwanted core files. Users can increase the allowed core file size up to the hard limit, which is unlimited by default. Once a hard limit is set in /etc/security/limits.conf, the user cannot increase that limit within his own session. If access to core dumps is required, consider restricting them to only certain users or groups. See the limits.conf(5) 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.

2.2.4.3 - Enable ExecShield

ExecShield comprises a number of kernel features to provide protection against 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. This protection is enabled by default, but the sysctl variables kernel.exec-shield and kernel.randomize va space should be checked to ensure that it has not been disabled. To ensure ExecShield (including random placement of virtual memory regions) is activated at boot, add or correct the following settings in /etc/sysctl.conf: kernel.exec-shield = 1 kernel.randomize_va_space = 1 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 there. However, this cannot always be done for all memory regions in which execution should not occur, so follow guidance in Section 2.2.4.4 to further protect the system.

2.2.4.4 - Enable Execute Disable (XD) or No Execute (NX) Support on x86 Systems

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.

2.2.4.4.1 - Check for Processor Support on x86 Systems

Check to see if the processor supports the PAE and NX features: $ cat /proc/cpuinfo If supported, the flags field will contain pae and nx.

2.2.4.4.2 - Install New Kernel on Supported x86 Systems

If supported 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.

2.2.4.4.3 - Enable Support in the BIOS

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. 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. See Section 2.3.5.1 for information on protecting this and other BIOS settings.

2.3 - Account and Access Control

In traditional Unix security, if an attacker gains shell access to a certain login account, he 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 RHEL5.

2.3.1 - Protect Accounts by Restricting Password-Based Login

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.

2.3.1.1 - Restrict Root Logins to System Console

Edit the file /etc/securetty. Ensure that the file contains only the following lines: * The primary system console device: console * The virtual console devices: tty1 tty2 tty3 tty4 tty5 tty6 ... * If required by your organization, the deprecated virtual console interface may be retained for backwards compatibility: vc/1 vc/2 vc/3 vc/4 vc/5 vc/6 ... * If required by your organization, the serial consoles may be added: ttyS0 ttyS1 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 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 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. See Section 3.5 for instructions on preventing root from logging in via SSH.

2.3.1.2 - Limit su Access to the Root Account

1. Ensure that the group wheel exists, and that the usernames of all administrators who should be allowed to execute commands as root are members of that group. # grep ^wheel /etc/group 2. Edit the file /etc/pam.d/su. Add, uncomment, or correct the line: auth required pam_wheel.so use_uid The su command allows a user to gain the privileges of another user by entering the password for that user’s account. It is desirable to restrict the root user so that only known administrators are ever allowed to access the root account. This restricts password-guessing against the root account by unauthorized users or by accounts which have been compromised. By convention, the group wheel contains all users who are allowed to run privileged commands. The PAM module pam wheel.so is used to restrict root access to this set of users.

2.3.1.3 - Configure sudo to Improve Auditing of Root Access

1. Ensure that the group wheel exists, and that the usernames of all administrators who should be allowed to execute commands as root are members of that group. # grep ^wheel /etc/group 2. Edit the file /etc/sudoers. Add, uncomment, or correct the line: %wheel ALL=(ALL) ALL The sudo command allows fine-grained control over which users can execute commands using other accounts. The primary benefit of sudo when configured as above is that it provides an audit trail of every command run by a privileged user. It is possible for a malicious administrator to circumvent this restriction, but, if there is an established procedure that all root commands are run using sudo, then it is easy for an auditor to detect unusual behavior when this procedure is not followed. Editing /etc/sudoers by hand can be dangerous, since a configuration error may make it impossible to access the root account remotely. The recommended means of editing this file is using the visudo command, which checks the file’s syntax for correctness before allowing it to be saved. Note that sudo allows any attacker who gains access to the password of an administrator account to run commands as root. This is a downside which must be weighed against the benefits of increased audit capability and of being able to heavily restrict the use of the high-value root password (which can be logistically difficult to change often). As a basic precaution, never use the NOPASSWD directive, which would allow anyone with access to an administrator account to execute commands as root without knowing the administrator’s password. The sudo command has many options which can be used to further customize its behavior. See the sudoers(5) man page for details.

2.3.1.4 - Block Shell and Login Access for Non-Root System Accounts

Do not perform the steps in this section on the root account. Doing so might cause the system to become inaccessible. Using /etc/passwd, obtain a listing of all users, their UIDs, and their shells, for instance by running: # 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. For each identified system account SYSACCT , lock the account: # usermod -L SYSACCT and disable its shell: # usermod -s /sbin/nologin SYSACCT These are the accounts which are not associated with a human user of the system, but which exist to perform some administrative function. Make it more difficult for an attacker to use these accounts by locking their passwords and by setting their shells to some non-valid shell. The RHEL5 default non-valid shell is /sbin/nologin, but any command which will exit with a failure status and disallow execution of any further commands, such as /bin/false or /dev/null, will work.

2.3.1.5 - Verify that No Accounts Have Empty Password Fields

Run the command: # awk -F: '($2 == "") {print}' /etc/shadow If this produces any output, fix the problem by locking each account (see Section 2.3.1.4 above) or by setting a password. If an account has an empty password, anybody may log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.

2.3.1.6 - Verify that No Non-Root Accounts Have UID 0

This command will print all password file entries for accounts with UID 0: # awk -F: '($3 == "0") {print}' /etc/passwd This should print only one line, for the user root. If any other lines appear, ensure that these additional UID-0 accounts are authorized, and that there is a good reason for them to exist. In general, the best practice solution for auditing use of the root account is to restrict the set of cases in which root must be accessed anonymously by requiring use of su or sudo in almost all cases. Some sites choose to have more than one account with UID 0 in order to differentiate between administrators, but this practice may have unexpected side effects, and is therefore not recommended.

2.3.1.7 - Set Password Expiration Parameters

Edit the file /etc/login.defs to specify password expiration settings for new accounts. Add or correct the following lines: PASS_MAX_DAYS=180 PASS_MIN_DAYS=7 PASS_MIN_LEN=8 PASS_WARN_AGE=7 For each existing human user USER , modify the current expiration settings to match these: # chage -M 180 -m 7 -W 7 USER 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.

2.3.1.8 - Remove Legacy + Entries from Password Files

The command: # grep "^+:" /etc/passwd /etc/shadow /etc/group should produce no output. The + symbol was used by systems to include data from NIS maps into existing files. However, a certain configuration error in which a NIS inclusion line appears in /etc/passwd, but NIS is not running, could lead to anyone being able to access the system with the username + and no password. Therefore, it is important to verify that no such line appears in any of the relevant system files. The correct way to tell the local system to consult network databases such as LDAP or NIS for user information is to make appropriate modifications to /etc/nsswitch.conf.

2.3.2 - Use Unix Groups to Enhance Security

The access control policies which can be enforced by standard Unix permissions are limited, and configuring SELinux (Section 2.4) is frequently a better choice. However, this guide recommends that security be enhanced to the extent possible by enforcing the Unix group policies outlined in this section.

2.3.2.1 - Create a Unique Default Group for Each User

When running useradd, do not use the -g flag or otherwise override the default group. The Red Hat default is that each new user account should have a unique primary group whose name is the same as that of the account. This default is recommended, in order to provide additional protection against files which are created with group write permission enabled.

2.3.2.2 - Create and Maintain a Group Containing All Human Users

Identify all user accounts on the system which correspond to human users. Depending on your system configuration, this may be all entries in /etc/passwd with UID values of at least 500. Once, you have identified such a set of users, create a group named usergroup (substitute some name appropriate to your environment) and populate it with each human user: # groupadd usergroup # usermod -G usergroup human1 # usermod -G usergroup human2 ... # usermod -G usergroup humanN Then modify your procedure for creating new user accounts by adding -G usergroup to the set of flags with which useradd is invoked, so that new human users will be placed in the correct group by default. Creating a group of human users does not, by itself, enhance system security. However, as you work on securing your system, you will often find commands which never need to be run by system accounts, or which are only ever needed by users logged into the graphical console (which should only ever be available to human users, even on workstations). Once a group of users has been created, it is easy to restrict access to a given command, for instance /path/to/graphical/command , to authorized users: # chgrp usergroup /path/to/graphical/command # chmod 750 /path/graphical/command Without a group of human users, it is necessary to restrict access by somehow preventing each system account from running the command, which is an error-prone process even when it is possible at all.

2.3.3 - Protect Accounts by Configuring PAM

PAM, or Pluggable Authentication Modules, is a system which implements modular authentication for Linux programs. PAM is well-integrated into Linux’s authentication architecture, making it difficult to remove, but it can be configured to minimize your system’s exposure to unnecessary risk. This section contains guidance on how to accomplish that, and how to ensure that the modules used by your PAM configuration do what they are supposed to do. 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. 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.1 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. 1One 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.

2.3.3.1 - Set Password Quality Requirements

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. The pam passwdqc PAM module provides the ability to enforce even more 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. If password strength stronger than that guaranteed by pam cracklib is required, configure PAM to use pam passwdqc. To activate pam passwdqc, locate the following line in /etc/pam.d/system-auth: password requisite pam_cracklib.so try_first_pass retry=3 and then replace it with the line: password requisite pam_passwdqc.so min=disabled,disabled,16,12,8 If necessary, modify the arguments (min=disabled,disabled,16,12,8) to ensure compliance with your organization’s security policy. Configuration options are described in the man page pam passwdqc(8) and also in /usr/share/doc/pam passwdqc-version. The minimum lengths provided here supercede that specified by the argument PASS MIN LEN as described in Section 2.3.1.7. The options given in the example above set a minimum length for each of the password “classes” that pam passwdqc recognizes. Setting a particular minimum value to disabled will stop users from choosing a password that falls into that category alone.

2.3.3.2 - Set Lockouts for Failed Password Attempts

The pam tally2 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 tally2. If locking out accounts after a number of incorrect login attempts is required by your security policy, implement use of pam tally2.so for the relevant PAM-aware programs such as login, sshd, and vsftpd. Find the following line in /etc/pam.d/system-auth: auth sufficient pam_unix.so nullok try_first_pass and then change it so that it reads as follows: auth required pam_unix.so nullok try_first_pass In the same file, comment out or delete the lines: auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so To enforce password lockout, add the following to the individual programs’ configuration files in /etc/pam.d. First, add to end of the auth lines: auth required pam_tally2.so deny=5 onerr=fail Second, add to the end of the account lines: account required pam_tally2.so Adjust the deny argument to conform to your system security policy. The pam tally2 utility can be used to unlock user accounts as follows: # /sbin/pam_tally2 --user username --reset Locking out user accounts presents the risk of a denial-of-service attack. The security policy regarding system lockout must weigh whether the risk of such a denial-of-service attack outweighs the benefits of thwarting password guessing attacks. The pam tally2 utility can be run from a cron job on a hourly or daily basis to try and offset this risk.

2.3.3.3 - Use pam deny.so to Quickly Deny Access to a Service

In order to deny access to a service SVCNAME via PAM, edit the file /etc/pam.d/SVCNAME . Prepend this line to the beginning of the file: auth requisite pam_deny.so Under most circumstances, there are better ways to disable a service than to deny access via PAM. However, this should suffice as a way to quickly make a service unavailable to future users (existing sessions which have already been authenticated, are not affected). The requisite tag tells PAM that, if the named module returns failure, authentication should fail, and PAM should immediately stop processing the configuration file. The pam deny.so module always returns failure regardless of its input.

2.3.3.4 - Restrict Execution of userhelper to Console Users

If your environment has defined a group, usergroup containing all the human users of your system, restrict execution of the userhelper program to only that group: # chgrp usergroup /usr/sbin/userhelper # chmod 4710 /usr/sbin/userhelper The userhelper program provides authentication for graphical services which must run with root privileges, such as the system-config- family of graphical configuration utilities. Only human users logged into the system console are likely to ever have a legitimate need to run these utilities. This step provides some protection against possible flaws in userhelper’s implementation, and against further privilege escalation when system accounts are compromised. See Section 2.3.2.2 for more information on creating a group of human users. The userhelper program is configured by the files in /etc/security/console.apps/. Each file specifies, for some program, what user the program should run as, and what program should be executed after successful authentication. Note: The configuration in /etc/security/console.apps/ is applied in combination with the PAM configuration of the service defined in /etc/pam.d/. First, userhelper determines what user the service should run as. (Typically, this will be root.) Next, userhelper uses the PAM API to allow the user who ran the program to attempt to authenticate as the desired user. The PAM API exchange is wrapped in a GUI if the application’s configuration requests one.

2.3.4 - Secure Session Configuration Files for Login Accounts

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, he 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.

2.3.4.1 - Ensure that No Dangerous Directories Exist in Roots Path '

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. For each directory DIR in the path, ensure that DIR is not equal to a single . 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. For each element in the path, run: # ls -ld DIR and ensure that write permissions are disabled for group and other. It is important to prevent root from executing unknown or untrusted programs, since such programs could contain malicious code. Therefore, root should not run programs installed by unprivileged users. Since root may often be working 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.

2.3.4.2 - Ensure that User Home Directories are not Group-Writable or World-Readable

Sections 2.3.4.2–2.3.4.5 recommend modifying user home directories. Notify your user community, and solicit input if appropriate, before making this type of change. For each human user 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 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 subdirectories or elsewhere in the filesystem if they are needed. Typically, user home directories should not be world-readable. If a subset of users need read access to one another’s home directories, this can be provided using groups.

2.3.4.3 - Ensure that User Dot-Files are not World-writable

For each human user USER of the system, view the permissions of all dot-files in the user’s home directory: # ls -ld /home/USER /.[A-Za-z0-9]* Ensure that none of these files are group- or world-writable. Correct each misconfigured file FILE by executing: # chmod go-w /home/USER /FILE A user who can modify another user’s configuration files can likely execute commands with the other user’s privileges, including stealing data, destroying files, or launching further attacks on the system.

2.3.4.4 - Ensure that Users Have Sensible Umask Values

1. Edit the global configuration files /etc/profile, /etc/bashrc, and /etc/csh.cshrc. Add or correct the line: umask 077 2. Edit the user definitions file /etc/login.defs. Add or correct the line: UMASK 077 3. View the additional configuration files /etc/csh.login and /etc/profile.d/*, and ensure that none of these files redefine the umask to a more permissive value unless there is a good reason for it. 4. Edit the root shell configuration files /root/.bashrc, /root/.bash profile, /root/.cshrc, and /root/.tcshrc. Add or correct the line: umask 077 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 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 group s of which the user is a member. In addition, it may be necessary to change root’s umask temporarily in order to install software or files which must be readable by other users, or to change the default umasks of certain service accounts such as the FTP user. However, setting a restrictive default protects the files of users who have not taken steps to make their files more available, and preventing files from being inadvertently shared.

2.3.4.5 - Ensure that Users do not Have .netrc Files

For each human user USER of the system, ensure that the user has no .netrc file. The command: # ls -l /home/USER /.netrc should return the error “No such file or directory”. If any user has such a file, approach that user to discuss removing this file. The .netrc file is a configuration file used to make unattended logins to other systems via FTP. When this file exists, it frequently contains unencrypted passwords which may be used to attack other systems.

2.3.5 - Protect Physical Console Access

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.

2.3.5.1 - Set BIOS Password

The BIOS (on x86 systems) is the first code to execute during system startup and controls many important system parameters, including which devices the system will try to boot from, and in which order. Assign a password to prevent any unauthorized changes to the BIOS configuration. The exact steps will vary depending on your machine, but are likely to include: 1. Reboot the machine. 2. Press the appropriate key during the initial boot screen (F2 is typical). 3. Navigate the BIOS configuration menu to add a password. The exact process will be system-specific and the system’s hardware manual may provide detailed instructions. This password should prevent attackers with physical access from attempting to change important parameters, such as those described in Sections 2.5.2.2.1 and 2.2.2.2.4. However, an attacker with physical access can usually clear the BIOS password. The password should be written down and stored in a physically-secure location, such as a safe, in the event that it is forgotten and must be retrieved.

2.3.5.2 - Set Boot Loader Password

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. 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, the boot loader configuration should be protected with a password. The default RHEL boot loader for x86 systems is called GRUB. To protect its configuration: 1. Select a password and then generate a hash from it by running: # grub-md5-crypt 2. Insert the following line into /etc/grub.conf immediately after the header comments. (Use the output from grub-md5-crypt as the value of password-hash ): password --md5 password-hash 3. Verify the permissions on /etc/grub.conf (which is a symlink to ../boot/grub/grub.conf): # chown root:root /etc/grub.conf # chmod 600 /etc/grub.conf Boot loaders for other platforms should offer a similar password protection feature.

2.3.5.3 - Require Authentication for Single-User Mode

Single-user mode is intended as a system recovery method, providing a single user root access to the system by providing a boot option at startup. By default, no authentication is performed if single-user mode is selected. This provides a trivial mechanism of bypassing security on the machine and gaining root access. To require entry of the root password even if the system is started in single-user mode, add the following line to the /etc/inittab file: ~~:S:wait:/sbin/sulogin

2.3.5.4 - Disable Interactive Boot

Edit the file /etc/sysconfig/init. Add or correct the setting: 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. Using interactive boot, the console user could disable auditing, firewalls, or other services, weakening system security.

2.3.5.5 - Implement Inactivity Time-out for Login Shells

If the system does not run X Windows, then the login shells can be configured to automatically log users out after a period of inactivity. The following instructions are not practical for systems which run X Windows, as they will close terminal windows in the X environment. For information on how to automatically lock those systems, see Section 2.3.5.6. To implement a 10-minute idle time-out for the default /bin/bash shell, create a new file tmout.sh in the directory /etc/profile.d with the following lines: TMOUT=600 readonly TMOUT export TMOUT To implement a 10-minute idle time-out for the tcsh shell, create a new file autologout.csh in the directory /etc/profile.d with the following line: set -r autologout 10 Similar actions should be taken for any other login shells used. The example time-out here of 10 minutes should be adjusted to whatever your security policy requires. The readonly line for bash and the -r option for tcsh can be omitted if policy allows users to override the value. The automatic shell logout only occurs when the shell is the foreground process. If, for example, a vi session is left idle, then automatic logout would not occur. When logging in through a remote connection, as with SSH, it may be more effective to set the timeout value directly through that service. To learn how to set automatic timeout intervals for SSH, see Section 3.5.2.3.

2.3.5.6 - Configure Screen Locking

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. A policy should be implemented that trains all users to lock the screen when they plan to temporarily step away from a logged-in account. Automatic screen locking is only meant as a safeguard for those cases where a user forgot to lock the screen.

2.3.5.6.1 - Configure GUI Screen Locking

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. Run the following commands to enforce idle activation of the screen saver, screen locking, a blank-screen screensaver, and 10-minute idle activation time: # gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type bool \ --set /apps/gnome-screensaver/idle_activation_enabled true # gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type bool \ --set /apps/gnome-screensaver/lock_enabled true # gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type string \ --set /apps/gnome-screensaver/mode blank-only # gconftool-2 --direct \ --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \ --type int \ --set /apps/gnome-screensaver/idle_delay 10 The default setting of 10 minutes for idle activation is reasonable for many office environments, but the setting should conform to whatever policy is defined. The screensaver mode blank-only is selected to conceal the contents of the display from passersby. 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://www.gnome.org/projects/gconf and the man page gconftool-2(1).

2.3.5.6.2 - Configure Console Screen Locking

A console screen locking mechanism is provided in the vlock package, which is not installed by default. If the ability to lock console screens is necessary, install the vlock package: # yum install vlock Instruct users to invoke the program when necessary, in order to prevent passersby from abusing their login: $ vlock The -a option can be used to prevent switching to other virtual consoles.

2.3.6 - Use a Centralized Authentication Service

A centralized authentication service is any method of maintaining central control over account and authentication data and of keeping this data synchronized between machines. Such services can range in complexity from a script which pushes centrally-generated password files out to all machines, to a managed scheme such as LDAP or Kerberos. If authentication information is not centrally