Guide to the Secure Configuration of Red Hat Enterprise Linux 7
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 7, 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-03-13)
Platforms
- cpe:/o:redhat:enterprise_linux:7
- cpe:/o:redhat:enterprise_linux:7::client
- cpe:/o:redhat:enterprise_linux:7::computenode
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
- Docker Service
- SSH Server
- System Security Services Daemon
- X Window System
- Avahi Server
- Print Support
- DHCP
- Network Time Protocol
- Mail Server Software
- LDAP
- NFS and RPC
- DNS Server
- FTP Server
- Web Server
- IMAP and POP3 Server
- Network Routing
- Samba(SMB) Microsoft Windows File Sharing Server
- Proxy Server
- SNMP Server
- Documentation to Support C2S/CIS 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 7 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 7 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 7, 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 |
System and Software Integrity [ref]groupSystem and software integrity can be gained by installing antivirus, increasing system encryption strength with FIPS, verifying installed software, enabling SELinux, installing an Intrusion Prevention System, etc. However, installing or enabling integrity checking tools cannot prevent intrusions, but they can detect that an intrusion may have occurred. Requirements for 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. |
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.
|
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.
|
Endpoint Protection Software [ref]groupEndpoint protection 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. |
McAfee Endpoint Security Software [ref]groupIn DoD environments, McAfee Host-based Security System (HBSS) and VirusScan Enterprise for Linux (VSEL) is required to be installed on all systems. |
McAfee Host-Based Intrusion Detection Software (HBSS) [ref]groupMcAfee Host-based Security System (HBSS) is a suite of software applications used to monitor, detect, and defend computer networks and systems. |
Federal Information Processing Standard (FIPS) [ref]group
The Federal Information Processing Standard (FIPS) is a computer security standard which
is developed by the U.S. Government and industry working groups to validate the quality
of cryptographic modules. The FIPS standard provides four security levels to ensure
adequate coverage of different industries, implementation of cryptographic modules, and
organizational sizes and requirements.
|
Operating System Vendor Support and Certification [ref]groupThe assurance of a vendor to provide operating system support and maintenance for their product is an important criterion to ensure product stability and security over the life of the product. A certified product that follows the necessary standards and government certification requirements guarantees that known software vulnerabilities will be remediated, and proper guidance for protecting and securing the operating system will be given. |
GNOME Desktop Environment [ref]group
GNOME is a graphical desktop environment bundled with many Linux distributions that
allow users to easily interact with the operating system graphically rather than
textually. The GNOME Graphical Display Manager (GDM) provides login, logout, and user
switching contexts as well as display server management.
|
Configure GNOME Login Screen [ref]groupIn the default GNOME3 desktop, the login is displayed after system boot
and can display user accounts, allow users to reboot the system, and allow users to
login automatically and/or with a guest account. The login screen should be configured
to prevent such behavior.
|
Configure GNOME Screen Locking [ref]groupIn the default GNOME3 desktop, the screen can be locked
by selecting the user name in the far right corner of the main panel and
selecting Lock.
|
GNOME System Settings [ref]groupGNOME provides configuration and functionality to a graphical desktop environment that changes grahical configurations or allow a user to perform actions that users normally would not be able to do in non-graphical mode such as remote access configuration, power policies, Geo-location, etc. Configuring such settings in GNOME will prevent accidential graphical configuration changes by users from taking place. |
GNOME Network Settings [ref]groupGNOME network settings that apply to the graphical interface. |
GNOME Remote Access Settings [ref]groupGNOME remote access settings that apply to the graphical interface. |
GNOME Media Settings [ref]groupGNOME media settings that apply to the graphical interface. |
Sudo [ref]group
|
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. |
Daemon Umask [ref]groupThe 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. |
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
on 32-bit systems and controlled through |
Enable Execute Disable (XD) or No Execute (NX) Support on x86 Systems [ref]groupRecent 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. This is enabled by default on the latest Red Hat and Fedora systems if supported by the hardware. |
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.
|
SELinux - Booleans [ref]groupEnable or Disable runtime customization of SELinux system policies without having to reload or recompile the SELinux policy. |
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 7. |
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 $ sudo 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 $ sudo 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 with pam_pwquality [ref]groupThe password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth.
Next, modify the settings in /etc/security/pwquality.conf to match the following:
difok = 4 minlen = 14 dcredit = -1 ucredit = -1 lcredit = -1 ocredit = -1 maxrepeat = 3The 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 Lockouts for Failed Password Attempts [ref]groupThe 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 GRUB2. 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 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 and 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 GNOME3 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 systems 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.
$ sudo 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 systemctl disable network.service |
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
in 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 |
Limit Network-Transmitted Configuration if Using Static IPv6 Addresses [ref]groupTo 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
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 = 1The 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.
|
firewalld [ref]groupThe dynamic firewall daemon |
Inspect and Activate Default firewalld Rules [ref]groupFirewalls can be used to separate networks into different zones
based on the level of trust the user has decided to place on the devices and
traffic within that network.
It is possible to designate one of these zones to be the default zone. When interface connections are added to NetworkManager, they are assigned
to the default zone. On installation, the default zone in firewalld is set to
be the public zone.
To find out all the settings of a zone, for example the public zone,
enter the following command as root:
# firewall-cmd --zone=public --list-allExample output of this command might look like the following: # firewall-cmd --zone=public --list-all public interfaces: services: mdns dhcpv6-client ssh ports: forward-ports: icmp-blocks: source-quenchTo view the network zones currently active, enter the following command as root: # firewall-cmd --get-serviceThe following listing displays the result of this command on common Red Hat Enterprise Linux 7 Server system: # firewall-cmd --get-service amanda-client bacula bacula-client dhcp dhcpv6 dhcpv6-client dns ftp high-availability http https imaps ipp ipp-client ipsec kerberos kpasswd ldap ldaps libvirt libvirt-tls mdns mountd ms-wbt mysql nfs ntp openvpn pmcd pmproxy pmwebapi pmwebapis pop3s postgresql proxy-dhcp radius rpc-bind samba samba-client smtp ssh telnet tftp tftp-client transmission-client vnc-server wbem-httpsFinally to view the network zones that will be active after the next firewalld service reload, enter the following command as root: # firewall-cmd --get-service --permanent |
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 configuration files under the warning
The program firewall-config
allows additional services to penetrate the default firewall rules
and automatically adjusts the firewalld ruleset(s). |
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
|
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.
|
IPSec Support [ref]groupSupport for Internet Protocol Security (IPsec) is provided in Red Hat Enterprise Linux 7 with Libreswan. |
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 Proper Configuration of Log Files [ref]group
The file *.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.logSee 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 |
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/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. |
Configure Logwatch on the Central Log Server [ref]group
Is this system the central log server? If so, edit the file |
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, ExecStartPost=-/sbin/augenrules --loadin the /usr/lib/systemd/system/auditd.service configuration file.
In order to instruct the auditd daemon to use the auditctl
utility to read audit rules, use the following setting:
ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rulesin the /usr/lib/systemd/system/auditd.service configuration file.
Refer to [Service] section of the /usr/lib/systemd/system/auditd.service
configuration file for further details.
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
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/SELinux_Users_and_Administrators_Guide/sect-Security-Enhanced_Linux-Troubleshooting-Fixing_Problems.html#sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages
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)
|
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: $ sudo 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 always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
-a always,exit -F arch=b32 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
-a always,exit -F arch=b32 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=4294967295 -F key=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,fchmod,fchmodat -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
-a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
-a always,exit -F arch=b64 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=4294967295 -F key=perm_mod
|
Record Attempts to Alter Logon and Logout Events [ref]groupThe audit system already collects login information for all users
and root. If the -w /var/log/tallylog -p wa -k logins -w /var/run/faillock/ -p wa -k logins -w /var/log/lastlog -p wa -k loginsIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following lines to
/etc/audit/audit.rules file in order to watch for unattempted manual
edits of files involved in storing logon events:
-w /var/log/tallylog -p wa -k logins -w /var/run/faillock/ -p wa -k logins -w /var/log/lastlog -p wa -k logins |
Record Unauthorized Access Attempts Events to Files (unsuccessful) [ref]groupAt a minimum, the audit system should collect unauthorized file
accesses 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 always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -F key=access
-a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -F key=access
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 creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=4294967295 -F key=access
-a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=4294967295 -F key=access
|
Record Execution Attempts to Run SELinux Privileged Commands [ref]groupAt a minimum, the audit system should collect the execution of SELinux privileged commands for all users and root. |
Record Information on the Use of Privileged Commands [ref]groupAt a minimum, the audit system should collect the execution of privileged commands for all users and root. |
Record File Deletion Events by User [ref]groupAt a minimum, the audit system should collect file deletion events
for all users and root. If the -a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=4294967295 -F key=deleteIf the auditd daemon is configured to use the auditctl
utility to read audit rules during daemon startup, add the following line to
/etc/audit/audit.rules file, setting ARCH to either b32 or b64 as
appropriate for your system:
-a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=4294967295 -F key=delete |
Record Information on Kernel Modules Loading and Unloading [ref]groupIf the -w /usr/sbin/insmod -p x -k modules -w /usr/sbin/rmmod -p x -k modules -w /usr/sbin/modprobe -p x -k modules -a always,exit -F arch=ARCH -S init_module,delete_module -F key=modulesIf the auditd daemon is configured to use the auditctl utility to read audit
rules during daemon startup, add the following lines to /etc/audit/audit.rules file
in order to capture kernel module loading and unloading events, setting ARCH to either b32 or
b64 as appropriate for your system:
-w /usr/sbin/insmod -p x -k modules -w /usr/sbin/rmmod -p x -k modules -w /usr/sbin/modprobe -p x -k modules -a always,exit -F arch=ARCH -S init_module,delete_module -F key=modules |
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 7 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 7 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 7
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. |
Chat/Messaging Services [ref]groupThe talk software makes it possible for users to send and receive messages across systems through a terminal session. |
Base Services [ref]groupThis section addresses the base services that are installed on a Red Hat Enterprise Linux 7 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 at and cron to Authorized Users if Necessary [ref]group
The
|
Docker Service [ref]groupThe docker service is necessary to create containers, which are self-sufficient and self-contained applications using the resource isolation features of the kernel. |
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).
firewall-cmd --permanent --add-rich-rule='rule family="ip_protocol" source address="netwk/mask" service name="ssh" accept' |
System Security Services Daemon [ref]group
The System Security Services Daemon (SSSD) is a system daemon that provides access
to different identity and authentication providers such as Red Hat's IdM, Microsoft's AD,
openLDAP, MIT Kerberos, etc. It uses a common framework that can provide caching and offline
support to systems utilizing SSSD. SSSD using caching to reduce load on authentication
servers permit offline authentication as well as store extended user data.
|
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 system, 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. |
Avahi Server [ref]groupThe Avahi daemon implements the DNS Service Discovery and Multicast DNS protocols, which provide service and host discovery on a network. It allows a system to automatically identify resources on the network, such as printers or web servers. This capability is also known as mDNSresponder and is a major part of Zeroconf networking. |
Disable Avahi Server if Possible [ref]groupBecause the Avahi daemon service keeps an open network port, it is subject to network attacks. Disabling it can reduce the system's vulnerability to such attacks. |
Configure Avahi if Necessary [ref]group
If your system requires the Avahi daemon, its configuration can be restricted
to improve security. The Avahi daemon configuration file is
|
Print Support [ref]groupThe Common Unix Printing System (CUPS) service provides both local
and network printing support. A system running the CUPS service can accept
print jobs from other systems, process them, and send them to the appropriate
printer. It also provides an interface for remote administration through a web
browser. The CUPS service is installed and activated by default. The project
homepage and more detailed documentation are available at
http://www.cups.org.
|
Configure the CUPS Service if Necessary [ref]groupCUPS provides the ability to easily share local printers with other systems over the network. It does this by allowing systems to share lists of available printers. Additionally, each system that runs the CUPS service can potentially act as a print server. Whenever possible, the printer sharing and print server capabilities of CUPS should be limited or disabled. The following recommendations should demonstrate how to do just that. |
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 Server [ref]group
The DHCP server |
Disable DHCP Server [ref]groupIf the system must act as a DHCP server, the configuration
information it serves should be minimized. Also, support for other protocols
and DNS-updating schemes should be explicitly disabled unless needed. The
configuration file for dhcpd is called |
Minimize Served Information [ref]groupEdit /etc/dhcp/dhcpd.conf. Examine each address range section within the file, and ensure that the following options are not defined unless there is an operational need to provide this information via DHCP: option domain-name option domain-name-servers option nis-domain option nis-servers option ntp-servers option routers option time-offset warning
By default, the Red Hat Enterprise Linux client installation uses DHCP
to request much of the above information from the DHCP server. In particular,
domain-name, domain-name-servers, and routers are configured via DHCP. These
settings are typically necessary for proper network functionality, but are also
usually static across systems at a given site. references: CM-7 |
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
|
Minimize the DHCP-Configured Options [ref]groupCreate the file supersede
If the setting should be configured remotely by the DHCP server, add the lines:
requestFor example, suppose the DHCP server should provide only the IP address itself and the subnet mask. Then the entire file should look like: supersede domain-name "example.com"; supersede domain-name-servers 192.168.1.2; supersede nis-domain ""; supersede nis-servers ""; supersede ntp-servers "ntp.example.com "; supersede routers 192.168.1.1; supersede time-offset -18000; request subnet-mask; require subnet-mask; warning
In this example, the options nis-servers and
nis-domain are set to empty strings, on the assumption that the deprecated NIS
protocol is not in use. It is necessary to supersede settings for unused
services so that they cannot be set by a hostile DHCP server. If an option is
set to an empty string, dhclient will typically not attempt to configure the
service. |
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 systems, 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 systems are not running MTAs unnecessarily,
and configure needed MTAs as defensively as possible.
|
Configure SMTP For Mail Clients [ref]groupThis section discusses settings for Postfix in a submission-only e-mail configuration. |
Configure Operating System to Protect Mail Server [ref]groupThe guidance in this section is appropriate for any host which is operating as a site MTA, whether the mail server runs using Sendmail, Postfix, or some other software. |
Configure SSL Certificates for Use with SMTP AUTH [ref]groupIf SMTP AUTH is to be used, the use of SSL to protect credentials in transit is strongly recommended. There are also configurations for which it may be desirable to encrypt all mail in transit from one MTA to another, though such configurations are beyond the scope of this guide. In either event, the steps for creating and installing an SSL certificate are independent of the MTA in use, and are described here. |
Ensure Security of Postfix SSL Certificate [ref]groupCreate the PKI directory for mail certificates, if it does not already exist: $ sudo mkdir /etc/pki/tls/mail $ sudo chown root:root /etc/pki/tls/mail $ sudo chmod 755 /etc/pki/tls/mailUsing removable media or some other secure transmission format, install the files generated in the previous step onto the mail server: /etc/pki/tls/mail/serverkey.pem: the private key mailserverkey.pem /etc/pki/tls/mail/servercert.pem: the certificate file mailservercert.pemVerify the ownership and permissions of these files: $ sudo chown root:root /etc/pki/tls/mail/serverkey.pem $ sudo chown root:root /etc/pki/tls/mail/servercert.pem $ sudo chmod 600 /etc/pki/tls/mail/serverkey.pem $ sudo chmod 644 /etc/pki/tls/mail/servercert.pemVerify that the CA's public certificate file has been installed as /etc/pki/tls/CA/cacert.pem, and has the
correct permissions:
$ sudo chown root:root /etc/pki/tls/CA/cacert.pem $ sudo chmod 644 /etc/pki/tls/CA/cacert.pem |
Configure Postfix if Necessary [ref]groupPostfix stores its configuration files in the directory
/etc/postfix by default. The primary configuration file is
|
Configure Postfix Resource Usage to Limit Denial of Service Attacks [ref]groupEdit default_process_limit = 100 smtpd_client_connection_count_limit = 10 smtpd_client_connection_rate_limit = 30 queue_minfree = 20971520 header_size_limit = 51200 message_size_limit = 10485760 smtpd_recipient_limit = 100The values here are examples. warning
Note: The values given here are examples, and may
need to be modified for any particular site. By default, the Postfix anvil
process gathers mail receipt statistics. To get information about about what
connection rates are typical at your site, look in /var/log/maillog
for lines with the daemon name postfix/anvil.
|
Control Mail Relaying [ref]groupPostfix's mail relay controls are implemented with the help of the smtpd recipient restrictions option, which controls the restrictions placed on the SMTP dialogue once the sender and recipient envelope addresses are known. The guidance in the following sections should be applied to all systems. If there are systems which must be allowed to relay mail, but which cannot be trusted to relay unconditionally, configure SMTP AUTH with SSL support. |
Configure Trusted Networks and Hosts [ref]groupEdit
|
Enact SMTP Relay Restrictions [ref]group
To configure Postfix to restrict addresses to which it
will send mail, see:
http://www.postfix.org/SMTPD_ACCESS_README.html#danger
|
Enact SMTP Recipient Restrictions [ref]group
To configure Postfix to restrict addresses to which it
will send mail, see:
http://www.postfix.org/SMTPD_ACCESS_README.html#danger
|
Require SMTP AUTH Before Relaying from Untrusted Clients [ref]groupSMTP authentication allows remote clients to relay mail safely by requiring them to authenticate before submitting mail. Postfix's SMTP AUTH uses an authentication library called SASL, which is not part of Postfix itself. To enable the use of SASL authentication, see http://www.postfix.org/SASL_README.html |
Use TLS for SMTP AUTH [ref]groupPostfix provides options to use TLS for certificate-based authentication and encrypted sessions. An encrypted session protects the information that is transmitted with SMTP mail or with SASL authentication. To configure Postfix to protect all SMTP AUTH transactions using TLS, see http://www.postfix.org/TLS_README.html. |
LDAP [ref]groupLDAP is a popular directory service, that is, a standardized way of looking up information from a central database. Red Hat Enterprise Linux 7 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 7 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. |
Configure OpenLDAP Server [ref]groupThis section details some security-relevant settings for an OpenLDAP server. Installation and configuration of OpenLDAP on Red Hat Enterprise Linux 7 is available at: https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Directory_Servers.html. |
Install and Protect LDAP Certificate Files [ref]groupCreate the PKI directory for LDAP certificates if it does not already exist: $ sudo mkdir /etc/pki/tls/ldap $ sudo chown root:root /etc/pki/tls/ldap $ sudo chmod 755 /etc/pki/tls/ldapUsing removable media or some other secure transmission format, install the certificate files onto the LDAP server:
$ sudo chown root:ldap /etc/pki/tls/ldap/serverkey.pem $ sudo chown root:ldap /etc/pki/tls/ldap/servercert.pem $ sudo chmod 640 /etc/pki/tls/ldap/serverkey.pem $ sudo chmod 640 /etc/pki/tls/ldap/servercert.pemVerify that the CA's public certificate file has been installed as /etc/pki/tls/CA/cacert.pem, and has the correct permissions:
$ sudo mkdir /etc/pki/tls/CA $ sudo chown root:root /etc/pki/tls/CA/cacert.pem $ sudo chmod 644 /etc/pki/tls/CA/cacert.pemAs a result of these steps, the LDAP server will have access to its own private certificate and the key with which that certificate is encrypted, and to the public certificate file belonging to the CA. Note that it would be possible for the key to be protected further, so that processes running as ldap could not read it. If this were done, the LDAP server process would need to be restarted manually whenever the server rebooted. |
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 systems 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 system
from operating as either an NFS client or an NFS server. Only perform these
steps on systems which do not need NFS at all. |
Disable Services Used Only by NFS [ref]groupIf NFS is not needed, disable the NFS client daemons nfslock, rpcgssd, and rpcidmapd.
|
Configure All Systems which Use NFS [ref]groupThe steps in this section are appropriate for all systems which run NFS, whether they operate as clients or as servers. |
Make Each System a Client or a Server, not Both [ref]groupIf NFS must be used, it should be deployed in the simplest configuration possible to avoid maintainability problems which may lead to unnecessary security exposure. Due to the reliability and security problems caused by NFS (specially NFSv3 and NFSv2), it is not a good idea for systems which act as NFS servers to also mount filesystems via NFS. At the least, crossed mounts (the situation in which each of two servers mounts a filesystem from the other) should never be used. |
Configure NFS Services to Use Fixed Ports (NFSv3 and NFSv2) [ref]groupFirewalling should be done at each host and at the border
firewalls to protect the NFS daemons from remote access, since NFS servers
should never be accessible from outside the organization. However, by default
for NFSv3 and NFSv2, the RPC Bind service assigns each NFS service to a port
dynamically at service startup time. Dynamic ports cannot be protected by port
filtering firewalls such as |
Configure NFS Clients [ref]groupThe steps in this section are appropriate for systems which operate as NFS clients. |
Disable NFS Server Daemons [ref]group
There is no need to run the NFS server daemons |
Mount Remote Filesystems with Restrictive Options [ref]groupEdit the file |
Configure NFS Servers [ref]groupThe steps in this section are appropriate for systems which operate as NFS servers. |
Configure the Exports File Restrictively [ref]groupLinux's NFS implementation uses the file /DIR host1(opt1,opt2) host2(opt3)where /DIR is a directory or filesystem to export, hostN is an IP address, netblock,
hostname, domain, or netgroup to which to export, and optN is an option.
|
Use Access Lists to Enforce Authorization Restrictions [ref]groupWhen configuring NFS exports, ensure that each export line in
|
Export Filesystems Read-Only if Possible [ref]groupIf a filesystem is being exported so that users can view the files in a convenient
fashion, but there is no need for users to edit those files, exporting the filesystem read-only
removes an attack vector against the server. The default filesystem export mode is |
DNS Server [ref]groupMost organizations have an operational need to run at least one nameserver. However, there are many common attacks involving DNS server software, and this server software should be disabled on any system on which it is not needed. |
Disable DNS Server [ref]groupDNS software should be disabled on any systems which does not need to be a nameserver. Note that the BIND DNS server software is not installed on Red Hat Enterprise Linux 7 by default. The remainder of this section discusses secure configuration of systems which must be nameservers. |
Isolate DNS from Other Services [ref]groupThis section discusses mechanisms for preventing the DNS server from interfering with other services. This is done both to protect the remainder of the network should a nameserver be compromised, and to make direct attacks on nameservers more difficult. |
Run DNS Software on Dedicated Servers [ref]groupSince DNS is a high-risk service which must frequently be made available to the entire Internet, it is strongly recommended that no other services be offered by systems which act as organizational DNS servers. |
Run DNS Software in a chroot Jail [ref]groupInstall the $ sudo yum install bind-chrootPlace a valid named.conf file inside the chroot jail: $ sudo cp /etc/named.conf /var/named/chroot/etc/named.conf $ sudo chown root:root /var/named/chroot/etc/named.conf $ sudo chmod 644 /var/named/chroot/etc/named.confCreate and populate an appropriate zone directory within the jail, based on the options directive. If your named.conf includes:
options {
directory "/path/to/DIRNAME ";
...
}
then copy that directory and its contents from the original zone directory:
$ sudo cp -r /path/to/DIRNAME /var/named/chroot/DIRNAMEAdd or correct the following line within /etc/sysconfig/named:
ROOTDIR=/var/named/chroot warning
If you are running BIND in a chroot jail, then you
should use the jailed named.conf as the primary nameserver
configuration file. That is, when this guide recommends editing
/etc/named.conf, you should instead edit
/var/named/chroot/etc/named.conf.
|
Protect DNS Data from Tampering or Attack [ref]groupThis section discusses DNS configuration options which make it more difficult for attackers to gain access to private DNS data or to modify DNS data. |
Run Separate DNS Servers for External and Internal Queries [ref]groupIs it possible to run external and internal nameservers on
separate systems? If so, follow the configuration guidance in this section. On
the external nameserver, edit options {
allow-query { any; };
recursion no;
...
};
zone "example.com " IN {
...
};
On the internal nameserver, edit /etc/named.conf. Add or correct the
following directives, where SUBNET is the numerical IP representation of your
organization in the form xxx.xxx.xxx.xxx/xx:
acl internal {
SUBNET ;
localhost;
};
options {
allow-query { internal; };
...
};
zone "internal.example.com " IN {
...
};
|
Use Views to Partition External and Internal Information [ref]groupIf it is not possible to run external and internal nameservers on
separate physical systems, run BIND9 and simulate this feature using views.
Edit acl internal {
SUBNET ;
localhost;
};
view "internal-view" {
match-clients { internal; };
zone "." IN {
type hint;
file "db.cache";
};
zone "internal.example.com " IN {
...
};
};
view "external-view" {
match-clients { any; };
recursion no;
zone "example.com " IN {
...
};
};
warning
As shown in the example, database files which are
required for recursion, such as the root hints file, must be available to any
clients which are allowed to make recursive queries. Under typical
circumstances, this includes only the internal clients which are allowed to use
this server as a general-purpose nameserver. |
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.
|
Disable vsftpd if Possible [ref]groupTo minimize attack surface, disable vsftpd if at all possible. |
Use vsftpd to Provide FTP Service if Necessary [ref]groupIf your use-case requires FTP service, install and set-up vsftpd to provide it. |
Use vsftpd to Provide FTP Service if Necessary [ref]groupThe primary vsftpd configuration file is
|
Restrict the Set of Users Allowed to Access FTP [ref]groupThis section describes how to disable non-anonymous (password-based) FTP logins, or, if it is not possible to do this entirely due to legacy applications, how to restrict insecure FTP login to only those users who have an identified need for this access. |
Limit Users Allowed FTP Access if Necessary [ref]groupIf there is a mission-critical reason for users to access their accounts via the insecure FTP protocol, limit the set of users who are allowed this access. Edit the vsftpd configuration file. Add or correct the following configuration options: userlist_enable=YES userlist_file=/etc/vsftp.ftpusers userlist_deny=NOEdit the file /etc/vsftp.ftpusers. For each user USERNAME who should be allowed to access the system via FTP, add a line containing that user's name:
USERNAMEIf anonymous access is also required, add the anonymous usernames to /etc/vsftp.ftpusers as well.
anonymous ftp |
Configure Firewalls to Protect the FTP Server [ref]groupBy default, |
Web Server [ref]groupThe web server is responsible for providing access to
content via the HTTP protocol. Web servers represent a significant
security risk because:
The system's default web server software is Apache 2 and is provided in the RPM package httpd. |
Disable Apache if Possible [ref]groupIf Apache was installed and activated, but the system does not need to act as a web server, then it should be disabled and removed from the system. |
Install Apache if Necessary [ref]groupIf $ sudo yum install httpdThis method of installation is recommended over installing the "Web Server" package group during the system installation process. The Web Server package group includes many packages which are likely extraneous, while the command-line method installs only the required httpd package itself.
|
Confirm Minimal Built-in Modules Installed [ref]groupThe default $ httpd -lIf the number of compiled-in modules is significantly larger than the aforementioned set, this guide recommends re-installing httpd with a
reduced configuration. Minimizing the number of modules that are compiled into
the httpd binary, reduces risk by limiting the capabilities allowed by
the webserver.
|
Secure Apache Configuration [ref]groupThe |
Restrict Web Server Information Leakage [ref]group
The |
Minimize Web Server Loadable Modules [ref]group
A default installation of $ sudo service httpd configtestThe purpose of each of the modules loaded by default will now be addressed one at a time. If none of a module's directives are being used, remove it. |
httpd Core Modules [ref]group
These modules comprise a basic subset of modules that are likely needed for base LoadModule auth_basic_module modules/mod_auth_basic.so LoadModule authn_default_module modules/mod_authn_default.so LoadModule authz_host_module modules/mod_authz_host.so LoadModule authz_user_module modules/mod_authz_user.so LoadModule authz_groupfile_module modules/mod_authz_groupfile.so LoadModule authz_default_module modules/mod_authz_default.so LoadModule log_config_module modules/mod_log_config.so LoadModule logio_module modules/mod_logio.so LoadModule setenvif_module modules/mod_setenvif.so LoadModule mime_module modules/mod_mome.so LoadModule autoindex_module modules/mod_autoindex.so LoadModule negotiation_module modules/mod_negotiation.so LoadModule dir_module modules/mod_dir.so LoadModule alias_module modules/mod_alias.soMinimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server. |
Minimize Modules for HTTP Basic Authentication [ref]group
The following modules are necessary if this web server will provide content that will
be restricted by a password.
LoadModule authn_file_module modules/mod_authn_file.so LoadModule authn_dbm_module modules/mod_authn_dbm.so authn_alias allows for authentication based on aliases. authn_anon
allows anonymous authentication similar to that of anonymous ftp sites. authz_owner
allows authorization based on file ownership. authz_dbm allows for authorization
based on group membership if the web server is using DBM authentication.
If the above functionality is unnecessary, comment out the related module: #LoadModule authn_alias_module modules/mod_authn_alias.so #LoadModule authn_anon_module modules/mod_authn_anon.so #LoadModule authz_owner_module modules/mod_authz_owner.so #LoadModule authz_dbm_module modules/mod_authz_dbm.so |
Minimize Various Optional Components [ref]groupThe following modules perform very specific tasks, sometimes providing access to just a few additional directives. If such functionality is not required (or if you are not using these directives), comment out the associated module:
|
Minimize Configuration Files Included [ref]group
The #Include conf.d/*.confIf the above change was made, ensure that the SSL encryption remains loaded by explicitly including the corresponding configuration file: Include conf.d/ssl.confIf PHP is necessary, a similar alteration must be made: Include conf.d/php.confExplicitly listing the configuration files to be loaded during web server start-up avoids the possibility of unwanted or malicious configuration files to be automatically included as part of the server's running configuration. |
Directory Restrictions [ref]groupThe Directory tags in the web server configuration file allow finer grained access control for a specified directory. All web directories should be configured on a case-by-case basis, allowing access only where needed. |
Use Appropriate Modules to Improve httpd's Security [ref]group
Among the modules available for |
Deploy mod_ssl [ref]group
Because HTTP is a plain text protocol, all traffic is susceptible to passive
monitoring. If there is a need for confidentiality, SSL should be configured
and enabled to encrypt content.
|
Deploy mod_security [ref]group
The |
Use Denial-of-Service Protection Modules [ref]groupDenial-of-service attacks are difficult to detect and prevent while maintaining acceptable access to authorized users. However, some traffic-shaping modules can be used to address the problem. Well-known DoS protection modules include: mod_cband mod_bwshare mod_limitipconn mod_evasiveDenial-of-service prevention should be implemented for a web server if such a threat exists. However, specific configuration details are very dependent on the environment and often best left at the discretion of the administrator. |
Configure PHP Securely [ref]group
PHP is a widely-used and often misconfigured server-side scripting language. It should
be used with caution, but configured appropriately when needed.
# Do not expose PHP error messages to external users display_errors = Off # Enable safe mode safe_mode = On # Only allow access to executables in isolated directory safe_mode_exec_dir = php-required-executables-path # Limit external access to PHP environment safe_mode_allowed_env_vars = PHP_ # Restrict PHP information leakage expose_php = Off # Log all errors log_errors = On # Do not register globals for input data register_globals = Off # Minimize allowable PHP post size post_max_size = 1K # Ensure PHP redirects appropriately cgi.force_redirect = 0 # Disallow uploading unless necessary file_uploads = Off # Disallow treatment of file requests as fopen calls allow_url_fopen = Off # Enable SQL safe mode sql.safe_mode = On |
Configure Operating System to Protect Web Server [ref]groupThe following configuration steps should be taken on the system which hosts the web server, in order to provide as safe an environment as possible for the web server. |
Restrict File and Directory Access [ref]group
Minimize access to critical |
Configure firewalld to Allow Access to the Web Server [ref]group
By default, |
Run httpd in a chroot Jail if Practical [ref]group
Running ChrootDir /chroot/apacheThis necessitates placing all files required by httpd inside
/chroot/apache , including httpd's binaries, modules,
configuration files, and served web pages. The details of this configuration
are beyond the scope of this guide. This may also require additional SELinux
configuration.
|
IMAP and POP3 Server [ref]groupDovecot provides IMAP and POP3 services. It is not installed by default. The project page at http://www.dovecot.org contains more detailed information about Dovecot configuration. |
Disable Dovecot [ref]groupIf the system does not need to operate as an IMAP or POP3 server, the dovecot software should be disabled and removed. |
Configure Dovecot if Necessary [ref]groupIf the system will operate as an IMAP or POP3 server, the dovecot software should be configured securely by following the recommendations below. |
Support Only the Necessary Protocols [ref]groupDovecot supports the IMAP and POP3 protocols, as well as
SSL-protected versions of those protocols. Configure the Dovecot server
to support only the protocols needed by your site. Edit protocols = PROTOCOLIf possible, require SSL protection for all transactions. The SSL protocol variants listen on alternate ports (995 instead of 110 for pop3s, and 993 instead of 143 for imaps), and require SSL-aware clients. An alternate approach is to listen on the standard port and require the client to use the STARTTLS command before authenticating. |
Enable SSL Support [ref]groupSSL should be used to encrypt network traffic between the Dovecot server and its clients. Users must authenticate to the Dovecot server in order to read their mail, and passwords should never be transmitted in clear text. In addition, protecting mail as it is downloaded is a privacy measure, and clients may use SSL certificates to authenticate the server, preventing another system from impersonating the server. |
Allow IMAP Clients to Access the Server [ref]groupThe default |
Network Routing [ref]groupA router is a very desirable target for a potential adversary because they fulfill a variety of infrastructure networking roles such as access to network segments, gateways to other networks, filtering, etc. Therefore, if one is required, the system acting as a router should be dedicated to that purpose alone and be stored in a physically secure location. The system's default routing software is Quagga, and provided in an RPM package of the same name. |
Disable Quagga if Possible [ref]groupIf Quagga was installed and activated, but the system does not need to act as a router, then it should be disabled and removed. |
Samba(SMB) Microsoft Windows File Sharing Server [ref]groupWhen properly configured, the Samba service allows
Linux systems to provide file and print sharing to Microsoft
Windows systems. There are two software packages that provide
Samba support. The first, |
Disable Samba if Possible [ref]groupEven after the Samba server package has been installed, it will remain disabled. Do not enable this service unless it is absolutely necessary to provide Microsoft Windows file and print sharing functionality. |
Configure Samba if Necessary [ref]groupAll settings for the Samba daemon can be found in
|
Restrict SMB File Sharing to Configured Networks [ref]groupOnly users with local user accounts will be able to log in to
Samba shares by default. Shares can be limited to particular users or network
addresses. Use the [share] hosts allow = 192.168.1. 127.0.0.1 valid users = userone usertwo @usergroupIt is also possible to limit read and write access to particular users with the read list and write list options, though the permissions set by the system itself will override these settings. Set the read only attribute for each share to ensure that global settings will not accidentally override the individual share settings. Then, as with the valid users directive, separate each user or group of users with a space: [share] read only = yes write list = userone usertwo @usergroup |
Restrict Printer Sharing [ref]groupBy default, Samba utilizes the CUPS printing service to enable
printer sharing with Microsoft Windows workstations. If there are no printers
on the local system, or if printer sharing with Microsoft Windows is not
required, disable the printer sharing capability by commenting out the
following lines, found in [global] load printers = yes cups options = raw [printers] comment = All Printers path = /usr/spool/samba browseable = no guest ok = no writable = no printable = yesThere may be other options present, but these are the only options enabled and uncommented by default. Removing the [printers] share should be enough
for most users. If the Samba printer sharing capability is needed, consider
disabling the Samba network browsing capability or restricting access to a
particular set of users or network addresses. Set the valid users
parameter to a small subset of users or restrict it to a particular group of
users with the shorthand @. Separate each user or group of users with
a space. For example, under the [printers] share:
[printers] valid users = user @printerusers |
Proxy Server [ref]groupA proxy server is a very desirable target for a potential adversary because much (or all) sensitive data for a given infrastructure may flow through it. Therefore, if one is required, the system acting as a proxy server should be dedicated to that purpose alone and be stored in a physically secure location. The system's default proxy server software is Squid, and provided in an RPM package of the same name. |
Disable Squid if Possible [ref]groupIf Squid was installed and activated, but the system does not need to act as a proxy server, then it should be disabled and removed. |
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. |
Disable SNMP Server if Possible [ref]groupThe system includes an SNMP daemon that allows for its remote monitoring, though it not installed by default. If it was installed and activated but is not needed, the software should be disabled and removed. |
Configure SNMP Server if Necessary [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 C2S/CIS Mapping [ref]groupThese groups exist to document how the Red Hat Enterprise Linux product meets (or does not meet) requirements listed in C2S/CIS, for those cases where Groups or Rules elsewhere in scap-security-guide do not clearly relate. |