This benchmarks helps people in improving their system configuration to be more resilient against attacks and vulnerabilities.

Applicable platforms

  • cpe:/o:gentoo:linux

Version: 20140412

Revision history

  • draft (as of 2014-04-12)

1. Introduction

Since years, Gentoo Linux has a Gentoo Security Handbook which provides a good insight in secure system configuration for a Gentoo systems. Although this is important, an improved method for describing and tuning a systems' security state has emerged: SCAP, or the Security Content Automation Protocol.

As such, this benchmark is an update on the security handbook, including both the in-depth explanation of settings as well as the means to validate if a system complies with this or not. Now, during the development of this benchmark document, not include all information from the Gentoo Security Handbook is included as some of the settings are specific to a service that is not all that default on a Gentoo Linux system or sufficiently separate that can benefit other distributions as well. Although these settings are important as well, it is best done in separate benchmarks for those services instead.

Where applicable, this benchmark will refer to a different hardening guide for specific purposes (such as the Hardening OpenSSH benchmark).

References

  1. Gentoo Security Handbook. URL: <http://www.gentoo.org/doc/en/security/security-handbook.xml>.

1.1. This is no security policy

It is very important to realize that this document is not a policy. There is no obligation to follow this to make a secure system nor should everything in this document be agreed upon. This document is a set of common best practices with the explanation (why is it a best practice) and method (how to implement the best practice).

The purpose of this document is to guide readers in their quest to hardening their systems. It will provide pointers that could help in deciding particular configuration settings and will do this hopefully using sufficient background information to allow readers to make a good choice.

Readers might find settings they don't agree with. That's fine, but if there is disagreement about why it is documented, we would like to hear it so we can update the guide accordingly.

1.2. A little more about SCAP and OVAL

Within SCAP, NIST has defined some new standards of which XCCDF and OVAL are notably important in light of this guide.

  • XCCDF (Extensible Configuration Checklist Description Format) is a specification language for writing security checklists and benchmarks

  • OVAL (Open Vulnerability and Assessment Language) is a standard to describe and validate system settings

Thanks to the OVAL and XCCDF standards, a security engineer can now describe how the state of a system should be configured, how this can be checked automatically and even report on these settings. Furthermore, within the description, the engineer can make "profiles" of different states (such as a profile for a workstation, server (generic), webserver, LDAP server, ...) and reusing the states (rules) identified in a more global scope.

1.3. Using this guide

This guide is generated from SCAP content (more specifically, the XCCDF document) using openscap, a free software implementation for handling SCAP content. Within Gentoo, the package app-forensics/openscap provides the tools, and the following command is used to generate the HTML output:

                
# oscap xccdf generate guide gentoo-xccdf.xml > output.html
              

Secondly, together with this XCCDF XML, an OVAL XML file is made available. The two files combined allow OVAL interpreters to automatically validate various settings as documented in the benchmark.

Finally, if certain tests are not available in OVAL yet, scripts are provided that can be executed through the SCE (Script Check Engine) support in openscap. As scripts are not guaranteed to have no impact on the system (or leave traces), -oval profiles are available that only enable the OVAL (and not SCE) checks.

To validate the tests, the following commands can be used:

                
# export PROFILE="xccdf_org.gentoo.dev.swift_profile_default"
# oscap xccdf eval --profile ${PROFILE} gentoo-xccdf.xml
              

To generate a full report in HTML as well, use the next command:

                
# oscap xccdf eval --profile ${PROFILE} --results xccdf-results.xml \
  --report report.html gentoo-xccdf.xml
              

Finally, this benchmark will suggest some settings that do not reflect the will of the reader. That is perfectly fine - even more, some settings might even raise eyebrows left and right. This document will explain the reasoning behind the settings but deviations are always possible. If that is the case, disable the rules in the XCCDF document or, better yet, create a new profile and only refer to the tests that are required.

1.4. Available XCCDF Profiles

As mentioned earlier, the XCCDF document supports multiple profiles. For the time being, two profiles are defined:

  • The default profile (xccdf_org.gentoo.dev.swift_profile_default) contains tests that are quick to validate

  • The default-oval profile (xccdf_org.gentoo.dev.swift_profile_default-oval) is like the default one, but does not call any other checker than OVAL (so no scripts).

  • The intensive profile (xccdf_org.gentoo.dev.swift_profile_intensive) contains all tests, including those that take a while (for instance because they perform full file system scans)

  • The intensive-oval profile (xccdf_org.gentoo.dev.swift_profile_intensive-oval) is like the intensive one, but does not call any other checker than OVAL (so no scripts).

Substitute the profile information in the commands above with the required profile.

1.5. About the rule weights

Within this guide, weights are assigned to tests to give some importance to the rule (higher weight is more important) as well as a severity.

The severity is one of the following:

  • high constitutes a grave or critical problem. A rule with this severity MUST be tackled as it detected a misconfiguration that is easily exploitable and could lead to full system compromise.

  • medium reflects a fairly serious problem. A rule with this severity SHOULD be tackled as it detected a misconfiguration that is easily exploitable.

  • low reflects a non-serious problem. A rule with this severity has detected a misconfiguration but its influence on the overall system security is minor (if other compliance rules are followed).

  • info reflects an informational rule. Failure to comply with this rule does not mean failure to comply with the document itself.

It is important to understand though that rules with a low severity can still lead to grave security problems if they are not met. Chaining of vulnerabilities or misconfiguration can still lead to full system compromise.

