Introductiongroup

The purpose of this guidance is to provide security configuration recommendations and baselines for the Fedora 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 Fedora's documentation and administration conventions. Some instructions within this guide are complex. All directions should be followed completely and with understanding of their effects in order to avoid serious adverse effects on the system and its security.

General Principlesgroup

The following general principles motivate much of the advice in this guide and should also influence any configuration decisions that are not explicitly covered.

Encrypt Transmitted Data Whenever Possiblegroup

Data transmitted over a network, whether wired or wireless, is susceptible to passive monitoring. Whenever practical solutions for encrypting such data exist, they should be applied. Even if data is expected to be transmitted only over a local network, it should still be encrypted. Encrypting authentication data, such as passwords, is particularly important. Networks of Fedora machines can and should be configured so that no unencrypted authentication data is ever transmitted between machines.

Minimize Software to Minimize Vulnerabilitygroup

The simplest way to avoid vulnerabilities in software is to avoid installing that software. On Fedora, the RPM Package Manager (originally Red Hat Package Manager, abbreviated RPM) allows for careful management of the set of software packages installed on a system. Installed software contributes to system vulnerability in several ways. Packages that include setuid programs may provide local attackers a potential path to privilege escalation. Packages that include network services may give this opportunity to network-based attackers. Packages that include programs which are predictably executed by local users (e.g. after graphical login) may provide opportunities for trojan horses or other attack code to be run undetected. The number of software packages installed on a system can almost always be significantly pruned to include only the software for which there is an environmental or operational need.

Run Different Network Services on Separate Systemsgroup

Whenever possible, a server should be dedicated to serving exactly one network service. This limits the number of other services that can be compromised in the event that an attacker is able to successfully exploit a software flaw in one network service.

Configure Security Tools to Improve System Robustnessgroup

Several tools exist which can be effectively used to improve a system's resistance to and detection of unknown attacks. These tools can improve robustness against attack at the cost of relatively little configuration effort. In particular, this guide recommends and discusses the use of Iptables for host-based firewalling, SELinux for protection against vulnerable services, and a logging and auditing infrastructure for detection of problems.

Least Privilegegroup

Grant the least privilege necessary for user accounts and software to perform tasks. For example, sudo can be implemented to limit authorization to super user accounts on the system only to designated personnel. Another example is to limit logins on server systems to only those administrators who need to log into them in order to perform administration tasks. Using SELinux also follows the principle of least privilege: SELinux policy can confine software to perform only actions on the system that are specifically allowed. This can be far more restrictive than the actions permissible by the traditional Unix permissions model.

How to Use This Guidegroup

Readers should heed the following points when using the guide.

Read Sections Completely and in Ordergroup

Each section may build on information and recommendations discussed in prior sections. Each section should be read and understood completely; instructions should never be blindly applied. Relevant discussion may occur after instructions for an action.

Test in Non-Production Environmentgroup

This guidance should always be tested in a non-production environment before deployment. This test environment should simulate the setup in which the system will be deployed as closely as possible.

Root Shell Environment Assumedgroup

