scap-security-guide project This guide is designed to provide comprehensive discussion of security-relevant configuration settings for Red Hat Enterprise Linux 6. Providing system administrators with such information enables them to securely configure systems under their control in a variety of network roles. This guide also provides policy makers with a comprehensive catalog of settings, from which security baselines can be constructed. 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. Applicable platforms
|
Version: 0.1 Revision history
|
Table of Contents
1. Introduction
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.
Table of Contents
link | previous | next | up | toc | home
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.
link | previous | next | up | toc | home
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 RHEL6 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.1.5. Least Privilege
Grant the least privilege necessary for user accounts and software to perform tasks.
For example, do not allow users except those that need administrator access to use
sudo
. 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.
1.2. How to Use This Guide
Readers should heed the following points when using the guide.
link | previous | next | up | toc | home
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. 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.
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 Settings
Table of Contents
-
2.1. Installing and Maintaining Software
-
2.1.1. Disk Partitioning
- 2.1.1.a. Ensure /tmp Located On Separate Partition
- 2.1.1.b. Ensure /var Located On Separate Partition
- 2.1.1.c. Ensure /var/log Located On Separate Partition
- 2.1.1.d. Ensure /var/log/audit Located On Separate Partition
- 2.1.1.e. Ensure /home Located On Separate Partition
- 2.1.1.6. Encrypting Partitions
- 2.1.2. Updating Software
- 2.1.3. Software Integrity Checking
-
2.1.1. Disk Partitioning
-
2.2. File Permissions and Masks
-
2.2.1. Restrict Partition Mount Options
- 2.2.1.a. Add nodev Option to Non-Root Local Partitions
- 2.2.1.b. Add nodev Option to Removable Media Partitions
- 2.2.1.c. Add noexec Option to Removable Media Partitions
- 2.2.1.d. Add nosuid Option to Removable Media Partitions
- 2.2.1.e. Add nodev Option to /tmp
- 2.2.1.f. Add noexec Option to /tmp
- 2.2.1.g. Add nosuid Option to /tmp
- 2.2.1.h. Add nodev Option to /dev/shm
- 2.2.1.i. Add noexec Option to /dev/shm
- 2.2.1.j. Add nosuid Option to /dev/shm
- 2.2.1.k. Bind Mount /var/tmp To /tmp
-
2.2.2. Restrict Dynamic Mounting and Unmounting of Filesystems
- 2.2.2.a. Restrict Console Device Access to Desktop Workstations
- 2.2.2.b. Restrict Console Device Access to Servers
- 2.2.2.c. Disable Modprobe Loading of USB Storage Driver
- 2.2.2.d. Disable Kernel Support for USB via Bootloader Configuration
- 2.2.2.e. Disable Booting from USB Devices
- 2.2.2.f. Disable the Automounter
- 2.2.2.g. Disable GNOME Automounting
- 2.2.2.h. Disable Mounting of cramfs
- 2.2.2.i. Disable Mounting of freevxfs
- 2.2.2.j. Disable Mounting of jffs2
- 2.2.2.k. Disable Mounting of hfs
- 2.2.2.l. Disable Mounting of hfsplus
- 2.2.2.m. Disable Mounting of squashfs
- 2.2.2.n. Disable Mounting of udf
- 2.2.2.o. Disable All GNOME Thumbnailers
-
2.2.3. Verify Permissions on Important Files and Directories
- 2.2.3.a. Verify that All World-Writable Directories Have Sticky Bits Set
- 2.2.3.b. Ensure No World-Writable Files Exist
- 2.2.3.c. Ensure All Setgid Executables Are Authorized
- 2.2.3.d. Ensure All SUID Executables Are Authorized
- 2.2.3.e. Ensure All Files Are Owned by a User
- 2.2.3.f. Ensure All Files Are Owned by a Group
- 2.2.3.g. Ensure All World-Writable Directories Are Owned by a System Account
-
2.2.3.8. Verify Permissions on Files with Local Account Information and Credentials
- 2.2.3.8.a. Verify User Who Owns shadow File
- 2.2.3.8.b. Verify Group Who Owns shadow File
- 2.2.3.8.c. Verify Permissions on shadow File
- 2.2.3.8.d. Verify User Who Owns group File
- 2.2.3.8.e. Verify Group Who Owns group File
- 2.2.3.8.f. Verify Permissions on group File
- 2.2.3.8.g. Verify User Who Owns gshadow File
- 2.2.3.8.h. Verify Group Who Owns gshadow File
- 2.2.3.8.i. Verify Permissions on gshadow File
- 2.2.3.8.j. Verify User Who Owns passwd File
- 2.2.3.8.k. Verify Group Who Owns passwd File
- 2.2.3.8.l. Verify Permissions on passwd File
- 2.2.3.9. Verify File Permissions Within Some Important Directories
- 2.2.4. Restrict Programs from Dangerous Execution Patterns
-
2.2.1. Restrict Partition Mount Options
- 2.3. SELinux
-
2.4. Account and Access Control
- 2.4.1. Protect Accounts by Restricting Password-Based Login
-
2.4.2. Protect Accounts by Configuring PAM
- 2.4.2.a. Set Password Hashing Algorithm
- 2.4.2.b. Limit Password Reuse
-
2.4.2.3. Set Password Quality Requirements
-
2.4.2.3.1. Set Password Quality Requirements, if using pam_cracklib
- 2.4.2.3.1.a. Set Password Retry Prompts Permitted Per-session
- 2.4.2.3.1.b. Set Password Strength Minimum Digit Characters
- 2.4.2.3.1.c. Set Password Strength Minimum Uppercase Characters
- 2.4.2.3.1.d. Set Password Strength Minimum Special Characters
- 2.4.2.3.1.e. Set Password Strength Minimum Lowercase Characters
- 2.4.2.3.1.f. Set Password Strength Minimum Different Characters
-
2.4.2.3.1. Set Password Quality Requirements, if using pam_cracklib
- 2.4.2.4. Set Lockouts for Failed Password Attempts
- 2.4.3. Secure Session Configuration Files for Login Accounts
- 2.4.4. Protect Physical Console Access
-
2.5. Network Configuration and Firewalls
- 2.5.a. Disable Unused Interfaces
- 2.5.b. Disable Zeroconf Networking
- 2.5.c. Ensure System is Not Acting as a Network Sniffer
-
2.5.4. Kernel Parameters Which Affect Networking
- 2.5.4.1. Network Parameters for Hosts Only
-
2.5.4.2. Network Related Kernel Runtime Parameters for Hosts and Routers
- 2.5.4.2.a. Disable Kernel Parameter for Accepting Source-Routed Packets for All Interfaces
- 2.5.4.2.b. Disable Kernel Parameter for Accepting ICMP Redirects for All Interfaces
- 2.5.4.2.c. Disable Kernel Parameter for Accepting Secure Redirects for All Interfaces
- 2.5.4.2.d. Enable Kernel Parameter to Log Martian Packets
- 2.5.4.2.e. Disable Kernel Parameter for Accepting Source-Routed Packets By Default
- 2.5.4.2.f. Disable Kernel Parameter for Accepting ICMP Redirects By Default
- 2.5.4.2.g. Disable Kernel Parameter for Accepting Secure Redirects By Default
- 2.5.4.2.h. Enable Kernel Parameter to Ignore ICMP Broadcast Echo Requests
- 2.5.4.2.i. Enable Kernel Parameter to Ignore Bogus ICMP Error Responses
- 2.5.4.2.k. Enable Kernel Parameter to Use Reverse Path Filtering for All Interfaces
- 2.5.4.2.l. Enable Kernel Parameter to Use Reverse Path Filtering by Default
- 2.5.5. Wireless Networking
-
2.5.6. IPv6
- 2.5.6.1. Disable Support for IPv6 unless Needed
- 2.5.6.2. Configure IPv6 Settings if Necessary
- 2.5.7. Iptables and Ip6tables
-
2.5.8. Secure Sockets Layer Support
- 2.5.8.1. Create a CA to Sign Certificates
- 2.5.8.2. Create SSL Certificates for Servers
- 2.5.8.3. Enable Client Support
- 2.5.8.4. Adding a Trusted CA for Firefox
- 2.5.8.5. Adding a Trusted CA for Thunderbird
- 2.5.8.6. Adding a Trusted CA for Evolution
- 2.5.8.7. Remove Certificate Authorities, if Appropriate
- 2.5.9. Uncommon Network Protocols
- 2.5.10. IPSec Support
-
2.6. Configure Syslog
- 2.6.a. Ensure rsyslog is Installed
- 2.6.b. Enable rsyslog Service
- 2.6.c. Disable Logwatch on Clients if a Logserver Exists
- 2.6.4. Ensure Proper Configuration of Log Files
- 2.6.5. Rsyslog Logs Sent To Remote Host
- 2.6.6. Configure rsyslogd to Accept Remote Messages If Acting as a Log Server
- 2.6.7. Ensure All Logs are Rotated by logrotate
- 2.6.8. Configure Logwatch on the Central Log Server
-
2.7. System Accounting with auditd
- 2.7.a. Enable auditd Service
- 2.7.b. Enable Auditing for Processes Which Start Prior to the Audit Daemon
-
2.7.3. Configure auditd Data Retention
- 2.7.3.a. Configure auditd Number of Logs Retained
- 2.7.3.b. Configure auditd Max Log File Size
- 2.7.3.c. Configure auditd max_log_file_action Upon Reaching Maximum Log Size
- 2.7.3.d. Configure auditd space_left Action on Low Disk Space
- 2.7.3.e. Configure auditd admin_space_left Action on Low Disk Space
- 2.7.3.f. Configure auditd mail_acct Action on Low Disk Space
-
2.7.4. Configure auditd Rules for Comprehensive Auditing
- 2.7.4.a. Record Events that Modify User/Group Information
- 2.7.4.b. Record Events that Modify the System's Network Environment
- 2.7.4.c. Record Events that Modify the System's Mandatory Access Controls
- 2.7.4.d. Record Attempts to Alter Logon and Logout Events
- 2.7.4.e. Record Attempts to Alter Process and Session Initiation Information
- 2.7.4.f. Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful)
- 2.7.4.g. Ensure auditd Collects Information on the Use of Privileged Commands
- 2.7.4.h. Ensure auditd Collects Information on Exporting to Media (successful)
- 2.7.4.i. Ensure auditd Collects File Deletion Events by User
- 2.7.4.j. Ensure auditd Collects System Administrator Actions
- 2.7.4.k. Ensure auditd Collects Information on Kernel Module Loading and Unloading
- 2.7.4.l. Make the auditd Configuration Immutable
- 2.7.4.13. Records Events that Modify Date and Time Information
-
2.7.4.14. Record Events that Modify the System's Discretionary Access Controls
- 2.7.4.14.a. Record Events that Modify the System's Discretionary Access Controls - chmod
- 2.7.4.14.b. Record Events that Modify the System's Discretionary Access Controls - chown
- 2.7.4.14.c. Record Events that Modify the System's Discretionary Access Controls - fchmod
- 2.7.4.14.d. Record Events that Modify the System's Discretionary Access Controls - fchmodat
- 2.7.4.14.e. Record Events that Modify the System's Discretionary Access Controls - fchown
- 2.7.4.14.f. Record Events that Modify the System's Discretionary Access Controls - fchownat
- 2.7.4.14.g. Record Events that Modify the System's Discretionary Access Controls - fremovexattr
- 2.7.4.14.h. Record Events that Modify the System's Discretionary Access Controls - fsetxattr
- 2.7.4.14.i. Record Events that Modify the System's Discretionary Access Controls - lchown
- 2.7.4.14.j. Record Events that Modify the System's Discretionary Access Controls - lremovexattr
- 2.7.4.14.k. Record Events that Modify the System's Discretionary Access Controls - lsetxattr
- 2.7.4.14.l. Record Events that Modify the System's Discretionary Access Controls - removexattr
- 2.7.4.14.m. Record Events that Modify the System's Discretionary Access Controls - setxattr
link | previous | next | up | toc | home
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.
link | previous | next | up | toc | home
2.1.1. Disk Partitioning
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.
link | previous | next | up | toc | home
2.1.1.a. Ensure /tmp Located On Separate Partition
The /tmp
directory is a world-writable directory used
for temporary file storage. Ensure that it has its own partition or
logical volume at installation time, or migrate it using LVM.
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.
Security identifiers
- CCE-14161-4
References
2.1.1.b. Ensure /var Located On Separate Partition
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.
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.
Security identifiers
- CCE-14777-7
References
2.1.1.c. Ensure /var/log Located On Separate Partition
System logs are stored in the /var/log
directory.
Ensure that it has its own partition or logical
volume at installation time, or migrate it using LVM.
Placing /var/log
in its own partition
enables better separation between log files
and other files in /var/
.
Security identifiers
- CCE-14011-1
References
2.1.1.d. Ensure /var/log/audit Located On Separate Partition
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.
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.
Security identifiers
- CCE-14171-3
References
2.1.1.e. Ensure /home Located On Separate Partition
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.
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.
Security identifiers
- CCE-14559-9
References
2.1.1.6. Encrypting Partitions
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 install time.
For manual installations, selecting the Encrypt
checkbox during
partition creation is all that is needed 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 need to be entered manually
every time the system boots.
For automated/unattended installations using Kickstart add the --encrypted
and --passphrase=
options to the definition of each partition you want
encrypted. For example:
part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=yourpassphrase
Where yourpassphrase is a passphrase of your choosing. The passphrase is
stored in the Kickstart file in clear-text. If that is of concern, leaving the
--passphrase=
option off the partition definition will cause the
installer to pause and interactively ask for the passphrase during the install.
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
References
- 1199. URL: <http://iase.disa.mil/cci/index.html>.
- 1350. URL: <http://iase.disa.mil/cci/index.html>.
- 1200. URL: <http://iase.disa.mil/cci/index.html>.
2.1.2. Updating Software
The yum
command line tool is used to install and
update software packages. 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.
Red Hat Enteprise Linux systems contain an embedded Installed Software
Catalog, or "RPM Database," which records metadata of installed packages.
The yum
, pirut
, and pup
tools interface
with the Installed Software Catalog to ensure all system metadata is
accurate with regard to installed software and security patches, and
for this reason, their use is strongly encouraged.
References
- 1233. URL: <http://iase.disa.mil/cci/index.html>.
link | previous | next | up | toc | home
2.1.2.a. Ensure Red Hat GPG Key Installed
To ensure that 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 that the GPG key is installed, run:
# rhn_register
This key is necessary to cryptographically verify that packages are from Red Hat.
Security identifiers
- CCE-14440-2
References
2.1.2.b. Ensure gpgcheck Enabled In Main Yum Configuration
The gpgcheck
option should be used to ensure that
checking of an RPM package’s signature always occurs prior to its
installation. To configure yum to check package signatures before installing
them, ensure that the following line appears in /etc/yum.conf
in
the [main]
section:
gpgcheck=1
Ensuring the validity of packages' cryptographic signatures prior to installation ensures the provenance of the software and protects against malicious tampering.
Security identifiers
- CCE-14914-6
References
- SI-2. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 352. URL: <http://iase.disa.mil/cci/index.html>.
- 663. URL: <http://iase.disa.mil/cci/index.html>.
2.1.2.c. Ensure gpgcheck Enabled For All Yum Package Repositories
To ensure that signature checking is not disabled for
any repos, remove any lines from files in /etc/yum.repos.d
of the form:
gpgcheck=0
Ensuring that all packages' cryptographic signatures are valid prior to installation ensures the provenance of the software and protects against malicious tampering.
Security identifiers
- CCE-14813-0
References
- SI-2. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 352. URL: <http://iase.disa.mil/cci/index.html>.
- 663. URL: <http://iase.disa.mil/cci/index.html>.
2.1.2.d. Ensure Software Patches Installed
The following command prints a list of packages that need to be updated:
# yum check-update
To actually install these updates, run:
# yum update
Installing software updates is a fundamental mitigation against the exploitation of publicly-known vulnerabilities.
References
- SI-2. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1232. URL: <http://iase.disa.mil/cci/index.html>.
2.1.3. Software Integrity Checking
Both the AIDE (Advanced Intrusion Detection Environment)
software and the RPM package management system provide
mechanisms for verifying the integrity of installed software.
AIDE is the successor to the well-known Tripwire integrity
checker. 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.
link | previous | next | up | toc | home
2.1.3.1. Verify Integrity with AIDE
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 before the system is connected to any network. AIDE is highly
configurable, with further configuration information located in
/usr/share/doc/aide-VERSION
References
- 374. URL: <http://iase.disa.mil/cci/index.html>.
- 1069. URL: <http://iase.disa.mil/cci/index.html>.
- 1297. URL: <http://iase.disa.mil/cci/index.html>.
- 1589. URL: <http://iase.disa.mil/cci/index.html>.
link | previous | next | up | toc | home
2.1.3.1.a. Install AIDE
Install the AIDE package with the command:
# yum install aide
The AIDE package must be installed if it is to be available for integrity checking.
Security identifiers
- CCE-4209-3
References
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-28. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SI-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
2.1.3.1.b. Disable Prelinking
The prelinking feature
changes binaries in an attempt to decrease their startup time.
In order to disable it, change or add the following line inside the file /etc/sysconfig/prelink
:
PRELINKING=no
Next, the following command to return binaries to a normal, non-prelinked state:
# /usr/sbin/prelink -ua
The prelinking feature can interfere with the operation of AIDE, because it changes binaries.
References
2.1.3.1.c. Build and Test AIDE Database
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.
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.
References
2.1.3.1.d. Configure Periodic Execution of AIDE
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.
By default, AIDE does not install itself for periodic execution. Periodically running AIDE may reveal unexpected changes in installed files.
References
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-28. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SI-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 416. URL: <http://iase.disa.mil/cci/index.html>.
- 1166. URL: <http://iase.disa.mil/cci/index.html>.
- 1263. URL: <http://iase.disa.mil/cci/index.html>.
- 1496. URL: <http://iase.disa.mil/cci/index.html>.
2.1.3.1.e. Manually Verify Integrity of AIDE
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.
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.
References
2.1.3.2. Verify Integrity with RPM
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.
link | previous | next | up | toc | home
2.1.3.2.a. Verify File Permissions with RPM
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 list which files on the system have permissions that are different from what is expected by the RPM database:
# rpm -Va | grep '^.M'
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.
Security identifiers
- CCE-14931-0
References
2.1.3.2.b. Verify File Hashes with RPM
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.
The MD5 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.
Security identifiers
- CCE-TODO
References
- SI-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1496. URL: <http://iase.disa.mil/cci/index.html>.
2.1.3.3. Virus Scanning
In order to minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Virus scanning software should be used to protect a system from penetration from computer viruses and to limit their spread through intermediate systems.
link | previous | next | up | toc | home
2.1.3.3.a. Install Virus Scanning Software
Virus scanning software should be installed and configured to perform scans
dynamically on accessed files. If this capability is not available, the system should be
configured to scan, at a minimum, all altered files on the system on a daily basis.
Virus signature definition files should be updated frequently. It is recommended that definition
files be updated at least every 7 days.
In order to minimize potential negative impact to the organization caused by malicious code, it is imperative that malicious code is identified and eradicated prior to entering protected enclaves.
Security identifiers
- CCE-TODO
References
- 1239. URL: <http://iase.disa.mil/cci/index.html>.
- 1668. URL: <http://iase.disa.mil/cci/index.html>.
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.
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 then you
will need to modify this command.
link | previous | next | up | toc | home
2.2.1. Restrict Partition Mount Options
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.
link | previous | next | up | toc | home
2.2.1.a. Add nodev Option to Non-Root Local Partitions
Legitimate character and block devices should exist in
the /dev
directory on the root patition or within chroot
jails built for system services. All other locations should not allow
character and block devices.
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.
Security identifiers
- CCE-4249-9
References
2.2.1.b. Add nodev Option to Removable Media Partitions
Removable Media partitions should be mounted with the
nodev
option.
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.
Security identifiers
- CCE-3522-0
References
2.2.1.c. Add noexec Option to Removable Media Partitions
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.
Allowing users to execute binaries from removable media such as USB keys exposes the system to potential compromise.
Security identifiers
- CCE-4275-4
References
2.2.1.d. Add nosuid Option to Removable Media Partitions
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.
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.
Security identifiers
- CCE-4275-4
References
2.2.1.e. Add nodev Option to /tmp
Legitimate character and block devices should not exist
within temporary directories like /tmp
. The nodev
mount option should be specified for /tmp
.
The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails.
Security identifiers
- CCE-14412-1
References
2.2.1.f. Add noexec Option to /tmp
It can be dangerous to allow the execution of binaries
from world-writeable temporary storage directories such as /tmp
.
The noexec
mount option prevents binaries from being executed
out of /tmp
.
Allowing users to execute binaries from world-writeable directories such as /tmp can expose the system to potential compromise.
Security identifiers
- CCE-14927-8
References
2.2.1.g. Add nosuid Option to /tmp
The nosuid
mount option should be set for temporary
storage partitions such as /tmp
. The suid/sgid permissions
should not be required in these world-writeable directories.
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.
Security identifiers
- CCE-14940-1
References
2.2.1.h. Add nodev Option to /dev/shm
Legitimate character and block devices should not exist
within temporary directories like /dev/shm
. The nodev
mount option should specified for /dev/shm
.
The only legitimate location for device files is the /dev directory located on the root partition. The only exception to this is chroot jails.
Security identifiers
- CCE-15007-8
References
2.2.1.i. Add noexec Option to /dev/shm
It can be dangerous to allow the execution of binaries
from world-writeable temporary storage directories such as /dev/shm
.
The noexec
mount option prevents binaries from being executed
out of /dev/shm
.
Allowing users to execute binaries from world-writeable directories such as /dev/shm can expose the system to potential compromise.
Security identifiers
- CCE-14703-3
References
2.2.1.j. Add nosuid Option to /dev/shm
The nosuid
mount option should be set for temporary
storage partitions such as /dev/shm
. The suid/sgid permissions
should not be required in these world-writeable directories.
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.
Security identifiers
- CCE-14306-5
References
2.2.1.k. Bind Mount /var/tmp To /tmp
The /var/tmp
directory should be bind mounted to /tmp
in order to consolidate temporary storage into one location protected by the same
techniques as /tmp
. This is done by editing /etc/fstab
and adding
the following line if needed:
/tmp /var/tmp none rw,nodev,noexec,nosuid,bind 0 0
See the mount(8) man page for further explanation of bind mounting.
Having multiple locations for temporary storage is not required. Unless absolutely necessary to meet requirements, the storage location /var/tmp should be bind mounted to /tmp and thus share the same protections.
Security identifiers
- CCE-14584-7
References
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.
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.
link | previous | next | up | toc | home
2.2.2.a. Restrict Console Device Access to Desktop Workstations
If the display manager has been altered to allow remote users to log in and the host is configured to run at runlevel 5, change console as well as the xconsole directive in the /etc/security/console.perms
to the following:
<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :0\.[0-9] :0
<xconsole>=:0\.[0-9] :0
When a user logs in, the module pam_console.so called via the command login, or by some of the graphics program of logging, such as gdm, kdm, and xdm. If this user is the first to log into the physical console - called the console user - the user module assures the mastery of a wide variety of devices normally belong to root. Administrative privileges should be limited for non-root users. Review the man page for pam_console
for more information
Security identifiers
- CCE-3685-5
References
2.2.2.b. Restrict Console Device Access to Servers
If the display manager has been altered to allow remote users to log in and the host is configured to run at runlevel 5, change console as well as the xconsole directive in the /etc/security/console.perms
to the following:
<console>=tty[0-9][0-9]* vc/[0-9][0-9]*
When a user logs in, the module pam_console.so called via the command login, or by some of the graphics program of logging, such as gdm, kdm, and xdm. If this user is the first to log into the physical console - called the console user - the user module assures the mastery of a wide variety of devices normally belong to root. Administrative privileges should be limited for non-root users. Review the man page for pam_console
for more information
Security identifiers
- CCE-3685-5
References
2.2.2.c. 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 the appropriate
file in /etc/modprobe.d/
to prevent loading of the usb-storage
kernel module:
install usb-storage /bin/true
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.
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.
Security identifiers
- CCE-4187-1
References
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1250. URL: <http://iase.disa.mil/cci/index.html>.
- 85. URL: <http://iase.disa.mil/cci/index.html>.
2.2.2.d. 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. 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.
Disabling the USB subsystem within the Linux kernel at system boot will also disable USB storage devices if they are plugged into the sytem. Support for these devices should be disabled and the devices themselves should be tightly controlled.
Security identifiers
- CCE-4173-1
References
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1250. URL: <http://iase.disa.mil/cci/index.html>.
- 85. URL: <http://iase.disa.mil/cci/index.html>.
2.2.2.e. 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 the section titled "Set BIOS Password" to prevent unauthorized configuration changes.
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.
Security identifiers
- CCE-3944-6
References
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1250. URL: <http://iase.disa.mil/cci/index.html>.
- 85. URL: <http://iase.disa.mil/cci/index.html>.
2.2.2.f. Disable the Automounter
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
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.
Security identifiers
- CCE-4072-5
References
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1250. URL: <http://iase.disa.mil/cci/index.html>.
- 85. URL: <http://iase.disa.mil/cci/index.html>.
2.2.2.g. Disable GNOME Automounting
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
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.
Security identifiers
- CCE-4231-7
References
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1250. URL: <http://iase.disa.mil/cci/index.html>.
- 85. URL: <http://iase.disa.mil/cci/index.html>.
2.2.2.h. Disable Mounting of cramfs
Using the install
command inside the appropriate .conf file inside/etc/modprobe.d
instructs the kernel module loading system to run the command
specified (here, /bin/true
) instead of inserting the module in the
kernel as normal. This effectively prevents usage of these uncommon
filesystems.
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled.
Security identifiers
- CCE-14089-7
References
2.2.2.i. Disable Mounting of freevxfs
Using the install
command inside the appropriate /etc/modprobe.d
configuration file.
instructs the kernel module loading system to run the command
specified (here, /bin/true
) instead of inserting the module in the
kernel as normal. This effectively prevents usage of these uncommon
filesystems.
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled.
Security identifiers
- CCE-14457-6
References
2.2.2.j. Disable Mounting of jffs2
Using the install
command inside the appropriate /etc/modprobe.d
configuration file.
instructs the kernel module loading system to run the command
specified (here, /bin/true
) instead of inserting the module in the
kernel as normal. This effectively prevents usage of these uncommon
filesystems.
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled.
Security identifiers
- CCE-14853-6
References
2.2.2.k. Disable Mounting of hfs
Using the install
command inside the appropriate /etc/modprobe.d
configuration file.
instructs the kernel module loading system to run the command
specified (here, /bin/true
) instead of inserting the module in the
kernel as normal. This effectively prevents usage of these uncommon
filesystems.
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled.
Security identifiers
- CCE-15087-0
References
2.2.2.l. Disable Mounting of hfsplus
Using the install
command inside the appropriate /etc/modprobe.d
configuration file.
instructs the kernel module loading system to run the command
specified (here, /bin/true
) instead of inserting the module in the
kernel as normal. This effectively prevents usage of these uncommon
filesystems.
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled.
Security identifiers
- CCE-14093-9
References
2.2.2.m. Disable Mounting of squashfs
Using the install
command inside the appropriate /etc/modprobe.d
configuration file.
instructs the kernel module loading system to run the command
specified (here, /bin/true
) instead of inserting the module in the
kernel as normal. This effectively prevents usage of these uncommon
filesystems.
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled.
Security identifiers
- CCE-14118-4
References
2.2.2.n. Disable Mounting of udf
Using the install
command inside the appropriate /etc/modprobe.d
configuration file.
instructs the kernel module loading system to run the command
specified (here, /bin/true
) instead of inserting the module in the
kernel as normal. This effectively prevents usage of these uncommon
filesystems.
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled.
Security identifiers
- CCE-14871-8
References
2.2.2.o. Disable All GNOME Thumbnailers
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.
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.
Security identifiers
- CCE-TODO
References
2.2.3. Verify Permissions on Important Files and Directories
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.
link | previous | next | up | toc | home
2.2.3.a. Verify that All World-Writable Directories Have Sticky Bits Set
When the so-called 'sticky bit' is set on a directory,
only the owner of a given file may remove that file from the
directory. Without the sticky bit, any user with write access to a
directory may remove any file in the directory. Setting the sticky
bit prevents users from removing each other's files. In cases where
there is no reason for a directory to be world-writable, a better
solution is to remove that permission rather than to set the sticky
bit. However, if a directory is used by a particular application,
consult that application's documentation instead of blindly
changing modes.
To set the sticky bit on a world-writable directory DIR, run the
following command:
# chmod +t DIR
Security identifiers
- CCE-3399-3
References
2.2.3.b. Ensure No World-Writable Files Exist
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.
Security identifiers
- CCE-3795-2
References
2.2.3.c. Ensure All Setgid Executables Are Authorized
The SGID (set group id) bit should be set only on files that were installed via authorized means. A straightforward means of identifying unauthorized SGID files is determine if any were not installed as part of an RPM package, which is cryptographically verified. Investigate the origin of any unpackaged SGID files.
Executable files with the SGID permission run with the privileges of the owner of the file. SGID files of uncertain provenance could allow for unprivileged users to elevate privileges. The presence of these files should be strictly controlled on the system.
Security identifiers
- CCE-14970-8
References
2.2.3.d. Ensure All SUID Executables Are Authorized
The SUID (set user id) bit should be set only on files that were installed via authorized means. A straightforward means of identifying unauthorized SGID files is determine if any were not installed as part of an RPM package, which is cryptographically verified. Investigate the origin of any unpackaged SUID files.
Executable files with the SUID permission run with the privileges of the owner of the file. SUID files of uncertain provenance could allow for unprivileged users to elevate privileges. The presence of these files should be strictly controlled on the system.
Security identifiers
- CCE-14340-4
References
2.2.3.e. Ensure All Files Are Owned by a User
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.
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 that they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed.
Security identifiers
- CCE-4223-4
References
2.2.3.f. Ensure All Files Are Owned by a Group
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.
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 that they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed.
Security identifiers
- CCE-3573-3
References
2.2.3.g. Ensure All World-Writable Directories Are Owned by a System Account
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.
Allowing a user account to own a world-writeable 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.
Security identifiers
- CCE-14794-2
References
2.2.3.8. Verify Permissions on Files with Local Account Information and Credentials
The default restritctive 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.
link | previous | next | up | toc | home
2.2.3.8.a. Verify User Who Owns shadow File
To properly set the owner of /etc/shadow
, run the command:
# chown root /etc/shadow
The /etc/shadow
file contains the list of local
system accounts and stores password hashes. Protection of this file is
critical for system security. Failure to give ownership of this file
to root provides the designated owner with access to sensitive information
which could weaken the system security posture.
Security identifiers
- CCE-3918-0
References
2.2.3.8.b. Verify Group Who Owns shadow File
To properly set the group owner of /etc/shadow
, run the command:
# chgrp root /etc/shadow
The /etc/shadow
file stores password hashes. Protection of this file is
critical for system security.
Security identifiers
- CCE-3988-3
References
2.2.3.8.c. Verify Permissions on shadow File
To properly set the permissions of /etc/shadow
, run the command:
# chmod 0000 /etc/shadow
The /etc/shadow
file contains the list of local
system accounts and stores password hashes. Protection of this file is
critical for system security. Failure to give ownership of this file
to root provides the designated owner with access to sensitive information
which could weaken the system security posture.
Security identifiers
- CCE-4130-1
References
2.2.3.8.d. Verify User Who Owns group File
To properly set the owner of /etc/group
, run the command:
# chown root /etc/group
The /etc/group
file contains information regarding groups that are configured
on the system. Protection of this file is important for system security.
Security identifiers
- CCE-3276-3
References
2.2.3.8.e. Verify Group Who Owns group File
To properly set the group owner of /etc/group
, run the command:
# chgrp root /etc/group
The /etc/group
file contains information regarding groups that are configured
on the system. Protection of this file is important for system security.
Security identifiers
- CCE-3883-6
References
2.2.3.8.f. Verify Permissions on group File
To properly set the permissions of /etc/group
, run the command:
# chmod 644 /etc/group
The /etc/group
file contains information regarding groups that are configured
on the system. Protection of this file is important for system security.
Security identifiers
- CCE-3967-7
References
2.2.3.8.g. Verify User Who Owns gshadow File
To properly set the owner of /etc/gshadow
, run the command:
# chown root /etc/gshadow
The /etc/gshadow
file contains group password hashes. Protection of this file
is critical for system security.
Security identifiers
- CCE-4210-1
References
2.2.3.8.h. Verify Group Who Owns gshadow File
To properly set the group owner of /etc/gshadow
, run the command:
# chgrp root /etc/gshadow
The /etc/gshadow
file contains group password hashes. Protection of this file
is critical for system security.
Security identifiers
- CCE-4064-2
References
2.2.3.8.i. Verify Permissions on gshadow File
To properly set the permissions of /etc/gshadow
, run the command:
# chmod 0000 /etc/gshadow
The /etc/gshadow file contains group password hashes. Protection of this file is critical for system security.
Security identifiers
- CCE-3932-1
References
2.2.3.8.j. Verify User Who Owns passwd File
To properly set the owner of /etc/passwd
, run the command:
# chown root /etc/passwd
The /etc/passwd
file should be owned by
root.
The /etc/passwd
contains information about the users that are configured on
the system. Protection of this file is critical for system security.
Security identifiers
- CCE-3958-6
References
2.2.3.8.k. Verify Group Who Owns passwd File
To properly set the group owner of /etc/passwd
, run the command:
# chgrp root /etc/passwd
The /etc/passwd
file contains information about the users that are configured on
the system. Protection of this file is critical for system security.
Security identifiers
- CCE-3495-9
References
2.2.3.8.l. Verify Permissions on passwd File
To properly set the permissions of /etc/passwd
, run the command:
# chmod 0644 /etc/passwd
If the /etc/passwd
file is writable by a group-owner or the
world the risk of its compromise is increased. The file contains the list of
acounts on the system and associated information, and protection of this file
is critical for system security.
Security identifiers
- CCE-3566-7
References
2.2.3.9. Verify File Permissions Within Some Important Directories
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.
link | previous | next | up | toc | home
2.2.3.9.a. Verify that Shared Library Files Have Restrictive Permissions
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.
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.
2.2.3.9.b. Verify that Shared Library Files Have Root Ownership
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.
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.
2.2.3.9.c. Verify that System Executables Have Restrictive Permissions
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.
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.
2.2.3.9.d. Verify that System Executables Have Root Ownership
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.
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.
2.2.4. Restrict Programs from Dangerous Execution Patterns
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.
link | previous | next | up | toc | home
2.2.4.1. Daemon Umask
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.
link | previous | next | up | toc | home
2.2.4.1.a. Set Daemon Umask
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.
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.
Security identifiers
- CCE-4220-0
References
2.2.4.2. Disable Core Dumps
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.
link | previous | next | up | toc | home
2.2.4.2.a. Disable Core Dumps for All Users
To disable core dumps for all users, add the following line to
/etc/security/limits.conf
:
* hard core 0
A core dump includes a memory image taken at the time the operating system terminates an application. The memory image could contain sensitive data and is generally useful only for developers trying to debug problems.
Security identifiers
- CCE-4225-9
References
2.2.4.2.b. Disable Core Dumps for SUID programs
To set the runtime status of the fs.suid_dumpable
kernel parameter,
run the following command:
# sysctl -w fs.suid_dumpable0
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.
Security identifiers
- CCE-4247-3
References
2.2.4.3. Enable ExecShield
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
.
link | previous | next | up | toc | home
2.2.4.3.a. Enable ExecShield
To set the runtime status of the kernel.exec-shield
kernel parameter,
run the following command:
# sysctl -w kernel.exec-shield1
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.
Security identifiers
- CCE-4168-1
References
2.2.4.3.b. Enable Randomized Layout of Virtual Address Space
To set the runtime status of the kernel.randomize_va_space
kernel parameter,
run the following command:
# sysctl -w kernel.randomize_va_space1
Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code he or she has introduced into a process's address space during an attempt at exploitation. ASLR also 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.
Security identifiers
- CCE-4146-7
References
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.
link | previous | next | up | toc | home
2.2.4.4.a. Install PAE Kernel on Supported 32-bit x86 Systems
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.
Security identifiers
- CCE-4172-3
References
2.2.4.4.b. Enable NX or XD Support in the BIOS
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.
Security identifiers
- CCE-4177-2
References
2.3. SELinux
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 RHEL6, 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.
link | previous | next | up | toc | home
2.3.a. Enable the SELinux Context Restoration Service (restorecond)
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 that the file receives the proper SELinux
security context.
The restorecond
service can be enabled with the following command:
# chkconfig restorecond on
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.
Security identifiers
- CCE-4129-3
References
2.3.b. Ensure No Daemons are Unconfined by SELinux
Daemons for which the SELinux policy does not contain rules will inherit the
context of the parent process. Because daemons are launched during
startup and descend from the init
process, they inherit the initrc_t
context.
To check for unconfined daemons, run the following command:
# ps -eZ | egrep "initrc" | egrep -vw "tr|ps|egrep|bash|awk" | tr ':' ' ' | awk '{ print $NF }'
It should produce no output in a well-configured system.
Daemons which run with the initrc_t
context may cause AVC denials,
or allow privileges that the daemon does not require.
References
2.3.c. Ensure No Device Files are Unlabeled by SELinux
Device files are used for communication with important system resources.
SELinux contexts should exist for these. By checking for unlabeled_t
file
contexts, we can determine if the system is optimally configured.
If a device file is not labeled, then misconfiguration is likely.
Security identifiers
- CCE-14991-4
References
2.3.4. Enable SELinux
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 relabelled for consistency using the command touch
/.autorelabel
, and reboot.
However, the RHEL6 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.
References
- 26. URL: <http://iase.disa.mil/cci/index.html>.
- 1084. URL: <http://iase.disa.mil/cci/index.html>.
- 1086. URL: <http://iase.disa.mil/cci/index.html>.
- 1087. URL: <http://iase.disa.mil/cci/index.html>.
- 1090. URL: <http://iase.disa.mil/cci/index.html>.
- 1091. URL: <http://iase.disa.mil/cci/index.html>.
- 1424. URL: <http://iase.disa.mil/cci/index.html>.
- 1426. URL: <http://iase.disa.mil/cci/index.html>.
- 802. URL: <http://iase.disa.mil/cci/index.html>.
link | previous | next | up | toc | home
2.3.4.a. Ensure SELinux Not Disabled in /etc/grub.conf
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 being disabled at boot.
Disabling a major host protection feature, such as SELinux, at boot time prevents it from confining system services at boot time. Further, it increases the chances that it will remain off during system operation.
Security identifiers
- CCE-3977-6
References
2.3.4.b. Ensure SELinux State is Enforcing
The SELinux state should be set to enforcing
at
system boot time. In the file /etc/selinux/config
, add or correct the
line SELINUX=enforcing
to configure the system to boot into enforcing
mode.
Setting the SELinux state to enforcing ensures that 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.
Security identifiers
- CCE-3999-0
References
2.3.4.c. Configure SELinux Policy
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.
Setting the SELinux policy to targeted
or a more specialized policy
ensures that the system will confine processes that are likely to be
targeted for exploitation, such as network services or system services.
Security identifiers
- CCE-3624-4
References
2.4. 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 RHEL6.
link | previous | next | up | toc | home
2.4.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.
link | previous | next | up | toc | home
2.4.1.1. Restrict Root Logins
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.
References
- 770. URL: <http://iase.disa.mil/cci/index.html>.
link | previous | next | up | toc | home
2.4.1.1.a. Restrict Virtual Console Root Logins
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
Preventing direct root login to virtual console devices helps ensure accountability for actions taken on the system using the root account.
Security identifiers
- CCE-3485-0
References
2.4.1.1.b. Restrict Serial Port Root Logins
To restrict root logins on serial ports,
ensure lines of this form do not appear in /etc/securetty
:
ttyS0
ttyS1
Preventing direct root login to serial port interfaces helps ensure accountability for actions taken on the systems using the root account.
Security identifiers
- CCE-4256-4
References
2.4.1.1.c. Ensure that System Accounts Do Not Run a Shell Upon Login
Some accounts are not associated with a human
user of the system, and exist to perform some administrative
function. Should an attacker be able to log into these accounts,
he or she should not be granted access to a shell.
Ensure that no shells are granted to system accounts.
First, obtain a listing of all users,
their UIDs, and their shells, 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.
Do not perform the steps in this section on the root account. Doing so might cause the system to become inaccessible.
Ensuring shells are not given to system accounts upon login makes it more difficult for attackers to make use of system accounts.
Security identifiers
- CCE-3987-5
References
2.4.1.1.d. Verify Only Root Has UID 0
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.
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 provilieged account. Proper configuration of sudo is recommended to afford multiple System Administrators access to the root account.
Security identifiers
- CCE-4009-7
References
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-11. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 366. URL: <http://iase.disa.mil/cci/index.html>.
2.4.1.2. Verify Proper Storage and Existence of Password Hashes
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.
link | previous | next | up | toc | home
2.4.1.2.a. Prevent Log In to Accounts With Empty Password
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-ac
to
prevent logins with empty passwords.
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.
Security identifiers
- CCE-4238-2
References
2.4.1.2.b. Verify All Account Password Hashes are Shadowed
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.
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.
Security identifiers
- CCE-14300-8
References
2.4.1.2.c. Verify No netrc Files Exist
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.
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.
Security identifiers
- CCE-TODO
References
2.4.1.3. Set Password Expiration Parameters
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
link | previous | next | up | toc | home
2.4.1.3.a. Set Password Minimum Length in login.defs
To specify password length requirements for new accounts,
edit the file /etc/login.defs
and add or correct the following
lines:
PASS_MIN_LEN LENGTH
The DoD requirement is
14
.
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.
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.
Security identifiers
- CCE-4154-1
References
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 205. URL: <http://iase.disa.mil/cci/index.html>.
2.4.1.3.b. Set Password Minimum Age
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
The DoD requirement is 7.
Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement.
Security identifiers
- CCE-4180-6
References
2.4.1.3.c. Set Password Maximum Age
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.
Setting the password maximum age ensures that 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.
Security identifiers
- CCE-4092-3
References
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 199. URL: <http://iase.disa.mil/cci/index.html>.
2.4.1.3.d. Set Password Warning Age
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:
PASS_WARN_AGE DAYS
A value of 7 days is considered for appropriate for many
environments.
Setting the password warning age enables users to make the change at a practical time.
Security identifiers
- CCE-4097-2
References
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
2.4.1.4. Set Account Expiration Parameters
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/defaults/useradd
controls
default settings for all newly-created accounts created with the system's
normal command line utilities.
link | previous | next | up | toc | home
2.4.1.4.a. Set Account Expiration Following Inactivity
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/defaults/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.
Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials.
References
- 15. URL: <http://iase.disa.mil/cci/index.html>.
- 16. URL: <http://iase.disa.mil/cci/index.html>.
- 17. URL: <http://iase.disa.mil/cci/index.html>.
- 795. URL: <http://iase.disa.mil/cci/index.html>.
2.4.2. Protect Accounts by Configuring PAM
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.
References
- 1391. URL: <http://iase.disa.mil/cci/index.html>.
- 1392. URL: <http://iase.disa.mil/cci/index.html>.
link | previous | next | up | toc | home
2.4.2.a. Set Password Hashing Algorithm
The system's default algorithm for storing password hashes in
/etc/shadow
is SHA-512.
In order to ensure the system is still configured to use SHA-512 algorithm,
the following line must appear in /etc/login.defs
:
ENCRYPT_METHOD SHA512
Also ensure that the pam_unix.so
module in the password
section in
/etc/pam.d/system-auth
includes the argument sha512
.
If this is not the case, the following command can be run to fix:
# /usr/sbin/authconfig --passalgo=sha512 --update
This ensures that when users change their passwords, hashes for the new passwords
will be generated using the SHA-512 algorithm.
Using a stronger hashing algorithm makes password cracking attacks more difficult.
Security identifiers
- CCE-14063-2
References
2.4.2.b. Limit Password Reuse
Do not allow users to reuse recent passwords. This can
be accomplished by using the remember
option for the pam_unix
PAM
module. In order to prevent a user from re-using any of their
last 5 passwords,
append remember=5
to
the password line which uses the pam_unix
module in the file
/etc/pam.d/system-auth
, as shown:
password sufficient pam_unix.so existing_options remember=5
Old (and thus no longer valid) passwords are stored in the
file /etc/security/opasswd
. The DoD requirement is currently 24 passwords.
Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user.
Security identifiers
- CCE-14939-3
References
2.4.2.3. 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. 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.
link | previous | next | up | toc | home
2.4.2.3.1. Set Password Quality Requirements, if using pam_cracklib
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 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=0
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.
link | previous | next | up | toc | home
2.4.2.3.1.a. Set Password Retry Prompts Permitted Per-session
The pam_cracklib module's retry=
parameter controls how many times a program
will re-prompt a user after an incorrect password entry, on a per-session basis. To configure this, open:
/etc/pam.d/system-auth
Locate the retry=
parameter, the DoD required value is 3.
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.
Security identifiers
- CCE-15054-0
References
- IA-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1092. URL: <http://iase.disa.mil/cci/index.html>.
2.4.2.3.1.b. Set Password Strength Minimum Digit Characters
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.
Requiring digits makes password guessing attacks more difficult by ensuring a larger search space.
Security identifiers
- CCE-14113-5
References
2.4.2.3.1.c. Set Password Strength Minimum Uppercase Characters
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.
Requiring a minimum number of uppercase characters makes password guessing attacks more difficult by ensuring a larger search space.
Security identifiers
- CCE-14672-0
References
2.4.2.3.1.d. Set Password Strength Minimum Special Characters
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.
Requiring a minimum number of special characters makes password guessing attacks more difficult by ensuring a larger search space.
Security identifiers
- CCE-14122-6
References
- IA-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1619. URL: <http://iase.disa.mil/cci/index.html>.
2.4.2.3.1.e. Set Password Strength Minimum Lowercase Characters
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.
Requiring a minimum number of lowercase characters makes password guessing attacks more difficult by ensuring a larger search space.
Security identifiers
- CCE-14712-4
References
2.4.2.3.1.f. Set Password Strength Minimum Different Characters
The pam_cracklib module's difok=
parameter controls requirements for
usage of different characters during a password change.
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.
Security identifiers
- CCE-14701-7
References
2.4.2.4. Set Lockouts for Failed Password Attempts
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.
link | previous | next | up | toc | home
2.4.2.4.a. Set Deny For Failed Password Attempts
This requires further investigation.
Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks.
Security identifiers
- CCE-3410-8
References
- AC-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1452. URL: <http://iase.disa.mil/cci/index.html>.
- 44. URL: <http://iase.disa.mil/cci/index.html>.
- 47. URL: <http://iase.disa.mil/cci/index.html>.
2.4.3. 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.
link | previous | next | up | toc | home
2.4.3.a. Limit the Number of Concurrent Login Sessions Allowed Per User
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. To set the number of concurrent
sessions per user add the following line in /etc/security/limits.conf
:
* hard maxlogins MAX
Where MAX is the maximum number of login sessions allowed.
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.
References
- 54. URL: <http://iase.disa.mil/cci/index.html>.
2.4.3.b. Ensure that User Home Directories are not Group-Writable or World-Readable
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
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 subdirectories 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.
Security identifiers
- CCE-4090-7
References
2.4.3.3. Ensure that No Dangerous Directories Exist in Root's 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.
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.
link | previous | next | up | toc | home
2.4.3.3.a. Ensure that Root's Path Does Not Include Relative Paths or Null Directories
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.
Security identifiers
- CCE-3301-9
References
2.4.3.3.b. Ensure that Root's Path Does Not Include World or Group-Writable Directories
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.
Security identifiers
- CCE-14957-5
References
2.4.3.4. Ensure that Users Have Sensible Umask Values
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.
link | previous | next | up | toc | home
2.4.3.4.a. Ensure the Default Bash Umask is Set Correctly
To ensure the default umask for users of the Bash shell is set properly,
add or correct the umask
setting in /etc/bashrc
to read
as follows:
umask 077
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/or written to by unauthorized users.
Security identifiers
- CCE-3844-8
References
2.4.3.4.b. Ensure the Default C Shell Umask is Set Correctly
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
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/or written to by unauthorized users.
Security identifiers
- CCE-4227-5
References
2.4.3.4.c. Ensure the Default Umask is Set Correctly in /etc/profile
To ensure the default umask controlled by /etc/profile
is set properly,
add or correct the umask
setting in /etc/profile
to read as follows:
umask 077
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/or written to by unauthorized users.
Security identifiers
- CCE-14847-8
References
2.4.3.4.d. Ensure the Default Umask is Set Correctly in login.defs
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
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/or written to by unauthorized users.
Security identifiers
- CCE-14107-7
References
2.4.4. 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.
link | previous | next | up | toc | home
2.4.4.a. 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.
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
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.
Security identifiers
- CCE-4241-6
References
2.4.4.b. Disable Interactive Boot
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.
Using interactive boot, the console user could disable auditing, firewalls, or other services, weakening system security.
Security identifiers
- CCE-4245-7
References
2.4.4.3. 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.
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, the boot loader configuration
should be protected with a password and its configuration file's permissions
should be set properly.
If any correction is needed for the permissions on /etc/grub.conf
, (which is a symlink to
../boot/grub/grub.conf
) the following commands can be used:
# chown root:root /etc/grub.conf
# chmod 600 /etc/grub.conf
link | previous | next | up | toc | home
2.4.4.3.a. Verify /boot/grub/grub.conf User Ownership
The file /etc/grub.conf
is a symbolic link to
/boot/grub/grub.conf
which should be owned by the root
user
to prevent destruction or modification of the file.
To properly set the owner of /boot/grub/grub.conf
, run the command:
# chown root /boot/grub/grub.conf
Only root should be able to modify important boot parameters.
Security identifiers
- CCE-4144-2
References
2.4.4.3.b. Verify /boot/grub/grub.conf Group Ownership
The file /etc/grub.conf
is a symbolic link to
/boot/grub/grub.conf
which should be group-owned by the root
group to prevent destruction or modification of the file.
To properly set the group owner of /boot/grub/grub.conf
, run the command:
# chgrp /boot/grub/grub.conf
The root
group is a highly-privileged group. Furthermore, the group-owner of this
file should not have any access privileges anyway.
Security identifiers
- CCE-4197-0
References
2.4.4.3.c. Verify /boot/grub/grub.conf Permissions
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 /boot/grub/grub.conf
Proper permissions ensure that only the root user can modify important boot parameters.
Security identifiers
- CCE-3923-0
References
2.4.4.3.d. Set Boot Loader Password
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:
# grub-crypt --sha-512
You will then be 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
Password protection on the boot loader configuration ensures that users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode.
Security identifiers
- CCE-3818-2
References
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 213. URL: <http://iase.disa.mil/cci/index.html>.
2.4.4.4. 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, 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.
link | previous | next | up | toc | home
2.4.4.4.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.
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)
.
link | previous | next | up | toc | home
2.4.4.4.1.a. Set GNOME Login Inactivity Timeout
The idle time-out value for period of inactivity GNOME desktop lockout should be 15 minutes.
# gconftool-2 \
--direct \
--config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
--type int \
--set /apps/gnome-screensaver/idle_delay 15
Setting the idle delay controls when the screensaver will start, and can be combined with screen locking to prevent access from passersby.
Security identifiers
- CCE-3315-9
References
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-11. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 57. URL: <http://iase.disa.mil/cci/index.html>.
2.4.4.4.1.b. GNOME Desktop Screensaver Mandatory Use
Idle activation of the screen saver should be enabled
# gconftool-2 --direct \
--config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
--type bool \
--set /apps/gnome-screensaver/idle_activation_enabled true
Enabling idle activation of the screen saver ensures that the screensaver will be activated after the idle delay.
Security identifiers
- CCE-14604-3
References
2.4.4.4.1.c. Enable Screen Lock Activation After Idle Period
Idle activation of the screen lock should be enabled.
# gconftool-2 --direct \
--config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
--type bool \
--set /apps/gnome-screensaver/lock_enabled true
Enabling the activation of the screen lock after an idle period ensures that password entry will be required in order to access the system, preventing access by passersby.
Security identifiers
- CCE-14023-6
References
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-11. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 57. URL: <http://iase.disa.mil/cci/index.html>.
2.4.4.4.1.d. Implement Blank Screen Saver
The screen saver should be blank.
# gconftool-2
--direct \
--config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
--type string \
--set /apps/gnome-screensaver/mode blank-only
Setting the screensaver mode to blank-only conceals the contents of the display from passersby.
Security identifiers
- CCE-14735-5
References
2.4.4.4.2. Configure Console Screen Locking
A console screen locking mechanism is provided in the vlock package, which is not installed by default.
link | previous | next | up | toc | home
2.4.4.4.2.a. Install the vlock Package
To enable console screen locking, 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.
Installing vlock ensures that a console locking capability is available for users who may need to suspend console logins.
Security identifiers
- CCE-3910-7
References
2.4.4.4.3. Using Smart Cards for System Login
The use of smart cards, like Common Access Cards (CAC), for system login
provides stronger, two-factor authentication than using a username/password.
Smart cards take advantage of Public Key Infrastructure (PKI) to store
encrypted digital certificates that can be used to authenticate the card
owner.
In Red Hat Enterprise Linux servers and workstations, smart card login
is not enabled by default and must be enabled in the system settings.
Detailed procedures on how to configure a system to use smart card
authentication for login can be found in the Red Hat Documentation web site:
-
https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html
It is recommended to use smart cards wherever feasible as part of a multifactor authentication system.
References
- 765. URL: <http://iase.disa.mil/cci/index.html>.
- 766. URL: <http://iase.disa.mil/cci/index.html>.
- 767. URL: <http://iase.disa.mil/cci/index.html>.
- 768. URL: <http://iase.disa.mil/cci/index.html>.
- 771. URL: <http://iase.disa.mil/cci/index.html>.
- 772. URL: <http://iase.disa.mil/cci/index.html>.
- 884. URL: <http://iase.disa.mil/cci/index.html>.
2.4.5. Warning Banners for System Accesses
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.
link | previous | next | up | toc | home
2.4.5.a. Modify the System Login Banner
The contents of the file /etc/issue
are
displayed on the screen just above the login prompt for users
logging directly into a terminal. Remote login programs such as
SSH or FTP can be configured to display /etc/issue
as well.
Instructions for configuring these daemons are available later.
By default, the system will display the version of the OS,
the kernel version, and the host name.
Edit /etc/issue
. Replace the default text with a message
compliant with the local site policy or a legal disclaimer.
Although unlikely to dissuade a serious attacker, the warning message reinforces policy awareness during the logon process.
Security identifiers
- CCE-4060-0
2.4.5.2. Implement a GUI Warning Banner
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.
link | previous | next | up | toc | home
2.4.5.2.a. Enable GUI Warning 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.
Although unlikely to dissuade a serious attacker, the warning message reinforces policy awareness during the logon process.
Security identifiers
- CCE-4188-9
2.4.5.2.b. Set GUI Warning Banner Text
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.
Although unlikely to dissuade a serious attacker, the warning message reinforces policy awareness during the logon process.
Security identifiers
- CCE-4188-9
2.4.5.3. Disable the User List
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
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.
link | previous | next | up | toc | home
2.4.5.3.a. Disable the User List
GDM's list of previously logged in users should not be displayed.
References
2.5. Network Configuration and Firewalls
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 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.
link | previous | next | up | toc | home
2.5.a. Disable Unused Interfaces
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
The network interfaces expand the attack surface of a system. Although unusual, if they are not needed they should be disabled.
References
2.5.b. Disable Zeroconf Networking
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
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.
Security identifiers
- CCE-14054-1
References
2.5.c. Ensure System is Not Acting as a Network Sniffer
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
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.
Security identifiers
- CCE-15013-6
References
2.5.4. Kernel Parameters Which Affect Networking
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.
link | previous | next | up | toc | home
2.5.4.1. Network Parameters for Hosts Only
If the system is not going to be used as a router, then certain kernel parameters should be set to ensure that the host will not perform routing of network traffic.
link | previous | next | up | toc | home
2.5.4.1.a. Disable Kernel Parameter for Sending ICMP Redirects by Default
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_redirects0
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 routers.
Security identifiers
- CCE-4151-7
References
2.5.4.1.b. Disable Kernel Parameter for Sending ICMP Redirects for All Interfaces
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_redirects0
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 routers.
Security identifiers
- CCE-4155-8
References
2.5.4.1.c. Disable Kernel Parameter for IP Forwarding
To set the runtime status of the net.ipv4.ip_forward
kernel parameter,
run the following command:
# sysctl -w net.ipv4.ip_forward0
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 routers.
Security identifiers
- CCE-3561-8
References
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
2.5.4.2. Network Related Kernel Runtime Parameters for Hosts and 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.
link | previous | next | up | toc | home
2.5.4.2.a. Disable Kernel Parameter for Accepting Source-Routed Packets for All Interfaces
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_route0
Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required.
Security identifiers
- CCE-4236-6
References
2.5.4.2.b. Disable Kernel Parameter for Accepting ICMP Redirects for All Interfaces
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_redirects0
Accepting ICMP redirects has few legitimate uses. It should be disabled unless it is absolutely required.
Security identifiers
- CCE-4217-6
References
2.5.4.2.c. Disable Kernel Parameter for Accepting Secure Redirects for All Interfaces
To set the runtime status of the net.ipv4.conf.all.secure_redirects
kernel parameter,
run the following command:
# sysctl -w net.ipv4.conf.all.secure_redirects0
Accepting "secure" ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required.
Security identifiers
- CCE-3472-8
References
2.5.4.2.d. Enable Kernel Parameter to Log Martian Packets
To set the runtime status of the net.ipv4.conf.all.log_martians
kernel parameter,
run the following command:
# sysctl -w net.ipv4.conf.all.log_martians1
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.
Security identifiers
- CCE-4320-8
References
2.5.4.2.e. Disable Kernel Parameter for Accepting Source-Routed Packets By Default
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_route0
Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required.
Security identifiers
- CCE-4091-5
References
2.5.4.2.f. Disable Kernel Parameter for Accepting ICMP Redirects By Default
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_redirects0
This feature of the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required.
Security identifiers
- CCE-4186-3
References
2.5.4.2.g. Disable Kernel Parameter for Accepting Secure Redirects By Default
To set the runtime status of the net.ipv4.conf.default.secure_redirects
kernel parameter,
run the following command:
# sysctl -w net.ipv4.conf.default.secure_redirects0
Accepting "secure" ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required.
Security identifiers
- CCE-3339-9
References
2.5.4.2.h. Enable Kernel Parameter to Ignore ICMP Broadcast Echo Requests
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_broadcasts1
Ignoring ICMP echo requests (pings) sent to broadcast or multicast addresses makes the system slightly more difficult to enumerate on the network.
Security identifiers
- CCE-3644-2
References
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
2.5.4.2.i. Enable Kernel Parameter to Ignore Bogus ICMP Error Responses
To set the runtime status of the net.ipv4.icmp_ignore_bogus_error_responses
kernel parameter,
run the following command:
# sysctl -w net.ipv4.icmp_ignore_bogus_error_responses1
Ignoring bogus ICMP error responses reduces log size, although some activity would not be logged.
Security identifiers
- CCE-4133-5
References
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
2.5.4.2.j. Enable Kernel Parameter to Use TCP Syncookies
To set the runtime status of the net.ipv4.tcp_syncookies
kernel parameter,
run the following command:
# sysctl -w net.ipv4.tcp_syncookies1
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.
Security identifiers
- CCE-4265-5
2.5.4.2.k. Enable Kernel Parameter to Use Reverse Path Filtering for All Interfaces
To set the runtime status of the net.ipv4.conf.all.rp_filter
kernel parameter,
run the following command:
# sysctl -w net.ipv4.conf.all.rp_filter1
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.
Security identifiers
- CCE-4080-8
References
2.5.4.2.l. Enable Kernel Parameter to Use Reverse Path Filtering by Default
To set the runtime status of the net.ipv4.conf.default.rp_filter
kernel parameter,
run the following command:
# sysctl -w net.ipv4.conf.default.rp_filter1
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.
Security identifiers
- CCE-3840-6
References
2.5.5. Wireless Networking
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 includes 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 instead focus on disabling wireless capability
via software.
link | previous | next | up | toc | home
2.5.5.1. Disable Wireless Through Software Configuration
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.
link | previous | next | up | toc | home
2.5.5.1.a. Disable WiFi or Bluetooth BIOS
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.
Disabling wireless support in the BIOS prevents easy activation of the wireless interface, generally requiring administrators to reboot the system first.
Security identifiers
- CCE-3628-5
References
2.5.5.1.b. Deactivate Wireless Network Interfaces
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
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.
Security identifiers
- CCE-4276-2
References
2.5.5.1.c. Disable Bluetooth Service
The bluetooth
service can be disabled with the following command:
# chkconfig bluetooth off
Disabling the bluetooth
service prevents the system from attempting
connections to 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.
Security identifiers
- CCE-4355-4
References
- AC-18. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 85. URL: <http://iase.disa.mil/cci/index.html>.
2.5.5.1.d. Disable Bluetooth Kernel Modules
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/true
install bluetooth /bin/true
If Bluetooth functionality must be disabled, preventing the kernel from loading the kernel module provides an additional safeguard against its activation.
Security identifiers
- CCE-14948-4
References
- AC-18. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 85. URL: <http://iase.disa.mil/cci/index.html>.
2.5.6. IPv6
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.
link | previous | next | up | toc | home
2.5.6.1. Disable Support for IPv6 unless Needed
Despite configuration that suggests support for IPv6 has been disabled, link-local IPv6 address autoconfiguration 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 IPv6 kernel module not to load it.
link | previous | next | up | toc | home
2.5.6.1.a. Disable IPv6 Networking Support Automatic Loading
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.
Any unnecessary network stacks - including IPv6 - should be disabled, to reduce the vulnerability to exploitation.
Security identifiers
- CCE-3562-6
References
2.5.6.1.b. Disable Interface Usage of IPv6
To prevent configuration of IPv6 for all interfaces, add or correct the following lines in /etc/sysconfig/network
:
NETWORKING_IPV6=no
IPV6INIT=no
For each network interface IFACE , add or correct the following lines in /etc/sysconfig/network-scripts/
ifcfg-IFACE as an additional prevention mechanism:
IPV6INIT=no
References
2.5.6.1.c. Disable Support for RPC IPv6
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 - -
References
2.5.6.2. Configure IPv6 Settings if Necessary
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 always preferable to accepting it from the network in an unauthenticated fashion.
link | previous | next | up | toc | home
2.5.6.2.a. Manually Assign Global IPv6 Address
To manually assign an IP address for an interface IFACE , edit the file /etc/sysconfig/network-scripts/ifcfg-IFACE
. 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.
References
2.5.6.2.b. Use Privacy Extensions for Address
To introduce randomness into the automatic generation of IPv6 addresses, add or correct the following line in /etc/sysconfig/network-scripts/ifcfg-IFACE
:
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.
Security identifiers
- CCE-3842-2
References
2.5.6.2.c. Manually Assign IPv6 Router Address
Edit the file /etc/sysconfig/network-scripts/ifcfg-IFACE
, 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 autoconfiguration or router advertisement.
References
2.5.6.2.d. Limit Network-Transmitted Configuration
Add the following lines to /etc/sysctl.conf
to limit the configuration information requested from other systems, and accepted from the network:
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.
Security identifiers
- CCE-4221-8
- CCE-4137-6
- CCE-4159-0
- CCE-3895-0
- CCE-4287-9
- CCE-4058-4
- CCE-4128-5
References
2.5.6.2.5. Disable Automatic Configuration
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
link | previous | next | up | toc | home
2.5.6.2.5.a. Disable Accepting IPv6 Router Advertisements
The default setting for accepting IPv6 router
advertisements should be: 0
for all interfaces. To do so add the following lines to /etc/sysctl.conf
to limit the configuration information requested from other systems, and accepted from the network:
net.ipv6.conf.default.accept_ra = 0
Security identifiers
- CCE-4269-7
References
2.5.6.2.5.b. Disable Accepting IPv6 Redirects
The setting for accepting IPv6 redirects should be: 0
for all interfaces. To do so add the following lines to /etc/sysctl.conf
to limit the configuration information requested from other systems, and accepted from the network:
net.ipv6.conf.default.accept_redirects = 0
An illicit ICMP redirect message could result in a man-in-the-middle attack.
Security identifiers
- CCE-4313-3
References
2.5.7. Iptables and Ip6tables
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.
References
- 66. URL: <http://iase.disa.mil/cci/index.html>.
- 86. URL: <http://iase.disa.mil/cci/index.html>.
link | previous | next | up | toc | home
2.5.7.1. Inspect and Activate Default Rules
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 RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
1 RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 255
3 ACCEPT esp -- 0.0.0.0/0 0.0.0.0/0
4 ACCEPT ah -- 0.0.0.0/0 0.0.0.0/0
5 ACCEPT udp -- 0.0.0.0/0 224.0.0.251 udp dpt:5353
6 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:631
7 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:631
8 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
9 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
10 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with
icmp-host-prohibited
The ip6tables
default rules are similar, with its rules 2 and
10 reflecting protocol naming and addressing differences. Instead
of rule 8, however, ip6tables
includes two rules that accept all
incoming udp and tcp packets with a particular destination port
range. This is because the current Netfilter implementation for
IPv6 lacks reliable connection-tracking functionality.
link | previous | next | up | toc | home
2.5.7.1.a. Verify ip6tables Enabled
The ip6tables
service can be enabled with the following command:
# chkconfig ip6tables on
The ip6tables
service provides the system's host-based firewalling
capability for IPv6 and ICMPv6.
Security identifiers
- CCE-4167-3
References
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 66. URL: <http://iase.disa.mil/cci/index.html>.
- 1115. URL: <http://iase.disa.mil/cci/index.html>.
- 1118. URL: <http://iase.disa.mil/cci/index.html>.
- 1092. URL: <http://iase.disa.mil/cci/index.html>.
- 1117. URL: <http://iase.disa.mil/cci/index.html>.
- 1098. URL: <http://iase.disa.mil/cci/index.html>.
- 1100. URL: <http://iase.disa.mil/cci/index.html>.
- 1097. URL: <http://iase.disa.mil/cci/index.html>.
- 1123. URL: <http://iase.disa.mil/cci/index.html>.
- 1124. URL: <http://iase.disa.mil/cci/index.html>.
- 1414. URL: <http://iase.disa.mil/cci/index.html>.
2.5.7.1.b. Verify iptables Enabled
The iptables
service can be enabled with the following command:
# chkconfig iptables on
The iptables
service provides the system's host-based firewalling
capability for IPv4 and ICMP.
Security identifiers
- CCE-4189-7
References
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 66. URL: <http://iase.disa.mil/cci/index.html>.
- 1115. URL: <http://iase.disa.mil/cci/index.html>.
- 1118. URL: <http://iase.disa.mil/cci/index.html>.
- 1092. URL: <http://iase.disa.mil/cci/index.html>.
- 27. URL: <http://iase.disa.mil/cci/index.html>.
- 1117. URL: <http://iase.disa.mil/cci/index.html>.
- 1098. URL: <http://iase.disa.mil/cci/index.html>.
- 1100. URL: <http://iase.disa.mil/cci/index.html>.
- 1097. URL: <http://iase.disa.mil/cci/index.html>.
- 1123. URL: <http://iase.disa.mil/cci/index.html>.
- 1124. URL: <http://iase.disa.mil/cci/index.html>.
- 1414. URL: <http://iase.disa.mil/cci/index.html>.
2.5.7.2. Strengthen the Default Ruleset
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.
link | previous | next | up | toc | home
2.5.7.2.a. Set Default Iptables Policy for Incoming Packets
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]
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.
Security identifiers
- CCE-14264-6
References
- AC-4. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 66. URL: <http://iase.disa.mil/cci/index.html>.
- 1109. URL: <http://iase.disa.mil/cci/index.html>.
- 1154. URL: <http://iase.disa.mil/cci/index.html>.
- 1414. URL: <http://iase.disa.mil/cci/index.html>.
2.5.7.2.b. Set Default Iptables Policy for Forwarded Packets
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]
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.
Security identifiers
- CCE-14264-6
References
2.5.7.2.3. Restrict ICMP Message Types
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 RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
and insert the lines:
-A RH-Firewall-1-INPUT -p icmp --icmp-type echo-reply -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
To allow the system to respond to pings, also insert the following line:
-A RH-Firewall-1-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 RH-Firewall-1-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 RH-Firewall-1-INPUT -p icmpv6 --icmpv6-type router-advertisement -j DROP
Restricting other ICMPv6 message types in /etc/sysconfig/ip6tables
is not recommended because the oper-
ation of IPv6 depends heavily on ICMPv6. Thus, more care must be taken when blocking ICMPv6 types.
References
2.5.7.2.4. Log and Drop Packets with Suspicious Source Addresses
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 -i eth0 -s 10.0.0.0/8 -j LOG --log-prefix "IP DROP SPOOF A: "
-A INPUT -i eth0 -s 172.16.0.0/12 -j LOG --log-prefix "IP DROP SPOOF B: "
-A INPUT -i eth0 -s 192.168.0.0/16 -j LOG --log-prefix "IP DROP SPOOF C: "
-A INPUT -i eth0 -s 224.0.0.0/4 -j LOG --log-prefix "IP DROP MULTICAST D: "
-A INPUT -i eth0 -s 240.0.0.0/5 -j LOG --log-prefix "IP DROP SPOOF E: "
-A INPUT -i eth0 -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 autoconfiguration 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: "
References
2.5.8. Secure Sockets Layer Support
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 certificates
-
Create SSL certificates for servers using that CA
-
Enable client support by distributing the CA’s certificate
References
- 1141. URL: <http://iase.disa.mil/cci/index.html>.
- 1148. URL: <http://iase.disa.mil/cci/index.html>.
- 1130. URL: <http://iase.disa.mil/cci/index.html>.
- 1131. URL: <http://iase.disa.mil/cci/index.html>.
- 1127. URL: <http://iase.disa.mil/cci/index.html>.
- 1128. URL: <http://iase.disa.mil/cci/index.html>.
- 1135. URL: <http://iase.disa.mil/cci/index.html>.
- 1129. URL: <http://iase.disa.mil/cci/index.html>.
- 1132. URL: <http://iase.disa.mil/cci/index.html>.
- 1142. URL: <http://iase.disa.mil/cci/index.html>.
- 1147. URL: <http://iase.disa.mil/cci/index.html>.
- 187. URL: <http://iase.disa.mil/cci/index.html>.
link | previous | next | up | toc | home
2.5.8.1. Create a CA to Sign Certificates
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 key
-
creates 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.
References
2.5.8.2. Create SSL Certificates for Servers
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:
-
Postfix
-
Dovecot
-
Apache
References
2.5.8.3. Enable Client Support
The system ships with certificates from well-known commercial CAs. If your server certificates were signed by one of these established CAs, then this step is not necessary since the clients should include the CA certificate already. If your servers use certificates signed by your own CA, some user applications will warn that the server’s certificate cannot be verified because the CA is not recognized. Other applications may simply fail to accept the certificate and refuse to operate, or continue operating without ever having properly verified the server certificate. To avoid this warning, and properly authenticate the servers, your CA certificate must be exported to every application on every client system that will be connecting to an SSL-enabled server.
References
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-17. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-12. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-13. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 185. URL: <http://iase.disa.mil/cci/index.html>.
2.5.8.4. Adding a Trusted CA for Firefox
To import a new CA certificate into Firefox:
-
Launch Firefox and choose Preferences from the menu.
-
Click the Advanced button.
-
Select the Encryption tab.
-
Click the View Certificates button.
-
Select the Authorities tab.
-
Click the Import button at the bottom of the screen.
-
Navigate to the CA certificate and import it. Determine whether the CA should be used to identify web sites, e-mail users, and software developers and trust it for each accordingly.
References
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-17. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-12. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-13. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
2.5.8.5. Adding a Trusted CA for Thunderbird
To import a new CA certificate into Thunderbird:
-
Launch Thunderbird and choose Preferences from the menu.
-
Click the Advanced button.
-
Select the Encryption tab.
-
Click the View Certificates button.
-
Select the Authorities tab.
-
Click the Import button at the bottom of the screen.
-
Navigate to the CA certificate and import it. Determine whether the CA should be used to identify web sites, e-mail users, and software developers and trust it for each accordingly.
References
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-17. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-12. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-13. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
2.5.8.6. Adding a Trusted CA for Evolution
To import a new CA certificate into Evolution:
-
Launch Evolution and choose Preferences from the menu.
-
Click the Advanced button.
-
Select the Encryption tab.
-
Click the View Certificates button.
-
Select the Authorities tab.
-
Click the Import button at the bottom of the screen.
-
Navigate to the CA certificate and import it. Determine whether the CA should be used to identify web sites, e-mail users, and software developers and trust it for each accordingly.
References
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-17. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-12. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-13. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
2.5.8.7. Remove Certificate Authorities, if Appropriate
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.
References
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-17. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-12. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-13. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
2.5.9. Uncommon Network Protocols
The system includes support for several network protocols which are not commonly used. Although security vul- nerabilities 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.
link | previous | next | up | toc | home
2.5.9.a. Disable DCCP Support
The Datagram Congestion Control Protocol (DCCP) is a
relatively new transport layer protocol, designed to support
streaming media and telephony.
To configure the system to prevent the dccp
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d
:
install dccp /bin/true
Disabling DCCP protects the system against exploitation of any flaws in its implementation.
Security identifiers
- CCE-14268-7
References
2.5.9.b. Disable SCTP Support
The Stream Control Transmission Protocol (SCTP) is a
transport layer protocol, designed to support the idea of
message-oriented communication, with several streams of messages
within one connection.
To configure the system to prevent the sctp
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d
:
install sctp /bin/true
Disabling SCTP protects the system against exploitation of any flaws in its implementation.
Security identifiers
- CCE-14132-5
References
2.5.9.c. Disable RDS Support
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/true
Disabling RDS protects the system against exploitation of any flaws in its implementation.
Security identifiers
- CCE-14027-7
References
2.5.9.d. Disable TIPC Support
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/true
Disabling TIPC protects the system against exploitation of any flaws in its implementation.
Security identifiers
- CCE-14911-2
References
2.5.10. IPSec Support
Support for Internet Protocol Security (IPsec) is provided in RHEL 6 with Openswan.
link | previous | next | up | toc | home
2.5.10.a. Install openswan Package
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
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.
References
- AC-17. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- MA-4. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-9. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1130. URL: <http://iase.disa.mil/cci/index.html>.
- 1131. URL: <http://iase.disa.mil/cci/index.html>.
- 1135. URL: <http://iase.disa.mil/cci/index.html>.
2.6. Configure Syslog
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.
link | previous | next | up | toc | home
2.6.a. Ensure rsyslog is Installed
Rsyslog is installed by default.
The rsyslog
package can be installed with the following command:
# yum install rsyslog
The rsyslog package provides the rsyslog daemon, which provides system logging services.
Security identifiers
- CCE-17742-8
References
2.6.b. Enable rsyslog Service
The rsyslog
service provides syslog-style logging by default on RHEL 6.
The rsyslog
service can be enabled with the following command:
# chkconfig rsyslog on
The rsyslog
service must be running in order to provide
logging services, which are essential to system administration.
Security identifiers
- CCE-17698-2
References
- AU-12. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1557. URL: <http://iase.disa.mil/cci/index.html>.
- 1312. URL: <http://iase.disa.mil/cci/index.html>.
- 1311. URL: <http://iase.disa.mil/cci/index.html>.
2.6.c. Disable Logwatch on Clients if a Logserver Exists
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.
2.6.4. Ensure Proper Configuration of Log Files
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
link | previous | next | up | toc | home
2.6.4.a. Ensure Log Files Exist
The log files written by rsyslog
are determined by the second part of each rule line in
/etc/rsyslog.conf
. These typically all appear in /var/log
.
For any log file LOGFILE referenced in /etc/rsyslog.conf
which
does not already exist the following commands will create it and apply proper
permissions:
# touch LOGFILE
# chown root:root LOGFILE
# chmod 0600 LOGFILE
If a log file referenced by rsyslog does not exist, rsyslog will not create it and important log messages can be lost.
Security identifiers
- CCE-18095-0
References
2.6.4.b. Ensure Log Files Are Owned By Appropriate User
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
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
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.
Security identifiers
- CCE-17857-4
References
2.6.4.c. Ensure Log Files Are Owned By Appropriate Group
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
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.
Security identifiers
- CCE-18240-2
References
2.6.4.d. Ensure System Log Files Have Correct Permissions
The file permissions for all log files written by
rsyslog should be set to 600, or more restrictive.
These log files are determined by the second part of each Rule line in
/etc/rsyslog.conf
and typically all appear in /var/log
.
For each log file LOGFILE referenced in /etc/rsyslog.conf
,
run the following command to inspect the file's permissions:
$ ls -l LOGFILE
If the permissions are not 600 or more restrictive,
run the following command to correct this:
# chmod 0600 LOGFILE
Log files can contain valuable information regarding system configuratation. If the system log files are not protected unauthorized users could change the logged data, eliminaating their foresive value.
Security identifiers
- CCE-18095-0
References
2.6.5. Rsyslog Logs Sent To Remote Host
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.
link | previous | next | up | toc | home
2.6.5.a. Ensure Logs Sent To Remote Host
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
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.
Security identifiers
- CCE-17248-6
References
- AU-2. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-9. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1348. URL: <http://iase.disa.mil/cci/index.html>.
- 136. URL: <http://iase.disa.mil/cci/index.html>.
- 1352. URL: <http://iase.disa.mil/cci/index.html>.
2.6.6. Configure rsyslogd to Accept Remote Messages If Acting as a Log Server
By default, RHEL6's 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.
link | previous | next | up | toc | home
2.6.6.a. Ensure rsyslog Does Not Accept Remote Messages Unless Acting As Log Server
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
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.
Security identifiers
- CCE-17639-6
References
2.6.6.b. Enable rsyslog to Accept Messages via TCP, if Acting As Log Server
The rsyslog
daemon should not accept remote messages
unless the system acts as a log server.
If the system needs to act as a central log server, add the following lines to
/etc/rsyslog.conf
to enable reception of messages over TCP:
$ModLoad imtcp.so
$InputTCPServerRun 514
If the system needs to act as a log server, this ensures that it can receive messages over a reliable TCP connection.
Security identifiers
- CCE-TODO
References
2.6.6.c. Enable rsyslog to Accept Messages via UDP, if Acting As Log Server
The rsyslog
daemon should not accept remote messages
unless the system acts as a log server.
If the system needs to act as a central log server, add the following lines to
/etc/rsyslog.conf
to enable reception of messages over UDP:
$ModLoad imudp.so
$InputUDPServerRun 514
Many devices, such as switches, routers, and other Unix-like systems, may only support the traditional syslog transmission over UDP. If the system must act as a log server, this enables it to receive their messages as well.
Security identifiers
- CCE-TODO
References
2.6.7. Ensure All Logs are Rotated by logrotate
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.
link | previous | next | up | toc | home
2.6.7.a. Ensure Logrotate Runs Periodically
The logrotate
service should be
enabled.
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.
Security identifiers
- CCE-4182-2
References
2.6.8. Configure Logwatch on the Central Log Server
Is this machine the central log server? If so, edit the file /etc/logwatch/conf/logwatch.conf
as shown below.
link | previous | next | up | toc | home
2.6.8.a. Configure Logwatch HostLimit Line
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
Security identifiers
- CCE-4323-2
2.6.8.b. Configure Logwatch SplitHosts Line
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
Security identifiers
- CCE-4323-2
2.7. System Accounting with auditd
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 includegetattr
,read
, andwrite
.
-
-
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, isexe="/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: thesamba_share_t
type is not accessible to processes running in thehttpd_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 asinitrc_t
andkernel_t
.exe="/usr/sbin/httpd"
: the full path to the executable that launched the process, which in this case, isexe="/usr/sbin/httpd"
.
References
- 120. URL: <http://iase.disa.mil/cci/index.html>.
- 135. URL: <http://iase.disa.mil/cci/index.html>.
- 166. URL: <http://iase.disa.mil/cci/index.html>.
- 1338. URL: <http://iase.disa.mil/cci/index.html>.
- 1339. URL: <http://iase.disa.mil/cci/index.html>.
- 157. URL: <http://iase.disa.mil/cci/index.html>.
link | previous | next | up | toc | home
2.7.a. Enable auditd Service
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 auditd on
Ensuring that the auditd
service is active ensures that
audit records generated by the kernel can be written to disk, or that appropriate
actions will be taken if other obstacles exist.
Security identifiers
- CCE-4292-9
References
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 169. URL: <http://iase.disa.mil/cci/index.html>.
- 172. URL: <http://iase.disa.mil/cci/index.html>.
- 174. URL: <http://iase.disa.mil/cci/index.html>.
- 1353. URL: <http://iase.disa.mil/cci/index.html>.
- 1462. URL: <http://iase.disa.mil/cci/index.html>.
- 1487. URL: <http://iase.disa.mil/cci/index.html>.
- 1115. URL: <http://iase.disa.mil/cci/index.html>.
- 1454. URL: <http://iase.disa.mil/cci/index.html>.
- 067. URL: <http://iase.disa.mil/cci/index.html>.
- 158. URL: <http://iase.disa.mil/cci/index.html>.
- 831. URL: <http://iase.disa.mil/cci/index.html>.
- 1123. URL: <http://iase.disa.mil/cci/index.html>.
- 1190. URL: <http://iase.disa.mil/cci/index.html>.
- 1312. URL: <http://iase.disa.mil/cci/index.html>.
- 1263. URL: <http://iase.disa.mil/cci/index.html>.
- 130. URL: <http://iase.disa.mil/cci/index.html>.
2.7.b. Enable Auditing for Processes Which Start Prior to the Audit Daemon
To ensure that 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
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 that it is set for every
process during boot.
Security identifiers
- CCE-15026-8
References
- AU-2. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1464. URL: <http://iase.disa.mil/cci/index.html>.
- 130. URL: <http://iase.disa.mil/cci/index.html>.
2.7.3. Configure auditd Data Retention
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
insuffcient. 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.
References
- 138. URL: <http://iase.disa.mil/cci/index.html>.
link | previous | next | up | toc | home
2.7.3.a. Configure auditd Number of Logs Retained
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.
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 maxium log file size and the number of logs retained.
2.7.3.b. Configure auditd Max Log File Size
Determine the amount of audit data (in megabytes)
which should be retained in each log file. Edit the file
/etc/audit/auditd.conf
. Add or modify the following line, substituting
the correct value 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.
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 maxium log file size and the number of logs retained.
2.7.3.c. Configure auditd max_log_file_action Upon Reaching Maximum Log Size
The default action to take when the logs reach their maximum size
is to rotate the log files, discarding the oldest one. To configure the action taken
by auditd
, add or correct the line:
max_log_file_action = ACTION
Possible values for ACTION are described in the auditd.conf
man
page. These include:
-
ignore
-
syslog
-
suspend
-
rotate
-
keep_logs
Set the ACTION
to rotate
to ensure log rotation
occurs. This is the default. The setting is case-insensitive.
Automatically rotating logs (by setting this to rotate
)
minimizes the chances of the system unexpectedly running out of disk space by
being overwhelmed with log data. However, for systems that must never discard
log data, or which use external processes to transfer it and reclaim space,
keep_logs
can be employed.
2.7.3.d. Configure auditd space_left Action on Low Disk Space
The auditd
service can be configured to take an action
when disk space starts to run low.
Edit the file /etc/audit/auditd.conf
. Modify the following line,
substituting ACTION appropriately:
space_left_action = ACTION
Possible values for ACTION are described in the auditd.conf
man page.
These include:
-
ignore
-
syslog
-
email
-
exec
-
suspend
-
single
-
halt
Set this to email
(instead of the default,
which is suspend
) as it is more likely to get prompt attention.
Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption.
References
- 140. URL: <http://iase.disa.mil/cci/index.html>.
- 143. URL: <http://iase.disa.mil/cci/index.html>.
- 144. URL: <http://iase.disa.mil/cci/index.html>.
2.7.3.e. Configure auditd admin_space_left Action on Low Disk Space
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:
-
ignore
-
syslog
-
email
-
exec
-
suspend
-
single
-
halt
Set this value to single
to cause the system to switch to single user
mode for corrective action. For certain systems, the need for availability
outweighs the need to log all actions, and a different setting should be
determined.
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.
References
- 140. URL: <http://iase.disa.mil/cci/index.html>.
- 143. URL: <http://iase.disa.mil/cci/index.html>.
- 144. URL: <http://iase.disa.mil/cci/index.html>.
- 1343. URL: <http://iase.disa.mil/cci/index.html>.
2.7.3.f. Configure auditd mail_acct Action on Low Disk Space
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
Email sent to the root account is typically aliased to the administrators of the system, who can take appropriate action.
References
- 139. URL: <http://iase.disa.mil/cci/index.html>.
2.7.4. Configure auditd Rules for Comprehensive Auditing
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
References
- 171. URL: <http://iase.disa.mil/cci/index.html>.
- 172. URL: <http://iase.disa.mil/cci/index.html>.
- 1115. URL: <http://iase.disa.mil/cci/index.html>.
- 1454. URL: <http://iase.disa.mil/cci/index.html>.
- 1487. URL: <http://iase.disa.mil/cci/index.html>.
- 1571. URL: <http://iase.disa.mil/cci/index.html>.
- 1589. URL: <http://iase.disa.mil/cci/index.html>.
- 880. URL: <http://iase.disa.mil/cci/index.html>.
- 347. URL: <http://iase.disa.mil/cci/index.html>.
- 85. URL: <http://iase.disa.mil/cci/index.html>.
- 1274. URL: <http://iase.disa.mil/cci/index.html>.
- 1356. URL: <http://iase.disa.mil/cci/index.html>.
- 374. URL: <http://iase.disa.mil/cci/index.html>.
- 130. URL: <http://iase.disa.mil/cci/index.html>.
link | previous | next | up | toc | home
2.7.4.a. Record Events that Modify User/Group Information
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
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.
Security identifiers
- CCE-14829-6
References
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 18. URL: <http://iase.disa.mil/cci/index.html>.
- 1403. URL: <http://iase.disa.mil/cci/index.html>.
- 1404. URL: <http://iase.disa.mil/cci/index.html>.
- 1405. URL: <http://iase.disa.mil/cci/index.html>.
- 1684. URL: <http://iase.disa.mil/cci/index.html>.
- 1683. URL: <http://iase.disa.mil/cci/index.html>.
- 1685. URL: <http://iase.disa.mil/cci/index.html>.
- 1686. URL: <http://iase.disa.mil/cci/index.html>.
2.7.4.b. Record Events that Modify the System's Network Environment
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
The network environment should not be modified by anything other than administrator action. Any change to network parameters should be audited.
Security identifiers
- CCE-14816-3
References
2.7.4.c. Record Events that Modify the System's Mandatory Access Controls
Add the following to /etc/audit/audit.rules
:
-w /etc/selinux/ -p wa -k MAC-policy
The system's mandatory access policy (SELinux) should not be arbitrarily changed by anything other than administrator action. All changes to MAC policy should be audited.
Security identifiers
- CCE-14821-3
References
2.7.4.d. Record Attempts to Alter Logon and Logout Events
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
Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion.
Security identifiers
- CCE-14904-7
2.7.4.e. Record Attempts to Alter Process and Session Initiation Information
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
Manual editing of these files may indicate nefarious activity, such as an attacker attempting to remove evidence of an intrusion.
Security identifiers
- CCE-14679-5
2.7.4.f. Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful)
At a minimum the audit system should collect
unauthorized file accesses for all users and root. 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
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.
Security identifiers
- CCE-14917-9
References
- AU-2.1 (v). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2 d. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 126. URL: <http://iase.disa.mil/cci/index.html>.
2.7.4.g. Ensure auditd Collects Information on the Use of Privileged Commands
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 / -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
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.
Security identifiers
- CCE-14296-8
References
2.7.4.h. Ensure auditd Collects Information on Exporting to Media (successful)
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
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.
Security identifiers
- CCE-14569-8
References
2.7.4.i. Ensure auditd Collects File Deletion Events by User
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
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.
Security identifiers
- CCE-14820-5
References
2.7.4.j. Ensure auditd Collects System Administrator Actions
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
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.
Security identifiers
- CCE-14824-7
References
2.7.4.k. Ensure auditd Collects Information on Kernel Module Loading and Unloading
Add the following to /etc/audit/audit.rules
in order
to capture kernel module loading and unloading events:
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -S init_module -S delete_module -k modules
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.
Security identifiers
- CCE-14688-6
References
2.7.4.l. Make the auditd Configuration Immutable
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.
Making the audit configuration immutable prevents accidential as well as malicious modification of the audit rules, although it may be problematic if legitimate changes are needed during system operation
Security identifiers
- CCE-14692-8
References
2.7.4.13. Records Events that Modify Date and Time Information
Arbitrary changes to the system time can be used to obfuscate nefarious activites 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.
link | previous | next | up | toc | home
2.7.4.13.a. Record attempts to alter time through adjtimex
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
Arbitrary changes to the system time can be used to obfuscate nefarious activites 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.
Security identifiers
- CCE-14051-7
References
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1487. URL: <http://iase.disa.mil/cci/index.html>.
- 169. URL: <http://iase.disa.mil/cci/index.html>.
2.7.4.13.b. Record attempts to alter time through settimeofday
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
Arbitrary changes to the system time can be used to obfuscate nefarious activites 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.
Security identifiers
- CCE-14051-7
References
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1487. URL: <http://iase.disa.mil/cci/index.html>.
- 169. URL: <http://iase.disa.mil/cci/index.html>.
2.7.4.13.c. Record Attempts to Alter Time Through stime
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
Arbitrary changes to the system time can be used to obfuscate nefarious activites 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.
Security identifiers
- CCE-14051-7
References
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1487. URL: <http://iase.disa.mil/cci/index.html>.
- 169. URL: <http://iase.disa.mil/cci/index.html>.
2.7.4.13.d. Record Attempts to Alter Time Through clock_settime
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
Arbitrary changes to the system time can be used to obfuscate nefarious activites 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.
Security identifiers
- CCE-14051-7
References
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1487. URL: <http://iase.disa.mil/cci/index.html>.
- 169. URL: <http://iase.disa.mil/cci/index.html>.
2.7.4.13.e. Record Attempts to Alter the localtime File
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.
Arbitrary changes to the system time can be used to obfuscate nefarious activites 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.
Security identifiers
- CCE-14051-7
References
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1487. URL: <http://iase.disa.mil/cci/index.html>.
- 169. URL: <http://iase.disa.mil/cci/index.html>.
2.7.4.14. Record Events that Modify the System's Discretionary Access Controls
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 acheiving the desired effect. An example of this is that the "-S" calls
could be split up and placed on seperate 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 amoung both authorized and unauthorized users.
link | previous | next | up | toc | home
2.7.4.14.a. Record Events that Modify the System's Discretionary Access Controls - chmod
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 acheiving the desired effect. Here the system calls have been placed independant of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse amoung both authorized and unauthorized users.
Security identifiers
- CCE-14058-2
References
2.7.4.14.b. Record Events that Modify the System's Discretionary Access Controls - chown
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 acheiving the desired effect. Here the system calls have been placed independant of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse amoung both authorized and unauthorized users.
Security identifiers
- CCE-14058-2
References
2.7.4.14.c. Record Events that Modify the System's Discretionary Access Controls - fchmod
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 acheiving the desired effect. Here the system calls have been placed independant of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse amoung both authorized and unauthorized users.
Security identifiers
- CCE-14058-2
References
2.7.4.14.d. Record Events that Modify the System's Discretionary Access Controls - fchmodat
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 acheiving the desired effect. Here the system calls have been placed independant of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse amoung both authorized and unauthorized users.
Security identifiers
- CCE-14058-2
References
2.7.4.14.e. Record Events that Modify the System's Discretionary Access Controls - fchown
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 acheiving the desired effect. Here the system calls have been placed independant of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse amoung both authorized and unauthorized users.
Security identifiers
- CCE-14058-2
References
2.7.4.14.f. Record Events that Modify the System's Discretionary Access Controls - fchownat
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 acheiving the desired effect. Here the system calls have been placed independant of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse amoung both authorized and unauthorized users.
Security identifiers
- CCE-14058-2
References
2.7.4.14.g. Record Events that Modify the System's Discretionary Access Controls - fremovexattr
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 acheiving the desired effect. Here the system calls have been placed independant of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse amoung both authorized and unauthorized users.
Security identifiers
- CCE-14058-2
References
2.7.4.14.h. Record Events that Modify the System's Discretionary Access Controls - fsetxattr
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 acheiving the desired effect. Here the system calls have been placed independant of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse amoung both authorized and unauthorized users.
Security identifiers
- CCE-14058-2
References
2.7.4.14.i. Record Events that Modify the System's Discretionary Access Controls - lchown
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 acheiving the desired effect. Here the system calls have been placed independant of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse amoung both authorized and unauthorized users.
Security identifiers
- CCE-14058-2
References
2.7.4.14.j. Record Events that Modify the System's Discretionary Access Controls - lremovexattr
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 acheiving the desired effect. Here the system calls have been placed independant of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse amoung both authorized and unauthorized users.
Security identifiers
- CCE-14058-2
References
2.7.4.14.k. Record Events that Modify the System's Discretionary Access Controls - lsetxattr
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 acheiving the desired effect. Here the system calls have been placed independant of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse amoung both authorized and unauthorized users.
Security identifiers
- CCE-14058-2
References
2.7.4.14.l. Record Events that Modify the System's Discretionary Access Controls - removexattr
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 acheiving the desired effect. Here the system calls have been placed independant of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse amoung both authorized and unauthorized users.
Security identifiers
- CCE-14058-2
References
2.7.4.14.m. Record Events that Modify the System's Discretionary Access Controls - setxattr
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 acheiving the desired effect. Here the system calls have been placed independant of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse amoung both authorized and unauthorized users.
Security identifiers
- CCE-14058-2
References
3. Services
The best protection against vulnerable software is running less software. This section describes how to review
the software which Red Hat Enterprise Linux installs on a system and disable software which is not needed. It
then enumerates the software packages installed on a default RHEL6 system and provides guidance about which
ones can be safely disabled.
RHEL6 provides a convenient minimal install option that essentially installs the bare necessities for a functional
system. When building RHEL6 servers it is highly recommended to select the minimal packages and then build up
the system from there.
Table of Contents
- 3.1. Obsolete Services
-
3.2. Base Services
- 3.2.a. Disable Automatic Bug Reporting Tool (abrtd)
- 3.2.b. Disable Advanced Configuration and Power Interface (acpid)
- 3.2.c. Disable At Service (atd)
- 3.2.d. Disable Certmonger Service (certmonger)
- 3.2.e. Disable Control Group Config (cgconfig)
- 3.2.f. Disable Control Group Rules Engine (cgred)
- 3.2.g. Disable CPU Speed (cpuspeed)
- 3.2.h. Disable Hardware Abstraction Layer Service (haldaemon)
- 3.2.i. Enable IRQ Balance (irqbalance)
- 3.2.j. Disable KDump Kernel Crash Analyzer (kdump)
- 3.2.k. Disable Software RAID Monitor (mdmonitor)
- 3.2.l. Disable D-Bus IPC Service (messagebus)
- 3.2.m. Disable Network Console (netconsole)
- 3.2.n. Disable ntpdate Service (ntpdate)
- 3.2.o. Disable Odd Job Daemon (oddjobd)
- 3.2.p. Disable Portreserve (portreserve)
- 3.2.q. Enable Process Accounting (psacct)
- 3.2.r. Disable Apache Qpid (qpidd)
- 3.2.s. Disable Quota Netlink (quota_nld)
- 3.2.t. Disable Network Router Discovery Daemon (rdisc)
- 3.2.u. Disable Red Hat Network Service (rhnsd)
- 3.2.v. Disable Red Hat Subscription Manager Daemon (rhsmcertd)
- 3.2.w. Disable Cyrus SASL Authentication Daemon (saslauthd)
- 3.2.x. Disable SMART Disk Monitoring Service (smartd)
- 3.2.y. Disable System Statistics Reset Service (sysstat)
- 3.3. Cron and At Daemons
-
3.4. SSH Server
- 3.4.a. Disable SSH Server If Possible (Unusual)
- 3.4.b. Remove SSH Server iptables Firewall exception (Unusual)
-
3.4.3. Configure OpenSSH Server if Necessary
- 3.4.3.a. Allow Only SSH Protocol 2
- 3.4.3.b. Limit Users' SSH Access
- 3.4.3.c. Set SSH Idle Timeout Interval
- 3.4.3.d. Set SSH Client Alive Count
- 3.4.3.e. Disable SSH Support for .rhosts Files
- 3.4.3.f. Disable Host-Based Authentication
- 3.4.3.g. Disable SSH Root Login
- 3.4.3.h. Disable SSH Access via Empty Passwords
- 3.4.3.j. Do Not Allow SSH Environment Options
- 3.4.3.k. Use Only Approved Ciphers
- 3.4.3.12. Strengthen Firewall Configuration if Possible
- 3.5. X Window System
- 3.6. Avahi Server
- 3.7. Print Support
- 3.8. DHCP
- 3.9. Network Time Protocol
-
3.10. Mail Server Software
- 3.10.a. Enable Postfix (postfix)
- 3.10.2. Configure SMTP For Mail Clients
-
3.10.3. Configure Operating System to Protect Mail Server
- 3.10.3.a. Configure iptables to Allow Access to the Mail Server
- 3.10.3.b. Verify System Logging and Log Permissions for Mail
- 3.10.3.3. Use Separate Hosts for External and Internal Mail if Possible
- 3.10.3.4. Protect the MTA Host from User Access
- 3.10.3.5. Restrict Remote Access to the Mail Spool
- 3.10.3.6. Configure SSL Certificates for Use with SMTP AUTH
- 3.10.4. Configure Postfix if Necessary
-
3.11. LDAP
- 3.11.1. Configure OpenLDAP Clients
-
3.11.2. Configure OpenLDAP Server
- 3.11.2.a. Uninstall openldap-servers Package
- 3.11.2.b. Configure Domain-Specific Parameters
- 3.11.2.c. LDAP Configuration File Security
- 3.11.2.d. Configure LDAP Root Password
- 3.11.2.e. Protect LDAP Certificate Files
- 3.11.2.f. Configure slapd to Protect Authentication Information
- 3.11.2.g. Correct Permissions on LDAP Server Files
- 3.11.2.h. Configure iptables to Allow Access to the LDAP Server
- 3.11.2.i. Configure Logging for LDAP
- 3.11.2.10. Create Top-level LDAP Structure for Domain
- 3.11.2.11. Create LDAP Structures for Users and Groups
- 3.11.2.12. Create Unix Accounts
- 3.11.2.13. Create Unix Groups
- 3.11.2.14. Create Groups to Administer LDAP
-
3.12. NFS and RPC
- 3.12.1. Disable All NFS Services if Possible
- 3.12.2. Configure All Machines which Use NFS
- 3.12.3. Configure NFS Clients
-
3.12.4. Configure NFS Servers
- 3.12.4.a. Use Root-Squashing on All Exports
- 3.12.4.b. Restrict NFS Clients to Privileged Ports
- 3.12.4.c. Ensure Insecure File Locking is Not Allowed
- 3.12.4.4. Configure the Exports File Restrictively
- 3.12.4.5. Use Access Lists to Enforce Authorization Restrictions
- 3.12.4.6. Export Filesystems Read-Only if Possible
- 3.12.4.7. Specify UID and GID for Anonymous Connections
- 3.13. DNS Server
-
3.14. FTP Server
- 3.14.1. Disable vsftpd if Possible
- 3.14.2. Use vsftpd to Provide FTP Service if Necessary
- 3.14.3. Use vsftpd to Provide FTP Service if Necessary
-
3.15. Web Server
- 3.15.1. Disable Apache if Possible
- 3.15.2. Install Apache if Necessary
-
3.15.3. Secure Apache Configuration
- 3.15.3.1. Restrict Web Server Information Leakage
-
3.15.3.2. Minimize Web Server Loadable Modules
-
3.15.3.2.1. httpd Core Modules
- 3.15.3.2.1.a. Disable HTTP Digest Authentication
- 3.15.3.2.1.b. Disable HTTP mod_rewrite
- 3.15.3.2.1.c. Disable LDAP Support
- 3.15.3.2.1.d. Disable Server Side Includes
- 3.15.3.2.1.e. Disable MIME Magic
- 3.15.3.2.1.f. Disable WebDAV (Distributed Authoring and Versioning)
- 3.15.3.2.1.g. Disable Server Activity Status
- 3.15.3.2.1.h. Disable Web Server Configuration Display
- 3.15.3.2.1.i. Disable URL Correction on Misspelled Entries
- 3.15.3.2.1.j. Disable Proxy Support
- 3.15.3.2.1.k. Disable Cache Support
- 3.15.3.2.1.l. Disable CGI Support
- 3.15.3.2.1.13. Minimize Modules for HTTP Basic Authentication
- 3.15.3.2.1.14. Minimize Various Optional Components
- 3.15.3.2.1.15. Minimize Configuration Files Included
-
3.15.3.2.1. httpd Core Modules
- 3.15.3.3. Directory Restrictions
- 3.15.3.4. Use Appropriate Modules to Improve httpd's Security
- 3.15.3.5. Use Denial-of-Service Protection Modules
- 3.15.3.6. Configure PHP Securely
- 3.15.3.7. Configure Operating System to Protect Web Server
- 3.16. IMAP and POP3 Server
-
3.17. Samba(SMB) Microsoft Windows File Sharing Server
- 3.17.1. Disable Samba if Possible
-
3.17.2. Configure Samba if Necessary
- 3.17.2.a. Disable Root Access
- 3.17.2.b. Disable Root Access
- 3.17.2.c. Require Client SMB Packet Signing, if using smbclient
- 3.17.2.d. Require Client SMB Packet Signing, if using mount.cifs
- 3.17.2.5. Let Domain Controllers Create Machine Trust Accounts On-the-Fly
- 3.17.2.6. Restrict Access to the [IPC$] Share
- 3.17.2.7. Restrict File Sharing
- 3.17.2.8. Restrict Printer Sharing
- 3.18. Proxy Server
- 3.19. SNMP Server
link | previous | next | up | toc | home
3.1. Obsolete Services
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 RHEL6
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.
link | previous | next | up | toc | home
3.1.1. Xinetd
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.
link | previous | next | up | toc | home
3.1.1.a. Disable xinetd Service
The xinetd
service can be disabled with the following command:
# chkconfig xinetd off
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.
Security identifiers
- CCE-4252-3
3.1.1.b. Uninstall xinetd Package
The xinetd
package can be uninstalled with the following command:
# yum erase xinetd
Removing the xinetd
package decreases the risk of the
xinetd service's accidental (or intentional) activation.
Security identifiers
- CCE-4164-0
3.1.2. Telnet
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.
link | previous | next | up | toc | home
3.1.2.a. Disable telnet Service
The telnet
service can be disabled with the following command:
# chkconfig telnet off
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.
Security identifiers
- CCE-3390-2
References
- 1436. URL: <http://iase.disa.mil/cci/index.html>.
- 196. URL: <http://iase.disa.mil/cci/index.html>.
- 197. URL: <http://iase.disa.mil/cci/index.html>.
3.1.2.b. Uninstall telnet-server Package
The telnet-server
package can be uninstalled with
the following command:
# yum erase telnet-server
Removing the telnet-server
package decreases the risk of the
telnet service's accidental (or intentional) activation.
Security identifiers
- CCE-4330-7
3.1.3. Rlogin, Rsh, and Rexec
The Berkeley r-commands are legacy services which allow cleartext remote access and have an insecure trust model.
link | previous | next | up | toc | home
3.1.3.a. Uninstall rsh-server Package
The rsh-server
package can be uninstalled with
the following command:
# yum erase rsh-server
The rsh-server
package provides several obsolete and insecure
network services. Removing it
decreases the risk of those services' accidental (or intentional)
activation.
Security identifiers
- CCE-4308-3
3.1.3.b. Disable rexec Service
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
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.
Security identifiers
- CCE-undefined
3.1.3.c. Disable rsh Service
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
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.
Security identifiers
- CCE-4141-8
References
- 1436. URL: <http://iase.disa.mil/cci/index.html>.
3.1.3.d. Disable rlogin Service
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
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.
Security identifiers
- CCE-3537-8
References
- 1436. URL: <http://iase.disa.mil/cci/index.html>.
3.1.3.e. Remove Rsh Trust Files
The files /etc/hosts.equiv
and ~/.rhosts
(in
each user's home directory) list remote hosts and users that are trusted by the
local system when using the rshd daemon.
To remove these files, run the following command to delete them from any
location:
# rm /etc/hosts.equiv
$ rm ~/.rhosts
Trust files are convenient, but when used in conjunction with the R-services, they can allow unauthenticated access to a system.
Security identifiers
- CCE-TODO
3.1.4. NIS
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.
link | previous | next | up | toc | home
3.1.4.a. Uninstall ypserv Package
The ypserv
package can be uninstalled with
the following command:
# yum erase ypserv
Removing the ypserv
package decreases the risk of the
accidental (or intentional) activation of NIS or NIS+ services.
Security identifiers
- CCE-4348-9
3.1.4.b. Disable ypbind Service
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
Disabling the ypbind
service ensures the system is not acting
as a client in a NIS or NIS+ domain.
Security identifiers
- CCE-3705-1
3.1.5. TFTP Server
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.
link | previous | next | up | toc | home
3.1.5.a. Disable tftp Service
The tftp
service should be disabled.
The tftp
service can be disabled with the following command:
# chkconfig tftp off
Disabling the tftp
service ensures the system is not acting
as a tftp server, which does not provide encryption or authentication.
Security identifiers
- CCE-4273-9
References
- 1436. URL: <http://iase.disa.mil/cci/index.html>.
3.1.5.b. Uninstall tftp-server Package
The tftp-server
package can be removed with the following command:
# yum erase tftp-server
Removing the tftp-server
package decreases the risk of the
accidental (or intentional) activation of tftp services.
Security identifiers
- CCE-3916-4
3.1.5.c. Ensure tftp Daemon Uses Secure Mode
If running the tftp
service is necessary, it should be configured
to change its root directory at startup. To do so, ensure that
/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
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.
Security identifiers
- CCE-TODO
3.2. Base Services
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.
link | previous | next | up | toc | home
3.2.a. Disable Automatic Bug Reporting Tool (abrtd)
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
Mishandling crash data could expose sensitive information about vulnerablities in software executing on the local machine, as well as sensitive information from within a process's address space or registers.
Security identifiers
- CCE-TODO
References
3.2.b. Disable Advanced Configuration and Power Interface (acpid)
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
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 may be prudent.
Security identifiers
- CCE-4298-6
References
3.2.c. Disable At Service (atd)
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
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.
Security identifiers
- CCE-TODO
References
3.2.d. Disable Certmonger Service (certmonger)
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
The services provided by certmonger may be essential for systems fulfilling some roles a PKI infrastructure, but its functionality is not necesssary for many other use cases.
Security identifiers
- CCE-TODO
References
3.2.e. Disable Control Group Config (cgconfig)
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
Unless control groups are used to manage system resources, running the cgconfig service is not necessary.
Security identifiers
- CCE-TODO
References
3.2.f. Disable Control Group Rules Engine (cgred)
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
Unless control groups are used to manage system resources, running the cgred service service is not necessary.
Security identifiers
- CCE-TODO
References
3.2.g. Disable CPU Speed (cpuspeed)
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
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.
Security identifiers
- CCE-4051-9
References
3.2.h. Disable Hardware Abstraction Layer Service (haldaemon)
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
The haldaemon provides essential functionality on systems that use removable media or devices, but can be disabled for systems that do not require these.
Security identifiers
- CCE-4364-6
References
3.2.i. Enable IRQ Balance (irqbalance)
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 irqbalance on
In an environment with multiple processors (now common), the irqbalance service provides potential speedups for handling interrupt requests.
Security identifiers
- CCE-4123-6
References
3.2.j. Disable KDump Kernel Crash Analyzer (kdump)
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
Unless the system is used for kernel development or testing, there is little need to run the kdump service.
Security identifiers
- CCE-3425-6
References
3.2.k. Disable Software RAID Monitor (mdmonitor)
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
If software RAID monitoring is not required (and it is uncommon), there is no need to run the service.
Security identifiers
- CCE-3854-7
References
3.2.l. Disable D-Bus IPC Service (messagebus)
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
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.
Security identifiers
- CCE-3822-4
References
3.2.m. Disable Network Console (netconsole)
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
The netconsole
service is not necessary unless there is a need to debug
kernel panics, which is not common.
Security identifiers
- CCE-TODO
References
3.2.n. Disable ntpdate Service (ntpdate)
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
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.
Security identifiers
- CCE-TODO
References
3.2.o. Disable Odd Job Daemon (oddjobd)
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
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.
Security identifiers
- CCE-TODO
References
- AC-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 382. URL: <http://iase.disa.mil/cci/index.html>.
3.2.p. Disable Portreserve (portreserve)
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
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.
Security identifiers
- CCE-TODO
References
3.2.q. Enable Process Accounting (psacct)
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 psacct on
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.
Security identifiers
- CCE-TODO
References
3.2.r. Disable Apache Qpid (qpidd)
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
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.
Security identifiers
- CCE-3854-7
References
3.2.s. Disable Quota Netlink (quota_nld)
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
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.
Security identifiers
- CCE-TODO
References
3.2.t. Disable Network Router Discovery Daemon (rdisc)
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
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.
Security identifiers
- CCE-TODO
References
- AC-4. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 382. URL: <http://iase.disa.mil/cci/index.html>.
3.2.u. Disable Red Hat Network Service (rhnsd)
The Red Hat Network service automatically queries Red Hat Network
servers to determine whether there are any actions that should be executed,
such as package updates. This only occurs if the system was registered to an
RHN server or satellite and managed as such.
The rhnsd
service can be disabled with the following command:
# chkconfig rhnsd off
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.
Security identifiers
- CCE-3416-5
References
3.2.v. Disable Red Hat Subscription Manager Daemon (rhsmcertd)
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
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.
Security identifiers
- CCE-TODO
References
3.2.w. Disable Cyrus SASL Authentication Daemon (saslauthd)
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
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.
Security identifiers
- CCE-TODO
References
3.2.x. Disable SMART Disk Monitoring Service (smartd)
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
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.
Security identifiers
- CCE-3455-3
References
3.2.y. Disable System Statistics Reset Service (sysstat)
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
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.
Security identifiers
- CCE-TODO
References
3.3. Cron and At Daemons
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.
link | previous | next | up | toc | home
3.3.a. Enable cron Service
The crond
service is used to execute commands at
preconfigured times. It is required by almost all systems to perform necessary
maintenance tasks, such as notifying root of system activity.
The crond
service can be enabled with the following command:
# chkconfig crond on
Due to its usage for maintenance and security-supporting tasks, enabling the cron daemon is essential.
Security identifiers
- CCE-4324-0
References
3.3.b. Disable anacron Service
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.
3.3.c. Disable atd Service
The at
service can be disabled with the following command:
# chkconfig at off
Many of the periodic or delayed execution features of the at daemon can be provided through the cron daemon instead.
Security identifiers
- CCE-14466-7
References
3.3.4. Restrict at and cron to Authorized Users if Necessary
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.deny
-
Edit
/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.deny
-
Edit
/etc/at.allow
, adding one line for each user allowed to use the at command to create at jobs.
3.4. SSH Server
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
.
References
- 1453. URL: <http://iase.disa.mil/cci/index.html>.
- 877. URL: <http://iase.disa.mil/cci/index.html>.
link | previous | next | up | toc | home
3.4.a. Disable SSH Server If Possible (Unusual)
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.
Security identifiers
- CCE-4268-9
3.4.b. Remove SSH Server iptables Firewall exception (Unusual)
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 RH-Firewall-1-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.
Security identifiers
- CCE-4295-2
3.4.3. Configure OpenSSH Server if Necessary
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.
References
- 68. URL: <http://iase.disa.mil/cci/index.html>.
- 197. URL: <http://iase.disa.mil/cci/index.html>.
- 888. URL: <http://iase.disa.mil/cci/index.html>.
- 1632. URL: <http://iase.disa.mil/cci/index.html>.
- 779. URL: <http://iase.disa.mil/cci/index.html>.
- 781. URL: <http://iase.disa.mil/cci/index.html>.
link | previous | next | up | toc | home
3.4.3.a. Allow Only SSH Protocol 2
Only SSH protocol version 2 connections should be
permitted. The default setting in
/etc/ssh/sshd_config
is correct, and can be
verified by ensuring that the following
line appears:
Protocol 2
SSH protocol version 1 suffers from design flaws that result in security vulnerabilities and should not be used.
Security identifiers
- CCE-4325-7
References
- 776. URL: <http://iase.disa.mil/cci/index.html>.
- 774. URL: <http://iase.disa.mil/cci/index.html>.
- 1135. URL: <http://iase.disa.mil/cci/index.html>.
3.4.3.b. Limit Users' SSH Access
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.
3.4.3.c. Set SSH Idle Timeout Interval
SSH allows administrators to set an idle timeout
interval.
After this interval has passed, the idle user will be
automatically logged out.
To set an idle timeout interval, edit the following line in /etc/ssh/sshd_config
as
follows:
ClientAliveInterval 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.
Causing idle users to be automatically logged out guards against compromises one system leading trivially to compromises on another.
Security identifiers
- CCE-3845-5
References
- 879. URL: <http://iase.disa.mil/cci/index.html>.
- 1133. URL: <http://iase.disa.mil/cci/index.html>.
3.4.3.d. Set SSH Client Alive Count
To ensure that the SSH idle timeout occurs precisely when the ClientAliveInterval
is set,
edit /etc/ssh/sshd_config
as
follows:
ClientAliveCountMax 0
This ensures that a user login will be terminated as soon as the ClientAliveInternal
is reached.
Security identifiers
- CCE-14061-6
3.4.3.e. Disable SSH Support for .rhosts Files
SSH can emulate the behavior of the obsolete rsh
command in allowing users to enable insecure access to their
accounts via .rhosts
files.
To ensure that this behavior is disabled, add or correct the
following line:
IgnoreRhosts yes
SSH trust relationships mean that a compromise on one host can allow an attacker to move trivially to other hosts.
Security identifiers
- CCE-4475-0
3.4.3.f. Disable Host-Based Authentication
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:
HostbasedAuthentication no
SSH trust relationships mean that a compromise on one host can allow an attacker to move trivially to other hosts.
Security identifiers
- CCE-4370-3
3.4.3.g. Disable SSH Root Login
The root user should never be allowed to login to a system directly over a network. To disable root login via SSH, add or correct the following line:
PermitRootLogin no
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.
Security identifiers
- CCE-4387-7
References
- 770. URL: <http://iase.disa.mil/cci/index.html>.
3.4.3.h. Disable SSH Access via Empty Passwords
To explicitly disallow remote login from accounts with empty passwords, add or correct the following line:
PermitEmptyPasswords no
Any accounts with empty passwords should be disabled immediately, and PAM configuration
should prevent users from being able to assign themselves empty passwords.
Configuring this setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere.
Security identifiers
- CCE-3660-8
3.4.3.i. Enable SSH Warning Banner
To enable the warning banner and ensure it is consistent
across the system, add or correct the following line in /etc/ssh/sshd_config
:
Banner /etc/issue
Another section contains information on how to create an
appropriate system-wide warning banner.
Although unlikely to dissuade a serious attacker, the warning message reinforces policy awareness during the logon process. Alternatively, systems whose ownership should not be obvious should ensure usage of a banner that does not provide easy attribution.
Security identifiers
- CCE-4431-3
3.4.3.j. Do Not Allow SSH Environment Options
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
SSH environment options potentially allow users to bypass access restriction in some configurations.
Security identifiers
- CCE-4422-2
3.4.3.k. Use Only Approved Ciphers
Limit the ciphers to those algorithms which are FIPS-approved.
Counter (CTR) mode is also preferred over cipher-block chaining (CBC) mode.
The following line in /etc/ssh/sshd_config
demonstrates use of FIPS-approved ciphers in CTR mode:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
The man page sshd_config(5)
contains a list of supported ciphers.
Note that older or less capable versions of SSH client or server software
may still be found on systems such as networking equipment, and these
may not support CTR mode. This may become an issue if, for example,
these systems need to retrieve files from your SSH server using SFTP.
TODO: Need to investigate current status of this. Earlier issues with
CBC were supposed to be fixed.
Approved algorithms should impart some level of confidence in their implementation. These are also required for compliance.
Security identifiers
- CCE-14491-5
References
- 803. URL: <http://iase.disa.mil/cci/index.html>.
- 1144. URL: <http://iase.disa.mil/cci/index.html>.
- 1145. URL: <http://iase.disa.mil/cci/index.html>.
- 1146. URL: <http://iase.disa.mil/cci/index.html>.
- 196. URL: <http://iase.disa.mil/cci/index.html>.
3.4.3.12. Strengthen Firewall Configuration if Possible
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 RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
and replace it with:
-A RH-Firewall-1-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.
3.5. X Window System
The X Window System implementation included with the system is called X.org.
link | previous | next | up | toc | home
3.5.1. Disable X Windows
Unless there is a mission-critical reason for the system to run a graphical user interface, ensure that 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.
link | previous | next | up | toc | home
3.5.1.a. Disable X Windows Startup By Setting Runlevel
Setting the system's runlevel to 3 will prevent automatic startup
of the X server. To do so, ensure that the following line in /etc/inittab
features a 3
as shown:
id:3:initdefault:
Security identifiers
- CCE-4462-8
3.5.1.b. Remove the X Windows Package Group
Removing all packages which constitute the X Window System ensures that users or malicious software cannot start X. To do so, run the following command:
# yum groupremove "X Window System"
Security identifiers
- CCE-4422-2
3.6. Avahi Server
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.
link | previous | next | up | toc | home
3.6.1. Disable Avahi Server if Possible
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.
link | previous | next | up | toc | home
3.6.1.a. Disable Avahi Server Software
The avahi-daemon
service can be disabled with the following command:
# chkconfig avahi-daemon off
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.
Security identifiers
- CCE-4365-3
References
3.6.2. Configure Avahi if Necessary
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.
link | previous | next | up | toc | home
3.6.2.a. Serve Avahi Only via Required Protocol
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
References
3.6.2.b. Check Avahi Responses' TTL Field
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
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.
References
3.6.2.c. Prevent Other Programs from Using Avahi's Port
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
This helps ensure that only Avahi is responsible for mDNS traffic coming from that port on the system.
References
3.6.2.d. Disable Avahi Publishing
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
This helps ensure that only Avahi is responsible for mDNS traffic coming from that port on the system.
References
3.6.2.5. Restrict Information Published by Avahi
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.
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.
References
3.7. Print Support
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.
link | previous | next | up | toc | home
3.7.a. Disable the CUPS Service
The cups
service can be disabled with the following command:
# chkconfig cups off
Turn off unneeded services to reduce attack surface.
Security identifiers
- CCE-3755-6
References
3.7.b. Disable Firewall Access to Printing Service
If the system does not need to act as a network print server, edit
the files /etc/sysconfig/iptables
and
/etc/sysconfig/ip6tables
(if IPv6 is in use). In each file, locate and
delete the lines:
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT
By default, inbound connections to the Internet Printing Protocol port are allowed. If the print server does not need to be accessed, either because the machine is not running the print service at all or because the machine is not providing a remote network printer to other machines, this exception should be removed from the firewall configuration.
Security identifiers
- CCE-3649-1
References
3.7.3. Configure the CUPS Service if Necessary
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.
link | previous | next | up | toc | home
3.7.3.a. Disable Printer Browsing Entirely if Possible
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
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.
Security identifiers
- CCE-4420-6
3.7.3.b. Disable Print Server Capabilities
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.
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.
Security identifiers
- CCE-4407-3
References
3.8. DHCP
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.
link | previous | next | up | toc | home
3.8.1. Disable DHCP Server
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.
link | previous | next | up | toc | home
3.8.1.a. Disable DHCP Service
The dhcpd
service should be disabled on
any system that does not need to act as a DHCP server.
The dhcpd
service can be disabled with the following command:
# chkconfig dhcpd off
Unmanaged or unintentionally activate DHCP servers may provide faulty information to clients, interfering with the operation of a legitimate site DHCP server if there is one.
Security identifiers
- CCE-4336-4
References
3.8.1.b. Uninstall DHCP Server Package
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
Removing the DHCP server ensures that it cannot be easily or accidentally reactivated and disrupt network operation.
Security identifiers
- CCE-4464-4
References
3.8.2. Disable DHCP Server
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.
link | previous | next | up | toc | home
3.8.2.a. Do Not Use Dynamic DNS
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).
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.
Security identifiers
- CCE-4257-2
3.8.2.b. Deny Decline Messages
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;
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.
Security identifiers
- CCE-4403-2
3.8.2.c. Deny BOOTP Queries
Unless your network needs to support older BOOTP clients, disable support for the bootp protocol by adding or correcting the global option:
deny bootp;
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.
Security identifiers
- CCE-4345-5
3.8.2.d. Configure Logging
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
Security identifiers
- CCE-3733-3
3.8.2.5. Minimize Served Information
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.
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.
3.8.3. Disable DHCP Client
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.
link | previous | next | up | toc | home
3.8.3.a. Disable DHCP Client
For each interface IFACE on the system (e.g. eth0), edit
/etc/sysconfig/network-scripts/ifcfg-IFACE
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
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.
Security identifiers
- CCE-4191-3
References
3.8.4. Configure DHCP Client if Necessary
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.
link | previous | next | up | toc | home
3.8.4.1. Minimize the DHCP-Configured Options
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).
3.9. Network Time Protocol
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.
link | previous | next | up | toc | home
3.9.a. Enable the NTP Daemon
The ntpd
service can be enabled with the following command:
# chkconfig ntpd on
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.
Security identifiers
- CCE-4376-0
References
- 160. URL: <http://iase.disa.mil/cci/index.html>.
3.9.b. Specify a Remote NTP Server
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.
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.
Security identifiers
- CCE-4385-1
References
- 160. URL: <http://iase.disa.mil/cci/index.html>.
3.9.c. Specify Additional Remote NTP Servers
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
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.
3.10. Mail Server Software
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 clients programs to retrieve email
from a central server that support 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.
link | previous | next | up | toc | home
3.10.a. Enable Postfix (postfix)
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 postfix on
Local mail delivery is essential to some system maintenance and notification tasks.
Security identifiers
- CCE-14068-1
References
3.10.2. Configure SMTP For Mail Clients
This section discusses settings for Postfix in a submission-only e-mail configuration.
link | previous | next | up | toc | home
3.10.2.a. Disable Postfix Network Listening
Edit the file /etc/postfix/main.cf
to ensure that only the following
inet_interfaces
line appears:
inet_interfaces = localhost
This ensures that 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.
Security identifiers
- CCE-15018-5
References
3.10.3. Configure Operating System to Protect Mail Server
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.
link | previous | next | up | toc | home
3.10.3.a. Configure iptables to Allow Access to the Mail Server
Edit /etc/sysconfig/iptables
. Add the following line, ensuring that it appears before the final LOG and
DROP lines for the RH-Firewall-1-INPUT chain:
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 25 -j ACCEPT
The default Iptables configuration does not allow inbound access to the SMTP service. This modification allows that access, while keeping other ports on the server in their default protected state.
References
3.10.3.b. Verify System Logging and Log Permissions for Mail
Edit the file /etc/rsyslog.conf
. Add or correct the following line if necessary (this is the default):
mail.* -/var/log/maillog
Run the following commands to ensure correct permissions on the mail log:
# chown root:root /var/log/maillog
# chmod 600 /var/log/maillog
Ensure log will be rotated as appropriate by adding or correcting the following line if needed into the list on the first line of /etc/logrotate.d/syslog
(this is the default):
/var/log/maillog
References
3.10.3.3. Use Separate Hosts for External and Internal Mail if Possible
The mail server is a frequent target of network attack from the outside. However, since all site users receive mail, the mail server must be open to some connection from each inside users. It is strongly recommended that these functions be separated, by having an externally visible mail server which processes all incoming and outgoing mail, then forwards internal mail to a separate machine from which users can access it.
References
3.10.3.4. Protect the MTA Host from User Access
The mail server contains privileged data belonging to all users and performs a vital network function. Preventing users from logging into this server is a precaution against privilege escalation or denial of service attacks which might compromise the mail service. Take steps to ensure that only system administrators are allowed shell access to the MTA host.
References
3.10.3.5. Restrict Remote Access to the Mail Spool
The mail server contains privileged data belonging to all users and performs a vital network function. Preventing users from logging into this server is a precaution against privilege escalation or denial of service attacks which might compromise the mail service. Take steps to ensure that only system administrators are allowed shell access to the MTA host.
References
- AC-2. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-4. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-2. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
3.10.3.6. Configure SSL Certificates for Use with SMTP AUTH
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.
link | previous | next | up | toc | home
3.10.3.6.a. Install the SSL Certificate
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
References
3.10.3.6.2. Create an SSL Certificate
Change into the CA certificate directory:
# cd /etc/pki/tls/certs
Generate a key pair for the mail server:
# openssl genrsa -out mailserverkey.pem 2048
Next, generate a certificate signing request (CSR) for the CA to sign, making sure to supply your mail
server’s fully qualified domain name as the Common Name:
# openssl req -new -key mailserverkey.pem -out mailserver.csr
Next, the mail server CSR must be signed to create the mail server certificate. You can either send the CSR
to an established CA or sign it with your CA.
To sign mailserver.csr using your CA:
# openssl ca -in mailserver.csr -out mailservercert.pem
Note: This step must be performed on your CA system, not on the MTA host itself. If you will have a commercial CA sign certificates, then this step should be performed on a separate, physically secure system devoted to that purpose.
This step creates a private key, mailserverkey.pem
, and a public certificate, mailservercert.pem
.
The mail server will use these to prove its identity by demonstrating that it has a certificate which has been signed by a
CA. Mail clients at your site should be willing to send their mail only to a server they can authenticate.
References
3.10.4. Configure Postfix if Necessary
Postfix stores its configuration files in the directory /etc/postfix by default. The primary configuration file is /etc/postfix/main.cf. Other files will be introduced as needed.
link | previous | next | up | toc | home
3.10.4.a. Limit Denial of Service Attacks
Edit /etc/postfix/main.cf
. Add or correct the following lines:
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
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.
References
3.10.4.b. Configure SMTP Greeting Banner
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
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.
3.10.4.3. Control Mail Relaying
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.
link | previous | next | up | toc | home
3.10.4.3.a. Configure Trusted Networks and Hosts
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 line:
mynetworks_style = subnet
-
If only the MTA host itself is trusted to relay messages, add or correct:
mynetworks_style = host
-
If 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.
References
3.10.4.3.b. Allow Unlimited Relaying for Trusted Networks Only
Edit /etc/postfix/main.cf
, and add or correct the smtpd_recipient_restrictions
definition so that it
contains at least:
smtpd_recipient_restrictions =
...
permit_mynetworks,
reject_unauth_destination,
...
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.
References
3.10.4.3.c. Require SMTP AUTH Before Relaying from Untrusted Clients
SMTP authentication allows remote clients to relay mail safely by requiring them to authenticate before submit-
ting mail. Postfix’s SMTP AUTH uses an authentication library called SASL, which is not part of Postfix itself.
This section describes how to configure authentication using the Cyrus-SASL implementation. See below for a
discussion of other options.
To enable the use of SASL authentication, edit /etc/postfix/main.cf
and add or correct the following
settings:
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions =
...
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
...
Then edit /usr/lib/sasl2/smtpd.conf
and add or correct the following line with the correct authentication
mechanism for SASL to use:
pwcheck_method: saslauthd
The saslauthd
service can be enabled with the following command:
# chkconfig saslauthd on
Postfix can use either the Cyrus library or Dovecot as a source for SASL authentication. If this host is running
Dovecot for some other reason, it is recommended that Dovecot’s SASL support be used instead of running the
Cyrus code as well. See http://www.postfix.org/SASL_README.html for instructions on implementing that
configuration, which is not described in this guide.
In Postfix’s configuration, the directive smtpd_sasl_auth_enable
tells smtpd
to allow the use of the SMTP AUTH
command during the SMTP dialogue, and to support that command by getting authentication information from
SASL. The smtpd_recipient_restrictions
directive is changed so that, if the client is not connecting from a
trusted address, it is allowed to attempt authentication (permit_sasl_authenticated
) in order to relay mail.
The file /usr/lib/sasl2/smtpd.conf
is the Cyrus-SASL configuration file. The pwcheck_method
directive tells
SASL how to find passwords. The simplest method, described above, is to run a separate authentication daemon,
saslauthd
, which is able to communicate with the system authentication system. On RHEL6, saslauthd
uses
PAM by default, which should work in most cases. If you have a centralized authentication system which does not
work via PAM, look at the saslauthd(8)
manpage to find out how to configure saslauthd
for your environment.
References
3.10.4.3.d. Require TLS for SMTP AUTH
Edit /etc/postfix/main.cf
, and add or correct the following lines:
smtpd_tls_CApath = /etc/pki/tls/CA
smtpd_tls_CAfile = /etc/pki/tls/CA/cacert.pem
smtpd_tls_cert_file = /etc/pki/tls/mail/servercert.pem
smtpd_tls_key_file = /etc/pki/tls/mail/serverkey.pem
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
These options tell Postfix to protect all SMTP AUTH transactions using TLS. The first four options describe
the locations of the necessary TLS key files.
The smtpd_tls_security_level
directive tells smtpd
to allow the STARTTLS command during the SMTP protocol
exchange, but not to require it for mail senders. (Unless your site receives mail only from other trusted sites
whose sysadmins can be asked to maintain a copy of your site certificate, you do not want to require TLS for all
SMTP exchanges.)
The smtpd_tls_auth_only
directive tells smtpd
to require the STARTTLS command before allowing the client to
attempt to authenticate for relaying using SMTP AUTH. It may not be possible to use this directive if you must
allow relaying from non-TLS-capable client software. If this is the case, simply omit that line.
References
3.11. LDAP
LDAP is a popular directory service, that is, a standardized way of looking up information from a central database. It is relatively simple to configure a RHEL6 machine to obtain authentication information from an LDAP server. If your network uses LDAP for authentication, be sure to configure both clients and servers securely.
link | previous | next | up | toc | home
3.11.1. Configure OpenLDAP Clients
This guide recommends configuring OpenLDAP clients by
manually editing the appropriate configuration files. RHEL6
provides an automated configuration tool called authconfig and a
graphical wrapper for authconfig called
system-config-authentication
. However, these tools do not give
sufficient flexibility over configuration. 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.
They are also overly aggressive in placing services such as
netgroups and automounter maps under LDAP control, where it is
safer to use LDAP only for services to which it is relevant in your
environment.
Before configuring any machine to be an LDAP client, ensure that a working LDAP server is present on the network.
link | previous | next | up | toc | home
3.11.1.a. Configure LDAP to Use TLS For All Transactions
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.
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.
Security identifiers
- CCE-14894-0
References
- 776. URL: <http://iase.disa.mil/cci/index.html>.
- 778. URL: <http://iase.disa.mil/cci/index.html>.
- 1453. URL: <http://iase.disa.mil/cci/index.html>.
3.11.1.b. Configure Certificate Directives for LDAP Use of TLS
Ensure a copy of the site's 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 the site's 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.
The tls_cacertdir or tls_cacertfile directives are required when tls_cheekpeer 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.
Security identifiers
- CCE-14894-0
References
- 776. URL: <http://iase.disa.mil/cci/index.html>.
- 778. URL: <http://iase.disa.mil/cci/index.html>.
- 1453. URL: <http://iase.disa.mil/cci/index.html>.
3.11.2. Configure OpenLDAP Server
This section contains guidance on how to configure an OpenLDAP server to securely provide information for use in a centralized authentication service. This is not a comprehensive guide to maintaining an OpenLDAP server, but may be helpful in securing an OpenLDAP infrastructure nonetheless.
link | previous | next | up | toc | home
3.11.2.a. Uninstall openldap-servers Package
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 RHEL6
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.
Security identifiers
- CCE-3501-4
References
3.11.2.b. Configure Domain-Specific Parameters
The ldap
server should be configured to use a domain specific suffix.
Is this system an OpenLDAP server? If so,
edit the ldap configuration file at
/etc/openldap/slapd.d/cn=config/olcDatabase={*}bdb.ldif
to include suffix information relevant to your domain.
olcSuffix: "dc=example,dc=com "
olcRootDN: "cn=Manager,dc=example,dc=com "
where dc=example,dc=com is the same root you will use on the LDAP clients.
These are basic LDAP configuration directives. The suffix parameter gives the root name of all information served by this LDAP server, and should be some name related to your domain. The rootdn parameter names LDAP’s privileged user, who is allowed to read or write all data managed by this LDAP server.
Security identifiers
- CCE-3501-4
References
3.11.2.c. LDAP Configuration File Security
Is this system an OpenLDAP server? If so,
ensure that the configuration files are protected from unauthorized
access or modification.
Edit the ldap configuration file at /etc/openldap/slapd.d/cn=config/olcDatabase={*}bdb.ldif
.
Ensure that the configuration file has reasonable permissions:
# chown root:ldap /etc/openldap/slapd.d/cn=config/olcDatabase={*}bdb.ldif
# chmod 640 /etc/openldap/slapd.d/cn=config/olcDatabase={*}bdb.ldif
Protect configuration files containing the hashed password the same way you would protect other files, such as
/etc/shadow
, which contain hashed authentication data.
References
3.11.2.d. Configure LDAP Root Password
Is this system an OpenLDAP server? If so,
ensure that the RootDN uses a secure password.
Generate a hashed password using the slappasswd utility:
# slappasswd
New password:
Re-enter new password:
This will output a hashed password string.
Edit the file
/etc/openldap/slapd.d/cn=config/olcDatabase={*}bdb.ldif
, and add or correct
the line:
olcRootPW: {SSHA}hashed-password-string
Be sure to select a secure password for the LDAP root user, since this user has permission to read and write all
LDAP data, so a compromise of the LDAP root password will probably enable a full compromise of your site.
In addition, be sure to use a reasonably strong hash function. The default hash function should be used. The default hash function is a salted SHA-1 algorith which is FIPS 160-1 compliant. Insecure schemes such as crypt should not be used.
References
3.11.2.e. Protect LDAP Certificate Files
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 files generated in the previous
step onto the LDAP server:
-
/etc/pki/tls/ldap/serverkey.pem
: the private keyldapserverkey.pem
-
/etc/pki/tls/ldap/servercert.pem
: the certificate fileldapservercert.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.
Security identifiers
- CCE-4360-4
- CCE-4378-6
- CCE-4492-5
- CCE-4263-0
- CCE-3502-2
- CCE-4449-5
- CCE-4361-2
- CCE-4427-1
- CCE-4321-6
- CCE-4339-8
- CCE-4105-3
- CCE-3718-4
References
- AC-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-11. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-12. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-13. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-17. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
3.11.2.f. Configure slapd to Protect Authentication Information
Use ldapmodify to add these entries to the database. Add or correct the following access specifications: 1. Protect the user’s password by allowing the user himself or the LDAP administrators to change it, allowing the anonymous user to authenticate against it, and allowing no other access:
olcAccess: to attrs=userPassword
by self write
by group/groupOfUniqueNames/uniqueMember="cn=admins ,ou=groups,dc=example,dc=com " write
by anonymous auth
by * none
olcAccess: to attrs=shadowLastChange
by self write
by group/groupOfUniqueNames/uniqueMember="cn=admins ,ou=groups,dc=example,dc=com " write
by * read
2. Allow anyone to read other information, and allow the administrators to change it:
olcAccess: to *
by group/groupOfUniqueNames/uniqueMember="cn=admins ,ou=groups,dc=example,dc=com " write
by * read
Access rules are applied in the order encountered, so more specific rules should appear first. In particular,
the rule restricting access to userPassword must appear before the rule allowing access to all data. The
shadowLastChange attribute is a timestamp, and is only critical if your site implements password expiration. If
your site does not have an LDAP administrators group, the LDAP root user (called Manager in this guide) will
be able to change data without an explicit access statement.
References
- AC-2. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-4. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-2. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
3.11.2.g. Correct Permissions on LDAP Server Files
Correct the permissions on the ldap server’s files:
# chown ldap:root /var/lib/ldap/*
Some manual methods of inserting information into the LDAP database may leave these files with incorrect
permissions. This will prevent slapd from starting correctly.
Security identifiers
- CCE-4484-2
- CCE-4502-1
References
3.11.2.h. Configure iptables to Allow Access to the LDAP Server
Determine an appropriate network block, netwk , and network mask, mask , representing the machines on your network which will synchronize to this server. Edit /etc/sysconfig/iptables. Add the following lines, ensuring that they appear before the final LOG and DROP lines for the RH-Firewall-1-INPUT chain:
-A RH-Firewall-1-INPUT -s netwk /mask -m state --state NEW -p tcp --dport 389 -j ACCEPT
-A RH-Firewall-1-INPUT -s netwk /mask -m state --state NEW -p tcp --dport 636 -j ACCEPT
The default Iptables configuration does not allow inbound access to any services. These modifications allow
access to the LDAP primary (389) and encrypted-only (636) ports, while keeping all other ports on the server
in their default protected state.
Note: Even if the LDAP server restricts connections so that only encrypted queries are allowed, it will probably
be necessary to allow traffic to the default port 389. This is true because many LDAP clients implement
encryption by connecting to the primary port and issuing the STARTTLS command.
References
- AC-4. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-2. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SC-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
3.11.2.i. Configure Logging for LDAP
-
Edit the file
/etc/rsyslog.conf
. Add or correct the following line:local4.*
-
Create the log file with safe permissions:
# touch /var/log/ldap.log # chown root:root /var/log/ldap.log # chmod 0600 /var/log/ldap.log
-
Edit the file /etc/logrotate.d/syslog and add the pathname
to the space-separated list in the first line./var/log/ldap.log
-
Edit the LDAP configuration file /etc/openldap/slapd.conf and set a reasonable set of default log parameters, such as:
loglevel stats2
OpenLDAP sends its log data to the syslog facility local4 at priority debug. By default, RHEL5 does not store
this facility at all. The syslog configuration suggested here will store any output logged by slapd in the file
/var/log/ldap.log
, and will include that file in the standard log rotation for syslog files.
By default, LDAP’s logging is quite verbose. The loglevel parameter is a space-separated list of items to be
logged. Specifying stats2
will reduce the log output somewhat, but this level will still produce some logging
every time an LDAP query is made. (This may be appropriate, depending on your site’s auditing requirements.)
In order to capture only slapd
startup messages, specify loglevel none
.
See slapd.conf(5)
for detailed information about the loglevel parameter.
References
- AC-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-9. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
3.11.2.10. Create Top-level LDAP Structure for Domain
Create a structure for the domain itself with at least the following attributes:
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
dc: example
o: Organization Description
This is a placeholder for the root of the domain’s LDAP tree. Without this entry, LDAP will not be able to find
any other entries for the domain.
References
3.11.2.11. Create LDAP Structures for Users and Groups
Create LDAP structures for people (users) and for groups with at least the following attributes:
dn: ou=people,dc=example,dc=com
ou: people
structuralObjectClass: organizationalUnit
objectClass: organizationalUnit
dn: ou=groups,dc=example,dc=com
ou: groups
structuralObjectClass: organizationalUnit
objectClass: organizationalUnit
Posix users and groups are the two top-level items which will be needed in order to use LDAP for authentication.
These organizational units are used to identify the two categories within LDAP.
References
3.11.2.12. Create Unix Accounts
For each Unix user, create an LDAP entry with at least the following attributes (others may be appropriate for your site as well), using variable values appropriate to that user.
dn: uid=username ,ou=people,dc=example,dc=com
structuralObjectClass: inetOrgPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: fullname
sn: surname
gecos: fullname
gidNumber: primary-group-id
homeDirectory: /home/username
loginShell: /path/to/shell
uid: username
uidNumber: uid
userPassword: {MD5}md5-hashed-password
shadowMax: N
In general, the LDAP schemas for users use uid to refer to the text username, and uidNumber for the numeric
UID. This usage may be slightly confusing when compared to the standard Unix usage.
You should not create entries for the root account or for system accounts which are unique to individual systems,
but only for user accounts which are to be shared across machines, and which have authentication information
(such as a password) associated with them.
References
3.11.2.13. Create Unix Groups
For each Unix group, create an LDAP entry with at least the following attributes:
dn: cn=groupname ,ou=groups,dc=example,dc=com
cn: groupname
structuralObjectClass: posixGroup
objectClass: posixGroup
gidNumber: gid
memberUid: username1
memberUid: username2
...
memberUid: usernameN
Note that each user has a primary group, identified by the gidNumber field in the user’s account entry. That
group must be created, but it is not necessary to list the user as a memberUid of the group. This behavior should
be familiar to administrators, since it is identical to the handling of the /etc/passwd and /etc/group files.
Do not create entries for the root group or for system groups, but only for groups which contain human users
or which are shared across systems.
References
3.11.2.14. Create Groups to Administer LDAP
If a group of LDAP administrators is desired, that group must be created somewhat differently. The specification should have these attributes:
dn: cn=admins ,ou=groups,dc=example,dc=com
cn: admins
structuralObjectClass: groupOfUniqueNames
objectClass: groupOfUniqueNames
uniqueMember: cn=Manager,dc=example,dc=com
uniqueMember: uid=admin1-username ,ou=people,dc=example,dc=com
uniqueMember: uid=admin2-username ,ou=people,dc=example,dc=com
...
uniqueMember: uid=adminN-username ,ou=people,dc=example,dc=com
LDAP cannot use Posix groups for its own internal authentication — it needs to compare the username specified
in an authenticated bind to some internal groupOfUniqueNames. If you do not specify an LDAP administrators’
group, then all LDAP management will need to be done using the LDAP root user (Manager). For reasons of
auditing and error detection, it is recommended that LDAP administrators have unique identities.
References
3.12. NFS and RPC
The Network File System is the most popular distributed filesystem for the Unix environment, and is very widely deployed. Unfortunately, NFS was not designed with security in mind, and has a number of weaknesses, both in terms of the protocol itself and because any NFS installation must expose several daemons, running on both servers and clients, to network attack.
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, as much as possible, NFS's configuration. This section is relevant to machines operating as NFS clients, as well as to those operating as NFS
servers.
link | previous | next | up | toc | home
3.12.1. Disable All NFS Services if Possible
Is there a mission-critical reason for this machine to operate as either an NFS client or an NFS server?
If not, follow all instructions in the remainder of this section to disable subsystems required by NFS.
NFS is a commonly used mechanism for sharing data between machines in an organization. However, its use opens many potential security holes. If NFS is not universally needed in your organization, improve the security posture of any machine which does not require NFS by disabling it entirely.
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.
link | previous | next | up | toc | home
3.12.1.1. Disable Services Used Only by NFS
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.
link | previous | next | up | toc | home
3.12.1.1.a. Disable Network File System Lock Service (nfslock)
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
Security identifiers
- CCE-4396-8
3.12.1.1.b. Disable Secure RPC Client Service (rpcgssd)
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
Security identifiers
- CCE-3535-2
3.12.1.1.c. Disable RPC ID Mapping Service (rpcidmapd)
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
Security identifiers
- CCE-3568-3
3.12.1.2. Disable netfs if Possible
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.
link | previous | next | up | toc | home
3.12.1.2.a. Disable Network File Systems (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
Security identifiers
- CCE-4533-6
3.12.1.3. Disable RPC Bind Service if Possible
If:
-
NFSv3 or NFSv2 is not needed (NFSv4 implementations do not require the use of the RPC Bind Service)
-
The site does not rely on NIS for authentication information, and
-
The machine does not run any other RPC-based service
then disable the RPC bind service.
By design, the RPC model does not require particular services to listen on fixed ports, but instead uses a daemon, rpcbind, to tell prospective clients which ports to use to contact the services they are trying to reach. This model weakens system security by introducing another privileged daemon which may be directly attacked, and is unnecessary because RPC was never adopted by enough services to risk using up all the ports on a system.
Unfortunately, rpcbind is central to RPC design, so it cannot be disabled if your site is using NFSv3 or NFSv2, NIS (see Section 3.2.4 for information about NIS, which is not recommended), or any third-party or custom RPC-based program. If none of these programs are in use, however, rpcbind should be disabled to improve system security.
In order to get more information about whether rpcbind may be disabled on a given host, query rpcbind using the command:
# rpcinfo -p
If the only services listed are portmapper and status, it is safe to disable rpcbind. If other services are listed and your site is not running NFS or NIS, investigate these services and disable them if possible.
link | previous | next | up | toc | home
3.12.1.3.a. Disable RPC Bind Service (rpcbind)
The rpcbind service is responsible for mapping RPC services to the TCP ports that they listen on. The rpcbind service also directs RPC clients to the proper port number that corresponds to the service the clients wants to communicate with. Unless RPC services are needed on the local system it is recommended to disable this service.
The rpcbind
service can be disabled with the following command:
# chkconfig rpcbind off
Security identifiers
- CCE-TODO
3.12.2. Configure All Machines which Use NFS
The steps in this section are appropriate for all machines which run NFS, whether they operate as clients or as servers.
link | previous | next | up | toc | home
3.12.2.1. Make Each Machine a Client or a Server, not Both
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.
3.12.2.2. Restrict Access to rpcbind
When using NFSv2 or NFSv3 which require rpcbind
, access to the rpcbind
service should be restricted by using TCP Wrappers. The /etc/hosts.allow
and /etc/hosts.deny
files are used by TCP Wrappers to determine whether specified remote hosts are allowed to access certain services. The default RPC Bind service shipped with RHEL6 has TCP Wrappers support built in, so this specification can be used to provide some protection against network attacks on rpcbind
.
Note: This step protects only the RPC Bind service itself. It is still possible for attackers to guess the port numbers of NFS services and attack those services directly, even if they are denied access to rpcbind
.
Edit the file /etc/hosts.deny
. Add or correct the line:
rpcbind: ALL
Edit the file /etc/hosts.allow
. Add or correct the line:
rpcbind: IPADDR1 , IPADDR2 , ...
where each IPADDR
is the IP address of a server or client with which this machine shares NFS filesystems. If the machine is an NFS server, it may be simpler to use an IP netblock specification, such as 10.3.2. (this is the TCP Wrappers syntax representing the netblock 10.3.2.0/24), or a hostname specification, such as
.subdomain.example.com. The use of hostnames is not recommended.
3.12.2.3. Configure NFS Services to Use Fixed Ports (NFSv3 and NFSv2)
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.
link | previous | next | up | toc | home
3.12.2.3.a. Configure lockd to use static TCP port
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.
Security identifiers
- CCE-4559-1
3.12.2.3.b. Configure lockd to use static UDP port
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.
Restrict service to always use a given port, so that firewalling can be done effectively.
Security identifiers
- CCE-4310-9
3.12.2.3.c. Configure statd to use static port
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.
Restrict service to always use a given port, so that firewalling can be done effectively.
Security identifiers
- CCE-3667-3
3.12.2.3.d. Configure mountd to use static port
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.
Restrict service to always use a given port, so that firewalling can be done effectively.
Security identifiers
- CCE-4438-8
3.12.3. Configure NFS Clients
The steps in this section are appropriate for machines which operate as NFS clients.
link | previous | next | up | toc | home
3.12.3.1. Disable NFS Server Daemons
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.
link | previous | next | up | toc | home
3.12.3.1.a. Disable Network File System (nfs)
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
Security identifiers
- CCE-4473-5
3.12.3.1.b. Disable Secure RPC Server Service (rpcsvcgssd)
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
Security identifiers
- CCE-4491-7
3.12.3.2. Mount Remote Filesystems with Restrictive Options
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.
link | previous | next | up | toc | home
3.12.3.2.a. Mount Remote Filesystems with nodev
The nodev
option should be enabled for all NFS mounts
Legitimate device files should only exist in the /dev directory. NFS mounts should not present device files to users.
Security identifiers
- CCE-4368-7
3.12.3.2.b. Mount Remote Filesystems with nosuid
The nosuid
option should be enabled for all NFS mounts
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.
Security identifiers
- CCE-4024-6
3.12.4. Configure NFS Servers
The steps in this section are appropriate for machines which operate as NFS servers.
link | previous | next | up | toc | home
3.12.4.a. Use Root-Squashing on All Exports
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.
Security identifiers
- CCE-4544-3
3.12.4.b. Restrict NFS Clients to Privileged Ports
By default, Linux’s 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.
Ensure that 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.
Security identifiers
- CCE-4465-1
3.12.4.c. Ensure Insecure File Locking is Not Allowed
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
.
Allowing insecure file locking could allow for sensitive data to be viewed or edited by an unauthorized user.
Security identifiers
- CCE-TO:DO
References
- 764. URL: <http://iase.disa.mil/cci/index.html>.
3.12.4.4. Configure the Exports File Restrictively
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.
3.12.4.5. Use Access Lists to Enforce Authorization Restrictions
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 resolver
-
Fully qualified domain name
-
IP address
-
IP subnets in the format
address/netmask
3.12.4.6. Export Filesystems Read-Only if Possible
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.
3.12.4.7. Specify UID and GID for Anonymous Connections
When an NFS server is configured to deny remote root
access, a selected UID and GID
are used to handle requests from the remote root
user. The UID and GID should be chosen from the
system to provide the appropriate level of non-privileged access. By default, the NFS server will
map remote root
users to the nobody
local account. Specifying the anonymous UID and GID
as -1 ensures that the remote root
user is mapped to a local account which has no permissions on the
system.
To specify the UID and GID for remote root
users, edit the /etc/exports
file and add
anonuid=-1
and anongid=-1
to the options list for each export.
3.13. DNS Server
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.
link | previous | next | up | toc | home
3.13.1. Disable DNS Server
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 RHEL6 by default. The remainder of this section discusses secure configuration of machines which must be nameservers.
link | previous | next | up | toc | home
3.13.1.a. Disable DNS Server
The named
service can be disabled with the following command:
# chkconfig named off
All network services involve some risk of compromise due to implementation flaws and should be disabled if possible.
Security identifiers
- CCE-3578-2
References
3.13.1.b. Uninstall bind Package
To remove the bind
package, which contains the
named
service, run the following command:
# yum erase bind
If there is no need to make DNS server software available, removing it provides a safeguard against its activation.
Security identifiers
- CCE-4219-2
References
3.13.2. Isolate DNS from Other Services
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.
link | previous | next | up | toc | home
3.13.2.a. Run DNS Software in a chroot Jail
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
Edit the file /etc/sysconfig/named
. Add or correct the line:
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.
Security identifiers
- CCE-3985-9
- CCE-4487-5
- CCE-4258-0
3.13.2.2. Run DNS Software on Dedicated Servers
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.
3.13.2.3. Configure Firewalls to Protect the DNS Server
Edit the file /etc/sysconfig/iptables
. Add the following
lines, ensuring that they appear before the final LOG and DROP lines for the
RH-Firewall-1-INPUT chain:
-A RH-Firewall-1-INPUT -m state --state NEW -p udp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 53 -j ACCEPT
These lines are necessary in order to allow remote machines to contact the DNS server. If this server is only available to the local network, it may be appropriate to insert a -s flag into this rule to allow traffic only from packets on the local network.
3.13.3. Protect DNS Data from Tampering or Attack
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.
link | previous | next | up | toc | home
3.13.3.a. Disable Dynamic Updates
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.
Security identifiers
- CCE-4399-2
3.13.3.2. Run Separate DNS Servers for External and Internal Queries
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
. 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.
3.13.3.3. Use Views to Partition External and Internal Information
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.
3.13.3.4. Disable Zone Transfers from the Nameserver
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.
Edit /etc/named.conf
. Add or correct the following directive:
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.
3.13.3.5. Authenticate Zone Transfers
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
Edit /etc/named.conf
on the primary nameserver. Add the directives:
key zone-transfer-key {
algorithm hmac-md5;
secret "base64-key-string ";
};
zone "example.com " IN {
type master;
allow-transfer { key zone-transfer-key; };
...
};
Edit /etc/named.conf
on the secondary nameserver. Add the directives:
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.
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.
3.14. FTP Server
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.
link | previous | next | up | toc | home
3.14.1. Disable vsftpd if Possible
link | previous | next | up | toc | home
3.14.1.a. Disable vsftpd Service
The vsftpd
service can be disabled with the following command:
# chkconfig vsftpd off
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.
Security identifiers
- CCE-3919-8
References
3.14.1.b. Uninstall vsftpd Package
The vsftpd
package can be removed with the following command:
# yum erase vsftpd
Removing the vsftpd package decreases the risk of its accidental activation.
Security identifiers
- CCE-14881-7
References
3.14.2. Use vsftpd to Provide FTP Service if Necessary
link | previous | next | up | toc | home
3.14.2.a. Install vsftpd Package
If this machine must operate as an FTP server, install the vsftpd
package via the standard channels:
# yum install vsftpd
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.
Security identifiers
- CCE-14881-7
References
3.14.3. Use vsftpd to Provide FTP Service if Necessary
The primary vsftpd configuration file is /etc/vsftpd.conf
, if that file exists, or /etc/vsftpd/vsftpd.conf
if it does not. For the remainder of this section, the phrase “the configuration file” will refer to whichever of those files is appropriate for your environment.
link | previous | next | up | toc | home
3.14.3.a. Enable Logging of All FTP Transactions
Edit the vsftpd configuration file. Add or correct the following configuration options:
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
The modifications above 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.
Security identifiers
- CCE-4549-2
3.14.3.b. Create Warning Banners for All FTP Users
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
This setting will cause the system greeting banner to be used for FTP connections as well.
Security identifiers
- CCE-4554-2
3.14.3.c. Disable FTP Uploads if Possible
Is there a mission-critical reason for users to upload files via FTP? If not: Edit the vsftpd configuration file. 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.
Security identifiers
- CCE-4461-0
3.14.3.d. Place the FTP Home Directory on its Own Partition
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.
3.14.3.5. Restrict the Set of Users Allowed to Access FTP
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.
link | previous | next | up | toc | home
3.14.3.5.a. Restrict Access to Anonymous Users if Possible
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.
Security identifiers
- CCE-4443-8
3.14.3.5.2. Limit Users Allowed FTP Access if Necessary
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.
3.14.3.6. Configure Firewalls to Protect the FTP Server
Edit the file /etc/sysconfig/iptables
. Add the following lines, ensuring that they appear before the final
LOG and DROP lines for the RH-Firewall-1-INPUT chain:
-A RH-Firewall-1-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.
3.15. Web Server
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 sources
-
Web server software is very complex, and includes a long history of vulnerabilities
-
The 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
.
link | previous | next | up | toc | home
3.15.1. Disable Apache if Possible
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.
link | previous | next | up | toc | home
3.15.1.a. Disable httpd Service
The httpd
service can be disabled with the following command:
# chkconfig httpd off
Running web server software provides a network-based avenue of attack, and should be disabled if not needed.
Security identifiers
- CCE-4338-0
References
3.15.1.b. Uninstall httpd Package
The httpd
package can be removed with the following command:
# yum erase httpd
If there is no need to make the web server software available, removing it provides a safeguard against its activation.
Security identifiers
- CCE-4514-6
References
3.15.2. Install Apache if Necessary
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 inscludes many packages which are likely extraneous, while the
command-line method installs only the required httpd
package itself.
link | previous | next | up | toc | home
3.15.2.1. Confirm Minimal Built-in Modules Installed
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
webserver.
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 reinstallating 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.
3.15.3. Secure Apache Configuration
The httpd
configuration file is
/etc/httpd/conf/httpd.conf
. Apply the recommendations in the remainder
of this section to this file.
link | previous | next | up | toc | home
3.15.3.1. Restrict Web Server Information Leakage
The ServerTokens
and ServerSignature
directives determine how
much information the web server discloses about the configuration of the
system.
link | previous | next | up | toc | home
3.15.3.1.a. Set httpd ServerTokens Directive to Prod
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
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.
Security identifiers
- CCE-4474-3
References
3.15.3.1.b. Set httpd ServerSignature Directive to Off
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
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.
Security identifiers
- CCE-3756-4
References
3.15.3.2. Minimize Web Server Loadable Modules
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.
link | previous | next | up | toc | home
3.15.3.2.1. httpd Core Modules
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.
link | previous | next | up | toc | home
3.15.3.2.1.a. Disable HTTP Digest Authentication
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.
3.15.3.2.1.b. Disable HTTP mod_rewrite
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.
3.15.3.2.1.c. Disable LDAP Support
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.
3.15.3.2.1.d. Disable Server Side Includes
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.
3.15.3.2.1.e. Disable MIME Magic
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.
3.15.3.2.1.f. Disable WebDAV (Distributed Authoring and Versioning)
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.
3.15.3.2.1.g. Disable Server Activity Status
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.
3.15.3.2.1.h. Disable Web Server Configuration Display
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.
3.15.3.2.1.i. Disable URL Correction on Misspelled Entries
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.
3.15.3.2.1.j. Disable Proxy Support
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.
3.15.3.2.1.k. Disable Cache Support
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.
3.15.3.2.1.l. Disable CGI Support
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.
3.15.3.2.1.13. Minimize Modules for HTTP Basic Authentication
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
3.15.3.2.1.14. Minimize Various Optional Components
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.so
-
User-specified Cache Control and Expiration
#LoadModule expires_module modules/mod_expires.so
-
Compression Output Filter (provides content compression prior to client delivery)
#LoadModule deflate_module modules/mod_deflate.so
-
HTTP Response/Request Header Customization
#LoadModule headers_module modules/mod_headers.so
-
User activity monitoring via cookies
#LoadModule usertrack_module modules/mod_usertrack.so
-
Dynamically 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.
3.15.3.2.1.15. Minimize Configuration Files Included
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.
3.15.3.3. Directory Restrictions
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.
link | previous | next | up | toc | home
3.15.3.3.a. Restrict Root Directory
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.
3.15.3.3.b. Restrict Web Directory
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.
3.15.3.3.c. Restrict Other Critical Directories
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.
3.15.3.3.d. Limit Available Methods
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.
3.15.3.4. Use Appropriate Modules to Improve httpd's Security
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.
link | previous | next | up | toc | home
3.15.3.4.1. Deploy mod_ssl
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.
link | previous | next | up | toc | home
3.15.3.4.1.a. Install mod_ssl
Install the mod_ssl
module:
# yum install mod_ssl
mod_ssl
provides encryption capabilites for the httpd
Web server. Unencrypted
content is transmitted in plain text which could be passively monitored and accessed by
unauthorized parties.
3.15.3.4.2. Deploy mod_security
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.
link | previous | next | up | toc | home
3.15.3.4.2.a. Install mod_security
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.
3.15.3.5. Use Denial-of-Service Protection Modules
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.
3.15.3.6. Configure PHP Securely
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
3.15.3.7. Configure Operating System to Protect Web Server
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.
link | previous | next | up | toc | home
3.15.3.7.1. Restrict File and Directory Access
Minimize access to critical httpd
files and directories.
link | previous | next | up | toc | home
3.15.3.7.1.a. Set Permissions on the /var/log/httpd/ Directory
Ensure that the permissions on the web server log directory is set to 700:
# chmod 700 /var/log/httpd/
This is its default setting.
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.
Security identifiers
- CCE-4574-0
References
3.15.3.7.1.b. Set Permissions on the /etc/httpd/conf/ Directory
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.
3.15.3.7.1.c. Set Permissions on All Configuration Files Inside /etc/httpd/conf/
Set permissions on the web server configuration files to 640:
# chmod 640 /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 to alter the server's configuration files.
Security identifiers
- CCE-4386-9
References
3.15.3.7.2. Configure iptables to Allow Access to the Web Server
By default, iptables
blocks access to the ports used by the web server.
To configure iptables
to allow port 80 traffic edit /etc/sysconfig/iptables
.
Add the following line, ensuring that it appears before the final LOG and DROP lines for
the RH-Firewall-1-INPUT chain:
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT
To configure iptables
to allow port 443 traffic edit /etc/sysconfig/iptables
.
Add the following line, ensuring that it appears before the final LOG and DROP lines for
the RH-Firewall-1-INPUT chain:
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 443 -j ACCEPT
3.15.3.7.3. Run httpd in a chroot Jail if Practical
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.
3.16. IMAP and POP3 Server
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.
link | previous | next | up | toc | home
3.16.1. Disable Dovecot
If the system does not need to operate as an IMAP or POP3 server, the dovecot software should be disabled and removed.
link | previous | next | up | toc | home
3.16.1.a. Disable Dovecot Service
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.
Security identifiers
- CCE-3847-1
3.16.1.b. Uninstall dovecot Package
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.
Security identifiers
- CCE-4239-0
3.16.2. Configure Dovecot if Necessary
If the system will operate as an IMAP or POP3 server, the dovecot software should be configured securely by following the recommendations below.
link | previous | next | up | toc | home
3.16.2.a. Support Only the Necessary Protocols
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.
Security identifiers
- CCE-4384-4
- CCE-3887-7
- CCE-4530-2
- CCE-4547-6
3.16.2.2. Enable SSL Support
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.
link | previous | next | up | toc | home
3.16.2.2.a. Enable the SSL flag in /etc/dovecot.conf
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.
3.16.2.2.b. Configure Dovecot to Use the SSL Certificate file
This option tell 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. 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.
3.16.2.2.c. Configure Dovecot to Use the SSL Key file
This option tell 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. 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.
3.16.2.2.d. Disable Plaintext Authentication
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.
Security identifiers
- CCE-4552-6
3.16.2.3. Allow IMAP Clients to Access the Server
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.
Edit /etc/sysconfig/iptables
. Add the following line, ensuring
that it appears before the final LOG
and DROP
lines
for the RH-Firewall-1-INPUT
chain:
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 143 -j ACCEPT
3.17. Samba(SMB) Microsoft Windows File Sharing Server
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.
link | previous | next | up | toc | home
3.17.1. Disable Samba if Possible
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.
3.17.2. Configure Samba if Necessary
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.
link | previous | next | up | toc | home
3.17.2.a. Disable Root Access
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.
3.17.2.b. Disable Root Access
By default, Samba will attempt to negotiate with Microsoft Windows machines to set a common communication protocol. Newer versions of Microsoft Windows may require the use of NTLMv2. NTLMv2 is the preferred protocol for authentication, but since older machines do not support it, Samba has disabled it by default. Enable it with the following:
[global]
client ntlmv2 auth = yes
For the sake of backwards compatibility, most modern Windows machines will still allow other machines to communicate with them over weak protocols such as LANMAN. On Samba, by enabling NTLMv2, you are also disabling LANMAN and NTLMv1. If NTLMv1 is required, it is still possible to individually disable LANMAN.
3.17.2.c. Require Client SMB Packet Signing, if using smbclient
To require samba clients running smbclient
to use
packet signing, add the following to the [global]
section
of the Samba configuration file:
client signing = mandatory
Requiring samba clients such as smbclient
to use packet
signing ensures that 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.
Security identifiers
- CCE-14075-6
3.17.2.d. Require Client SMB Packet Signing, if using mount.cifs
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 that 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.
Security identifiers
- CCE-15029-2
3.17.2.5. Let Domain Controllers Create Machine Trust Accounts On-the-Fly
Add or correct an add machine script entry to the
[global]
section of /etc/samba/smb.conf
to allow Samba to
dynamically create Machine Trust Accounts:
[global]
add machine script = /usr/sbin/useradd -n -g machines -d /dev/null -s /sbin/nologin %u
Make sure that the group machines exists. If not, add it with the following command:
# /usr/sbin/groupadd machines
When acting as a PDC, it becomes necessary to create and store Machine Trust Accounts for each machine that joins the domain. On a Microsoft Windows PDC, this account is created with the Server Manager tool, but on a Samba PDC, two accounts must be created. The first is the local machine account, and the second is the Samba account. For security purposes, it is recommended to let Samba create these accounts on-the-fly. When Machine Trust Accounts are created manually, there is a small window of opportunity in which a rogue machine could join the domain in place of the new server.
3.17.2.6. Restrict Access to the [IPC$] Share
Limit access to the [IPC$]
share so that only machines in
your network will be able to connect to it:
[IPC$]
hosts allow = 192.168.1. 127.0.0.1
hosts deny = 0.0.0.0/0
The [IPC$]
share allows users to anonymously fetch a list
of shared resources from a server. It is intended to allow users to browse the
list of available shares. It also can be used as a point of attack into a
system. Disabling it completely may break some functionality, so it is
recommended that you merely limit access to it instead.
3.17.2.7. Restrict File Sharing
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:
[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. Do not use the Samba service to share files between Unix or Linux machines.
3.17.2.8. Restrict Printer Sharing
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.
3.18. Proxy Server
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.
link | previous | next | up | toc | home
3.18.1. Disable Squid if Possible
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.
link | previous | next | up | toc | home
3.18.1.a. Disable Squid
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.
Security identifiers
- CCE-4556-7
3.18.1.b. Uninstall squid Package
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.
Security identifiers
- CCE-4076-6
3.19. SNMP Server
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 also usage of easily-guessable choices for community string.
link | previous | next | up | toc | home
3.19.1. Disable SNMP Server if Possible
The system includes an SNMP daemon that allows for its remote monitoring, though it not installed by default. If it was installed and activated, the software should be disabled and removed.
link | previous | next | up | toc | home
3.19.1.a. Disable snmpd Service
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.
Security identifiers
- CCE-3765-5
3.19.1.b. Uninstall net-snmp Package
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.
Security identifiers
- CCE-14081-4
3.19.2. Configure SNMP Server if Necessary
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 encryption
-
write access to the MIB (Management Information Base) should be allowed only if necessary
-
all access to the MIB should be restricted following a principle of least privilege
-
network 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 rules
-
ensure SNMP agents send traps only to, and accept SNMP queries only from, authorized management stations
-
ensure that permissions on the
snmpd.conf
configuration file (by default, in/etc/snmp
) are 640 or more restrictive -
ensure that any MIB files’ permissions are also 640 or more restrictive
References
- . TODO::INSERT.
Colophon
Trademark Information 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.