For this reason, weights are added to rules as well. A higher weight has a more severe potential impact.

Weights are the CVSS (or CCSS) score that is thought to be the case for a misconfiguration. They are calculated by NVD's CVSS calculator. Each rule is scored individually; a "chain" of misconfigurations might lead to a significantly higher issue, but this would make it very hard to make proper scoring.

As an example, take the rule that says /var has to be on its own partition. The metrics we fill in in the calculator are currently based on the risk that the root file system is filled (no more free space), which can halt the system.

  • The related exploit range (access vector) is "Local", because this is by itself not exploitable remotely - unless of course certain services are running that can fill up /var, but such assumptions are not taken.

  • The attack complexity (access complexity) is "Low", as all that is needed is a local account and we can find the necessary ways to fill up /var.

  • The level of authentication needed (authentication) is "Single" as the attacker needs one authentication step (local access) to exploit.

  • The confidentiality impact is "None" (no data leakage)

  • The integrity impact is "None" (no data manipulation)

  • The availability impact is "Complete" (system crash or halt).

This results in the CVSS base score of 4.6. The environmental score metrics and temporal score metrics are ignored as those are too specific for environments and organizations.

References

  1. NVD CVSS calculator. URL: <https://nvd.nist.gov/cvss.cfm?calculator&version=2>.
  2. The Common Configuration Scoring System (PDF). URL: <http://csrc.nist.gov/publications/nistir/ir7502/nistir-7502_CCSS.pdf>.

2. Before starting

Before starting to deploy Gentoo Linux and start hardening it, it is wise to take a step back and think about what to accomplish. Setting up a more secured Gentoo Linux isn't a goal, but a means to reach something. Most likely the system will become a Gentoo Linux powered server. What is this server for? Where will it be hosted? What services are scheduled to run on this operating system? Etc.

2.1. Infrastructure architecturing

When considering the entire IT architecture, many architecturing frameworks exist to write down and further design infrastructure. There are very elaborate ones, like TOGAF (The Open Group Architecture Framework), but smaller ones exist as well.

A well written and maintained infrastructure architecture helps to position new services or consider the impact of changes on existing components.

Security is about reducing risks, not about harassing people or making work for a system administrator harder. And reducing risks also means that a clear eye needs to be kept on the architecture and all its components. If there is no knowledge as to what is being integrated, where it is going to be installed or why, then hardening by itself will probably not do much to the secure state of the system.

2.2. Mapping requirements

When designing a service, we need to take both functional and non-functional requirements into account. That does sound like overshooting for a simple server installation, but it is not. Is auditing considered? Where should the audit logs be sent to? What about authentication? Centrally managed, or manually set? And the server, will it only host a particular service, or will it provide several services?

When hosting multiple services on the same server, make sure that the server is positioned within the network on an acceptable segment. It is not safe to host central LDAP infrastructure on the same system as a web server that is facing the Internet.

References

  1. IBM DeveloperWorks article on "Capturing Architectural Requirements". URL: <https://www.ibm.com/developerworks/rational/library/4706.html>.

2.3. Non-software security concerns

From the next chapter onwards, the focus will be on the software side hardening. There are of course also non-software concerns that need to be taken care of.

References

  1. Site Security Handbook (RFC2196). URL: <https://www.rfc-editor.org/info/rfc2196>.

2.3.1. Physical security

Make sure that the system is only accessible (physically) by trusted people. Fully hardening a system, only to have a malicious person take out the harddisk and run away with the confidential data is not something fun to experience.

When physical security cannot be guaranteed (like with laptops), make sure that theft of the device only results in the loss of the hardware and not of the data and software on it (take backups!), and also that the data on it cannot be read by unauthorized people.

References

  1. Data Center Physical Security Checklist (SANS, PDF). URL: <http://www.sans.org/reading_room/whitepapers/awareness/data-center-physical-security-checklist_416>.

2.3.2. Policies and contractual agreements

Create or validate the security policies in the organization. This is not only as a stick (against internal people who might want to abuse their powers) but also to document and describe why certain decisions are made (both architecturally as otherwise).

Make sure that the reasoning for the guidelines is clear. If the policies ever need to be adjusted towards new environments or concepts (like "bring your own device") having the reasons for the (old) guidelines documented will make it much easier to write new ones.

References

  1. Technical Writing for IT Security Policies in Five Easy Steps (SANS, PDF). URL: <http://www.sans.org/reading_room/whitepapers/policyissues/technical-writing-security-policies-easy-steps_492>.
  2. Information Security Policy Templates (SANS). URL: <https://www.sans.org/security-resources/policies/>.

3. Installation configuration

Gentoo Linux allows us to update various parts of the system after installation, but it might be interesting to consider the following aspects during (or before) installation to not risk a huge migration project later.

3.1. Storage configuration

Storage is of utmost importance in any environment. It needs to be sufficiently fast (performance), but also secure and manageable while remaining flexible to handle future changes.

3.1.1. Partitioning

Know which locations in the file system structure need to be on a different partition or logical volume. Separate locations allow for a more distinct segregation (for instance, no hard links between different file systems) and low-level protection (file system corruption impact, but also putting the right data on the right storage media).

References

  1. Filesystem Hierarchy Standard. URL: <http://www.pathname.com/fhs/>.

3.1.1.1. Separate file systems for important locations

