Items in this section are advised for all systems, but may be difficult or require extensive preparation after the initial setup of the system.

Directories that are used for system-wide functions can be further protected by placing them on separate partitions. This provides protection for resource exhaustion and enables the use of mounting options that are applicable to the directory's intended use. Users' data can be stored on separate partitions and have stricter mount options. A user partition is a filesystem that has been established for use by the users and does not contain software for system operations.

The recommendations in this section are easier to perform during initial system installation. If the system is already installed, it is recommended that a full backup be performed before repartitioning the system.

Note: If you are repartitioning a system that has already been installed (This may require the system to be in single-user mode):

• Mount the new partition to a temporary mountpoint e.g. mount /dev/sda2 /mnt
• Copy data from the original partition to the new partition. e.g. cp /var/tmp/* /mnt
• Verify that all data is present on the new partition. e.g. ls -la /mnt
• Unmount the new partition. e.g. umount /mnt
• Remove the data from the original directory that was in the old partition. e.g. rm -Rf /var/tmp/* Otherwise it will still consume space in the old partition that will be masked when the new filesystem is mounted.
• Mount the new partition to the desired mountpoint. e.g. mount /dev/sda2 /var/tmp
• Update /etc/fstab with the new mountpoint. e.g. /dev/sda2 /var/tmp xfs defaults,rw,nosuid,nodev,noexec,relatime 0 0

A number of uncommon filesystem types are supported under Linux. Removing support for unneeded filesystem types reduces the local attack surface of the system. If a filesystem type is not needed it should be disabled. Native Linux file systems are designed to ensure that built-in security controls function as expected. Non-native filesystems can lead to unexpected consequences to both the security and functionality of the system and should be used with caution. Many filesystems are created for niche use cases and are not maintained and supported as the operating systems are updated and patched. Users of non-native filesystems should ensure that there is attention and ongoing support for them, especially in light of frequent operating system changes.

Standard network connectivity and Internet access to cloud storage may make the use of non-standard filesystem formats to directly attach heterogeneous devices much less attractive.

Note : This should not be considered a comprehensive list of filesystems. You may wish to consider additions to those listed here for your environment. For the current available file system modules on the system see /usr/lib/modules/$(uname -r)/kernel/fs

Start up scripts

Kernel modules loaded directly via insmod will ignore what is configured in the relevant /etc/modprobe.d/*.conf files. If modules are still being loaded after a reboot whilst having the correctly configured blacklist and install command, check for insmod entries in start up scripts such as .bashrc .

You may also want to check /lib/modprobe.d/ . Please note that this directory should not be used for user defined module loading. Ensure that all such entries resides in /etc/modprobe.d/*.conf files.

Return values

By using /bin/false as the command in disabling a particular module serves two purposes; to convey the meaning of the entry to the user and cause a non-zero return value. The latter can be tested for in scripts. Please note that insmod will ignore what is configured in the relevant /etc/modprobe.d/*.conf files. The preferred way to load modules is with modprobe .

The /tmp directory is a world-writable directory used for temporary storage by all users and some applications.

The /var directory is used by daemons and other system services to temporarily store dynamic data. Some directories created by these processes may be world-writable.

The /var/tmp directory is a world-writable directory used for temporary storage by all users and some applications. Temporary files residing in /var/tmp are to be preserved between reboots.

The /var/log directory is used by system services to store log data.

The auditing daemon, auditd , stores log data in the /var/log/audit directory.

Please note that home directories could be mounted anywhere and are not necessarily restricted to /home nor restricted to a single location, nor is the name restricted in any way.

Checks can be made by looking in /etc/passwd , looking over the mounted file systems with mount or querying the relevant database with getent .

AIDE is a file integrity checking tool, similar in nature to Tripwire. While it cannot prevent intrusions, it can detect unauthorized changes to configuration files by alerting when the files are changed. When setting up AIDE, decide internally what the site policy will be concerning integrity checking. Review the AIDE quick start guide and AIDE documentation before proceeding.

Outdated software is vulnerable to cyber criminals and hackers. Software updates help reduce the risk to your organization. The release of software update notes often reveal the patched exploitable entry points to the public. Public knowledge of these exploits cans your organization more vulnerable to malicious actors attempting to gain entry to your system's data.

Software updates often offer new and improved features and speed enhancements

The recommendations in this section focus on securing the bootloader and settings involved in the boot process directly.

Mandatory Access Control (MAC) provides an additional layer of access restrictions to processes on top of the base Discretionary Access Controls. By restricting how processes can access files and resources on a system the potential impact from vulnerabilities in the processes can be reduced.

Impact: Mandatory Access Control limits the capabilities of applications and daemons on a system, while this can prevent unauthorized access the configuration of MAC can be complex and difficult to implement correctly preventing legitimate access from occurring.

Note:

• Apparmor is the default MAC provided with Debian-based systems.
• Additional Mandatory Access Control systems to include SELinux exist. If a different Mandatory Access Control systems is used, please follow it's vendors guidance for proper implementation in place of the guidance provided in this section

AppArmor provides a Mandatory Access Control (MAC) system that greatly augments the default Discretionary Access Control (DAC) model. Under AppArmor MAC rules are applied by file paths instead of by security contexts as in other MAC systems. As such it does not require support in the filesystem and can be applied to network mounted filesystems for example. AppArmor security policies define what system resources applications can access and what privileges they can do so with. This automatically limits the damage that the software can do to files accessible by the calling user. The user does not need to take any action to gain this benefit. For an action to occur, both the traditional DAC permissions must be satisfied as well as the AppArmor MAC rules. The action will not be allowed if either one of these models does not permit the action. In this way, AppArmor rules can only make a system's permissions more restrictive and secure.

References:

1. AppArmor Documentation: http://wiki.apparmor.net/index.php/Documentation
2. Ubuntu AppArmor Documentation: https://help.ubuntu.com/community/AppArmor
3. SUSE AppArmor Documentation: https://www.suse.com/documentation/apparmor/

Presenting a warning message prior to the normal user login may assist in the prosecution of trespassers on the computer system. Changing some of these login banners also has the side effect of hiding OS version information and other detailed system information from attackers attempting to target specific exploits at a system. The /etc/motd , /etc/issue , and /etc/issue.net files govern warning banners for standard command line logins for both local and remote users.

Guidelines published by the US Department of Defense require that warning messages include at least the name of the organization that owns the system, the fact that the system is subject to monitoring and that such monitoring is in compliance with local statutes, and that use of the system implies consent to such monitoring. It is important that the organization's legal counsel review the content of all messages before any system modifications are made, as these warning messages are inherently site-specific. More information (including citations of relevant case law) can be found at http://www.justice.gov/criminal/cybercrime/

Note: The text provided in the remediation actions for these items is intended as an example only. Please edit to include the specific text for your organization as approved by your legal department

The GNOME Display Manager (GDM) is a program that manages graphical display servers and handles graphical user logins.

Note: If GDM is not installed on the system, this section can be skipped

While applying system updates and patches helps correct known vulnerabilities, one of the best ways to protect the system against as yet unreported vulnerabilities is to disable all services that are not required for normal system operation. This prevents the exploitation of vulnerabilities discovered at a later date. If a service is not enabled, it cannot be exploited. The actions in this section of the document provide guidance on some services which can be safely disabled and under which circumstances, greatly reducing the number of possible threats to the resulting system. Additionally some services which should remain enabled but with secure configuration are covered as well as insecure service clients.

Note: This should not be considered a comprehensive list of insecure services. You may wish to consider additions to those listed here for your environment.

It is recommended that physical systems and virtual guests lacking direct access to the physical host's clock be configured to synchronize their time using a service such as systemd-timesyncd, chrony, or ntp.

Note:

• If access to a physical host's clock is available and configured according to site policy, this section can be skipped
• Only one time synchronization method should be in use on the system
• Only the section related to the time synchronization method in use on the system should be followed, all other time synchronization recommendations should be skipped
• If access to a physical host's clock is available and configured according to site policy:
  • systemd-timesyncd should be stopped and masked
  • chrony should be removed from the system
  • ntp should be removed from the system

It is recommended that physical systems and virtual guests lacking direct access to the physical host's clock be configured to synchronize their time using a service such as systemd-timesyncd, chrony, or ntp.

chrony is a daemon which implements the Network Time Protocol (NTP) and is designed to synchronize system clocks across a variety of systems and use a source that is highly accurate.

chrony can be configured to be a client and/or a server.

More information on chrony can be found at: http://chrony.tuxfamily.org/ .

Note:

• If ntp or systemd-timesyncd are used, chrony should be removed and this section skipped
• Only one time synchronization method should be in use on the system

systemd-timesyncd is a daemon that has been added for synchronizing the system clock across the network. It implements an SNTP client. In contrast to NTP implementations such as chrony or the NTP reference server this only implements a client side, and does not bother with the full NTP complexity, focusing only on querying time from one remote server and synchronizing the local clock to it. The daemon runs with minimal privileges, and has been hooked up with networkd to only operate when network connectivity is available. The daemon saves the current clock to disk every time a new NTP sync has been acquired, and uses this to possibly correct the system clock early at bootup, in order to accommodate for systems that lack an RTC such as the Raspberry Pi and embedded devices, and make sure that time monotonically progresses on these systems, even if it is not always correct. To make use of this daemon a new system user and group "systemd-timesync" needs to be created on installation of systemd.

The default configuration is set during compilation, so configuration is only needed when it is necessary to deviate from those defaults. Initially, the main configuration file in /etc/systemd/ contains commented out entries showing the defaults as a guide to the administrator. Local overrides can be created by editing this file or by creating drop-ins, as described below. Using drop-ins for local configuration is recommended over modifications to the main configuration file.

In addition to the "main" configuration file, drop-in configuration snippets are read from /usr/lib/systemd/*.conf.d/ , /usr/local/lib/systemd/*.conf.d/ , and /etc/systemd/*.conf.d/ . Those drop-ins have higher precedence and override the main configuration file. Files in the *.conf.d/ configuration subdirectories are sorted by their filename in lexicographic order, regardless of in which of the subdirectories they reside. When multiple files specify the same option, for options which accept just a single value, the entry in the file sorted last takes precedence, and for options which accept a list of values, entries are collected as they occur in the sorted files.

When packages need to customize the configuration, they can install drop-ins under /usr/. Files in /etc/ are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. Drop-ins have to be used to override package drop-ins, since the main configuration file has lower precedence. It is recommended to prefix all filenames in those subdirectories with a two-digit number and a dash, to simplify the ordering of the files.

To disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in the configuration directory in /etc/, with the same filename as the vendor configuration file.

Note:

• The recommendations in this section only apply if timesyncd is in use on the system
• The systemd-timesyncd service specifically implements only SNTP.
  • This minimalistic service will set the system clock for large offsets or slowly adjust it for smaller deltas
  • More complex use cases are not covered by systemd-timesyncd
• If chrony or ntp are used, systemd-timesyncd should be stopped and masked, and this section skipped
• One, and only one, time synchronization method should be in use on the system

ntp is a daemon which implements the Network Time Protocol (NTP). It is designed to synchronize system clocks across a variety of systems and use a source that is highly accurate. More information on NTP can be found at http://www.ntp.org . ntp can be configured to be a client and/or a server.

Note:

• If chrony or systemd-timesyncd are used, ntp should be removed and this section skipped
• This recommendation only applies if ntp is in use on the system
• Only one time synchronization method should be in use on the system

This section describes services that are installed on systems that specifically need to run these services. If any of these services are not required, it is recommended that they be deleted from the system to reduce the potential attack surface. If a package is required as a dependency, and the service is not required, the service should be stopped and masked.

The following command can be used to stop and mask the service:

A number of insecure services exist. While disabling the servers prevents a local attack against these services, it is advised to remove their clients unless they are required.

Note: This should not be considered a comprehensive list of insecure service clients. You may wish to consider additions to those listed here for your environment.

This section provides guidance on for securing the network configuration of the system through kernel parameters, access list control, and firewall settings.

Note:

• sysctl settings are defined through files in /usr/lib/sysctl.d/ , /run/sysctl.d/ , and /etc/sysctl.d/ .
• Files must have the " .conf " extension.
• Vendors settings live in /usr/lib/sysctl.d/
• To override a whole file, create a new file with the same name in /etc/sysctl.d/ and put new settings there.
• To override only specific settings, add a file with a lexically later name in /etc/sysctl.d/ and put new settings there.
• The paths where sysctl preload files usually exist
  • /run/sysctl.d/*.conf
  • /etc/sysctl.d/*.conf
  • /usr/local/lib/sysctl.d/*.conf
  • /usr/lib/sysctl.d/*.conf
  • /lib/sysctl.d/*.conf
  • /etc/sysctl.conf
• On systems with Uncomplicated Firewall, additional settings may be configured in /etc/ufw/sysctl.conf
  • The settings in /etc/ufw/sysctl.conf will override settings in /etc/sysctl.conf
  • This behavior can be changed by updating the IPT_SYSCTL parameter in /etc/default/ufw

To reduce the attack surface of a system, unused network protocols and devices should be disabled.

The Linux kernel modules support several network protocols that are not commonly used. If these protocols are not needed, it is recommended that they be disabled in the kernel.

Note: This should not be considered a comprehensive list of uncommon network protocols, you may wish to consider additions to those listed here for your environment.

The following network parameters are intended for use if the system is to act as a host only. A system is considered host only if the system has a single interface, or has multiple interfaces but will not be configured as a router.

Note:

Configuration files are read from directories in /etc/ , /run/ , /usr/local/lib/ , and /lib/ , in order of precedence. Files must have the the ".conf" extension. extension. Files in /etc/ override files with the same name in /run/ , /usr/local/lib/ , and /lib/ . Files in /run/ override files with the same name under /usr/ .

All configuration files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same option, the entry in the file with the lexicographically latest name will take precedence. Thus, the configuration in a certain file may either be replaced completely (by placing a file with the same name in a directory with higher priority), or individual settings might be changed (by specifying additional settings in a file with a different name that is ordered later).

Packages should install their configuration files in /usr/lib/ (distribution packages) or /usr/local/lib/ (local installs). Files in /etc/ are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. It is recommended to prefix all filenames with a two-digit number and a dash, to simplify the ordering of the files.

If the administrator wants to disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in the configuration directory in /etc/ , with the same filename as the vendor configuration file. If the vendor configuration file is included in the initrd image, the image has to be regenerated.

The following network parameters are intended for use on both host only and router systems. A system acts as a router if it has at least two interfaces and is configured to perform routing functions.

Note:

Configuration files are read from directories in /etc/ , /run/ , /usr/local/lib/ , and /lib/ , in order of precedence. Files must have the the ".conf" extension. extension. Files in /etc/ override files with the same name in /run/ , /usr/local/lib/ , and /lib/ . Files in /run/ override files with the same name under /usr/ .

All configuration files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same option, the entry in the file with the lexicographically latest name will take precedence. Thus, the configuration in a certain file may either be replaced completely (by placing a file with the same name in a directory with higher priority), or individual settings might be changed (by specifying additional settings in a file with a different name that is ordered later).

Packages should install their configuration files in /usr/lib/ (distribution packages) or /usr/local/lib/ (local installs). Files in /etc/ are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. It is recommended to prefix all filenames with a two-digit number and a dash, to simplify the ordering of the files.

If the administrator wants to disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in the configuration directory in /etc/ , with the same filename as the vendor configuration file. If the vendor configuration file is included in the initrd image, the image has to be regenerated.

A firewall is a set of rules. When a data packet moves into or out of a protected network space, its contents (in particular, information about its origin, target, and the protocol it plans to use) are tested against the firewall rules to see if it should be allowed through

To provide a Host Based Firewall, the Linux kernel includes support for:

• Netfilter - A set of hooks inside the Linux kernel that allows kernel modules to register callback functions with the network stack. A registered callback function is then called back for every packet that traverses the respective hook within the network stack. Includes the ip_tables, ip6_tables, arp_tables, and ebtables kernel modules. These modules are some of the significant parts of the Netfilter hook system.
• nftables - A subsystem of the Linux kernel providing filtering and classification of network packets/datagrams/frames. nftables is supposed to replace certain parts of Netfilter, while keeping and reusing most of it. nftables utilizes the building blocks of the Netfilter infrastructure, such as the existing hooks into the networking stack, connection tracking system, userspace queueing component, and logging subsystem. Is available in Linux kernels 3.13 and newer .

In order to configure firewall rules for Netfilter or nftables, a firewall utility needs to be installed. Guidance has been included for the following firewall utilities:

• UncomplicatedFirewall (ufw) - Provides firewall features by acting as a front-end for the Linux kernel's netfilter framework via the iptables backend. ufw supports both IPv4 and IPv6 networks
• nftables - Includes the nft utility for configuration of the nftables subsystem of the Linux kernel
• iptables - Includes the iptables, ip6tables, arptables and ebtables utilities for configuration Netfilter and the ip_tables, ip6_tables, arp_tables, and ebtables kernel modules.

Note:

• Only one method should be used to configure a firewall on the system. Use of more than one method could produce unexpected results
• This section is intended only to ensure the resulting firewall rules are in place, not how they are configured

If nftables or iptables are being used in your environment, please follow the guidance in their respective section and pass-over the guidance in this section.

Uncomplicated Firewall (UFW) is a program for managing a netfilter firewall designed to be easy to use.

• Uses a command-line interface consisting of a small number of simple commands
• Uses iptables for configuration
• Rules are processed until first matching rule. The first matching rule will be applied.

Note:

• Configuration of a live system's firewall directly over a remote connection will often result in being locked out
• Rules should be ordered so that ALLOW rules come before DENY rules.

If Uncomplicated Firewall (UFW) or iptables are being used in your environment, please follow the guidance in their respective section and pass-over the guidance in this section.

nftables is a subsystem of the Linux kernel providing filtering and classification of network packets/datagrams/frames and is the successor to iptables. The biggest change with the successor nftables is its simplicity. With iptables, we have to configure every single rule and use the syntax which can be compared with normal commands. With nftables, the simpler syntax, much like BPF (Berkely Packet Filter) means shorter lines and less repetition. Support for nftables should also be compiled into the kernel, together with the related nftables modules. Please ensure that your kernel supports nf_tables before choosing this option.

Note:

• This section broadly assumes starting with an empty nftables firewall ruleset (established by flushing the rules with nft flush ruleset).
• Remediation steps included only affect the live system, you will also need to configure your default firewall configuration to apply on boot.
• Configuration of a live systems firewall directly over a remote connection will often result in being locked out. It is advised to have a known good firewall configuration set to run on boot and to configure an entire firewall structure in a script that is then run and tested before saving to boot.

The following will implement the firewall rules of this section and open ICMP, IGMP, and port 22(ssh) from anywhere. Opening the ports for ICMP, IGMP, and port 22(ssh) needs to be updated in accordance with local site policy. Allow port 22(ssh) needs to be updated to only allow systems requiring ssh connectivity to connect, as per site policy .

Save the script bellow as /etc/nftables.rules

Run the following command to load the file into nftables

All changes in the nftables subsections are temporary.

To make these changes permanent:

Run the following command to create the nftables.rules file

Add the following line to /etc/nftables.conf

If Uncomplicated Firewall (UFW) or nftables are being used in your environment, please follow the guidance in their respective section and pass-over the guidance in this section.

IPtables is an application that allows a system administrator to configure the IPv4 and IPv6 tables, chains and rules provided by the Linux kernel firewall. While several methods of configuration exist this section is intended only to ensure the resulting IPtables rules are in place, not how they are configured. If IPv6 is in use in your environment, similar settings should be applied to the IP6tables as well.

Note: Configuration of a live system's firewall directly over a remote connection will often result in being locked out

This section provides guidance for installing, enabling, removing, and disabling software packages necessary for using IPTables as the method for configuring and maintaining a Host Based Firewall on the system.

Note: Using more than one method to configure and maintain a Host Based Firewall can cause unexpected results. If FirewallD or NFTables are being used for configuration and maintenance, this section should be skipped and the guidance in their respective section followed.

Iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. Several different tables may be defined. Each table contains a number of built-in chains and may also contain user-defined chains.

Each chain is a list of rules which can match a set of packets. Each rule specifies what to do with a packet that matches. This is called a 'target', which may be a jump to a user-defined chain in the same table.

Note: This section broadly assumes starting with an empty IPtables firewall ruleset (established by flushing the rules with iptables -F). Remediation steps included only affect the live system, you will also need to configure your default firewall configuration to apply on boot. Configuration of a live systems firewall directly over a remote connection will often result in being locked out. It is advised to have a known good firewall configuration set to run on boot and to configure an entire firewall structure in a script that is then run and tested before saving to boot. The following script will implement the firewall rules of this section and open port 22(ssh) from anywhere:

Ip6tables is used to set up, maintain, and inspect the tables of IPv6 packet filter rules in the Linux kernel. Several different tables may be defined. Each table contains a number of built-in chains and may also contain user-defined chains. Each chain is a list of rules which can match a set of packets. Each rule specifies what to do with a packet that matches. This is called a `target', which may be a jump to a user-defined chain in the same table.

If IPv6 in enabled on the system, the ip6tables should be configured.

Note: This section broadly assumes starting with an empty ip6tables firewall ruleset (established by flushing the rules with ip6tables -F). Remediation steps included only affect the live system, you will also need to configure your default firewall configuration to apply on boot. Configuration of a live systems firewall directly over a remote connection will often result in being locked out. It is advised to have a known good firewall configuration set to run on boot and to configure an entire firewall structure in a script that is then run and tested before saving to boot.

The following script will implement the firewall rules of this section and open port 22(ssh) from anywhere:

cron is a time-based job scheduler used to schedule jobs, commands or shell scripts, to run periodically at fixed times, dates, or intervals.

at provides the ability to execute a command or shell script at a specified date and hour, or after a given interval of time.

Notes:

• Other methods exist for scheduling jobs, such as systemd timers . If another method is used, it should be secured in accordance with local site policy
• systemd timers are systemd unit files whose name ends in .timer that control .service files or events
  • Timers can be used as an alternative to cron and at
  • Timers have built-in support for calendar time events, monotonic time events, and can be run asynchronously
• If cron and at are not installed, this section can be skipped

SSH is a secure, encrypted replacement for common login services such as telnet , ftp , rlogin , rsh , and rcp . It is strongly recommended that sites abandon older clear-text login protocols and use SSH to prevent session hijacking and sniffing of sensitive data off the network.

Note:

• The recommendations in this section only apply if the SSH daemon is installed on the system, if remote access is not required the SSH daemon can be removed and this section skipped.
• The following openSSH daemon configuration options, Include and Match , may cause the audits in this section's recommendations to report incorrectly. It is recommended that these options only be used if they're needed and fully understood. If these options are configured in accordance with local site policy, they should be accounted for when following the recommendations in this section.
• The default Include location is the /etc/ssh/sshd_config.d directory. This default has been accounted for in this section. If a file has an additional Include that isn't this default location, the files should be reviewed to verify that the recommended setting is not being over-ridden.
• The audits of the running configuration in this section are run in the context of the root user, the local host name, and the local host's IP address. If a Match block exists that matches one of these criteria, the output of the audit will be from the match block. The respective matched criteria should be replaced with a non-matching substitution.
• Once all configuration changes have been made to /etc/ssh/sshd_config or any included configuration files, the sshd configuration must be reloaded
• Include :
  • Include the specified configuration file(s).
  • Multiple pathnames may be specified and each pathname may contain glob(7) wildcards.
  • Files without absolute paths are assumed to be in /etc/ssh.
  • An Include directive may appear inside a Match block to perform conditional inclusion.
• Match :
  • Introduces a conditional block.
  • If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file.
  • If a keyword appears in multiple Match blocks that are satisfied, only the first instance of the keyword is applied.
  • The arguments to Match are one or more criteria-pattern pairs or the single token All which matches all criteria. The available criteria are User, Group, Host, LocalAddress, LocalPort, RDomain, and Address (with RDomain representing the rdomain(4) on which the connection was received).
  • The match patterns may consist of single entries or comma-separated lists and may use the wildcard and negation operators described in the PATTERNS section of ssh_config(5).
  • The patterns in an Address criteria may additionally contain addresses to match in CIDR address/masklen format, such as 192.0.2.0/24 or 2001:db8::/32. Note that the mask length provided must be consistent with the address - it is an error to specify a mask length that is too long for the address or one with bits set in this host portion of the address. For example, 192.0.2.0/33 and 192.0.2.0/8, respectively.
  • Only a subset of keywords may be used on the lines following a Match keyword.
  • Available keywords are: AcceptEnv , AllowAgentForwarding , AllowGroups , AllowStreamLocalForwarding , AllowTcpForwarding , AllowUsers , AuthenticationMethods , AuthorizedKeysCommand , AuthorizedKeysCommandUser , AuthorizedKeysFile , AuthorizedPrincipalsCommand , AuthorizedPrincipalsCommandUser , AuthorizedPrincipalsFile , Banner , ChrootDirectory , ClientAliveCountMax , ClientAliveInterval , DenyGroups , DenyUsers , ForceCommand , GatewayPorts , GSSAPIAuthentication , HostbasedAcceptedKeyTypes , HostbasedAuthentication , HostbasedUsesNameFromPacketOnly , Include , IPQoS , KbdInteractiveAuthentication , KerberosAuthentication , LogLevel , MaxAuthTries , MaxSessions , PasswordAuthentication , PermitEmptyPasswords , PermitListen , PermitOpen , PermitRootLogin , PermitTTY , PermitTunnel , PermitUserRC , PubkeyAcceptedKeyTypes , PubkeyAuthentication , RekeyLimit , RevokedKeys , RDomain , SetEnv , StreamLocalBindMask , StreamLocalBindUnlink , TrustedUserCAKeys , X11DisplayOffset , X11Forwarding and X11UseLocalhost .

Command to re-load the SSH daemon configuration:

Command to remove the SSH daemon:

There are various tools which allows a permitted user to execute a command as the superuser or another user, as specified by the security policy.

sudo

sudo documentation

The invoking user's real (not effective) user ID is used to determine the user name with which to query the security policy.

sudo supports a plug-in architecture for security policies and input/output logging. Third parties can develop and distribute their own policy and I/O logging plug-ins to work seamlessly with the sudo front end. The default security policy is sudoers , which is configured via the file /etc/sudoers and any entries in /etc/sudoers.d .

pkexec

pkexec documentation

pkexec allows an authorized user to execute PROGRAM as another user. If username is not specified, then the program will be executed as the administrative super user, root .

PAM (Pluggable Authentication Modules) is a service that implements modular authentication modules on UNIX systems. PAM is implemented as a set of shared objects that are loaded and executed when a program needs to authenticate a user. Files for PAM are typically located in the /etc/pam.d directory. PAM must be carefully configured to secure system authentication. While this section covers some of PAM, please consult other PAM resources to fully understand the configuration capabilities.

Note: The usage of pam-auth-update :

• As of this writing, the management of PAM via pam-auth-update does not offer all the required functionality implemented by the benchmark. As such, the usage of pam-auth-update is not recommended at present.

This section provides guidance on setting up secure defaults for system and user accounts and their environment.

While a majority of the password control parameters have been moved to PAM, some parameters are still available through the shadow password suite. Any changes made to /etc/login.defs will only be applied if the usermod command is used. If user IDs are added a different way, use the chage command to effect changes to individual user IDs.

The items in this section describe how to configure logging, log monitoring, and auditing, using tools included in most distributions.

It is recommended that rsyslog be used for logging (with logwatch providing summarization) and auditd be used for auditing (with aureport providing summarization) to automatically monitor logs for intrusion attempts and other suspicious system behavior.

In addition to the local log files created by the steps in this section, it is also recommended that sites collect copies of their system logs on a secure, centralized log server via an encrypted connection. Not only does centralized logging help sites correlate events that may be occurring on multiple systems, but having a second copy of the system log information may be critical after a system compromise where the attacker has modified the local log files on the affected system(s). If a log correlation system is deployed, configure it to process the logs described in this section.

Because it is often necessary to correlate log information from many different systems (particularly after a security incident) it is recommended that the time be synchronized among systems and devices connected to the local network.

It is important that all logs described in this section be monitored on a regular basis and correlated to determine trends. A seemingly innocuous entry in one log could be more significant when compared to an entry in another log.

Note on log file permissions: There really isn't a "one size fits all" solution to the permissions on log files. Many sites utilize group permissions so that administrators who are in a defined security group, such as "wheel" do not have to elevate privileges to root in order to read log files. Also, if a third party log aggregation tool is used, it may need to have group permissions to read the log files, which is preferable to having it run setuid to root. Therefore, there are two remediation and audit steps for log file permissions. One is for systems that do not have a secured group method implemented that only permits root to read the log files ( root:root 600 ). The other is for sites that do have such a setup and are designated as root:securegrp 640 where securegrp is the defined security group (in some cases wheel ).

Logging services should be configured to prevent information leaks and to aggregate logs on a remote server so that they can be reviewed in the event of a system compromise. A centralized log server provides a single point of entry for further analysis, monitoring and filtering.

Security principals for logging

• Ensure transport layer security is implemented between the client and the log server.
• Ensure that logs are rotated as per the environment requirements.
• Ensure all locally generated logs have the appropriate permissions.
• Ensure all security logs are sent to a remote log server.
• Ensure the required events are logged.

What is covered

This section will cover the minimum best practices for the usage of eitherrsyslogorjournald . The recommendations are written such that each is wholly independent of each other and only one is implemented .

• If your organization makes use of an enterprise wide logging system completely outside of rsyslog or journald , then the following recommendations does not directly apply. However, the principals of the recommendations should be followed regardless of what solution is implemented. If the enterprise solution incorporates either of these tools, careful consideration should be given to the following recommendations to determine exactly what applies.
• Should your organization make use of both rsyslog and journald , take care how the recommendations may or may not apply to you.

What is not covered

• Enterprise logging systems not utilizing rsyslog or journald . As logging is very situational and dependant on the local environment, not everything can be covered here.
• Transport layer security should be applied to all remote logging functionality. Both rsyslog and journald supports secure transport and should be configured as such.
• The log server. There are a multitude of reasons for a centralized log server (and keeping a short period logging on the local system), but the log server is out of scope for these recommendations.

Included in the systemd suite is a journaling service called systemd-journald.service for the collection and storage of logging data. It creates and maintains structured, indexed journals based on logging information that is received from a variety of sources such as:

• Classic RFC3164 BSD syslog via the /dev/log socket
• STDOUT/STDERR of programs via StandardOutput=journal + StandardError=journal in service files (both of which are default settings)
• Kernel log messages via the /dev/kmsg device node
• Audit records via the kernel’s audit subsystem
• Structured log messages via journald’s native protocol

Any changes made to the systemd-journald configuration will require a re-start of systemd-journald

The rsyslog software package may be used instead of the default journald logging mechanism.

Note: This section only applies if rsyslog is the chosen method for client side logging. Do not apply this section if journald is used.

The Linux Auditing System operates on a set of rules that collects certain types of system activity to facilitate incident investigation, detect unauthorized access or modification of data. By default events will be logged to /var/log/audit/audit.log , which can be configured in /etc/audit/auditd.conf .

The following types of audit rules can be specified:

• Control rules: Configuration of the auditing system.
• File system rules: Allow the auditing of access to a particular file or a directory. Also known as file watches.
• System call rules: Allow logging of system calls that any specified program makes.

Audit rules can be set:

• On the command line using the auditctl utility. These rules are not persistent across reboots.
• In /etc/audit/audit.rules . These rules have to be merged and loaded before they are active.

Notes:

• For 64 bit systems that have arch as a rule parameter, you will need two rules: one for 64 bit and one for 32 bit systems calls. For 32 bit systems, only one rule is needed.
• If the auditing system is configured to be locked ( -e 2 ), a system reboot will be required in order to load any changes.
• Key names are optional on the rules and will not be used as a compliance auditing. The usage of key names is highly recommended as it facilitates organisation and searching, as such, all remediation steps will have key names supplied.
• It is best practice to store the rules, in number prepended files, in /etc/audit/rules.d/ . Rules must end in a .rules suffix. This then requires the use of augenrules to merge all the rules into /etc/audit/audit.rules based on their their alphabetical (lexical) sort order. All benchmark recommendations follow this best practice for remediation, specifically using the prefix of 50 which is centre weighed if all rule sets make use of the number prepending naming convention.
• Your system may have been customized to change the default UID_MIN . All samples output uses 1000 , but this value will not be used in compliance auditing. To confirm the UID_MIN for your system, run the following command: awk '/^\s*UID_MIN/{print $2}' /etc/login.defs

Normalization

The Audit system normalizes some entries, so when you look at the sample output keep in mind that:

• With regards to users whose login UID is not set, the values -1 / unset / 4294967295 are equivalent and normalized to -1 .
• When comparing field types and both sides of the comparison is valid fields types, such as euid!=uid , then the auditing system may normalize such that the output is uid!=euid .
• Some parts of the rule may be rearranged whilst others are dependant on previous syntax. For example, the following two statements are the same:

and

Capacity planning

The recommendations in this section implement auditing policies that not only produces large quantities of logged data, but may also negatively impact system performance. Capacity planning is critical in order not to adversely impact production environments.

• Disk space. If a significantly large set of events are captured, additional on system or off system storage may need to be allocated. If the logs are not sent to a remote log server, ensure that log rotation is implemented else the disk will fill up and the system will halt. Even when logs are sent to a log server, ensure sufficient disk space to allow caching of logs in the case of temporary network outages.
• Disk IO. It is not just the amount of data collected that should be considered, but the rate at which logs are generated.
• CPU overhead. System call rules might incur considerable CPU overhead. Test the systems open/close syscalls per second with and without the rules to gauge the impact of the rules.

The capturing of system events provides system administrators with information to allow them to determine if unauthorized access to their system is occurring.

When auditing, it is important to carefully configure the storage requirements for audit logs. By default, auditd will max out the log files at 5MB and retain only 4 copies of them. Older versions will be deleted. It is possible on a system that the 20 MBs of audit logs may fill up the system causing loss of audit data. While the recommendations here provide guidance, check your site policy for audit storage requirements.

The Audit system operates on a set of rules that define what is to be captured in the log files.

The following types of Audit rules can be specified:

• Control rules: Allow the Audit system's behavior and some of its configuration to be modified.
• File system rules: Allow the auditing of access to a particular file or a directory. (Also known as file watches)
• System call rules: Allow logging of system calls that any specified program makes.

Audit rules can be set:

• on the command line using the auditctl utility. Note that these rules are not persistent across reboots.
• in a file ending in .rules in the /etc/audit/audit.d/ directory.

Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events.

Recommendations in this section are intended as maintenance and are intended to be checked on a frequent basis to ensure system stability. Many recommendations do not have quick remediations and require investigation into the cause and best fix available and may indicate an attempted breach of system security.

This section provides guidance on securing aspects of system files and directories.

This section provides guidance on securing aspects of the local users and groups.

Note: The recommendations in this section check local users and groups. Any users or groups from other sources such as LDAP will not be audited. In a domain environment similar checks should be performed against domain users and groups.