Guide to the Secure Configuration of Fedora
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).
Profile ID | (default) |
---|
Revision History
Current version: 0.0.4
- draft (as of 2015-09-05)
Platforms
- cpe:/o:fedoraproject:fedora:23
- cpe:/o:fedoraproject:fedora:22
- cpe:/o:fedoraproject:fedora:21
Table of Contents
- Introduction
- System Settings
- Installing and Maintaining Software
- File Permissions and Masks
- Account and Access Control
- Network Configuration and Firewalls
- System Accounting with auditd
- Services
Checklist
IntroductiongroupThe 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 PrinciplesgroupThe 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 PossiblegroupData 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 VulnerabilitygroupThe 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 SystemsgroupWhenever 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 RobustnessgroupSeveral tools exist which can be effectively used to improve a system's resistance to and detection of unknown attacks. These tools can improve robustness against attack at the cost of relatively little configuration effort. In particular, this guide recommends and discusses the use of Iptables for host-based firewalling, SELinux for protection against vulnerable services, and a logging and auditing infrastructure for detection of problems. |
Least Privilegegroup
Grant the least privilege necessary for user accounts and software to perform tasks.
For example, |
How to Use This GuidegroupReaders should heed the following points when using the guide. |
Read Sections Completely and in OrdergroupEach 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 EnvironmentgroupThis guidance should always be tested in a non-production environment before deployment. This test environment should simulate the setup in which the system will be deployed as closely as possible. |
Root Shell Environment Assumedgroup
Most of the actions listed in this document are written with the
assumption that they will be executed by the root user running the
|
Formatting Conventionsgroup
Commands intended for shell execution, as well as configuration file text,
are featured in a |
Reboot RequiredgroupA system reboot is implicitly required after some actions in order to complete the reconfiguration of the system. In many cases, the changes will not take effect until a reboot is performed. In order to ensure that changes are applied properly and to test functionality, always reboot the system after applying a set of recommendations from this guide. |
System Settingsgroup |
Installing and Maintaining SoftwaregroupThe following sections contain information on security-relevant choices during the initial operating system installation process and the setup of software updates. |
Updating SoftwaregroupThe |
Software Integrity Checkinggroup
Both the AIDE (Advanced Intrusion Detection Environment)
software and the RPM package management system provide
mechanisms for verifying the integrity of installed software.
AIDE uses snapshots of file metadata (such as hashes) and compares these
to current system files in order to detect changes.
The RPM package management system can conduct integrity
checks by comparing information in its metadata database with
files installed on the system.
|
Verify Integrity with AIDEgroupAIDE conducts integrity checks by comparing information about
files with previously-gathered information. Ideally, the AIDE database is
created immediately after initial system configuration, and then again after any
software update. AIDE is highly configurable, with further configuration
information located in |
Verify Integrity with RPMgroupThe RPM package management system includes the ability to verify the integrity of installed packages by comparing the installed files with information about the files taken from the package metadata stored in the RPM database. Although an attacker could corrupt the RPM database (analogous to attacking the AIDE database as described above), this check can still reveal modification of important files. To list which files on the system differ from what is expected by the RPM database: # rpm -qVaSee the man page for rpm to see a complete explanation of each column.
|
Additional Security SoftwaregroupAdditional security software that is not provided or supported by Red Hat can be installed to provide complementary or duplicative security capabilities to those provided by the base platform. Add-on software may not be appropriate for some specialized systems. |
File Permissions and MasksgroupTraditional Unix security relies heavily on file and directory permissions to prevent unauthorized users from reading or modifying files to which they should not have access. |
Restrict Dynamic Mounting and Unmounting of FilesystemsgroupLinux includes a number of facilities for the automated addition
and removal of filesystems on a running system. These facilities may be
necessary in many environments, but this capability also carries some risk -- whether direct
risk from allowing users to introduce arbitrary filesystems,
or risk that software flaws in the automated mount facility itself could
allow an attacker to compromise the system.
$ find /lib/modules/`uname -r`/kernel/fs -type f -name '*.ko'If these filesystems are not required then they can be explicitly disabled in a configuratio file in /etc/modprobe.d .
|
Verify File Permissions Within Some Important DirectoriesgroupSome directories contain files whose confidentiality or integrity is notably important and may also be susceptible to misconfiguration over time, particularly if unpackaged software is installed. As such, an argument exists to verify that files' permissions within these directories remain configured correctly and restrictively. |
Restrict Programs from Dangerous Execution PatternsgroupThe recommendations in this section are designed to ensure that the system's features to protect against potentially dangerous program execution are activated. These protections are applied at the system initialization or kernel level, and defend against certain types of badly-configured or compromised programs. |
Daemon UmaskgroupThe umask is a per-process setting which limits the default permissions for creation of new files and directories. The system includes initialization scripts which set the default umask for system daemons. |
Disable Core DumpsgroupA core dump file is the memory image of an executable
program when it was terminated by the operating system due to
errant behavior. In most cases, only software developers
legitimately need to access these files. The core dump files may
also contain sensitive information, or unnecessarily occupy large
amounts of disk space.
|
Enable ExecShieldgroupExecShield describes kernel features that provide
protection against exploitation of memory corruption errors such as buffer
overflows. These features include random placement of the stack and other
memory regions, prevention of execution in memory that should only hold data,
and special handling of text buffers. These protections are enabled by default
on 32-bit systems and controlled through |
Enable Execute Disable (XD) or No Execute (NX) Support on x86 SystemsgroupRecent processors in the x86 family support the ability to prevent code execution on a per memory page basis. Generically and on AMD processors, this ability is called No Execute (NX), while on Intel processors it is called Execute Disable (XD). This ability can help prevent exploitation of buffer overflow vulnerabilities and should be activated whenever possible. Extra steps must be taken to ensure that this protection is enabled, particularly on 32-bit x86 systems. Other processors, such as Itanium and POWER, have included such support since inception and the standard kernel for those platforms supports the feature. This is enabled by default on the latest Red Hat and Fedora systems if supported by the hardware. |
Account and Access ControlgroupIn traditional Unix security, if an attacker gains shell access to a certain login account, they can perform any action or access any file to which that account has access. Therefore, making it more difficult for unauthorized people to gain shell access to accounts, particularly to privileged accounts, is a necessary part of securing a system. This section introduces mechanisms for restricting access to accounts under Fedora. |
Protect Accounts by Restricting Password-Based LogingroupConventionally, Unix shell accounts are accessed by
providing a username and password to a login program, which tests
these values for correctness using the |
Restrict Root Loginsgroup
Direct root logins should be allowed only for emergency use.
In normal situations, the administrator should access the system
via a unique unprivileged account, and then use |
Proper Storage and Existence of Password Hashesgroup
By default, password hashes for local accounts are stored
in the second field (colon-separated) in
|
Set Password Expiration ParametersgroupThe file # chage -M 180 -m 7 -W 7 USER |
Secure Session Configuration Files for Login AccountsgroupWhen a user logs into a Unix account, the system configures the user's session by reading a number of files. Many of these files are located in the user's home directory, and may have weak permissions as a result of user error or misconfiguration. If an attacker can modify or even read certain types of account configuration information, they can often gain full access to the affected user's account. Therefore, it is important to test and correct configuration file permissions for interactive accounts, particularly those of privileged users such as root or system administrators. |
Ensure that No Dangerous Directories Exist in Root's PathgroupThe active path of the root account can be obtained by starting a new root shell and running: $ sudo echo $PATHThis will produce a colon-separated list of directories in the path. Certain path elements could be considered dangerous, as they could lead to root executing unknown or untrusted programs, which could contain malicious code. Since root may sometimes work inside untrusted directories, the . character, which represents the
current directory, should never be in the root path, nor should any
directory which can be written to by an unprivileged or
semi-privileged (system) user.
It is a good practice for administrators to always execute privileged commands by typing the full path to the command. |
Ensure that Users Have Sensible Umask Valuesgroup
The umask setting controls the default permissions
for the creation of new files.
With a default |
Protect Accounts by Configuring PAMgroupPAM, or Pluggable Authentication Modules, is a system
which implements modular authentication for Linux programs. PAM provides
a flexible and configurable architecture for authentication, and it should be configured
to minimize exposure to unnecessary risk. This section contains
guidance on how to accomplish that.
warning
Be careful when making changes to PAM's
configuration files. The syntax for these files is complex, and
modifications can have unexpected consequences. The default
configurations shipped with applications should be sufficient for
most users. warning
Running authconfig or
system-config-authentication will re-write the PAM configuration
files, destroying any manually made changes and replacing them with
a series of system defaults. One reference to the configuration
file syntax can be found at
http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-configuration-file.html. |
Set Password Quality RequirementsgroupThe default |
Set Password Quality Requirements with pam_pwqualitygroupThe password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=If no such line exists, add one as the first line of the password section in /etc/pam.d/system-auth .
Next, modify the settings in /etc/security/pwquality.conf to match the following:
difok = 4 minlen = 14 dcredit = -1 ucredit = -1 lcredit = -1 ocredit = -1 maxrepeat = 3The arguments can be modified to ensure compliance with your organization's security policy. Discussion of each parameter follows. warning
Note that the password quality
requirements are not enforced for the root account for some
reason. |
Set Lockouts for Failed Password AttemptsgroupThe warning
Locking out user accounts presents the
risk of a denial-of-service attack. The lockout policy
must weigh whether the risk of such a
denial-of-service attack outweighs the benefits of thwarting
password guessing attacks. |
Set Password Hashing AlgorithmgroupThe system's default algorithm for storing password hashes in
|
Protect Physical Console AccessgroupIt is impossible to fully protect a system from an attacker with physical access, so securing the space in which the system is located should be considered a necessary step. However, there are some steps which, if taken, make it more difficult for an attacker to quickly or undetectably modify a system from its console. |
Set Boot Loader PasswordgroupDuring the boot process, the boot loader is responsible for starting the execution of the kernel and passing options to it. The boot loader allows for the selection of different kernels - possibly on different partitions or media. The default Fedora boot loader for x86 systems is called GRUB2. Options it can pass to the kernel include single-user mode, which provides root access without any authentication, and the ability to disable SELinux. To prevent local users from modifying the boot parameters and endangering security, protect the boot loader configuration with a password and ensure its configuration file's permissions are set properly. |
Configure Screen LockinggroupWhen a user must temporarily leave an account
logged-in, screen locking should be employed to prevent passersby
from abusing the account. User education and training is
particularly important for screen locking to be effective, and policies
can be implemented to reinforce this.
|
Configure GUI Screen LockinggroupIn the default GNOME3 desktop, the screen can be locked
by selecting the user name in the far right corner of the main panel and
selecting Lock.
|
Configure Console Screen Lockinggroup
A console screen locking mechanism is provided in the
|
Hardware Tokens for AuthenticationgroupThe 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. |
Warning Banners for System AccessesgroupEach system should expose as little information about
itself as possible.
|
Implement a GUI Warning BannergroupIn the default graphical environment, users logging directly into the system are greeted with a login screen provided by the GNOME3 Display Manager (GDM). The warning banner should be displayed in this graphical environment for these users. The following sections describe how to configure the GDM login banner. |
Network Configuration and FirewallsgroupMost machines must be connected to a network of some
sort, and this brings with it the substantial risk of network
attack. This section discusses the security impact of decisions
about networking which must be made when configuring a system.
|
Disable Unused InterfacesgroupNetwork interfaces expand the attack surface of the
system. Unused interfaces are not monitored or controlled, and
should be disabled.
$ sudo rm /etc/sysconfig/network-scripts/ifcfg-interfaceIf the system is a standalone machine with no need for network access or even communication over the loopback device, then disable this service. The network service can be disabled with the following command:
$ sudo systemctl disable network.service |
IPv6groupThe system includes support for Internet Protocol version 6. A major and often-mentioned improvement over IPv4 is its enormous increase in the number of available addresses. Another important feature is its support for automatic configuration of many network settings. |
Disable Support for IPv6 Unless NeededgroupDespite configuration that suggests support for IPv6 has been disabled, link-local IPv6 address auto-configuration occurs even when only an IPv4 address is assigned. The only way to effectively prevent execution of the IPv6 networking stack is to instruct the system not to activate the IPv6 kernel module. |
Configure IPv6 Settings if NecessarygroupA major feature of IPv6 is the extent to which systems implementing it can automatically configure their networking devices using information from the network. From a security perspective, manually configuring important configuration information is preferable to accepting it from the network in an unauthenticated fashion. |
Disable Automatic ConfigurationgroupDisable the system's acceptance of router
advertisements and redirects by adding or correcting the following
line in IPV6_AUTOCONF=no |
Limit Network-Transmitted Configuration if Using Static IPv6 AddressesgroupTo limit the configuration information requested from other
systems and accepted from the network on a system that uses
statically-configured IPv6 addresses, add the following lines to
net.ipv6.conf.default.router_solicitations = 0 net.ipv6.conf.default.accept_ra_rtr_pref = 0 net.ipv6.conf.default.accept_ra_pinfo = 0 net.ipv6.conf.default.accept_ra_defrtr = 0 net.ipv6.conf.default.autoconf = 0 net.ipv6.conf.default.dad_transmits = 0 net.ipv6.conf.default.max_addresses = 1The router_solicitations setting determines how many router
solicitations are sent when bringing up the interface. If addresses are
statically assigned, there is no need to send any solicitations.
The accept_ra_pinfo setting controls whether the system will accept
prefix info from the router.
The accept_ra_defrtr setting controls whether the system will accept
Hop Limit settings from a router advertisement. Setting it to 0 prevents a
router from changing your default IPv6 Hop Limit for outgoing packets.
The autoconf setting controls whether router advertisements can cause
the system to assign a global unicast address to an interface.
The dad_transmits setting determines how many neighbor solicitations
to send out per address (global and link-local) when bringing up an interface
to ensure the desired address is unique on the network.
The max_addresses setting determines how many global unicast IPv6
addresses can be assigned to each interface. The default is 16, but it should
be set to exactly the number of statically configured global addresses
required.
|
System Accounting with auditdgroupThe audit service provides substantial capabilities
for recording system activities. By default, the service audits about
SELinux AVC denials and certain types of security-relevant events
such as system logins, account modifications, and authentication
events performed by programs such as sudo.
Under its default configuration, ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rulesin the /usr/lib/systemd/system/auditd.service configuration file. In order
to instruct the auditd daemon to use the augenrules program
to read audit rules, use the following setting:
ExecStartPost=-/sbin/augenrules --loadin the /usr/lib/systemd/system/auditd.service configuration file. Refer to
[Service] section of the /usr/lib/systemd/system/auditd.service
configuration for further details.
Government networks often have substantial auditing requirements and auditd can be configured to meet these
requirements.
Examining some example audit records demonstrates how the Linux audit system
satisfies common requirements.
The following example from Fedora Documentation available at
http://docs.fedoraproject.org/en-US/Fedora/21/html/SELinux_Users_and_Administrators_Guide/sect-Security-Enhanced_Linux-Fixing_Problems-Raw_Audit_Messages.html
shows the substantial amount of information captured in a
two typical "raw" audit messages, followed by a breakdown of the most important
fields. In this example the message is SELinux-related and reports an AVC
denial (and the associated system call) that occurred when the Apache HTTP
Server attempted to access the /var/www/html/file1 file (labeled with
the samba_share_t type):
type=AVC msg=audit(1226874073.147:96): avc: denied { getattr } for pid=2465 comm="httpd" path="/var/www/html/file1" dev=dm-0 ino=284133 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:samba_share_t:s0 tclass=file type=SYSCALL msg=audit(1226874073.147:96): arch=40000003 syscall=196 success=no exit=-13 a0=b98df198 a1=bfec85dc a2=54dff4 a3=2008171 items=0 ppid=2463 pid=2465 auid=502 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=6 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null)
|
Configure auditd Data Retentiongroup
The audit system writes data to |
Configure auditd Rules for Comprehensive AuditinggroupThe
Auditing rules at startup are controlled by the file /etc/audit/audit.rules .
Add rules to it to meet the auditing requirements for your organization.
Each line in /etc/audit/audit.rules represents a series of arguments
that can be passed to auditctl and can be individually tested
during runtime. See documentation in /usr/share/doc/audit-VERSION and
in the related man pages for more details.
If copying any example audit rulesets from /usr/share/doc/audit-VERSION ,
be sure to comment out the
lines containing arch= which are not appropriate for your system's
architecture. Then review and understand the following rules,
ensuring rules are activated as needed for the appropriate
architecture.
After reviewing all the rules, reading the following sections, and editing as needed, the new rules can be activated as follows: $ sudo service auditd restart |
Records Events that Modify Date and Time InformationgroupArbitrary changes to the system time can be used to obfuscate nefarious activities in log files, as well as to confuse network services that are highly dependent upon an accurate system time. All changes to the system time should be audited. |
Record Events that Modify the System's Discretionary Access ControlsgroupAt a minimum the audit system should collect file permission
changes for all users and root. Note that the "-F arch=b32" lines should be
present even on a 64 bit system. These commands identify system calls for
auditing. Even if the system is 64 bit it can still execute 32 bit system
calls. Additionally, these rules can be configured in a number of ways while
still achieving the desired effect. An example of this is that the "-S" calls
could be split up and placed on separate lines, however, this is less efficient.
Add the following to -a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b32 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_modIf your system is 64 bit then these lines should be duplicated and the arch=b32 replaced with arch=b64 as follows: -a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S chown -S fchown -S fchownat -S lchown -F auid>=1000 -F auid!=4294967295 -k perm_mod -a always,exit -F arch=b64 -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S lremovexattr -S fremovexattr -F auid>=1000 -F auid!=4294967295 -k perm_mod |
Servicesgroup
The best protection against vulnerable software is running less software. This
section describes how to review the software which 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.
|
SSH ServergroupThe SSH protocol is recommended for remote login and remote file
transfer. SSH provides confidentiality and integrity for data exchanged between
two systems, as well as server authentication, through the use of public key
cryptography. The implementation included with the system is called OpenSSH,
and more detailed documentation is available from its website,
http://www.openssh.org. Its server program is called |
Configure OpenSSH Server if NecessarygroupIf the system needs to act as an SSH server, then certain changes
should be made to the OpenSSH daemon configuration file
|
Network Time ProtocolgroupThe Network Time Protocol is used to manage the system
clock over a network. Computer clocks are not very accurate, so
time will drift unpredictably on unmanaged systems. Central time
protocols can be used both to ensure that time is consistent among
a network of machines, and that their time is consistent with the
outside world.
|
Audit DeamongroupThe Linux Audit system provides a way to track security-relevant information on your system. Based on pre-configured rules, Audit generates log entries to record as much information about the events that are happening on your system as possible. This information is crucial for mission-critical environments to determine the violator of the security policy and the actions they performed. Audit does not provide additional security to your system; rather, it can be used to discover violations of security policies used on your system. These violations can further be prevented by additional security measures such as SELinux. |
FTP ServergroupFTP is a common method for allowing remote access to
files. Like telnet, the FTP protocol is unencrypted, which means
that passwords and other data transmitted during the session can be
captured and that the session is vulnerable to hijacking.
Therefore, running the FTP server software is not recommended.
|
Disable vsftpd if Possiblegroup |
Use vsftpd to Provide FTP Service if Necessarygroup |
Use vsftpd to Provide FTP Service if NecessarygroupThe primary vsftpd configuration file is
|
Restrict the Set of Users Allowed to Access FTPgroupThis section describes how to disable non-anonymous (password-based) FTP logins, or, if it is not possible to do this entirely due to legacy applications, how to restrict insecure FTP login to only those users who have an identified need for this access. |
Limit Users Allowed FTP Access if NecessarygroupIf there is a mission-critical reason for users to access their accounts via the insecure FTP protocol, limit the set of users who are allowed this access. Edit the vsftpd configuration file. Add or correct the following configuration options: userlist_enable=YES userlist_file=/etc/vsftp.ftpusers userlist_deny=NOEdit 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:
USERNAMEIf anonymous access is also required, add the anonymous usernames to /etc/vsftp.ftpusers as well.
anonymous ftp |
Configure Firewalls to Protect the FTP ServergroupBy default, -A INPUT -m state --state NEW -p tcp --dport 21 -j ACCEPTEdit the file /etc/sysconfig/iptables-config . Ensure that the space-separated list of modules contains
the FTP connection tracking module:
IPTABLES_MODULES="ip_conntrack_ftp" |
SNMP ServergroupThe Simple Network Management Protocol allows administrators to monitor the state of network devices, including computers. Older versions of SNMP were well-known for weak security, such as plaintext transmission of the community string (used for authentication) and usage of easily-guessable choices for the community string. |
Disable SNMP Server if PossiblegroupThe system includes an SNMP daemon that allows for its remote monitoring, though it not installed by default. If it was installed and activated but is not needed, the software should be disabled and removed. |
Configure SNMP Server if NecessarygroupIf it is necessary to run the snmpd agent on the system, some best practices should be followed to minimize the security risk from the installation. The multiple security models implemented by SNMP cannot be fully covered here so only the following general configuration advice can be offered:
|
NFS and RPCgroupThe Network File System is a popular distributed filesystem for the Unix environment, and is very widely deployed. This section discusses the circumstances under which it is possible to disable NFS and its dependencies, and then details steps which should be taken to secure NFS's configuration. This section is relevant to machines operating as NFS clients, as well as to those operating as NFS servers. |
Disable All NFS Services if PossiblegroupIf there is not a reason for the system to operate as either an NFS client or an NFS server, follow all instructions in this section to disable subsystems required by NFS. warning
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 NFSgroupIf NFS is not needed, disable the NFS client daemons nfslock, rpcgssd, and rpcidmapd.
|
Disable netfs if PossiblegroupTo determine if any network filesystems handled by netfs are currently mounted on the system execute the following command: # mount -t nfs,nfs4,smbfs,cifs,ncpfsIf the command did not return any output then disable netfs. |
Configure All Machines which Use NFSgroupThe steps in this section are appropriate for all machines which run NFS, whether they operate as clients or as servers. |
Make Each Machine a Client or a Server, not BothgroupIf NFS must be used, it should be deployed in the simplest configuration possible to avoid maintainability problems which may lead to unnecessary security exposure. Due to the reliability and security problems caused by NFS (specially NFSv3 and NFSv2), it is not a good idea for machines which act as NFS servers to also mount filesystems via NFS. At the least, crossed mounts (the situation in which each of two servers mounts a filesystem from the other) should never be used. |
Configure NFS Services to Use Fixed Ports (NFSv3 and NFSv2)groupFirewalling should be done at each host and at the border
firewalls to protect the NFS daemons from remote access, since NFS servers
should never be accessible from outside the organization. However, by default
for NFSv3 and NFSv2, the RPC Bind service assigns each NFS service to a port
dynamically at service startup time. Dynamic ports cannot be protected by port
filtering firewalls such as iptables.
|
Configure NFS ClientsgroupThe steps in this section are appropriate for machines which operate as NFS clients. |
Disable NFS Server Daemonsgroup
There is no need to run the NFS server daemons |
Mount Remote Filesystems with Restrictive OptionsgroupEdit the file |
Configure NFS ServersgroupThe steps in this section are appropriate for machines which operate as NFS servers. |
Configure the Exports File RestrictivelygroupLinux's NFS implementation uses the file /DIR host1(opt1,opt2) host2(opt3)where /DIR is a directory or filesystem to export, hostN is an IP address, netblock,
hostname, domain, or netgroup to which to export, and optN is an option.
|
Use Access Lists to Enforce Authorization RestrictionsgroupWhen configuring NFS exports, ensure that each export line in
|
Export Filesystems Read-Only if PossiblegroupIf a filesystem is being exported so that users can view the files in a convenient
fashion, but there is no need for users to edit those files, exporting the filesystem read-only
removes an attack vector against the server. The default filesystem export mode is |