Most of the actions listed in this document are written with the assumption that they will be executed by the root user running the /bin/bash shell. Commands preceded with a hash mark (#) assume that the administrator will execute the commands as root, i.e. apply the command via sudo whenever possible, or use su to gain root privileges if sudo cannot be used. Commands which can be executed as a non-root user are are preceded by a dollar sign ($) prompt.

Formatting Conventionsgroup

Commands intended for shell execution, as well as configuration file text, are featured in a monospace font. Italics are used to indicate instances where the system administrator must substitute the appropriate information into a command or configuration file.

Reboot Requiredgroup

A system reboot is implicitly required after some actions in order to complete the reconfiguration of the system. In many cases, the changes will not take effect until a reboot is performed. In order to ensure that changes are applied properly and to test functionality, always reboot the system after applying a set of recommendations from this guide.

System Settingsgroup

General System Wide Configuration Settingsgroup

The following sections contain information on various security-relevant configuration settings that in particular way modify the behaviour of the system as a whole.

Installing and Maintaining Softwaregroup

The following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates.

Updating Softwaregroup

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.



Fedora systems contain an installed software catalog called the RPM database, which records metadata of installed packages. Tools such as yum or the graphical Software Update ensure usage of RPM packages for software installation. This allows for insight into the current inventory of installed software on the system, and is highly recommended.

Software Integrity Checkinggroup

Both the AIDE (Advanced Intrusion Detection Environment) software and the RPM package management system provide mechanisms for verifying the integrity of installed software. AIDE uses snapshots of file metadata (such as hashes) and compares these to current system files in order to detect changes. The RPM package management system can conduct integrity checks by comparing information in its metadata database with files installed on the system.



Integrity checking cannot prevent intrusions, but can detect that they have occurred. Requirements for software integrity checking may be highly dependent on the environment in which the system will be used. Snapshot-based approaches such as AIDE may induce considerable overhead in the presence of frequent software updates.

Verify Integrity with AIDEgroup

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.

Verify Integrity with RPMgroup

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

Additional Security Softwaregroup

Additional security software that is not provided or supported by Red Hat can be installed to provide complementary or duplicative security capabilities to those provided by the base platform. Add-on software may not be appropriate for some specialized systems.

File Permissions and Masksgroup

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.

Verify File Permissions Within Some Important Directoriesgroup

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.

Account and Access Controlgroup

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 Fedora.

Protect Accounts by Restricting Password-Based Logingroup

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.

Restrict Root Loginsgroup

Direct root logins should be allowed only for emergency use. In normal situations, the administrator should access the system via a unique unprivileged account, and then use su or sudo to execute privileged commands. Discouraging administrators from accessing the root account directly ensures an audit trail in organizations with multiple administrators. Locking down the channels through which root can connect directly also reduces opportunities for password-guessing against the root account. The login program uses the file /etc/securetty to determine which interfaces should allow root logins. The virtual devices /dev/console and /dev/tty* represent the system consoles (accessible via the Ctrl-Alt-F1 through Ctrl-Alt-F6 keyboard sequences on a default installation). The default securetty file also contains /dev/vc/*. These are likely to be deprecated in most environments, but may be retained for compatibility. Furthermore, /dev/hvc* represent virtio-serial consoles, /dev/hvsi* IBM pSeries serial consoles, and finally /dev/xvc0 Xen virtual console. 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.

Proper Storage and Existence of Password Hashesgroup

By default, password hashes for local accounts are stored in the second field (colon-separated) in /etc/shadow. This file should be readable only by processes running with root credentials, preventing users from casually accessing others' password hashes and attempting to crack them. However, it remains possible to misconfigure the system and store password hashes in world-readable files such as /etc/passwd, or to even store passwords themselves in plaintext on the system. Using system-provided tools for password change/creation should allow administrators to avoid such misconfiguration.

Set Password Expiration Parametersgroup

The file /etc/login.defs controls several password-related settings. Programs such as passwd, su, and login consult /etc/login.defs to determine behavior with regard to password aging, expiration warnings, and length. See the man page login.defs(5) for more information.



Users should be forced to change their passwords, in order to decrease the utility of compromised passwords. However, the need to change passwords often should be balanced against the risk that users will reuse or write down passwords if forced to change them too often. Forcing password changes every 90-360 days, depending on the environment, is recommended. Set the appropriate value as PASS_MAX_DAYS and apply it to existing accounts with the -M flag.



The PASS_MIN_DAYS (-m) setting prevents password changes for 7 days after the first change, to discourage password cycling. If you use this setting, train users to contact an administrator for an emergency password change in case a new password becomes compromised. The PASS_WARN_AGE (-W) setting gives users 7 days of warnings at login time that their passwords are about to expire.



For example, for each existing human user USER, expiration parameters could be adjusted to a 180 day maximum password age, 7 day minimum password age, and 7 day warning period with the following command:

# chage -M 180 -m 7 -W 7 USER

Protect Physical Console Accessgroup

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.

Set Boot Loader Passwordgroup

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 Fedora boot loader for x86 systems is called GRUB2. Options it can pass to the kernel include single-user mode, which provides root access without any authentication, and the ability to disable SELinux. To prevent local users from modifying the boot parameters and endangering security, protect the boot loader configuration with a password and ensure its configuration file's permissions are set properly.

Configure Screen Lockinggroup

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.

Configure GUI Screen Lockinggroup

In the default GNOME desktop, the screen can be locked by choosing Lock Screen from the System menu.



The gconftool-2 program can be used to enforce mandatory screen locking settings for the default GNOME environment. The following sections detail commands to enforce idle activation of the screen saver, screen locking, a blank-screen screensaver, and an idle activation time.



Because users should be trained to lock the screen when they step away from the computer, the automatic locking feature is only meant as a backup. The Lock Screen icon from the System menu can also be dragged to the taskbar in order to facilitate even more convenient screen-locking.



The root account cannot be screen-locked, but this should have no practical effect as the root account should never be used to log into an X Windows environment, and should only be used to for direct login via console in emergency circumstances.



For more information about configuring GNOME screensaver, see http://live.gnome.org/GnomeScreensaver. For more information about enforcing preferences in the GNOME environment using the GConf configuration system, see http://projects.gnome.org/gconf and the man page gconftool-2(1).

Configure Console Screen Lockinggroup

A console screen locking mechanism is provided in the screen package, which is not installed by default.

Hardware Tokens for Authenticationgroup

The use of hardware tokens such as smart cards for system login provides stronger, two-factor authentication than using a username/password. In Fedora servers and workstations, hardware token login is not enabled by default and must be enabled in the system settings.

Servicesgroup

The best protection against vulnerable software is running less software. This section describes how to review the software which Fedora installs on a system and disable software which is not needed. It then enumerates the software packages installed on a default Fedora system and provides guidance about which ones can be safely disabled.



Fedora provides a convenient minimal install option that essentially installs the bare necessities for a functional system. When building Fedora servers, it is highly recommended to select the minimal packages and then build up the system from there.

Network Time Protocolgroup

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 machines, and that their time is consistent with the outside world.



If every system on a network reliably reports the same time, then it is much easier to correlate log messages in case of an attack. In addition, a number of cryptographic protocols (such as Kerberos) use timestamps to prevent certain types of attacks. If your network does not have synchronized time, these protocols may be unreliable or even unusable.



Depending on the specifics of the network, global time accuracy may be just as important as local synchronization, or not very important at all. If your network is connected to the Internet, using a public timeserver (or one provided by your enterprise) provides globally accurate timestamps which may be essential in investigating or responding to an attack which originated outside of your network.



A typical network setup involves a small number of internal systems operating as NTP servers, and the remainder obtaining time information from those internal servers.



More information on how to configure the NTP server software, including configuration of cryptographic authentication for time data, is available at http://www.ntp.org.

SSH Servergroup

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.

Configure OpenSSH Server if Necessarygroup

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.

FTP Servergroup

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.

Disable vsftpd if Possiblegroup

Use vsftpd to Provide FTP Service if Necessarygroup

Use vsftpd to Provide FTP Service if Necessarygroup

The primary vsftpd configuration file is /etc/vsftpd.conf, if that file exists, or /etc/vsftpd/vsftpd.conf if it does not.

Restrict the Set of Users Allowed to Access FTPgroup

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.

Limit Users Allowed FTP Access if Necessarygroup

If there is a mission-critical reason for users to access their accounts via the insecure FTP protocol, limit the set of users who are allowed this access. Edit the vsftpd configuration file. Add or correct the following configuration options:

userlist_enable=YES
userlist_file=/etc/vsftp.ftpusers
userlist_deny=NO

USERNAME

anonymous
ftp

Configure Firewalls to Protect the FTP Servergroup

By default, iptables blocks access to the ports used by the web server. To configure iptables to allow port 21 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 21 -j ACCEPT Edit the file /etc/sysconfig/iptables-config. Ensure that the space-separated list of modules contains the FTP connection tracking module:

IPTABLES_MODULES="ip_conntrack_ftp"

SNMP Servergroup

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.

Disable SNMP Server if Possiblegroup

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.

Configure SNMP Server if Necessarygroup

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

NFS and RPCgroup

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 machines operating as NFS clients, as well as to those operating as NFS servers.

Disable All NFS Services if Possiblegroup

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.

Disable Services Used Only by NFSgroup

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.

Disable netfs if Possiblegroup

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

Configure All Machines which Use NFSgroup

The steps in this section are appropriate for all machines which run NFS, whether they operate as clients or as servers.

Make Each Machine a Client or a Server, not Bothgroup

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 machines which act as NFS servers to also mount filesystems via NFS. At the least, crossed mounts (the situation in which each of two servers mounts a filesystem from the other) should never be used.

Configure NFS Services to Use Fixed Ports (NFSv3 and NFSv2)group

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.

Configure NFS Clientsgroup

The steps in this section are appropriate for machines which operate as NFS clients.

Disable NFS Server Daemonsgroup

There is no need to run the NFS server daemons nfs and rpcsvcgssd except on a small number of properly secured machines designated as NFS servers. Ensure that these daemons are turned off on clients.

Mount Remote Filesystems with Restrictive Optionsgroup

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.

Configure NFS Serversgroup

The steps in this section are appropriate for machines which operate as NFS servers.

Configure the Exports File Restrictivelygroup

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)

Use Access Lists to Enforce Authorization Restrictionsgroup

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

Export Filesystems Read-Only if Possiblegroup

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.