Having a separate file system for important locations has several advantages, but those advantages need to be weighted against the disadvantages of separate file systems.

These disadvantages are:

  • Separate file systems mean that better disk space control is needed (governing free space). A file system that is given too much free space means that disk space is being wasted, but a file system that is not given enough free disk space will need to be grown quickly - if possibile. This also means that creating a proper partitioning setup with many different partitions (file systems) will take some time and calculations; many users have no good idea how much space they need to make available for a file system.

  • Some file system locations need to be available early in the boot process. If those locations reside on different file systems, special precautions need to be taken to make those file systems available when the system is booted (such as creating an initial ram file system).

The advantages on the other hand:

  • A sudden disk space growth will eventually be stopped by the limits of the file system. If a non-critical file system is full, the impact on the overall system is limited. Without separate file systems, a full file system might jeopardise the availability of the entire system.

  • Specific mount options can be enabled on the file systems that improve the security of the file system (permissions) as well as performance. Such mount options include ownership details, allowing (or disallowing) setuid binaries, device files and more.

  • Different file systems can be hosted on different devices (or even on network shares), allowing administrators to pick the most efficient storage device for a particular file system.

Considering these pros and cons, it is recommended to have at least the following file system locations to be on a different file system:

  • /tmp as this is a world-writable location and requires specific mount options. When possible, this location can be made a tmpfs file system. This is to protect the root file system from being flooded.

  • /var as this contains variable data (and thus is prone to grow extensively depending on the installed services). This is to protect the root file system from being flooded.

  • /var/log as this contains logging data (and thus is prone to grow extensively depending on the services). This is to protect the /var file system from being flooded, as this might impact various services (like databases, web servers, etc.).

  • /var/log/audit as this contains (potentially sensitive) logging data. Some services refuse to continue if the audit target location is full. Having the location separate from /var/log protects the audit file system when /var/log would be flooded.

  • /home as this is completely under the control of end users. It needs to be mounted with more secure settings (more about that later) and should be separate both to protect the root file system, but also to allow the /home location to be either shared or used elsewhere.

  • /var/tmp which is a "second" /tmp location, but where the content is preserved after a reboot. Still, it is world-writable and requires specific mount options, and should be on a different file system to prevent /var to be flooded which might impact the availability of services.

3.1.1.1.a. /tmp is a separate file system

Remediation instructions

Create a file system for /tmp; make sure it is added in the /etc/fstab file and reboot the system.

3.1.1.1.b. /var is a separate file system

Remediation instructions

Create a file system for /var; make sure it is added in the /etc/fstab file and reboot the system.

3.1.1.1.c. /var/log is a separate file system

Remediation instructions

Create a file system for /var/log; make sure it is added in the /etc/fstab file and reboot the system.

3.1.1.1.d. /var/log/audit is a separate file system

Remediation instructions

Create a file system for /var/log/audit; make sure it is added in the /etc/fstab file and reboot the system.

3.1.1.1.e. /home is a separate file system

Remediation instructions

Create a file system for /home; make sure it is added in the /etc/fstab file and reboot the system.

3.1.1.1.f. /var/tmp is a separate file system

Remediation instructions

Create a file system for /var/tmp; make sure it is added in the /etc/fstab file and reboot the system.

3.2. Use a Hardened Toolchain

When Gentoo is installed, use the hardened stages and hardened toolchain. The hardened toolchain includes additional security patches, such as support for non-executable program stacks and buffer overflow detection.

  • Position Independent Executables (PIE) and Position Independent Code (PIC) implements a memory hardening approach where the application (or library), when loaded to memory, does not have hard requirements where in memory it is loaded. Together with ASLR this makes it more difficult for exploits to know at which memory region certain data will be available.

  • Stack Smashing Protection (SSP) adds markers outside buffer areas to detect buffer overflow attacks, killing the application rather than effectively having the overflow succeed.

During installation, make sure that the default hardened toolchain is selected, not one of the -hardenedno* as those are toolchains where specific settings are disabled. The -vanilla one is a toolchain with no hardened patches.

                
# gcc-config -l
 [1] x86_64-pc-linux-gnu-4.4.5 *
 [2] x86_64-pc-linux-gnu-4.4.5-hardenednopie
 [3] x86_64-pc-linux-gnu-4.4.5-hardenednopie.gcc-config-ref
 [4] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp
 [5] x86_64-pc-linux-gnu-4.4.5-hardenednossp
 [6] x86_64-pc-linux-gnu-4.4.5-vanilla
              

3.2.a. The hardened toolchain is used

Remediation instructions

Use a hardened Gentoo profile and select the default compiler (not vanilla nor any of the hardenedno* ones).

4. System settings

Within this chapter, the (recommended) settings that can be adjusted relatively easily are presented, even when a Gentoo installation has already been performed. This is the bulk of the security settings.

Table of Contents

4.1. File system related settings

Servers and systems are about manipulating data. In this chapter, the security settings for file systems are explained.

4.1.1. Using no* mount options for the file systems

Non-root file systems should be mounted with the nodev mount option. This mount option ensures that device files are not allowed on these file systems (and if they are there, they are ignored by the Linux kernel for any device operation).

Having device files on non-root file systems could allow unauthorized people access to sensitive data (for instance when having a readable raw disk device files) or even manipulate the system.

The privilege to create special device files (beyond regular sockets) such as character and block device files is handled through the CAP_MKNOD capability which is not granted to regular users. As such, the risk is when more privileged users or processes are tricked to create such device files.

