Guide to the Secure Configuration of Red Hat Enterprise Linux 5
https://www.open-scap.org/security-policies/scap-security-guide
scap-security-guide
package which is developed at
https://www.open-scap.org/security-policies/scap-security-guide.
Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG for Red Hat Enterprise Linux 5, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.
Profile ID | (default) |
---|
Revision History
Current version: 0.1.31
- draft (as of 2017-08-11)
Platforms
- cpe:/o:redhat:enterprise_linux:4
- cpe:/o:redhat:enterprise_linux:5
Table of Contents
- Remediation functions used by the SCAP Security Guide Project
- Introduction
- System Settings
- Installing and Maintaining Software
- File Permissions and Masks
- SELinux
- Account and Access Control
- Network Configuration and Firewalls
- Configure Syslog
- System Accounting with auditd
- Services
- Obsolete Services
- Base Services
- Cron and At Daemons
- SSH Server
- X Window System
- DHCP
- Network Time Protocol
- Mail Server Software
- LDAP
- NFS and RPC
- FTP Server
- Samba(SMB) Microsoft Windows File Sharing Server
- SNMP Server
- Documentation to Support DISA OS SRG Mapping
Checklist
Remediation functions used by the SCAP Security Guide Project [ref]groupXCCDF form of the various remediation functions as used by remediation scripts from the SCAP Security Guide Project |
Introduction [ref]groupThe purpose of this guidance is to provide security configuration recommendations and baselines for the Red Hat Enterprise Linux 5 operating system. 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 the product'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. |
General Principles [ref]groupThe following general principles motivate much of the advice in this guide and should also influence any configuration decisions that are not explicitly covered. |
Encrypt Transmitted Data Whenever Possible [ref]groupData 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 Red Hat Enterprise Linux 5 machines can and should be configured so that no unencrypted authentication data is ever transmitted between machines. |
Minimize Software to Minimize Vulnerability [ref]groupThe simplest way to avoid vulnerabilities in software is to avoid installing that software. On Red Hat Enterprise Linux 5, 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. |
Run Different Network Services on Separate Systems [ref]groupWhenever 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. |
Configure Security Tools to Improve System Robustness [ref]groupSeveral 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 host-based firewalling, SELinux for protection against vulnerable services, and a logging and auditing infrastructure for detection of problems. |
Least Privilege [ref]group
Grant the least privilege necessary for user accounts and software to perform tasks.
For example, |
How to Use This Guide [ref]groupReaders should heed the following points when using the guide. |
Read Sections Completely and in Order [ref]groupEach 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. |
Test in Non-Production Environment [ref]groupThis 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. |
Root Shell Environment Assumed [ref]group
Most of the actions listed in this document are written with the
assumption that they will be executed by the root user running the
|
Formatting Conventions [ref]group
Commands intended for shell execution, as well as configuration file text,
are featured in a |
Reboot Required [ref]groupA 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. |
System Settings [ref]groupContains rules that check correct system settings. |
Installing and Maintaining Software [ref]groupThe following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates. |
Disk Partitioning [ref]groupTo 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
|
Updating Software [ref]groupThe |
Software Integrity Checking [ref]group
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.
|
Verify Integrity with AIDE [ref]groupAIDE 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 |
Verify Integrity with RPM [ref]groupThe 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 -qVaSee the man page for rpm to see a complete explanation of each column.
|
Additional Security Software [ref]groupAdditional 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. |
File Permissions and Masks [ref]groupTraditional 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.
$ mount -t xfs | awk '{print $3}'For any systems that use a different local filesystem type, modify this command as appropriate. |
Restrict Partition Mount Options [ref]groupSystem partitions can be mounted with certain options
that limit what files on those partitions can do. These options
are set in the |
Restrict Dynamic Mounting and Unmounting of Filesystems [ref]groupLinux 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.
# 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 .
|
Verify Permissions on Important Files and Directories [ref]groupPermissions 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. |
Verify Permissions on Files with Local Account Information and Credentials [ref]groupThe default restrictive permissions for files which act as
important security databases such as |
Verify File Permissions Within Some Important Directories [ref]groupSome 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. |
Restrict Programs from Dangerous Execution Patterns [ref]groupThe 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. |
Disable Core Dumps [ref]groupA 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.
|
Enable ExecShield [ref]groupExecShield 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 |
SELinux [ref]groupSELinux 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.
|
Enable SELinux [ref]groupEdit the file SELINUX=enforcing SELINUXTYPE=targetedEdit the file /etc/grub.conf . Ensure that the following
arguments DO NOT appear on any kernel command line in the file:
selinux=0 enforcing=0The directive SELINUX=enforcing enables SELinux at boot time.
If SELinux is suspected of involvement with boot-time problems
(unlikely), it is possible to boot into the warning-only mode
SELINUX=permissive for debugging purposes. Make certain to change
the mode back to enforcing after debugging, set the filesystems to
be relabeled for consistency using the command touch
/.autorelabel , and reboot.
However, the Red Hat Enterprise Linux 6 default SELinux configuration should be sufficiently reasonable that most systems will boot without serious problems. Some applications that require deep or unusual system privileges, such as virtual machine software, may not be compatible with SELinux in its default configuration. However, this should be uncommon, and SELinux's application support continues to improve. In other cases, SELinux may reveal unusual or insecure program behavior by design. The directive SELINUXTYPE=targeted configures SELinux to use
the default targeted policy.
The SELinux boot mode specified in /etc/selinux/config can be
overridden by command-line arguments passed to the kernel. It is
necessary to check grub.conf to ensure that this has not been done
and to protect the boot process.
|
Account and Access Control [ref]groupIn 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 Red Hat Enterprise Linux 5. |
Special Privileged Accounts Exist [ref]groupThe system must not have special
privilege accounts, such as |
Protect Accounts by Restricting Password-Based Login [ref]groupConventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the |
Restrict Root Logins [ref]group
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 |
Verify Proper Storage and Existence of Password Hashes [ref]group
By default, password hashes for local accounts are stored
in the second field (colon-separated) in
|
Set Password Expiration Parameters [ref]groupThe file # chage -M 180 -m 7 -W 7 USER |
Set Account Expiration Parameters [ref]groupAccounts 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 # chage -I NUM_DAYS USERAccounts, 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.
|
Protect Accounts by Configuring PAM [ref]groupPAM, 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.
Warning:
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. Warning:
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. |
Set Password Quality Requirements [ref]groupThe default |
Set Password Quality Requirements, if using pam_cracklib [ref]groupThe password requisite pam_cracklib.so try_first_pass retry=3and 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=4If 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.
Warning:
Note that the password quality
requirements are not enforced for the root account for some
reason. |
Set Authentication Failure Actions [ref]groupThe system should be configured to handle authentication failures so that password cracking attempts are mitigated. Warning:
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. |
Set Password Hashing Algorithm [ref]groupThe system's default algorithm for storing password hashes in
|
Secure Session Configuration Files for Login Accounts [ref]groupWhen 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. |
Ensure that No Dangerous Directories Exist in Root's Path [ref]groupThe active path of the root account can be obtained by starting a new root shell and running: # echo $PATHThis will produce a colon-separated list of directories in the path. Certain path elements could be considered dangerous, as they could lead to root executing unknown or untrusted programs, which could contain malicious code. Since root may sometimes work inside untrusted directories, the . character, which represents the
current directory, should never be in the root path, nor should any
directory which can be written to by an unprivileged or
semi-privileged (system) user.
It is a good practice for administrators to always execute privileged commands by typing the full path to the command. |
Ensure that Users Have Sensible Umask Values [ref]group
The umask setting controls the default permissions
for the creation of new files.
With a default |
Protect Physical Console Access [ref]groupIt 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. |
Set Boot Loader Password [ref]groupDuring 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 Red Hat Enterprise Linux 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. |
Configure Screen Locking [ref]groupWhen 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.
|
Configure GUI Screen Locking [ref]groupIn the default GNOME desktop, the screen can be locked
by choosing Lock Screen from the System menu.
|
Configure Console Screen Locking [ref]group
A console screen locking mechanism is provided in the
|
Hardware Tokens for Authentication [ref]groupThe 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. |
Warning Banners for System Accesses [ref]groupEach system should expose as little information about
itself as possible.
|
Implement a GUI Warning Banner [ref]groupIn 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. |
Network Configuration and Firewalls [ref]groupMost 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.
|
Disable Unused Interfaces [ref]groupNetwork interfaces expand the attack surface of the
system. Unused interfaces are not monitored or controlled, and
should be disabled.
# rm /etc/sysconfig/network-scripts/ifcfg-interfaceIf 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:
$ sudo chkconfig network off |
Restrict Access to Network Configuration Changes [ref]groupThe network configuration should only be allowed to be modified by authorized users. |
Kernel Parameters Which Affect Networking [ref]groupThe |
Network Parameters for Hosts Only [ref]groupIf 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. |
Network Related Kernel Runtime Parameters for Hosts and Routers [ref]groupCertain 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. |
Wireless Networking [ref]groupWireless 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.
|
Disable Wireless Through Software Configuration [ref]groupIf 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. |
IPv6 [ref]groupThe 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. |
Disable Support for IPv6 Unless Needed [ref]groupDespite 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. |
Configure IPv6 Settings if Necessary [ref]groupA major feature of IPv6 is the extent to which systems implementing it can automatically configure their networking devices using information from the network. From a security perspective, manually configuring important configuration information is preferable to accepting it from the network in an unauthenticated fashion. |
Disable Automatic Configuration [ref]groupDisable the system's acceptance of router
advertisements and redirects by adding or correcting the following
line in IPV6_AUTOCONF=no |
iptables and ip6tables [ref]groupA 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.
|
Inspect and Activate Default Rules [ref]groupView the currently-enforced iptables rules by running the command: # iptables -nL --line-numbersThe 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 restartThe 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 destinationThe ip6tables default rules are essentially the same. |
Strengthen the Default Ruleset [ref]groupThe 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
Warning:
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. |
Transport Layer Security Support [ref]group
Support for Transport Layer Security (TLS), and its predecessor, the Secure
Sockets Layer (SSL), is included in Red Hat Enterprise Linux in the OpenSSL software (RPM package
|
IP Tunnelling Support [ref]groupSupport for creating IP encapsulated tunnels between a system and remote endpoints, to also include tunnelling ipv6 over ipv4, is available in Red Hat. |
Uncommon Network Protocols [ref]groupThe 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. Warning:
Although these protocols are not commonly used, avoid disruption
in your network environment by ensuring they are not needed
prior to disabling them.
|
Configure Syslog [ref]groupThe 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. |
Ensure All Logs are Rotated by logrotate [ref]groupEdit the file /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/syslog.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. |
System Accounting with auditd [ref]groupThe 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, 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)
|
Configure auditd Data Retention [ref]group
The audit system writes data to |
Configure auditd Rules for Comprehensive Auditing [ref]groupThe
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 |
Records Events that Modify Date and Time Information [ref]groupArbitrary 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. |
Record Events that Modify the System's Discretionary Access Controls [ref]groupAt 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 -a exit,always -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod -a exit,always -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod -a exit,always -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_modIf your system is 64 bit then these lines should be duplicated and the arch=b32 replaced with arch=b64 as follows: -a exit,always -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=500 -F auid!=4294967295 -k perm_mod -a exit,always -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=500 -F auid!=4294967295 -k perm_mod -a exit,always -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=500 -F auid!=4294967295 -k perm_mod |
Services [ref]group
The best protection against vulnerable software is running less software. This section describes how to review
the software which Red Hat Enterprise Linux 5 installs on a system and disable software which is not needed. It
then enumerates the software packages installed on a default Red Hat Enterprise Linux 5 system and provides guidance about which
ones can be safely disabled.
|
Obsolete Services [ref]groupThis section discusses a number of network-visible
services which have historically caused problems for system
security, and for which disabling or severely limiting the service
has been the best available guidance for some time. As a result of
this, many of these services are not installed as part of Red Hat Enterprise Linux 6
by default.
|
Xinetd [ref]groupThe |
Telnet [ref]groupThe telnet protocol does not provide confidentiality or integrity for information transmitted on the network. This includes authentication information such as passwords. Organizations which use telnet should be actively working to migrate to a more secure protocol. |
Rlogin, Rsh, and Rexec [ref]groupThe Berkeley r-commands are legacy services which allow cleartext remote access and have an insecure trust model. |
NIS [ref]groupThe Network Information Service (NIS), also known as 'Yellow Pages' (YP), and its successor NIS+ have been made obsolete by Kerberos, LDAP, and other modern centralized authentication services. NIS should not be used because it suffers from security problems inherent in its design, such as inadequate protection of important authentication information. |
TFTP Server [ref]groupTFTP is a lightweight version of the FTP protocol which has traditionally been used to configure networking equipment. However, TFTP provides little security, and modern versions of networking operating systems frequently support configuration via SSH or other more secure protocols. A TFTP server should be run only if no more secure method of supporting existing equipment can be found. |
Base Services [ref]groupThis section addresses the base services that are installed on a Red Hat Enterprise Linux 6 default installation which are not covered in other sections. Some of these services listen on the network and should be treated with particular discretion. Other services are local system utilities that may or may not be extraneous. In general, system services should be disabled if not required. |
Cron and At Daemons [ref]groupThe cron and at services are used to allow commands to be executed at a later time. The cron service is required by almost all systems to perform necessary maintenance tasks, while at may or may not be required on a given system. Both daemons should be configured defensively. |
Restrict cron to Authorized Users if Necessary [ref]group
The
|
Restrict at to Authorized Users if Necessary [ref]group
The
|
SSH Server [ref]groupThe SSH protocol is recommended for remote login and
remote file transfer. SSH provides confidentiality and integrity
for data exchanged between two systems, as well as server
authentication, through the use of public key cryptography. The
implementation included with the system is called OpenSSH, and more
detailed documentation is available from its website,
http://www.openssh.org. Its server program is called |
Configure OpenSSH Server if Necessary [ref]groupIf the system needs to act as an SSH server, then
certain changes should be made to the OpenSSH daemon configuration
file |
Strengthen Firewall Configuration if Possible [ref]groupIf the SSH server is expected to only receive connections from
the local network, then strengthen the default firewall rule for the SSH service
to only accept connections from the appropriate network segment(s).
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPTand replace it with: -A INPUT -s netwk/mask -m state --state NEW -p tcp --dport 22 -j ACCEPT |
Configure OpenSSH Client if Necessary [ref]groupIf the system needs to utilize the SSH client, then
certain changes should be made to the OpenSSH client configuration
file |
X Window System [ref]groupThe X Window System implementation included with the system is called X.org. |
Disable X Windows [ref]groupUnless there is a mission-critical reason for the system to run a graphical user interface, ensure X is not set to start automatically at boot and remove the X Windows software packages. There is usually no reason to run X Windows on a dedicated server machine, as it increases the system's attack surface and consumes system resources. Administrators of server systems should instead login via SSH or on the text console. |
DHCP [ref]groupThe Dynamic Host Configuration Protocol (DHCP) allows
systems to request and obtain an IP address and other configuration
parameters from a server.
|
Disable DHCP Client [ref]groupDHCP is the default network configuration method provided by the system installer, and common on many networks. Nevertheless, manual management of IP addresses for systems implies a greater degree of management and accountability for network activity. |
Configure DHCP Client if Necessary [ref]groupIf DHCP must be used, then certain configuration changes can
minimize the amount of information it receives and applies from the network,
and thus the amount of incorrect information a rogue DHCP server could
successfully distribute. For more information on configuring dhclient, see the
|
Network Time Protocol [ref]groupThe Network Time Protocol is used to manage the system
clock over a network. Computer clocks are not very accurate, so
time will drift unpredictably on unmanaged systems. Central time
protocols can be used both to ensure that time is consistent among
a network of machines, and that their time is consistent with the
outside world.
|
Mail Server Software [ref]group
Mail servers are used to send and receive email over the network.
Mail is a very common service, and Mail Transfer Agents (MTAs) are obvious
targets of network attack.
Ensure that machines are not running MTAs unnecessarily,
and configure needed MTAs as defensively as possible.
|
Mail Server Logging [ref]groupIt is important to ensure adequate logging of mail server connections so as to support detecting any unauthorized activity. |
Mail Server Features [ref]group
Mail servers are used to send and receive email over the network.
Mail is a very common service, and Mail Transfer Agents (MTAs) are obvious
targets of network attack.
Ensure that machines are not running MTAs unnecessarily,
and configure needed MTAs as defensively as possible.
|
LDAP [ref]groupLDAP is a popular directory service, that is, a standardized way of looking up information from a central database. Red Hat Enterprise Linux 5 includes software that enables a system to act as both an LDAP client and server. |
Configure OpenLDAP Clients [ref]groupThis section provides information on which security settings are
important to configure in OpenLDAP clients by manually editing the appropriate
configuration files. Red Hat Enterprise Linux 5 provides an automated configuration tool called
authconfig and a graphical wrapper for authconfig called
Warning:
Before configuring any system to be an
LDAP client, ensure that a working LDAP server is present on the
network. |
NFS and RPC [ref]groupThe Network File System is a popular distributed filesystem for the Unix environment, and is very widely deployed. This section discusses the circumstances under which it is possible to disable NFS and its dependencies, and then details steps which should be taken to secure NFS's configuration. This section is relevant to machines operating as NFS clients, as well as to those operating as NFS servers. |
Disable All NFS Services if Possible [ref]groupIf there is not a reason for the system to operate as either an NFS client or an NFS server, follow all instructions in this section to disable subsystems required by NFS. Warning:
The steps in this section will prevent a machine
from operating as either an NFS client or an NFS server. Only perform these
steps on machines which do not need NFS at all. |
Remove Services Used Only by NFS [ref]groupIf NFS is not needed, remove the NFS client daemons portmap and rpcbind.
|
Disable Services Used Only by NFS [ref]groupIf NFS is not needed, disable the NFS client daemons nfslock, rpcgssd, and rpcidmapd.
|
Configure All Machines which Use NFS [ref]groupThe steps in this section are appropriate for all machines which run NFS, whether they operate as clients or as servers. |
Configure NFS Clients [ref]groupThe steps in this section are appropriate for machines which operate as NFS clients. |
Configure NFS Servers [ref]groupThe steps in this section are appropriate for machines which operate as NFS servers. |
FTP Server [ref]groupFTP is a common method for allowing remote access to
files. Like telnet, the FTP protocol is unencrypted, which means
that passwords and other data transmitted during the session can be
captured and that the session is vulnerable to hijacking.
Therefore, running the FTP server software is not recommended.
|
Samba(SMB) Microsoft Windows File Sharing Server [ref]groupWhen properly configured, the Samba service allows
Linux machines to provide file and print sharing to Microsoft
Windows machines. There are two software packages that provide
Samba support. The first, |
Remove Samba if Possible [ref]groupThe Samba server must not be installed unless it provides an operational need. |
Configure Samba if Necessary [ref]groupAll settings for the Samba daemon can be found in
|
SNMP Server [ref]groupThe Simple Network Management Protocol allows administrators to monitor the state of network devices, including computers. Older versions of SNMP were well-known for weak security, such as plaintext transmission of the community string (used for authentication) and usage of easily-guessable choices for the community string. |
Configure SNMP Server [ref]groupIf it is necessary to run the snmpd agent on the system, some best practices should be followed to minimize the security risk from the installation. The multiple security models implemented by SNMP cannot be fully covered here so only the following general configuration advice can be offered:
|
Documentation to Support DISA OS SRG Mapping [ref]groupThese groups exist to document how the Red Hat Enterprise Linux product meets (or does not meet) requirements listed in the DISA OS SRG, for those cases where Groups or Rules elsewhere in scap-security-guide do not clearly relate. |