This guide presents a catalog of security-relevant
configuration settings for Red Hat Enterprise Linux 6. It is a rendering of
content structured in the eXtensible Configuration Checklist Description Format (XCCDF)
in order to support security automation. The SCAP content is
is available in the Applicable platforms
|
Version: 0.9 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 RHEL 6 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, sudo
can be implemented to limit authorization to super user
accounts on the system only to designated personnel. Another example is to limit
logins on server systems to only those administrators who need to log into them in
order to perform administration tasks. Using SELinux also follows the principle of
least privilege: SELinux policy can confine software to perform only actions on the
system that are specifically allowed. This can be far more restrictive than the
actions permissible by the traditional Unix permissions model.
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 may occur after instructions for an action.
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.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. Disable Modprobe Loading of USB Storage Driver
- 2.2.2.b. Disable Kernel Support for USB via Bootloader Configuration
- 2.2.2.c. Disable Booting from USB Devices in Boot Firmware
- 2.2.2.d. Assign Password to Prevent Changes to Boot Firmware Configuration
- 2.2.2.e. Disable the Automounter
- 2.2.2.f. Disable GNOME Automounting
- 2.2.2.g. Disable Mounting of cramfs
- 2.2.2.h. Disable Mounting of freevxfs
- 2.2.2.i. Disable Mounting of jffs2
- 2.2.2.j. Disable Mounting of hfs
- 2.2.2.k. Disable Mounting of hfsplus
- 2.2.2.l. Disable Mounting of squashfs
- 2.2.2.m. Disable Mounting of udf
- 2.2.2.n. 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 SGID 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.3.a. Ensure SELinux Not Disabled in /etc/grub.conf
- 2.3.b. Ensure SELinux State is Enforcing
- 2.3.c. Configure SELinux Policy
- 2.3.d. Enable the SELinux Context Restoration Service (restorecond)
- 2.3.e. Uninstall setroubleshoot Package
- 2.3.f. Uninstall mcstrans Package
- 2.3.g. Ensure No Daemons are Unconfined by SELinux
- 2.3.h. Ensure No Device Files are Unlabeled by SELinux
-
2.4. Account and Access Control
-
2.4.1. Protect Accounts by Restricting Password-Based Login
-
2.4.1.1. Restrict Root Logins
- 2.4.1.1.a. Direct root Logins Not Allowed
- 2.4.1.1.b. Restrict Virtual Console Root Logins
- 2.4.1.1.c. Restrict Serial Port Root Logins
- 2.4.1.1.d. Restrict Web Browser Use for Administrative Accounts
- 2.4.1.1.e. Ensure that System Accounts Do Not Run a Shell Upon Login
- 2.4.1.1.f. Verify Only Root Has UID 0
- 2.4.1.1.g. Root Path Must Be Vendor Default
- 2.4.1.2. Verify Proper Storage and Existence of Password Hashes
- 2.4.1.3. Set Password Expiration Parameters
- 2.4.1.4. Set Account Expiration Parameters
-
2.4.1.1. Restrict Root Logins
-
2.4.2. Protect Accounts by Configuring PAM
- 2.4.2.a. Set Last Logon/Access Notification
-
2.4.2.2. Set Password Quality Requirements
-
2.4.2.2.1. Set Password Quality Requirements, if using pam_cracklib
- 2.4.2.2.1.a. Set Password Retry Prompts Permitted Per-Session
- 2.4.2.2.1.b. Set Password to Maximum of Three Consecutive Repeating Characters
- 2.4.2.2.1.c. Set Password Strength Minimum Digit Characters
- 2.4.2.2.1.d. Set Password Strength Minimum Uppercase Characters
- 2.4.2.2.1.e. Set Password Strength Minimum Special Characters
- 2.4.2.2.1.f. Set Password Strength Minimum Lowercase Characters
- 2.4.2.2.1.g. Set Password Strength Minimum Different Characters
-
2.4.2.2.1. Set Password Quality Requirements, if using pam_cracklib
- 2.4.2.3. Set Lockouts for Failed Password Attempts
- 2.4.2.4. Set Password Hashing Algorithm
- 2.4.3. Secure Session Configuration Files for Login Accounts
-
2.4.4. Protect Physical Console Access
- 2.4.4.a. Require Authentication for Single User Mode
- 2.4.4.b. Disable Ctrl-Alt-Del Reboot Activation
- 2.4.4.c. Disable Interactive Boot
- 2.4.4.4. Set Boot Loader Password
- 2.4.4.5. Configure Screen Locking
-
2.4.1. Protect Accounts by Restricting Password-Based Login
-
2.5. Network Configuration and Firewalls
- 2.5.a. Disable Zeroconf Networking
- 2.5.b. Ensure System is Not Acting as a Network Sniffer
- 2.5.3. Disable Unused Interfaces
-
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. Transport Layer Security Support
- 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.3.g. Configure auditd to use audispd plugin
-
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. System Audit Logs Must Have Mode 0640 or Less Permissive
- 2.7.4.d. System Audit Logs Must Be Owned By Root
- 2.7.4.e. Record Events that Modify the System's Mandatory Access Controls
- 2.7.4.f. Record Attempts to Alter Logon and Logout Events
- 2.7.4.g. Record Attempts to Alter Process and Session Initiation Information
- 2.7.4.h. Ensure auditd Collects Unauthorized Access Attempts to Files (unsuccessful)
- 2.7.4.i. Ensure auditd Collects Information on the Use of Privileged Commands
- 2.7.4.j. Ensure auditd Collects Information on Exporting to Media (successful)
- 2.7.4.k. Ensure auditd Collects File Deletion Events by User
- 2.7.4.l. Ensure auditd Collects System Administrator Actions
- 2.7.4.m. Ensure auditd Collects Information on Kernel Module Loading and Unloading
- 2.7.4.n. Make the auditd Configuration Immutable
- 2.7.4.15. Records Events that Modify Date and Time Information
-
2.7.4.16. Record Events that Modify the System's Discretionary Access Controls
- 2.7.4.16.a. Record Events that Modify the System's Discretionary Access Controls - chmod
- 2.7.4.16.b. Record Events that Modify the System's Discretionary Access Controls - chown
- 2.7.4.16.c. Record Events that Modify the System's Discretionary Access Controls - fchmod
- 2.7.4.16.d. Record Events that Modify the System's Discretionary Access Controls - fchmodat
- 2.7.4.16.e. Record Events that Modify the System's Discretionary Access Controls - fchown
- 2.7.4.16.f. Record Events that Modify the System's Discretionary Access Controls - fchownat
- 2.7.4.16.g. Record Events that Modify the System's Discretionary Access Controls - fremovexattr
- 2.7.4.16.h. Record Events that Modify the System's Discretionary Access Controls - fsetxattr
- 2.7.4.16.i. Record Events that Modify the System's Discretionary Access Controls - lchown
- 2.7.4.16.j. Record Events that Modify the System's Discretionary Access Controls - lremovexattr
- 2.7.4.16.k. Record Events that Modify the System's Discretionary Access Controls - lsetxattr
- 2.7.4.16.l. Record Events that Modify the System's Discretionary Access Controls - removexattr
- 2.7.4.16.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 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-26435-8
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-26639-5
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-26215-4
References
- AU-9. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1208. URL: <http://iase.disa.mil/cci/index.html>.
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-26436-6
References
- AU-4. 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>.
- 137. URL: <http://iase.disa.mil/cci/index.html>.
- 138. URL: <http://iase.disa.mil/cci/index.html>.
- 1208. URL: <http://iase.disa.mil/cci/index.html>.
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-26557-9
References
2.1.1.f. Encrypt 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 installation time.
For manual installations, select the Encrypt
checkbox during
partition creation to encrypt the partition. When this
option is selected the system will prompt for a passphrase to use in
decrypting the partition. The passphrase will subsequently need to be entered manually
every time the system boots.
For automated/unattended installations, it is possible to use Kickstart by adding
the --encrypted
and --passphrase=
options to the definition of each partition to be
encrypted. For example, the following line would encrypt the root partition:
part / --fstype=ext3 --size=100 --onpart=hda1 --encrypted --passphrase=PASSPHRASE
Any PASSPHRASE is stored in the Kickstart in plaintext, and the Kickstart must then be protected accordingly.
Omitting the --passphrase=
option from the partition definition will cause the
installer to pause and interactively ask for the passphrase during installation.
Detailed information on encrypting partitions using LUKS can be found on the Red Had Documentation web site:
https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html
The risk of a system's physical compromise, particularly mobile systems such as laptops, places its data at risk of compromise. Encrypting this data mitigates the risk of its loss if the system is lost.
Security identifiers
- CCE-27596-6
References
- SC-13. 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>.
- 1019. URL: <http://iase.disa.mil/cci/index.html>.
- 1199. 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 a graphical
software update tool in the System menu, in the Administration submenu,
called Software Update.
Red Hat Enterprise Linux systems contain an installed software catalog called
the RPM database, which records metadata of installed packages. Consistently using
yum
or the graphical Software Update for all software installation
allows for insight into the current inventory of installed software on the system.
link | previous | next | up | toc | home
2.1.2.a. Ensure Red Hat GPG Key Installed
To ensure the system can cryptographically verify base software packages come from Red Hat (and to connect to the Red Hat Network to receive them), the Red Hat GPG key must properly be installed. To install the Red Hat GPG key, run:
# rhn_register
If the system is not connected to the Internet or an RHN Satellite,
then install the Red Hat GPG key from trusted media such as
the Red Hat installation CD-ROM or DVD. Assuming the disc is mounted
in /media/cdrom
, use the following command as the root user to import
it into the keyring:
# rpm --import /media/cdrom/RPM-GPG-KEY
The Red Hat GPG key is necessary to cryptographically verify packages are from Red Hat.
Security identifiers
- CCE-26506-6
References
2.1.2.b. Ensure gpgcheck Enabled In Main Yum Configuration
The gpgcheck
option controls whether
RPM packages' signatures are always checked prior to installation.
To configure yum to check package signatures before installing
them, ensure the following line appears in /etc/yum.conf
in
the [main]
section:
gpgcheck=1
Ensuring the validity of packages' cryptographic signatures prior to installation ensures the authenticity of the software and protects against malicious tampering.
Security identifiers
- CCE-26709-6
References
- SI-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- MA-1(b). 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 signature checking is not disabled for
any repos, remove any lines from files in /etc/yum.repos.d
of the form:
gpgcheck=0
Ensuring all packages' cryptographic signatures are valid prior to installation ensures the authenticity of the software and protects against malicious tampering.
Security identifiers
- CCE-26647-8
References
- SI-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- MA-1(b). 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
If the system is joined to the Red Hat Network, a Red Hat Satellite Server, or a yum server, run the following command to install updates:
# yum update
If the system is not configured to use one of these sources, updates (in the form of RPM packages)
can be manually downloaded from the Red Hat Network and installed using rpm
.
Installing software updates is a fundamental mitigation against the exploitation of publicly-known vulnerabilities.
Security identifiers
- CCE-27635-2
References
- SI-2. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- MA-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1227. URL: <http://iase.disa.mil/cci/index.html>.
- 1233. 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 uses snapshots of file metadata (such as hashes) and compares these
to current system files in order to detect changes.
The RPM package management system can conduct integrity
checks by comparing information in its metadata database with
files installed on the system.
Integrity checking cannot prevent intrusions,
but can detect that they have occurred. Requirements
for software integrity checking may be highly dependent on
the environment in which the system will be used. Snapshot-based
approaches such as AIDE may induce considerable overhead
in the presence of frequent software updates.
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 is
created immediately after initial system configuration, and then again after any
software update. AIDE is highly configurable, with further configuration
information located in /usr/share/doc/aide-VERSION
.
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.
Remediation script
yum -y install aide
Security identifiers
- CCE-27024-9
References
- CM-3(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-3(e). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6(3). 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>.
- 1069. URL: <http://iase.disa.mil/cci/index.html>.
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, run 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.
Remediation script
#
# Disable prelinking altogether
#
if grep -q ^PRELINKING /etc/sysconfig/prelink
then
sed -i 's/PRELINKING.*/PRELINKING=no/g' /etc/sysconfig/prelink
else
echo -e "\n# Set PRELINKING=no per security requirements" >> /etc/sysconfig/prelink
echo "PRELINKING=no" >> /etc/sysconfig/prelink
fi
#
# Undo previous prelink changes to binaries
#
/usr/sbin/prelink -ua
Security identifiers
- CCE-27221-1
References
- CM-6(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6(3). 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.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.
Security identifiers
- CCE-27135-3
References
- CM-3(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-3(e). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6(3). 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.d. Configure Periodic Execution of AIDE
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 is necessary to reveal unexpected changes in installed files.
Security identifiers
- CCE-27222-9
References
- CM-3(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-3(e). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6(3). 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>.
- 374. URL: <http://iase.disa.mil/cci/index.html>.
- 416. URL: <http://iase.disa.mil/cci/index.html>.
- 1069. URL: <http://iase.disa.mil/cci/index.html>.
- 1263. 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>.
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 and Correct 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. After locating a file with incorrect permissions, run the following command to determine which package owns it:
# rpm -qf FILENAME
Next, run the following command to reset its permissions to
the correct values:
# rpm --setperms PACKAGENAME
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-26731-0
References
- AC-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6(3). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1493. URL: <http://iase.disa.mil/cci/index.html>.
- 1494. URL: <http://iase.disa.mil/cci/index.html>.
- 1495. URL: <http://iase.disa.mil/cci/index.html>.
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. If the file was not expected to
change, investigate the cause of the change using audit logs or other means.
The package can then be reinstalled to restore the file.
Run the following command to determine which package owns the file:
# rpm -qf FILENAME
The package can be reinstalled from a yum repository using the command:
yum reinstall PACKAGENAME
Alternatively, the package can be reinstalled from trusted media using the command:
rpm -Uvh PACKAGENAME
The hashes of important files like system executables should match the information given by the RPM database. Executables with erroneous hashes could be a sign of nefarious activity on the system.
Security identifiers
- CCE-27223-7
References
- CM-6(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CM-6(3). 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>.
- 1496. URL: <http://iase.disa.mil/cci/index.html>.
2.1.3.3. Additional Security Software
Additional security software that is not provided or supported by Red Hat can be installed to provide complementary or duplicative security capabilities to those provided by the base platform. Add-on software may not be appropriate for some specialized systems.
link | previous | next | up | toc | home
2.1.3.3.a. Install Intrusion Detection Software
The base Red Hat platform already includes a sophisticated auditing system that
can detect intruder activity, as well as SELinux, which provides host-based
intrusion prevention capabilities by confining privileged programs and user
sessions which may become compromised.
Host-based intrusion detection tools provide a system-level defense when an intruder gains access to a system or network.
Security identifiers
- CCE-27409-2
References
- SC-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1263. URL: <http://iase.disa.mil/cci/index.html>.
2.1.3.3.b. Install Virus Scanning Software
Install virus scanning software, which uses signatures to search for the presence of viruses on the filesystem. The McAfee uvscan virus scanning tool is provided for DoD systems. Ensure virus definition files are no older than 7 days, or their last release. Configure the virus scanning software to perform scans dynamically on all accessed files. If this is not possible, configure the system to scan all altered files on the system on a daily basis. If the system processes inbound SMTP mail, configure the virus scanner to scan all received mail.
Virus scanning software can be used to detect if a system has been compromised by computer viruses, as well as to limit their spread to other systems.
Security identifiers
- CCE-27529-7
References
- SC-28. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- SI-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 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.
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 system.
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 all ext4 partitions on the local
system, which is the default filesystem for Red Hat Enterprise Linux
6 installations:
$ mount -t ext4 | awk '{print $3}'
For any systems that use a different
local filesystem type, modify this command as appropriate.
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
The nodev
mount option prevents files from being
interpreted as character or block devices.
Legitimate character and block devices should exist only in
the /dev
directory on the root partition or within chroot
jails built for system services.
Add the nodev
option to the fourth column of
/etc/fstab
for the line which controls mounting of
any non-root local partitions.
The nodev
mount option prevents files from being
interpreted as character or block devices. The only legitimate location
for device files is the /dev
directory located on the root partition.
The only exception to this is chroot jails, for which it is not advised
to set nodev
on these filesystems.
Security identifiers
- CCE-27045-4
References
2.2.1.b. Add nodev Option to Removable Media Partitions
The nodev
mount option prevents files from being
interpreted as character or block devices.
Legitimate character and block devices should exist only in
the /dev
directory on the root partition or within chroot
jails built for system services.
Add the nodev
option to the fourth column of
/etc/fstab
for the line which controls mounting of
any removable media partitions.
The only legitimate location for device files is the /dev
directory
located on the root partition. An exception to this is chroot jails, and it is
not advised to set nodev
on partitions which contain their root
filesystems.
Security identifiers
- CCE-26860-7
References
- AC-19(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-19(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-19(e). 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>.
- MP-2. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
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.
Preventing the direct execution of binaries from removable media (such as a USB
key) provides a defense against malicious software that may be present on such
untrusted media.
Add the noexec
option to the fourth column of
/etc/fstab
for the line which controls mounting of
any removable media partitions.
Allowing users to execute binaries from removable media such as USB keys exposes the system to potential compromise.
Security identifiers
- CCE-27196-5
References
- AC-19(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-19(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-19(e). 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>.
- MP-2. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 87. URL: <http://iase.disa.mil/cci/index.html>.
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.
Add the nosuid
option to the fourth column of
/etc/fstab
for the line which controls mounting of
any removable media partitions.
The presence of suid and sgid executables should be tightly controlled. Allowing users to introduce suid or sgid binaries from partitions mounted off of removable media would allow them to introduce their own highly-privileged programs.
Security identifiers
- CCE-27056-1
References
- AC-19(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-19(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-19(e). 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>.
- MP-2. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
2.2.1.e. Add nodev Option to /tmp
The nodev
mount option can be used to prevent device files from
being created in /tmp
.
Legitimate character and block devices should not exist
within temporary directories like /tmp
.
Add the nodev
option to the fourth column of
/etc/fstab
for the line which controls mounting of
/tmp
.
The only legitimate location for device files is the /dev
directory
located on the root partition. The only exception to this is chroot jails.
Security identifiers
- CCE-26499-4
References
2.2.1.f. Add noexec Option to /tmp
The noexec
mount option can be used to prevent binaries
from being executed out of /tmp
.
Add the noexec
option to the fourth column of
/etc/fstab
for the line which controls mounting of
/tmp
.
Allowing users to execute binaries from world-writable directories
such as /tmp
should never be necessary in normal operation and
can expose the system to potential compromise.
Security identifiers
- CCE-26720-3
References
2.2.1.g. Add nosuid Option to /tmp
The nosuid
mount option can be used to prevent
execution of setuid programs in /tmp
. The suid/sgid permissions
should not be required in these world-writable directories.
Add the nosuid
option to the fourth column of
/etc/fstab
for the line which controls mounting of
/tmp
.
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-26762-5
References
2.2.1.h. Add nodev Option to /dev/shm
The nodev
mount option can be used to prevent creation
of device files in /dev/shm
.
Legitimate character and block devices should not exist
within temporary directories like /dev/shm
.
Add the nodev
option to the fourth column of
/etc/fstab
for the line which controls mounting of
/dev/shm
.
The only legitimate location for device files is the /dev
directory
located on the root partition. The only exception to this is chroot jails.
Security identifiers
- CCE-26778-1
References
2.2.1.i. Add noexec Option to /dev/shm
The noexec
mount option can be used to prevent binaries
from being executed out of /dev/shm
.
It can be dangerous to allow the execution of binaries
from world-writable temporary storage directories such as /dev/shm
.
Add the noexec
option to the fourth column of
/etc/fstab
for the line which controls mounting of
/dev/shm
.
Allowing users to execute binaries from world-writable directories
such as /dev/shm
can expose the system to potential compromise.
Security identifiers
- CCE-26622-1
References
2.2.1.j. Add nosuid Option to /dev/shm
The nosuid
mount option can be used to prevent execution
of setuid programs in /dev/shm
. The suid/sgid permissions should not
be required in these world-writable directories.
Add the nosuid
option to the fourth column of
/etc/fstab
for the line which controls mounting of
/dev/shm
.
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-26486-1
References
2.2.1.k. Bind Mount /var/tmp To /tmp
The /var/tmp
directory is a world-writable directory.
Bind-mount it to /tmp
in order to consolidate temporary storage into
one location protected by the same techniques as /tmp
. To do so, edit
/etc/fstab
and add the following line:
/tmp /var/tmp none rw,nodev,noexec,nosuid,bind 0 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-26582-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 be
necessary in many environments, but this capability also carries some risk -- whether direct
risk from allowing users to introduce arbitrary filesystems,
or risk that software flaws in the automated mount facility itself could
allow an attacker to compromise the system.
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 can be explicitly disabled
in a configuratio file in /etc/modprobe.d
.
link | previous | next | up | toc | home
2.2.2.a. Disable Modprobe Loading of USB Storage Driver
To prevent USB storage devices from being used, configure the kernel module loading system
to prevent automatic loading of the USB storage driver.
To configure the system to prevent the usb-storage
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d
:
install usb-storage /bin/false
This will prevent the modprobe
program from loading the usb-storage
module, but will not prevent an administrator (or another program) from using the
insmod
program to load the module manually.
USB storage devices such as thumb drives can be used to introduce malicious software.
Remediation script
echo "install usb-storage /bin/false" > /etc/modprobe.d/usb-storage.conf
Security identifiers
- CCE-27016-5
References
- AC-19(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-19(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-19(e). 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.b. Disable Kernel Support for USB via Bootloader Configuration
All USB support can be disabled by adding the nousb
argument to the kernel's boot loader configuration. To do so,
append "nousb" to the kernel line in /etc/grub.conf
as shown:
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 configuration is
infeasible for systems which require USB devices, which is common.
Disabling the USB subsystem within the Linux kernel at system boot will protect against potentially malicious USB devices, although it is only practical in specialized systems.
Security identifiers
- CCE-27011-6
References
- AC-19(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-19(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-19(e). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1250. URL: <http://iase.disa.mil/cci/index.html>.
2.2.2.c. Disable Booting from USB Devices in Boot Firmware
Configure the system boot firmware (historically called BIOS on PC systems) to disallow booting from USB drives.
Booting a system from a USB device would allow an attacker to circumvent any security measures provided by the operating system. Attackers could mount partitions and modify the configuration of the OS.
Security identifiers
- CCE-26923-3
References
- AC-19(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-19(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-19(e). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1250. URL: <http://iase.disa.mil/cci/index.html>.
2.2.2.d. Assign Password to Prevent Changes to Boot Firmware Configuration
Assign a password to the system boot firmware (historically called BIOS on PC systems) to require a password for any configuration changes.
Assigning a password to the system boot firmware prevents anyone with physical access from configuring the system to boot from local media and circumvent the operating system's access controls. For systems in physically secure locations, such as a data center or Sensitive Compartmented Information Facility (SCIF), this risk must be weighed against the risk of administrative personnel being unable to conduct recovery operations in a timely fashion.
Security identifiers
- CCE-27131-2
2.2.2.e. 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 may be
possible to configure filesystem mounts statically by editing /etc/fstab
rather than relying on the automounter.
The autofs
service can be disabled with the following command:
# chkconfig autofs off
Disabling the automounter permits the administrator to
statically control filesystem mounting through /etc/fstab
.
Remediation script
#
# Disable autofs for all run levels
#
chkconfig --level 0123456 autofs off
#
# Stop autofs if currently running
#
service autofs stop
Security identifiers
- CCE-26976-1
References
- AC-19(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-19(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-19(e). 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 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
Disabling automatic mounting in GNOME can prevent the introduction of malware via removable media. It will, however, also prevent desktop users from legitimate use of removable media.
Security identifiers
- CCE-27035-5
References
2.2.2.g. Disable Mounting of cramfs
To configure the system to prevent the cramfs
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d
:
install cramfs /bin/false
This effectively prevents usage of this uncommon filesystem.
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled.
Remediation script
echo "install cramfs /bin/false" > /etc/modprobe.d/cramfs.conf
Security identifiers
- CCE-26340-0
References
2.2.2.h. Disable Mounting of freevxfs
To configure the system to prevent the freevxfs
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d
:
install freevxfs /bin/false
This effectively prevents usage of this uncommon filesystem.
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled.
Remediation script
echo "install freevxfs /bin/false" > /etc/modprobe.d/freevxfs.conf
Security identifiers
- CCE-26544-7
References
2.2.2.i. Disable Mounting of jffs2
To configure the system to prevent the jffs2
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d
:
install jffs2 /bin/false
This effectively prevents usage of this uncommon filesystem.
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled.
Remediation script
echo "install jffs2 /bin/false" > /etc/modprobe.d/jffs2.conf
Security identifiers
- CCE-26670-0
References
2.2.2.j. Disable Mounting of hfs
To configure the system to prevent the hfs
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d
:
install hfs /bin/false
This effectively prevents usage of this uncommon filesystem.
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled.
Remediation script
echo "install hfs /bin/false" > /etc/modprobe.d/hfs.conf
Security identifiers
- CCE-26800-3
References
2.2.2.k. Disable Mounting of hfsplus
To configure the system to prevent the hfsplus
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d
:
install hfsplus /bin/false
This effectively prevents usage of this uncommon filesystem.
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled.
Remediation script
echo "install hfsplus /bin/false" > /etc/modprobe.d/hfsplus.conf
Security identifiers
- CCE-26361-6
References
2.2.2.l. Disable Mounting of squashfs
To configure the system to prevent the squashfs
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d
:
install squashfs /bin/false
This effectively prevents usage of this uncommon filesystem.
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled.
Remediation script
echo "install squashfs /bin/false" > /etc/modprobe.d/squashfs.conf
Security identifiers
- CCE-26404-4
References
2.2.2.m. Disable Mounting of udf
To configure the system to prevent the udf
kernel module from being loaded, add the following line to a file in the directory /etc/modprobe.d
:
install udf /bin/false
This effectively prevents usage of this uncommon filesystem.
Linux kernel modules which implement filesystems that are not needed by the local system should be disabled.
Remediation script
echo "install udf /bin/false" > /etc/modprobe.d/udf.conf
Security identifiers
- CCE-26677-5
References
2.2.2.n. 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-27224-5
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
Failing to set the sticky bit on public directories allows unauthorized users to delete files in the directory structure.
The only authorized public directories are those temporary directories supplied with the system,
or those designed to be temporary file repositories. The setting is normally reserved for directories
used by the system, by users for temporary file storage (such as /tmp
), and for directories
requiring global read/write access.
Remediation script
df --local -P | awk {'if (NR!=1) print $6'} \
| xargs -I '{}' find '{}' -xdev -type d \
\( -perm -0002 -a ! -perm -1000 \) 2>/dev/null \
| xargs chmod a+t
Security identifiers
- CCE-26840-9
References
2.2.3.b. Ensure No World-Writable Files Exist
It is generally a good idea to remove global (other) write access to a file when it is discovered. However, check with documentation for specific applications before making changes. Also, monitor for recurring world-writable files, as these may be symptoms of a misconfigured application or user account.
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.
Security identifiers
- CCE-26910-0
References
2.2.3.c. Ensure All SGID Executables Are Authorized
The SGID (set group id) bit should be set only on files that were installed via authorized means. A straightforward means of identifying unauthorized SGID files is determine if any were not installed as part of an RPM package, which is cryptographically verified. Investigate the origin of any unpackaged SGID files.
Executable files with the SGID permission run with the privileges of the owner of the file. SGID files of uncertain provenance could allow for unprivileged users to elevate privileges. The presence of these files should be strictly controlled on the system.
Security identifiers
- CCE-26769-0
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-26497-8
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 they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed.
Security identifiers
- CCE-27032-2
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 they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed.
Security identifiers
- CCE-26872-2
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-writable directory is undesirable because it allows the owner of that directory to remove or replace any files that may be placed in the directory by other users.
Security identifiers
- CCE-26642-9
References
2.2.3.8. Verify Permissions on Files with Local Account Information and Credentials
The default restrictive permissions for files which act as
important security databases such as passwd
, shadow
,
group
, and gshadow
files must be maintained. Many utilities
need read access to the passwd
file in order to function properly, but
read access to the shadow
file allows malicious attacks against system
passwords, and should never be enabled.
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.
Remediation script
chown root /etc/shadow
Security identifiers
- CCE-26947-2
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.
Remediation script
chgrp root /etc/shadow
Security identifiers
- CCE-26967-0
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.
Remediation script
chmod 0000 /etc/shadow
Security identifiers
- CCE-26992-8
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-26822-7
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-26930-8
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-26954-8
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-27026-4
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-26975-3
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-26951-4
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 contains information about the users that are configured on
the system. Protection of this file is critical for system security.
Security identifiers
- CCE-26953-0
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-26856-5
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
accounts on the system and associated information, and protection of this file
is critical for system security.
Security identifiers
- CCE-26868-0
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. If any file in these
directories is found to be group-writable or world-writable, correct
its permission with the following command:
# chmod go-w FILE
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.
Remediation script
DIRS="/lib /lib64 /usr/lib /usr/lib64"
for dirPath in $DIRS; do
find $dirPath -perm /022 -type f -exec chmod go-w '{}' \;
done
Security identifiers
- CCE-27381-3
References
- AC-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1499. URL: <http://iase.disa.mil/cci/index.html>.
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. If the directory, or any file in these
directories, is found to be owned by a user other than root correct its
ownership with the following command:
# chown root FILE
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.
Remediation script
for LIBDIR in /usr/lib /usr/lib64 /lib /lib64
do
if [ -d $LIBDIR ]
then
find -L $LIBDIR \! -user root -exec chown root {} \;
fi
done
Security identifiers
- CCE-27424-1
References
- AC-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1499. URL: <http://iase.disa.mil/cci/index.html>.
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.
If any file FILE in these directories is found
to be group-writable or world-writable, correct its permission with the
following command:
# chmod go-w FILE
System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted.
Remediation script
DIRS="/bin /usr/bin /usr/local/bin /sbin /usr/sbin /usr/local/sbin"
for dirPath in $DIRS; do
find $dirPath -perm /022 -exec chmod go-w '{}' \;
done
Security identifiers
- CCE-27289-8
References
- AC-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1499. URL: <http://iase.disa.mil/cci/index.html>.
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.
If any file FILE in these directories is found
to be owned by a user other than root, correct its ownership with the
following command:
# chown root FILE
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.
Security identifiers
- CCE-27623-8
References
- AC-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1499. URL: <http://iase.disa.mil/cci/index.html>.
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.a. Restrict Access to Kernel Message Buffer
To set the runtime status of the kernel.dmesg_restrict
kernel parameter,
run the following command:
# sysctl -w kernel.dmesg_restrict=1
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
kernel.dmesg_restrict = 1
Unprivileged access to the kernel syslog can expose sensitive kernel address information.
Security identifiers
- CCE-27366-4
2.2.4.2. 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.2.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.
Remediation script
var_umask_for_daemons="022"
grep -q ^umask /etc/init.d/functions && \
sed -i "s/umask.*/umask $var_umask_for_daemons/g" /etc/init.d/functions
if ! [ $? -eq 0 ]; then
echo "umask $var_umask_for_daemons" >> /etc/init.d/functions
fi
Security identifiers
- CCE-27031-4
References
2.2.4.3. 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.3.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.
Remediation script
echo "* hard core 0" >> /etc/security/limits.conf
Security identifiers
- CCE-27033-0
References
2.2.4.3.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_dumpable=0
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
fs.suid_dumpable = 0
The core dump of a setuid program is more likely to contain sensitive data, as the program itself runs with greater privileges than the user who initiated execution of the program. Disabling the ability for any setuid program to write a core file decreases the risk of unauthorized access of such data.
Remediation script
#
# Set runtime for fs.suid_dumpable
#
sysctl -q -n -w fs.suid_dumpable=0
#
# If fs.suid_dumpable present in /etc/sysctl.conf, change value to "0"
# else, add "fs.suid_dumpable = 0" to /etc/sysctl.conf
#
if grep --silent ^fs.suid_dumpable /etc/sysctl.conf ; then
sed -i 's/^fs.suid_dumpable.*/fs.suid_dumpable = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set fs.suid_dumpable to 0 per security requirements" >> /etc/sysctl.conf
echo "fs.suid_dumpable = 0" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-27044-7
References
2.2.4.4. 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.4.a. Enable ExecShield
To set the runtime status of the kernel.exec-shield
kernel parameter,
run the following command:
# sysctl -w kernel.exec-shield=1
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
kernel.exec-shield = 1
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.
Remediation script
#
# Set runtime for kernel.exec-shield
#
sysctl -q -n -w kernel.exec-shield=1
#
# If kernel.exec-shield present in /etc/sysctl.conf, change value to "1"
# else, add "kernel.exec-shield = 1" to /etc/sysctl.conf
#
if grep --silent ^kernel.exec-shield /etc/sysctl.conf ; then
sed -i 's/^kernel.exec-shield.*/kernel.exec-shield = 1/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set kernel.exec-shield to 1 per security requirements" >> /etc/sysctl.conf
echo "kernel.exec-shield = 1" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-27007-4
References
2.2.4.4.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_space=2
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
kernel.randomize_va_space = 2
Address space layout randomization (ASLR) makes it more difficult for an attacker to predict the location of attack code they have introduced into a process's address space during an attempt at exploitation. Additionally, ASLR makes it more difficult for an attacker to know the location of existing code in order to re-purpose it using return oriented programming (ROP) techniques.
Remediation script
#
# Set runtime for kernel.randomize_va_space
#
sysctl -q -n -w kernel.randomize_va_space=2
#
# If kernel.randomize_va_space present in /etc/sysctl.conf, change value to "2"
# else, add "kernel.randomize_va_space = 2" to /etc/sysctl.conf
#
if grep --silent ^kernel.randomize_va_space /etc/sysctl.conf ; then
sed -i 's/^kernel.randomize_va_space.*/kernel.randomize_va_space = 2/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set kernel.randomize_va_space to 2 per security requirements" >> /etc/sysctl.conf
echo "kernel.randomize_va_space = 2" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-26999-3
References
2.2.4.5. 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.5.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-27010-8
References
2.2.4.5.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-27163-5
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 RHEL 6, has been
sufficiently developed and debugged that it should be usable on
almost any Red Hat machine with minimal configuration and a small
amount of system administrator training. This policy prevents
system services - including most of the common network-visible
services such as mail servers, FTP servers, and DNS servers - from
accessing files which those services have no valid reason to
access. This action alone prevents a huge amount of possible damage
from network attacks against services, from trojaned software, and
so forth.
This guide recommends that SELinux be enabled using the
default (targeted) policy on every Red Hat system, unless that
system has unusual requirements which make a stronger policy
appropriate.
link | previous | next | up | toc | home
2.3.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 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.
Remediation script
sed -i "s/selinux=0//gI" /etc/grub.conf
sed -i "s/enforcing=0//gI" /etc/grub.conf
Security identifiers
- CCE-26956-3
References
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-3(3). 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>.
- AU-9. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 22. URL: <http://iase.disa.mil/cci/index.html>.
- 32. URL: <http://iase.disa.mil/cci/index.html>.
2.3.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
following line to configure the system to boot into enforcing mode:
SELINUX=enforcing
Setting the SELinux state to enforcing ensures SELinux is able to confine potentially compromised processes to the security policy, which is designed to prevent them from causing damage to the system or further elevating their privileges.
Remediation script
var_selinux_state="enforcing"
grep -q ^SELINUX= /etc/selinux/config && \
sed -i "s/SELINUX=.*/SELINUX=$var_selinux_state/g" /etc/selinux/config
if ! [ $? -eq 0 ]; then
echo "SELINUX=$var_selinux_state" >> /etc/selinux/config
fi
Security identifiers
- CCE-26969-6
References
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-3(3). 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>.
- AU-9. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 22. URL: <http://iase.disa.mil/cci/index.html>.
- 32. URL: <http://iase.disa.mil/cci/index.html>.
- 26. URL: <http://iase.disa.mil/cci/index.html>.
2.3.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 the system will confine processes that are likely to be
targeted for exploitation, such as network or system services.
Remediation script
var_selinux_policy_name="targeted"
grep -q ^SELINUXTYPE /etc/selinux/config && \
sed -i "s/SELINUXTYPE=.*/SELINUXTYPE=$var_selinux_policy_name/g" /etc/selinux/config
if ! [ $? -eq 0 ]; then
echo "SELINUXTYPE=$var_selinux_policy_name" >> /etc/selinux/config
fi
Security identifiers
- CCE-26875-5
References
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-3(3). 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>.
- AU-9. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 22. URL: <http://iase.disa.mil/cci/index.html>.
- 32. URL: <http://iase.disa.mil/cci/index.html>.
2.3.d. 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 the file receives the proper SELinux
security context.
The restorecond
service can be enabled with the following command:
# chkconfig --level 2345 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.
Remediation script
#
# Enable restorecond for all run levels
#
chkconfig --level 0123456 restorecond on
#
# Start restorecond if not currently running
#
service restorecond start
Security identifiers
- CCE-26991-0
References
- AC-3. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-3(3). 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>.
- AU-9. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
2.3.e. Uninstall setroubleshoot Package
The SETroubleshoot service notifies desktop users of SELinux
denials. The service provides information around configuration errors,
unauthorized intrusions, and other potential errors.
The setroubleshoot
package can be removed with the following command:
# yum erase setroubleshoot
The SETroubleshoot service is an unnecessary daemon to have running on a server
Security identifiers
- CCE-
2.3.f. Uninstall mcstrans Package
The mcstransd
daemon provides category label information
to client processes requesting information. The label translations are defined
in /etc/selinux/targeted/setrans.conf
.
The mcstrans
package can be removed with the following command:
# yum erase mcstrans
Since this service is not used very often, disable it to reduce the amount of potentially vulnerable code running on the system. NOTE: This rule was added in support of the CIS RHEL6 v1.2.0 benchmark. Please note that Red Hat does not feel this rule is security relevant.
Security identifiers
- CCE-
2.3.g. 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.
Security identifiers
- CCE-27111-4
References
2.3.h. Ensure No Device Files are Unlabeled by SELinux
Device files, which are used for communication with important
system resources, should be labeled with proper SELinux types. If any device
files carry the SELinux type unlabeled_t
, investigate the cause and
correct the file's context.
If a device file carries the SELinux type unlabeled_t
, then SELinux
cannot properly restrict access to the device file.
Security identifiers
- CCE-26774-0
References
- AC-6. 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>.
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 22. URL: <http://iase.disa.mil/cci/index.html>.
- 32. URL: <http://iase.disa.mil/cci/index.html>.
2.4. Account and Access Control
In traditional Unix security, if an attacker gains shell access to a certain login account, they can perform any action or access any file to which that account has access. Therefore, making it more difficult for unauthorized people to gain shell access to accounts, particularly to privileged accounts, is a necessary part of securing a system. This section introduces mechanisms for restricting access to accounts under RHEL 6.
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.
link | previous | next | up | toc | home
2.4.1.1.a. Direct root Logins Not Allowed
To further limit access to the root
account, administrators
can disable root logins at the console by editing the /etc/securetty
file.
This file lists all devices the root user is allowed to login to. If the file does
not exist at all, the root user can login through any communication device on the
system, whether via the console or via a raw network interface. This is dangerous
as user can login to his machine as root via Telnet, which sends the password in
plain text over the network. By default, Red Hat Enteprise Linux's
/etc/securetty
file only allows the root user to login at the console
physically attached to the machine. To prevent root from logging in, remove the
contents of this file. To prevent direct root logins, remove the contents of this
file by typing the following command:
echo > /etc/securetty
Disabling direct root logins ensures proper accountability and multifactor authentication to privileged accounts. Users will first login, then escalate to privileged (root) access via su / sudo. This is required for FISMA Low and FISMA Moderate systems.
Security identifiers
- CCE-26891-2
References
2.4.1.1.b. 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.
Remediation script
sed -i '/^vc\//d' /etc/securetty
Security identifiers
- CCE-26855-7
References
- AC-6(2). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 770. URL: <http://iase.disa.mil/cci/index.html>.
2.4.1.1.c. 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-27047-0
References
- AC-6(2). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 770. URL: <http://iase.disa.mil/cci/index.html>.
2.4.1.1.d. Restrict Web Browser Use for Administrative Accounts
Enforce policy requiring administrative accounts use web browsers only for local service administration.
If a browser vulnerability is exploited while running with administrative privileges, the entire system could be compromised. Specific exceptions for local service administration should be documented in site-defined policy.
Security identifiers
- CCE-26795-5
2.4.1.1.e. Ensure that System Accounts Do Not Run a Shell Upon Login
Some accounts are not associated with a human
user of the system, and exist to perform some administrative
function. Should an attacker be able to log into these accounts,
they should not be granted access to a shell.
The login shell for each local account is stored in the last field of each line
in /etc/passwd
. System accounts are those user accounts with a user ID less than
500. The user ID is stored in the third field.
If any system account SYSACCT (other than root) has a login shell,
disable it with the command:
# usermod -s /sbin/nologin SYSACCT
Do not perform the steps in this section on the root account. Doing so might cause the system to become inaccessible.
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-26966-2
References
2.4.1.1.f. 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 privileged account. Proper configuration of sudo is recommended to afford multiple system administrators access to root privileges in an accountable manner.
Remediation script
awk -F: '$3 == 0 && $1 != "root" { print $1 }' /etc/passwd | xargs passwd -l
Security identifiers
- CCE-26971-2
References
2.4.1.1.g. Root Path Must Be Vendor Default
Assuming root shell is bash, edit the following files:
~/.profile
~/.bashrc
Change any PATH
variables to the vendor default for root and remove any
empty PATH
entries or references to relative paths.
The root account's executable search path must be the vendor default, and must contain only absolute paths.
Security identifiers
- CCE-27125-4
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
to
prevent logins with empty passwords.
If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.
Remediation script
sed --follow-symlinks -i 's/\<nullok\>//g' /etc/pam.d/system-auth
Security identifiers
- CCE-27038-9
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-26476-2
References
- IA-5(h). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 201. URL: <http://iase.disa.mil/cci/index.html>.
2.4.1.2.c. All GIDs referenced in /etc/passwd must be defined in /etc/group
Add a group to the system for each GID referenced without a corresponding group.
Inconsistency in GIDs between /etc/passwd
and /etc/group
could lead to a user having unintended rights.
Security identifiers
- CCE-27379-7
References
- 366. URL: <http://iase.disa.mil/cci/index.html>.
2.4.1.2.d. 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-27225-2
References
- IA-5(h). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 196. URL: <http://iase.disa.mil/cci/index.html>.
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 14
The DoD requirement is
14
.
The FISMA requirement is 12
.
If a program consults /etc/login.defs
and also another PAM module
(such as pam_cracklib
) during a password change operation,
then the most restrictive must be satisfied. See PAM section
for more information about enforcing password quality requirements.
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.
Remediation script
var_accounts_password_minlen_login_defs="14"
grep -q ^PASS_MIN_LEN /etc/login.defs && \
sed -i "s/PASS_MIN_LEN.*/PASS_MIN_LEN $var_accounts_password_minlen_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]; then
echo "PASS_MIN_LEN $var_accounts_password_minlen_login_defs" >> /etc/login.defs
fi
Security identifiers
- CCE-27002-5
References
- IA-5(f). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(1)(a). 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
A value of 1 day is considered for sufficient for many
environments.
The DoD requirement is 1.
Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement.
Remediation script
var_accounts_minimum_age_login_defs="7"
grep -q ^PASS_MIN_DAYS /etc/login.defs && \
sed -i "s/PASS_MIN_DAYS.*/PASS_MIN_DAYS $var_accounts_minimum_age_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]; then
echo "PASS_MIN_DAYS $var_accounts_minimum_age_login_defs" >> /etc/login.defs
fi
Security identifiers
- CCE-27013-2
References
- IA-5(f). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(1)(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 198. URL: <http://iase.disa.mil/cci/index.html>.
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 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.
Remediation script
var_accounts_maximum_age_login_defs="60"
grep -q ^PASS_MAX_DAYS /etc/login.defs && \
sed -i "s/PASS_MAX_DAYS.*/PASS_MAX_DAYS $var_accounts_maximum_age_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]; then
echo "PASS_MAX_DAYS $var_accounts_maximum_age_login_defs" >> /etc/login.defs
fi
Security identifiers
- CCE-26985-2
References
- IA-5(f). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(g). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(1)(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 180. URL: <http://iase.disa.mil/cci/index.html>.
- 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, replacing DAYS appropriately:
PASS_WARN_AGE DAYS
The DoD requirement is 7.
Setting the password warning age enables users to make the change at a practical time.
Remediation script
var_accounts_password_warn_age_login_defs="7"
grep -q ^PASS_WARN_AGE /etc/login.defs && \
sed -i "s/PASS_WARN_AGE.*/PASS_WARN_AGE $var_accounts_password_warn_age_login_defs/g" /etc/login.defs
if ! [ $? -eq 0 ]; then
echo "PASS_WARN_AGE $var_accounts_password_warn_age_login_defs" >> /etc/login.defs
fi
Security identifiers
- CCE-26988-6
References
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/default/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/default/useradd
, substituting
NUM_DAYS
appropriately:
INACTIVE=NUM_DAYS
A value of 35 is recommended.
If a password is currently on the
verge of expiration, then 35 days remain until the account is automatically
disabled. However, if the password will not expire for another 60 days, then 95
days could elapse until the account would be automatically disabled. See the
useradd
man page for more information. Determining the inactivity
timeout must be done with careful consideration of the length of a "normal"
period of inactivity for users in the particular environment. Setting
the timeout too low incurs support costs and also has the potential to impact
availability of the system to legitimate users.
Disabling inactive accounts ensures that accounts which may not have been responsibly removed are not available to attackers who may have compromised their credentials.
Remediation script
var_account_disable_post_pw_expiration="35"
grep -q ^INACTIVE /etc/default/useradd && \
sed -i "s/INACTIVE.*/INACTIVE=$var_account_disable_post_pw_expiration/g" /etc/default/useradd
if ! [ $? -eq 0 ]; then
echo "INACTIVE=$var_account_disable_post_pw_expiration" >> /etc/default/useradd
fi
Security identifiers
- CCE-27283-1
References
- AC-2(2). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-2(3). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 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.1.4.b. Ensure All Accounts on the System Have Unique Names
Change usernames, or delete accounts, so each has a unique name.
Unique usernames allow for accountability on the system.
Security identifiers
- CCE-27609-7
References
- 770. URL: <http://iase.disa.mil/cci/index.html>.
- 804. URL: <http://iase.disa.mil/cci/index.html>.
2.4.1.4.c. Assign Expiration Date to Temporary Accounts
In the event temporary or emergency accounts are required, configure the system
to terminate them after a documented time period. For every temporary and
emergency account, run the following command to set an expiration date on it,
substituting USER
and YYYY-MM-DD
appropriately:
# chage -E YYYY-MM-DD USER
YYYY-MM-DD
indicates the documented expiration date for the account.
When temporary and emergency accounts are created, there is a risk they may
remain in place and active after the need for them no longer exists. Account
expiration greatly reduces the risk of accounts being misused or hijacked.
Security identifiers
- CCE-27474-6
References
- AC-2(2). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-2(3). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 16. URL: <http://iase.disa.mil/cci/index.html>.
- 1682. 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.
link | previous | next | up | toc | home
2.4.2.a. Set Last Logon/Access Notification
To configure the system to notify users of last logon/access
using pam_lastlog
, add the following line immediately after session required pam_limits.so
:
session required pam_lastlog.so showfailed
Users need to be aware of activity that occurs regarding their account. Providing users with information regarding the number of unsuccessful attempts that were made to login to their account allows the user to determine if any unauthorized activity has occurred and gives them an opportunity to notify administrators.
Security identifiers
- CCE-27291-4
References
- 53. URL: <http://iase.disa.mil/cci/index.html>.
2.4.2.2. 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.2.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 maxrepeat=3 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 difok=4
If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth
.
The arguments can be modified to ensure compliance with
your organization's security policy. Discussion of each parameter follows.
Note that the password quality requirements are not enforced for the root account for some reason.
link | previous | next | up | toc | home
2.4.2.2.1.a. Set Password Retry Prompts Permitted Per-Session
To configure the number of retry prompts that are permitted per-session:
Edit the pam_cracklib.so
statement in /etc/pam.d/system-auth
to
show retry=3
, or a lower value if site policy is more restrictive.
The DoD requirement is a maximum of 3 prompts per session.
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-27123-9
References
- IA-5(c). 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.2.1.b. Set Password to Maximum of Three Consecutive Repeating Characters
The pam_cracklib module's maxrepeat
parameter controls requirements for
consecutive repeating characters. When set to a positive number, it will reject passwords
which contain more than that number of consecutive characters. Add maxrepeat=3
after pam_cracklib.so to prevent a run of four or more identical characters.
Passwords with excessive repeating characters may be more vulnerable to password-guessing attacks.
Security identifiers
- CCE-27227-8
References
- IA-5(c). 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.2.2.1.c. 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.
Add dcredit=-1
after pam_cracklib.so to require use of a digit in passwords.
Requiring digits makes password guessing attacks more difficult by ensuring a larger search space.
Security identifiers
- CCE-26374-9
References
- IA-5(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(c). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 194. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 194. URL: <http://iase.disa.mil/cci/index.html>.
2.4.2.2.1.d. 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.
Add ucredit=-1
after pam_cracklib.so to require use of an upper case character in passwords.
Requiring a minimum number of uppercase characters makes password guessing attacks more difficult by ensuring a larger search space.
Security identifiers
- CCE-26601-5
References
- IA-5(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(c). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(1)(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 192. URL: <http://iase.disa.mil/cci/index.html>.
2.4.2.2.1.e. 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.
Add ocredit=-1
after pam_cracklib.so to require use of a special character in passwords.
Requiring a minimum number of special characters makes password guessing attacks more difficult by ensuring a larger search space.
Security identifiers
- CCE-26409-3
References
- IA-5(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(c). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(1)(a). 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.2.1.f. 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.
Add lcredit=-1
after pam_cracklib.so to require use of a lowercase character in passwords.
Requiring a minimum number of lowercase characters makes password guessing attacks more difficult by ensuring a larger search space.
Security identifiers
- CCE-26631-2
References
- IA-5(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(c). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(1)(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 193. URL: <http://iase.disa.mil/cci/index.html>.
2.4.2.2.1.g. Set Password Strength Minimum Different Characters
The pam_cracklib module's difok
parameter controls requirements for
usage of different characters during a password change.
Add difok=NUM
after pam_cracklib.so to require differing
characters when changing passwords, substituting NUM appropriately.
The DoD requirement is 4
.
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-26615-5
References
- IA-5(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(c). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(1)(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 195. URL: <http://iase.disa.mil/cci/index.html>.
2.4.2.3. 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.3.a. Set Deny For Failed Password Attempts
To configure the system to lock out accounts after a number of incorrect login
attempts using pam_faillock.so
:
Add the following lines immediately below the pam_unix.so
statement in AUTH
section of
both /etc/pam.d/system-auth
and /etc/pam.d/password-auth:
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 fail_interval=900
auth required pam_faillock.so authsucc deny=3 unlock_time=604800 fail_interval=900
Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks.
Security identifiers
- CCE-26844-1
References
- AC-7(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 44. URL: <http://iase.disa.mil/cci/index.html>.
2.4.2.3.b. Set Lockout Time For Failed Password Attempts
To configure the system to lock out accounts after a number of incorrect login
attempts and require an administrator to unlock the account using pam_faillock.so
:
Add the following lines immediately below the pam_env.so
statement in /etc/pam.d/system-auth
:
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 fail_interval=900
auth required pam_faillock.so authsucc deny=3 unlock_time=604800 fail_interval=900
Locking out user accounts after a number of incorrect attempts prevents direct password guessing attacks. Ensuring that an administrator is involved in unlocking locked accounts draws appropriate attention to such situations.
Security identifiers
- CCE-27110-6
References
- AC-7(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 47. URL: <http://iase.disa.mil/cci/index.html>.
2.4.2.3.c. Set Interval For Counting Failed Password Attempts
Utilizing pam_faillock.so
, the fail_interval
directive configures the system to lock out accounts after a number of incorrect login
attempts.
Add the following fail_interval
directives to pam_faillock.so
immediately below the pam_env.so
statement in
/etc/pam.d/system-auth
and /etc/pam.d/password-auth
:
auth [default=die] pam_faillock.so authfail deny=3 unlock_time=604800 fail_interval=900
auth required pam_faillock.so authsucc deny=3 unlock_time=604800 fail_interval=900
Locking out user accounts after a number of incorrect attempts within a specific period of time prevents direct password guessing attacks.
Security identifiers
- CCE-27215-3
References
- AC-7(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1452. URL: <http://iase.disa.mil/cci/index.html>.
2.4.2.3.d. 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 the file /etc/pam.d/system-auth
, append remember=24
to the
line which refers to the pam_unix.so
module, as shown:
password sufficient pam_unix.so existing_options remember=24
The DoD and FISMA requirement is 24 passwords.
Preventing re-use of previous passwords helps ensure that a compromised password is not re-used by a user.
Security identifiers
- CCE-26741-9
References
- IA-5(f). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(1)(e). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 200. URL: <http://iase.disa.mil/cci/index.html>.
2.4.2.4. Set Password Hashing Algorithm
The system's default algorithm for storing password hashes in
/etc/shadow
is SHA-512. This can be configured in several
locations.
link | previous | next | up | toc | home
2.4.2.4.a. Set Password Hashing Algorithm in /etc/pam.d/system-auth
In /etc/pam.d/system-auth
, the password
section of
the file controls which PAM modules execute during a password change.
Set the pam_unix.so
module in the
password
section to include the argument sha512
, as shown below:
password sufficient pam_unix.so sha512 other arguments...
This will help ensure when local users change their passwords, hashes for the new
passwords will be generated using the SHA-512 algorithm.
This is the default.
Using a stronger hashing algorithm makes password cracking attacks more difficult.
Security identifiers
- CCE-26303-8
References
- IA-5(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(c). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(1)(c). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 803. URL: <http://iase.disa.mil/cci/index.html>.
2.4.2.4.b. Set Password Hashing Algorithm in /etc/login.defs
In /etc/login.defs
, add or correct the following line to ensure
the system will use SHA-512 as the hashing algorithm:
ENCRYPT_METHOD SHA512
Using a stronger hashing algorithm makes password cracking attacks more difficult.
Security identifiers
- CCE-27228-6
References
- IA-5(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(c). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(1)(c). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 803. URL: <http://iase.disa.mil/cci/index.html>.
2.4.2.4.c. Set Password Hashing Algorithm in /etc/libuser.conf
In /etc/libuser.conf
, add or correct the following line in its
[defaults]
section to ensure the system will use the SHA-512
algorithm for password hashing:
crypt_style = sha512
Using a stronger hashing algorithm makes password cracking attacks more difficult.
Security identifiers
- CCE-27229-4
References
- IA-5(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(c). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(1)(c). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 803. 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, they can often gain full access to the affected user's account. Therefore, it is important to test and correct configuration file permissions for interactive accounts, particularly those of privileged users such as root or system administrators.
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. The DoD requirement is 10. To set the number of concurrent
sessions per user add the following line in /etc/security/limits.conf
:
* hard maxlogins 10
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.
Remediation script
var_accounts_max_concurrent_login_sessions="1"
echo "* hard maxlogins $var_accounts_max_concurrent_login_sessions" >> /etc/security/limits.conf
Security identifiers
- CCE-27457-1
References
2.4.3.b. Ensure that User Home Directories are not Group-Writable or World-Readable
For each human user of the system, view the permissions of the user's home directory:
# ls -ld /home/USER
Ensure that the directory is not group-writable and that it
is not world-readable. If necessary, repair the permissions:
# chmod g-w /home/USER
# chmod o-rwx /home/USER
This action may involve modifying user home directories. Notify your user community, and solicit input if appropriate, before making this type of change.
User home directories contain many configuration files which affect the behavior of a user's account. No user should ever have write permission to another user's home directory. Group shared directories can be configured in sub-directories or elsewhere in the filesystem if they are needed. Typically, user home directories should not be world-readable, as it would disclose file names to other users. If a subset of users need read access to one another's home directories, this can be provided using groups or ACLs.
Security identifiers
- CCE-26981-1
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-26826-8
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-26768-2
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 or written to by unauthorized users.
Remediation script
var_accounts_user_umask="027"
grep -q umask /etc/bashrc && \
sed -i "s/umask.*/umask $var_accounts_user_umask/g" /etc/bashrc
if ! [ $? -eq 0 ]; then
echo "umask $var_accounts_user_umask" >> /etc/bashrc
fi
Security identifiers
- CCE-26917-5
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 or written to by unauthorized users.
Remediation script
var_accounts_user_umask="027"
grep -q umask /etc/csh.cshrc && \
sed -i "s/umask.*/umask $var_accounts_user_umask/g" /etc/csh.cshrc
if ! [ $? -eq 0 ]; then
echo "umask $var_accounts_user_umask" >> /etc/csh.cshrc
fi
Security identifiers
- CCE-27034-8
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 or written to by unauthorized users.
Remediation script
var_accounts_user_umask="027"
grep -q umask /etc/profile && \
sed -i "s/umask.*/umask $var_accounts_user_umask/g" /etc/profile
if ! [ $? -eq 0 ]; then
echo "umask $var_accounts_user_umask" >> /etc/profile
fi
Security identifiers
- CCE-26669-2
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 written to by unauthorized users.
Remediation script
var_accounts_user_umask="027"
grep -q UMASK /etc/login.defs && \
sed -i "s/UMASK.*/UMASK $var_accounts_user_umask/g" /etc/login.defs
if ! [ $? -eq 0 ]; then
echo "UMASK $var_accounts_user_umask" >> /etc/login.defs
fi
Security identifiers
- CCE-26371-5
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.
Remediation script
grep -q ^SINGLE /etc/sysconfig/init && \
sed -i "s/SINGLE.*/SINGLE=\/sbin\/sulogin/g" /etc/sysconfig/init
if ! [ $? -eq 0 ]; then
echo "SINGLE=/sbin/sulogin" >> /etc/sysconfig/init
fi
Security identifiers
- CCE-27040-5
References
- IA-2(1). 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.b. Disable Ctrl-Alt-Del Reboot Activation
By default, the system includes the following line in
/etc/init/control-alt-delete.conf
to reboot the system when the Ctrl-Alt-Del key sequence is pressed:
exec /sbin/shutdown -r now "Control-Alt-Delete pressed"
To configure the system to log a message instead of rebooting the system, alter that line to read as follows:
exec /usr/bin/logger -p security.info "Control-Alt-Delete pressed"
A locally logged-in user who presses Ctrl-Alt-Del, when at the console,
can reboot the system. If accidentally pressed, as could happen in
the case of mixed OS environment, this can create the risk of short-term
loss of availability of systems due to unintentional reboot.
In the GNOME graphical environment, risk of unintentional reboot from the
Ctrl-Alt-Del sequence is reduced because the user will be
prompted before any action is taken.
NOTE: When updating the initscripts
package on a Red Hat Enterprise
Linux 6 system, custom changes to /etc/init/control-alt-delete.conf
may be overwritten. Refer to https://access.redhat.com/site/solutions/70464
for additional information.
Security identifiers
- CCE-27567-7
2.4.4.c. 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.
Remediation script
grep -q ^PROMPT /etc/sysconfig/init && \
sed -i "s/PROMPT.*/PROMPT=no/g" /etc/sysconfig/init
if ! [ $? -eq 0 ]; then
echo "PROMPT=no" >> /etc/sysconfig/init
fi
Security identifiers
- CCE-27043-9
References
2.4.4.4. 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, protect the boot loader configuration with a password and ensure its configuration file's permissions are set properly.
link | previous | next | up | toc | home
2.4.4.4.a. Verify /etc/grub.conf User Ownership
The file /etc/grub.conf
should
be owned by the root
user to prevent destruction
or modification of the file.
To properly set the owner of /etc/grub.conf
, run the command:
# chown root/etc/grub.conf
Only root should be able to modify important boot parameters.
Security identifiers
- CCE-26995-1
References
2.4.4.4.b. Verify /etc/grub.conf Group Ownership
The file /etc/grub.conf
should
be group-owned by the root
group to prevent
destruction or modification of the file.
To properly set the group owner of /etc/grub.conf
, run the command:
# chgrp root/etc/grub.conf
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-27022-3
References
2.4.4.4.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 600/boot/grub/grub.conf
Proper permissions ensure that only the root user can modify important boot parameters.
Security identifiers
- CCE-26949-8
References
2.4.4.4.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 the following command:
# grub-crypt --sha-512
When prompted to enter a password, insert the following line into /etc/grub.conf
immediately after the header comments. (Use the output from grub-crypt
as the
value of password-hash):
password --encrypted password-hash
NOTE: To meet FISMA Moderate, the bootloader password MUST differ from the root password.
Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode.
Security identifiers
- CCE-26911-8
References
- IA-2(1). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IA-5(e). 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.5. 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.5.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.5.1.a. Set GNOME Login Inactivity Timeout
Run the following command to set the idle time-out value for inactivity in the GNOME desktop to 15 minutes:
# gconftool-2 \
--direct \
--config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
--type int \
--set /desktop/gnome/session/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-26828-4
References
- AC-11(a). 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.5.1.b. GNOME Desktop Screensaver Mandatory Use
Run the following command to activate the screensaver in the GNOME desktop after a period of inactivity:
# gconftool-2 --direct \
--config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
--type bool \
--set /apps/gnome-screensaver/idle_activation_enabled true
Enabling idle activation of the screen saver ensures the screensaver will be activated after the idle delay. Applications requiring continuous, real-time screen display (such as network management products) require the login session does not have administrator rights and the display station is located in a controlled-access area.
Security identifiers
- CCE-26600-7
References
- AC-11(a). 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.5.1.c. Enable Screen Lock Activation After Idle Period
Run the following command to activate locking of the screensaver in the GNOME desktop when it is activated:
# gconftool-2 --direct \
--config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
--type bool \
--set /apps/gnome-screensaver/lock_enabled true
Enabling the activation of the screen lock after an idle period ensures password entry will be required in order to access the system, preventing access by passersby.
Security identifiers
- CCE-26235-2
References
- AC-11(a). 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.5.1.d. Implement Blank Screen Saver
Run the following command to set the screensaver mode in the GNOME desktop to a blank screen:
# gconftool-2 --direct \
--config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
--type string \
--set /apps/gnome-screensaver/mode blank-only
Setting the screensaver mode to blank-only conceals the contents of the display from passersby.
Security identifiers
- CCE-26638-7
References
- AC-11(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 60. URL: <http://iase.disa.mil/cci/index.html>.
2.4.4.5.2. Configure Console Screen Locking
A console screen locking mechanism is provided in the
screen
package, which is not installed by default.
link | previous | next | up | toc | home
2.4.4.5.2.a. Install the screen Package
To enable console screen locking, install the screen
package:
# yum install screen
Instruct users to begin new terminal sessions with the following command:
$ screen
The console can now be locked with the following key combination:
ctrl+a x
Installing screen
ensures a console locking capability is available
for users who may need to suspend console logins.
Remediation script
yum -y install screen
Security identifiers
- CCE-26940-7
References
- 58. URL: <http://iase.disa.mil/cci/index.html>.
2.4.4.5.3. Hardware Tokens for Authentication
The use of hardware tokens such as smart cards for system login provides stronger, two-factor authentication than using a username/password. In Red Hat Enterprise Linux servers and workstations, hardware token login is not enabled by default and must be enabled in the system settings.
link | previous | next | up | toc | home
2.4.4.5.3.a. Enable Smart Card Login
To enable smart card authentication, consult the documentation at:
-
https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/enabling-smart-card-login.html
Smart card login provides two-factor authentication stronger than that provided by a username/password combination. Smart cards leverage a PKI (public key infrastructure) in order to provide and verify credentials.
Security identifiers
- CCE-27440-7
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
To configure the system login banner:
Edit /etc/issue
. Replace the default text with a message
compliant with the local site policy or a legal disclaimer.
The DoD required text is either:
You are accessing a U.S. Government (USG) Information System (IS) that is
provided for USG-authorized use only. By using this IS (which includes any
device attached to this IS), you consent to the following conditions:
-The USG routinely intercepts and monitors communications on this IS for purposes
including, but not limited to, penetration testing, COMSEC monitoring, network
operations and defense, personnel misconduct (PM), law enforcement (LE), and
counterintelligence (CI) investigations.
-At any time, the USG may inspect and seize data stored on this IS.
-Communications using, or data stored on, this IS are not private, are subject
to routine monitoring, interception, and search, and may be disclosed or used
for any USG-authorized purpose.
-This IS includes security measures (e.g., authentication and access controls)
to protect USG interests -- not for your personal benefit or privacy.
-Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative
searching or monitoring of the content of privileged communications, or work
product, related to personal representation or services by attorneys,
psychotherapists, or clergy, and their assistants. Such communications and work
product are private and confidential. See User Agreement for details.
OR:
I've read & consent to terms in IS user agreem't.
An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers.
Remediation script
login_banner_text=""
cat <<EOF >/etc/issue
$login_banner_text
EOF
Security identifiers
- CCE-26974-6
2.4.5.b. 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.
Security identifiers
- CCE-27230-2
References
2.4.5.3. 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.3.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.
An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers.
Security identifiers
- CCE-27195-7
2.4.5.3.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.
An appropriate warning message reinforces policy awareness during the logon process and facilitates possible legal action against attackers.
Security identifiers
- CCE-27017-3
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 an attackers' ability
to connect to your system. These rules can specify that network
traffic should be allowed or denied from certain IP addresses,
hosts, and networks. The rules can also specify which of the
system's network services are available to particular hosts or
networks.
link | previous | next | up | toc | home
2.5.a. 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.254.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.
Remediation script
echo "NOZEROCONF=yes" >> /etc/sysconfig/network
Security identifiers
- CCE-27151-0
References
2.5.b. 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-27152-8
References
2.5.3. Disable Unused Interfaces
Network interfaces expand the attack surface of the
system. Unused interfaces are not monitored or controlled, and
should be disabled.
If the system does not require network communications but still
needs to use the loopback interface, remove all files of the form
ifcfg-interface
except for ifcfg-lo
from
/etc/sysconfig/network-scripts
:
# rm /etc/sysconfig/network-scripts/ifcfg-interface
If the system is a standalone machine with no need for network access or even
communication over the loopback device, then disable this service.
The network
service can be disabled with the following command:
# chkconfig network off
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 setting certain kernel parameters 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_redirects=0
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv4.conf.default.send_redirects = 0
Sending ICMP redirects permits the system to instruct other systems to update their routing information. The ability to send ICMP redirects is only appropriate for systems acting as routers.
Remediation script
#
# Set runtime for net.ipv4.conf.default.send_redirects
#
sysctl -q -n -w net.ipv4.conf.default.send_redirects=0
#
# If net.ipv4.conf.default.send_redirects present in /etc/sysctl.conf, change value to "0"
# else, add "net.ipv4.conf.default.send_redirects = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.default.send_redirects /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.default.send_redirects.*/net.ipv4.conf.default.send_redirects = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.default.send_redirects to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.send_redirects = 0" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-27001-7
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-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>.
- 1551. URL: <http://iase.disa.mil/cci/index.html>.
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_redirects=0
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv4.conf.all.send_redirects = 0
Sending ICMP redirects permits the system to instruct other systems to update their routing information. The ability to send ICMP redirects is only appropriate for systems acting as routers.
Security identifiers
- CCE-27004-1
References
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1551. URL: <http://iase.disa.mil/cci/index.html>.
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_forward=0
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv4.ip_forward = 0
IP forwarding permits the kernel to forward packets from one network interface to another. The ability to forward packets between two networks is only appropriate for systems acting as routers.
Security identifiers
- CCE-26866-4
References
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_route=0
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv4.conf.all.accept_source_route = 0
Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required.
Remediation script
#
# Set runtime for net.ipv4.conf.all.accept_source_route
#
sysctl -q -n -w net.ipv4.conf.all.accept_source_route=0
#
# If net.ipv4.conf.all.accept_source_route present in /etc/sysctl.conf, change value to "0"
# else, add "net.ipv4.conf.all.accept_source_route = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.all.accept_source_route /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.all.accept_source_route.*/net.ipv4.conf.all.accept_source_route = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.all.accept_source_route to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.accept_source_route = 0" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-27037-1
References
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1551. URL: <http://iase.disa.mil/cci/index.html>.
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_redirects=0
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv4.conf.all.accept_redirects = 0
Accepting ICMP redirects has few legitimate uses. It should be disabled unless it is absolutely required.
Remediation script
#
# Set runtime for net.ipv4.conf.all.accept_redirects
#
sysctl -q -n -w net.ipv4.conf.all.accept_redirects=0
#
# If net.ipv4.conf.all.accept_redirects present in /etc/sysctl.conf, change value to "0"
# else, add "net.ipv4.conf.all.accept_redirects = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.all.accept_redirects /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.all.accept_redirects.*/net.ipv4.conf.all.accept_redirects = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.all.accept_redirects to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.accept_redirects = 0" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-27027-2
References
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1503. URL: <http://iase.disa.mil/cci/index.html>.
- 1551. URL: <http://iase.disa.mil/cci/index.html>.
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_redirects=0
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv4.conf.all.secure_redirects = 0
Accepting "secure" ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required.
Remediation script
#
# Set runtime for net.ipv4.conf.all.secure_redirects
#
sysctl -q -n -w net.ipv4.conf.all.secure_redirects=0
#
# If net.ipv4.conf.all.secure_redirects present in /etc/sysctl.conf, change value to "0"
# else, add "net.ipv4.conf.all.secure_redirects = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.all.secure_redirects /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.all.secure_redirects.*/net.ipv4.conf.all.secure_redirects = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.all.secure_redirects to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.secure_redirects = 0" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-26854-0
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>.
- 1503. URL: <http://iase.disa.mil/cci/index.html>.
- 1551. URL: <http://iase.disa.mil/cci/index.html>.
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_martians=1
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv4.conf.all.log_martians = 1
The presence of "martian" packets (which have impossible addresses) as well as spoofed packets, source-routed packets, and redirects could be a sign of nefarious network activity. Logging these packets enables this activity to be detected.
Remediation script
#
# Set runtime for net.ipv4.conf.all.log_martians
#
sysctl -q -n -w net.ipv4.conf.all.log_martians=1
#
# If net.ipv4.conf.all.log_martians present in /etc/sysctl.conf, change value to "1"
# else, add "net.ipv4.conf.all.log_martians = 1" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.all.log_martians /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.all.log_martians.*/net.ipv4.conf.all.log_martians = 1/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.all.log_martians to 1 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.log_martians = 1" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-27066-0
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_route=0
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv4.conf.default.accept_source_route = 0
Accepting source-routed packets in the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required.
Remediation script
#
# Set runtime for net.ipv4.conf.default.accept_source_route
#
sysctl -q -n -w net.ipv4.conf.default.accept_source_route=0
#
# If net.ipv4.conf.default.accept_source_route present in /etc/sysctl.conf, change value to "0"
# else, add "net.ipv4.conf.default.accept_source_route = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.default.accept_source_route /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.default.accept_source_route.*/net.ipv4.conf.default.accept_source_route = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.default.accept_source_route to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.accept_source_route = 0" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-26983-7
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-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>.
- 1551. URL: <http://iase.disa.mil/cci/index.html>.
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_redirects=0
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv4.conf.default.accept_redirects = 0
This feature of the IPv4 protocol has few legitimate uses. It should be disabled unless it is absolutely required.
Remediation script
#
# Set runtime for net.ipv4.conf.default.accept_redirects
#
sysctl -q -n -w net.ipv4.conf.default.accept_redirects=0
#
# If net.ipv4.conf.default.accept_redirects present in /etc/sysctl.conf, change value to "0"
# else, add "net.ipv4.conf.default.accept_redirects = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.default.accept_redirects /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.default.accept_redirects.*/net.ipv4.conf.default.accept_redirects = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.default.accept_redirects to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.accept_redirects = 0" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-27015-7
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-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>.
- 1551. URL: <http://iase.disa.mil/cci/index.html>.
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_redirects=0
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv4.conf.default.secure_redirects = 0
Accepting "secure" ICMP redirects (from those gateways listed as default gateways) has few legitimate uses. It should be disabled unless it is absolutely required.
Remediation script
#
# Set runtime for net.ipv4.conf.default.secure_redirects
#
sysctl -q -n -w net.ipv4.conf.default.secure_redirects=0
#
# If net.ipv4.conf.default.secure_redirects present in /etc/sysctl.conf, change value to "0"
# else, add "net.ipv4.conf.default.secure_redirects = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.default.secure_redirects /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.default.secure_redirects.*/net.ipv4.conf.default.secure_redirects = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.default.secure_redirects to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.secure_redirects = 0" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-26831-8
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-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>.
- 1551. URL: <http://iase.disa.mil/cci/index.html>.
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_broadcasts=1
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv4.icmp_echo_ignore_broadcasts = 1
Ignoring ICMP echo requests (pings) sent to broadcast or multicast addresses makes the system slightly more difficult to enumerate on the network.
Remediation script
#
# Set runtime for net.ipv4.icmp_echo_ignore_broadcasts
#
sysctl -q -n -w net.ipv4.icmp_echo_ignore_broadcasts=1
#
# If net.ipv4.icmp_echo_ignore_broadcasts present in /etc/sysctl.conf, change value to "1"
# else, add "net.ipv4.icmp_echo_ignore_broadcasts = 1" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.icmp_echo_ignore_broadcasts /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.icmp_echo_ignore_broadcasts.*/net.ipv4.icmp_echo_ignore_broadcasts = 1/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.icmp_echo_ignore_broadcasts to 1 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.icmp_echo_ignore_broadcasts = 1" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-26883-9
References
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_responses=1
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv4.icmp_ignore_bogus_error_responses = 1
Ignoring bogus ICMP error responses reduces log size, although some activity would not be logged.
Remediation script
#
# Set runtime for net.ipv4.icmp_ignore_bogus_error_responses
#
sysctl -q -n -w net.ipv4.icmp_ignore_bogus_error_responses=1
#
# If net.ipv4.icmp_ignore_bogus_error_responses present in /etc/sysctl.conf, change value to "1"
# else, add "net.ipv4.icmp_ignore_bogus_error_responses = 1" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.icmp_ignore_bogus_error_responses /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.icmp_ignore_bogus_error_responses.*/net.ipv4.icmp_ignore_bogus_error_responses = 1/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.icmp_ignore_bogus_error_responses to 1 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.icmp_ignore_bogus_error_responses = 1" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-26993-6
References
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_syncookies=1
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv4.tcp_syncookies = 1
A TCP SYN flood attack can cause a denial of service by filling a system's TCP connection table with connections in the SYN_RCVD state. Syncookies can be used to track a connection when a subsequent ACK is received, verifying the initiator is attempting a valid connection and is not a flood source. This feature is activated when a flood condition is detected, and enables the system to continue servicing valid connection requests.
Remediation script
#
# Set runtime for net.ipv4.tcp_syncookies
#
sysctl -q -n -w net.ipv4.tcp_syncookies=1
#
# If net.ipv4.tcp_syncookies present in /etc/sysctl.conf, change value to "1"
# else, add "net.ipv4.tcp_syncookies = 1" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.tcp_syncookies /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.tcp_syncookies.*/net.ipv4.tcp_syncookies = 1/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.tcp_syncookies to 1 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.tcp_syncookies = 1" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-27053-8
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_filter=1
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv4.conf.all.rp_filter = 1
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.
Remediation script
#
# Set runtime for net.ipv4.conf.all.rp_filter
#
sysctl -q -n -w net.ipv4.conf.all.rp_filter=1
#
# If net.ipv4.conf.all.rp_filter present in /etc/sysctl.conf, change value to "1"
# else, add "net.ipv4.conf.all.rp_filter = 1" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.all.rp_filter /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.all.rp_filter.*/net.ipv4.conf.all.rp_filter = 1/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.all.rp_filter to 1 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.all.rp_filter = 1" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-26979-5
References
- AC-4. 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>.
- 1551. URL: <http://iase.disa.mil/cci/index.html>.
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_filter=1
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv4.conf.default.rp_filter = 1
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.
Remediation script
#
# Set runtime for net.ipv4.conf.default.rp_filter
#
sysctl -q -n -w net.ipv4.conf.default.rp_filter=1
#
# If net.ipv4.conf.default.rp_filter present in /etc/sysctl.conf, change value to "1"
# else, add "net.ipv4.conf.default.rp_filter = 1" to /etc/sysctl.conf
#
if grep --silent ^net.ipv4.conf.default.rp_filter /etc/sysctl.conf ; then
sed -i 's/^net.ipv4.conf.default.rp_filter.*/net.ipv4.conf.default.rp_filter = 1/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv4.conf.default.rp_filter to 1 per security requirements" >> /etc/sysctl.conf
echo "net.ipv4.conf.default.rp_filter = 1" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-26915-9
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 include provisions to
prevent the purchase of equipment that will be used in sensitive spaces and
includes wireless capabilities. If it is impractical to remove the wireless
hardware, and policy permits the device to enter sensitive spaces as long
as wireless is disabled, efforts should instead focus on disabling wireless capability
via software.
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-26878-9
References
- AC-17(8). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-18(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-18(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-18(3). 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.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-27057-9
References
- AC-17(8). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-18(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-18(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-18(3). 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.c. Disable Bluetooth Service
The bluetooth
service can be disabled with the following command:
# chkconfig bluetooth off
# service bluetooth stop
Disabling the bluetooth
service prevents the system from attempting
connections to Bluetooth devices, which entails some security risk.
Nevertheless, variation in this risk decision may be expected due to the
utility of Bluetooth connectivity and its limited range.
Remediation script
#
# Disable bluetooth for all run levels
#
chkconfig --level 0123456 bluetooth off
#
# Stop bluetooth if currently running
#
service bluetooth stop
Security identifiers
- CCE-27081-9
References
- AC-17(8). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-18(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-18(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-18(3). 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>.
- 1551. 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/false
install bluetooth /bin/false
If Bluetooth functionality must be disabled, preventing the kernel from loading the kernel module provides an additional safeguard against its activation.
Security identifiers
- CCE-26763-3
References
- AC-17(8). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-18(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-18(d). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-18(3). 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>.
- 1551. 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 auto-configuration occurs even when only an IPv4 address is assigned. The only way to effectively prevent execution of the IPv6 networking stack is to instruct the system not to activate the IPv6 kernel module.
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-27153-6
References
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1551. URL: <http://iase.disa.mil/cci/index.html>.
2.5.6.1.b. Disable Interface Usage of IPv6
To disable interface usage of IPv6, add or correct the following lines in /etc/sysconfig/network
:
NETWORKING_IPV6=no
IPV6INIT=no
Security identifiers
- CCE-27161-9
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 - -
Security identifiers
- CCE-27232-8
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 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, edit the
file /etc/sysconfig/network-scripts/ifcfg-interface
. Add or correct the
following line (substituting the correct IPv6 address):
IPV6ADDR=2001:0DB8::ABCD/64
Manually assigning an IP address is preferable to accepting one from routers or
from the network otherwise. The example address here is an IPv6 address
reserved for documentation purposes, as defined by RFC3849.
Security identifiers
- CCE-27233-6
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-interface
:
IPV6_PRIVACY=rfc3041
Automatically-generated IPv6 addresses are based on the underlying hardware
(e.g. Ethernet) address, and so it becomes possible to track a piece of
hardware over its lifetime using its traffic. If it is important for a system's
IP address to not trivially reveal its hardware address, this setting should be
applied.
Security identifiers
- CCE-27154-4
References
2.5.6.2.c. Manually Assign IPv6 Router Address
Edit the file
/etc/sysconfig/network-scripts/ifcfg-interface
, and add or correct
the following line (substituting your gateway IP as appropriate):
IPV6_DEFAULTGW=2001:0DB8::0001
Router addresses should be manually set and not accepted via any
auto-configuration or router advertisement.
Security identifiers
- CCE-27234-4
References
2.5.6.2.4. 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.4.a. Disable Accepting IPv6 Router Advertisements
To set the runtime status of the net.ipv6.conf.default.accept_ra
kernel parameter,
run the following command:
# sysctl -w net.ipv6.conf.default.accept_ra=0
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv6.conf.default.accept_ra = 0
An illicit router advertisement message could result in a man-in-the-middle attack.
Remediation script
#
# Set runtime for net.ipv6.conf.default.accept_ra
#
sysctl -q -n -w net.ipv6.conf.default.accept_ra=0
#
# If net.ipv6.conf.default.accept_ra present in /etc/sysctl.conf, change value to "0"
# else, add "net.ipv6.conf.default.accept_ra = 0" to /etc/sysctl.conf
#
if grep --silent ^net.ipv6.conf.default.accept_ra /etc/sysctl.conf ; then
sed -i 's/^net.ipv6.conf.default.accept_ra.*/net.ipv6.conf.default.accept_ra = 0/g' /etc/sysctl.conf
else
echo "" >> /etc/sysctl.conf
echo "# Set net.ipv6.conf.default.accept_ra to 0 per security requirements" >> /etc/sysctl.conf
echo "net.ipv6.conf.default.accept_ra = 0" >> /etc/sysctl.conf
fi
Security identifiers
- CCE-27164-3
References
2.5.6.2.4.b. Disable Accepting IPv6 Redirects
To set the runtime status of the net.ipv6.conf.default.accept_redirects
kernel parameter,
run the following command:
# sysctl -w net.ipv6.conf.default.accept_redirects=0
If this is not the system's default value, add the following line to /etc/sysctl.conf
:
net.ipv6.conf.default.accept_redirects = 0
An illicit ICMP redirect message could result in a man-in-the-middle attack.
Security identifiers
- CCE-27166-8
References
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1551. URL: <http://iase.disa.mil/cci/index.html>.
2.5.6.2.5. Limit Network-Transmitted Configuration if Using Static IPv6 Addresses
To limit the configuration information requested from other
systems and accepted from the network on a system that uses
statically-configured IPv6 addresses, add the following lines to
/etc/sysctl.conf
:
net.ipv6.conf.default.router_solicitations = 0
net.ipv6.conf.default.accept_ra_rtr_pref = 0
net.ipv6.conf.default.accept_ra_pinfo = 0
net.ipv6.conf.default.accept_ra_defrtr = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.dad_transmits = 0
net.ipv6.conf.default.max_addresses = 1
The router_solicitations
setting determines how many router
solicitations are sent when bringing up the interface. If addresses are
statically assigned, there is no need to send any solicitations.
The
accept_ra_pinfo
setting controls whether the system will accept
prefix info from the router.
The
accept_ra_defrtr
setting controls whether the system will accept
Hop Limit settings from a router advertisement. Setting it to 0 prevents a
router from changing your default IPv6 Hop Limit for outgoing packets.
The
autoconf
setting controls whether router advertisements can cause
the system to assign a global unicast address to an interface.
The
dad_transmits
setting determines how many neighbor solicitations
to send out per address (global and link-local) when bringing up an interface
to ensure the desired address is unique on the network.
The
max_addresses
setting determines how many global unicast IPv6
addresses can be assigned to each interface. The default is 16, but it should
be set to exactly the number of statically configured global addresses
required.
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.
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 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
2 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
5 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
1 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
The ip6tables
default rules are essentially the same.
link | previous | next | up | toc | home
2.5.7.1.a. Verify ip6tables Enabled if Using IPv6
The ip6tables
service can be enabled with the following command:
# chkconfig --level 2345 ip6tables on
The ip6tables
service provides the system's host-based firewalling
capability for IPv6 and ICMPv6.
Remediation script
#
# Enable ip6tables for all run levels
#
chkconfig --level 0123456 ip6tables on
#
# Start ip6tables if not currently running
#
service ip6tables start
Security identifiers
- CCE-27006-6
References
- AC-4. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CA-3(c). 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>.
- 32. URL: <http://iase.disa.mil/cci/index.html>.
- 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>.
- 1414. URL: <http://iase.disa.mil/cci/index.html>.
2.5.7.1.b. Set Default ip6tables 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/ip6tables
:
:INPUT DROP [0:0]
In ip6tables
the default policy is applied only after all
the applicable rules in the table are examined for a match. Setting the
default policy to DROP
implements proper design for a firewall, i.e.
any packets which are not explicitly permitted should not be
accepted.
Security identifiers
- CCE-27317-7
References
- 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>.
- 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.1.c. Verify iptables Enabled
The iptables
service can be enabled with the following command:
# chkconfig --level 2345 iptables on
The iptables
service provides the system's host-based firewalling
capability for IPv4 and ICMP.
Remediation script
#
# Enable iptables for all run levels
#
chkconfig --level 0123456 iptables on
#
# Start iptables if not currently running
#
service iptables start
Security identifiers
- CCE-27018-1
References
- AC-4. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- CA-3(c). 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>.
- 32. URL: <http://iase.disa.mil/cci/index.html>.
- 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>.
- 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-26444-0
References
- 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>.
- 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-27186-6
References
- CM-7. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1109. URL: <http://iase.disa.mil/cci/index.html>.
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 INPUT -p icmp --icmp-type any -j ACCEPT
and insert the lines:
-A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
-A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
-A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
To allow the system to respond to pings, also insert the following line:
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT
Ping responses can also be limited to certain networks or hosts by using the -s
option in the previous rule. Because IPv6 depends so heavily on ICMPv6, it is
preferable to deny the ICMPv6 packets you know you don't need (e.g. ping
requests) in /etc/sysconfig/ip6tables
, while letting everything else
through:
-A INPUT -p icmpv6 --icmpv6-type echo-request -j DROP
If you are going to statically configure the machine's address, it should
ignore Router Advertisements which could add another IPv6 address to the
interface or alter important network settings:
-A INPUT -p icmpv6 --icmpv6-type router-advertisement -j DROP
Restricting ICMPv6 message types in /etc/sysconfig/ip6tables
is not
recommended because the operation of IPv6 depends heavily on ICMPv6. Thus, great
care must be taken if any other ICMPv6 types are blocked.
Restricting ICMP messages may make a system slightly less discoverable to an unsophisticated attacker but is not appropriate for many general-purpose use cases and can also make troubleshooting more difficult.
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 -s 10.0.0.0/8 -j LOG --log-prefix "IP DROP SPOOF A: "
-A INPUT -s 172.16.0.0/12 -j LOG --log-prefix "IP DROP SPOOF B: "
-A INPUT -s 192.168.0.0/16 -j LOG --log-prefix "IP DROP SPOOF C: "
-A INPUT -s 224.0.0.0/4 -j LOG --log-prefix "IP DROP MULTICAST D: "
-A INPUT -s 240.0.0.0/5 -j LOG --log-prefix "IP DROP SPOOF E: "
-A INPUT -d 127.0.0.0/8 -j LOG --log-prefix "IP DROP LOOPBACK: "
Similarly, you might wish to log packets containing some IPv6 reserved addresses if they are not expected
on your network:
-A INPUT -i eth0 -s ::1 -j LOG --log-prefix "IPv6 DROP LOOPBACK: "
-A INPUT -s 2002:E000::/20 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
-A INPUT -s 2002:7F00::/24 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
-A INPUT -s 2002:0000::/24 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
-A INPUT -s 2002:FF00::/24 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
-A INPUT -s 2002:0A00::/24 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
-A INPUT -s 2002:AC10::/28 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
-A INPUT -s 2002:C0A8::/32 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
If you are not expecting to see site-local multicast or auto-tunneled traffic, you can log those:
-A INPUT -s FF05::/16 -j LOG --log-prefix "IPv6 SITE-LOCAL MULTICAST: "
-A INPUT -s ::0.0.0.0/96 -j LOG --log-prefix "IPv4 COMPATIBLE IPv6 ADDR: "
If you wish to block multicasts to all link-local nodes (e.g. if you are not using router auto-configuration and
do not plan to have any services that multicast to the entire local network), you can block the link-local
all-nodes multicast address (before accepting incoming ICMPv6):
-A INPUT -d FF02::1 -j LOG --log-prefix "Link-local All-Nodes Multicast: "
However, if you're going to allow IPv4 compatible IPv6 addresses (of the form ::0.0.0.0/96), you should
then consider logging the non-routable IPv4-compatible addresses:
-A INPUT -s ::0.0.0.0/104 -j LOG --log-prefix "IP NON-ROUTABLE ADDR: "
-A INPUT -s ::127.0.0.0/104 -j LOG --log-prefix "IP DROP LOOPBACK: "
-A INPUT -s ::224.0.0.0.0/100 -j LOG --log-prefix "IP DROP MULTICAST D: "
-A INPUT -s ::255.0.0.0/104 -j LOG --log-prefix "IP BROADCAST: "
If you are not expecting to see any IPv4 (or IPv4-compatible) traffic on your network, consider logging it before it gets dropped:
-A INPUT -s ::FFFF:0.0.0.0/96 -j LOG --log-prefix "IPv4 MAPPED IPv6 ADDR: "
-A INPUT -s 2002::/16 -j LOG --log-prefix "IPv6 6to4 ADDR: "
The following rule will log all traffic originating from a site-local address, which is deprecated address space:
-A INPUT -s FEC0::/10 -j LOG --log-prefix "SITE-LOCAL ADDRESS TRAFFIC: "
2.5.8. Transport Layer Security Support
Support for Transport Layer Security (TLS), and its predecessor, the Secure
Sockets Layer (SSL), is included in RHEL in the OpenSSL software (RPM package
openssl
). TLS provides encrypted and authenticated network
communications, and many network services include support for it. TLS or SSL
can be leveraged to avoid any plaintext transmission of sensitive data.
For information on how to use OpenSSL, see
http://www.openssl.org/docs/HOWTO/. Information on FIPS validation
of OpenSSL is available at http://www.openssl.org/docs/fips/fipsvalidation.html
and http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm.
2.5.9. Uncommon Network Protocols
The system includes support for several network protocols which are not commonly used. Although security vulnerabilities in kernel networking code are not frequently discovered, the consequences can be dramatic. Ensuring uncommon network protocols are disabled reduces the system's risk to attacks targeted at its implementation of those protocols.
Although these protocols are not commonly used, avoid disruption in your network environment by ensuring they are not needed prior to disabling them.
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/false
Disabling DCCP protects the system against exploitation of any flaws in its implementation.
Remediation script
echo "install dccp /bin/false" > /etc/modprobe.d/dccp.conf
Security identifiers
- CCE-26448-1
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/false
Disabling SCTP protects the system against exploitation of any flaws in its implementation.
Remediation script
echo "install sctp /bin/false" > /etc/modprobe.d/sctp.conf
Security identifiers
- CCE-26410-1
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/false
Disabling RDS protects the system against exploitation of any flaws in its implementation.
Remediation script
echo "install rds /bin/false" > /etc/modprobe.d/rds.conf
Security identifiers
- CCE-26239-4
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/false
Disabling TIPC protects the system against exploitation of any flaws in its implementation.
Remediation script
echo "install tipc /bin/false" > /etc/modprobe.d/tipc.conf
Security identifiers
- CCE-26696-5
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.
Remediation script
yum -y install openswan
Security identifiers
- CCE-27626-1
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>.
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.
Remediation script
yum -y install rsyslog
Security identifiers
- CCE-26809-4
References
- AU-9(2). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1311. URL: <http://iase.disa.mil/cci/index.html>.
- 1312. URL: <http://iase.disa.mil/cci/index.html>.
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 --level 2345 rsyslog on
The rsyslog
service must be running in order to provide
logging services, which are essential to system administration.
Remediation script
#
# Enable rsyslog for all run levels
#
chkconfig --level 0123456 rsyslog on
#
# Start rsyslog if not currently running
#
service rsyslog start
Security identifiers
- CCE-26807-8
References
- AU-12. 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.
Security identifiers
- CCE-27162-7
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 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
and typically all appear in /var/log
.
For each log file LOGFILE referenced in /etc/rsyslog.conf
,
run the following command to inspect the file's owner:
$ ls -l LOGFILE
If the owner is not root
, run the following command to
correct this:
# chown root LOGFILE
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-26812-8
References
- AC-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1314. URL: <http://iase.disa.mil/cci/index.html>.
2.6.4.b. 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-26821-9
References
- AC-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 1314. URL: <http://iase.disa.mil/cci/index.html>.
2.6.4.c. 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 configuration. If the system log files are not protected unauthorized users could change the logged data, eliminating their forensic value.
Security identifiers
- CCE-27190-8
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-26801-1
References
- AU-3(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>.
2.6.6. Configure rsyslogd to Accept Remote Messages If Acting as a Log Server
By default, rsyslog
does not listen over the network
for log messages. If needed, modules can be enabled to allow
the rsyslog daemon to receive messages from other systems and for the system
thus to act as a log server.
If the machine is not a log server, then lines concerning these modules
should remain commented out.
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
$InputTCPServerRun port
$ModLoad imudp
$UDPServerRun port
$ModLoad imrelp
$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-26803-7
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
$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-27235-1
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
$UDPServerRun 514
Many devices, such as switches, routers, and other Unix-like systems, may only support the traditional syslog transmission over UDP. If the system must act as a log server, this enables it to receive their messages as well.
Security identifiers
- CCE-27236-9
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
utility allows for the automatic rotation of
log files. The frequency of rotation is specified in /etc/logrotate.conf
,
which triggers a cron task. To configure logrotate to run daily, add or correct
the following line in /etc/logrotate.conf
:
# rotate log files frequency
daily
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-27014-0
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-27197-3
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-27069-4
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"
.
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 --level 2345 auditd on
Ensuring the auditd
service is active ensures
audit records generated by the kernel can be written to disk, or that appropriate
actions will be taken if other obstacles exist.
Remediation script
#
# Enable auditd for all run levels
#
chkconfig --level 0123456 auditd on
#
# Start auditd if not currently running
#
service auditd start
Security identifiers
- CCE-27058-7
References
- AC-17(1). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-10. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-12(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-12(c). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IR-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 347. URL: <http://iase.disa.mil/cci/index.html>.
- 157. URL: <http://iase.disa.mil/cci/index.html>.
- 172. URL: <http://iase.disa.mil/cci/index.html>.
- 880. 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>.
- 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>.
- 120. URL: <http://iase.disa.mil/cci/index.html>.
- 1589. URL: <http://iase.disa.mil/cci/index.html>.
2.7.b. Enable Auditing for Processes Which Start Prior to the Audit Daemon
To ensure all processes can be audited, even
those which start prior to the audit daemon, add the argument
audit=1
to the 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 it is set for every
process during boot.
Security identifiers
- CCE-26785-6
References
- AC-17(1). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- AU-10. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IR-5. 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
insufficient. The log file size needed will depend heavily on what types
of events are being audited. First configure auditing to log all the events of
interest. Then monitor the log size manually for awhile to determine what file
size will allow you to keep the required data for the correct time period.
Using a dedicated partition for /var/log/audit
prevents the
auditd
logs from disrupting system functionality if they fill, and,
more importantly, prevents other activity in /var
from filling the
partition and stopping the audit trail. (The audit logs are size-limited and
therefore unlikely to grow without bound unless configured to do so.) Some
machines may have requirements that no actions occur which cannot be audited.
If this is the case, then auditd
can be configured to halt the machine
if it runs out of space. Note: Since older logs are rotated,
configuring auditd
this way does not prevent older logs from being
rotated away before they can be viewed.
If your system is configured to halt when logging cannot be performed, make
sure this can never happen under normal circumstances! Ensure that
/var/log/audit
is on its own partition, and that this partition is
larger than the maximum amount of data auditd
will retain
normally.
References
- AU-11. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 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 maximum log file size and the number of logs retained.
Security identifiers
- CCE-27522-2
References
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 maximum log file size and the number of logs retained.
Security identifiers
- CCE-27550-3
References
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 in /etc/audit/auditd.conf
:
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.
Security identifiers
- CCE-27237-7
References
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-4. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-11. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IR-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
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. Acceptable values
also include suspend
, single
, and halt
.
Notifying administrators of an impending disk space problem may allow them to take corrective action prior to any disruption.
Security identifiers
- CCE-27238-5
References
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-4. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-5(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IR-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 140. URL: <http://iase.disa.mil/cci/index.html>.
- 143. 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
Set this value to single
to cause the system to switch to single user
mode for corrective action. Acceptable values also include suspend
and
halt
. For certain systems, the need for availability
outweighs the need to log all actions, and a different setting should be
determined. Details regarding all possible values for ACTION are described in the
auditd.conf
man page.
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.
Remediation script
var_auditd_admin_space_left_action="single"
grep -q ^admin_space_left_action /etc/audit/auditd.conf && \
sed -i "s/admin_space_left_action.*/admin_space_left_action = $var_auditd_admin_space_left_action/g" /etc/audit/auditd.conf
if ! [ $? -eq 0 ]; then
echo "admin_space_left_action = $var_auditd_admin_space_left_action" >> /etc/audit/auditd.conf
fi
Security identifiers
- CCE-27239-3
References
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-4. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-5(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IR-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 140. 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.
Security identifiers
- CCE-27241-9
References
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-4. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-5(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IR-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 139. URL: <http://iase.disa.mil/cci/index.html>.
- 144. URL: <http://iase.disa.mil/cci/index.html>.
2.7.3.g. Configure auditd to use audispd plugin
To configure the auditd
service to use the
audispd
plugin, set the active
line in
/etc/audisp/plugins.d/syslog.conf
to yes
.
Restart the auditd
service:
# service auditd restart
The auditd service does not include the ability to send audit records to a centralized server for management directly. It does, however, include an audit event multiplexor plugin (audispd) to pass audit records to the local syslog server
Security identifiers
- CCE-26933-2
References
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-3(2). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IR-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 136. 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
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-26664-3
References
- AC-2(4). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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 always,exit -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-26648-6
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
2.7.4.c. System Audit Logs Must Have Mode 0640 or Less Permissive
Change the mode of the audit log files with the following command:
# chmod 0640 audit_file
If users can write to audit logs, audit trails can be modified or destroyed.
Security identifiers
- CCE-27243-5
References
- AC-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). 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>.
- IR-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 166. URL: <http://iase.disa.mil/cci/index.html>.
2.7.4.d. System Audit Logs Must Be Owned By Root
To properly set the owner of /var/log
, run the command:
# chown root/var/log
Failure to give ownership of the audit log files to root allows the designated owner, and unauthorized users, potential access to sensitive information.
Security identifiers
- CCE-27244-3
References
- AC-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). 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>.
- IR-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 166. URL: <http://iase.disa.mil/cci/index.html>.
2.7.4.e. 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-26657-7
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
2.7.4.f. 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-26691-6
References
2.7.4.g. 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-26610-6
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
2.7.4.h. 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-26712-0
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.i. 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 / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null
Then, for each setuid program on the system, add a line of the following form to
/etc/audit/audit.rules
, where SETUID_PROG_PATH is the full path to each setuid program
in the list:
-a always,exit -F path=SETUID_PROG_PATH -F perm=x -F auid>=500 -F auid!=4294967295 -k privileged
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-26457-2
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- AU-2(4). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- IR-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 40. URL: <http://iase.disa.mil/cci/index.html>.
2.7.4.j. 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-26573-6
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.k. 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 rmdir -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-26651-0
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.l. 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-26662-7
References
- AC-2(7)(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.m. 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, setting ARCH to either b32 or b64 as appropriate for your system:
-w /sbin/insmod -p x -k modules
-w /sbin/rmmod -p x -k modules
-w /sbin/modprobe -p x -k modules
-a always,exit -F arch=ARCH -S init_module -S delete_module -k modules
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-26611-4
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.n. 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 accidental 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-26612-2
References
- AC-6. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
2.7.4.15. Records Events that Modify Date and Time Information
Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time. All changes to the system time should be audited.
link | previous | next | up | toc | home
2.7.4.15.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 activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.
Security identifiers
- CCE-26242-8
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.15.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 activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.
Security identifiers
- CCE-27203-9
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.15.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 stime" 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 activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.
Security identifiers
- CCE-27169-2
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.15.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 activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.
Security identifiers
- CCE-27170-0
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.15.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 activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time (such as sshd). All changes to the system time should be audited.
Security identifiers
- CCE-27172-6
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.16. 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 achieving the desired effect. An example of this is that the "-S" calls
could be split up and placed on separate lines, however, this is less efficient.
Add the following to /etc/audit/audit.rules
:
-a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod
If your system is 64 bit then these lines should be duplicated and the
arch=b32 replaced with arch=b64 as follows:
-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.
link | previous | next | up | toc | home
2.7.4.16.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 achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.
Security identifiers
- CCE-26280-8
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.16.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 achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.
Security identifiers
- CCE-27173-4
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.16.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 achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.
Security identifiers
- CCE-27174-2
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.16.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 achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.
Security identifiers
- CCE-27175-9
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.16.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 achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.
Security identifiers
- CCE-27177-5
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.16.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 achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.
Security identifiers
- CCE-27178-3
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.16.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 achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.
Security identifiers
- CCE-27179-1
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.16.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 achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.
Security identifiers
- CCE-27180-9
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.16.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 achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.
Security identifiers
- CCE-27181-7
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.16.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 achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.
Security identifiers
- CCE-27182-5
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.16.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 achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.
Security identifiers
- CCE-27183-3
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.16.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 achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.
Security identifiers
- CCE-27184-1
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. 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.16.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 achieving the desired effect. Here the system calls have been placed independent of other system calls. Grouping these system calls with others as identifying earlier in this guide is more efficient.
The changing of file permissions could indicate that a user is attempting to gain access to information that would otherwise be disallowed. Auditing DAC modifications can facilitate the identification of patterns of abuse among both authorized and unauthorized users.
Security identifiers
- CCE-27185-8
References
- AC-17(7). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-1(b). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(a). URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- AU-2(c). 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>.
- IR-5. URL: <http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final.pdf>.
- 126. URL: <http://iase.disa.mil/cci/index.html>.
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 6 installs on a system and disable software which is not needed. It
then enumerates the software packages installed on a default RHEL 6 system and provides guidance about which
ones can be safely disabled.
RHEL 6 provides a convenient minimal install option that essentially installs the bare necessities for a functional
system. When building RHEL 6 servers, it is highly recommended to select the minimal packages and then build up
the system from there.
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 Certmonger Service (certmonger)
- 3.2.d. Disable Control Group Config (cgconfig)
- 3.2.e. Disable Control Group Rules Engine (cgred)
- 3.2.f. Disable CPU Speed (cpuspeed)
- 3.2.g. Disable Hardware Abstraction Layer Service (haldaemon)
- 3.2.h. Enable IRQ Balance (irqbalance)
- 3.2.i. Disable KDump Kernel Crash Analyzer (kdump)
- 3.2.j. Disable Software RAID Monitor (mdmonitor)
- 3.2.k. Disable D-Bus IPC Service (messagebus)
- 3.2.l. Disable Network Console (netconsole)
- 3.2.m. Disable ntpdate Service (ntpdate)
- 3.2.n. Disable Odd Job Daemon (oddjobd)
- 3.2.o. Disable Portreserve (portreserve)
- 3.2.p. Enable Process Accounting (psacct)
- 3.2.q. Disable Apache Qpid (qpidd)
- 3.2.r. Disable Quota Netlink (quota_nld)
- 3.2.s. Disable Network Router Discovery Daemon (rdisc)
- 3.2.t. Disable Red Hat Network Service (rhnsd)
- 3.2.u. Disable Red Hat Subscription Manager Daemon (rhsmcertd)
- 3.2.v. Disable Cyrus SASL Authentication Daemon (saslauthd)
- 3.2.w. Disable SMART Disk Monitoring Service (smartd)
- 3.2.x. 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 Service
- 3.10.b. Uninstall Sendmail Package
- 3.10.3. Configure SMTP For Mail Clients
- 3.10.4. Configure Operating System to Protect Mail Server
- 3.11. 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.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.18. Proxy Server
- 3.19. SNMP Server
link | previous | next | up | toc | home
3.1. Obsolete Services
This section discusses a number o