The SCAP Security Guide Project
https://fedorahosted.org/scap-security-guide

This guide presents a catalog of security-relevant configuration settings for Fedora release 20 (Heisenbug) formatted in the eXtensible Configuration Checklist Description Format (XCCDF).

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

Applicable platforms

  • cpe:/o:fedoraproject:fedora:20

Version: 0.0.3

Revision history

  • draft (as of 2013-10-22)

1. Introduction

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

link | previous | next | up | toc | home

1.1. General Principles

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

link | previous | next | up | toc | home

1.1.1. Encrypt Transmitted Data Whenever Possible

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.

link | previous | next | up | toc | home

1.1.2. Minimize Software to Minimize Vulnerability

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.

link | previous | next | up | toc | home

1.1.3. Run Different Network Services on Separate Systems

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.

link | previous | next | up | toc | home

1.1.4. Configure Security Tools to Improve System Robustness

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.

link | previous | next | up | toc | home

1.1.5. Least Privilege

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.

link | previous | next | up | toc | home

1.2. How to Use This Guide

Readers should heed the following points when using the guide.

link | previous | next | up | toc | home

1.2.1. Read Sections Completely and in Order

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.

link | previous | next | up | toc | home

1.2.2. Test in Non-Production Environment

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.

link | previous | next | up | toc | home

1.2.3. Root Shell Environment Assumed

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.

link | previous | next | up | toc | home

1.2.4. Formatting Conventions

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.

link | previous | next | up | toc | home

1.2.5. Reboot Required

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.

link | previous | next | up | toc | home

2. System Settings

link | previous | next | up | toc | home

2.1. Installing and Maintaining Software

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

link | previous | next | up | toc | home

2.1.1. Updating Software

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.

link | previous | next | up | toc | home

2.1.1.a. Ensure gpgcheck Enabled In Main Yum Configuration

The gpgcheck option should be used to ensure checking of an RPM package's signature always occurs prior to its installation. To configure yum to check package signatures before installing them, ensure the following line appears in /etc/yum.conf in the [main] section: 

gpgcheck=1

Ensuring the validity of packages' cryptographic signatures prior to installation ensures the provenance of the software and protects against malicious tampering.

link | previous | next | up | toc | home

2.1.1.b. Ensure gpgcheck Enabled For All Yum Package Repositories

To ensure signature checking is not disabled for any repos, remove any lines from files in /etc/yum.repos.d of the form: 

gpgcheck=0

Ensuring all packages' cryptographic signatures are valid prior to installation ensures the provenance of the software and protects against malicious tampering.

link | previous | next | up | toc | home

2.2. Account and Access Control

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.

link | previous | next | up | toc | home

2.2.1. Protect Accounts by Restricting Password-Based Login

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.

link | previous | next | up | toc | home

2.2.1.1. Restrict Root Logins

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.

link | previous | next | up | toc | home

2.2.1.1.a. Direct root Logins Not Allowed

To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to login to. If the file does not exist at all, the root user can login through any communication device on the system, whether via the console or via a raw network interface. This is dangerous as user can login to his machine as root via Telnet, which sends the password in plain text over the network. By default, Fedora's /etc/securetty file only allows the root user to login at the console physically attached to the machine. To prevent root from logging in, remove the contents of this file. To prevent direct root logins, remove the contents of this file by typing the following command: 


echo > /etc/securetty

Disabling direct root logins ensures proper accountability and multifactor authentication to privileged accounts. Users will first login, then escalate to privileged (root) access via su / sudo. This scenario is nowadays required by security standards.

link | previous | next | up | toc | home

2.2.1.1.b. Restrict Virtual Console Root Logins

To restrict root logins through the (deprecated) virtual console devices, ensure lines of this form do not appear in /etc/securetty: 

vc/1
vc/2
vc/3
vc/4

Preventing direct root login to virtual console devices helps ensure accountability for actions taken on the system using the root account.

link | previous | next | up | toc | home

2.2.1.1.c. Restrict Serial Port Root Logins

To restrict root logins on serial ports, ensure lines of this form do not appear in /etc/securetty: 

ttyS0
ttyS1

Preventing direct root login to serial port interfaces helps ensure accountability for actions taken on the systems using the root account.

link | previous | next | up | toc | home

2.2.1.1.d. Restrict Web Browser Use for Administrative Accounts

Enforce policy requiring administrative accounts use web browsers only for local service administration.

If a browser vulnerability is exploited while running with administrative privileges, the entire system could be compromised. Specific exceptions for local service administration should be documented in site-defined policy.

link | previous | next | up | toc | home

2.2.1.1.e. Ensure that System Accounts Do Not Run a Shell Upon Login

Some accounts are not associated with a human user of the system, and exist to perform some administrative function. Should an attacker be able to log into these accounts, they should not be granted access to a shell.

The login shell for each local account is stored in the last field of each line in /etc/passwd. System accounts are those user accounts with a user ID less than 500. The user ID is stored in the third field. If any system account SYSACCT (other than root) has a login shell, disable it with the command: 

