|
Introductiongroup
The purpose of this guidance is to provide security configuration
recommendations and baselines for the Red Hat Enterprise Linux (RHEL) 7 operating
system. The guidance provided here should be applicable to all variants
(Desktop, Server, Advanced Platform) of the product. Recommended
settings for the basic operating system are provided, as well as for many
network services that the system can provide to other systems.
The guide is intended for system administrators. Readers are assumed to
possess basic system administration skills for Unix-like systems, as well
as some familiarity with Red Hat's documentation and administration
conventions. Some instructions within this guide are complex.
All directions should be followed completely and with understanding of
their effects in order to avoid serious adverse effects on the system
and its security.
|
|
General Principlesgroup
The 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 Possiblegroup
Data transmitted over a network, whether wired or wireless, is susceptible
to passive monitoring. Whenever practical solutions for encrypting
such data exist, they should be applied. Even if data is expected to
be transmitted only over a local network, it should still be encrypted.
Encrypting authentication data, such as passwords, is particularly
important. Networks of 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 Vulnerabilitygroup
The simplest way to avoid vulnerabilities in software is to avoid
installing that software. On RHEL, the RPM Package Manager (originally
Red Hat Package Manager, abbreviated RPM) allows for careful management of
the set of software packages installed on a system. Installed software
contributes to system vulnerability in several ways. Packages that
include setuid programs may provide local attackers a potential path to
privilege escalation. Packages that include network services may give
this opportunity to network-based attackers. Packages that include
programs which are predictably executed by local users (e.g. after
graphical login) may provide opportunities for trojan horses or other
attack code to be run undetected. The number of software packages
installed on a system can almost always be significantly pruned to include
only the software for which there is an environmental or operational need.
|
|
Run Different Network Services on Separate Systemsgroup
Whenever possible, a server should be dedicated to serving exactly one
network service. This limits the number of other services that can
be compromised in the event that an attacker is able to successfully
exploit a software flaw in one network service.
|
|
Configure Security Tools to Improve System Robustnessgroup
Several tools exist which can be effectively used to improve a system's
resistance to and detection of unknown attacks. These tools can improve
robustness against attack at the cost of relatively little configuration
effort. In particular, this guide recommends and discusses the use of
FirewallD for host-based firewalling, SELinux for protection against
vulnerable services, and a logging and auditing infrastructure for
detection of problems.
|
|
Least Privilegegroup
Grant the least privilege necessary for user accounts and software to perform tasks.
For example, sudo can be implemented to limit authorization to super user
accounts on the system only to designated personnel. Another example is to limit
logins on server systems to only those administrators who need to log into them in
order to perform administration tasks. Using SELinux also follows the principle of
least privilege: SELinux policy can confine software to perform only actions on the
system that are specifically allowed. This can be far more restrictive than the
actions permissible by the traditional Unix permissions model.
|
|
How to Use This Guidegroup
Readers should heed the following points when using the guide.
|
|
Read Sections Completely and in Ordergroup
Each section may build on information and recommendations discussed in
prior sections. Each section should be read and understood completely;
instructions should never be blindly applied. Relevant discussion may
occur after instructions for an action.
|
|
Test in Non-Production Environmentgroup
This guidance should always be tested in a non-production environment
before deployment. This test environment should simulate the setup in
which the system will be deployed as closely as possible.
|
|
Root Shell Environment Assumedgroup
Most of the actions listed in this document are written with the
assumption that they will be executed by the root user running the
/bin/bash shell. Commands preceded with a hash mark (#)
assume that the administrator will execute the commands as root, i.e.
apply the command via sudo whenever possible, or use
su to gain root privileges if sudo cannot be
used. Commands which can be executed as a non-root user are are preceded
by a dollar sign ($) prompt.
|
|
Formatting Conventionsgroup
Commands intended for shell execution, as well as configuration file text,
are featured in a monospace font. Italics are used
to indicate instances where the system administrator must substitute
the appropriate information into a command or configuration file.
|
|
Reboot Requiredgroup
A system reboot is implicitly required after some actions in order to
complete the reconfiguration of the system. In many cases, the changes
will not take effect until a reboot is performed. In order to ensure
that changes are applied properly and to test functionality, always
reboot the system after applying a set of recommendations from this guide.
|
|
System Settingsgroup |
|
Installing and Maintaining SoftwaregroupThe following sections contain information on
security-relevant choices during the initial operating system
installation process and the setup of software
updates. |
|
Disk PartitioninggroupTo ensure separation and protection of data, there
are top-level system directories which should be placed on their
own physical partition or logical volume. The installer's default
partitioning scheme creates separate logical volumes for
/, /boot, and swap.
If starting with any of the default layouts, check the box to
"Review and modify partitioning." This allows for the easy creation
of additional logical volumes inside the volume group already
created, though it may require making /'s logical volume smaller to
create space. In general, using logical volumes is preferable to
using partitions because they can be more easily adjusted
later.If creating a custom layout, create the partitions mentioned in
the previous paragraph (which the installer will require anyway),
as well as separate ones described in the following sections.
If a system has already been installed, and the default
partitioning scheme was used, it is possible but nontrivial to
modify it to create separate logical volumes for the directories
listed above. The Logical Volume Manager (LVM) makes this possible.
See the LVM HOWTO at http://tldp.org/HOWTO/LVM-HOWTO/ for more
detailed information on LVM. |
|
Updating SoftwaregroupThe yum command line tool is used to install and
update software packages. The system also provides a graphical
software update tool in the System menu, in the Administration submenu,
called Software Update.
Red Hat Enterprise Linux systems contain an installed software catalog called
the RPM database, which records metadata of installed packages. Consistently using
yum or the graphical Software Update for all software installation
allows for insight into the current inventory of installed software on the system.
|
|
Software Integrity Checkinggroup
Both the AIDE (Advanced Intrusion Detection Environment)
software and the RPM package management system provide
mechanisms for verifying the integrity of installed software.
AIDE uses snapshots of file metadata (such as hashes) and compares these
to current system files in order to detect changes.
The RPM package management system can conduct integrity
checks by comparing information in its metadata database with
files installed on the system.
Integrity checking cannot prevent intrusions,
but can detect that they have occurred. Requirements
for software integrity checking may be highly dependent on
the environment in which the system will be used. Snapshot-based
approaches such as AIDE may induce considerable overhead
in the presence of frequent software updates.
|
|
Verify Integrity with AIDEgroupAIDE conducts integrity checks by comparing information about
files with previously-gathered information. Ideally, the AIDE database is
created immediately after initial system configuration, and then again after any
software update. AIDE is highly configurable, with further configuration
information located in /usr/share/doc/aide-VERSION.
|
|
Verify Integrity with RPMgroupThe RPM package management system includes the ability
to verify the integrity of installed packages by comparing the
installed files with information about the files taken from the
package metadata stored in the RPM database. Although an attacker
could corrupt the RPM database (analogous to attacking the AIDE
database as described above), this check can still reveal
modification of important files. To list which files on the system differ from what is expected by the RPM database:
$ rpm -qVa
See the man page for rpm to see a complete explanation of each column.
|
|
Additional Security Softwaregroup
Additional security software that is not provided or supported
by Red Hat can be installed to provide complementary or duplicative
security capabilities to those provided by the base platform. Add-on
software may not be appropriate for some specialized systems.
|
|
File Permissions and MasksgroupTraditional Unix security relies heavily on file and
directory permissions to prevent unauthorized users from reading or
modifying files to which they should not have access.
Several of the commands in this section search filesystems
for files or directories with certain characteristics, and are
intended to be run on every local partition on a given system.
When the variable PART appears in one of the commands below,
it means that the command is intended to be run repeatedly, with the
name of each local partition substituted for PART in turn.
The following command prints a list of all xfs partitions on the local
system, which is the default filesystem for Red Hat Enterprise Linux
7 installations:
$ mount -t xfs | awk '{print $3}'
For any systems that use a different
local filesystem type, modify this command as appropriate.
|
|
Restrict Partition Mount OptionsgroupSystem partitions can be mounted with certain options
that limit what files on those partitions can do. These options
are set in the /etc/fstab configuration file, and can be
used to make certain types of malicious behavior more difficult. |
|
Restrict Dynamic Mounting and Unmounting of
FilesystemsgroupLinux includes a number of facilities for the automated addition
and removal of filesystems on a running system. These facilities may be
necessary in many environments, but this capability also carries some risk -- whether direct
risk from allowing users to introduce arbitrary filesystems,
or risk that software flaws in the automated mount facility itself could
allow an attacker to compromise the system.
This command can be used to list the types of filesystems that are
available to the currently executing kernel:
$ find /lib/modules/`uname -r`/kernel/fs -type f -name '*.ko'
If these filesystems are not required then they can be explicitly disabled
in a configuratio file in /etc/modprobe.d.
|
|
Verify Permissions on Important Files and
DirectoriesgroupPermissions 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 CredentialsgroupThe default restrictive permissions for files which act as
important security databases such as passwd, shadow,
group, and gshadow files must be maintained. Many utilities
need read access to the passwd file in order to function properly, but
read access to the shadow file allows malicious attacks against system
passwords, and should never be enabled. |
|
Verify File Permissions Within Some Important DirectoriesgroupSome 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 PatternsgroupThe 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 UmaskgroupThe 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 DumpsgroupA core dump file is the memory image of an executable
program when it was terminated by the operating system due to
errant behavior. In most cases, only software developers
legitimately need to access these files. The core dump files may
also contain sensitive information, or unnecessarily occupy large
amounts of disk space.
Once a hard limit is set in /etc/security/limits.conf, a
user cannot increase that limit within his or her own session. If access
to core dumps is required, consider restricting them to only
certain users or groups. See the limits.conf man page for more
information.
The core dumps of setuid programs are further protected. The
sysctl variable fs.suid_dumpable controls whether
the kernel allows core dumps from these programs at all. The default
value of 0 is recommended. |
|
Enable ExecShieldgroupExecShield 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 sysctl variables
kernel.exec-shield and kernel.randomize_va_space. On the latest
64-bit systems, kernel.exec-shield cannot be enabled or disabled with
sysctl.
|
|
Enable Execute Disable (XD) or No Execute (NX) Support on
x86 SystemsgroupRecent 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. |
|
SELinuxgroupSELinux is a feature of the Linux kernel which can be
used to guard against misconfigured or compromised programs.
SELinux enforces the idea that programs should be limited in what
files they can access and what actions they can take.
The default SELinux policy, as configured on Red Hat Enterprise Linux 7, has been
sufficiently developed and debugged that it should be usable on
almost any Red Hat machine with minimal configuration and a small
amount of system administrator training. This policy prevents
system services - including most of the common network-visible
services such as mail servers, FTP servers, and DNS servers - from
accessing files which those services have no valid reason to
access. This action alone prevents a huge amount of possible damage
from network attacks against services, from trojaned software, and
so forth.
This guide recommends that SELinux be enabled using the
default (targeted) policy on every Red Hat system, unless that
system has unusual requirements which make a stronger policy
appropriate.
|
|
Account and Access ControlgroupIn 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 LogingroupConventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the /etc/passwd and
/etc/shadow files. Password-based login is vulnerable to
guessing of weak passwords, and to sniffing and man-in-the-middle
attacks against passwords entered over a network or at an insecure
console. Therefore, mechanisms for accessing accounts by entering
usernames and passwords should be restricted to those which are
operationally necessary. |
|
Restrict Root Loginsgroup
Direct root logins should be allowed only for emergency use.
In normal situations, the administrator should access the system
via a unique unprivileged account, and then use su or sudo to execute
privileged commands. Discouraging administrators from accessing the
root account directly ensures an audit trail in organizations with
multiple administrators. Locking down the channels through which
root can connect directly also reduces opportunities for
password-guessing against the root account. The login program
uses the file /etc/securetty to determine which interfaces
should allow root logins.
The virtual devices /dev/console
and /dev/tty* represent the system consoles (accessible via
the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default
installation). The default securetty file also contains /dev/vc/*.
These are likely to be deprecated in most environments, but may be retained
for compatibility. Root should also be prohibited from connecting
via network protocols. Other sections of this document
include guidance describing how to prevent root from logging in via SSH.
|
|
Verify Proper Storage and Existence of Password
Hashesgroup
By default, password hashes for local accounts are stored
in the second field (colon-separated) in
/etc/shadow. This file should be readable only by
processes running with root credentials, preventing users from
casually accessing others' password hashes and attempting
to crack them.
However, it remains possible to misconfigure the system
and store password hashes
in world-readable files such as /etc/passwd, or
to even store passwords themselves in plaintext on the system.
Using system-provided tools for password change/creation
should allow administrators to avoid such misconfiguration.
|
|
Set Password Expiration ParametersgroupThe file /etc/login.defs controls several
password-related settings. Programs such as passwd,
su, and
login consult /etc/login.defs to determine
behavior with regard to password aging, expiration warnings,
and length. See the man page login.defs(5) for more information.
Users should be forced to change their passwords, in order to
decrease the utility of compromised passwords. However, the need to
change passwords often should be balanced against the risk that
users will reuse or write down passwords if forced to change them
too often. Forcing password changes every 90-360 days, depending on
the environment, is recommended. Set the appropriate value as
PASS_MAX_DAYS and apply it to existing accounts with the
-M flag.
The PASS_MIN_DAYS (-m) setting prevents password
changes for 7 days after the first change, to discourage password
cycling. If you use this setting, train users to contact an administrator
for an emergency password change in case a new password becomes
compromised. The PASS_WARN_AGE (-W) setting gives
users 7 days of warnings at login time that their passwords are about to expire.
For example, for each existing human user USER, expiration parameters
could be adjusted to a 180 day maximum password age, 7 day minimum password
age, and 7 day warning period with the following command:
$ sudo chage -M 180 -m 7 -W 7 USER
|
|
Set Account Expiration ParametersgroupAccounts can be configured to be automatically disabled
after a certain time period,
meaning that they will require administrator interaction to become usable again.
Expiration of accounts after inactivity can be set for all accounts by default
and also on a per-account basis, such as for accounts that are known to be temporary.
To configure automatic expiration of an account following
the expiration of its password (that is, after the password has expired and not been changed),
run the following command, substituting NUM_DAYS and USER appropriately:
$ sudo chage -I NUM_DAYS USER
Accounts, such as temporary accounts, can also be configured to expire on an explicitly-set date with the
-E option.
The file /etc/default/useradd controls
default settings for all newly-created accounts created with the system's
normal command line utilities.
|
|
Protect Accounts by Configuring PAMgroupPAM, or Pluggable Authentication Modules, is a system
which implements modular authentication for Linux programs. PAM provides
a flexible and configurable architecture for authentication, and it should be configured
to minimize exposure to unnecessary risk. This section contains
guidance on how to accomplish that.
PAM is implemented as a set of shared objects which are
loaded and invoked whenever an application wishes to authenticate a
user. Typically, the application must be running as root in order
to take advantage of PAM, because PAM's modules often need to be able
to access sensitive stores of account information, such as /etc/shadow.
Traditional privileged network listeners
(e.g. sshd) or SUID programs (e.g. sudo) already meet this
requirement. An SUID root application, userhelper, is provided so
that programs which are not SUID or privileged themselves can still
take advantage of PAM.
PAM looks in the directory /etc/pam.d for
application-specific configuration information. For instance, if
the program login attempts to authenticate a user, then PAM's
libraries follow the instructions in the file /etc/pam.d/login
to determine what actions should be taken.
One very important file in /etc/pam.d is
/etc/pam.d/system-auth. This file, which is included by
many other PAM configuration files, defines 'default' system authentication
measures. Modifying this file is a good way to make far-reaching
authentication changes, for instance when implementing a
centralized authentication service. |
|
Set Password Quality RequirementsgroupThe default pam_pwquality PAM module provides strength
checking for passwords. It performs a number of checks, such as
making sure passwords are not similar to dictionary words, are of
at least a certain length, are not the previous password reversed,
and are not simply a change of case from the previous password. It
can also require passwords to be in certain character classes. The
pam_pwquality module is the preferred way of configuring
password requirements.
The pam_cracklib PAM module can also provide strength
checking for passwords as the pam_pwquality module.
It performs a number of checks, such as making sure passwords are
not similar to dictionary words, are of at least a certain length,
are not the previous password reversed, and are not simply a change
of case from the previous password. It can also require passwords to
be in certain character classes.
The man pages pam_pwquality(8) and pam_cracklib(8)
provide information on the capabilities and configuration of
each. |
|
Set Password Quality Requirements with pam_pwqualitygroupThe pam_pwquality PAM module can be configured to meet
requirements for a variety of policies.
For example, to configure pam_pwquality to require at least one uppercase
character, lowercase character, digit, and other (special)
character, make sure that pam_pwquality exists in /etc/pam.d/system-auth:
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 = 3
The arguments can be modified to ensure compliance with
your organization's security policy. Discussion of each parameter follows.
|
|
Set Lockouts for Failed Password AttemptsgroupThe pam_faillock PAM module provides the capability to
lock out user accounts after a number of failed login attempts. Its
documentation is available in
/usr/share/doc/pam-VERSION/txts/README.pam_faillock.
|
|
Set Password Hashing AlgorithmgroupThe system's default algorithm for storing password hashes in
/etc/shadow is SHA-512. This can be configured in several
locations. |
|
Secure Session Configuration Files for Login AccountsgroupWhen 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 PathgroupThe active path of the root account can be obtained by
starting a new root shell and running:
# echo $PATH
This will produce a colon-separated list of
directories in the path.
Certain path elements could be considered dangerous, as they could lead
to root executing unknown or
untrusted programs, which could contain malicious
code.
Since root may sometimes work inside
untrusted directories, the . character, which represents the
current directory, should never be in the root path, nor should any
directory which can be written to by an unprivileged or
semi-privileged (system) user.
It is a good practice for administrators to always execute
privileged commands by typing the full path to the
command. |
|
Ensure that Users Have Sensible Umask Valuesgroup
The umask setting controls the default permissions
for the creation of new files.
With a default umask setting of 077, files and directories
created by users will not be readable by any other user on the
system. Users who wish to make specific files group- or
world-readable can accomplish this by using the chmod command.
Additionally, users can make all their files readable to their
group by default by setting a umask of 027 in their shell
configuration files. If default per-user groups exist (that is, if
every user has a default group whose name is the same as that
user's username and whose only member is the user), then it may
even be safe for users to select a umask of 007, making it very
easy to intentionally share files with groups of which the user is
a member.
|
|
Protect Physical Console AccessgroupIt 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 PasswordgroupDuring 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 LockinggroupWhen a user must temporarily leave an account
logged-in, screen locking should be employed to prevent passersby
from abusing the account. User education and training is
particularly important for screen locking to be effective, and policies
can be implemented to reinforce this.
Automatic screen locking is only meant as a safeguard for
those cases where a user forgot to lock the screen. |
|
Configure GUI Screen LockinggroupIn 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.
The following sections detail commands to enforce idle activation of the screensaver,
screen locking, a blank-screen screensaver, and an idle
activation time.
Because users should be trained to lock the screen when they
step away from the computer, the automatic locking feature is only
meant as a backup.
The root account can be screen-locked; however,
the root account should never be used
to log into an X Windows environment and should only be used to
for direct login via console in emergency circumstances.
For more information about enforcing preferences in the GNOME3 environment using the DConf
configuration system, see http://wiki.gnome.org/dconf and
the man page dconf(1). For Red Hat specific information on configuring DConf
settings, see https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/7/html/Desktop_Migration_and_Administration_Guide/part-Configuration_and_Administration.html
|
|
Configure Console Screen Lockinggroup
A console screen locking mechanism is provided in the
screen package, which is not installed by default.
|
|
Hardware Tokens for Authenticationgroup
The 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 AccessesgroupEach system should expose as little information about
itself as possible.
System banners, which are typically displayed just before a
login prompt, give out information about the service or the host's
operating system. This might include the distribution name and the
system kernel version, and the particular version of a network
service. This information can assist intruders in gaining access to
the system as it can reveal whether the system is running
vulnerable software. Most network services can be configured to
limit what information is displayed.
Many organizations implement security policies that require a
system banner provide notice of the system's ownership, provide
warning to unauthorized users, and remind authorized users of their
consent to monitoring. |
|
Implement a GUI Warning BannergroupIn 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 FirewallsgroupMost machines must be connected to a network of some
sort, and this brings with it the substantial risk of network
attack. This section discusses the security impact of decisions
about networking which must be made when configuring a system.
This section also discusses firewalls, network access
controls, and other network security frameworks, which allow
system-level rules to be written that can limit an attackers' ability
to connect to your system. These rules can specify that network
traffic should be allowed or denied from certain IP addresses,
hosts, and networks. The rules can also specify which of the
system's network services are available to particular hosts or
networks. |
|
Disable Unused InterfacesgroupNetwork interfaces expand the attack surface of the
system. Unused interfaces are not monitored or controlled, and
should be disabled.
If the system does not require network communications but still
needs to use the loopback interface, remove all files of the form
ifcfg-interface except for ifcfg-lo from
/etc/sysconfig/network-scripts:
$ sudo rm /etc/sysconfig/network-scripts/ifcfg-interface
If the system is a standalone machine with no need for network access or even
communication over the loopback device, then disable this service.
The network service can be disabled with the following command:
$ sudo systemctl disable network
|
|
Kernel Parameters Which Affect NetworkinggroupThe sysctl utility is used to set
parameters which affect the operation of the Linux kernel. Kernel parameters
which affect networking and have security implications are described here.
|
|
Network Parameters for Hosts OnlygroupIf 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 RoutersgroupCertain 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 NetworkinggroupWireless 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.
Removal of hardware provides the greatest assurance that the wireless
capability remains disabled. Acquisition policies often include provisions to
prevent the purchase of equipment that will be used in sensitive spaces and
includes wireless capabilities. If it is impractical to remove the wireless
hardware, and policy permits the device to enter sensitive spaces as long
as wireless is disabled, efforts should instead focus on disabling wireless capability
via software. |
|
Disable Wireless Through Software ConfigurationgroupIf 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. |
|
IPv6groupThe 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 Neededgroup
Despite configuration that suggests support for IPv6 has
been disabled, link-local IPv6 address auto-configuration occurs
even when only an IPv4 address is assigned. The only way to
effectively prevent execution of the IPv6 networking stack is to
instruct the system not to activate the IPv6 kernel module.
|
|
Configure IPv6 Settings if NecessarygroupA 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 ConfigurationgroupDisable the system's acceptance of router
advertisements and redirects by adding or correcting the following
line in /etc/sysconfig/network (note that this does not disable
sending router solicitations):
IPV6_AUTOCONF=no
|
|
Limit Network-Transmitted Configuration if Using Static IPv6 AddressesgroupTo limit the configuration information requested from other
systems and accepted from the network on a system that uses
statically-configured IPv6 addresses, add the following lines to
/etc/sysctl.conf:
net.ipv6.conf.default.router_solicitations = 0
net.ipv6.conf.default.accept_ra_rtr_pref = 0
net.ipv6.conf.default.accept_ra_pinfo = 0
net.ipv6.conf.default.accept_ra_defrtr = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.dad_transmits = 0
net.ipv6.conf.default.max_addresses = 1
The router_solicitations setting determines how many router
solicitations are sent when bringing up the interface. If addresses are
statically assigned, there is no need to send any solicitations.
The accept_ra_pinfo setting controls whether the system will accept
prefix info from the router.
The accept_ra_defrtr setting controls whether the system will accept
Hop Limit settings from a router advertisement. Setting it to 0 prevents a
router from changing your default IPv6 Hop Limit for outgoing packets.
The autoconf setting controls whether router advertisements can cause
the system to assign a global unicast address to an interface.
The dad_transmits setting determines how many neighbor solicitations
to send out per address (global and link-local) when bringing up an interface
to ensure the desired address is unique on the network.
The max_addresses setting determines how many global unicast IPv6
addresses can be assigned to each interface. The default is 16, but it should
be set to exactly the number of statically configured global addresses
required.
|
|
firewalldgroupThe dynamic firewall daemon firewalld provides a
dynamically managed firewall with support for network “zones” to assign
a level of trust to a network and its associated connections and interfaces.
It has support for IPv4 and IPv6 firewall settings. It supports Ethernet
bridges and has a separation of runtime and permanent configuration options.
It also has an interface for services or applications to add firewall rules
directly.
A graphical configuration tool, firewall-config, is used to configure
firewalld, which in turn uses iptables tool to communicate
with Netfilter in the kernel which implements packet filtering.
The firewall service provided by firewalld is dynamic rather than
static because changes to the configuration can be made at anytime and are
immediately implemented. There is no need to save or apply the changes. No
unintended disruption of existing network connections occurs as no part of
the firewall has to be reloaded.
|
|
Inspect and Activate Default firewalld RulesgroupFirewalls 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. NetworkManager informs firewalld to which
zone an interface belongs. An interface's assigned zone can be changed by
NetworkManager or via the firewall-config tool.
The zone settings in /etc/firewalld/ are a range of preset settings
which can be quickly applied to a network interface. These are the zones
provided by firewalld sorted according to the default trust level of the
zones from untrusted to trusted:
dropAny incoming network packets are dropped, there is no
reply. Only outgoing network connections are possible.blockAny incoming network connections are rejected with an
icmp-host-prohibited message for IPv4 and icmp6-adm-prohibited
for IPv6. Only network connections initiated from within the system are
possible.publicFor use in public areas. You do not trust the other
computers on the network to not harm your computer. Only selected incoming
connections are accepted.externalFor use on external networks with masquerading enabled
especially for routers. You do not trust the other computers on the network to
not harm your computer. Only selected incoming connections are accepted.dmzFor computers in your demilitarized zone that are
publicly-accessible with limited access to your internal network. Only selected
incoming connections are accepted.workFor use in work areas. You mostly trust the other computers
on networks to not harm your computer. Only selected incoming connections are
accepted.homeFor use in home areas. You mostly trust the other computers
on networks to not harm your computer. Only selected incoming connections are
accepted.internalFor use on internal networks. You mostly trust the
other computers on the networks to not harm your computer. Only selected
incoming connections are accepted.trustedAll network connections are accepted.
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-all
Example 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-quench
To view the network zones currently active, enter the following command as root:
# firewall-cmd --get-service
The 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-https
Finally 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 RulesetgroupThe default rules can be strengthened. The system
scripts that activate the firewall rules expect them to be defined
in configuration files under the /etc/firewalld/services
and /etc/firewalld/zones directories.
The following recommendations describe how to strengthen the
default ruleset configuration file. An alternative to editing this
configuration file is to create a shell script that makes calls to
the firewall-cmd program to load in rules under the /etc/firewalld/services
and /etc/firewalld/zones directories.
Instructions apply to both unless otherwise noted. Language and address
conventions for regular firewalld rules are used throughout this section.
|
|
Transport Layer Security Supportgroup
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
openssl). TLS provides encrypted and authenticated network
communications, and many network services include support for it. TLS or SSL
can be leveraged to avoid any plaintext transmission of sensitive data.
For information on how to use OpenSSL, see
http://www.openssl.org/docs/HOWTO/. Information on FIPS validation
of OpenSSL is available at http://www.openssl.org/docs/fips/fipsvalidation.html
and http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm.
For information on how to use and implement OpenSSL on Red Hat Enterprise Linux, see
https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/sec-Using_OpenSSL.html
|
|
Uncommon Network ProtocolsgroupThe 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. |
|
IPSec SupportgroupSupport for Internet Protocol Security (IPsec)
is provided in Red Hat Enterprise Linux 7 with Libreswan.
|
|
Configure SysloggroupThe syslog service has been the default Unix logging mechanism for
many years. It has a number of downsides, including inconsistent log format,
lack of authentication for received messages, and lack of authentication,
encryption, or reliable transport for messages sent over a network. However,
due to its long history, syslog is a de facto standard which is supported by
almost all Unix applications.
In Red Hat Enterprise Linux 7, rsyslog has replaced ksyslogd as the
syslog daemon of choice, and it includes some additional security features
such as reliable, connection-oriented (i.e. TCP) transmission of logs, the
option to log to database formats, and the encryption of log data en route to
a central logging server.
This section discusses how to configure rsyslog for
best effect, and how to use tools provided with the system to maintain and
monitor logs. |
|
Ensure Proper Configuration of Log Filesgroup
The file /etc/rsyslog.conf controls where log message are written.
These are controlled by lines called rules, which consist of a
selector and an action.
These rules are often customized depending on the role of the system, the
requirements of the environment, and whatever may enable
the administrator to most effectively make use of log data.
The default rules in Red Hat Enterprise Linux 7 are:
*.info;mail.none;authpriv.none;cron.none /var/log/messages
authpriv.* /var/log/secure
mail.* -/var/log/maillog
cron.* /var/log/cron
*.emerg *
uucp,news.crit /var/log/spooler
local7.* /var/log/boot.log
See the man page rsyslog.conf(5) for more information.
Note that the rsyslog daemon can be configured to use a timestamp format that
some log processing programs may not understand. If this occurs,
edit the file /etc/rsyslog.conf and add or edit the following line:
$ ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
|
|
Rsyslog Logs Sent To Remote Hostgroup
If system logs are to be useful in detecting malicious
activities, it is necessary to send logs to a remote server. An
intruder who has compromised the root account on a machine may
delete the log entries which indicate that the system was attacked
before they are seen by an administrator.
However, it is recommended that logs be stored on the local
host in addition to being sent to the loghost, especially if
rsyslog has been configured to use the UDP protocol to send
messages over a network. UDP does not guarantee reliable delivery,
and moderately busy sites will lose log messages occasionally,
especially in periods of high traffic which may be the result of an
attack. In addition, remote rsyslog messages are not
authenticated in any way by default, so it is easy for an attacker to
introduce spurious messages to the central log server. Also, some
problems cause loss of network connectivity, which will prevent the
sending of messages to the central server. For all of these reasons, it is
better to store log messages both centrally and on each host, so
that they can be correlated if necessary. |
|
Configure rsyslogd to Accept Remote Messages If Acting as a Log Servergroup
By default, rsyslog does not listen over the network
for log messages. If needed, modules can be enabled to allow
the rsyslog daemon to receive messages from other systems and for the system
thus to act as a log server.
If the machine is not a log server, then lines concerning these modules
should remain commented out.
|
|
Ensure All Logs are Rotated by logrotategroupEdit the file /etc/logrotate.d/syslog. Find the first
line, which should look like this (wrapped for clarity):
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler \
/var/log/boot.log /var/log/cron {
Edit this line so that it contains a one-space-separated
listing of each log file referenced in /etc/rsyslog.conf.
All logs in use on a system must be rotated regularly, or the
log files will consume disk space over time, eventually interfering
with system operation. The file /etc/logrotate.d/syslog is the
configuration file used by the logrotate program to maintain all
log files written by syslog. By default, it rotates logs weekly and
stores four archival copies of each log. These settings can be
modified by editing /etc/logrotate.conf, but the defaults are
sufficient for purposes of this guide.
Note that logrotate is run nightly by the cron job
/etc/cron.daily/logrotate. If particularly active logs need to be
rotated more often than once a day, some other mechanism must be
used. |
|
Configure Logwatch on the Central Log Servergroup
Is this machine the central log server? If so, edit the file /etc/logwatch/conf/logwatch.conf as shown below.
|
|
System Accounting with auditdgroupThe audit service provides substantial capabilities
for recording system activities. By default, the service audits about
SELinux AVC denials and certain types of security-relevant events
such as system logins, account modifications, and authentication
events performed by programs such as sudo.
Under its default configuration, auditd has modest disk space
requirements, and should not noticeably impact system performance.
NOTE: The Linux Audit daemon auditd can be configured to use
the augenrules program to read audit rules files (*.rules)
located in /etc/audit/rules.d location and compile them to create
the resulting form of the /etc/audit/audit.rules configuration file
during the daemon startup (default configuration). Alternatively, the auditd
daemon can use the auditctl utility to read audit rules from the
/etc/audit/audit.rules configuration file during daemon startup,
and load them into the kernel. The expected behavior is configured via the
appropriate ExecStartPost directive setting in the
/usr/lib/systemd/system/auditd.service configuration file.
To instruct the auditd daemon to use the augenrules program
to read audit rules (default configuration), use the following setting:
ExecStartPost=-/sbin/augenrules --load
in 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.rules
in 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)
msg=audit(1226874073.147:96)The number in parentheses is the unformatted time stamp (Epoch time)
for the event, which can be converted to standard time by using the
date command.
{ getattr }The item in braces indicates the permission that was denied. getattr
indicates the source process was trying to read the target file's status information.
This occurs before reading files. This action is denied due to the file being
accessed having the wrong label. Commonly seen permissions include getattr,
read, and write.comm="httpd"The executable that launched the process. The full path of the executable is
found in the exe= section of the system call (SYSCALL) message,
which in this case, is exe="/usr/sbin/httpd".
path="/var/www/html/file1"The path to the object (target) the process attempted to access.
scontext="unconfined_u:system_r:httpd_t:s0"The SELinux context of the process that attempted the denied action. In
this case, it is the SELinux context of the Apache HTTP Server, which is running
in the httpd_t domain.
tcontext="unconfined_u:object_r:samba_share_t:s0"The SELinux context of the object (target) the process attempted to access.
In this case, it is the SELinux context of file1. Note: the samba_share_t
type is not accessible to processes running in the httpd_t domain. From the system call (SYSCALL) message, two items are of interest:
success=no: indicates whether the denial (AVC) was enforced or not.
success=no indicates the system call was not successful (SELinux denied
access). success=yes indicates the system call was successful - this can
be seen for permissive domains or unconfined domains, such as initrc_t
and kernel_t.
exe="/usr/sbin/httpd": the full path to the executable that launched
the process, which in this case, is exe="/usr/sbin/httpd".
|
|
Configure auditd Data Retentiongroup
The audit system writes data to /var/log/audit/audit.log. By default,
auditd rotates 5 logs by size (6MB), retaining a maximum of 30MB of
data in total, and refuses to write entries when the disk is too
full. This minimizes the risk of audit data filling its partition
and impacting other services. This also minimizes the risk of the audit
daemon temporarily disabling the system if it cannot write audit log (which
it can be configured to do).
For a busy
system or a system which is thoroughly auditing system activity, the default settings
for data retention may be
insufficient. The log file size needed will depend heavily on what types
of events are being audited. First configure auditing to log all the events of
interest. Then monitor the log size manually for awhile to determine what file
size will allow you to keep the required data for the correct time period.
Using a dedicated partition for /var/log/audit prevents the
auditd logs from disrupting system functionality if they fill, and,
more importantly, prevents other activity in /var from filling the
partition and stopping the audit trail. (The audit logs are size-limited and
therefore unlikely to grow without bound unless configured to do so.) Some
machines may have requirements that no actions occur which cannot be audited.
If this is the case, then auditd can be configured to halt the machine
if it runs out of space. Note: Since older logs are rotated,
configuring auditd this way does not prevent older logs from being
rotated away before they can be viewed.
If your system is configured to halt when logging cannot be performed, make
sure this can never happen under normal circumstances! Ensure that
/var/log/audit is on its own partition, and that this partition is
larger than the maximum amount of data auditd will retain
normally.
references:
AU-11, 138 |
|
Configure auditd Rules for Comprehensive AuditinggroupThe auditd program can perform comprehensive
monitoring of system activity. This section describes recommended
configuration settings for comprehensive auditing, but a full
description of the auditing system's capabilities is beyond the
scope of this guide. The mailing list linux-audit@redhat.com exists
to facilitate community discussion of the auditing system.
The audit subsystem supports extensive collection of events, including:
Tracing of arbitrary system calls (identified by name or number)
on entry or exit.Filtering by PID, UID, call success, system call argument (with
some limitations), etc.Monitoring of specific files for modifications to the file's
contents or metadata.
Auditing rules at startup are controlled by the file /etc/audit/audit.rules.
Add rules to it to meet the auditing requirements for your organization.
Each line in /etc/audit/audit.rules represents a series of arguments
that can be passed to auditctl and can be individually tested
during runtime. See documentation in /usr/share/doc/audit-VERSION and
in the related man pages for more details.
If copying any example audit rulesets from /usr/share/doc/audit-VERSION,
be sure to comment out the
lines containing arch= which are not appropriate for your system's
architecture. Then review and understand the following rules,
ensuring rules are activated as needed for the appropriate
architecture.
After reviewing all the rules, reading the following sections, and
editing as needed, the new rules can be activated as follows:
$ sudo service auditd restart
|
|
Records Events that Modify Date and Time InformationgroupArbitrary 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 ControlsgroupAt a minimum the audit system should collect file permission
changes for all users and root. Note that the "-F arch=b32" lines should be
present even on a 64 bit system. These commands identify system calls for
auditing. Even if the system is 64 bit it can still execute 32 bit system
calls. Additionally, these rules can be configured in a number of ways while
still achieving the desired effect. An example of this is that the "-S" calls
could be split up and placed on separate lines, however, this is less efficient.
Add the following to /etc/audit/audit.rules:
-a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
If your system is 64 bit then these lines should be duplicated and the
arch=b32 replaced with arch=b64 as follows:
-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod
-a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod
|
|
Servicesgroup
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.
Red Hat Enterprise Linux 7 provides a convenient minimal install option that essentially installs the bare necessities for a functional
system. When building Red Hat Enterprise Linux 7 servers, it is highly recommended to select the minimal packages and then build up
the system from there.
|
|
Obsolete ServicesgroupThis 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.
Organizations which are running these services should
switch to more secure equivalents as soon as possible.
If it remains absolutely necessary to run one of
these services for legacy reasons, care should be taken to restrict
the service as much as possible, for instance by configuring host
firewall software such as firewalld to restrict access to the
vulnerable service to only those remote hosts which have a known
need to use it. |
|
XinetdgroupThe xinetd service acts as a dedicated listener for some
network services (mostly, obsolete ones) and can be used to provide access
controls and perform some logging. It has been largely obsoleted by other
features, and it is not installed by default. The older Inetd service
is not even available as part of Red Hat Enterprise Linux 7. |
|
TelnetgroupThe 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 RexecgroupThe Berkeley r-commands are legacy services which
allow cleartext remote access and have an insecure trust
model. |
|
NISgroupThe 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 Servergroup
TFTP is a lightweight version of the FTP protocol which has
traditionally been used to configure networking equipment. However,
TFTP provides little security, and modern versions of networking
operating systems frequently support configuration via SSH or other
more secure protocols. A TFTP server should be run only if no more
secure method of supporting existing equipment can be
found. |
|
Chat/Messaging Servicesgroup
The talk software makes it possible for users to send and receive messages
across systems through a terminal session.
|
|
Base ServicesgroupThis 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 DaemonsgroupThe 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 Necessarygroup
The /etc/cron.allow and /etc/at.allow files contain lists of users who are allowed
to use cron and at to delay execution of processes. If these files exist and
if the corresponding files /etc/cron.deny and /etc/at.deny do not exist,
then only users listed in the relevant allow files can run the crontab and at
commands to submit jobs to be run at scheduled intervals.
On many systems, only the system administrator needs the ability to schedule
jobs. Note that even if a given user is not listed in cron.allow, cron jobs can
still be run as that user. The cron.allow file controls only administrative access
to the crontab command for scheduling and modifying cron jobs.
To restrict at and cron to only authorized users:
Remove the cron.deny file:$ sudo rm /etc/cron.denyEdit /etc/cron.allow, adding one line for each user allowed to use the crontab command to create cron jobs.Remove the at.deny file:$ sudo rm /etc/at.denyEdit /etc/at.allow, adding one line for each user allowed to use the at command to create at jobs.
|
|
SSH ServergroupThe SSH protocol is recommended for remote login and
remote file transfer. SSH provides confidentiality and integrity
for data exchanged between two systems, as well as server
authentication, through the use of public key cryptography. The
implementation included with the system is called OpenSSH, and more
detailed documentation is available from its website,
http://www.openssh.org. Its server program is called sshd and
provided by the RPM package openssh-server. |
|
Configure OpenSSH Server if NecessarygroupIf the system needs to act as an SSH server, then
certain changes should be made to the OpenSSH daemon configuration
file /etc/ssh/sshd_config. The following recommendations can be
applied to this file. See the sshd_config(5) man page for more
detailed information. |
|
Strengthen Firewall Configuration if PossiblegroupIf the SSH server is expected to only receive connections from
the local network, then strengthen the default firewall rule for the SSH service
to only accept connections from the appropriate network segment(s).
Determine an appropriate network block, netwk, network mask, mask, and
network protocol, ip_protocol, representing the machines on your network which will
be allowed to access this SSH server.
Run the following command:
firewall-cmd --permanent --add-rich-rule='rule family="ip_protocol" source address="netwk/mask" service name="ssh" accept'
|
|
X Window SystemgroupThe X Window System implementation included with the
system is called X.org. |
|
Disable X WindowsgroupUnless 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. |
|
Avahi ServergroupThe 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 PossiblegroupBecause 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 Necessarygroup
If your system requires the Avahi daemon, its configuration can be restricted
to improve security. The Avahi daemon configuration file is
/etc/avahi/avahi-daemon.conf. The following security recommendations
should be applied to this file:
See the avahi-daemon.conf(5) man page, or documentation at
http://www.avahi.org, for more detailed information about the configuration options.
|
|
Print SupportgroupThe 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 NecessarygroupCUPS provides the ability to easily share local printers with
other machines over the network. It does this by allowing machines to share
lists of available printers. Additionally, each machine that runs the CUPS
service can potentially act as a print server. Whenever possible, the printer
sharing and print server capabilities of CUPS should be limited or disabled.
The following recommendations should demonstrate how to do just that.
|
|
DHCPgroupThe Dynamic Host Configuration Protocol (DHCP) allows
systems to request and obtain an IP address and other configuration
parameters from a server.
This guide recommends configuring networking on clients by manually editing
the appropriate files under /etc/sysconfig. Use of DHCP can make client
systems vulnerable to compromise by rogue DHCP servers, and should be avoided
unless necessary. If using DHCP is necessary, however, there are best practices
that should be followed to minimize security risk.
|
|
Disable DHCP Servergroup
The DHCP server dhcpd is not installed or activated by
default. If the software was installed and activated, but the
system does not need to act as a DHCP server, it should be disabled
and removed.
|
|
Disable DHCP ServergroupIf the system must act as a DHCP server, the configuration
information it serves should be minimized. Also, support for other protocols
and DNS-updating schemes should be explicitly disabled unless needed. The
configuration file for dhcpd is called /etc/dhcp/dhcpd.conf. The file
begins with a number of global configuration options. The remainder of the file
is divided into sections, one for each block of addresses offered by dhcpd,
each of which contains configuration options specific to that address
block. |
|
Minimize Served InformationgroupEdit /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
references:
CM-7 |
|
Disable DHCP Clientgroup
DHCP is the default network configuration method provided by the system
installer, and common on many networks. Nevertheless, manual management
of IP addresses for systems implies a greater degree of management and
accountability for network activity.
|
|
Configure DHCP Client if NecessarygroupIf DHCP must be used, then certain configuration changes can
minimize the amount of information it receives and applies from the network,
and thus the amount of incorrect information a rogue DHCP server could
successfully distribute. For more information on configuring dhclient, see the
dhclient(8) and dhclient.conf(5) man pages. |
|
Minimize the DHCP-Configured OptionsgroupCreate the file /etc/dhcp/dhclient.conf, and add an
appropriate setting for each of the ten configuration settings which can be
obtained via DHCP. For each setting, do one of the following:
If the setting should not be configured remotely by the DHCP server,
select an appropriate static value, and add the line:
supersede setting value;
If the setting should be configured remotely by the DHCP server, add the lines:
request setting;
require setting;
For example, suppose the DHCP server should provide only the IP address itself
and the subnet mask. Then the entire file should look like:
supersede domain-name "example.com";
supersede domain-name-servers 192.168.1.2;
supersede nis-domain "";
supersede nis-servers "";
supersede ntp-servers "ntp.example.com ";
supersede routers 192.168.1.1;
supersede time-offset -18000;
request subnet-mask;
require subnet-mask;
|
|
Network Time ProtocolgroupThe 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.
If every system on a network reliably reports the same time, then it is much
easier to correlate log messages in case of an attack. In addition, a number of
cryptographic protocols (such as Kerberos) use timestamps to prevent certain
types of attacks. If your network does not have synchronized time, these
protocols may be unreliable or even unusable.
Depending on the specifics of the network, global time accuracy may be just as
important as local synchronization, or not very important at all. If your
network is connected to the Internet, using a public timeserver (or one
provided by your enterprise) provides globally accurate timestamps which may be
essential in investigating or responding to an attack which originated outside
of your network.
A typical network setup involves a small number of internal systems operating
as NTP servers, and the remainder obtaining time information from those
internal servers.
There is a choice between the daemons ntpd and chronyd, which
are available from the repositories in the ntp and chrony
packages respectively.
The default chronyd daemon can work well when external time references
are only intermittently accesible, can perform well even when the network is
congested for longer periods of time, can usually synchronize the clock faster
and with better time accuracy, and quickly adapts to sudden changes in the rate
of the clock, for example, due to changes in the temperature of the crystal
oscillator. Chronyd should be considered for all systems which are
frequently suspended or otherwise intermittently disconnected and reconnected
to a network. Mobile and virtual systems for example.
The ntpd NTP daemon fully supports NTP protocol version 4 (RFC 5905),
including broadcast, multicast, manycast clients and servers, and the orphan
mode. It also supports extra authentication schemes based on public-key
cryptography (RFC 5906). The NTP daemon (ntpd) should be considered
for systems which are normally kept permanently on. Systems which are required
to use broadcast or multicast IP, or to perform authentication of packets with
the Autokey protocol, should consider using ntpd.
Refer to https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/ch-Configuring_NTP_Using_the_chrony_Suite.html for more detailed comparison of features of chronyd
and ntpd daemon features respectively, and for further guidance how to
choose between the two NTP daemons.
The upstream manual pages at http://chrony.tuxfamily.org/manual.html for
chronyd and http://www.ntp.org for ntpd provide additional
information on the capabilities and configuration of each of the NTP daemons.
|
|
Mail Server Softwaregroup
Mail servers are used to send and receive email over the network.
Mail is a very common service, and Mail Transfer Agents (MTAs) are obvious
targets of network attack.
Ensure that machines are not running MTAs unnecessarily,
and configure needed MTAs as defensively as possible.
Very few systems at any site should be configured to directly receive email over the
network. Users should instead use mail client programs to retrieve email
from a central server that supports protocols such as IMAP or POP3.
However, it is normal for most systems to be independently capable of sending email,
for instance so that cron jobs can report output to an administrator.
Most MTAs, including Postfix, support a submission-only mode in which mail can be sent from
the local system to a central site MTA (or directly delivered to a local account),
but the system still cannot receive mail directly over a network.
The alternatives program in Red Hat Enterprise Linux permits selection of other mail server software
(such as Sendmail), but Postfix is the default and is preferred.
Postfix was coded with security in mind and can also be more effectively contained by
SELinux as its modular design has resulted in separate processes performing specific actions.
More information is available on its website, http://www.postfix.org.
|
|
Configure SMTP For Mail ClientsgroupThis section discusses settings for Postfix in a submission-only
e-mail configuration. |
|
Configure Operating System to Protect Mail Server
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 AUTHgroup
If SMTP AUTH is to be used, the use of SSL to protect credentials in transit is strongly recommended.
There are also configurations for which it may be desirable to encrypt all mail in transit from one MTA to another,
though such configurations are beyond the scope of this guide. In either event, the steps for creating and installing
an SSL certificate are independent of the MTA in use, and are described here.
|
|
Ensure Security of Postfix SSL CertificategroupCreate 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/mail
Using removable media or some other secure transmission format, install the files generated in the previous
step onto the mail server:
/etc/pki/tls/mail/serverkey.pem: the private key mailserverkey.pem
/etc/pki/tls/mail/servercert.pem: the certificate file mailservercert.pem
Verify the ownership and permissions of these files:
$ 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.pem
Verify 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 NecessarygroupPostfix stores its configuration files in the directory
/etc/postfix by default. The primary configuration file is
/etc/postfix/main.cf.
|
|
Configure Postfix Resource Usage to Limit Denial of Service AttacksgroupEdit /etc/postfix/main.cf. Edit the following lines to
configure the amount of system resources Postfix can consume:
default_process_limit = 100
smtpd_client_connection_count_limit = 10
smtpd_client_connection_rate_limit = 30
queue_minfree = 20971520
header_size_limit = 51200
message_size_limit = 10485760
smtpd_recipient_limit = 100
The values here are examples.
|
|
Control Mail RelayinggroupPostfix's mail relay controls are implemented with the help of the
smtpd recipient restrictions option, which controls the restrictions placed on
the SMTP dialogue once the sender and recipient envelope addresses are known.
The guidance in the following sections should be applied to all machines. If
there are machines which must be allowed to relay mail, but which cannot be
trusted to relay unconditionally, configure SMTP AUTH with SSL support.
|
|
Configure Trusted Networks and HostsgroupEdit /etc/postfix/main.cf, and configure the contents of
the mynetworks variable in one of the following ways:
If any machine in the subnet containing the MTA may be trusted to relay
messages, add or correct the following line:
mynetworks_style = subnet
This is also the default setting, and is in effect if all
my_networks_style directives are commented.If only the MTA host itself is trusted to relay messages, add or correct
the following line:
mynetworks_style = hostIf the set of machines which can relay is more complicated, manually
specify an entry for each netblock or IP address which is trusted to relay by
setting the mynetworks variable directly:
mynetworks = 10.0.0.0/16, 192.168.1.0/24, 127.0.0.1
|
|
Enact SMTP Relay Restrictionsgroup
To configure Postfix to restrict addresses to which it
will send mail, see:
http://www.postfix.org/SMTPD_ACCESS_README.html#danger
The full contents of smtpd_recipient_restrictions will
vary by site, since this is a common place to put spam restrictions and other
site-specific options. The permit_mynetworks option allows all mail to
be relayed from the machines in mynetworks. Then, the
reject_unauth_destination option denies all mail whose destination
address is not local, preventing any other machines from relaying. These two
options should always appear in this order, and should usually follow one
another immediately unless SMTP AUTH is used.
|
|
Enact SMTP Recipient Restrictionsgroup
To configure Postfix to restrict addresses to which it
will send mail, see:
http://www.postfix.org/SMTPD_ACCESS_README.html#danger
The full contents of smtpd_recipient_restrictions will
vary by site, since this is a common place to put spam restrictions and other
site-specific options. The permit_mynetworks option allows all mail to
be relayed from the machines in mynetworks. Then, the
reject_unauth_destination option denies all mail whose destination
address is not local, preventing any other machines from relaying. These two
options should always appear in this order, and should usually follow one
another immediately unless SMTP AUTH is used.
|
|
Require SMTP AUTH Before Relaying from Untrusted ClientsgroupSMTP 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 AUTHgroup
Postfix 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.
|
|
LDAPgroupLDAP 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 ClientsgroupThis 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
system-config-authentication. However, these tools do not provide as
much control over configuration as manual editing of configuration files. The
authconfig tools do not allow you to specify locations of SSL certificate
files, which is useful when trying to use SSL cleanly across several protocols.
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.
|
|
Configure OpenLDAP ServergroupThis 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 FilesgroupCreate 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/ldap
Using removable media or some other secure transmission format, install the certificate files
onto the LDAP server:
/etc/pki/tls/ldap/serverkey.pem: the private key ldapserverkey.pem/etc/pki/tls/ldap/servercert.pem: the certificate file ldapservercert.pem
Verify the ownership and permissions of these files:
$ 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.pem
Verify 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.pem
As a result of these steps, the LDAP server will have access to its own private
certificate and the key with which that certificate is encrypted, and to the
public certificate file belonging to the CA. Note that it would be possible for
the key to be protected further, so that processes running as ldap could not
read it. If this were done, the LDAP server process would need to be restarted
manually whenever the server rebooted.
|
|
NFS and RPCgroupThe 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 PossiblegroupIf 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.
|
|
Disable Services Used Only by NFSgroupIf NFS is not needed, disable the NFS client daemons nfslock, rpcgssd, and rpcidmapd.
All of these daemons run with elevated privileges, and many listen for network
connections. If they are not needed, they should be disabled to improve system
security posture. |
|
Disable netfs if PossiblegroupTo determine if any network filesystems handled by netfs are
currently mounted on the system execute the following command:
$ mount -t nfs,nfs4,smbfs,cifs,ncpfs
If the command did not return any output then disable netfs.
|
|
Configure All Machines which Use NFSgroupThe steps in this section are appropriate for all machines which
run NFS, whether they operate as clients or as servers. |
|
Make Each Machine a Client or a Server, not BothgroupIf NFS must be used, it should be deployed in the simplest
configuration possible to avoid maintainability problems which may lead to
unnecessary security exposure. Due to the reliability and security problems
caused by NFS (specially NFSv3 and NFSv2), it is not a good idea for machines
which act as NFS servers to also mount filesystems via NFS. At the least,
crossed mounts (the situation in which each of two servers mounts a filesystem
from the other) should never be used.
|
|
Configure NFS Services to Use Fixed Ports (NFSv3 and NFSv2)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 firewalld.
Therefore, restrict each service to always use a given port, so that
firewalling can be done effectively. Note that, because of the way RPC is
implemented, it is not possible to disable the RPC Bind service even if ports
are assigned statically to all RPC services.
In NFSv4, the mounting and locking protocols have been incorporated into the
protocol, and the server listens on the the well-known TCP port 2049. As such,
NFSv4 does not need to interact with the rpcbind, lockd, and rpc.statd
daemons, which can and should be disabled in a pure NFSv4 environment. The
rpc.mountd daemon is still required on the NFS server to setup
exports, but is not involved in any over-the-wire operations.
|
|
Configure NFS ClientsgroupThe steps in this section are appropriate for machines which operate as NFS clients. |
|
Disable NFS Server Daemonsgroup
There is no need to run the NFS server daemons nfs and
rpcsvcgssd except on a small number of properly secured machines
designated as NFS servers. Ensure that these daemons are turned off on
clients. |
|
Mount Remote Filesystems with Restrictive OptionsgroupEdit the file /etc/fstab. For each filesystem whose type
(column 3) is nfs or nfs4, add the text
,nodev,nosuid to the list of mount options in column 4. If
appropriate, also add ,noexec.
See the section titled "Restrict Partition Mount Options" for a description of
the effects of these options. In general, execution of files mounted via NFS
should be considered risky because of the possibility that an adversary could
intercept the request and substitute a malicious file. Allowing setuid files to
be executed from remote servers is particularly risky, both for this reason and
because it requires the clients to extend root-level trust to the NFS
server. |
|
Configure NFS ServersgroupThe steps in this section are appropriate for machines which operate as NFS servers. |
|
Configure the Exports File RestrictivelygroupLinux's NFS implementation uses the file /etc/exports to control what filesystems
and directories may be accessed via NFS. (See the exports(5) manpage for more information about the
format of this file.)
The syntax of the exports file is not necessarily checked fully on reload, and syntax errors
can leave your NFS configuration more open than intended. Therefore, exercise caution when modifying
the file.
The syntax of each line in /etc/exports is:
/DIR host1(opt1,opt2) host2(opt3)
where /DIR is a directory or filesystem to export, hostN is an IP address, netblock,
hostname, domain, or netgroup to which to export, and optN is an option.
|
|
Use Access Lists to Enforce Authorization RestrictionsgroupWhen configuring NFS exports, ensure that each export line in /etc/exports contains
a list of hosts which are allowed to access that export. If no hosts are specified on an export line,
then that export is available to any remote host which requests it. All lines of the exports file should
specify the hosts (or subnets, if needed) which are allowed to access the exported directory, so that
unknown or remote hosts will be denied.
Authorized hosts can be specified in several different formats:
Name or alias that is recognized by the resolverFully qualified domain nameIP addressIP subnets in the format address/netmask or address/CIDR
|
|
Export Filesystems Read-Only if PossiblegroupIf a filesystem is being exported so that users can view the files in a convenient
fashion, but there is no need for users to edit those files, exporting the filesystem read-only
removes an attack vector against the server. The default filesystem export mode is ro,
so do not specify rw without a good reason.
|
|
DNS ServergroupMost 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 Servergroup
DNS software should be disabled on any machine which does not
need to be a nameserver. Note that the BIND DNS server software is
not installed on Red Hat Enterprise Linux 7 by default. The remainder of this section
discusses secure configuration of machines which must be
nameservers.
|
|
Isolate DNS from Other ServicesgroupThis 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 ServersgroupSince DNS is
a high-risk service which must frequently be made available to the entire
Internet, it is strongly recommended that no other services be offered by
machines which act as organizational DNS servers. |
|
Run DNS Software in a chroot JailgroupInstall the bind-chroot package:
$ sudo yum install bind-chroot
Place 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.conf
Create and populate an appropriate zone directory within the jail, based on the
options directive. If your named.conf includes:
options {
directory "/path/to/DIRNAME ";
...
}
then copy that directory and its contents from the original zone directory:
$ sudo cp -r /path/to/DIRNAME /var/named/chroot/DIRNAME
Add or correct the following line within /etc/sysconfig/named:
ROOTDIR=/var/named/chroot
|
|
Protect DNS Data from Tampering or AttackgroupThis 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 QueriesgroupIs it possible to run external and internal nameservers on
separate machines? If so, follow the configuration guidance in this section. On
the external nameserver, edit /etc/named.conf to add or correct the
following directives:
options {
allow-query { any; };
recursion no;
...
};
zone "example.com " IN {
...
};
On the internal nameserver, edit /etc/named.conf. Add or correct the
following directives, where SUBNET is the numerical IP representation of your
organization in the form xxx.xxx.xxx.xxx/xx:
acl internal {
SUBNET ;
localhost;
};
options {
allow-query { internal; };
...
};
zone "internal.example.com " IN {
...
};
|
|
Use Views to Partition External and Internal InformationgroupIf it is not possible to run external and internal nameservers on
separate physical machines, run BIND9 and simulate this feature using views.
Edit /etc/named.conf. Add or correct the following directives (where
SUBNET is the numerical IP representation of your organization in the form
xxx.xxx.xxx.xxx/xx):
acl internal {
SUBNET ;
localhost;
};
view "internal-view" {
match-clients { internal; };
zone "." IN {
type hint;
file "db.cache";
};
zone "internal.example.com " IN {
...
};
};
view "external-view" {
match-clients { any; };
recursion no;
zone "example.com " IN {
...
};
};
|
|
FTP ServergroupFTP is a common method for allowing remote access to
files. Like telnet, the FTP protocol is unencrypted, which means
that passwords and other data transmitted during the session can be
captured and that the session is vulnerable to hijacking.
Therefore, running the FTP server software is not recommended.
However, there are some FTP server configurations which may
be appropriate for some environments, particularly those which
allow only read-only anonymous access as a means of downloading
data available to the public. |
|
Disable vsftpd if Possiblegroup |
|
Use vsftpd to Provide FTP Service if Necessarygroup |
|
Use vsftpd to Provide FTP Service if NecessarygroupThe primary vsftpd configuration file is
/etc/vsftpd.conf, if that file exists, or
/etc/vsftpd/vsftpd.conf if it does not.
|
|
Restrict the Set of Users Allowed to Access FTPgroupThis 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 NecessarygroupIf there is a mission-critical reason for users to access their accounts via the insecure FTP protocol, limit the set of users who are allowed this access. Edit the vsftpd configuration file. Add or correct the following configuration options:
userlist_enable=YES
userlist_file=/etc/vsftp.ftpusers
userlist_deny=NO
Edit the file /etc/vsftp.ftpusers. For each user USERNAME who should be allowed to access the system via FTP, add a line containing that user's name:
USERNAME
If anonymous access is also required, add the anonymous usernames to /etc/vsftp.ftpusers as well.
anonymous
ftp
|
|
Configure Firewalls to Protect the FTP ServergroupBy default, firewalld
blocks access to the ports used by the web server.
To configure firewalld to allow access, run the following command(s):
firewall-cmd --permanent --add-service=ftp
|
|
Web ServergroupThe web server is responsible for providing access to
content via the HTTP protocol. Web servers represent a significant
security risk because:
The HTTP port is commonly probed by malicious sourcesWeb server software is very complex, and includes a long
history of vulnerabilitiesThe HTTP protocol is unencrypted and vulnerable to passive
monitoring
The system's default web server software is Apache 2 and is
provided in the RPM package httpd. |
|
Disable Apache if PossiblegroupIf 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 NecessarygroupIf httpd was not installed and activated, but the system
needs to act as a web server, then it should be installed on the system. Follow these
guidelines to install it defensively. The httpd package can be installed with
the following command:
$ sudo yum install httpd
This method of installation is recommended over installing the "Web Server"
package group during the system installation process. The Web Server package
group includes many packages which are likely extraneous, while the
command-line method installs only the required httpd package itself.
|
|
Confirm Minimal Built-in Modules InstalledgroupThe default httpd installation minimizes the number of
modules that are compiled directly into the binary (core prefork http_core
mod_so). This minimizes risk by limiting the capabilities allowed by the
web server.
Query the set of compiled-in modules using the following command:
$ httpd -l
If the number of compiled-in modules is significantly larger than the
aforementioned set, this guide recommends 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 ConfigurationgroupThe httpd configuration file is
/etc/httpd/conf/httpd.conf. Apply the recommendations in the remainder
of this section to this file. |
|
Restrict Web Server Information Leakagegroup
The ServerTokens and ServerSignature directives determine how
much information the web server discloses about the configuration of the
system. |
|
Minimize Web Server Loadable Modulesgroup
A default installation of httpd includes a plethora of dynamically shared objects (DSO)
that are loaded at run-time. Unlike the aforementioned compiled-in modules, a DSO can be
disabled in the configuration file by removing the corresponding LoadModule directive.
Note: A DSO only provides additional functionality if associated directives are included
in the httpd configuration file. It should also be noted that removing a DSO will produce
errors on httpd startup if the configuration file contains directives that apply to that
module. Refer to http://httpd.apache.org/docs/ for details on which directives
are associated with each DSO.
Following each DSO removal, the configuration can be tested with the following command
to check if everything still works:
$ sudo service httpd configtest
The purpose of each of the modules loaded by default will now be addressed one at a time.
If none of a module's directives are being used, remove it.
|
|
httpd Core Modulesgroup
These modules comprise a basic subset of modules that are likely needed for base httpd
functionality; ensure they are not commented out in /etc/httpd/conf/httpd.conf:
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule authn_default_module modules/mod_authn_default.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_default_module modules/mod_authz_default.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule logio_module modules/mod_logio.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mome.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
LoadModule alias_module modules/mod_alias.so
Minimizing the number of loadable modules available to the web server reduces risk
by limiting the capabilities allowed by the web server.
|
|
Minimize Modules for HTTP Basic Authenticationgroup
The following modules are necessary if this web server will provide content that will
be restricted by a password.
Authentication can be performed using local plain text password files (authn_file),
local DBM password files (authn_dbm) or an LDAP directory. The only module required by
the web server depends on your choice of authentication. Comment out the modules you don't
need from the following:
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authn_dbm_module modules/mod_authn_dbm.so
authn_alias allows for authentication based on aliases. authn_anon
allows anonymous authentication similar to that of anonymous ftp sites. authz_owner
allows authorization based on file ownership. authz_dbm allows for authorization
based on group membership if the web server is using DBM authentication.
If the above functionality is unnecessary, comment out the related module:
#LoadModule authn_alias_module modules/mod_authn_alias.so
#LoadModule authn_anon_module modules/mod_authn_anon.so
#LoadModule authz_owner_module modules/mod_authz_owner.so
#LoadModule authz_dbm_module modules/mod_authz_dbm.so
|
|
Minimize Various Optional Componentsgroup
The following modules perform very specific tasks, sometimes providing access to
just a few additional directives. If such functionality is not required (or if you
are not using these directives), comment out the associated module:
External filtering (response passed through external program prior to client delivery)
#LoadModule ext_filter_module modules/mod_ext_filter.soUser-specified Cache Control and Expiration
#LoadModule expires_module modules/mod_expires.soCompression Output Filter (provides content compression prior to client delivery)
#LoadModule deflate_module modules/mod_deflate.soHTTP Response/Request Header Customization
#LoadModule headers_module modules/mod_headers.soUser activity monitoring via cookies
#LoadModule usertrack_module modules/mod_usertrack.soDynamically configured mass virtual hosting
#LoadModule vhost_alias_module modules/mod_vhost_alias.so
Minimizing the number of loadable modules available to the web server reduces risk
by limiting the capabilities allowed by the web server.
|
|
Minimize Configuration Files Includedgroup
The Include directive directs httpd to load supplementary configuration files
from a provided path. The default configuration loads all files that end in .conf
from the /etc/httpd/conf.d directory.
To restrict excess configuration, the following line should be commented out and
replaced with Include directives that only reference required configuration files:
#Include conf.d/*.conf
If the above change was made, ensure that the SSL encryption remains loaded by
explicitly including the corresponding configuration file:
Include conf.d/ssl.conf
If PHP is necessary, a similar alteration must be made:
Include conf.d/php.conf
Explicitly listing the configuration files to be loaded during web server start-up avoids
the possibility of unwanted or malicious configuration files to be automatically included as
part of the server's running configuration.
|
|
Directory Restrictionsgroup
The Directory tags in the web server configuration file allow finer grained access
control for a specified directory. All web directories should be configured on a
case-by-case basis, allowing access only where needed.
|
|
Use Appropriate Modules to Improve httpd's Securitygroup
Among the modules available for httpd are several whose use may improve the
security of the web server installation. This section recommends and discusses
the deployment of security-relevant modules.
|
|
Deploy mod_sslgroup
Because HTTP is a plain text protocol, all traffic is susceptible to passive
monitoring. If there is a need for confidentiality, SSL should be configured
and enabled to encrypt content.
Note: mod_nss is a FIPS 140-2 certified alternative to mod_ssl.
The modules share a considerable amount of code and should be nearly identical
in functionality. If FIPS 140-2 validation is required, then mod_nss should
be used. If it provides some feature or its greater compatibility is required,
then mod_ssl should be used.
|
|
Deploy mod_securitygroup
The security module provides an application level firewall for httpd.
Following its installation with the base ruleset, specific configuration advice can be found at
http://www.modsecurity.org/ to design a policy that best matches the security needs of
the web applications. Usage of mod_security is highly recommended for some environments,
but it should be noted this module does not ship with Red Hat Enterprise Linux itself,
and instead is provided via Extra Packages for Enterprise Linux (EPEL).
For more information on EPEL please refer to http://fedoraproject.org/wiki/EPEL.
|
|
Use Denial-of-Service Protection Modulesgroup
Denial-of-service attacks are difficult to detect and prevent while maintaining
acceptable access to authorized users. However, some traffic-shaping
modules can be used to address the problem. Well-known DoS protection modules include:
mod_cband mod_bwshare mod_limitipconn mod_evasive
Denial-of-service prevention should be implemented for a web server if such a threat exists.
However, specific configuration details are very dependent on the environment and often best left
at the discretion of the administrator.
|
|
Configure PHP Securelygroup
PHP is a widely-used and often misconfigured server-side scripting language. It should
be used with caution, but configured appropriately when needed.
Review /etc/php.ini and make the following changes if possible:
# Do not expose PHP error messages to external users
display_errors = Off
# Enable safe mode
safe_mode = On
# Only allow access to executables in isolated directory
safe_mode_exec_dir = php-required-executables-path
# Limit external access to PHP environment
safe_mode_allowed_env_vars = PHP_
# Restrict PHP information leakage
expose_php = Off
# Log all errors
log_errors = On
# Do not register globals for input data
register_globals = Off
# Minimize allowable PHP post size
post_max_size = 1K
# Ensure PHP redirects appropriately
cgi.force_redirect = 0
# Disallow uploading unless necessary
file_uploads = Off
# Disallow treatment of file requests as fopen calls
allow_url_fopen = Off
# Enable SQL safe mode
sql.safe_mode = On
|
|
Configure Operating System to Protect Web Servergroup
The following configuration steps should be taken on the machine which hosts the
web server, in order to provide as safe an environment as possible for the web server.
|
|
Restrict File and Directory Accessgroup
Minimize access to critical httpd files and directories.
|
|
Configure firewalld to Allow Access to the Web Servergroup
By default, firewalld
blocks access to the ports used by the web server.
To configure firewalld to allow access, run the following command(s):
firewall-cmd --permanent --add-service=http
To configure firewalld to allow access, run the following command(s):
firewall-cmd --permanent --add-service=https
|
|
Run httpd in a chroot Jail if Practicalgroup
Running httpd inside a chroot jail is designed to isolate the
web server process to a small section of the filesystem, limiting the damage if
it is compromised. Versions of Apache greater than 2.2.10 (such as the one
included with Red Hat Enterprise Linux 7) provide the ChrootDir directive. To run Apache
inside a chroot jail in /chroot/apache, add the following line to
/etc/httpd/conf/httpd.conf: ChrootDir /chroot/apache This
necessitates placing all files required by httpd inside
/chroot/apache , including httpd's binaries, modules,
configuration files, and served web pages. The details of this configuration
are beyond the scope of this guide. This may also require additional SELinux
configuration.
|
|
IMAP and POP3 ServergroupDovecot 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 DovecotgroupIf the system does not need to operate as an IMAP or
POP3 server, the dovecot software should be disabled and removed.
|
|
Configure Dovecot if NecessarygroupIf 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 ProtocolsgroupDovecot supports the IMAP and POP3 protocols, as well as
SSL-protected versions of those protocols. Configure the Dovecot server
to support only the protocols needed by your site. Edit /etc/dovecot/dovecot.conf.
Add or correct the following lines, replacing PROTOCOL with
only the subset of protocols (imap, imaps,
pop3, pop3s) required:
protocols = PROTOCOL
If possible, require SSL protection for all transactions. The SSL
protocol variants listen on alternate ports (995 instead of 110 for
pop3s, and 993 instead of 143 for imaps), and require SSL-aware clients.
An alternate approach is to listen on the standard port and require the
client to use the STARTTLS command before authenticating.
|
|
Enable SSL SupportgroupSSL 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 ServergroupThe default firewalld configuration does not allow inbound
access to any services. This modification will allow remote hosts to
initiate connections to the IMAP daemon, while keeping all other ports
on the server in their default protected state.
To configure firewalld to allow access, run the following command(s):
firewall-cmd --permanent --add-port=143/tcp and
|
|
Samba(SMB) Microsoft Windows File Sharing ServergroupWhen properly configured, the Samba service allows
Linux machines to provide file and print sharing to Microsoft
Windows machines. There are two software packages that provide
Samba support. The first, samba-client, provides a series of
command line tools that enable a client machine to access Samba
shares. The second, simply labeled samba, provides the Samba
service. It is this second package that allows a Linux machine to
act as an Active Directory server, a domain controller, or as a
domain member. Only the samba-client package is installed by
default. |
|
Disable Samba if Possiblegroup
Even after the Samba server package has been installed, it
will remain disabled. Do not enable this service unless it is
absolutely necessary to provide Microsoft Windows file and print
sharing functionality.
|
|
Configure Samba if NecessarygroupAll settings for the Samba daemon can be found in
/etc/samba/smb.conf. Settings are divided between a
[global] configuration section and a series of user
created share definition sections meant to describe file or print
shares on the system. By default, Samba will operate in user mode
and allow client machines to access local home directories and
printers. It is recommended that these settings be changed or that
additional limitations be set in place. |
|
Restrict SMB File Sharing to Configured NetworksgroupOnly users with local user accounts will be able to log in to
Samba shares by default. Shares can be limited to particular users or network
addresses. Use the hosts allow and hosts deny directives
accordingly, and consider setting the valid users directive to a limited subset
of users or to a group of users. Separate each address, user, or user group
with a space as follows for a particular share or global:
[share]
hosts allow = 192.168.1. 127.0.0.1
valid users = userone usertwo @usergroup
It is also possible to limit read and write access to particular users with the
read list and write list options, though the permissions set by the system
itself will override these settings. Set the read only attribute for each share
to ensure that global settings will not accidentally override the individual
share settings. Then, as with the valid users directive, separate each user or
group of users with a space:
[share]
read only = yes
write list = userone usertwo @usergroup
|
|
Restrict Printer SharinggroupBy default, Samba utilizes the CUPS printing service to enable
printer sharing with Microsoft Windows workstations. If there are no printers
on the local machine, or if printer sharing with Microsoft Windows is not
required, disable the printer sharing capability by commenting out the
following lines, found in /etc/samba/smb.conf:
[global]
load printers = yes
cups options = raw
[printers]
comment = All Printers
path = /usr/spool/samba
browseable = no
guest ok = no
writable = no
printable = yes
There may be other options present, but these are the only options enabled and
uncommented by default. Removing the [printers] share should be enough
for most users. If the Samba printer sharing capability is needed, consider
disabling the Samba network browsing capability or restricting access to a
particular set of users or network addresses. Set the valid users
parameter to a small subset of users or restrict it to a particular group of
users with the shorthand @. Separate each user or group of users with
a space. For example, under the [printers] share:
[printers]
valid users = user @printerusers
|
|
Proxy ServergroupA proxy server is a very desirable target for a
potential adversary because much (or all) sensitive data for a
given infrastructure may flow through it. Therefore, if one is
required, the machine acting as a proxy server should be dedicated
to that purpose alone and be stored in a physically secure
location. The system's default proxy server software is Squid, and
provided in an RPM package of the same name. |
|
Disable Squid if PossiblegroupIf 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 ServergroupThe 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 PossiblegroupThe 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 NecessarygroupIf it is necessary to run the snmpd agent on the system, some best
practices should be followed to minimize the security risk from the
installation. The multiple security models implemented by SNMP cannot be fully
covered here so only the following general configuration advice can be offered:
use only SNMP version 3 security models and enable the use of authentication and encryptionwrite access to the MIB (Management Information Base) should be allowed only if necessaryall access to the MIB should be restricted following a principle of least privilegenetwork access should be limited to the maximum extent possible including restricting to expected network
addresses both in the configuration files and in the system firewall rulesensure SNMP agents send traps only to, and accept SNMP queries only from, authorized management
stationsensure that permissions on the snmpd.conf configuration file (by default, in /etc/snmp) are 640 or more restrictiveensure that any MIB files' permissions are also 640 or more restrictive
|
|
Documentation to Support DISA OS SRG MappinggroupThese 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.
|
|