python 2.6.6 5.10 2011-09-21T13:44:00 Ensure gpgcheck Enabled For All Yum Package Repositories Fedora 19 Ensure all yum repositories utilize signature checking. File grub.cfg Owned By root Group Red Hat Enterprise Linux 7 Fedora 20 The grub.cfg file should be owned by the root group. By default, this file is located at /boot/grub2/grub.cfg or, for EFI systems, at /boot/efi/EFI/redhat/grub.cfg Verify No netrc Files Exist Fedora 19 The .netrc files contain login information used to auto-login into FTP servers and reside in the user's home directory. Any .netrc files should be removed. Package net-snmp Removed Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 The RPM package net-snmp should be removed. Package ntp Installed Fedora 19 Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 The RPM package ntp should be installed. Set Password Expiration Parameters Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 The minimum password age policy should be set appropriately. Verify that System Executables Have Restrictive Permissions Fedora 19 Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Checks that binary files under /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, and /usr/local/sbin, are not group-writable or world-writable. File grub.cfg Owned By root User Red Hat Enterprise Linux 7 Fedora 20 The grub.cfg file should be owned by the root user. By default, this file is located at /boot/grub2/grub.cfg or, for EFI systems, at /boot/efi/EFI/redhat/grub.cfg Set Password Expiration Parameters Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 The password expiration warning age should be set appropriately. Restrict Virtual Console Root Logins Fedora 19 Preventing direct root login to virtual console devices helps ensure accountability for actions taken on the system using the root account. Specify a Remote NTP Server for Time Data Fedora 19 A remote NTP Server for time synchronization should be specified Ensure Yum gpgcheck Globally Activated Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 The gpgcheck option should be used to ensure that checking of an RPM package's signature always occurs prior to its installation. Fedora release 19 (Schrödinger's Cat) Fedora 19 The operating system installed on the system is Fedora release 19 (Schrödinger's Cat) Package vsftpd Installed Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 The RPM package vsftpd should be installed. File grub.cfg Permissions Red Hat Enterprise Linux 7 Fedora 20 File permissions for grub.cfg should be set to 0600 (or stronger). By default, this file is located at /boot/grub2/grub.cfg or, for EFI systems, at /boot/efi/EFI/redhat/grub.cfg Set Password Expiration Parameters Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 The password minimum length should be set appropriately. Set Password Expiration Parameters Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 The maximum password age policy should meet minimum requirements. Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 6 The operating system installed on the system is Red Hat Enterprise Linux 6 Restrict Serial Port Root Logins Fedora 19 Preventing direct root login to serial port interfaces helps ensure accountability for actions taken on the system using the root account. Verify that System Executables Have Root Ownership Fedora 19 Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Checks that /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, and objects therein, are owned by root. Package Antivirus Installed Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 Antivirus software should be installed. Set ClientAliveCountMax for User Logins Fedora 19 The SSH ClientAliveCountMax should be set to an appropriate value (and dependencies are met) Service ntpd Enabled Fedora 19 The ntpd service should be enabled. SNMP default communities disabled Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 SNMP default communities must be removed. Package openssh-server Removed Fedora 19 Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 The RPM package openssh-server should be removed. All Password Hashes Shadowed Fedora 19 All password hashes should be shadowed. SNMP use newer protocols Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 SNMP version 1 and 2c must not be enabled. Set OpenSSH Idle Timeout Interval Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 The SSH idle timeout interval should be set to an appropriate value. UID 0 Belongs Only To Root Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 Only the root account should be assigned a user id of 0. Banner for FTP Users Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 To trace malicious activity facilitated by the FTP service, it must be configured to ensure that all commands sent to the FTP server are logged using the verbose vsftpd log format. Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 7 The operating system installed on the system is Red Hat Enterprise Linux 7 Service sshd Disabled Fedora 19 The sshd service should be disabled. Disable root Login via SSH Fedora 19 Root login via SSH should be disabled (and dependencies are met) Verify that Shared Library Files Have Restrictive Permissions Fedora 19 Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Checks that /lib, /lib64, /usr/lib, /usr/lib64, /lib/modules, and objects therein, are not group-writable or world-writable. Set Boot Loader Password Red Hat Enterprise Linux 7 Fedora 20 The grub2 boot loader should have password protection enabled. Ensure insecure_locks is disabled Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 Allowing insecure file locking could allow for sensitive data to be viewed or edited by an unauthorized user. Disable Prelinking Red Hat Enterprise Linux 6 Fedora 20 The prelinking feature can interfere with the operation of checksum integrity tools (e.g. AIDE), mitigates the protection provided by ASLR, and requires additional CPU cycles by software upgrades. No nullok Option in /etc/pam.d/system-auth Fedora 19 The file /etc/pam.d/system-auth should not contain the nullok option Banner for FTP Users Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 This setting will cause the system greeting banner to be used for FTP connections as well. Disable Empty Passwords Fedora 19 Remote connections from accounts with empty passwords should be disabled (and dependencies are met) Verify that Shared Library Files Have Root Ownership Fedora 19 Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Checks that /lib, /lib64, /usr/lib, /usr/lib64, /lib/modules, and objects therein, are owned by root. System Accounts Do Not Run a Shell Fedora 19 The root account is the only system account that should have a login shell. /etc/yum.repos.d .* ^\s*gpgcheck\s*=\s*0\s*$ 1 /boot/grub2/grub.cfg /boot/efi/EFI/redhat/grub.cfg /home ^\.netrc$ net-snmp ntp /etc/login.defs ^[\s]*PASS_MIN_DAYS[\s]+(\d+)[\s]*(?:|(?:#.*))?$ 1 ^\/(|s)bin|^\/usr\/(|local\/)(|s)bin ^.*$ oval:ssg:ste:272 oval:ssg:ste:273 /boot/grub2/grub.cfg /boot/efi/EFI/redhat/grub.cfg /etc/login.defs ^[\s]*PASS_WARN_AGE[\s]+(\d+)[\s]*(?:|(?:#.*))?$ 1 /etc/securetty ^vc/[0-9]+$ 1 /etc/ntp.conf ^[\s]*server[\s]+.+$ 1 /etc/yum.conf ^\s*gpgcheck\s*=\s*1\s*$ 1 fedora-release vsftpd /boot/grub2/grub.cfg /boot/efi/EFI/redhat/grub.cfg /etc/login.defs ^[\s]*PASS_MIN_LEN[\s]+(\d+)[\s]*(?:|(?:#.*))?$ 1 /etc/login.defs ^[\s]*PASS_MAX_DAYS[\s]+(\d+)[\s]*(?:|(?:#.*))?$ 1 redhat-release-workstation redhat-release-server /etc/securetty ^ttyS[0-9]+$ 1 ^\/(|s)bin|^\/usr\/(|local\/)(|s)bin oval:ssg:ste:274 ^\/(|s)bin|^\/usr\/(|local\/)(|s)bin ^.*$ oval:ssg:ste:274 McAfeeVSEForLinux /etc/ssh/sshd_config ^[\s]*(?i)ClientAliveCountMax[\s]+([\d]+)[\s]*$ 1 /etc/systemd/system/multi-user.target.wants/ntpd.service oval:ssg:ste:275 /etc/snmp/snmpd.conf ^[\s]*(com2se|rocommunity|rwcommunity|createUser).*(public|private) 1 openssh-server .* /etc/snmp/snmpd.conf ^[\s]*(com2se|rocommunity|rwcommunity) 1 /etc/ssh/sshd_config ^[\s]*(?i)ClientAliveInterval[\s]+(\d+)[\s]*(?:|(?:#.*))?$ 1 /etc/passwd ^(?!root:)[^:]*:[^:]*:0 1 /etc/vsftpd/vsftpd.conf ^[\s]*xferlog_enable[\s]*=[\s]*YES$ 1 /etc/vsftpd/vsftpd.conf ^[\s]*xferlog_std_format[\s]*=[\s]*NO$ 1 /etc/vsftpd/vsftpd.conf ^[\s]*log_ftp_protocol[\s]*=[\s]*YES$ 1 redhat-release-workstation redhat-release-server /etc/systemd/system/multi-user.target.wants/sshd.service oval:ssg:ste:275 /etc/ssh/sshd_config ^(?i)(?:(?!\n\s*PermitRootLogin\s+yes).)*(\n\s*PermitRootLogin\s+no)(.*)$ 1 ^\/lib(|64)|^\/usr\/lib(|64) oval:ssg:ste:276 oval:ssg:ste:277 ^\/lib(|64)|^\/usr\/lib(|64) ^.*$ oval:ssg:ste:276 oval:ssg:ste:277 /etc/grub2.cfg ^[\s]*set[\s]+superusers=\"(?i)(?!root|admin|administrator)(?-i).*\"$ 1 /etc/grub2.cfg ^[\s]*password_pbkdf2[\s]+.*[\s]+grub\.pbkdf2\.sha512.*$ 1 /etc/exports ^(.*?(\binsecure_locks\b)[^$]*)$ 1 /etc/sysconfig/prelink ^[\s]*PRELINKING=no[\s]* 1 /etc/pam.d/system-auth \s*nullok\s* 1 /etc/vsftpd/vsftpd.conf ^[\s]*banner_file[\s]*=[\s]*/etc/issue*$ 1 /etc/ssh/sshd_config ^(?i)\s*PermitEmptyPasswords\s+(yes|no)\s*$ 1 /etc/ssh/sshd_config ^(?i)(?:(?!\n\s*PermitEmptyPasswords\s+yes).)*(\n\s*PermitEmptyPasswords\s+no)(.*)$ 1 ^\/lib(|64)\/|^\/usr\/lib(|64)\/ oval:ssg:ste:278 ^\/lib(|64)\/|^\/usr\/lib(|64)\/ ^.*$ oval:ssg:ste:278 /etc/passwd ^(?!root).*:x:[\d]*:0*([0-9]{1,2}|[1-4][0-9]{2}):[^:]*:[^:]*:(?!\/sbin\/nologin|\/bin\/sync|\/sbin\/shutdown|\/sbin\/halt).*$ 1 0 true true symbolic link 0 unix ^19$ false false false false false false false ^6.*$ ^6.*$ 0 0 symbolic link x 0 unix ^7.*$ ^7.*$ true true symbolic link 0 draft Guide to the Secure Configuration of Fedora This guide presents a catalog of security-relevant configuration settings for Fedora operating system 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). 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.

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. 0.0.4 Common Profile for General-Purpose Fedora Systems This profile contains items common to general-purpose Fedora installations. A conditional clause for check statements. A conditional clause for check statements. This is a placeholder. Introduction 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 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. 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. 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. 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. 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. 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. How to Use This Guide Readers should heed the following points when using the guide. 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. 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. 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. 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. 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. System Settings General System Wide Configuration Settings The following sections contain information on various security-relevant configuration settings that in particular way modify the behaviour of the system as a whole. Prelinking Disabled The prelinking feature changes binaries in an attempt to decrease their startup time. In order to disable it, change or add the following line inside the file /etc/sysconfig/prelink: 
PRELINKING=no
Next, run the following command to return binaries to a normal, non-prelinked state: 
# /sbin/prelink -ua
 CM-6(d) CM-6(3) SC-28 SI-7 The prelinking feature can interfere with the operation of checksum integrity tools (e.g. AIDE), because it modifies binaries to speed up their startup time. Also it makes the location of shared libraries very predictable, mitigating the efficiency of address space layout randomization (ASLR) protection mechanism. In addition, each upgrade of an application or a library requires prelink to be run again. # # Disable prelinking altogether # if grep -q ^PRELINKING /etc/sysconfig/prelink then sed -i 's/PRELINKING.*/PRELINKING=no/g' /etc/sysconfig/prelink else echo -e "\n# Set PRELINKING=no per security requirements" >> /etc/sysconfig/prelink echo "PRELINKING=no" >> /etc/sysconfig/prelink fi # # Undo previous prelink changes to binaries # /usr/sbin/prelink -ua 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. 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. 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
 SI-7 MA-1(b) 352 663 Ensuring the validity of packages' cryptographic signatures prior to installation ensures the provenance of the software and protects against malicious tampering. To determine whether yum is configured to use gpgcheck, inspect /etc/yum.conf and ensure the following appears in the [main] section: 
gpgcheck=1
A value of 1 indicates that gpgcheck is enabled. Absence of a gpgcheck line or a setting of 0 indicates that it is disabled. 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
 SI-7 MA-1(b) 352 663 Ensuring all packages' cryptographic signatures are valid prior to installation ensures the provenance of the software and protects against malicious tampering. To determine whether yum has been configured to disable gpgcheck for any repos, inspect all files in /etc/yum.repos.d and ensure the following does not appear in any sections: 
gpgcheck=0
A value of 0 indicates that gpgcheck has been disabled for that repo. Software Integrity Checking 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 AIDE 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. Install AIDE Install the AIDE package with the command: 
# yum install aide
 CM-3(d) CM-3(e) CM-6(d) CM-6(3) SC-28 SI-7 1069 The AIDE package must be installed if it is to be available for integrity checking. Run the following command to determine if the aide package is installed: # rpm -q aide Build and Test AIDE Database Run the following command to generate a new database: 
# /usr/sbin/aide --init
By default, the database will be written to the file /var/lib/aide/aide.db.new.gz. Storing the database, the configuration file /etc/aide.conf, and the binary /usr/sbin/aide (or hashes of these files), in a secure location (such as on read-only media) provides additional assurance about their integrity. The newly-generated database can be installed as follows: 
# cp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
To initiate a manual check, run the following command: 
# /usr/sbin/aide --check
If this check produces any unexpected output, investigate. CM-3(d) CM-3(e) CM-6(d) CM-6(3) SC-28 SI-7 For AIDE to be effective, an initial database of "known-good" information about files must be captured and it should be able to be verified against the installed files. Configure Periodic Execution of AIDE To implement a daily execution of AIDE at 4:05am using cron, add the following line to /etc/crontab: 
05 4 * * * root /usr/sbin/aide --check
AIDE can be executed periodically through other means; this is merely one example. CM-3(d) CM-3(e) CM-6(d) CM-6(3) SC-28 SI-7 374 416 1069 1263 1297 1589 By default, AIDE does not install itself for periodic execution. Periodically running AIDE is necessary to reveal unexpected changes in installed files. To determine that periodic AIDE execution has been scheduled, run the following command: 
# grep aide /etc/crontab
 Verify Integrity with RPM 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. Verify and Correct File Permissions with RPM The RPM package management system can check file access permissions of installed software packages, including many that are important to system security. After locating a file with incorrect permissions, run the following command to determine which package owns it: 
# rpm -qf FILENAME
Next, run the following command to reset its permissions to the correct values: 
# rpm --setperms PACKAGENAME
 AC-6 CM-6(d) CM-6(3) 1493 1494 1495 Permissions on system binaries and configuration files that are too generous could allow an unauthorized user to gain privileges that they should not have. The permissions set by the vendor should be maintained. Any deviations from this baseline should be investigated. The following command will list which files on the system have permissions different from what is expected by the RPM database: 
# rpm -Va | grep '^.M'
 Verify File Hashes with RPM The RPM package management system can check the hashes of installed software packages, including many that are important to system security. Run the following command to list which files on the system have hashes that differ from what is expected by the RPM database: 
# rpm -Va | grep '^..5'
A "c" in the second column indicates that a file is a configuration file, which may appropriately be expected to change. If the file was not expected to change, investigate the cause of the change using audit logs or other means. The package can then be reinstalled to restore the file. Run the following command to determine which package owns the file: 
# rpm -qf FILENAME
The package can be reinstalled from a yum repository using the command: 
yum reinstall PACKAGENAME
Alternatively, the package can be reinstalled from trusted media using the command: 
rpm -Uvh PACKAGENAME
 CM-6(d) CM-6(3) SI-7 1496 The hashes of important files like system executables should match the information given by the RPM database. Executables with erroneous hashes could be a sign of nefarious activity on the system. The following command will list which files on the system have file hashes different from what is expected by the RPM database. 
# rpm -Va | awk '$1 ~ /..5/ && $2 != "c"'
 Additional Security Software 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. Install Intrusion Detection Software The Red Hat platform includes a sophisticated auditing system and SELinux, which provide host-based intrusion detection capabilities. SC-7 1263 Host-based intrusion detection tools provide a system-level defense when an intruder gains access to a system or network. Inspect the system to determine if intrusion detection software has been installed. Verify this intrusion detection software is active. Install Virus Scanning Software Install virus scanning software, which uses signatures to search for the presence of viruses on the filesystem. The McAfee VirusScan Enterprise for Linux virus scanning tool is provided for DoD systems. Ensure virus definition files are no older than 7 days, or their last release. Configure the virus scanning software to perform scans dynamically on all accessed files. If this is not possible, configure the system to scan all altered files on the system on a daily basis. If the system processes inbound SMTP mail, configure the virus scanner to scan all received mail. SC-28 SI-3 1239 1668 Virus scanning software can be used to detect if a system has been compromised by computer viruses, as well as to limit their spread to other systems. Inspect the system for a cron job or system service which executes a virus scanning tool regularly.
To verify the McAfee VSEL system service is operational, run the following command: 
# /etc/init.d/nails status

To check on the age of uvscan virus definition files, run the following command: 
# cd /opt/NAI/LinuxShield/engine/dat
# ls -la avvscan.dat avvnames.dat avvclean.dat
 File Permissions and Masks 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 Directories 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. Shared Library Files Have Restrictive Permissions System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: 
/lib
/lib64
/usr/lib
/usr/lib64
Kernel modules, which can be added to the kernel during runtime, are stored in /lib/modules. All files in these directories should not be group-writable or world-writable. If any file in these directories is found to be group-writable or world-writable, correct its permission with the following command: 
# chmod go-w FILE
 AC-6 1499 Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Restrictive permissions are necessary to protect the integrity of the system. Shared Library Files Have Root Ownership System-wide shared library files, which are linked to executables during process load time or run time, are stored in the following directories by default: 
/lib
/lib64
/usr/lib
/usr/lib64
Kernel modules, which can be added to the kernel during runtime, are also stored in /lib/modules. All files in these directories should be owned by the root user. If the directory, or any file in these directories, is found to be owned by a user other than root correct its ownership with the following command: 
# chown root FILE
 AC-6 1499 Files from shared library directories are loaded into the address space of processes (including privileged ones) or of the kernel itself at runtime. Proper ownership is necessary to protect the integrity of the system. System Executables Have Restrictive Permissions System executables are stored in the following directories by default: 
/bin
/usr/bin
/usr/local/bin
/sbin
/usr/sbin
/usr/local/sbin
All files in these directories should not be group-writable or world-writable. If any file FILE in these directories is found to be group-writable or world-writable, correct its permission with the following command: 
# chmod go-w FILE
 AC-6 1499 System binaries are executed by privileged users, as well as system services, and restrictive permissions are necessary to ensure execution of these programs cannot be co-opted. System Executables Have Root Ownership System executables are stored in the following directories by default: 
/bin
/usr/bin
/usr/local/bin
/sbin
/usr/sbin
/usr/local/sbin
All files in these directories should be owned by the root user. If any file FILE in these directories is found to be owned by a user other than root, correct its ownership with the following command: 
# chown root FILE
 AC-6 1499 System binaries are executed by privileged users as well as system services, and restrictive permissions are necessary to ensure that their execution of these programs cannot be co-opted. 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. 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. 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. 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
IA-2(1) 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. To ensure root may not directly login to the system over physical consoles, run the following command: 
cat /etc/securetty
If any output is returned, this is a finding. Virtual Console Root Logins Restricted 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
 AC-6(2) 770 Preventing direct root login to virtual console devices helps ensure accountability for actions taken on the system using the root account. To check for virtual console entries which permit root login, run the following command: 
# grep ^vc/[0-9] /etc/securetty
If any output is returned, then root logins over virtual console devices is permitted. Serial Port Root Logins Restricted To restrict root logins on serial ports, ensure lines of this form do not appear in /etc/securetty: 
ttyS0
ttyS1
 AC-6(2) 770 Preventing direct root login to serial port interfaces helps ensure accountability for actions taken on the systems using the root account. To check for serial port entries which permit root login, run the following command: 
# grep ^ttyS/[0-9] /etc/securetty
If any output is returned, then root login over serial ports is permitted. Web Browser Use for Administrative Accounts Restricted 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. Check the root home directory for a .mozilla directory. If one exists, ensure browsing is limited to local service administration. 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. 178 Ensuring shells are not given to system accounts upon login makes it more difficult for attackers to make use of system accounts. To obtain a listing of all users, their UIDs, and their shells, run the command: 
$ awk -F: '{print $1 ":" $3 ":" $7}' /etc/passwd
Identify the system accounts from this listing. These will primarily be the accounts with UID numbers less than 500, other than root. 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. AC-6 IA-2(1) 366 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. To list all password file entries for accounts with UID 0, run the following command: 
# awk -F: '($3 == "0") {print}' /etc/passwd
This should print only one line, for the user root. Root Path Is 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. To view the root user's PATH, run the following command: 
# env | grep PATH
If correctly configured, the PATH must: use vendor default settings, have no empty entries, and have no entries beginning with a character other than a slash (/). 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. Log In to Accounts With Empty Password Impossible 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. IA-5(b) IA-5(c) IA-5(1)(a) 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. To verify that null passwords cannot be used, run the following command: 
# grep nullok /etc/pam.d/system-auth
If this produces any output, it may be possible to log into accounts with empty passwords. Password Hashes For Each Account 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. IA-5(h) 201 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. To check that no password hashes are stored in /etc/passwd, run the following command: 
# awk -F: '($2 != "x") {print}' /etc/passwd
If it produces any output, then a password hash is stored in /etc/passwd. All GIDs referenced in /etc/passwd Defined in /etc/group Add a group to the system for each GID referenced without a corresponding group. 366 Inconsistency in GIDs between /etc/passwd and /etc/group could lead to a user having unintended rights. To ensure all GIDs referenced in /etc/passwd are defined in /etc/group, run the following command: 
# pwck -qr
There should be no output. netrc Files Do Not 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. IA-5(h) 196 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. To check the system for the existence of any .netrc files, run the following command: 
# find /home -xdev -name .netrc
 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
 minimum password length Minimum number of characters in password This will only check new passwords 12 6 8 10 12 14 maximum password age Maximum age of password in days This will only apply to newly created accounts 60 60 90 120 180 minimum password age Minimum age of password in days This will only apply to newly created accounts 7 7 5 1 2 0 warning days before password expires The number of days' warning given before a password expires. This will only apply to newly created accounts 7 0 7 14 Password Minimum Length To specify password length requirements for new accounts, edit the file /etc/login.defs, locate the following line: 
PASS_MIN_LEN LENGTH
and correct it to have the form of: 
PASS_MIN_LEN

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. IA-5(f) IA-5(1)(a) 205 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. var_accounts_password_minlen_login_defs="" grep -q ^PASS_MIN_LEN /etc/login.defs && \ sed -i "s/PASS_MIN_LEN.*/PASS_MIN_LEN\t$var_accounts_password_minlen_login_defs/g" /etc/login.defs if ! [ $? -eq 0 ] then echo -e "PASS_MIN_LEN\t$var_accounts_password_minlen_login_defs" >> /etc/login.defs fi To check the minimum password length, run the command: 
$ grep PASS_MIN_LEN /etc/login.defs
Passwords of length 12 characters and more are nowadays considered to be a standard requirement. Password Minimum Age To specify password minimum age for new accounts, edit the file /etc/login.defs, locate the following line: 
PASS_MIN_DAYS DAYS
and correct it to have the form of: 
PASS_MIN_DAYS

A value greater than 1 day is considered to be sufficient for many environments. IA-5(f) IA-5(1)(d) 198 Setting the minimum password age protects against users cycling back to a favorite password after satisfying the password reuse requirement. var_accounts_minimum_age_login_defs="" grep -q ^PASS_MIN_DAYS /etc/login.defs && \ sed -i "s/PASS_MIN_DAYS.*/PASS_MIN_DAYS\t$var_accounts_minimum_age_login_defs/g" /etc/login.defs if ! [ $? -eq 0 ] then echo -e "PASS_MIN_DAYS\t$var_accounts_minimum_age_login_defs" >> /etc/login.defs fi To check the minimum password age, run the command: 
$ grep PASS_MIN_DAYS /etc/login.defs
A value greater than 1 day is considered to be sufficient for many environments. Password Maximum Age To specify password maximum age for new accounts, edit the file /etc/login.defs, locate the following line: 
PASS_MAX_DAYS DAYS
and correct it to have the form of: 
PASS_MAX_DAYS

A value less than 180 days is sufficient for many environments. IA-5(f) IA-5(g) IA-5(1)(d) 180 199 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. var_accounts_maximum_age_login_defs="" grep -q ^PASS_MAX_DAYS /etc/login.defs && \ sed -i "s/PASS_MAX_DAYS.*/PASS_MAX_DAYS\t$var_accounts_maximum_age_login_defs/g" /etc/login.defs if ! [ $? -eq 0 ] then echo -e "PASS_MAX_DAYS\t$var_accounts_maximum_age_login_defs" >> /etc/login.defs fi To check the maximum password age, run the command: 
$ grep PASS_MAX_DAYS /etc/login.defs
A value less than 180 days is sufficient for many environments. 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, locate the following line: 
PASS_WARN_AGE DAYS
and correct it to have the form of: 
PASS_WARN_AGE

A value of 7 days would be nowadays considered to be a standard. IA-5(f) Setting the password warning age enables users to make the change at a practical time. var_accounts_password_warn_age_login_defs="" grep -q ^PASS_WARN_AGE /etc/login.defs && \ sed -i "s/PASS_WARN_AGE.*/PASS_WARN_AGE\t$var_accounts_password_warn_age_login_defs/g" /etc/login.defs if ! [ $? -eq 0 ] then echo -e "PASS_WARN_AGE\t$var_accounts_password_warn_age_login_defs" >> /etc/login.defs fi To check the password warning age, run the command: 
$ grep PASS_WARN_AGE /etc/login.defs
A value of 7 days would be nowadays considered to be a standard. Protect Physical Console Access 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 Password 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. Verify /boot/grub2/grub.cfg User Ownership The file /boot/grub2/grub.cfg should be owned by the root user to prevent destruction or modification of the file. To properly set the owner of /boot/grub2/grub.cfg, run the command: # chown root/boot/grub2/grub.cfg 225 Only root should be able to modify important boot parameters. To check the ownership of /boot/grub2/grub.cfg, run the command: $ ls -lL /boot/grub2/grub.cfg If properly configured, the output should indicate the following owner: root Verify /boot/grub2/grub.cfg Group Ownership The file /boot/grub2/grub.cfg should be group-owned by the root group to prevent destruction or modification of the file. To properly set the group owner of /boot/grub2/grub.cfg, run the command: # chgrp root/boot/grub2/grub.cfg 225 The root group is a highly-privileged group. Furthermore, the group-owner of this file should not have any access privileges anyway. To check the group ownership of /boot/grub2/grub.cfg, run the command: $ ls -lL /boot/grub2/grub.cfg If properly configured, the output should indicate the following group-owner. root Verify /boot/grub2/grub.cfg Permissions File permissions for /boot/grub2/grub.cfg should be set to 600, which is the default. To properly set the permissions of /boot/grub2/grub.cfg, run the command: # chmod 600/boot/grub2/grub.cfg 225 Proper permissions ensure that only the root user can modify important boot parameters. To check the permissions of /boot/grub2/grub.cfg, run the command: 
$ sudo ls -lL /boot/grub2/grub.cfg
If properly configured, the output should indicate the following permissions: -rw------- Set Boot Loader Password The grub2 boot loader should have a superuser account and password protection enabled to protect boot-time settings.

To do so, select a superuser account and password and add them into the appropriate grub2 configuration file(s) under /etc/grub.d. Since plaintext passwords are a security risk, generate a hash for the pasword by running the following command: 
$ grub2-mkpasswd-pbkdf2
When prompted, enter the password that was selected and insert the returned password hash into the appropriate grub2 configuration file(s) under /etc/grub.d immediately after the superuser account. (Use the output from grub2-mkpasswd-pbkdf2 as the value of password-hash): 
password_pbkdf2 superusers-account password-hash
NOTE: It is recommended not to use common administrator account names like root, admin, or administrator for the grub2 superuser account.
To meet FISMA Moderate, the bootloader superuser account and password MUST differ from the root account and password. Once the superuser account and password have been added, update the grub.cfg file by running: 
grub2-mkconfig -o /boot/grub2/grub.cfg
NOTE: Do NOT manually add the superuser account and password to the grub.cfg file as the grub2-mkconfig command overwrites this file. IA-2(1) IA-5(e) 213 Password protection on the boot loader configuration ensures users with physical access cannot trivially alter important bootloader settings. These include which kernel to use, and whether to enter single-user mode. For more information on how to configure the grub2 superuser account and password, please refer to
  • https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sec-GRUB_2_Password_Protection.html
    • .
To verify the boot loader superuser account and superuser account password have been set, and the password encrypted, run the following command: 
sudo grep -A1 "superusers\|password" /etc/grub2.cfg
The output should show the following: 
set superusers="superusers-account"
password_pbkdf2 superusers-account password-hash
 Require Authentication for Single User Mode Single-user mode is intended as a system recovery method, providing a single user root access to the system by providing a boot option at startup. By default, no authentication is performed if single-user mode is selected.

To require entry of the root password even if the system is started in single-user mode, add or correct the following line in the file /etc/sysconfig/init: 
SINGLE=/sbin/sulogin
 IA-2(1) 213 This prevents attackers with physical access from trivially bypassing security on the machine and gaining root access. Such accesses are further prevented by configuring the bootloader password. To check if authentication is required for single-user mode, run the following command: 
$ grep SINGLE /etc/sysconfig/init
The output should be the following: 
SINGLE=/sbin/sulogin
 Disable Ctrl-Alt-Del Reboot Activation By default, the system includes the following line in /etc/init/control-alt-delete.conf to reboot the system when the Ctrl-Alt-Del key sequence is pressed: 
exec /sbin/shutdown -r now "Control-Alt-Delete pressed"

To configure the system to log a message instead of rebooting the system, alter that line to read as follows: 
exec /usr/bin/logger -p security.info "Control-Alt-Delete pressed"
 A locally logged-in user who presses Ctrl-Alt-Del, when at the console, can reboot the system. If accidentally pressed, as could happen in the case of mixed OS environment, this can create the risk of short-term loss of availability of systems due to unintentional reboot. In the GNOME graphical environment, risk of unintentional reboot from the Ctrl-Alt-Del sequence is reduced because the user will be prompted before any action is taken. To ensure the system is configured to log a message instead of rebooting the system when Ctrl-Alt-Del is pressed, ensure the following line is in /etc/init/control-alt-delete.conf: 
exec /usr/bin/logger -p security.info "Control-Alt-Delete pressed"
 Disable Interactive Boot To disable the ability for users to perform interactive startups, edit the file /etc/sysconfig/init. Add or correct the line: 
PROMPT=no
The PROMPT option allows the console user to perform an interactive system startup, in which it is possible to select the set of services which are started on boot. SC-2 213 Using interactive boot, the console user could disable auditing, firewalls, or other services, weakening system security. To check whether interactive boot is disabled, run the following command: 
$ grep PROMPT /etc/sysconfig/init
If interactive boot is disabled, the output will show: 
PROMPT=no
 Configure Screen Locking 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 Locking 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). Inactivity timeout Choose allowed duration of inactive SSH connections, shells, and X sessions 15 5 10 15 Set GNOME Login Inactivity Timeout Run the following command to set the idle time-out value for inactivity in the GNOME desktop to 15 minutes: 
# gconftool-2 \
  --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --type int \
  --set /apps/gnome-screensaver/idle_delay 15
 AC-11(a) 57 Setting the idle delay controls when the screensaver will start, and can be combined with screen locking to prevent access from passersby. To check the current idle time-out value, run the following command: 
$ gconftool-2 -g /apps/gnome-screensaver/idle_delay
If properly configured, the output should be 15. GNOME Desktop Screensaver Mandatory Use Run the following command to activate the screensaver in the GNOME desktop after a period of inactivity: 
# gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --type bool \
  --set /apps/gnome-screensaver/idle_activation_enabled true
 AC-11(a) 57 Enabling idle activation of the screen saver ensures the screensaver will be activated after the idle delay. Applications requiring continuous, real-time screen display (such as network management products) require the login session does not have administrator rights and the display station is located in a controlled-access area. To check the screensaver mandatory use status, run the following command: 
$ gconftool-2 -g /apps/gnome-screensaver/idle_activation_enabled
If properly configured, the output should be true. Enable Screen Lock Activation After Idle Period Run the following command to activate locking of the screensaver in the GNOME desktop when it is activated: 
# gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --type bool \
  --set /apps/gnome-screensaver/lock_enabled true
 AC-11(a) 57 Enabling the activation of the screen lock after an idle period ensures password entry will be required in order to access the system, preventing access by passersby. To check the status of the idle screen lock activation, run the following command: 
$ gconftool-2 -g /apps/gnome-screensaver/lock_enabled
If properly configured, the output should be true. Implement Blank Screen Saver Run the following command to set the screensaver mode in the GNOME desktop to a blank screen: 
# gconftool-2 --direct \
  --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory \
  --type string \
  --set /apps/gnome-screensaver/mode blank-only
 AC-11(b) 60 Setting the screensaver mode to blank-only conceals the contents of the display from passersby. To ensure the screensaver is configured to be blank, run the following command: 
$ gconftool-2 -g /apps/gnome-screensaver/mode
If properly configured, the output should be blank-only Configure Console Screen Locking A console screen locking mechanism is provided in the screen package, which is not installed by default. Install the screen Package To enable console screen locking, install the screen package: 
# yum install screen
Instruct users to begin new terminal sessions with the following command: 
$ screen
The console can now be locked with the following key combination: 
ctrl+a x
 58 Installing screen ensures a console locking capability is available for users who may need to suspend console logins. Run the following command to determine if the screen package is installed: # rpm -q screen Hardware Tokens for Authentication 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. Enable Smart Card Login To enable smart card authentication, consult the documentation at:
  • https://docs.fedoraproject.org/docs/en-US/Fedora/18/html/Security_Guide/sect-Security_Guide-Single_Sign_on_SSO-Getting_Started_with_your_new_Smart_Card.html
 765 766 767 768 771 772 884 Smart card login provides two-factor authentication stronger than that provided by a username/password combination. Smart cards leverage a PKI (public key infrastructure) in order to provide and verify credentials. Interview the SA to determine if all accounts not exempted by policy are using CAC authentication. Services 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 Protocol 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. NTP Daemon Enabled The ntpd service can be enabled with the following command: # systemctl enable ntpd.service AU-8(1) 160 Enabling the ntpd service ensures that the ntpd service will be running and that the system will synchronize its time to any servers specified. This is important whether the system is configured to be a client (and synchronize only its own clock) or it is also acting as an NTP server to other systems. Synchronizing time is essential for authentication services such as Kerberos, but it is also important for maintaining accurate logs and auditing possible security breaches.

The NTP daemon offers all of the functionality of ntpdate, which is now deprecated. Additional information on this is available at http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate # # Install ntp package if necessary # yum -y install ntp # # Enable ntpd service (for current systemd target) # systemctl enable ntpd.service # # Start ntpd if not currently running # systemctl start ntpd.service Remote NTP Server Specified To specify a remote NTP server for time synchronization, edit the file /etc/ntp.conf. Add or correct the following lines, substituting the IP or hostname of a remote NTP server for ntpserver: 
server ntpserver
This instructs the NTP software to contact that remote server to obtain time data. AU-8(1) 160 Synchronizing with an NTP server makes it possible to collate system logs from multiple sources or correlate computer events with real time events. SSH Server 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. SSH session Idle time Specify duration of allowed idle time. 300 300 600 900 Configure OpenSSH Server if Necessary 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. SSH Root Login Disabled The root user should never be allowed to login to a system directly over a network. To disable root login via SSH, add or correct the following line in /etc/ssh/sshd_config: 
PermitRootLogin no
 AC-6(2) IA-2(1) 770 Permitting direct root login reduces auditable information about who ran privileged commands on the system and also allows direct attack attempts on root's password. SSHD_CONFIG='/etc/ssh/sshd_config' # Obtain line number of first uncommented case-insensitive occurrence of Match # block directive (possibly prefixed with whitespace) present in $SSHD_CONFIG FIRST_MATCH_BLOCK=$(sed -n '/^[[:space:]]*Match[^\n]*/I{=;q}' $SSHD_CONFIG) # Obtain line number of first uncommented case-insensitive occurence of # PermitRootLogin directive (possibly prefixed with whitespace) present in # $SSHD_CONFIG FIRST_PERMIT_ROOT_LOGIN=$(sed -n '/^[[:space:]]*PermitRootLogin[^\n]*/I{=;q}' $SSHD_CONFIG) # Case: Match block directive not present in $SSHD_CONFIG if [ -z "$FIRST_MATCH_BLOCK" ] then # Case: PermitRootLogin directive not present in $SSHD_CONFIG yet if [ -z "$FIRST_PERMIT_ROOT_LOGIN" ] then # Append 'PermitRootLogin no' at the end of $SSHD_CONFIG echo -e "\nPermitRootLogin no" >> $SSHD_CONFIG # Case: PermitRootLogin directive present in $SSHD_CONFIG already else # Replace first uncommented case-insensitive occurrence # of PermitRootLogin directive sed -i "$FIRST_PERMIT_ROOT_LOGIN s/^[[:space:]]*PermitRootLogin.*$/PermitRootLogin no/I" $SSHD_CONFIG fi # Case: Match block directive present in $SSHD_CONFIG else # Case: PermitRootLogin directive not present in $SSHD_CONFIG yet if [ -z "$FIRST_PERMIT_ROOT_LOGIN" ] then # Prepend 'PermitRootLogin no' before first uncommented # case-insensitive occurrence of Match block directive sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/PermitRootLogin no\n\1/I" $SSHD_CONFIG # Case: PermitRootLogin directive present in $SSHD_CONFIG and placed # before first Match block directive elif [ "$FIRST_PERMIT_ROOT_LOGIN" -lt "$FIRST_MATCH_BLOCK" ] then # Replace first uncommented case-insensitive occurrence # of PermitRootLogin directive sed -i "$FIRST_PERMIT_ROOT_LOGIN s/^[[:space:]]*PermitRootLogin.*$/PermitRootLogin no/I" $SSHD_CONFIG # Case: PermitRootLogin directive present in $SSHD_CONFIG and placed # after first Match block directive else # Prepend 'PermitRootLogin no' before first uncommented # case-insensitive occurrence of Match block directive sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/PermitRootLogin no\n\1/I" $SSHD_CONFIG fi fi SSH Access via Empty Passwords Disabled To explicitly disallow remote login from accounts with empty passwords, add or correct the following line in /etc/ssh/sshd_config: 
PermitEmptyPasswords no
Any accounts with empty passwords should be disabled immediately, and PAM configuration should prevent users from being able to assign themselves empty passwords. 765 766 Configuring this setting for the SSH daemon provides additional assurance that remote login via SSH will require a password, even in the event of misconfiguration elsewhere. SSHD_CONFIG='/etc/ssh/sshd_config' # Obtain line number of first uncommented case-insensitive occurrence of Match # block directive (possibly prefixed with whitespace) present in $SSHD_CONFIG FIRST_MATCH_BLOCK=$(sed -n '/^[[:space:]]*Match[^\n]*/I{=;q}' $SSHD_CONFIG) # Obtain line number of first uncommented case-insensitive occurence of # PermitEmptyPasswords directive (possibly prefixed with whitespace) present in # $SSHD_CONFIG FIRST_PERMIT_EMPTY_PASSWORDS=$(sed -n '/^[[:space:]]*PermitEmptyPasswords[^\n]*/I{=;q}' $SSHD_CONFIG) # Case: Match block directive not present in $SSHD_CONFIG if [ -z "$FIRST_MATCH_BLOCK" ] then # Case: PermitEmptyPasswords directive not present in $SSHD_CONFIG yet if [ -z "$FIRST_PERMIT_EMPTY_PASSWORDS" ] then # Append 'PermitEmptyPasswords no' at the end of $SSHD_CONFIG echo -e "\nPermitEmptyPasswords no" >> $SSHD_CONFIG # Case: PermitEmptyPasswords directive present in $SSHD_CONFIG already else # Replace first uncommented case-insensitive occurrence # of PermitEmptyPasswords directive sed -i "$FIRST_PERMIT_EMPTY_PASSWORDS s/^[[:space:]]*PermitEmptyPasswords.*$/PermitEmptyPasswords no/I" $SSHD_CONFIG fi # Case: Match block directive present in $SSHD_CONFIG else # Case: PermitEmptyPasswords directive not present in $SSHD_CONFIG yet if [ -z "$FIRST_PERMIT_EMPTY_PASSWORDS" ] then # Prepend 'PermitEmptyPasswords no' before first uncommented # case-insensitive occurrence of Match block directive sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/PermitEmptyPasswords no\n\1/I" $SSHD_CONFIG # Case: PermitEmptyPasswords directive present in $SSHD_CONFIG and placed # before first Match block directive elif [ "$FIRST_PERMIT_EMPTY_PASSWORDS" -lt "$FIRST_MATCH_BLOCK" ] then # Replace first uncommented case-insensitive occurrence # of PermitEmptyPasswords directive sed -i "$FIRST_PERMIT_EMPTY_PASSWORDS s/^[[:space:]]*PermitEmptyPasswords.*$/PermitEmptyPasswords no/I" $SSHD_CONFIG # Case: PermitEmptyPasswords directive present in $SSHD_CONFIG and placed # after first Match block directive else # Prepend 'PermitEmptyPasswords no' before first uncommented # case-insensitive occurrence of Match block directive sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/PermitEmptyPasswords no\n\1/I" $SSHD_CONFIG fi fi SSH Idle Timeout Interval Used SSH allows administrators to set an idle timeout interval. After this interval has passed, the idle user will be automatically logged out.

To set an idle timeout interval, edit the /etc/ssh/sshd_config file, locate the following line: 
ClientAliveInterval INTERVAL
and correct it to have the form of: 
ClientAliveInterval
The timeout INTERVAL is given in seconds. To have a timeout of 15 minutes, set INTERVAL to 900.

If a shorter timeout has already been set for the login shell, that value will preempt any SSH setting made here. Keep in mind that some processes may stop SSH from correctly detecting that the user is idle. 879 1133 Causing idle users to be automatically logged out guards against compromises one system leading trivially to compromises on another. sshd_idle_timeout_value="" SSHD_CONFIG='/etc/ssh/sshd_config' # Obtain line number of first uncommented case-insensitive occurrence of Match # block directive (possibly prefixed with whitespace) present in $SSHD_CONFIG FIRST_MATCH_BLOCK=$(sed -n '/^[[:space:]]*Match[^\n]*/I{=;q}' $SSHD_CONFIG) # Obtain line number of first uncommented case-insensitive occurence of # ClientAliveInterval directive (possibly prefixed with whitespace) present in # $SSHD_CONFIG FIRST_CLIENT_ALIVE_INTERVAL=$(sed -n '/^[[:space:]]*ClientAliveInterval[^\n]*/I{=;q}' $SSHD_CONFIG) # Case: Match block directive not present in $SSHD_CONFIG if [ -z "$FIRST_MATCH_BLOCK" ] then # Case: ClientAliveInterval directive not present in $SSHD_CONFIG yet if [ -z "$FIRST_CLIENT_ALIVE_INTERVAL" ] then # Append 'ClientAliveInterval $sshd_idle_timeout_value' at the end of $SSHD_CONFIG echo -e "\nClientAliveInterval $sshd_idle_timeout_value" >> $SSHD_CONFIG # Case: ClientAliveInterval directive present in $SSHD_CONFIG already else # Replace first uncommented case-insensitive occurrence # of ClientAliveInterval directive sed -i "$FIRST_CLIENT_ALIVE_INTERVAL s/^[[:space:]]*ClientAliveInterval.*$/ClientAliveInterval $sshd_idle_timeout_value/I" $SSHD_CONFIG fi # Case: Match block directive present in $SSHD_CONFIG else # Case: ClientAliveInterval directive not present in $SSHD_CONFIG yet if [ -z "$FIRST_CLIENT_ALIVE_INTERVAL" ] then # Prepend 'ClientAliveInterval $sshd_idle_timeout_value' before first uncommented # case-insensitive occurrence of Match block directive sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/ClientAliveInterval $sshd_idle_timeout_value\n\1/I" $SSHD_CONFIG # Case: ClientAliveInterval directive present in $SSHD_CONFIG and placed # before first Match block directive elif [ "$FIRST_CLIENT_ALIVE_INTERVAL" -lt "$FIRST_MATCH_BLOCK" ] then # Replace first uncommented case-insensitive occurrence # of ClientAliveInterval directive sed -i "$FIRST_CLIENT_ALIVE_INTERVAL s/^[[:space:]]*ClientAliveInterval.*$/ClientAliveInterval $sshd_idle_timeout_value/I" $SSHD_CONFIG # Case: ClientAliveInterval directive present in $SSHD_CONFIG and placed # after first Match block directive else # Prepend 'ClientAliveInterval $sshd_idle_timeout_value' before first uncommented # case-insensitive occurrence of Match block directive sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/ClientAliveInterval $sshd_idle_timeout_value\n\1/I" $SSHD_CONFIG fi fi SSH Client Alive Count Used To ensure the SSH idle timeout occurs precisely when the ClientAliveCountMax is set, edit /etc/ssh/sshd_config as follows: 
ClientAliveCountMax 0
 879 1133 This ensures a user login will be terminated as soon as the ClientAliveCountMax is reached. SSHD_CONFIG='/etc/ssh/sshd_config' # Obtain line number of first uncommented case-insensitive occurrence of Match # block directive (possibly prefixed with whitespace) present in $SSHD_CONFIG FIRST_MATCH_BLOCK=$(sed -n '/^[[:space:]]*Match[^\n]*/I{=;q}' $SSHD_CONFIG) # Obtain line number of first uncommented case-insensitive occurence of # ClientAliveCountMax directive (possibly prefixed with whitespace) present in # $SSHD_CONFIG FIRST_CLIENT_ALIVE_COUNT_MAX=$(sed -n '/^[[:space:]]*ClientAliveCountMax[^\n]*/I{=;q}' $SSHD_CONFIG) # Case: Match block directive not present in $SSHD_CONFIG if [ -z "$FIRST_MATCH_BLOCK" ] then # Case: ClientAliveCountMax directive not present in $SSHD_CONFIG yet if [ -z "$FIRST_CLIENT_ALIVE_COUNT_MAX" ] then # Append 'ClientAliveCountMax 0' at the end of $SSHD_CONFIG echo -e "\nClientAliveCountMax 0" >> $SSHD_CONFIG # Case: ClientAliveCountMax directive present in $SSHD_CONFIG already else # Replace first uncommented case-insensitive occurrence # of ClientAliveCountMax directive sed -i "$FIRST_CLIENT_ALIVE_COUNT_MAX s/^[[:space:]]*ClientAliveCountMax.*$/ClientAliveCountMax 0/I" $SSHD_CONFIG fi # Case: Match block directive present in $SSHD_CONFIG else # Case: ClientAliveCountMax directive not present in $SSHD_CONFIG yet if [ -z "$FIRST_CLIENT_ALIVE_COUNT_MAX" ] then # Prepend 'ClientAliveCountMax 0' before first uncommented # case-insensitive occurrence of Match block directive sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/ClientAliveCountMax 0\n\1/I" $SSHD_CONFIG # Case: ClientAliveCountMax directive present in $SSHD_CONFIG and placed # before first Match block directive elif [ "$FIRST_CLIENT_ALIVE_COUNT_MAX" -lt "$FIRST_MATCH_BLOCK" ] then # Replace first uncommented case-insensitive occurrence # of ClientAliveCountMax directive sed -i "$FIRST_CLIENT_ALIVE_COUNT_MAX s/^[[:space:]]*ClientAliveCountMax.*$/ClientAliveCountMax 0/I" $SSHD_CONFIG # Case: ClientAliveCountMax directive present in $SSHD_CONFIG and placed # after first Match block directive else # Prepend 'ClientAliveCountMax 0' before first uncommented # case-insensitive occurrence of Match block directive sed -i "$FIRST_MATCH_BLOCK s/^\([[:space:]]*Match[^\n]*\)/ClientAliveCountMax 0\n\1/I" $SSHD_CONFIG fi fi FTP Server 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 Possible Disable vsftpd Service The vsftpd service can be disabled with the following command: # systemctl disable vsftpd.service CM-7 1436 Running FTP server software provides a network-based avenue of attack, and should be disabled if not needed. Furthermore, the FTP protocol is unencrypted and creates a risk of compromising sensitive information. To check that the vsftpd service is disabled in system boot configuration, run the following command: # chkconfig vsftpd --list Output should indicate the vsftpd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig vsftpd --list vsftpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify vsftpd is disabled through current runtime configuration: # service vsftpd status If the service is disabled the command will return the following output: vsftpd is stopped Uninstall vsftpd Package The vsftpd package can be removed with the following command: # yum erase vsftpd CM-7 1436 Removing the vsftpd package decreases the risk of its accidental activation. Run the following command to determine if the vsftpd package is installed: # rpm -q vsftpd Use vsftpd to Provide FTP Service if Necessary Install vsftpd Package If this machine must operate as an FTP server, install the vsftpd package via the standard channels. 
# yum install vsftpd
 CM-7 After RHEL 2.1, Red Hat switched from distributing wu-ftpd with RHEL to distributing vsftpd. For security and for consistency with future Red Hat releases, the use of vsftpd is recommended. Use vsftpd to Provide FTP Service if Necessary The primary vsftpd configuration file is /etc/vsftpd.conf, if that file exists, or /etc/vsftpd/vsftpd.conf if it does not. Enable Logging of All FTP Transactions Add or correct the following configuration options within the vsftpd configuration file, located at /etc/vsftpd/vsftpd.conf: 
xferlog_enable=YES
xferlog_std_format=NO
log_ftp_protocol=YES
 If verbose logging to vsftpd.log is done, sparse logging of downloads to /var/log/xferlog will not also occur. However, the information about what files were downloaded is included in the information logged to vsftpd.log To trace malicious activity facilitated by the FTP service, it must be configured to ensure that all commands sent to the FTP server are logged using the verbose vsftpd log format. The default vsftpd log file is /var/log/vsftpd.log. Find if logging is applied to the FTP daemon.

Procedures:

If vsftpd is started by xinetd the following command will indicate the xinetd.d startup file: 
# grep vsftpd /etc/xinetd.d/*
# grep server_args vsftpd xinetd.d startup file
This will indicate the vsftpd config file used when starting through xinetd. If the server_args line is missing or does not include the vsftpd configuration file, then the default config file (/etc/vsftpd/vsftpd.conf) is used. 
# grep xferlog_enable vsftpd config file
 Create Warning Banners for All FTP Users Edit the vsftpd configuration file, which resides at /etc/vsftpd/vsftpd.conf by default. Add or correct the following configuration options: 
banner_file=/etc/issue
 48 This setting will cause the system greeting banner to be used for FTP connections as well. If FTP services are not installed, this is not applicable.

To verify this configuration, run the following command: 
grep "banner_file" /etc/vsftpd/vsftpd.conf
The output should show the value of banner_file is set to /etc/issue, an example of which is shown below: 
# grep "banner_file" /etc/vsftpd/vsftpd.conf
banner_file=/etc/issue
 Restrict the Set of Users Allowed to Access FTP 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. Restrict Access to Anonymous Users if Possible Is there a mission-critical reason for users to transfer files to/from their own accounts using FTP, rather than using a secure protocol like SCP/SFTP? If not, edit the vsftpd configuration file. Add or correct the following configuration option: 
local_enable=NO
If non-anonymous FTP logins are necessary, follow the guidance in the remainder of this section to secure these logins as much as possible. The use of non-anonymous FTP logins is strongly discouraged. Since SSH clients and servers are widely available, and since SSH provides support for a transfer mode which resembles FTP in user interface, there is no good reason to allow password-based FTP access. Limit Users Allowed FTP Access if Necessary 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
Edit the file /etc/vsftp.ftpusers. For each user USERNAME who should be allowed to access the system via FTP, add a line containing that user's name: 
USERNAME
If anonymous access is also required, add the anonymous usernames to /etc/vsftp.ftpusers as well. 
anonymous
ftp
 Historically, the file /etc/ftpusers contained a list of users who were not allowed to access the system via FTP. It was used to prevent system users such as the root user from logging in via the insecure FTP protocol. However, when the configuration option userlist deny=NO is set, vsftpd interprets ftpusers as the set of users who are allowed to login via FTP. Since it should be possible for most users to access their accounts via secure protocols, it is recommended that this setting be used, so that non-anonymous FTP access can be limited to legacy users who have been explicitly identified. Disable FTP Uploads if Possible Is there a mission-critical reason for users to upload files via FTP? If not, edit the vsftpd configuration file to add or correct the following configuration options: 
write_enable=NO
If FTP uploads are necessary, follow the guidance in the remainder of this section to secure these transactions as much as possible. Anonymous FTP can be a convenient way to make files available for universal download. However, it is less common to have a need to allow unauthenticated users to place files on the FTP server. If this must be done, it is necessary to ensure that files cannot be uploaded and downloaded from the same directory. Place the FTP Home Directory on its Own Partition By default, the anonymous FTP root is the home directory of the FTP user account. The df command can be used to verify that this directory is on its own partition. If there is a mission-critical reason for anonymous users to upload files, precautions must be taken to prevent these users from filling a disk used by other services. Configure Firewalls to Protect the FTP Server 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"
 These settings configure iptables to allow connections to an FTP server. The first line allows initial connections to the FTP server port. FTP is an older protocol which is not very compatible with firewalls. During the initial FTP dialogue, the client and server negotiate an arbitrary port to be used for data transfer. The ip_conntrack_ftp module is used by iptables to listen to that dialogue and allow connections to the data ports which FTP negotiates. This allows an FTP server to operate on a machine which is running a firewall. SNMP Server 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 Possible 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. Disable snmpd Service The snmpd service can be disabled with the following command: # systemctl disable snmpd.service Running SNMP software provides a network-based avenue of attack, and should be disabled if not needed. To check that the snmpd service is disabled in system boot configuration, run the following command: # chkconfig snmpd --list Output should indicate the snmpd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig snmpd --list snmpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify snmpd is disabled through current runtime configuration: # service snmpd status If the service is disabled the command will return the following output: snmpd is stopped Uninstall net-snmp Package The net-snmp package provides the snmpd service. The net-snmpd package can be removed with the following command: # yum erase net-snmpd If there is no need to run SNMP server software, removing the package provides a safeguard against its activation. Run the following command to determine if the net-snmpd package is installed: # rpm -q net-snmpd Configure SNMP Server if Necessary 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
 Configure SNMP Service to Use Only SNMPv3 or Newer Edit /etc/snmp/snmpd.conf, removing any references to rocommunity, rwcommunity, or com2sec. Upon doing that, restart the SNMP service: 
# service snmpd restart
 Earlier versions of SNMP are considered insecure, as they potentially allow unauthorized access to detailed system management information. To ensure only SNMPv3 or newer is used, run the following command: 
# grep 'rocommunity\|rwcommunity\|com2sec' /etc/snmp/snmpd.conf | grep -v "^#"
There should be no output. Ensure Default Password Is Not Used Edit /etc/snmp/snmpd.conf, remove default community string public. Upon doing that, restart the SNMP service: 
# service snmpd restart
 Presence of the default SNMP password enables querying of different system aspects and could result in unauthorized knowledge of the system. To ensure the default password is not set, run the following command: 
# grep -v "^#" /etc/snmp/snmpd.conf| grep public
There should be no output. NFS and RPC 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 Possible 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. The steps in this section will prevent a machine from operating as either an NFS client or an NFS server. Only perform these steps on machines which do not need NFS at all. Disable Services Used Only by NFS 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 Network File System Lock Service (nfslock) The Network File System Lock (nfslock) service starts the required remote procedure call (RPC) processes which allow clients to lock files on the server. If the local machine is not configured to mount NFS filesystems then this service should be disabled. The nfslock service can be disabled with the following command: # systemctl disable nfslock.service Disable Secure RPC Client Service (rpcgssd) The rpcgssd service manages RPCSEC GSS contexts required to secure protocols that use RPC (most often Kerberos and NFS). The rpcgssd service is the client-side of RPCSEC GSS. If the system does not require secure RPC then this service should be disabled. The rpcgssd service can be disabled with the following command: # systemctl disable rpcgssd.service Disable RPC ID Mapping Service (rpcidmapd) The rpcidmapd service is used to map user names and groups to UID and GID numbers on NFSv4 mounts. If NFS is not in use on the local system then this service should be disabled. The rpcidmapd service can be disabled with the following command: # systemctl disable rpcidmapd.service Disable netfs if Possible 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. Disable Network File Systems (netfs) The netfs script manages the boot-time mounting of several types of networked filesystems, of which NFS and Samba are the most common. If these filesystem types are not in use, the script can be disabled, protecting the system somewhat against accidental or malicious changes to /etc/fstab and against flaws in the netfs script itself. The netfs service can be disabled with the following command: # systemctl disable netfs.service Configure All Machines which Use NFS 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 Both 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) 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 lockd to use static TCP port Configure the lockd daemon to use a static TCP port as opposed to letting the RPC Bind service dynamically assign a port. Edit the file /etc/sysconfig/nfs. Add or correct the following line: 
LOCKD_TCPPORT=lockd-port
Where lockd-port is a port which is not used by any other service on your network. Restrict service to always use a given port, so that firewalling can be done effectively. Configure lockd to use static UDP port Configure the lockd daemon to use a static UDP port as opposed to letting the RPC Bind service dynamically assign a port. Edit the file /etc/sysconfig/nfs. Add or correct the following line: 
LOCKD_UDPPORT=lockd-port
Where lockd-port is a port which is not used by any other service on your network. Restricting services to always use a given port enables firewalling to be done more effectively. Configure statd to use static port Configure the statd daemon to use a static port as opposed to letting the RPC Bind service dynamically assign a port. Edit the file /etc/sysconfig/nfs. Add or correct the following line: 
STATD_PORT=statd-port
Where statd-port is a port which is not used by any other service on your network. Restricting services to always use a given port enables firewalling to be done more effectively. Configure mountd to use static port Configure the mountd daemon to use a static port as opposed to letting the RPC Bind service dynamically assign a port. Edit the file /etc/sysconfig/nfs. Add or correct the following line: 
MOUNTD_PORT=statd-port
Where mountd-port is a port which is not used by any other service on your network. Restricting services to always use a given port enables firewalling to be done more effectively. Configure NFS Clients The steps in this section are appropriate for machines which operate as NFS clients. Disable NFS Server Daemons 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. Specify UID and GID for Anonymous NFS Connections To specify the UID and GID for remote root users, edit the /etc/exports file and add the following for each export: 
anonuid=-1
anongid=-1
Specifying the anonymous UID and GID as -1 ensures that the remote root user is mapped to a local account which has no permissions on the system. Disable Network File System (nfs) The Network File System (NFS) service allows remote hosts to mount and interact with shared filesystems on the local machine. If the local machine is not designated as a NFS server then this service should be disabled. The nfs service can be disabled with the following command: # systemctl disable nfs.service Unnecessary services should be disabled to decrease the attack surface of the system. It is prudent to ensure the nfs service is disabled in system boot, as well as not currently running. First, run the following to verify the service is stopped: 
$ service nfs status
If the service is stopped or disabled, it will return the following: 
rpc.svcgssd is stopped
rpc.mountd is stopped
nfsd is stopped
rpc.rquotad is stopped
To verify that the nfs service is disabled, run the following command: 
$ chkconfig --list nfs
If properly configured, the output should look like: 
nfs            	0:off	1:off	2:off	3:off	4:off	5:off	6:off
 Disable Secure RPC Server Service (rpcsvcgssd) The rpcsvcgssd service manages RPCSEC GSS contexts required to secure protocols that use RPC (most often Kerberos and NFS). The rpcsvcgssd service is the server-side of RPCSEC GSS. If the system does not require secure RPC then this service should be disabled. The rpcsvcgssd service can be disabled with the following command: # systemctl disable rpcsvcgssd.service Unnecessary services should be disabled to decrease the attack surface of the system. To check that the rpcsvcgssd service is disabled in system boot configuration, run the following command: # chkconfig rpcsvcgssd --list Output should indicate the rpcsvcgssd service has either not been installed, or has been disabled at all runlevels, as shown in the example below: # chkconfig rpcsvcgssd --list rpcsvcgssd 0:off 1:off 2:off 3:off 4:off 5:off 6:off Run the following command to verify rpcsvcgssd is disabled through current runtime configuration: # service rpcsvcgssd status If the service is disabled the command will return the following output: rpcsvcgssd is stopped Mount Remote Filesystems with Restrictive Options 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. Mount Remote Filesystems with nodev Add the nodev option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts. Legitimate device files should only exist in the /dev directory. NFS mounts should not present device files to users. To verify the nodev option is configured for all NFS mounts, run the following command: 
$ mount  | grep nfs
All NFS mounts should show the nodev setting in parentheses. This is not applicable if NFS is not implemented. Mount Remote Filesystems with nosuid Add the nosuid option to the fourth column of /etc/fstab for the line which controls mounting of any NFS mounts. NFS mounts should not present suid binaries to users. Only vendor-supplied suid executables should be installed to their default location on the local filesystem. To verify the nosuid option is configured for all NFS mounts, run the following command: 
$ mount  | grep nfs
All NFS mounts should show the nosuid setting in parentheses. This is not applicable if NFS is not implemented. Configure NFS Servers The steps in this section are appropriate for machines which operate as NFS servers. Configure the Exports File Restrictively 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. Use Access Lists to Enforce Authorization Restrictions 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 Possible 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. Use Root-Squashing on All Exports If a filesystem is exported using root squashing, requests from root on the client are considered to be unprivileged (mapped to a user such as nobody). This provides some mild protection against remote abuse of an NFS server. Root squashing is enabled by default, and should not be disabled.

Ensure that no line in /etc/exports contains the option no_root_squash. If the NFS server allows root access to local file systems from remote hosts, this access could be used to compromise the system. Restrict NFS Clients to Privileged Ports By default, the server NFS implementation requires that all client requests be made from ports less than 1024. If your organization has control over machines connected to its network, and if NFS requests are prohibited at the border firewall, this offers some protection against malicious requests from unprivileged users. Therefore, the default should not be changed.

To ensure that the default has not been changed, ensure no line in /etc/exports contains the option insecure. Allowing client requests to be made from ports higher than 1024 could allow a unprivileged user to initiate an NFS connection. If the unprivileged user account has been compromised, an attacker could gain access to data on the NFS server. Ensure Insecure File Locking is Not Allowed By default the NFS server requires secure file-lock requests, which require credentials from the client in order to lock a file. Most NFS clients send credentials with file lock requests, however, there are a few clients that do not send credentials when requesting a file-lock, allowing the client to only be able to lock world-readable files. To get around this, the insecure_locks option can be used so these clients can access the desired export. This poses a security risk by potentially allowing the client access to data for which it does not have authorization. Remove any instances of the insecure_locks option from the file /etc/exports. 764 Allowing insecure file locking could allow for sensitive data to be viewed or edited by an unauthorized user. To verify insecure file locking has been disabled, run the following command: 
# grep insecure_locks /etc/exports
 python 2.6.6 5.10 2011-09-21T13:44:00 Fedora release 19 (Schrödinger's Cat) Fedora 19 The operating system installed on the system is Fedora release 19 (Schrödinger's Cat) Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 6 The operating system installed on the system is Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 7 The operating system installed on the system is Red Hat Enterprise Linux 7 fedora-release redhat-release-workstation redhat-release-server redhat-release-workstation redhat-release-server unix ^19$ ^6.*$ ^6.*$ unix ^7.*$ ^7.*$ Fedora release 19 (Schrödinger's Cat) oval:ssg:def:100 python 2.6.6 5.10 2011-09-21T13:44:00 Ensure gpgcheck Enabled For All Yum Package Repositories Fedora 19 Ensure all yum repositories utilize signature checking. File grub.cfg Owned By root Group Red Hat Enterprise Linux 7 Fedora 20 The grub.cfg file should be owned by the root group. By default, this file is located at /boot/grub2/grub.cfg or, for EFI systems, at /boot/efi/EFI/redhat/grub.cfg Verify No netrc Files Exist Fedora 19 The .netrc files contain login information used to auto-login into FTP servers and reside in the user's home directory. Any .netrc files should be removed. Package net-snmp Removed Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 The RPM package net-snmp should be removed. Package ntp Installed Fedora 19 Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 The RPM package ntp should be installed. Set Password Expiration Parameters Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 The minimum password age policy should be set appropriately. Verify that System Executables Have Restrictive Permissions Fedora 19 Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Checks that binary files under /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, and /usr/local/sbin, are not group-writable or world-writable. File grub.cfg Owned By root User Red Hat Enterprise Linux 7 Fedora 20 The grub.cfg file should be owned by the root user. By default, this file is located at /boot/grub2/grub.cfg or, for EFI systems, at /boot/efi/EFI/redhat/grub.cfg Set Password Expiration Parameters Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 The password expiration warning age should be set appropriately. Restrict Virtual Console Root Logins Fedora 19 Preventing direct root login to virtual console devices helps ensure accountability for actions taken on the system using the root account. Specify a Remote NTP Server for Time Data Fedora 19 A remote NTP Server for time synchronization should be specified Ensure Yum gpgcheck Globally Activated Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 The gpgcheck option should be used to ensure that checking of an RPM package's signature always occurs prior to its installation. Fedora release 19 (Schrödinger's Cat) Fedora 19 The operating system installed on the system is Fedora release 19 (Schrödinger's Cat) Package vsftpd Installed Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 The RPM package vsftpd should be installed. File grub.cfg Permissions Red Hat Enterprise Linux 7 Fedora 20 File permissions for grub.cfg should be set to 0600 (or stronger). By default, this file is located at /boot/grub2/grub.cfg or, for EFI systems, at /boot/efi/EFI/redhat/grub.cfg Set Password Expiration Parameters Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 The password minimum length should be set appropriately. Set Password Expiration Parameters Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 The maximum password age policy should meet minimum requirements. Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 6 The operating system installed on the system is Red Hat Enterprise Linux 6 Restrict Serial Port Root Logins Fedora 19 Preventing direct root login to serial port interfaces helps ensure accountability for actions taken on the system using the root account. Verify that System Executables Have Root Ownership Fedora 19 Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Checks that /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, and objects therein, are owned by root. Package Antivirus Installed Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 Antivirus software should be installed. Set ClientAliveCountMax for User Logins Fedora 19 The SSH ClientAliveCountMax should be set to an appropriate value (and dependencies are met) Service ntpd Enabled Fedora 19 The ntpd service should be enabled. SNMP default communities disabled Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 SNMP default communities must be removed. Package openssh-server Removed Fedora 19 Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 The RPM package openssh-server should be removed. All Password Hashes Shadowed Fedora 19 All password hashes should be shadowed. SNMP use newer protocols Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 SNMP version 1 and 2c must not be enabled. Set OpenSSH Idle Timeout Interval Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 The SSH idle timeout interval should be set to an appropriate value. UID 0 Belongs Only To Root Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 Only the root account should be assigned a user id of 0. Banner for FTP Users Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 To trace malicious activity facilitated by the FTP service, it must be configured to ensure that all commands sent to the FTP server are logged using the verbose vsftpd log format. Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 7 The operating system installed on the system is Red Hat Enterprise Linux 7 Service sshd Disabled Fedora 19 The sshd service should be disabled. Disable root Login via SSH Fedora 19 Root login via SSH should be disabled (and dependencies are met) Verify that Shared Library Files Have Restrictive Permissions Fedora 19 Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Checks that /lib, /lib64, /usr/lib, /usr/lib64, /lib/modules, and objects therein, are not group-writable or world-writable. Set Boot Loader Password Red Hat Enterprise Linux 7 Fedora 20 The grub2 boot loader should have password protection enabled. Ensure insecure_locks is disabled Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 Allowing insecure file locking could allow for sensitive data to be viewed or edited by an unauthorized user. Disable Prelinking Red Hat Enterprise Linux 6 Fedora 20 The prelinking feature can interfere with the operation of checksum integrity tools (e.g. AIDE), mitigates the protection provided by ASLR, and requires additional CPU cycles by software upgrades. No nullok Option in /etc/pam.d/system-auth Fedora 19 The file /etc/pam.d/system-auth should not contain the nullok option Banner for FTP Users Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Fedora 20 This setting will cause the system greeting banner to be used for FTP connections as well. Disable Empty Passwords Fedora 19 Remote connections from accounts with empty passwords should be disabled (and dependencies are met) Verify that Shared Library Files Have Root Ownership Fedora 19 Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 7 Checks that /lib, /lib64, /usr/lib, /usr/lib64, /lib/modules, and objects therein, are owned by root. System Accounts Do Not Run a Shell Fedora 19 The root account is the only system account that should have a login shell. /etc/yum.repos.d .* ^\s*gpgcheck\s*=\s*0\s*$ 1 /boot/grub2/grub.cfg /boot/efi/EFI/redhat/grub.cfg /home ^\.netrc$ net-snmp ntp /etc/login.defs ^[\s]*PASS_MIN_DAYS[\s]+(\d+)[\s]*(?:|(?:#.*))?$ 1 ^\/(|s)bin|^\/usr\/(|local\/)(|s)bin ^.*$ oval:ssg:ste:272 oval:ssg:ste:273 /boot/grub2/grub.cfg /boot/efi/EFI/redhat/grub.cfg /etc/login.defs ^[\s]*PASS_WARN_AGE[\s]+(\d+)[\s]*(?:|(?:#.*))?$ 1 /etc/securetty ^vc/[0-9]+$ 1 /etc/ntp.conf ^[\s]*server[\s]+.+$ 1 /etc/yum.conf ^\s*gpgcheck\s*=\s*1\s*$ 1 fedora-release vsftpd /boot/grub2/grub.cfg /boot/efi/EFI/redhat/grub.cfg /etc/login.defs ^[\s]*PASS_MIN_LEN[\s]+(\d+)[\s]*(?:|(?:#.*))?$ 1 /etc/login.defs ^[\s]*PASS_MAX_DAYS[\s]+(\d+)[\s]*(?:|(?:#.*))?$ 1 redhat-release-workstation redhat-release-server /etc/securetty ^ttyS[0-9]+$ 1 ^\/(|s)bin|^\/usr\/(|local\/)(|s)bin oval:ssg:ste:274 ^\/(|s)bin|^\/usr\/(|local\/)(|s)bin ^.*$ oval:ssg:ste:274 McAfeeVSEForLinux /etc/ssh/sshd_config ^[\s]*(?i)ClientAliveCountMax[\s]+([\d]+)[\s]*$ 1 /etc/systemd/system/multi-user.target.wants/ntpd.service oval:ssg:ste:275 /etc/snmp/snmpd.conf ^[\s]*(com2se|rocommunity|rwcommunity|createUser).*(public|private) 1 openssh-server .* /etc/snmp/snmpd.conf ^[\s]*(com2se|rocommunity|rwcommunity) 1 /etc/ssh/sshd_config ^[\s]*(?i)ClientAliveInterval[\s]+(\d+)[\s]*(?:|(?:#.*))?$ 1 /etc/passwd ^(?!root:)[^:]*:[^:]*:0 1 /etc/vsftpd/vsftpd.conf ^[\s]*xferlog_enable[\s]*=[\s]*YES$ 1 /etc/vsftpd/vsftpd.conf ^[\s]*xferlog_std_format[\s]*=[\s]*NO$ 1 /etc/vsftpd/vsftpd.conf ^[\s]*log_ftp_protocol[\s]*=[\s]*YES$ 1 redhat-release-workstation redhat-release-server /etc/systemd/system/multi-user.target.wants/sshd.service oval:ssg:ste:275 /etc/ssh/sshd_config ^(?i)(?:(?!\n\s*PermitRootLogin\s+yes).)*(\n\s*PermitRootLogin\s+no)(.*)$ 1 ^\/lib(|64)|^\/usr\/lib(|64) oval:ssg:ste:276 oval:ssg:ste:277 ^\/lib(|64)|^\/usr\/lib(|64) ^.*$ oval:ssg:ste:276 oval:ssg:ste:277 /etc/grub2.cfg ^[\s]*set[\s]+superusers=\"(?i)(?!root|admin|administrator)(?-i).*\"$ 1 /etc/grub2.cfg ^[\s]*password_pbkdf2[\s]+.*[\s]+grub\.pbkdf2\.sha512.*$ 1 /etc/exports ^(.*?(\binsecure_locks\b)[^$]*)$ 1 /etc/sysconfig/prelink ^[\s]*PRELINKING=no[\s]* 1 /etc/pam.d/system-auth \s*nullok\s* 1 /etc/vsftpd/vsftpd.conf ^[\s]*banner_file[\s]*=[\s]*/etc/issue*$ 1 /etc/ssh/sshd_config ^(?i)\s*PermitEmptyPasswords\s+(yes|no)\s*$ 1 /etc/ssh/sshd_config ^(?i)(?:(?!\n\s*PermitEmptyPasswords\s+yes).)*(\n\s*PermitEmptyPasswords\s+no)(.*)$ 1 ^\/lib(|64)\/|^\/usr\/lib(|64)\/ oval:ssg:ste:278 ^\/lib(|64)\/|^\/usr\/lib(|64)\/ ^.*$ oval:ssg:ste:278 /etc/passwd ^(?!root).*:x:[\d]*:0*([0-9]{1,2}|[1-4][0-9]{2}):[^:]*:[^:]*:(?!\/sbin\/nologin|\/bin\/sync|\/sbin\/shutdown|\/sbin\/halt).*$ 1 0 true true symbolic link 0 unix ^19$ false false false false false false false ^6.*$ ^6.*$ 0 0 symbolic link x 0 unix ^7.*$ ^7.*$ true true symbolic link 0