This setting is appropriate for file systems such as (non-exhaustive list):

  • /var (as it is recommended to be a separate file system)

  • /var/log (as it is recommended to be a separate file system)

  • /var/log/audit (as it is recommended to be a separate file system)

  • /home (as it is recommended to be a separate file system)

  • /tmp (as it is recommended to be a separate file system)

Specific file systems should also be mounted with the nosuid mount option. This prevents setuid binaries to run as a different user when hosted on this file system. As there are several locations where setuid binaries might be needed, this only affects particular file systems:

  • The /tmp file system should not be used for setuid binaries as this is a world-writable location and often target storage for attacks.

  • The /home file system should not be used for setuid binaries as this is the home location for non-root users.

  • The /dev/shm file system should not be used for any binaries (shared memory region).

Specific file systems should also be mounted with the noexec mount option. This prevents some automated attacks to execute certain payload (exploits) from these locations.

This is just one of the many "layers" though, as executing payload can still be done using different methods. For instance, scripts can be invoked through the shell itself (rather than directly) and in the past, binaries could even be executed through the ld-linux.so binary (although this has been fixed).

File systems for which noexec is recommended are:

  • The /tmp file system as it is a popular target to store exploit code in.

  • The /dev/shm file system as it is meant as a shared memory location and is becoming a popular target to store exploit code in.

4.1.1.a. /var is mounted with nodev

Remediation instructions

Mount /var with nodev mount option

Remediation script

                    
mount -o remount,nodev /var
          
                  

4.1.1.b. /var/log is mounted with nodev

Remediation instructions

Mount /var/log with nodev mount option

Remediation script

                    
mount -o remount,nodev /var/log
          
                  

4.1.1.c. /var/log/audit is mounted with nodev

Remediation instructions

Mount /var/log/audit with nodev mount option

Remediation script

                    
mount -o remount,nodev /var/log/audit
          
                  

4.1.1.d. /home is mounted with nodev

Remediation instructions

Mount /home with nodev mount option

Remediation script

                    
mount -o remount,nodev /home
          
                  

4.1.1.e. /tmp is mounted with nodev

Remediation instructions

Mount /tmp with nodev mount option

Remediation script

                    
mount -o remount,nodev /tmp
          
                  

4.1.1.f. /tmp is mounted with nosuid

Remediation instructions

Mount /tmp with nosuid mount option

Remediation script

                    
mount -o remount,nosuid /tmp
          
                  

4.1.1.g. /home is mounted with nosuid

Remediation instructions

Mount /home with nosuid mount option

Remediation script

                    
mount -o remount,nosuid /home
          
                  

4.1.1.h. /dev/shm is mounted with nosuid

Remediation instructions

Mount /dev/shm with nosuid mount option

Remediation script

                    
mount -o remount,nosuid /dev/shm
          
                  

4.1.1.i. /tmp is mounted with noexec

Remediation instructions

Mount /tmp with noexec mount option

Remediation script

                    
mount -o remount,noexec /tmp
          
                  

4.1.1.j. /dev/shm is mounted with noexec

Remediation instructions

Mount /dev/shm with nosuid mount option

Remediation script

                    
mount -o remount,noexec /dev/shm
          
                  

4.1.2. Disk quota support

Most file systems support the notion of quotas - limits on the amount of data / files that are allowed on that particular file system.

To enable quotas, first configure the Linux kernel to include CONFIG_QUOTA.

Next, install the sys-fs/quota package.

                  
# emerge quota
                

Then add usrquota and grpquota to the partitions (in /etc/fstab) where quotas need to be enabled on. For instance, the following snippet from /etc/fstab enables quotas on /var and /home.

                  
/dev/mapper/volgrp-home /home ext4 noatime,nodev,nosuid,usrquota,grpquota 0 0
/dev/mapper/volgrp-var  /var  ext4 noatime,usrquota,grpquota              0 0
                

Finally, add the quota service to the boot runlevel.

                  
# rc-update add quota boot
                

Reboot the system so that the partitions are mounted with the correct mount options and that the quota service is running. Then the quotas for users and groups can be set up.

References

  1. Managing Disk Usage with Quotas (LinuxHomeNetworking). URL: <http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch28_:_Managing_Disk_Usage_with_Quotas>.
  2. Gentoo Linux Kernel Configuration - shorthand notation information. URL: <http://www.gentoo.org/doc/en/kernel-config.xml#shorthand>.

4.1.2.a. The kernel supports quota (CONFIG_QUOTA)

Remediation instructions

Rebuild the Linux kernel with quota support (CONFIG_QUOTA)

4.1.2.b. The /var file system is mounted with usrquota or grpquota

Remediation instructions

Mount /var with usrquota and/or grpquota

Remediation script

                    
mount -o remount,usrquota,grpquota /var
          
                  

4.1.2.c. The /home file system is mounted with usrquota or grpquota

Remediation instructions

Mount /home with usrquota and/or grpquota

Remediation script

                    
mount -o remount,usrquota,grpquota /home
          
                  

4.1.3. Hiding process information through hidepid

In order to hide process information from other users, the /proc file system needs to be mounted with the hidepid option. With value 0, the default behavior is used, meaning that all process information is world readable.

When the value 1 is passed, the process information is not readable, but process directories are still shown in the /proc mount. In order to truly hide this information, pass on the value 2.

