## Guide to the Secure Configuration of Red Hat Virtualization 4

The SCAP Security Guide Project
https://www.open-scap.org/security-policies/scap-security-guide
This guide presents a catalog of security-relevant configuration settings for Red Hat Virtualization 4. It is a rendering of content structured in the eXtensible Configuration Checklist Description Format (XCCDF) in order to support security automation. The SCAP content is is available in the `scap-security-guide` package which is developed at https://www.open-scap.org/security-policies/scap-security-guide.
Providing system administrators with such guidance informs them how to securely configure systems under their control in a variety of network roles. Policy makers and baseline creators can use this catalog of settings, with its associated references to higher-level security control catalogs, in order to assist them in security baseline creation. This guide is a catalog, not a checklist, and satisfaction of every item is not likely to be possible or sensible in many operational scenarios. However, the XCCDF format enables granular selection and adjustment of settings, and their association with OVAL and OCIL content provides an automated checking capability. Transformations of this document, and its associated automated checking content, are capable of providing baselines that meet a diverse set of policy objectives. Some example XCCDF Profiles, which are selections of items that form checklists and can be used as baselines, are available with this guide. They can be processed, in an automated fashion, with tools that support the Security Content Automation Protocol (SCAP). The DISA STIG, which provides required settings for US Department of Defense systems, is one example of a baseline created from this guidance.
Do not attempt to implement any of the settings in this guide without first testing them in a non-operational environment. The creators of this guidance assume no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic.

## Profile Information

Profile ID | (default)

#### CPE Platforms

- cpe:/a:redhat:enterprise_virtualization_manager:4
- cpe:/o:redhat:enterprise_linux:7::hypervisor

## Revision History

Current version: 0.1.44

- draft (as of 2019-06-13)

## Table of Contents

1. Remediation functions used by the SCAP Security Guide Project
2. System Settings

1. Configure Syslog
2. System Accounting with auditd
3. Account and Access Control
4. Installing and Maintaining Software
5. Network Configuration and Firewalls
6. Set Boot Loader Password
7. SELinux
8. File Permissions and Masks
9. Protect Random-Number Entropy Pool
10. Set Boot Loader Password

3. Services

1. Network Routing
2. APT service configuration
3. DNS Server
4. DHCP
5. Base Services
6. Obsolete Services
7. System Security Services Daemon
8. Web Server
9. X Window System
10. Docker Service
11. SSH Server
12. SNMP Server
13. Mail Server Software
14. FTP Server
15. Network Time Protocol
16. Proxy Server
17. Avahi Server
18. LDAP
19. Print Support
20. Samba(SMB) Microsoft Windows File Sharing Server
21. Cron and At Daemons
22. Deprecated services
23. NFS and RPC
24. IMAP and POP3 Server

4. Introduction

1. How to Use This Guide
2. General Principles

## Checklist