# usermod -s /sbin/nologin SYSACCT

Do not perform the steps in this section on the root account. Doing so might cause the system to become inaccessible.

Ensuring shells are not given to system accounts upon login makes it more difficult for attackers to make use of system accounts.

link | previous | next | up | toc | home

2.2.1.1.f. Verify Only Root Has UID 0

If any account other than root has a UID of 0, this misconfiguration should be investigated and the accounts other than root should be removed or have their UID changed.

An account has root authority if it has a UID of 0. Multiple accounts with a UID of 0 afford more opportunity for potential intruders to guess a password for a privileged account. Proper configuration of sudo is recommended to afford multiple system administrators access to root privileges in an accountable manner.

link | previous | next | up | toc | home

2.2.1.1.g. Root Path Must Be Vendor Default

Assuming root shell is bash, edit the following files: 

~/.profile
~/.bashrc
Change any PATH variables to the vendor default for root and remove any empty PATH entries or references to relative paths.

The root account's executable search path must be the vendor default, and must contain only absolute paths.

link | previous | next | up | toc | home

2.2.1.2. Verify Proper Storage and Existence of Password Hashes

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.

link | previous | next | up | toc | home

2.2.1.2.a. Prevent Log In to Accounts With Empty Password

If an account is configured for password authentication but does not have an assigned password, it may be possible to log into the account without authentication. Remove any instances of the nullok option in /etc/pam.d/system-auth to prevent logins with empty passwords.

If an account has an empty password, anyone could log in and run commands with the privileges of that account. Accounts with empty passwords should never be used in operational environments.

link | previous | next | up | toc | home

2.2.1.2.b. Verify All Account Password Hashes are Shadowed

If any password hashes are stored in /etc/passwd (in the second field, instead of an x), the cause of this misconfiguration should be investigated. The account should have its password reset and the hash should be properly stored, or the account should be deleted entirely.

The hashes for all user account passwords should be stored in the file /etc/shadow and never in /etc/passwd, which is readable by all users.

link | previous | next | up | toc | home

2.2.1.2.c. All GIDs referenced in /etc/passwd must be defined in /etc/group

Add a group to the system for each GID referenced without a corresponding group.

Inconsistency in GIDs between /etc/passwd and /etc/group could lead to a user having unintended rights.

References

  1. 366. URL: <http://iase.disa.mil/cci/index.html>.

link | previous | next | up | toc | home

2.2.1.2.d. Verify No netrc Files Exist

The .netrc files contain login information used to auto-login into FTP servers and reside in the user's home directory. These files may contain unencrypted passwords to remote FTP servers making them susceptible to access by unauthorized users and should not be used. Any .netrc files should be removed.

Unencrypted passwords for remote FTP servers may be stored in .netrc files. DoD policy requires passwords be encrypted in storage and not used in access scripts.

link | previous | next | up | toc | home

2.2.1.3. Set Password Expiration Parameters

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

link | previous | next | up | toc | home

2.2.1.3.a. Set Password Minimum Length in login.defs

To specify password length requirements for new accounts, edit the file /etc/login.defs and add or correct the following lines: 

PASS_MIN_LEN 12


Nowadays recommended values, considered as secure by various organizations focused on topic of computer security, range from 12 (FISMA) up to 14 (DoD) characters for password length requirements. If a program consults /etc/login.defs and also another PAM module (such as pam_cracklib) during a password change operation, then the most restrictive must be satisfied. See PAM section for more information about enforcing password quality requirements.

Requiring a minimum password length makes password cracking attacks more difficult by ensuring a larger search space. However, any security benefit from an onerous requirement must be carefully weighed against usability problems, support costs, or counterproductive behavior that may result.

link | previous | next | up | toc | home

2.2.1.3.b. Set Password Minimum Age

To specify password minimum age for new accounts, edit the file /etc/login.defs and add or correct the following line, replacing the DAYS item as appropriate: 

PASS_MIN_DAYS DAYS
A value of 1 day is considered to be sufficient for many environments.

Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement.

link | previous | next | up | toc | home

2.2.1.3.c. Set Password Maximum Age

To specify password maximum age for new accounts, edit the file /etc/login.defs and add or correct the following line, replacing the DAYS item appropriately: 

PASS_MAX_DAYS DAYS
A value of 180 days is sufficient for many environments.

Setting the password maximum age ensures users are required to periodically change their passwords. This could possibly decrease the utility of a stolen password. Requiring shorter password lifetimes increases the risk of users writing down the password in a convenient location subject to physical compromise.

link | previous | next | up | toc | home

2.2.1.3.d. Set Password Warning Age

To specify how many days prior to password expiration that a warning will be issued to users, edit the file /etc/login.defs and add or correct the following line, replacing the DAYS item as appropriate: 

PASS_WARN_AGE DAYS
A value of 7 days would be nowadays considered to be a standard.

Setting the password warning age enables users to make the change at a practical time.

link | previous | next | up | toc | home

Colophon

Red Hat and Fedora 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.