In order to allow a particular group of people to see other people's processes, the gid= option can be used to exempt this group from the PID hiding.

4.1.3.a. The /proc file system is mounted with hidepid=1 or hidepid=2

Remediation instructions

Mount /proc with hidepid=1 or hidepid=2

Remediation script

                    
mount -o remount,hidepid=2 /proc
          
                  

4.2. System services

Services (daemons) are the primary reason for a server to exist. They represent the function of the server. For instance, a web server will run the apache2 or lighttpd service. A name server will run the named service.

In this benchmark, the focus is on a limited set of system services. For the other services it is wise to consult other hardening guides specific for those services.

References

  1. Center for Internet Security, host of many service benchmarks. URL: <http://www.cisecurity.org>.

4.2.1. Disable unsafe services

It is recommended to disable (or even uninstall) the following services unless absolutely necessary. These services use plain-text protocols and are as such unsafe to use on (untrusted) networks.

  • Telnet service

  • FTP Service

It is recommended to substitute these services with their more secure counterparts (like sFTP, SSH, ...).

4.2.1.a. No telnet daemons are running

Remediation instructions

Stop telnet services

Remediation script

                    
for service in /etc/init.d/*telnet*;
do
  test -f ${service} && run_init rc-service ${service##*/} stop;
done
          
                  

4.2.1.b. No FTP daemons are running

Remediation instructions

Stop FTPd services

Remediation script

                    
for service in /etc/init.d/*ftp*;
do
  test -f ${service} && run_init rc-service ${service##*/} stop;
done
          
                  

4.2.2. Require single-user boot to give root password

When a system is booted in single user mode, some users might find it handy to immediately get a root prompt; many even have a specific bootloader entry to boot in single user mode.

It is important that, for a more secure server environment, even booting in single user mode requires the user to enter the root password. This is already done by default in Gentoo through the rc_shell variable in /etc/rc.conf.

Administrators should also make sure that no direct shells are provided in /etc/inittab for single-user mode. Gentoo's /etc/inittab definition should look like so:

                  
su0:S:wait:/sbin/rc single
su1:S:wait:/sbin/sulogin
                

4.2.2.a. sulogin is used for single-user boot (/etc/rc.conf)

Remediation instructions

Set /sbin/sulogin for rc_shell

Remediation script

                    
sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf
          
                  

4.2.2.b. sulogin is used for single-user boot (/etc/inittab)

Remediation instructions

Set /sbin/sulogin or '/sbin/rc single' for single-user boot in /etc/inittab

4.2.3. Properly Configure TCP Wrappers

With TCP wrappers, services that support TCP wrappers (or those started through xinetd) should be configured to only accept communication with trusted hosts. With the use of /etc/hosts.allow and /etc/hosts.deny, proper access control lists can be created.

More information on the format of these files can be obtained through man 5 hosts_access.

4.2.3.a. /etc/hosts.allow exists

Remediation instructions

Create and properly configure /etc/hosts.allow

4.2.4. SSH service

The SSH service is used for secure remote access towards a system, but also to provide secure file transfers. It is very commonly found on Unix/Linux systems so proper hardening is definitely in place.

Please use the "Hardening OpenSSH" guide for the necessary instructions.

4.2.5. Cron service

A cron service is used to schedule tasks and processes on predefined times. Cron is most often used for regular maintenance tasks.

4.2.5.1. Only allow trusted accounts cron access

Only allow trusted accounts to use cron. How to achieve this depends on the cron service installed.

If vixie-cron or cronie is installed, then have (only) those users that need cron access take part in the cron unix group.

If dcron is used, then make sure /usr/sbin/crontab is only executable by root and the cron unix group, and make sure (only) those users that need cron access take part in the cron unix group.

4.2.6. At service

The at service allows users to execute a task once on a given time. Unlike cron, this is not scheduled repeatedly - once executed, the task is considered completed and at will not invoke it again.

4.2.6.1. Only allow trusted accounts at access

Only allow trusted accounts to use at. Unlike cron access, at access is governed through the /etc/at/at.allow file. If the at.allow file does not exist but /etc/at/at.deny does, then all names not mentioned in the file are allowed to run at. The most secure method is to use the at.allow method.

The format of these files is one username per line.

4.2.6.1.a. /etc/at/at.allow exists

Remediation instructions

Create and properly configure /etc/at/at.allow

4.2.7. NTP service

With NTP, systems can synchronise their clocks, ensuring correct date and time information. This is important as huge clock drift could cause misinterpretation of log files or even unwanted execution of commands.

4.2.7.1. Synchronise the system clock

Synchronise the systems' clock with an authorative NTP server, and use the same NTP service for all other systems.

This can be accomplished by regularly executing ntpdate, but can also be handled using a service like net-misc/ntp's ntpd.

4.2.8. Syslog service

The system logger handles all non-audit related logging generated by applications and daemons. In order to ensure proper forensic analysis if it would ever be needed, the system logger should be properly configured.

4.2.8.1. Configure the system logger to log intervals

Have the system logger log every 10 minutes or so. Without interval logging, administrators might think nothing is wrong although in reality the system logger is malfunctioning and not writing any log events.

4.2.8.2. Enable remote logging

If possible, have vital (or all) logs sent to a remote system logger as well. In home deployments, off-the-shelf (wifi) routers often have a logging daemon that can receive syslog events. For larger environments, a dedicated centralized log server is recommended.

4.2.8.3. Decide which events to send to user terminals