Group Guide to the Secure Configuration of Red Hat Virtualization 4
Group Remediation functions used by the SCAP Security Guide Project
[ref] XCCDF form of the various remediation functions as used by remediation scripts from the SCAP Security Guide Project.
Group System Settings
[ref] Contains rules that check correct system settings.
Group Configure Syslog
[ref] The syslog service has been the default Unix logging mechanism for many years. It has a number of downsides, including inconsistent log format, lack of authentication for received messages, and lack of authentication, encryption, or reliable transport for messages sent over a network. However, due to its long history, syslog is a de facto standard which is supported by almost all Unix applications. In Red Hat Virtualization 4, 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.
Group Rsyslog Logs Sent To Remote Host
[ref] 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 system 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.
Group Configure rsyslogd to Accept Remote Messages If Acting as a Log Server
[ref] 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 system is not a log server, then lines concerning these modules should remain commented out.
Group Ensure Proper Configuration of Log Files
[ref] 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 Virtualization 4 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
Group Ensure All Logs are Rotated by logrotate
[ref] Edit the file `/etc/logrotate.d/syslog`. Find the first line, which should look like this (wrapped for clarity):
    /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler \
      /var/log/boot.log /var/log/cron {
Edit this line so that it contains a one-space-separated listing of each log file referenced in `/etc/rsyslog.conf`. All logs in use on a system must be rotated regularly, or the log files will consume disk space over time, eventually interfering with system operation. The file `/etc/logrotate.d/syslog` is the configuration file used by the `logrotate` program to maintain all log files written by `syslog`. By default, it rotates logs weekly and stores four archival copies of each log. These settings can be modified by editing `/etc/logrotate.conf`, but the defaults are sufficient for purposes of this guide. Note that `logrotate` is run nightly by the cron job `/etc/cron.daily/logrotate`. If particularly active logs need to be rotated more often than once a day, some other mechanism must be used.
Group Configure Logwatch on the Central Log Server
[ref] Is this system the central log server? If so, edit the file `/etc/logwatch/conf/logwatch.conf` as shown below.
Group System Accounting with auditd
[ref] The audit service provides substantial capabilities for recording system activities. By default, the service audits about SELinux AVC denials and certain types of security-relevant events such as system logins, account modifications, and authentication events performed by programs such as sudo. Under its default configuration, `auditd` has modest disk space requirements, and should not noticeably impact system performance. 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"`.
Group Configure auditd Rules for Comprehensive Auditing
[ref] The `auditd` program can perform comprehensive monitoring of system activity. This section describes recommended configuration settings for comprehensive auditing, but a full description of the auditing system's capabilities is beyond the scope of this guide. The mailing list linux-audit@redhat.com exists to facilitate community discussion of the auditing system. The audit subsystem supports extensive collection of events, including: Tracing of arbitrary system calls (identified by name or number) on entry or exit. Filtering by PID, UID, call success, system call argument (with some limitations), etc. Monitoring of specific files for modifications to the file's contents or metadata. Auditing rules at startup are controlled by the file `/etc/audit/audit.rules`. Add rules to it to meet the auditing requirements for your organization. Each line in `/etc/audit/audit.rules` represents a series of arguments that can be passed to `auditctl` and can be individually tested during runtime. See documentation in `/usr/share/doc/audit-VERSION` and in the related man pages for more details. If copying any example audit rulesets from `/usr/share/doc/audit-VERSION`, be sure to comment out the lines containing `arch=` which are not appropriate for your system's architecture. Then review and understand the following rules, ensuring rules are activated as needed for the appropriate architecture. After reviewing all the rules, reading the following sections, and editing as needed, the new rules can be activated as follows:
    $ sudo service auditd restart
Group Record Information on Kernel Modules Loading and Unloading
[ref] To capture kernel module loading and unloading events, use following lines, setting ARCH to either b32 for 32-bit system, or having two lines for both b32 and b64 in case your system is 64-bit:
    -w /usr/sbin/insmod -p x -k modules
    -w /usr/sbin/rmmod -p x -k modules
    -w /usr/sbin/modprobe -p x -k modules
    -a always,exit -F arch=ARCH -S init_module,delete_module -F key=modules
Place to add the lines depends on a way `auditd` daemon is configured. If it is configured to use the `augenrules` program (the default), add the lines to a file with suffix `.rules` in the directory `/etc/audit/rules.d`. If the `auditd` daemon is configured to use the `auditctl` utility, add the lines to file `/etc/audit/audit.rules`.
Group Record Unauthorized Access Attempts Events to Files (unsuccessful)
[ref] At a minimum, the audit system should collect unauthorized file accesses for all users and root. Note that the "-F arch=b32" lines should be present even on a 64 bit system. These commands identify system calls for auditing. Even if the system is 64 bit it can still execute 32 bit system calls. Additionally, these rules can be configured in a number of ways while still achieving the desired effect. An example of this is that the "-S" calls could be split up and placed on separate lines, however, this is less efficient. Add the following to `/etc/audit/audit.rules`:
    -a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
        -a always,exit -F arch=b32 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
If your system is 64 bit then these lines should be duplicated and the arch=b32 replaced with arch=b64 as follows:
    -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=access
        -a always,exit -F arch=b64 -S creat,open,openat,open_by_handle_at,truncate,ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=unset -F key=access
Group Record Execution Attempts to Run SELinux Privileged Commands
[ref] At a minimum, the audit system should collect the execution of SELinux privileged commands for all users and root.
Group Record Attempts to Alter Logon and Logout Events
[ref] The audit system already collects login information for all users and root. If the `auditd` daemon is configured to use the `augenrules` program to read audit rules during daemon startup (the default), add the following lines to a file with suffix `.rules` in the directory `/etc/audit/rules.d` in order to watch for attempted manual edits of files involved in storing logon events:
    -w /var/log/tallylog -p wa -k logins
    -w /var/run/faillock/ -p wa -k logins
    -w /var/log/lastlog -p wa -k logins
If the `auditd` daemon is configured to use the `auditctl` utility to read audit rules during daemon startup, add the following lines to `/etc/audit/audit.rules` file in order to watch for unattempted manual edits of files involved in storing logon events:
    -w /var/log/tallylog -p wa -k logins
    -w /var/run/faillock/ -p wa -k logins
    -w /var/log/lastlog -p wa -k logins
Group Records Events that Modify Date and Time Information
[ref] Arbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time. All changes to the system time should be audited.
Group Record Events that Modify the System's Discretionary Access Controls
[ref] At a minimum, the audit system should collect file permission changes for all users and root. Note that the "-F arch=b32" lines should be present even on a 64 bit system. These commands identify system calls for auditing. Even if the system is 64 bit it can still execute 32 bit system calls. Additionally, these rules can be configured in a number of ways while still achieving the desired effect. An example of this is that the "-S" calls could be split up and placed on separate lines, however, this is less efficient. Add the following to `/etc/audit/audit.rules`:
    -a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
        -a always,exit -F arch=b32 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
        -a always,exit -F arch=b32 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
If your system is 64 bit then these lines should be duplicated and the arch=b32 replaced with arch=b64 as follows:
    -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=unset -F key=perm_mod
        -a always,exit -F arch=b64 -S chown,fchown,fchownat,lchown -F auid>=1000 -F auid!=unset -F key=perm_mod
        -a always,exit -F arch=b64 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=unset -F key=perm_mod
Group Record File Deletion Events by User
[ref] At a minimum, the audit system should collect file deletion events for all users and root. If the `auditd` daemon is configured to use the `augenrules` program to read audit rules during daemon startup (the default), add the following line to a file with suffix `.rules` in the directory `/etc/audit/rules.d`, setting ARCH to either b32 or b64 as appropriate for your system:
    -a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=unset -F key=delete
If the `auditd` daemon is configured to use the `auditctl` utility to read audit rules during daemon startup, add the following line to `/etc/audit/audit.rules` file, setting ARCH to either b32 or b64 as appropriate for your system:
    -a always,exit -F arch=ARCH -S rmdir,unlink,unlinkat,rename,renameat -F auid>=1000 -F auid!=unset -F key=delete
Group Record Information on the Use of Privileged Commands
[ref] At a minimum, the audit system should collect the execution of privileged commands for all users and root.
Group Configure auditd Data Retention
[ref] 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.
Group Account and Access Control
[ref] In traditional Unix security, if an attacker gains shell access to a certain login account, they can perform any action or access any file to which that account has access. Therefore, making it more difficult for unauthorized people to gain shell access to accounts, particularly to privileged accounts, is a necessary part of securing a system. This section introduces mechanisms for restricting access to accounts under Red Hat Virtualization 4.
Group Secure Session Configuration Files for Login Accounts
[ref] When a user logs into a Unix account, the system configures the user's session by reading a number of files. Many of these files are located in the user's home directory, and may have weak permissions as a result of user error or misconfiguration. If an attacker can modify or even read certain types of account configuration information, they can often gain full access to the affected user's account. Therefore, it is important to test and correct configuration file permissions for interactive accounts, particularly those of privileged users such as root or system administrators.
Group Ensure that No Dangerous Directories Exist in Root's Path
[ref] The active path of the root account can be obtained by starting a new root shell and running:
    # echo $PATH
This will produce a colon-separated list of directories in the path. Certain path elements could be considered dangerous, as they could lead to root executing unknown or untrusted programs, which could contain malicious code. Since root may sometimes work inside untrusted directories, the `.` character, which represents the current directory, should never be in the root path, nor should any directory which can be written to by an unprivileged or semi-privileged (system) user. It is a good practice for administrators to always execute privileged commands by typing the full path to the command.
Group Ensure that Users Have Sensible Umask Values
[ref] 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.
Group Warning Banners for System Accesses
[ref] Each system should expose as little information about itself as possible. System banners, which are typically displayed just before a login prompt, give out information about the service or the host's operating system. This might include the distribution name and the system kernel version, and the particular version of a network service. This information can assist intruders in gaining access to the system as it can reveal whether the system is running vulnerable software. Most network services can be configured to limit what information is displayed. Many organizations implement security policies that require a system banner provide notice of the system's ownership, provide warning to unauthorized users, and remind authorized users of their consent to monitoring.
Group Implement a GUI Warning Banner
[ref] In the default graphical environment, users logging directly into the system are greeted with a login screen provided by the GNOME Display Manager (GDM). The warning banner should be displayed in this graphical environment for these users. The following sections describe how to configure the GDM login banner.
Group Protect Accounts by Restricting Password-Based Login
[ref] Conventionally, Unix shell accounts are accessed by providing a username and password to a login program, which tests these values for correctness using the `/etc/passwd` and `/etc/shadow` files. Password-based login is vulnerable to guessing of weak passwords, and to sniffing and man-in-the-middle attacks against passwords entered over a network or at an insecure console. Therefore, mechanisms for accessing accounts by entering usernames and passwords should be restricted to those which are operationally necessary.
Group Set Account Expiration Parameters
[ref] Accounts can be configured to be automatically disabled after a certain time period, meaning that they will require administrator interaction to become usable again. Expiration of accounts after inactivity can be set for all accounts by default and also on a per-account basis, such as for accounts that are known to be temporary. To configure automatic expiration of an account following the expiration of its password (that is, after the password has expired and not been changed), run the following command, substituting `NUM_DAYS` and `USER` appropriately:
    $ 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. Warning: This will only apply to newly created accounts
Group Restrict Root Logins
[ref] 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.
Group Verify Proper Storage and Existence of Password Hashes
[ref] 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.
Group Set Password Expiration Parameters
[ref] The file `/etc/login.defs` controls several password-related settings. Programs such as `passwd`, `su`, and `login` consult `/etc/login.defs` to determine behavior with regard to password aging, expiration warnings, and length. See the man page `login.defs(5)` for more information. Users should be forced to change their passwords, in order to decrease the utility of compromised passwords. However, the need to change passwords often should be balanced against the risk that users will reuse or write down passwords if forced to change them too often. Forcing password changes every 90-360 days, depending on the environment, is recommended. Set the appropriate value as `PASS_MAX_DAYS` and apply it to existing accounts with the `-M` flag. The `PASS_MIN_DAYS` (`-m`) setting prevents password changes for 7 days after the first change, to discourage password cycling. If you use this setting, train users to contact an administrator for an emergency password change in case a new password becomes compromised. The `PASS_WARN_AGE` (`-W`) setting gives users 7 days of warnings at login time that their passwords are about to expire. For example, for each existing human user USER, expiration parameters could be adjusted to a 180 day maximum password age, 7 day minimum password age, and 7 day warning period with the following command:
    $ sudo chage -M 180 -m 7 -W 7 USER
Group Protect Physical Console Access
[ref] It is impossible to fully protect a system from an attacker with physical access, so securing the space in which the system is located should be considered a necessary step. However, there are some steps which, if taken, make it more difficult for an attacker to quickly or undetectably modify a system from its console.
Group Configure Screen Locking
[ref] When a user must temporarily leave an account logged-in, screen locking should be employed to prevent passersby from abusing the account. User education and training is particularly important for screen locking to be effective, and policies can be implemented to reinforce this. Automatic screen locking is only meant as a safeguard for those cases where a user forgot to lock the screen.
Group Configure Console Screen Locking
[ref] A console screen locking mechanism is a temporary action taken when a user stops work and moves away from the immediate physical vicinity of the information system but does not logout because of the temporary nature of the absence. Rather than relying on the user to manually lock their operation system session prior to vacating the vicinity, operating systems need to be able to identify when a user's session has idled and take action to initiate the session lock.
Group Hardware Tokens for Authentication
[ref] 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.
Group Protect Accounts by Configuring PAM
[ref] PAM, or Pluggable Authentication Modules, is a system which implements modular authentication for Linux programs. PAM provides a flexible and configurable architecture for authentication, and it should be configured to minimize exposure to unnecessary risk. This section contains guidance on how to accomplish that. PAM is implemented as a set of shared objects which are loaded and invoked whenever an application wishes to authenticate a user. Typically, the application must be running as root in order to take advantage of PAM, because PAM's modules often need to be able to access sensitive stores of account information, such as /etc/shadow. Traditional privileged network listeners (e.g. sshd) or SUID programs (e.g. sudo) already meet this requirement. An SUID root application, userhelper, is provided so that programs which are not SUID or privileged themselves can still take advantage of PAM. PAM looks in the directory `/etc/pam.d` for application-specific configuration information. For instance, if the program login attempts to authenticate a user, then PAM's libraries follow the instructions in the file `/etc/pam.d/login` to determine what actions should be taken. One very important file in `/etc/pam.d` is `/etc/pam.d/system-auth`. This file, which is included by many other PAM configuration files, defines 'default' system authentication measures. Modifying this file is a good way to make far-reaching authentication changes, for instance when implementing a centralized authentication service. Warning: Be careful when making changes to PAM's configuration files. The syntax for these files is complex, and modifications can have unexpected consequences. The default configurations shipped with applications should be sufficient for most users. Warning: Running `authconfig` or `system-config-authentication` will re-write the PAM configuration files, destroying any manually made changes and replacing them with a series of system defaults. One reference to the configuration file syntax can be found at http://www.linux-pam.org/Linux-PAM-html/sag-configuration-file.html.
Group Set Lockouts for Failed Password Attempts
[ref] The `pam_faillock` PAM module provides the capability to lock out user accounts after a number of failed login attempts. Its documentation is available in `/usr/share/doc/pam-VERSION/txts/README.pam_faillock`. Warning: Locking out user accounts presents the risk of a denial-of-service attack. The lockout policy must weigh whether the risk of such a denial-of-service attack outweighs the benefits of thwarting password guessing attacks.
Group Set Password Hashing Algorithm
[ref] The system's default algorithm for storing password hashes in `/etc/shadow` is SHA-512. This can be configured in several locations.
Group Set Password Quality Requirements
[ref] The 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.
Group Set Password Quality Requirements with pam_pwquality
[ref] The `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.
Group Set Password Quality Requirements, if using pam_cracklib
[ref] The `pam_cracklib` PAM module can be configured to meet requirements for a variety of policies. For example, to configure `pam_cracklib` to require at least one uppercase character, lowercase character, digit, and other (special) character, locate the following line in `/etc/pam.d/system-auth`:
    password requisite pam_cracklib.so try_first_pass retry=3
and then alter it to read:
    password required pam_cracklib.so try_first_pass retry=3 maxrepeat=3 minlen=14 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 difok=4
If no such line exists, add one as the first line of the password section in `/etc/pam.d/system-auth`. The arguments can be modified to ensure compliance with your organization's security policy. Discussion of each parameter follows. Warning: Note that the password quality requirements are not enforced for the root account for some reason.
Group Installing and Maintaining Software
[ref] The following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates.
Group Sudo
[ref] `Sudo`, which stands for \"su 'do'\", provides the ability to delegate authority to certain users, groups of users, or system administrators. When configured for system users and/or groups, `Sudo` can allow a user or group to execute privileged commands that normally only `root` is allowed to execute. For more information on `Sudo` and addition `Sudo` configuration options, see https://www.sudo.ws.
Group GNOME Desktop Environment
[ref] GNOME is a graphical desktop environment bundled with many Linux distributions that allow users to easily interact with the operating system graphically rather than textually. The GNOME Graphical Display Manager (GDM) provides login, logout, and user switching contexts as well as display server management. GNOME is developed by the GNOME Project and is considered the default Red Hat Graphical environment. For more information on GNOME and the GNOME Project, see https://www.gnome.org.
Group Configure GNOME Screen Locking
[ref] In 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)`.
Group GNOME Media Settings
[ref] GNOME media settings that apply to the graphical interface.
Group GNOME Remote Access Settings
[ref] GNOME remote access settings that apply to the graphical interface.
Group Configure GNOME Login Screen
[ref] In the default GNOME desktop, the login is displayed after system boot and can display user accounts, allow users to reboot the system, and allow users to login automatically and/or with a guest account. The login screen should be configured to prevent such behavior. For more information about enforcing preferences in the GNOME3 environment using the DConf configuration system, see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Desktop_Migration_and_Administration_Guide/index.html/> and the man page `dconf(1)`.
Group GNOME Network Settings
[ref] GNOME network settings that apply to the graphical interface.
Group GNOME System Settings
[ref] GNOME provides configuration and functionality to a graphical desktop environment that changes grahical configurations or allow a user to perform actions that users normally would not be able to do in non-graphical mode such as remote access configuration, power policies, Geo-location, etc. Configuring such settings in GNOME will prevent accidential graphical configuration changes by users from taking place.
Group Disk Partitioning
[ref] To ensure separation and protection of data, there are top-level system directories which should be placed on their own physical partition or logical volume. The installer's default partitioning scheme creates separate logical volumes for `/`, `/boot`, and `swap`. If starting with any of the default layouts, check the box to \"Review and modify partitioning.\" This allows for the easy creation of additional logical volumes inside the volume group already created, though it may require making `/`'s logical volume smaller to create space. In general, using logical volumes is preferable to using partitions because they can be more easily adjusted later. If creating a custom layout, create the partitions mentioned in the previous paragraph (which the installer will require anyway), as well as separate ones described in the following sections. If a system has already been installed, and the default partitioning scheme was used, it is possible but nontrivial to modify it to create separate logical volumes for the directories listed above. The Logical Volume Manager (LVM) makes this possible. See the LVM HOWTO at http://tldp.org/HOWTO/LVM-HOWTO/ for more detailed information on LVM.
Group System and Software Integrity
[ref] System and software integrity can be gained by installing antivirus, increasing system encryption strength with FIPS, verifying installed software, enabling SELinux, installing an Intrusion Prevention System, etc. However, installing or enabling integrity checking tools cannot prevent intrusions, but they can detect that an intrusion may have occurred. Requirements for integrity checking may be highly dependent on the environment in which the system will be used. Snapshot-based approaches such as AIDE may induce considerable overhead in the presence of frequent software updates.
Group Software Integrity Checking
[ref] 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.
Group Verify Integrity with RPM
[ref] The RPM package management system includes the ability to verify the integrity of installed packages by comparing the installed files with information about the files taken from the package metadata stored in the RPM database. Although an attacker could corrupt the RPM database (analogous to attacking the AIDE database as described above), this check can still reveal modification of important files. To list which files on the system differ from what is expected by the RPM database:
    $ rpm -qVa
See the man page for `rpm` to see a complete explanation of each column.
Group Verify Integrity with AIDE
[ref] AIDE conducts integrity checks by comparing information about files with previously-gathered information. Ideally, the AIDE database is created immediately after initial system configuration, and then again after any software update. AIDE is highly configurable, with further configuration information located in `/usr/share/doc/aide-VERSION`.
Group Federal Information Processing Standard (FIPS)
[ref] The Federal Information Processing Standard (FIPS) is a computer security standard which is developed by the U.S. Government and industry working groups to validate the quality of cryptographic modules. The FIPS standard provides four security levels to ensure adequate coverage of different industries, implementation of cryptographic modules, and organizational sizes and requirements. FIPS 140-2 is the current standard for validating that mechanisms used to access cryptographic modules utilize authentication that meets industry and government requirements. For government systems, this allows Security Levels 1, 2, 3, or 4 for use on Red Hat Virtualization 4. See http://csrc.nist.gov/publications/PubsFIPS.html for more information.
Group Endpoint Protection Software
[ref] Endpoint protection security software that is not provided or supported by Red Hat can be installed to provide complementary or duplicative security capabilities to those provided by the base platform. Add-on software may not be appropriate for some specialized systems.
Group McAfee Endpoint Security Software
[ref] In DoD environments, McAfee Host-based Security System (HBSS) and VirusScan Enterprise for Linux (VSEL) is required to be installed on all systems.
Group McAfee Host-Based Intrusion Detection Software (HBSS)
[ref] McAfee Host-based Security System (HBSS) is a suite of software applications used to monitor, detect, and defend computer networks and systems.
Group Operating System Vendor Support and Certification
[ref] The assurance of a vendor to provide operating system support and maintenance for their product is an important criterion to ensure product stability and security over the life of the product. A certified product that follows the necessary standards and government certification requirements guarantees that known software vulnerabilities will be remediated, and proper guidance for protecting and securing the operating system will be given.
Group System Cryptographic Policies
[ref] Linux has the capability to centrally configure cryptographic polices. The command `update-crypto-policies` is used to set the policy applicable for the various cryptographic back-ends, such as SSL/TLS libraries. The configured cryptographic policies will be the default policy used by these backends unless the application user configures them otherwise. When the system has been configured to use the centralized cryptographic policies, the administrator is assured that any application that utilizes the supported backends will follow a policy that adheres to the configured profile. Currently the supported backends are: GnuTLS library OpenSSL library NSS library OpenJDK Libkrb5 BIND OpenSSH Applications and languages which rely on any of these backends will follow the system policies as well. Examples are apache httpd, nginx, php, and others.
Group Updating Software
[ref] The `yum` command line tool is used to install and update software packages. The system also provides a graphical software update tool in the System menu, in the Administration submenu, called Software Update. Red Hat Virtualization 4 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.
Group SAP Specific Requirement
[ref] SAP (Systems, Applications and Products in Data Processing) is enterprise software to manage business operations and customer relations. The following section contains SAP specific requirement that is not part of standard or common OS setting.
Group Network Configuration and Firewalls
[ref] Most systems must be connected to a network of some sort, and this brings with it the substantial risk of network attack. This section discusses the security impact of decisions about networking which must be made when configuring a system. 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.
Group Disable Unused Interfaces
[ref] Network interfaces expand the attack surface of the system. Unused interfaces are not monitored or controlled, and should be disabled. If the system does not require network communications but still needs to use the loopback interface, remove all files of the form `ifcfg-interface` except for `ifcfg-lo` from `/etc/sysconfig/network-scripts`:
    $ 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.service
Group IPSec Support
[ref] Support for Internet Protocol Security (IPsec)
Group Uncommon Network Protocols
[ref] The system includes support for several network protocols which are not commonly used. Although security vulnerabilities in kernel networking code are not frequently discovered, the consequences can be dramatic. Ensuring uncommon network protocols are disabled reduces the system's risk to attacks targeted at its implementation of those protocols. Warning: Although these protocols are not commonly used, avoid disruption in your network environment by ensuring they are not needed prior to disabling them.
Group iptables and ip6tables
[ref] A host-based firewall called `netfilter` is included as part of the Linux kernel distributed with the system. It is activated by default. This firewall is controlled by the program `iptables`, and the entire capability is frequently referred to by this name. An analogous program called `ip6tables` handles filtering for IPv6. Unlike TCP Wrappers, which depends on the network server program to support and respect the rules written, `netfilter` filtering occurs at the kernel level, before a program can even process the data from the network packet. As such, any program on the system is affected by the rules written. This section provides basic information about strengthening the `iptables` and `ip6tables` configurations included with the system. For more complete information that may allow the construction of a sophisticated ruleset tailored to your environment, please consult the references at the end of this section.
Group Strengthen the Default Ruleset
[ref] The default rules can be strengthened. The system scripts that activate the firewall rules expect them to be defined in the configuration files `iptables` and `ip6tables` in the directory `/etc/sysconfig`. Many of the lines in these files are similar to the command line arguments that would be provided to the programs `/sbin/iptables` or `/sbin/ip6tables` - but some are quite different. The following recommendations describe how to strengthen the default ruleset configuration file. An alternative to editing this configuration file is to create a shell script that makes calls to the iptables program to load in rules, and then invokes service iptables save to write those loaded rules to `/etc/sysconfig/iptables.` The following alterations can be made directly to `/etc/sysconfig/iptables` and `/etc/sysconfig/ip6tables`. Instructions apply to both unless otherwise noted. Language and address conventions for regular iptables are used throughout this section; configuration for ip6tables will be either analogous or explicitly covered. Warning: The program `system-config-securitylevel` allows additional services to penetrate the default firewall rules and automatically adjusts `/etc/sysconfig/iptables`. This program is only useful if the default ruleset meets your security requirements. Otherwise, this program should not be used to make changes to the firewall configuration because it re-writes the saved configuration file.
Group Restrict ICMP Message Types
[ref] In `/etc/sysconfig/iptables`, the accepted ICMP messages types can be restricted. To accept only ICMP echo reply, destination unreachable, and time exceeded messages, remove the line:
    -A INPUT -p icmp --icmp-type any -j ACCEPT
and insert the lines:
    -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
    -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
    -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
To allow the system to respond to pings, also insert the following line:
    -A INPUT -p icmp --icmp-type echo-request -j ACCEPT
Ping responses can also be limited to certain networks or hosts by using the -s option in the previous rule. Because IPv6 depends so heavily on ICMPv6, it is preferable to deny the ICMPv6 packets you know you don't need (e.g. ping requests) in `/etc/sysconfig/ip6tables`, while letting everything else through:
    -A INPUT -p icmpv6 --icmpv6-type echo-request -j DROP
If you are going to statically configure the system's address, it should ignore Router Advertisements which could add another IPv6 address to the interface or alter important network settings:
    -A INPUT -p icmpv6 --icmpv6-type router-advertisement -j DROP
Restricting ICMPv6 message types in `/etc/sysconfig/ip6tables` is not recommended because the operation of IPv6 depends heavily on ICMPv6. Thus, great care must be taken if any other ICMPv6 types are blocked.
Group Log and Drop Packets with Suspicious Source Addresses
[ref] Packets with non-routable source addresses should be rejected, as they may indicate spoofing. Because the modified policy will reject non-matching packets, you only need to add these rules if you are interested in also logging these spoofing or suspicious attempts before they are dropped. If you do choose to log various suspicious traffic, add identical rules with a target of `DROP` after each LOG. To log and then drop these IPv4 packets, insert the following rules in `/etc/sysconfig/iptables` (excepting any that are intentionally used):
    -A INPUT -s 10.0.0.0/8 -j LOG --log-prefix "IP DROP SPOOF A: "
    -A INPUT -s 172.16.0.0/12 -j LOG --log-prefix "IP DROP SPOOF B: "
    -A INPUT -s 192.168.0.0/16 -j LOG --log-prefix "IP DROP SPOOF C: "
    -A INPUT -s 224.0.0.0/4 -j LOG --log-prefix "IP DROP MULTICAST D: "
    -A INPUT -s 240.0.0.0/5 -j LOG --log-prefix "IP DROP SPOOF E: "
    -A INPUT -d 127.0.0.0/8 -j LOG --log-prefix "IP DROP LOOPBACK: "
Similarly, you might wish to log packets containing some IPv6 reserved addresses if they are not expected on your network:
    -A INPUT -i eth0 -s ::1 -j LOG --log-prefix "IPv6 DROP LOOPBACK: "
    -A INPUT -s 2002:E000::/20 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
    -A INPUT -s 2002:7F00::/24 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
    -A INPUT -s 2002:0000::/24 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
    -A INPUT -s 2002:FF00::/24 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
    -A INPUT -s 2002:0A00::/24 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
    -A INPUT -s 2002:AC10::/28 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
    -A INPUT -s 2002:C0A8::/32 -j LOG --log-prefix "IPv6 6to4 TRAFFIC: "
If you are not expecting to see site-local multicast or auto-tunneled traffic, you can log those:
    -A INPUT -s FF05::/16 -j LOG --log-prefix "IPv6 SITE-LOCAL MULTICAST: "
    -A INPUT -s ::0.0.0.0/96 -j LOG --log-prefix "IPv4 COMPATIBLE IPv6 ADDR: "
If you wish to block multicasts to all link-local nodes (e.g. if you are not using router auto-configuration and do not plan to have any services that multicast to the entire local network), you can block the link-local all-nodes multicast address (before accepting incoming ICMPv6):
    -A INPUT -d FF02::1 -j LOG --log-prefix "Link-local All-Nodes Multicast: "
However, if you're going to allow IPv4 compatible IPv6 addresses (of the form ::0.0.0.0/96), you should then consider logging the non-routable IPv4-compatible addresses:
    -A INPUT -s ::0.0.0.0/104 -j LOG --log-prefix "IP NON-ROUTABLE ADDR: "
    -A INPUT -s ::127.0.0.0/104 -j LOG --log-prefix "IP DROP LOOPBACK: "
    -A INPUT -s ::224.0.0.0.0/100 -j LOG --log-prefix "IP DROP MULTICAST D: "
    -A INPUT -s ::255.0.0.0/104 -j LOG --log-prefix "IP BROADCAST: "
If you are not expecting to see any IPv4 (or IPv4-compatible) traffic on your network, consider logging it before it gets dropped:
    -A INPUT -s ::FFFF:0.0.0.0/96 -j LOG --log-prefix "IPv4 MAPPED IPv6 ADDR: "
    -A INPUT -s 2002::/16 -j LOG --log-prefix "IPv6 6to4 ADDR: "
The following rule will log all traffic originating from a site-local address, which is deprecated address space:
    -A INPUT -s FEC0::/10 -j LOG --log-prefix "SITE-LOCAL ADDRESS TRAFFIC: "
Group Inspect and Activate Default Rules
[ref] View the currently-enforced `iptables` rules by running the command:
    $ sudo iptables -nL --line-numbers
The command is analogous for `ip6tables`. If the firewall does not appear to be active (i.e., no rules appear), activate it and ensure that it starts at boot by issuing the following commands (and analogously for `ip6tables`):
    $ sudo service iptables restart
The default iptables rules are:
    Chain INPUT (policy ACCEPT)
    num  target     prot opt source       destination
    1    ACCEPT     all  --  0.0.0.0/0    0.0.0.0/0    state RELATED,ESTABLISHED
    2    ACCEPT     icmp --  0.0.0.0/0    0.0.0.0/0
    3    ACCEPT     all  --  0.0.0.0/0    0.0.0.0/0
    4    ACCEPT     tcp  --  0.0.0.0/0    0.0.0.0/0    state NEW tcp dpt:22
    5    REJECT     all  --  0.0.0.0/0    0.0.0.0/0    reject-with icmp-host-prohibited

    Chain FORWARD (policy ACCEPT)
    num  target     prot opt source       destination
    1    REJECT     all  --  0.0.0.0/0    0.0.0.0/0    reject-with icmp-host-prohibited

    Chain OUTPUT (policy ACCEPT)
    num  target     prot opt source       destination
The `ip6tables` default rules are essentially the same.
Group firewalld
[ref] The 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.
Group Inspect and Activate Default firewalld Rules
[ref] Firewalls 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: `drop` Any incoming network packets are dropped, there is no reply. Only outgoing network connections are possible. `block` Any 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. `public` For 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. `external` For 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. `dmz` For computers in your demilitarized zone that are publicly-accessible with limited access to your internal network. Only selected incoming connections are accepted. `work` For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted. `home` For use in home areas. You mostly trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted. `internal` For use on internal networks. You mostly trust the other computers on the networks to not harm your computer. Only selected incoming connections are accepted. `trusted` All 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 Virtualization 4 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
Group Strengthen the Default Ruleset
[ref] The 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. Warning: The program `firewall-config` allows additional services to penetrate the default firewall rules and automatically adjusts the `firewalld` ruleset(s).
Group IPv6
[ref] The system includes support for Internet Protocol version 6. A major and often-mentioned improvement over IPv4 is its enormous increase in the number of available addresses. Another important feature is its support for automatic configuration of many network settings.
Group Disable Support for IPv6 Unless Needed
[ref] 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.
Group Configure IPv6 Settings if Necessary
[ref] A major feature of IPv6 is the extent to which systems implementing it can automatically configure their networking devices using information from the network. From a security perspective, manually configuring important configuration information is preferable to accepting it from the network in an unauthenticated fashion.
Group Disable Automatic Configuration
[ref] Disable the system's acceptance of router advertisements and redirects by adding or correcting the following line in `/etc/sysconfig/network` (note that this does not disable sending router solicitations):
    IPV6_AUTOCONF=no
Group Limit Network-Transmitted Configuration if Using Static IPv6 Addresses
[ref] To limit the configuration information requested from other systems and accepted from the network on a system that uses statically-configured IPv6 addresses, add the following lines to `/etc/sysctl.conf`:
    net.ipv6.conf.default.router_solicitations = 0
    net.ipv6.conf.default.accept_ra_rtr_pref = 0
    net.ipv6.conf.default.accept_ra_pinfo = 0
    net.ipv6.conf.default.accept_ra_defrtr = 0
    net.ipv6.conf.default.autoconf = 0
    net.ipv6.conf.default.dad_transmits = 0
    net.ipv6.conf.default.max_addresses = 1
The `router_solicitations` setting determines how many router solicitations are sent when bringing up the interface. If addresses are statically assigned, there is no need to send any solicitations. The `accept_ra_pinfo` setting controls whether the system will accept prefix info from the router. The `accept_ra_defrtr` setting controls whether the system will accept Hop Limit settings from a router advertisement. Setting it to 0 prevents a router from changing your default IPv6 Hop Limit for outgoing packets. The `autoconf` setting controls whether router advertisements can cause the system to assign a global unicast address to an interface. The `dad_transmits` setting determines how many neighbor solicitations to send out per address (global and link-local) when bringing up an interface to ensure the desired address is unique on the network. The `max_addresses` setting determines how many global unicast IPv6 addresses can be assigned to each interface. The default is 16, but it should be set to exactly the number of statically configured global addresses required.
Group Wireless Networking
[ref] Wireless networking, such as 802.11 (WiFi) and Bluetooth, can present a security risk to sensitive or classified systems and networks. Wireless networking hardware is much more likely to be included in laptop or portable systems than 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.
Group Disable Wireless Through Software Configuration
[ref] If it is impossible to remove the wireless hardware from the device in question, disable as much of it as possible through software. The following methods can disable software support for wireless networking, but note that these methods do not prevent malicious software or careless users from re-activating the devices.
Group Kernel Parameters Which Affect Networking
[ref] The `sysctl` utility is used to set parameters which affect the operation of the Linux kernel. Kernel parameters which affect networking and have security implications are described here.
Group Network Related Kernel Runtime Parameters for Hosts and Routers
[ref] Certain kernel parameters should be set for systems which are acting as either hosts or routers to improve the system's ability defend against certain types of IPv4 protocol attacks.
Group Network Parameters for Hosts Only
[ref] If the system is not going to be used as a router, then setting certain kernel parameters ensure that the host will not perform routing of network traffic.
Group Transport Layer Security Support
[ref] 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/. Information on FIPS validation of OpenSSL is available at http://www.openssl.org/docs/fips.html and http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm.
Group Set Boot Loader Password
[ref] During the boot process, the boot loader is responsible for starting the execution of the kernel and passing options to it. The boot loader allows for the selection of different kernels - possibly on different partitions or media. The default Red Hat Enterprise Linux boot loader for x86 systems is called GRUB. Options it can pass to the kernel include single-user mode, which provides root access without any authentication, and the ability to disable SELinux. To prevent local users from modifying the boot parameters and endangering security, protect the boot loader configuration with a password and ensure its configuration file's permissions are set properly.
Group SELinux
[ref] SELinux is a feature of the Linux kernel which can be used to guard against misconfigured or compromised programs. SELinux enforces the idea that programs should be limited in what files they can access and what actions they can take. The default SELinux policy, as configured on Red Hat Virtualization 4, has been sufficiently developed and debugged that it should be usable on almost any system 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 Virtualization 4 system, unless that system has unusual requirements which make a stronger policy appropriate.
Group SELinux - Booleans
[ref] Enable or Disable runtime customization of SELinux system policies without having to reload or recompile the SELinux policy.
Group File Permissions and Masks
[ref] Traditional Unix security relies heavily on file and directory permissions to prevent unauthorized users from reading or modifying files to which they should not have access. Several of the commands in this section search filesystems for files or directories with certain characteristics, and are intended to be run on every local partition on a given system. When the variable PART appears in one of the commands below, it means that the command is intended to be run repeatedly, with the name of each local partition substituted for PART in turn. The following command prints a list of all xfs partitions on the local system, which is the default filesystem for Red Hat Virtualization 4 installations:
    $ mount -t xfs | awk '{print $3}'
For any systems that use a different local filesystem type, modify this command as appropriate.
Group Verify Permissions on Important Files and Directories
[ref] Permissions for many files on a system must be set restrictively to ensure sensitive information is properly protected. This section discusses important permission restrictions which can be verified to ensure that no harmful discrepancies have arisen.
Group Verify File Permissions Within Some Important Directories
[ref] Some directories contain files whose confidentiality or integrity is notably important and may also be susceptible to misconfiguration over time, particularly if unpackaged software is installed. As such, an argument exists to verify that files' permissions within these directories remain configured correctly and restrictively.
Group Verify Permissions on Files with Local Account Information and Credentials
[ref] The default restrictive permissions for files which act as important security databases such as `passwd`, `shadow`, `group`, and `gshadow` files must be maintained. Many utilities need read access to the `passwd` file in order to function properly, but read access to the `shadow` file allows malicious attacks against system passwords, and should never be enabled.
Group Restrict Dynamic Mounting and Unmounting of Filesystems
[ref] Linux includes a number of facilities for the automated addition and removal of filesystems on a running system. These facilities may be necessary in many environments, but this capability also carries some risk -- whether direct risk from allowing users to introduce arbitrary filesystems, or risk that software flaws in the automated mount facility itself could allow an attacker to compromise the system. This command can be used to list the types of filesystems that are available to the currently executing kernel:
    $ find /lib/modules/`uname -r`/kernel/fs -type f -name '*.ko'
If these filesystems are not required then they can be explicitly disabled in a configuratio file in `/etc/modprobe.d`.
Group Restrict Programs from Dangerous Execution Patterns
[ref] The recommendations in this section are designed to ensure that the system's features to protect against potentially dangerous program execution are activated. These protections are applied at the system initialization or kernel level, and defend against certain types of badly-configured or compromised programs.
Group Disable Core Dumps
[ref] A core dump file is the memory image of an executable program when it was terminated by the operating system due to errant behavior. In most cases, only software developers legitimately need to access these files. The core dump files may also contain sensitive information, or unnecessarily occupy large amounts of disk space. Once a hard limit is set in `/etc/security/limits.conf`, a user cannot increase that limit within his or her own session. If access to core dumps is required, consider restricting them to only certain users or groups. See the `limits.conf` man page for more information. The core dumps of setuid programs are further protected. The `sysctl` variable `fs.suid_dumpable` controls whether the kernel allows core dumps from these programs at all. The default value of 0 is recommended.
Group Daemon Umask
[ref] The umask is a per-process setting which limits the default permissions for creation of new files and directories. The system includes initialization scripts which set the default umask for system daemons.
Group Enable ExecShield
[ref] ExecShield describes kernel features that provide protection against exploitation of memory corruption errors such as buffer overflows. These features include random placement of the stack and other memory regions, prevention of execution in memory that should only hold data, and special handling of text buffers. These protections are enabled by default 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`.
Group Enable Execute Disable (XD) or No Execute (NX) Support on x86 Systems
[ref] Recent processors in the x86 family support the ability to prevent code execution on a per memory page basis. Generically and on AMD processors, this ability is called No Execute (NX), while on Intel processors it is called Execute Disable (XD). This ability can help prevent exploitation of buffer overflow vulnerabilities and should be activated whenever possible. Extra steps must be taken to ensure that this protection is enabled, particularly on 32-bit x86 systems. Other processors, such as Itanium and POWER, have included such support since inception and the standard kernel for those platforms supports the feature. This is enabled by default on the latest Red Hat and Fedora systems if supported by the hardware.
Group Memory Poisoning
[ref] Memory Poisoning consists of writing a special value to uninitialized or freed memory. Poisoning can be used as a mechanism to prevent leak of information and detection of corrupted memory.
Group Restrict Partition Mount Options
[ref] System partitions can be mounted with certain options that limit what files on those partitions can do. These options are set in the `/etc/fstab` configuration file, and can be used to make certain types of malicious behavior more difficult.
Group Protect Random-Number Entropy Pool
[ref] The I/O operations of the Linux kernel block layer due to their inherently unpredictable execution times have been traditionally considered as a reliable source to contribute to random-number entropy pool of the Linux kernel. This has changed with introduction of solid-state storage devices (SSDs) though.
Group Set Boot Loader Password
[ref] During the boot process, the boot loader is responsible for starting the execution of the kernel and passing options to it. The boot loader allows for the selection of different kernels - possibly on different partitions or media. The default Red Hat Virtualization 4 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.
Group Services
[ref] The best protection against vulnerable software is running less software. This section describes how to review the software which Red Hat Virtualization 4 installs on a system and disable software which is not needed. It then enumerates the software packages installed on a default Red Hat Virtualization 4 system and provides guidance about which ones can be safely disabled. Red Hat Virtualization 4 provides a convenient minimal install option that essentially installs the bare necessities for a functional system. When building Red Hat Virtualization 4 systems, it is highly recommended to select the minimal packages and then build up the system from there.
Group Network Routing
[ref] A router is a very desirable target for a potential adversary because they fulfill a variety of infrastructure networking roles such as access to network segments, gateways to other networks, filtering, etc. Therefore, if one is required, the system acting as a router should be dedicated to that purpose alone and be stored in a physically secure location. The system's default routing software is Quagga, and provided in an RPM package of the same name.
Group Disable Quagga if Possible
[ref] If Quagga was installed and activated, but the system does not need to act as a router, then it should be disabled and removed.
Group APT service configuration
[ref] The apt service manage the package management and update of the whole system. Its configuration need to be properly defined to ensure efficient security updates, packages and repository authentication and proper lifecycle management.
Group DNS Server
[ref] Most organizations have an operational need to run at least one nameserver. However, there are many common attacks involving DNS server software, and this server software should be disabled on any system on which it is not needed.
Group Isolate DNS from Other Services
[ref] This section discusses mechanisms for preventing the DNS server from interfering with other services. This is done both to protect the remainder of the network should a nameserver be compromised, and to make direct attacks on nameservers more difficult.
Group Run DNS Software in a chroot Jail
[ref] Install 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
Warning: If you are running BIND in a chroot jail, then you should use the jailed `named.conf` as the primary nameserver configuration file. That is, when this guide recommends editing `/etc/named.conf`, you should instead edit `/var/named/chroot/etc/named.conf`.
Group Run DNS Software on Dedicated Servers
[ref] Since DNS is a high-risk service which must frequently be made available to the entire Internet, it is strongly recommended that no other services be offered by systems which act as organizational DNS servers.
Group Protect DNS Data from Tampering or Attack
[ref] This section discusses DNS configuration options which make it more difficult for attackers to gain access to private DNS data or to modify DNS data.
Group Use Views to Partition External and Internal Information
[ref] If it is not possible to run external and internal nameservers on separate physical systems, 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 {
        ...
      };
    };
Warning: As shown in the example, database files which are required for recursion, such as the root hints file, must be available to any clients which are allowed to make recursive queries. Under typical circumstances, this includes only the internal clients which are allowed to use this server as a general-purpose nameserver.
Group Run Separate DNS Servers for External and Internal Queries
[ref] Is it possible to run external and internal nameservers on separate systems? If so, follow the configuration guidance in this section. On the external nameserver, edit `/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 {
      ...
    };
Group Disable DNS Server
[ref] DNS software should be disabled on any systems which does not need to be a nameserver. Note that the BIND DNS server software is not installed on Red Hat Virtualization 4 by default. The remainder of this section discusses secure configuration of systems which must be nameservers.
Group DHCP
[ref] The 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.
Group Disable DHCP Client
[ref] 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.
Group Disable DHCP Server
[ref] 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.
Group Configure DHCP Client if Necessary
[ref] If DHCP must be used, then certain configuration changes can minimize the amount of information it receives and applies from the network, and thus the amount of incorrect information a rogue DHCP server could successfully distribute. For more information on configuring dhclient, see the `dhclient(8)` and `dhclient.conf(5)` man pages.
Group Configure DHCP Server
[ref] If the system must act as a DHCP server, the configuration information it serves should be minimized. Also, support for other protocols and DNS-updating schemes should be explicitly disabled unless needed. The configuration file for dhcpd is called `/etc/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.
Group Base Services
[ref] This section addresses the base services that are installed on a Red Hat Virtualization 4 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.
Group Obsolete Services
[ref] This section discusses a number of network-visible services which have historically caused problems for system security, and for which disabling or severely limiting the service has been the best available guidance for some time. As a result of this, many of these services are not installed as part of Red Hat Virtualization 4 by default. Organizations which are running these services should switch to more secure equivalents as soon as possible. If it remains absolutely necessary to run one of these services for legacy reasons, care should be taken to restrict the service as much as possible, for instance by configuring host firewall software such as `iptables` to restrict access to the vulnerable service to only those remote hosts which have a known need to use it.
Group Chat/Messaging Services
[ref] The talk software makes it possible for users to send and receive messages across systems through a terminal session.
Group Rlogin, Rsh, and Rexec
[ref] The Berkeley r-commands are legacy services which allow cleartext remote access and have an insecure trust model.
Group Telnet
[ref] The telnet protocol does not provide confidentiality or integrity for information transmitted on the network. This includes authentication information such as passwords. Organizations which use telnet should be actively working to migrate to a more secure protocol.
Group NIS
[ref] The Network Information Service (NIS), also known as 'Yellow Pages' (YP), and its successor NIS+ have been made obsolete by Kerberos, LDAP, and other modern centralized authentication services. NIS should not be used because it suffers from security problems inherent in its design, such as inadequate protection of important authentication information.
Group Xinetd
[ref] The `xinetd` service acts as a dedicated listener for some network services (mostly, obsolete ones) and can be used to provide access controls and perform some logging. It has been largely obsoleted by other features, and it is not installed by default. The older Inetd service is not even available as part of Red Hat Virtualization 4.
Group TFTP Server
[ref] 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.
Group System Security Services Daemon
[ref] The System Security Services Daemon (SSSD) is a system daemon that provides access to different identity and authentication providers such as Red Hat's IdM, Microsoft's AD, openLDAP, MIT Kerberos, etc. It uses a common framework that can provide caching and offline support to systems utilizing SSSD. SSSD using caching to reduce load on authentication servers permit offline authentication as well as store extended user data. For more information, see
Group System Security Services Daemon (SSSD) - LDAP
[ref] The System Security Services Daemon (SSSD) is a system daemon that provides access to different identity and authentication providers such as Red Hat's IdM, Microsoft's AD, openLDAP, MIT Kerberos, etc. It uses a common framework that can provide caching and offline support to systems utilizing SSSD. SSSD using caching to reduce load on authentication servers permit offline authentication as well as store extended user data. SSSD can support many backends including LDAP. The `sssd-ldap` backend allows SSSD to fetch identity information from an LDAP server.
Group Web Server
[ref] The web server is responsible for providing access to content via the HTTP protocol. Web servers represent a significant security risk because: The HTTP port is commonly probed by malicious sources Web server software is very complex, and includes a long history of vulnerabilities The HTTP protocol is unencrypted and vulnerable to passive monitoring The system's default web server software is Apache 2 and is provided in the RPM package `httpd`.
Group Disable Apache if Possible
[ref] If Apache was installed and activated, but the system does not need to act as a web server, then it should be disabled and removed from the system.
Group Secure Apache Configuration
[ref] The `httpd` configuration file is `/etc/httpd/conf/httpd.conf`. Apply the recommendations in the remainder of this section to this file.
Group Configure HTTPD-Served Web Content Securely
[ref] 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.
Group Minimize Web Server Loadable Modules
[ref] 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.
Group httpd Core Modules
[ref] 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.
Group Minimize Modules for HTTP Basic Authentication
[ref] 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
Group Minimize Various Optional Components
- [ref] The following modules perform very specific tasks, sometimes providing access to just a few additional directives. If such functionality is not required (or if you are not using these directives), comment out the associated module: External filtering (response passed through external program prior to client delivery)
      #LoadModule ext_filter_module modules/mod_ext_filter.so
- User-specified Cache Control and Expiration
      #LoadModule expires_module modules/mod_expires.so
- Compression Output Filter (provides content compression prior to client delivery)
      #LoadModule deflate_module modules/mod_deflate.so
- HTTP Response/Request Header Customization
      #LoadModule headers_module modules/mod_headers.so
- User activity monitoring via cookies
      #LoadModule usertrack_module modules/mod_usertrack.so
- Dynamically configured mass virtual hosting
      #LoadModule vhost_alias_module modules/mod_vhost_alias.so
Minimizing the number of loadable modules available to the web server reduces risk by limiting the capabilities allowed by the web server.
Group Minimize Configuration Files Included
[ref] 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.
Group Restrict Web Server Information Leakage
[ref] The `ServerTokens` and `ServerSignature` directives determine how much information the web server discloses about the configuration of the system.
Group Configure Operating System to Protect Web Server
[ref] The following configuration steps should be taken on the system which hosts the web server, in order to provide as safe an environment as possible for the web server.
Group Run httpd in a chroot Jail if Practical
[ref] 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 Virtualization 4) 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.
Group Restrict File and Directory Access
[ref] Minimize access to critical `httpd` files and directories.
Group Configure PHP Securely
[ref] 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
Group Use Denial-of-Service Protection Modules
[ref] 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.
Group Configure PERL Securely
[ref] PERL (Practical Extraction and Report Language) is an interpreted language optimized for scanning arbitrary text files, extracting information from those text files, and printing reports based on that information. The language is often used in shell scripting and is intended to be practical, easy to use, and efficient means of generating interactive web pages for the user.
Group Directory Restrictions
[ref] 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.
Group Use Appropriate Modules to Improve httpd's Security
[ref] 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.
Group Deploy mod_security
[ref] 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.
Group Deploy mod_ssl
[ref] 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.
Group Install Apache if Necessary
[ref] If `httpd` was not installed and activated, but the system needs to act as a web server, then it should be installed on the system. Follow these guidelines to install it defensively. The `httpd` package can be installed with the following command:
    $ 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.
Group Confirm Minimal Built-in Modules Installed
[ref] The default `httpd` installation minimizes the number of modules that are compiled directly into the binary (`core prefork http_core mod_so`). This minimizes risk by limiting the capabilities allowed by the 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.
Group X Window System
[ref] The X Window System implementation included with the system is called X.org.
Group Disable X Windows
[ref] Unless there is a mission-critical reason for the system to run a graphical user interface, ensure X is not set to start automatically at boot and remove the X Windows software packages. There is usually no reason to run X Windows on a dedicated server system, as it increases the system's attack surface and consumes system resources. Administrators of server systems should instead login via SSH or on the text console.
Group Docker Service
[ref] The docker service is necessary to create containers, which are self-sufficient and self-contained applications using the resource isolation features of the kernel.
Group SSH Server
[ref] The SSH protocol is recommended for remote login and remote file transfer. SSH provides confidentiality and integrity for data exchanged between two systems, as well as server authentication, through the use of public key cryptography. The implementation included with the system is called OpenSSH, and more detailed documentation is available from its website, http://www.openssh.org. Its server program is called `sshd` and provided by the RPM package `openssh-server`.
Group Configure OpenSSH Server if Necessary
[ref] If the system needs to act as an SSH server, then certain changes should be made to the OpenSSH daemon configuration file `/etc/ssh/sshd_config`. The following recommendations can be applied to this file. See the `sshd_config(5)` man page for more detailed information.
Group Strengthen Firewall Configuration if Possible
[ref] If the SSH server is expected to only receive connections from the local network, then strengthen the default firewall rule for the SSH service to only accept connections from the appropriate network segment(s). Determine an appropriate network block, `netwk`, network mask, `mask`, and network protocol, `ip_protocol`, representing the systems 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'
Group SNMP Server
[ref] The Simple Network Management Protocol allows administrators to monitor the state of network devices, including computers. Older versions of SNMP were well-known for weak security, such as plaintext transmission of the community string (used for authentication) and usage of easily-guessable choices for the community string.
Group Configure SNMP Server if Necessary
[ref] If it is necessary to run the snmpd agent on the system, some best practices should be followed to minimize the security risk from the installation. The multiple security models implemented by SNMP cannot be fully covered here so only the following general configuration advice can be offered: use only SNMP version 3 security models and enable the use of authentication and encryption write access to the MIB (Management Information Base) should be allowed only if necessary all access to the MIB should be restricted following a principle of least privilege network access should be limited to the maximum extent possible including restricting to expected network addresses both in the configuration files and in the system firewall rules ensure SNMP agents send traps only to, and accept SNMP queries only from, authorized management stations ensure that permissions on the `snmpd.conf` configuration file (by default, in `/etc/snmp`) are 640 or more restrictive ensure that any MIB files' permissions are also 640 or more restrictive
Group Disable SNMP Server if Possible
[ref] The 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.
Group Mail Server Software
[ref] Mail servers are used to send and receive email over the network. Mail is a very common service, and Mail Transfer Agents (MTAs) are obvious targets of network attack. Ensure that systems are not running MTAs unnecessarily, and configure needed MTAs as defensively as possible. 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 Virtualization 4 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.
Group Configure SMTP For Mail Clients
[ref] This section discusses settings for Postfix in a submission-only e-mail configuration.
Group Configure Operating System to Protect Mail Server
[ref] The guidance in this section is appropriate for any host which is operating as a site MTA, whether the mail server runs using Sendmail, Postfix, or some other software.
Group Configure SSL Certificates for Use with SMTP AUTH
[ref] 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.
Group Ensure Security of Postfix SSL Certificate
[ref] Create 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
Group Configure Postfix if Necessary
[ref] Postfix stores its configuration files in the directory /etc/postfix by default. The primary configuration file is `/etc/postfix/main.cf`.
Group Control Mail Relaying
[ref] Postfix's mail relay controls are implemented with the help of the smtpd recipient restrictions option, which controls the restrictions placed on the SMTP dialogue once the sender and recipient envelope addresses are known. The guidance in the following sections should be applied to all systems. If there are systems which must be allowed to relay mail, but which cannot be trusted to relay unconditionally, configure SMTP AUTH with SSL support.
Group Require SMTP AUTH Before Relaying from Untrusted Clients
[ref] SMTP 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
Group Enact SMTP Recipient Restrictions
[ref] 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 systems in `mynetworks`. Then, the `reject_unauth_destination` option denies all mail whose destination address is not local, preventing any other systems from relaying. These two options should always appear in this order, and should usually follow one another immediately unless SMTP AUTH is used.
Group Use TLS for SMTP AUTH
[ref] 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.
Group Enact SMTP Relay Restrictions
[ref] 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 systems in `mynetworks`. Then, the `reject_unauth_destination` option denies all mail whose destination address is not local, preventing any other systems from relaying. These two options should always appear in this order, and should usually follow one another immediately unless SMTP AUTH is used.
Group Configure Trusted Networks and Hosts
- [ref] Edit `/etc/postfix/main.cf`, and configure the contents of the `mynetworks` variable in one of the following ways: If any system 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 = host
- If the set of systems 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
Group Configure Postfix Resource Usage to Limit Denial of Service Attacks
[ref] Edit `/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. Warning: Note: The values given here are examples, and may need to be modified for any particular site. By default, the Postfix anvil process gathers mail receipt statistics. To get information about about what connection rates are typical at your site, look in `/var/log/maillog` for lines with the daemon name postfix/anvil.
Group FTP Server
[ref] FTP is a common method for allowing remote access to files. Like telnet, the FTP protocol is unencrypted, which means that passwords and other data transmitted during the session can be captured and that the session is vulnerable to hijacking. Therefore, running the FTP server software is not recommended. However, there are some FTP server configurations which may be appropriate for some environments, particularly those which allow only read-only anonymous access as a means of downloading data available to the public.
Group Configure vsftpd to Provide FTP Service if Necessary
[ref] The primary vsftpd configuration file is `/etc/vsftpd.conf`, if that file exists, or `/etc/vsftpd/vsftpd.conf` if it does not.
Group Restrict the Set of Users Allowed to Access FTP
[ref] This section describes how to disable non-anonymous (password-based) FTP logins, or, if it is not possible to do this entirely due to legacy applications, how to restrict insecure FTP login to only those users who have an identified need for this access.
Group Use vsftpd to Provide FTP Service if Necessary
[ref] If your use-case requires FTP service, install and set-up vsftpd to provide it.
Group Disable vsftpd if Possible
[ref] To minimize attack surface, disable vsftpd if at all possible.
Group Network Time Protocol
[ref] The Network Time Protocol is used to manage the system clock over a network. Computer clocks are not very accurate, so time will drift unpredictably on unmanaged systems. Central time protocols can be used both to ensure that time is consistent among a network of systems, 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://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/servers/Configuring_NTP_Using_the_chrony_Suite/ 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.
Group Proxy Server
[ref] A proxy server is a very desirable target for a potential adversary because much (or all) sensitive data for a given infrastructure may flow through it. Therefore, if one is required, the system acting as a proxy server should be dedicated to that purpose alone and be stored in a physically secure location. The system's default proxy server software is Squid, and provided in an RPM package of the same name.
Group Disable Squid if Possible
[ref] If Squid was installed and activated, but the system does not need to act as a proxy server, then it should be disabled and removed.
Group Avahi Server
[ref] The Avahi daemon implements the DNS Service Discovery and Multicast DNS protocols, which provide service and host discovery on a network. It allows a system to automatically identify resources on the network, such as printers or web servers. This capability is also known as mDNSresponder and is a major part of Zeroconf networking.
Group Configure Avahi if Necessary
[ref] 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.
Group Disable Avahi Server if Possible
[ref] Because the Avahi daemon service keeps an open network port, it is subject to network attacks. Disabling it can reduce the system's vulnerability to such attacks.
Group LDAP
[ref] LDAP is a popular directory service, that is, a standardized way of looking up information from a central database. Red Hat Virtualization 4 includes software that enables a system to act as both an LDAP client and server.
Group Configure OpenLDAP Server
[ref] This section details some security-relevant settings for an OpenLDAP server.
Group Install and Protect LDAP Certificate Files
[ref] Create 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.
Group Configure OpenLDAP Clients
[ref] This section provides information on which security settings are important to configure in OpenLDAP clients by manually editing the appropriate configuration files. Red Hat Virtualization 4 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 Virtualization 4 is available at Warning: Before configuring any system to be an LDAP client, ensure that a working LDAP server is present on the network.
Group Print Support
[ref] The Common Unix Printing System (CUPS) service provides both local and network printing support. A system running the CUPS service can accept print jobs from other systems, process them, and send them to the appropriate printer. It also provides an interface for remote administration through a web browser. The CUPS service is installed and activated by default. The project homepage and more detailed documentation are available at http://www.cups.org.
Group Configure the CUPS Service if Necessary
[ref] CUPS provides the ability to easily share local printers with other systems over the network. It does this by allowing systems to share lists of available printers. Additionally, each system that runs the CUPS service can potentially act as a print server. Whenever possible, the printer sharing and print server capabilities of CUPS should be limited or disabled. The following recommendations should demonstrate how to do just that.
Group Samba(SMB) Microsoft Windows File Sharing Server
[ref] When properly configured, the Samba service allows Linux systems to provide file and print sharing to Microsoft Windows systems. There are two software packages that provide Samba support. The first, `samba-client`, provides a series of command line tools that enable a client system to access Samba shares. The second, simply labeled `samba`, provides the Samba service. It is this second package that allows a Linux system to act as an Active Directory server, a domain controller, or as a domain member. Only the `samba-client` package is installed by default.
Group Configure Samba if Necessary
[ref] All settings for the Samba daemon can be found in `/etc/samba/smb.conf`. Settings are divided between a `[global]` configuration section and a series of user created share definition sections meant to describe file or print shares on the system. By default, Samba will operate in user mode and allow client systems to access local home directories and printers. It is recommended that these settings be changed or that additional limitations be set in place.
Group Restrict SMB File Sharing to Configured Networks
[ref] Only users with local user accounts will be able to log in to Samba shares by default. Shares can be limited to particular users or network addresses. Use the `hosts allow` and `hosts deny` directives accordingly, and consider setting the valid users directive to a limited subset of users or to a group of users. Separate each address, user, or user group with a space as follows 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
Group Restrict Printer Sharing
[ref] By default, Samba utilizes the CUPS printing service to enable printer sharing with Microsoft Windows workstations. If there are no printers on the local system, or if printer sharing with Microsoft Windows is not required, disable the printer sharing capability by commenting out the following lines, found in `/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
Group Disable Samba if Possible
[ref] 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.
Group Cron and At Daemons
[ref] The cron and at services are used to allow commands to be executed at a later time. The cron service is required by almost all systems to perform necessary maintenance tasks, while at may or may not be required on a given system. Both daemons should be configured defensively.
Group Restrict at and cron to Authorized Users if Necessary
- [ref] 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.deny
- Edit `/etc/cron.allow`, adding one line for each user allowed to use the crontab command to create cron jobs. Remove the `at.deny` file:
      $ sudo rm /etc/at.deny
Edit `/etc/at.allow`, adding one line for each user allowed to use the at command to create at jobs.
Group Deprecated services
[ref] Some deprecated software services impact the overall system security due to their behavior (leak of confidentiality in network exchange, usage as uncontrolled communication channel, risk associated with the service due to its old age, etc.
Group NFS and RPC
[ref] The Network File System is a popular distributed filesystem for the Unix environment, and is very widely deployed. This section discusses the circumstances under which it is possible to disable NFS and its dependencies, and then details steps which should be taken to secure NFS's configuration. This section is relevant to systems operating as NFS clients, as well as to those operating as NFS servers.
Group Configure NFS Clients
[ref] The steps in this section are appropriate for systems which operate as NFS clients.
Group Mount Remote Filesystems with Restrictive Options
[ref] Edit the file `/etc/fstab`. For each filesystem whose type (column 3) is `nfs` or `nfs4`, add the text `,nodev,nosuid` to the list of mount options in column 4. If appropriate, also add `,noexec`. See the section titled "Restrict Partition Mount Options" for a description of the effects of these options. In general, execution of files mounted via NFS should be considered risky because of the possibility that an adversary could intercept the request and substitute a malicious file. Allowing setuid files to be executed from remote servers is particularly risky, both for this reason and because it requires the clients to extend root-level trust to the NFS server.
Group Disable NFS Server Daemons
[ref] There is no need to run the NFS server daemons `nfs` and `rpcsvcgssd` except on a small number of properly secured systems designated as NFS servers. Ensure that these daemons are turned off on clients.
Group Configure All Systems which Use NFS
[ref] The steps in this section are appropriate for all systems which run NFS, whether they operate as clients or as servers.
Group Configure NFS Services to Use Fixed Ports (NFSv3 and NFSv2)
[ref] Firewalling should be done at each host and at the border firewalls to protect the NFS daemons from remote access, since NFS servers should never be accessible from outside the organization. However, by default for NFSv3 and NFSv2, the RPC Bind service assigns each NFS service to a port dynamically at service startup time. Dynamic ports cannot be protected by port filtering firewalls such as `iptables`. Therefore, restrict each service to always use a given port, so that firewalling can be done effectively. Note that, because of the way RPC is implemented, it is not possible to disable the RPC Bind service even if ports are assigned statically to all RPC services. In NFSv4, the mounting and locking protocols have been incorporated into the protocol, and the server listens on the the well-known TCP port 2049. As such, NFSv4 does not need to interact with the `rpcbind, lockd, and rpc.statd` daemons, which can and should be disabled in a pure NFSv4 environment. The `rpc.mountd` daemon is still required on the NFS server to setup exports, but is not involved in any over-the-wire operations.
Group Make Each System a Client or a Server, not Both
[ref] If NFS must be used, it should be deployed in the simplest configuration possible to avoid maintainability problems which may lead to unnecessary security exposure. Due to the reliability and security problems caused by NFS (specially NFSv3 and NFSv2), it is not a good idea for systems which act as NFS servers to also mount filesystems via NFS. At the least, crossed mounts (the situation in which each of two servers mounts a filesystem from the other) should never be used.
Group Disable All NFS Services if Possible
[ref] If there is not a reason for the system to operate as either an NFS client or an NFS server, follow all instructions in this section to disable subsystems required by NFS. Warning: The steps in this section will prevent a system from operating as either an NFS client or an NFS server. Only perform these steps on systems which do not need NFS at all.
Group Disable netfs if Possible
[ref] To determine if any network filesystems handled by netfs are currently mounted on the system execute the following command:
    $ mount -t nfs,nfs4,smbfs,cifs,ncpfs
If the command did not return any output then disable netfs.
Group Disable Services Used Only by NFS
[ref] If NFS is not needed, disable the NFS client daemons nfslock, rpcgssd, and rpcidmapd. All of these daemons run with elevated privileges, and many listen for network connections. If they are not needed, they should be disabled to improve system security posture.
Group Configure NFS Servers
[ref] The steps in this section are appropriate for systems which operate as NFS servers.
Group Use Access Lists to Enforce Authorization Restrictions
[ref] When configuring NFS exports, ensure that each export line in `/etc/exports` contains a list of hosts which are allowed to access that export. If no hosts are specified on an export line, then that export is available to any remote host which requests it. All lines of the exports file should specify the hosts (or subnets, if needed) which are allowed to access the exported directory, so that unknown or remote hosts will be denied. Authorized hosts can be specified in several different formats: Name or alias that is recognized by the resolver Fully qualified domain name IP address IP subnets in the format `address/netmask` or `address/CIDR`
Group Configure the Exports File Restrictively
[ref] Linux's NFS implementation uses the file `/etc/exports` to control what filesystems and directories may be accessed via NFS. (See the `exports(5)` manpage for more information about the format of this file.) The syntax of the `exports` file is not necessarily checked fully on reload, and syntax errors can leave your NFS configuration more open than intended. Therefore, exercise caution when modifying the file. The syntax of each line in `/etc/exports` is:
    /DIR	host1(opt1,opt2) host2(opt3)
where `/DIR` is a directory or filesystem to export, `hostN` is an IP address, netblock, hostname, domain, or netgroup to which to export, and `optN` is an option.
Group Export Filesystems Read-Only if Possible
[ref] If a filesystem is being exported so that users can view the files in a convenient fashion, but there is no need for users to edit those files, exporting the filesystem read-only removes an attack vector against the server. The default filesystem export mode is `ro`, so do not specify `rw` without a good reason.
Group IMAP and POP3 Server
[ref] Dovecot provides IMAP and POP3 services. It is not installed by default. The project page at http://www.dovecot.org contains more detailed information about Dovecot configuration.
Group Configure Dovecot if Necessary
[ref] If the system will operate as an IMAP or POP3 server, the dovecot software should be configured securely by following the recommendations below.
Group Enable SSL Support
[ref] SSL should be used to encrypt network traffic between the Dovecot server and its clients. Users must authenticate to the Dovecot server in order to read their mail, and passwords should never be transmitted in clear text. In addition, protecting mail as it is downloaded is a privacy measure, and clients may use SSL certificates to authenticate the server, preventing another system from impersonating the server.
Group Support Only the Necessary Protocols
[ref] Dovecot supports the IMAP and POP3 protocols, as well as SSL-protected versions of those protocols. Configure the Dovecot server to support only the protocols needed by your site. Edit `/etc/dovecot/dovecot.conf`. Add or correct the following lines, replacing `PROTOCOL` with only the subset of protocols (`imap`, `imaps`, `pop3`, `pop3s`) required:
    protocols = PROTOCOL
If possible, require SSL protection for all transactions. The SSL protocol variants listen on alternate ports (995 instead of 110 for pop3s, and 993 instead of 143 for imaps), and require SSL-aware clients. An alternate approach is to listen on the standard port and require the client to use the STARTTLS command before authenticating.
Group Allow IMAP Clients to Access the Server
[ref] The default iptables configuration does not allow inbound access to any services. This modification will allow remote hosts to initiate connections to the IMAP daemon, while keeping all other ports on the server in their default protected state. To configure `iptables` to allow port 143 traffic, one must edit `/etc/sysconfig/iptables` and `/etc/sysconfig/ip6tables` (if IPv6 is in use). Add the following line, ensuring that it appears before the final LOG and DROP lines for the INPUT chain:
    -A INPUT -m state --state NEW -p tcp --dport 143 -j ACCEPT
Group Disable Dovecot
[ref] If the system does not need to operate as an IMAP or POP3 server, the dovecot software should be disabled and removed.
Group Introduction
[ref] The purpose of this guidance is to provide security configuration recommendations and baselines for the Red Hat Virtualization 4 operating system. Recommended settings for the basic operating system are provided, as well as for many network services that the system can provide to other systems. The guide is intended for system administrators. Readers are assumed to possess basic system administration skills for Unix-like systems, as well as some familiarity with the product's documentation and administration conventions. Some instructions within this guide are complex. All directions should be followed completely and with understanding of their effects in order to avoid serious adverse effects on the system and its security.
Group How to Use This Guide
[ref] Readers should heed the following points when using the guide.
Group Root Shell Environment Assumed
[ref] 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.
Group Test in Non-Production Environment
[ref] 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.
Group Formatting Conventions
[ref] 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.
Group Read Sections Completely and in Order
[ref] 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.
Group Reboot Required
[ref] 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.
Group General Principles
[ref] The following general principles motivate much of the advice in this guide and should also influence any configuration decisions that are not explicitly covered.
Group Configure Security Tools to Improve System Robustness
[ref] 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 host-based firewalling, SELinux for protection against vulnerable services, and a logging and auditing infrastructure for detection of problems.
Group Encrypt Transmitted Data Whenever Possible
[ref] 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 Virtualization 4 machines can and should be configured so that no unencrypted authentication data is ever transmitted between machines.
Group Least Privilege
[ref] 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.
Group Minimize Software to Minimize Vulnerability
[ref] The simplest way to avoid vulnerabilities in software is to avoid installing that software. On Red Hat Virtualization 4,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.
Group Run Different Network Services on Separate Systems
[ref] 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.

Red Hat and Red Hat Enterprise Linux are either registered trademarks or trademarks of Red Hat, Inc. in the United States and other countries. All other names are registered trademarks or trademarks of their respective companies.