On Linux and Unix systems, events can be sent to user terminals to make those users immediately aware of what is happening. It is recommended to send emergency-level events to everyone and have alerts sent to specific administrative user terminals.

4.3. Portage settings

The package manager of any system is a very important tool. It is responsible for handling proper software deployments, but also offers features that should not be neglected, like security patch roll-out.

For Gentoo, the package manager offers a great deal of flexibility (as that is the goal of Gentoo anyhow). As such, good settings for a more secure environment within Portage (assuming that Portage is used as package manager) are important.

4.3.1. USE flags

USE flags in Gentoo are used to tune the functionality of many components and enable or disable features.

For a well secured environment, there are a couple of USE flags that should be set in a global manner. These USE flags are

  • pam to enable Pluggable Authentication Modules support

  • tcpd for TCP wrappers support

  • ssl for SSL/TLS support

Pluggable Authentication Modules are a powerful mechanism to manage authentication, authorization and user sessions. Applications that support PAM can be tuned to the liking of the organization, leveraging central authentication, password policies, auditing and more.

With TCP wrappers, services can be shielded from unauthorized access on host level. It is an access control level mechanism which allows configuring allowed (and denied) hosts or network segments on application level.

Finally, leveraging Secure Sockets Layer (or the standardized Transport Layer Security) allows applications to encrypt network communication or even implement a client-certificate based authentication mechanism.

Set the USE flags globally in /etc/portage/make.conf so they are applicable to all installed software.

                  
USE="... pam tcpd ssl"
                

4.3.1.a. USE="pam" is set

Remediation instructions

Edit /etc/portage/make.conf and make sure that 'pam' is in the USE declaration

4.3.1.b. USE="tcpd" is set

Remediation instructions

Edit /etc/portage/make.conf and make sure that 'tcpd' is in the USE declaration

4.3.1.c. USE="ssl" is set

Remediation instructions

Edit /etc/portage/make.conf and make sure that 'ssl' is in the USE declaration

4.3.2. Fetching signed portage tree

Gentoo Portage supports fetching signed tree snapshots using emerge-webrsync. This is documented in the Gentoo Handbook, but as it is quite easy, here are the instructions again:

                  
# mkdir -p /etc/portage/gpg
# chmod 0700 /etc/portage/gpg
# export SRV="subkeys.pgp.net"
# export KEY="0x96D8BF6D"
# gpg --homedir /etc/portage/gpg --keyserver ${SRV} --recv-keys ${KEY}
# gpg --homedir /etc/portage/gpg --edit-key ${KEY} trust
                

After this, edit /etc/portage/make.conf:

                  
FEATURES="webrsync-gpg"
PORTAGE_GPG_DIR="/etc/portage/gpg"

                

In the repository configuration (/etc/portage/repos.conf or a file inside it) sync-uri has to be commented out, or set to an empty value.

4.3.2.a. FEATURES="webrsync-gpg" is set

Remediation instructions

Edit /etc/portage/make.conf and make sure that 'webrsync-gpg' is in the FEATURES declaration.

4.3.2.b. PORTAGE_GPG_DIR is set

Remediation instructions

Edit /etc/portage/make.conf and make sure that PORTAGE_GPG_DIR is set correctly.

4.4. Kernel configuration

The Linux kernel should be configured using a sane security standard in mind. When using grSecurity, additional security-enhancing settings can be enabled.

For further details, please refer to the "Hardening the Linux kernel" guide.

References

  1. Gentoo Kernel Configuration Guide - Shorthand notation information. URL: <http://www.gentoo.org/doc/en/kernel-config.xml#shorthand>.

4.5. Bootloader configuration

The bootloader (be it GRUB or another tool) is responsible for loading the Linux kernel and handing over system control to the kernel. But boot loaders also allow for a flexible approach on kernel loading, which can be (ab)used to work around security mechanisms.

4.5.1. Password protect GRUB 2

It is recommended to password-protect the GRUB configuration so that the boot options cannot be modified during a boot without providing the valid password.

TODO looks like this has become a lot more difficult to obtain

References

  1. GRUB2 Passwords (Ubuntu wiki). URL: <https://help.ubuntu.com/community/Grub2/Passwords>.

4.5.2. Password protect GRUB (legacy)

It is recommended to password-protect the GRUB configuration so that the boot options cannot be modified during a boot without providing the valid password.

This can be accomplished by inserting password abc123 in /boot/grub/grub.conf (which will set the password to "abc123"). But as clear-text passwords in the configuration file are insecure as well, hash the passwords. Just start grub and, in the grub-shell, type md5crypt.

                  
# grub

GRUB version 0.92 (640K lower / 3072K upper memory)

[ Minimal BASH-like line editing is supported. ... ]

grub> md5crypt

Password: abc123
Encrypted: $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.

grub> quit
                

This hashed password can now be used in grub.conf using password --md5 $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY..

4.5.2.a. Grub legacy (if it exists) has a password entry with md5 hash

Remediation instructions

Edit /boot/grub/grub.conf and set a password entry with md5 hash

4.5.3. Password protect LILO

It is recommended to password-protect the LILO configuration so that modifying the boot options during a boot without providing the valid password is not possible.

This can be accomplished by inserting password=abc123 followed by restricted in the /etc/lilo.conf file. It is also possible to do this on a per-image level.

                  
password=abc123
restricted
delay=3

image=/boot/bzImage
        read-only
        password=def456
        restricted
                

The restricted keyword is needed to have LILO only ask for the password if a modification is given. If the defaults are used, then no password needs to be provided.

Rerun lilo after updating the configuration file.

4.5.3.a. LILO (if it exists) has a password entry

Remediation instructions

Edit /etc/lilo.conf and set a password entry

4.6. Authentication and authorization settings

An important part in a servers' security is its authentication and authorization support. We have already described how to build in PAM support (through the Portage USE flags), but proper authentication and authorization settings are mode than just compiling in the necessary functionality.

4.6.1. Restrict root system logon

To restrict where the root user can directly log on, edit /etc/securetty and specify the supported terminals for the root user.

When properly configured, any attempt to log on as the root user from a non-defined terminal will result in logon failure.

A recommended setting is to only allow root user login through the console and the physical terminals (tty0-tty12).

                  
console
tty0
tty1
...
tty12
                

4.6.1.a. /etc/securetty is limited to console and tty's

Remediation instructions

Edit /etc/securetty and make sure only 'console' and 'tty[0-9]*' are defined.

4.6.2. Allow only known users to login

When PAM is enabled, the /etc/security/access.conf file is used to check which users are allowed to log on and not (through the login application). These limits are based on username, group and host, network or tty that the user is trying to log on from.

By enabling these settings, the risk is reduced that a functional account (say apache) is abused to log on with, or that a new account is created as part of an exploit.

The following example setting allows only local root logins on tty1, and only the swift account to log on on the system.

                  
+ : root : tty1
- : ALL EXCEPT swift : ALL
          
                

4.6.3. Restrict user resources

When facing a DoS (Denial-of-Service) attack, reducing the impact of the attack can be done by limited resource consumption. Although the component that is under attack will even more quickly fail, the impact towards the other services on the system (including remote logon to fix things) is more limited.

In Gentoo Linux, the following methods are available to limit resources.

  • /etc/security/limits.conf defines the resource limits for logins that are done through a PAM-aware component (default in our setup)

  • /etc/limits defines the resource limits for logins that are done through login programs that are not PAM-aware.

Generally, it should suffice to set up /etc/security/limits.conf, which is the configuration file used by the pam_limits.so module.

Note that the settings are applicable on a per login session basis.

More information on these files and their syntax can be obtained through their manual pages.

                  
# man limits.conf
# man limits
                

4.6.4. Enforce password policy

Usually most organizations have a password policy, telling their users how long their passwords should be and how often the passwords should be changed. Most users see this as an annoying aspect, so it might be best to enforce this policy.

Enforcing password policies is (partially) part of the sys-apps/shadow package (which is installed by default) and can be configured through the /etc/login.defs file. This file is well documented (using comments) and it has a full manual page as well.

A second important player when dealing with password policies is the pam_cracklib.so library. This can be used in the appropriate /etc/pam.d/* files. For instance, for the /etc/pam.d/passwd definition:

                  
auth     required pam_unix.so shadow nullok
account  required pam_unix.so
password required pam_cracklib.so difok=3 retry=3 \
                                  minlen=8 dcredit=-2 \
				  ocredit=-2
password required pam_unix.so md5 use_authok
session  required pam_unix.so
                

In the above example, the password is required to be at least 8 characters long, differ more than 3 characters from the previous password, contain 2 digits and 2 non-alphanumeric characters.

4.6.5. Review password strength regularly

Regularly check the strength of the users' passwords. There are tools out there, like app-crypt/johntheripper which, given a /etc/shadow file (or sometimes even LDAP dump) try to find the passwords for the users.

When such a tool can guess a users' password, that users' password should be expired and the user should be notified and asked to change his password.

4.7. Session settings

Unlike authentication and authorization settings, a session setting is one that is applicable to an authenticated and authorized user when he is logged on to the system.

4.7.1. Disable access to user terminals

By default, user terminals are accessible by others to write messages to (using write, wall or talk). It is adviseable to disable this unless explicitly necessary.

Messages can confuse users and trick them into performing malicious actions.

This can be disabled by setting mesg n in /etc/profile. A user-friendly method for doing so in Gentoo is to create a file /etc/profile.d/disable_mesg which contains this command.

4.8. File and directory privileges and integrity

Proper privileges on files makes it far more difficult to malicious users to obtain sensitive information or write/update files they should not have access to.

4.8.1. Limit world writable files and locations

Limit (or even remove) the use of world writable files and locations. If a directory is world writable, it makes sense to have the sticky bit set on it as well (like with /tmp).

Use find to locate such files or directories.

                  
# find / -perm +o=w ! \( -type d -perm +o=t \) ! -type l -print
                

The above command shows world writable files and locations, unless it is a directory with the sticky bit set, or a symbolic link (whose world writable privilege is not accessible anyhow).

4.8.1.a. All world writable directories have the sticky bit set

Remediation instructions

Make sure all world-writable directories have the sticky bit set

4.8.2. Limit setuid and setgid file and directory usage

The setuid and setgid flags for files and directories can be used to work around authentication and authorization measures taken on the system. So their use should be carefully guarded.

In case of files, the setuid or setgid bit causes the application (if the file is marked as executable) to run with the privileges of the file owner (setuid) or group owner (setgid). It is necessary for applications that need elevated privileges, like su or sudo.

In case of directories, the setgit bit causes newly created files in that directory to automatically be owned by the same group as the mentioned (parent) directory.

4.8.3. Limit capability enabled files

Capabilities within Linux allow users to perform certain privileged tasks.

Unlike setuid flags, the allowed privileges can be defined in a more granular approach (although one can still add in all possible capabilities and thus gain similar privileges as through setuid binaries).

Files with particular capabilities set (through the setcap application) should be regularly reviewed. Capability-enabled files can be found through the following command:

                  
# getcap -r /
                

4.8.4. Logs only readable by proper group

No log file in /var/log should be world readable. Log files should be limited by particular groups (either the group representing the service, like apache or portage, or a specific administrative group like wheel).

4.8.5. Files only used by root should be root-only

Some files, like /etc/shadow, are meant to be read (and perhaps modified) by root only. These files should never have privileges for group- or others.

A nonexhaustive list of such files is:

  • /etc/shadow which contains account password information (including password hashes)

  • /etc/securetty which contains the list of terminals where root is allowed to log on from

4.8.6. Review file integrity regularly

Deploy intrusion detection tool(s) to validate the integrity and privileges on important files. app-forensics/aide is an example of such a tool.

5. Data flows

Clearly map out how data flows in and out of the server (and which data this is). This will be needed anyhow when firewalls are configured, but it also improves integration of the server in a larger infrastructure.

5.1. Backup the data

Make sure that the data is backed up. This is not only in case of server loss, but also to protect against accidental file removal or an awkward bug in a service that deleted important information.

5.1.1. Automated backups

Automate backups on the system. If the backups are performed manually then they are done wrong and someone will eventually forget it.

Use scheduling software like cron to automatically take backups on regular intervals, or use a central backup solution like bacula.

5.1.2. Full data coverage

Many users that do take backups only do this on what they seem as important files. However, it is wise to make full system backups too as recreating an entire system from scratch could otherwise take days or even weeks.

5.1.3. Retention

Ensure that the backups use a long enough retention. It is not wise to take a single backup and overwrite this one over and over again, as there will be a time that a file needs to be recovered that was corrupted long before the last backup was taken.

There is no perfect retention period however, as the more backups are kept, the more storage is required and the more money or time needs to be invested in managing the backups.

In most cases, introduce a "layered" approach on retention. For instance:

  • keep daily backups for a week

  • keep weekly backups (say each monday backup) for a month

  • keep monthly backups (say each first monday) for a year

  • keep yearly backups for 30 years

5.1.4. Off-site backups

Keep the backups off-site in case of disaster. But consider this location carefully. Investigate how fast the backup can be put there, but also how fast it can be retrieved it in case of need. Also investigate if this location is juridically sane (is it allowed to put the data on this location and is this off-site location trusted).

Also ensure that the backups are stored securely. If necessary, encrypt the backups.

5.1.5. Validate and test

Validate that the backup system works. Try recovering files (for instance on a second server or different location) or even entire systems (virtualization is a great help here) and do this regularly.

6. Decommissioning servers

When a server needs to be decommissioned, make sure that its data is safeguarded from future extraction.

Table of Contents

6.1. Wipe disks

Clear all data from the disks on the server in a secure manner. Applications like shred (part of sys-apps/coreutils) can be used to security wipe data or even entire partitions or disks.

It is recommended to perform full disk wipes rather than file wipes. If this needs to be done on file level, see if the file system journaling can be disabled during the wipe session as journaling might "buffer" the secure writes and only write the end result to the disk.

References

  1. NIST Publication "Guidelines for Media Sanitization" (PDF). URL: <http://csrc.nist.gov/publications/drafts/800-88-rev1/sp800_88_r1_draft.pdf>.

Rule Selection

Based on profile: Default server setup settings (non-scripted) (xccdf_org.gentoo.dev.swift_profile_default-oval)

In this profile, we verify common settings for Gentoo Linux configurations. The tests that are enabled in this profile can be ran without visibly impacting the performance of the system. No scripted checks are executed.

Rule selection
/tmp is a separate file system selected
/var is a separate file system selected
/var/log is a separate file system selected
/var/log/audit is a separate file system selected
/home is a separate file system selected
/var/tmp is a separate file system selected
The hardened toolchain is used not selected
/var is mounted with nodev selected
/var/log is mounted with nodev selected
/var/log/audit is mounted with nodev selected
/home is mounted with nodev selected
/tmp is mounted with nodev selected
/tmp is mounted with nosuid selected
/home is mounted with nosuid selected
/dev/shm is mounted with nosuid selected
/tmp is mounted with noexec selected
/dev/shm is mounted with noexec selected
The kernel supports quota (CONFIG_QUOTA) selected
The /var file system is mounted with usrquota or grpquota selected
The /home file system is mounted with usrquota or grpquota selected
The /proc file system is mounted with hidepid=1 or hidepid=2 selected
No telnet daemons are running selected
No FTP daemons are running selected
sulogin is used for single-user boot (/etc/rc.conf) selected
sulogin is used for single-user boot (/etc/inittab) selected
/etc/hosts.allow exists selected
/etc/at/at.allow exists selected
USE="pam" is set selected
USE="tcpd" is set selected
USE="ssl" is set selected
FEATURES="webrsync-gpg" is set selected
PORTAGE_GPG_DIR is set selected
Grub legacy (if it exists) has a password entry with md5 hash selected
LILO (if it exists) has a password entry selected
/etc/securetty is limited to console and tty's selected
All world writable directories have the sticky bit set not selected