diff options
Diffstat (limited to 'xml/SCAP/gentoo-xccdf.xml')
| -rw-r--r-- | xml/SCAP/gentoo-xccdf.xml | 4158 |
1 files changed, 2205 insertions, 1953 deletions
diff --git a/xml/SCAP/gentoo-xccdf.xml b/xml/SCAP/gentoo-xccdf.xml index aa85c1e..35ea6c0 100644 --- a/xml/SCAP/gentoo-xccdf.xml +++ b/xml/SCAP/gentoo-xccdf.xml @@ -1,2018 +1,2270 @@ <?xml version="1.0" encoding="UTF-8"?> <Benchmark xmlns="http://checklists.nist.gov/xccdf/1.2" xmlns:h="http://www.w3.org/1999/xhtml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="xccdf_org.gentoo.dev.swift_benchmark_gentoo-@@VERSION@@-1" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 xccdf-1.2.xsd" resolved="0"> - <status date="@@DATE@@">draft</status> - <title>Gentoo Security Benchmark</title> - <description> - This benchmarks helps people in improving their system configuration to be - more resilient against attacks and vulnerabilities. - </description> - <platform idref="cpe:/o:gentoo:linux"/> - <version>@@VERSION@@</version> - <model system="urn:xccdf:scoring:default" /> - <model system="urn:xccdf:scoring:flat" /> - <model system="urn:xccdf:scoring:flat-unweighted" /> - <Profile id="xccdf_org.gentoo.dev.swift_profile_intensive" extends="xccdf_org.gentoo.dev.swift_profile_default"> - <title>Intensive validation profile</title> - <description> - This profile extends the default server profile by including tests that - are more intensive to run on a system. Tests such as full file system - scans to find world-writable files or directories have an otherwise too - large impact on the performance of a server. Tests include scripted - validationn. - </description> - <!-- Make sure all world-writable directories have the sticky bit set --> - <select idref="xccdf_org.gentoo.dev.swift_rule_worldwritedir-stickybit" selected="true" /> - </Profile> - <Profile id="xccdf_org.gentoo.dev.swift_profile_intensive-oval" extends="xccdf_org.gentoo.dev.swift_profile_default-oval"> - <title>Intensive validation profile (non-scripted)</title> - <description> - This profile extends the default server profile by including tests that - are more intensive to run on a system. Tests such as full file system - scans to find world-writable files or directories have an otherwise too - large impact on the performance of a server. Tests do not include - scripted validation. - </description> - <!-- Make sure all world-writable directories have the sticky bit set --> - <select idref="xccdf_org.gentoo.dev.swift_rule_worldwritedir-stickybit" selected="true" /> - </Profile> - <Profile id="xccdf_org.gentoo.dev.swift_profile_default-oval"> - <title>Default server setup settings (non-scripted)</title> - <description> - 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. - </description> - <!-- The /tmp location is a separate file system --> - <select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp" selected="true" /> - <!-- The /var location is a separate file system --> - <select idref="xccdf_org.gentoo.dev.swift_rule_partition-var" selected="true" /> - <!-- The /var/log location is a separate file system --> - <select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlog" selected="true" /> - <!-- The /var/log/audit location is a separate file system --> - <select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit" selected="true" /> - <!-- The /home location is a separate file system --> - <select idref="xccdf_org.gentoo.dev.swift_rule_partition-home" selected="true" /> - <!-- The /var/tmp location is a separate file system --> - <select idref="xccdf_org.gentoo.dev.swift_rule_partition-vartmp" selected="true" /> - <!-- The /var partition is mounted with nodev --> - <select idref="xccdf_org.gentoo.dev.swift_rule_partition-var-nodev" selected="true" /> - <!-- The /var/log partition is mounted with nodev --> - <select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlog-nodev" selected="true" /> - <!-- The /var/log/audit partition is mounted with nodev --> - <select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit-nodev" selected="true" /> - <!-- The /home partition is moounted with nodev --> - <select idref="xccdf_org.gentoo.dev.swift_rule_partition-home-nodev" selected="true" /> - <!-- The /tmp partition is mounted with nodev --> - <select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nodev" selected="true" /> - <!-- The /tmp partition is mounted with nosuid --> - <select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nosuid" selected="true" /> - <!-- The /home partition is mounted with nosuid --> - <select idref="xccdf_org.gentoo.dev.swift_rule_partition-home-nosuid" selected="true" /> - <!-- The /dev/shm partition is mounted with nosuid --> - <select idref="xccdf_org.gentoo.dev.swift_rule_partition-devshm-nosuid" selected="true" /> - <!-- The /tmp partition is mounted with noexec --> - <select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-noexec" selected="true" /> - <!-- The /dev/shm partition is mounted with noexec --> - <select idref="xccdf_org.gentoo.dev.swift_rule_partition-devshm-noexec" selected="true" /> - <!-- Kernel quota support must be enabled --> - <select idref="xccdf_org.gentoo.dev.swift_rule_kernel-quota" selected="true" /> - <!-- /var is mounted with usrquota or grpquota --> - <select idref="xccdf_org.gentoo.dev.swift_rule_var-quota" selected="true" /> - <!-- /home is mounted with usrquota or grpquota --> - <select idref="xccdf_org.gentoo.dev.swift_rule_home-quota" selected="true" /> - <!-- No telnetd process is running --> - <select idref="xccdf_org.gentoo.dev.swift_rule_telnetd-notrunning" selected="true" /> - <!-- No ftpd process is running --> - <select idref="xccdf_org.gentoo.dev.swift_rule_ftpd-notrunning" selected="true" /> - <!-- sulogin is used as shell for single user boot (definition /etc/rc.conf) --> - <select idref="xccdf_org.gentoo.dev.swift_rule_rcconf-sulogin" selected="true" /> - <!-- sulogin is used as shell for single user boot (definition /etc/inittab) --> - <select idref="xccdf_org.gentoo.dev.swift_rule_inittab-sulogin" selected="true" /> - <!-- Verify that /etc/hosts.allow exists --> - <select idref="xccdf_org.gentoo.dev.swift_rule_hostsallow-exists" selected="true" /> - <!-- Verify that /etc/at/at.allow exists --> - <select idref="xccdf_org.gentoo.dev.swift_rule_atallow-exists" selected="true" /> - <!-- Make sure USE=pam is set --> - <select idref="xccdf_org.gentoo.dev.swift_rule_USE-pam" selected="true" /> - <!-- Make sure USE=tcpd is set --> - <select idref="xccdf_org.gentoo.dev.swift_rule_USE-tcpd" selected="true" /> - <!-- Make sure USE=ssl is set --> - <select idref="xccdf_org.gentoo.dev.swift_rule_USE-ssl" selected="true" /> - <!-- Make sure FEATURES=webrsync-gpg is set --> - <select idref="xccdf_org.gentoo.dev.swift_rule_FEATURES-webrsync-gpg" selected="true" /> - <!-- Make sure PORTAGE_GPG_DIR is set --> - <select idref="xccdf_org.gentoo.dev.swift_rule_PORTAGE_GPG_DIR-nonempty" selected="true" /> - <!-- Make sure /etc/securetty only contains console and tty's --> - <select idref="xccdf_org.gentoo.dev.swift_rule_securetty-limitentries" selected="true" /> - <!-- Make sure /proc is mounted with hidepid=1 or hidepid=2 --> - <select idref="xccdf_org.gentoo.dev.swift_rule_proc-hidepid" selected="true" /> - <!-- Make sure /boot/grub/grub.conf (if it exists) has a password entry with md5 hash --> - <select idref="xccdf_org.gentoo.dev.swift_rule_grubconf-password-md5" selected="true" /> - <!-- Make sure /etc/lilo.conf (if it exists) has a password entry --> - <select idref="xccdf_org.gentoo.dev.swift_rule_liloconf-password" selected="true" /> - </Profile> - <Profile id="xccdf_org.gentoo.dev.swift_profile_default" extends="xccdf_org.gentoo.dev.swift_profile_default-oval"> - <title>Default server setup settings</title> - <description> - In this profile, common settings for Gentoo Linux configurations are validated. - The tests can be ran without visibly impacting the performance of the system, and - also includes the scripted evaluation checks (SCE). - </description> - <!-- The hardened toolchain must be installated and used --> - <select idref="xccdf_org.gentoo.dev.swift_rule_installation-toolchain-hardened" selected="true" /> - </Profile> - <Group id="xccdf_org.gentoo.dev.swift_group_intro"> - <title>Introduction</title> - <description> - <h:p> - 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 <h:em>Security Content Automation Protocol</h:em>. - </h:p> - <h:p> - 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. - </h:p> - <h:p> - Where applicable, this benchmark will refer to a different hardening guide - for specific purposes (such as the Hardening OpenSSH benchmark). - </h:p> - </description> - <reference href="http://www.gentoo.org/doc/en/security/security-handbook.xml">Gentoo - Security Handbook</reference> - <Group id="xccdf_org.gentoo.dev.swift_group_intro-security"> - <title>This is no security policy</title> - <description> - <h:p> - It is <h:em>very important</h:em> 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). - </h:p> - <h:p> - 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. - </h:p> - <h:p> - Readers might find settings they don't agree with. That's fine, but - if there is disagreement about <h:em>why</h:em> it is documented, we would - like to hear it so we can update the guide accordingly. - </h:p> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_intro-scap"> - <title>A little more about SCAP and OVAL</title> - <description> - <h:p> - Within SCAP, NIST has defined some new standards of which XCCDF and OVAL - are notably important in light of this guide. - </h:p> - <h:ul> - <h:li> - XCCDF (Extensible Configuration Checklist Description Format) is - a specification language for writing security checklists and benchmarks - </h:li> - <h:li> - OVAL (Open Vulnerability and Assessment Language) is a standard to describe - and validate system settings - </h:li> - </h:ul> - <h:p> - 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. - </h:p> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_intro-using"> - <title>Using this guide</title> - <description> - <h:p> - This guide is generated from SCAP content (more specifically, the XCCDF document) - using <h:b>openscap</h:b>, a free software implementation for handling SCAP content. - Within Gentoo, the package <h:code>app-forensics/openscap</h:code> provides the tools, - and the following command is used to generate the HTML output: - </h:p> - <h:pre> +<status date="@@DATE@@">draft</status> +<title>Gentoo Security Benchmark</title> +<description> +This benchmarks helps people in improving their system configuration to be +more resilient against attacks and vulnerabilities. +</description> +<platform idref="cpe:/o:gentoo:linux"/> +<version>@@VERSION@@</version> +<model system="urn:xccdf:scoring:default" /> +<model system="urn:xccdf:scoring:flat" /> +<model system="urn:xccdf:scoring:flat-unweighted" /> + +<!-- + Profiles +--> + +<Profile id="xccdf_org.gentoo.dev.swift_profile_intensive" extends="xccdf_org.gentoo.dev.swift_profile_default"> +<title>Intensive validation profile</title> +<description> +This profile extends the default server profile by including tests that +are more intensive to run on a system. Tests such as full file system +scans to find world-writable files or directories have an otherwise too +large impact on the performance of a server. Tests include scripted +validationn. +</description> +<!-- Make sure all world-writable directories have the sticky bit set --> +<select idref="xccdf_org.gentoo.dev.swift_rule_worldwritedir-stickybit" selected="true" /> +</Profile> + +<Profile id="xccdf_org.gentoo.dev.swift_profile_intensive-oval" extends="xccdf_org.gentoo.dev.swift_profile_default-oval"> +<title>Intensive validation profile (non-scripted)</title> +<description> +This profile extends the default server profile by including tests that +are more intensive to run on a system. Tests such as full file system +scans to find world-writable files or directories have an otherwise too +large impact on the performance of a server. Tests do not include +scripted validation. +</description> +<!-- Make sure all world-writable directories have the sticky bit set --> +<select idref="xccdf_org.gentoo.dev.swift_rule_worldwritedir-stickybit" selected="true" /> +</Profile> + +<Profile id="xccdf_org.gentoo.dev.swift_profile_default-oval"> +<title>Default server setup settings (non-scripted)</title> +<description> +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. +</description> +<!-- The /tmp location is a separate file system --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp" selected="true" /> +<!-- The /var location is a separate file system --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-var" selected="true" /> +<!-- The /var/log location is a separate file system --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlog" selected="true" /> +<!-- The /var/log/audit location is a separate file system --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit" selected="true" /> +<!-- The /home location is a separate file system --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-home" selected="true" /> +<!-- The /var/tmp location is a separate file system --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-vartmp" selected="true" /> +<!-- The / partition is mounted with nodev --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-root-nodev" selected="true" /> +<!-- The /var partition is mounted with nodev --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-var-nodev" selected="true" /> +<!-- The /var/log partition is mounted with nodev --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlog-nodev" selected="true" /> +<!-- The /var/log/audit partition is mounted with nodev --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit-nodev" selected="true" /> +<!-- The /home partition is moounted with nodev --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-home-nodev" selected="true" /> +<!-- The /tmp partition is mounted with nodev --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nodev" selected="true" /> +<!-- The /tmp partition is mounted with nosuid --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nosuid" selected="true" /> +<!-- The /home partition is mounted with nosuid --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-home-nosuid" selected="true" /> +<!-- The /dev/shm partition is mounted with nosuid --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-devshm-nosuid" selected="true" /> +<!-- The /tmp partition is mounted with noexec --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-noexec" selected="true" /> +<!-- The /dev/shm partition is mounted with noexec --> +<select idref="xccdf_org.gentoo.dev.swift_rule_partition-devshm-noexec" selected="true" /> +<!-- Kernel quota support must be enabled --> +<select idref="xccdf_org.gentoo.dev.swift_rule_kernel-quota" selected="true" /> +<!-- /var is mounted with usrquota or grpquota --> +<select idref="xccdf_org.gentoo.dev.swift_rule_var-quota" selected="true" /> +<!-- /home is mounted with usrquota or grpquota --> +<select idref="xccdf_org.gentoo.dev.swift_rule_home-quota" selected="true" /> +<!-- No telnetd process is running --> +<select idref="xccdf_org.gentoo.dev.swift_rule_telnetd-notrunning" selected="true" /> +<!-- No ftpd process is running --> +<select idref="xccdf_org.gentoo.dev.swift_rule_ftpd-notrunning" selected="true" /> +<!-- sulogin is used as shell for single user boot (definition /etc/rc.conf) --> +<select idref="xccdf_org.gentoo.dev.swift_rule_rcconf-sulogin" selected="true" /> +<!-- sulogin is used as shell for single user boot (definition /etc/inittab) --> +<select idref="xccdf_org.gentoo.dev.swift_rule_inittab-sulogin" selected="true" /> +<!-- Verify that /etc/hosts.allow exists --> +<select idref="xccdf_org.gentoo.dev.swift_rule_hostsallow-exists" selected="true" /> +<!-- Verify that /etc/at/at.allow exists --> +<select idref="xccdf_org.gentoo.dev.swift_rule_atallow-exists" selected="true" /> +<!-- Make sure USE=pam is set --> +<select idref="xccdf_org.gentoo.dev.swift_rule_USE-pam" selected="true" /> +<!-- Make sure USE=tcpd is set --> +<select idref="xccdf_org.gentoo.dev.swift_rule_USE-tcpd" selected="true" /> +<!-- Make sure USE=ssl is set --> +<select idref="xccdf_org.gentoo.dev.swift_rule_USE-ssl" selected="true" /> +<!-- Make sure FEATURES=webrsync-gpg is set --> +<select idref="xccdf_org.gentoo.dev.swift_rule_FEATURES-webrsync-gpg" selected="true" /> +<!-- Make sure PORTAGE_GPG_DIR is set --> +<select idref="xccdf_org.gentoo.dev.swift_rule_PORTAGE_GPG_DIR-nonempty" selected="true" /> +<!-- Make sure /etc/securetty only contains console and tty's --> +<select idref="xccdf_org.gentoo.dev.swift_rule_securetty-limitentries" selected="true" /> +<!-- Make sure /proc is mounted with hidepid=1 or hidepid=2 --> +<select idref="xccdf_org.gentoo.dev.swift_rule_proc-hidepid" selected="true" /> +<!-- Make sure /boot/grub/grub.conf (if it exists) has a password entry with md5 hash --> +<select idref="xccdf_org.gentoo.dev.swift_rule_grubconf-password-md5" selected="true" /> +<!-- Make sure /etc/lilo.conf (if it exists) has a password entry --> +<select idref="xccdf_org.gentoo.dev.swift_rule_liloconf-password" selected="true" /> +</Profile> + +<Profile id="xccdf_org.gentoo.dev.swift_profile_default" extends="xccdf_org.gentoo.dev.swift_profile_default-oval"> +<title>Default server setup settings</title> +<description> +In this profile, common settings for Gentoo Linux configurations are validated. +The tests can be ran without visibly impacting the performance of the system, and +also includes the scripted evaluation checks (SCE). +</description> +<!-- The hardened toolchain must be installated and used --> +<select idref="xccdf_org.gentoo.dev.swift_rule_installation-toolchain-hardened" selected="true" /> +</Profile> + +<!-- + Benchmark instructions +--> + +<!-- INTRODUCTION --> + +<Group id="xccdf_org.gentoo.dev.swift_group_intro"> +<title>Introduction</title> +<description> +<h:p> +In the past, Gentoo Linux has had a Gentoo Security Handbook +which provides a good insight in securing a Gentoo system. +In order to move this to a next level, we started developing a security +benchmark using SCAP, or the <h:em>Security Content Automation Protocol</h:em>. +</h:p> +<h:p> +Using the SCAP suite, we not only document the various security rules and hardening +entries for a Gentoo Linux system, but we also allow the benchmark to be interpreted +by SCAP compliant tools, which can validate an existing system configuration against +the rules that are documented in the SCAP document. +</h:p> +<h:p> +This particular 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 all +information from the Gentoo Security Handbook is included: +</h:p> +<h:ul> +<h:li> +Some of the settings are specific to a service that is not default (or extremely popular) +on a Gentoo Linux system +</h:li> +<h:li> +Some of the settings are particular to a service that is not specific to Gentoo. Such +settings are best put inside a service-specific benchmark so it is replayable and usable +by non-Gentoo systems as well. +</h:li> +</h:ul> +<h:p> +Although these settings are important as well, it is best done in +separate benchmarks for those services instead. As a result, a number of benchmarks will be +authored and maintained alongside this one. +</h:p> +</description> + +<Group id="xccdf_org.gentoo.dev.swift_group_intro-security"> +<title>This is no security policy</title> +<description> +<h:p> +It is <h:em>very important</h:em> 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). +</h:p> +<h:p> +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. +</h:p> +<h:p> +Readers might find settings they don't agree with. That's fine and perfectly +understandable. Security depends a lot on the environment, use case of the system, +user base and more. If the same security settings would be applicable to all users, +then those settings would be made default (or perhaps even hardcoded) a long time ago. +</h:p> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_intro-scap"> +<title>A little more about SCAP and OVAL</title> +<description> +<h:p> +Within SCAP, NIST has defined some new standards of which XCCDF and OVAL +are notably important in light of this guide. +</h:p> +<h:ul> +<h:li> +XCCDF (Extensible Configuration Checklist Description Format) is +a specification language for writing security checklists and benchmarks +</h:li> +<h:li> +OVAL (Open Vulnerability and Assessment Language) is a standard to describe +and validate system settings +</h:li> +</h:ul> +<h:p> +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. +</h:p> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_intro-using"> +<title>Using this guide</title> +<description> +<h:p> +This guide is generated from SCAP content (more specifically, the XCCDF document) +using <h:b>openscap</h:b>, a free software implementation for handling SCAP content. +Within Gentoo, the package <h:code>app-forensics/openscap</h:code> provides the tools, +and the following command is used to generate the HTML output: +</h:p> +<h:pre> # <h:b>oscap xccdf generate guide gentoo-xccdf.xml > output.html</h:b></h:pre> - <h:p> - 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. - </h:p> - <h:p> - 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), - <h:code>-oval</h:code> profiles are available that only enable the OVAL (and not SCE) - checks. - </h:p> - <h:p> - To validate the tests, the following commands can be used: - </h:p> - <h:pre> +<h:p> +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. +</h:p> +<h:p> +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), +<h:code>-oval</h:code> profiles are available that only enable the OVAL (and not SCE) +checks. +</h:p> +<h:p> +To validate the tests, the following commands can be used: +</h:p> +<h:pre> # <h:b>export PROFILE="xccdf_org.gentoo.dev.swift_profile_default"</h:b> # <h:b>oscap xccdf eval --profile ${PROFILE} gentoo-xccdf.xml</h:b></h:pre> - <h:p> - To generate a full report in HTML as well, use the next command: - </h:p> - <h:pre> +<h:p> +To generate a full report in HTML as well, use the next command: +</h:p> +<h:pre> # <h:b>oscap xccdf eval --profile ${PROFILE} --results xccdf-results.xml \ - --report report.html gentoo-xccdf.xml</h:b></h:pre> - <h:p> - 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. - </h:p> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_intro-profiles"> - <title>Available XCCDF Profiles</title> - <description> - <h:p> - As mentioned earlier, the XCCDF document supports multiple profiles. For the time - being, two profiles are defined: - </h:p> - <h:ul> - <h:li> - The <h:em>default</h:em> profile (xccdf_org.gentoo.dev.swift_profile_default) contains - tests that are quick to validate - </h:li> - <h:li> - The <h:em>default-oval</h:em> 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). - </h:li> - <h:li> - The <h:em>intensive</h:em> 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) - </h:li> - <h:li> - The <h:em>intensive-oval</h:em> 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). - </h:li> - </h:ul> - <h:p> - Substitute the profile information in the commands above with the required profile. - </h:p> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_intro-weights"> - <title>About the rule weights</title> - <description> - <h:p> - 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. - </h:p> - <h:p> - The severity is one of the following: - </h:p> - <h:ul> - <h:li> - <h:em>high</h:em> constitutes a grave or critical problem. A rule with this severity - <h:em>MUST</h:em> be tackled as it detected a misconfiguration that is easily - exploitable and could lead to full system compromise. - </h:li> - <h:li> - <h:em>medium</h:em> reflects a fairly serious problem. A rule with this severity - <h:em>SHOULD</h:em> be tackled as it detected a misconfiguration that is easily - exploitable. - </h:li> - <h:li> - <h:em>low</h:em> 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). - </h:li> - <h:li> - <h:em>info</h:em> reflects an informational rule. Failure to comply with this rule - does not mean failure to comply with the document itself. - </h:li> - </h:ul> - <h:p> - 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. - </h:p> - <h:p> - For this reason, weights are added to rules as well. A higher weight has a more - severe potential impact. - </h:p> - <h:p> - 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. - </h:p> - <h:p> - As an example, take the rule that says <h:code>/var</h:code> 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. - </h:p> - <h:ul> - <h:li> - The <h:em>related exploit range</h:em> (access vector) is "Local", because this is - by itself not exploitable remotely - unless of course certain services are running - that can fill up <h:code>/var</h:code>, but such assumptions are not taken. - </h:li> - <h:li> - The <h:em>attack complexity</h:em> (access complexity) is "Low", as all that is - needed is a local account and we can find the necessary ways to fill up - <h:code>/var</h:code>. - </h:li> - <h:li> - The <h:em>level of authentication needed</h:em> (authentication) is "Single" - as the attacker needs one authentication step (local access) to exploit. - </h:li> - <h:li> - The <h:em>confidentiality impact</h:em> is "None" (no data leakage) - </h:li> - <h:li> - The <h:em>integrity impact</h:em> is "None" (no data manipulation) - </h:li> - <h:li> - The <h:em>availability impact</h:em> is "Complete" (system crash or halt). - </h:li> - </h:ul> - <h:p> - 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. - </h:p> - </description> - <reference href="https://nvd.nist.gov/cvss.cfm?calculator&version=2">NVD CVSS calculator</reference> - <reference href="http://csrc.nist.gov/publications/nistir/ir7502/nistir-7502_CCSS.pdf">The Common Configuration Scoring System (PDF)</reference> - </Group> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation"> - <title>Before starting</title> - <description> - 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. - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-architecturing"> - <title>Infrastructure architecturing</title> - <description> - <h:p> - 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. - </h:p> - <h:p> - A well written and maintained infrastructure architecture helps to - position new services or consider the impact of changes on existing - components. - </h:p> - <h:p> - 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. - </h:p> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-requirements"> - <title>Mapping requirements</title> - <description> - <h:p> - 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? - </h:p> - <h:p> - 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. - </h:p> - </description> - <reference href="https://www.ibm.com/developerworks/rational/library/4706.html">IBM DeveloperWorks article on "Capturing Architectural Requirements"</reference> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-nonsoftware"> - <title>Non-software security concerns</title> - <description> - 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. - </description> - <reference href="https://www.rfc-editor.org/info/rfc2196">Site Security Handbook (RFC2196)</reference> - <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-nonsoftware-physical"> - <title>Physical security</title> - <description> - <h:p> - 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. - </h:p> - <h:p> - 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. - </h:p> - </description> - <reference - href="http://www.sans.org/reading_room/whitepapers/awareness/data-center-physical-security-checklist_416">Data Center Physical Security Checklist (SANS, PDF)</reference> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-nonsoftware-policies"> - <title>Policies and contractual agreements</title> - <description> - <h:p> - 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). - </h:p> - <h:p> - 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. - </h:p> - </description> - <reference - href="http://www.sans.org/reading_room/whitepapers/policyissues/technical-writing-security-policies-easy-steps_492">Technical Writing for IT Security Policies in Five Easy Steps (SANS, PDF)</reference> - <reference - href="https://www.sans.org/security-resources/policies/">Information Security Policy Templates (SANS)</reference> - </Group> - </Group> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_installation"> - <title>Installation configuration</title> - <description> - 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. - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_installation-storage"> - <title>Storage configuration</title> - <description> - 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. - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_installation-storage-partitioning"> - <title>Partitioning</title> - <description> - 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). - </description> - <reference href="http://www.pathname.com/fhs/">Filesystem Hierarchy - Standard</reference> - <Group id="xccdf_org.gentoo.dev.swift_group_installation-storage-partitioning-separate"> - <title>Separate file systems for important locations</title> - <description> - <h:p> - 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. - </h:p> - <h:p> - These disadvantages are: - </h:p> - <h:ul> - <h:li> - 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. - </h:li> - <h:li> - 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). - </h:li> - </h:ul> - <h:p> - The advantages on the other hand: - </h:p> - <h:ul> - <h:li> - 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. - </h:li> - <h:li> - 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. - </h:li> - <h:li> - 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. - </h:li> - </h:ul> - <h:p> - Considering these pros and cons, it is recommended to have at least the following - file system locations to be on a different file system: - </h:p> - <h:ul> - <h:li> - <h:code>/tmp</h:code> as this is a world-writable location and requires - specific mount options. When possible, this location can be made a - <h:em>tmpfs</h:em> file system. This is to protect the root file system - from being flooded. - </h:li> - <h:li> - <h:code>/var</h:code> 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. - </h:li> - <h:li> - <h:code>/var/log</h:code> as this contains logging data (and thus is prone - to grow extensively depending on the services). This is to protect the - <h:code>/var</h:code> file system from being flooded, as this might impact - various services (like databases, web servers, etc.). - </h:li> - <h:li> - <h:code>/var/log/audit</h:code> as this contains (potentially sensitive) - logging data. Some services refuse to continue if the audit target location - is full. Having the location separate from <h:code>/var/log</h:code> protects - the audit file system when <h:code>/var/log</h:code> would be flooded. - </h:li> - <h:li> - <h:code>/home</h:code> 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 <h:code>/home</h:code> location to be either shared or used elsewhere. - </h:li> - <h:li> - <h:code>/var/tmp</h:code> which is a "second" <h:code>/tmp</h:code> 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 <h:code>/var</h:code> to be flooded which might impact the - availability of services. - </h:li> - </h:ul> - </description> - <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp" selected="false" severity="medium" weight="4.6"> - <title>/tmp is a separate file system</title> - <fixtext> - Create a file system for <h:code>/tmp</h:code>; make sure it is added in - the <h:code>/etc/fstab</h:code> file and reboot the system. - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:5" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-var" selected="false" severity="medium" weight="4.6"> - <title>/var is a separate file system</title> - <fixtext> - Create a file system for <h:code>/var</h:code>; make sure it is added in - the <h:code>/etc/fstab</h:code> file and reboot the system. - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:6" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlog" selected="false" severity="low" weight="2.1"> - <title>/var/log is a separate file system</title> - <fixtext> - Create a file system for <h:code>/var/log</h:code>; make sure it is added in - the <h:code>/etc/fstab</h:code> file and reboot the system. - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:7" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit" selected="false" severity="low" weight="2.1"> - <title>/var/log/audit is a separate file system</title> - <fixtext> - Create a file system for <h:code>/var/log/audit</h:code>; make sure it is added in - the <h:code>/etc/fstab</h:code> file and reboot the system. - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:8" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home" selected="false" severity="medium" weight="4.6"> - <title>/home is a separate file system</title> - <fixtext> - Create a file system for <h:code>/home</h:code>; make sure it is added in - the <h:code>/etc/fstab</h:code> file and reboot the system. - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:2" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-vartmp" selected="false" severity="low" weight="2.1"> - <title>/var/tmp is a separate file system</title> - <fixtext> - Create a file system for <h:code>/var/tmp</h:code>; make sure it is added in - the <h:code>/etc/fstab</h:code> file and reboot the system. - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:17" href="gentoo-oval.xml" /> - </check> - </Rule> - </Group> - </Group> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_installation-toolchain"> - <title>Use a Hardened Toolchain</title> - <description> - <h:p> - 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. - </h:p> - <h:ul> - <h:li> - <h:em>Position Independent Executables (PIE)</h:em> and <h:em>Position Independent - Code (PIC)</h:em> 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. - </h:li> - <h:li> - <h:em>Stack Smashing Protection (SSP)</h:em> adds markers outside buffer areas - to detect buffer overflow attacks, killing the application rather than effectively - having the overflow succeed. - </h:li> - </h:ul> - <h:p> - During installation, make sure that the <h:em>default</h:em> hardened - toolchain is selected, not one of the <h:code>-hardenedno*</h:code> as - those are toolchains where specific settings are disabled. The - <h:code>-vanilla</h:code> one is a toolchain with no hardened patches. - </h:p> - <h:pre> -# <h:b>gcc-config -l</h:b> - [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</h:pre> - </description> - <Rule id="xccdf_org.gentoo.dev.swift_rule_installation-toolchain-hardened" selected="false" severity="low" weight="0.0"> - <title>The hardened toolchain is used</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_installation-toolchain-hardened"> - Use a hardened Gentoo profile and select the default compiler (not vanilla - nor any of the hardenedno* ones). - </fixtext> - <check system="http://open-scap.org/page/SCE"> - <check-import import-name="stdout" /> - <check-content-ref href="bin/gentoo-sce_installation-toolchain-hardened.sh" /> - </check> - </Rule> - </Group> <!-- installation-toolchain --> - </Group> <!-- installation --> - <Group id="xccdf_org.gentoo.dev.swift_group_system"> - <title>System settings</title> - <description> - 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. - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_system-fs"> - <title>File system related settings</title> - <description> - Servers and systems are about manipulating data. In this chapter, the security settings - for file systems are explained. - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_system-fs-mountoptions"> - <title>Using no* mount options for the file systems</title> - <description> - <h:p> - Non-root file systems should be mounted with the <h:em>nodev</h:em> 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). - </h:p> - <h:p> - 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. - </h:p> - <h:p> - 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. - </h:p> - <h:p> - This setting is appropriate for file systems such as (non-exhaustive list): - </h:p> - <h:ul> - <h:li> - <h:code>/var</h:code> (as it is recommended to be a separate file system) - </h:li> - <h:li> - <h:code>/var/log</h:code> (as it is recommended to be a separate file system) - </h:li> - <h:li> - <h:code>/var/log/audit</h:code> (as it is recommended to be a separate file system) - </h:li> - <h:li> - <h:code>/home</h:code> (as it is recommended to be a separate file system) - </h:li> - <h:li> - <h:code>/tmp</h:code> (as it is recommended to be a separate file system) - </h:li> - </h:ul> - <h:p> - Specific file systems should also be mounted with the <h:em>nosuid</h:em> 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: - </h:p> - <h:ul> - <h:li> - The <h:code>/tmp</h:code> file system should not be used for setuid binaries - as this is a world-writable location and often target storage for attacks. - </h:li> - <h:li> - The <h:code>/home</h:code> file system should not be used for setuid binaries - as this is the home location for non-root users. - </h:li> - <h:li> - The <h:code>/dev/shm</h:code> file system should not be used for any binaries - (shared memory region). - </h:li> - </h:ul> - <h:p> - Specific file systems should also be mounted with the <h:em>noexec</h:em> mount - option. This prevents some automated attacks to execute certain payload (exploits) - from these locations. - </h:p> - <h:p> - 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 <h:code>ld-linux.so</h:code> binary (although this has - been fixed). - </h:p> - <h:p> - File systems for which <h:em>noexec</h:em> is recommended are: - </h:p> - <h:ul> - <h:li> - The <h:code>/tmp</h:code> file system as it is a popular target to store exploit - code in. - </h:li> - <h:li> - The <h:code>/dev/shm</h:code> file system as it is meant as a shared memory - location and is becoming a popular target to store exploit code in. - </h:li> - </h:ul> - </description> - <!-- CVSS2 AV:L/Au:M/C:C/I:C/A:C (high complexity as device node needs - to be created first and is then only exploitable after local access. - Multiple authentication (one to create device file, one to log on) - --> - <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-var-nodev" selected="false" severity="low" weight="5.9"> - <title>/var is mounted with nodev</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-var-nodev">Mount /var with nodev mount option</fixtext> - <fix id="xccdf_org.gentoo.dev.swift_fix_partition-var-nodev" - system="urn:xccdf:fix:system:commands" - platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> +--report report.html gentoo-xccdf.xml</h:b></h:pre> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_intro-profiles"> +<title>Available XCCDF Profiles</title> +<description> +<h:p> +As mentioned earlier, this XCCDF document supports multiple profiles. For the time +being, two profiles are defined: +</h:p> +<h:ul> +<h:li> +The <h:em>default</h:em> profile (xccdf_org.gentoo.dev.swift_profile_default) contains +tests that are quick to validate +</h:li> +<h:li> +The <h:em>default-oval</h:em> 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). +</h:li> +<h:li> +The <h:em>intensive</h:em> 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) +</h:li> +<h:li> +The <h:em>intensive-oval</h:em> 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). +</h:li> +</h:ul> +<h:p> +Substitute the profile information in the commands above with the required profile. +</h:p> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_intro-weights"> +<title>About the rule weights</title> +<description> +<h:p> +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. +</h:p> +<h:p> +The severity is one of the following: +</h:p> +<h:ul> +<h:li> +<h:em>high</h:em> constitutes a grave or critical problem. A rule with this severity +<h:em>MUST</h:em> be tackled as it detected a misconfiguration that is easily +exploitable and could lead to full system compromise. +</h:li> +<h:li> +<h:em>medium</h:em> reflects a fairly serious problem. A rule with this severity +<h:em>SHOULD</h:em> be tackled as it detected a misconfiguration that is easily +exploitable. +</h:li> +<h:li> +<h:em>low</h:em> 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). +</h:li> +<h:li> +<h:em>info</h:em> reflects an informational rule. Failure to comply with this rule +does not mean failure to comply with the document itself. +</h:li> +</h:ul> +<h:p> +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. +</h:p> +<h:p> +For this reason, weights are added to rules as well. A higher weight has a more +severe potential impact. +</h:p> +<h:p> +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. +</h:p> +<h:p> +As an example, take the rule that says <h:code>/var</h:code> 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. +</h:p> +<h:ul> +<h:li> +The <h:em>related exploit range</h:em> (access vector) is "Local", because this is +by itself not exploitable remotely - unless of course certain services are running +that can fill up <h:code>/var</h:code>, but such assumptions are not taken. +</h:li> +<h:li> +The <h:em>attack complexity</h:em> (access complexity) is "Low", as all that is +needed is a local account and we can find the necessary ways to fill up +<h:code>/var</h:code>. +</h:li> +<h:li> +The <h:em>level of authentication needed</h:em> (authentication) is "Single" +as the attacker needs one authentication step (local access) to exploit. +</h:li> +<h:li> +The <h:em>confidentiality impact</h:em> is "None" (no data leakage) +</h:li> +<h:li> +The <h:em>integrity impact</h:em> is "None" (no data manipulation) +</h:li> +<h:li> +The <h:em>availability impact</h:em> is "Complete" (system crash or halt). +</h:li> +</h:ul> +<h:p> +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. +</h:p> +</description> +<reference href="https://nvd.nist.gov/cvss.cfm?calculator&version=2">NVD CVSS calculator</reference> +<reference href="http://csrc.nist.gov/publications/nistir/ir7502/nistir-7502_CCSS.pdf">The Common Configuration Scoring System (PDF)</reference> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_intro-resources"> +<title>Additional resources</title> +<description> +From the next chapter onwards, the focus will be on the software side +hardening. For more information about other related security areas, please take a look +at the following resources. +</description> +<reference href="https://www.rfc-editor.org/info/rfc2196">Site Security Handbook (RFC2196)</reference> +<reference href="http://www.sans.org/reading_room/whitepapers/awareness/data-center-physical-security-checklist_416">Data Center Physical Security Checklist (SANS, PDF)</reference> +<reference href="http://www.sans.org/reading_room/whitepapers/policyissues/technical-writing-security-policies-easy-steps_492">Technical Writing for IT Security Policies in Five Easy Steps (SANS, PDF)</reference> +<reference href="https://www.sans.org/security-resources/policies/">Information Security Policy Templates (SANS)</reference> +</Group> +</Group> + +<!-- INSTALLATION --> + +<Group id="xccdf_org.gentoo.dev.swift_group_installation"> +<title>Installation related settings</title> +<description> +<h:p> +Gentoo Linux allows us to update various parts of the system after installation, +but it might be interesting to consider some aspects during (or before) +installation as it might require a huge migration afterwards. +</h:p> +<h:p> +The Gentoo Linux installation is structured as follows: +</h:p> +<h:ol> +<h:li>The disks, partitions or other storage is prepared to host the Gentoo Linux OS</h:li> +<h:li>The base Gentoo installation (a minimal install called a "stage3") is extracted on the system</h:li> +<h:li>Boot-critical configuration entries, such as file system information and Portage configuration are set up</h:li> +<h:li>A Linux kernel is compiled and installed, together with a boot loader</h:li> +<h:li>Basic accounts are created to allow a log on to the system after boot</h:li> +</h:ol> +<h:p> +In the following sections, the best practices for a secure system are described related to these installation specific entries. +</h:p> +</description> +<reference href="https://wiki.gentoo.org/wiki/Handbook:Main_Page">Gentoo Linux Handbook</reference> + +<Group id="xccdf_org.gentoo.dev.swift_group_installation-hardware"> +<title>Hardware selection</title> +<description> +<h:p> +TODO +</h:p> +</description> + +<Group id="xccdf_org.gentoo.dev.swift_group_installation-hardware-tpm"> +<title>Trusted Platform Module</title> +<description> +<h:p> +TODO +</h:p> +</description> +</Group> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_installation-storage"> +<title>Storage and file systems</title> +<description> +<h:p> +Storage devices, and the file systems on them, are one of the basic parts of any operating system. +The file systems provide not only structured access to the data, but also metadata about the files +and directories, including access control related information. +</h:p> +<h:p> +When securing a system, we need to look at: +</h:p> +<h:ul> +<h:li>Partition and file system structure</h:li> +<h:li>File system tuning</h:li> +</h:ul> +<h:p> +The file system structure (or partition layout as it is also often called) is a very important +step in the design of any operating system deployment. Within Gentoo Linux' Handbook, an entire +chapter is written just on this particular matter. The structure needs to support the purpose of +the system. +</h:p> +<h:p> +For instance, for a database server, the file system on which the database files are stored is +usually separate from the operating system file system, and often even has its dedicated back +end storage (different disks) in order to be sufficiently high performing. The location of the +log files (and audit logs) is separate from operating system and database files so that an overflow +in the logs does not harm the database itself or the operating system. +</h:p> +<h:p> +And database servers are just one example. LDAP servers, mail servers, shell servers, workstations, +... all have their own specific file system structure and best practices. +</h:p> +</description> +<reference href="http://www.pathname.com/fhs/">Filesystem Hierarchy Standard</reference> + +<Group id="xccdf_org.gentoo.dev.swift_group_installation-storage-separatepartitions"> +<title>Separate file systems for important locations</title> +<description> +<h:p> +Separate file systems for important locations is an important basic security measure, but it does have +its consequences. Depending on the purpose of the system and the financial freedom while designing the +server structure, some concessions might need to be made. +</h:p> +<h:p> +The main disadvantages of a separate file system for a location are: +</h:p> +<h:ul> +<h:li> +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. +</h:li> +<h:li> +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). +</h:li> +</h:ul> +<h:p> +The advantages on the other hand: +</h:p> +<h:ul> +<h:li> +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. +</h:li> +<h:li> +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. +</h:li> +<h:li> +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. +</h:li> +</h:ul> +<h:p> +Considering these pros and cons, it is recommended to have at least the following +file system locations be on a different file system: +</h:p> +<h:ul> +<h:li> +<h:code>/tmp</h:code> as this is a world-writable location and requires +specific mount options. When possible, this location can be made a +<h:em>tmpfs</h:em> file system. This is to protect the root file system +from being flooded. +</h:li> +<h:li> +<h:code>/var</h:code> 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. +</h:li> +<h:li> +<h:code>/var/log</h:code> as this contains logging data (and thus is prone +to grow extensively depending on the services). This is to protect the +<h:code>/var</h:code> file system from being flooded, as this might impact +various services (like databases, web servers, etc.). +</h:li> +<h:li> +<h:code>/var/log/audit</h:code> as this contains (potentially sensitive) +logging data. Some services refuse to continue if the audit target location +is full. Having the location separate from <h:code>/var/log</h:code> protects +the audit file system when <h:code>/var/log</h:code> would be flooded. +</h:li> +<h:li> +<h:code>/home</h:code> 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 <h:code>/home</h:code> location to be either shared or used elsewhere. +</h:li> +<h:li> +<h:code>/var/tmp</h:code> which is a "second" <h:code>/tmp</h:code> 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 <h:code>/var</h:code> to be flooded which might impact the +availability of services. +</h:li> +</h:ul> +</description> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp" selected="false" severity="medium" weight="4.6"> +<title>/tmp is a separate file system</title> +<fixtext> +Create a file system for <h:code>/tmp</h:code>; make sure it is added in +the <h:code>/etc/fstab</h:code> file and reboot the system. +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:5" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-var" selected="false" severity="medium" weight="4.6"> +<title>/var is a separate file system</title> +<fixtext> +Create a file system for <h:code>/var</h:code>; make sure it is added in +the <h:code>/etc/fstab</h:code> file and reboot the system. +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:6" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlog" selected="false" severity="low" weight="2.1"> +<title>/var/log is a separate file system</title> +<fixtext> +Create a file system for <h:code>/var/log</h:code>; make sure it is added in +the <h:code>/etc/fstab</h:code> file and reboot the system. +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:7" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit" selected="false" severity="low" weight="2.1"> +<title>/var/log/audit is a separate file system</title> +<fixtext> +Create a file system for <h:code>/var/log/audit</h:code>; make sure it is added in +the <h:code>/etc/fstab</h:code> file and reboot the system. +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:8" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home" selected="false" severity="medium" weight="4.6"> +<title>/home is a separate file system</title> +<fixtext> +Create a file system for <h:code>/home</h:code>; make sure it is added in +the <h:code>/etc/fstab</h:code> file and reboot the system. +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:2" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-vartmp" selected="false" severity="low" weight="2.1"> +<title>/var/tmp is a separate file system</title> +<fixtext> +Create a file system for <h:code>/var/tmp</h:code>; make sure it is added in +the <h:code>/etc/fstab</h:code> file and reboot the system. +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:17" href="gentoo-oval.xml" /> +</check> +</Rule> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_installation-storage-mountoptions"> +<title>File system mount options</title> +<description> +<h:p> +There are a number of mount options which can improve system security significantly. +</h:p> +<!-- nodev --> +<h:p> +A first important setting is the <h:tt>nodev</h:tt> 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 the wrong 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. +</h:p> +<h:p> +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 into creating such device files, or by having different +locations with device files accessible (such as removable media). +</h:p> +<h:p> +Given that, on Gentoo Linux, device files are situated inside a <h:em>devtmpfs</h:em> +file system, most mount points can be configured with the <h:tt>nodev</h:tt> mount +option. +</h:p> +<h:ul> +<h:li> +<h:code>/</h:code> (as the root file system) +</h:li> +<h:li> +<h:code>/var</h:code> (as it is recommended to be a separate file system) +</h:li> +<h:li> +<h:code>/var/log</h:code> (as it is recommended to be a separate file system) +</h:li> +<h:li> +<h:code>/var/log/audit</h:code> (as it is recommended to be a separate file system) +</h:li> +<h:li> +<h:code>/home</h:code> (as it is recommended to be a separate file system) +</h:li> +<h:li> +<h:code>/tmp</h:code> (as it is recommended to be a separate file system) +</h:li> +</h:ul> +<!-- nosuid --> +<h:p> +A second important mount option is the <h:tt>nosuid</h:tt> one. This prevents setuid binaries +to effectively run as a different user when hosted on this file system. In other words, it is as +if there is no setuid bit set on these binaries. When SELinux is enabled, this will also prevent any +domain transition for executables on this file system. When using capabilities, the <h:tt>nosuid</h:tt> +option also influences the <h:tt>CAP_SETUID</h:tt> and <h:tt>CAP_SETGID</h:tt> capabilities. +</h:p> +<h:p> +As there are several locations where setuid binaries (or related capabilities) might be needed +(or where SELinux domain transitions are still wanted), this is only recommended for a specific +set of file systems: +</h:p> +<h:ul> +<h:li> +The <h:code>/tmp</h:code> file system should not be used for setuid binaries +as this is a world-writable location and often target storage for attacks. +</h:li> +<h:li> +The <h:code>/home</h:code> file system should not be used for setuid binaries +as this is the home location for non-root users. +</h:li> +<h:li> +The <h:code>/dev/shm</h:code> file system should not be used for any binaries +(shared memory region). +</h:li> +</h:ul> +<!-- noexec --> +<h:p> +Specific file systems should also be mounted with the <h:tt>noexec</h:tt> mount +option. This prevents some automated attacks to execute certain payload (exploits) +from these locations. +</h:p> +<h:p> +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 <h:code>ld-linux.so</h:code> binary (although this has +been fixed). +</h:p> +<h:p> +File systems for which <h:tt>noexec</h:tt> is recommended are: +</h:p> +<h:ul> +<h:li> +The <h:code>/tmp</h:code> file system as it is a popular target to store exploit +code in. +</h:li> +<h:li> +The <h:code>/dev/shm</h:code> file system as it is meant as a shared memory +location and is becoming a popular target to store exploit code in. +</h:li> +</h:ul> +</description> +<warning> +This section uses mount options as the means to configure the mount points. However, mount options are not the +only way of tuning these settings - many file systems support the same through commands such as <h:tt>tune2fs</h:tt>. +</warning> + +<!-- CVSS2 AV:L/Au:M/C:C/I:C/A:C (high complexity as device node needs +to be created first and is then only exploitable after local access. +Multiple authentication (one to create device file, one to log on) +--> +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-root-nodev" selected="false" severity="low" weight="5.9"> +<title>/ is mounted with nodev</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-root-nodev">Mount / with nodev mount option</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_partition-root-nodev" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> +mount -o remount,nodev / +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:37" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-var-nodev" selected="false" severity="low" weight="5.9"> +<title>/var is mounted with nodev</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-var-nodev">Mount /var with nodev mount option</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_partition-var-nodev" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> mount -o remount,nodev /var - </fix> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:9" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlog-nodev" selected="false" severity="low" weight="5.9"> - <title>/var/log is mounted with nodev</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-varlog-nodev">Mount /var/log with nodev mount option</fixtext> - <fix id="xccdf_org.gentoo.dev.swift_fix_partition-varlog-nodev" - system="urn:xccdf:fix:system:commands" - platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:9" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlog-nodev" selected="false" severity="low" weight="5.9"> +<title>/var/log is mounted with nodev</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-varlog-nodev">Mount /var/log with nodev mount option</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_partition-varlog-nodev" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> mount -o remount,nodev /var/log - </fix> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:10" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit-nodev" selected="false" severity="low" weight="5.9"> - <title>/var/log/audit is mounted with nodev</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-varlogaudit-nodev">Mount /var/log/audit with nodev mount option</fixtext> - <fix id="xccdf_org.gentoo.dev.swift_fix_partition-varlogaudit-nodev" - system="urn:xccdf:fix:system:commands" - platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:10" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit-nodev" selected="false" severity="low" weight="5.9"> +<title>/var/log/audit is mounted with nodev</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-varlogaudit-nodev">Mount /var/log/audit with nodev mount option</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_partition-varlogaudit-nodev" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> mount -o remount,nodev /var/log/audit - </fix> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:11" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home-nodev" selected="false" severity="low" weight="5.9"> - <title>/home is mounted with nodev</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-home-nodev">Mount /home with nodev mount option</fixtext> - <fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-nodev" - system="urn:xccdf:fix:system:commands" - platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:11" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home-nodev" selected="false" severity="low" weight="5.9"> +<title>/home is mounted with nodev</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-home-nodev">Mount /home with nodev mount option</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-nodev" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> mount -o remount,nodev /home - </fix> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:4" href="gentoo-oval.xml" /> - </check> - </Rule> - <!-- Higher severity due to more best practices and world writeable, - also more likely that exploit of process is done towards /tmp --> - <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nodev" selected="false" severity="medium" weight="5.9"> - <title>/tmp is mounted with nodev</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nodev">Mount /tmp with nodev mount option</fixtext> - <fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nodev" - system="urn:xccdf:fix:system:commands" - platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:4" href="gentoo-oval.xml" /> +</check> +</Rule> + +<!-- Higher severity due to more best practices and world writeable, also more likely that exploit of process is done towards /tmp --> +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nodev" selected="false" severity="medium" weight="5.9"> +<title>/tmp is mounted with nodev</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nodev">Mount /tmp with nodev mount option</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nodev" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> mount -o remount,nodev /tmp - </fix> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:12" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nosuid" selected="false" severity="medium" weight="5.9"> - <title>/tmp is mounted with nosuid</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nosuid">Mount /tmp with nosuid mount option</fixtext> - <fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nosuid" - system="urn:xccdf:fix:system:commands" - platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:12" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nosuid" selected="false" severity="medium" weight="5.9"> +<title>/tmp is mounted with nosuid</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nosuid">Mount /tmp with nosuid mount option</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nosuid" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> mount -o remount,nosuid /tmp - </fix> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:13" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home-nosuid" selected="false" severity="low" weight="5.9"> - <title>/home is mounted with nosuid</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-home-nosuid">Mount /home with nosuid mount option</fixtext> - <fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-nosuid" - system="urn:xccdf:fix:system:commands" - platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:13" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home-nosuid" selected="false" severity="low" weight="5.9"> +<title>/home is mounted with nosuid</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-home-nosuid">Mount /home with nosuid mount option</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-nosuid" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> mount -o remount,nosuid /home - </fix> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:3" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-devshm-nosuid" selected="false" severity="medium" weight="5.9"> - <title>/dev/shm is mounted with nosuid</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-devshm-nosuid">Mount /dev/shm with nosuid mount option</fixtext> - <fix id="xccdf_org.gentoo.dev.swift_fix_partition-devshm-nosuid" - system="urn:xccdf:fix:system:commands" - platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:3" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-devshm-nosuid" selected="false" severity="medium" weight="5.9"> +<title>/dev/shm is mounted with nosuid</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-devshm-nosuid">Mount /dev/shm with nosuid mount option</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_partition-devshm-nosuid" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> mount -o remount,nosuid /dev/shm - </fix> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:14" href="gentoo-oval.xml" /> - </check> - </Rule> - <!-- Weight is 0 as this is a means to exploit, not exploitable by - itself --> - <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-noexec" selected="false" severity="medium" weight="0.0"> - <title>/tmp is mounted with noexec</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-noexec">Mount /tmp with noexec mount option</fixtext> - <fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-noexec" - system="urn:xccdf:fix:system:commands" - platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:14" href="gentoo-oval.xml" /> +</check> +</Rule> + +<!-- Weight is 0 as this is a means to exploit, not exploitable by itself --> +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-noexec" selected="false" severity="medium" weight="0.0"> +<title>/tmp is mounted with noexec</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-noexec">Mount /tmp with noexec mount option</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-noexec" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> mount -o remount,noexec /tmp - </fix> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:15" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-devshm-noexec" selected="false" severity="medium" weight="0.0"> - <title>/dev/shm is mounted with noexec</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-devshm-noexec">Mount /dev/shm with nosuid mount option</fixtext> - <fix id="xccdf_org.gentoo.dev.swift_fix_partition-devshm-noexec" - system="urn:xccdf:fix:system:commands" - platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:15" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_partition-devshm-noexec" selected="false" severity="medium" weight="0.0"> +<title>/dev/shm is mounted with noexec</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-devshm-noexec">Mount /dev/shm with nosuid mount option</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_partition-devshm-noexec" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> mount -o remount,noexec /dev/shm - </fix> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:16" href="gentoo-oval.xml" /> - </check> - </Rule> - </Group> <!-- system-fs-mountoptions --> - <Group id="xccdf_org.gentoo.dev.swift_group_system-fs-quotas"> - <title>Disk quota support</title> - <description> - <h:p> - Most file systems support the notion of <h:em>quotas</h:em> - limits - on the amount of data / files that are allowed on that particular file system. - </h:p> - <h:p> - To enable quotas, first configure the Linux kernel to include - <h:code>CONFIG_QUOTA</h:code>. - </h:p> - <h:p> - Next, install the <h:code>sys-fs/quota</h:code> package. - </h:p> - <h:pre> +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:16" href="gentoo-oval.xml" /> +</check> +</Rule> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_installation-storage-encrypted"> +<title>Use encrypted file systems</title> +<description> +<h:p> +TODO: Use encrypted file systems if not hosted in fully trusted environment +</h:p> +<h:p> +This includes encrypted swap! +</h:p> +</description> +</Group> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_installation-base"> +<title>Gentoo base installation</title> +<description> +<h:p> +The Gentoo base installation concerns itself with the extraction of a minimal Gentoo Linux environment. +This minimal environment provides the base foundation for building the rest of the system, including +a compiler, necessary set of libraries and system services. +</h:p> +</description> + +<Group id="xccdf_org.gentoo.dev.swift_group_installation-base-stage3"> +<title>Hardened stage3</title> +<description> +<h:p> +Use one of Gentoo Hardened's stage3 archive files as the base of the Linux installation. +</h:p> +<h:p> +The Gentoo Hardened stages are built with a hardened compiler and toolchain, which means +that the various binaries included are already built with PIC and PIE, allowing for the +various memory protections (such as Address Space Layout Randomization) to take effect. +</h:p> +<h:p> +Administrations will have the option of selecting a hardened <h:em>nomultilib</h:em> stage +as well. With multilib, the system is capable of running both 32-bit and 64-bit applications. +With a <h:em>nomultilib</h:em> stage, only 64-bit applications can be used. It is generally recommended +to use the <h:em>nomultilib</h:em> stages if this is possible functionally. That means, if there +is no need to run 32-bit applications on a 64-bit installation. +</h:p> +<h:p> +One of the concerns with using multilib systems is that a number of libraries are provided through +the <h:tt>emul-linux</h:tt> package, which might contain vulnerable libraries. Sadly, there is not +enough manpower available to update this package as quickly as the main libraries. Gentoo Linux +is slowly converting towards the <h:em>gx86-multilib</h:em> approach where the 32-bit libraries +are provided by the native ebuilds themselves. +</h:p> +</description> +<reference href="https://wiki.gentoo.org/wiki/Multilib/gx86-multilib">Gentoo gx86-multilib information</reference> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_installation-base-toolchain"> +<title>Hardened toolchain</title> +<description> +<h:p> +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. +</h:p> +<h:ul> +<h:li> +When using <h:em>Position Independent Executables (PIE)</h:em> and <h:em>Position Independent +Code (PIC)</h:em>, which is enabled when selecting the hardened toolchain, memory hardening techniques +such as those implemented by grsecurity PaX allows for Address Space Layout Randomization (ASLR) so +that memory locations for an application are randomized with every run. This makes exploitation of +memory oriented vulnerabilities much harder. +</h:li> +<h:li> +<h:em>Stack Smashing Protection (SSP)</h:em> adds markers outside buffer areas +to detect buffer overflow attacks, killing the application rather than effectively +having the overflow succeed. +</h:li> +</h:ul> +<h:p> +During installation, make sure that the <h:em>default</h:em> hardened +toolchain is selected, not one of the <h:code>-hardenedno*</h:code> as +those are toolchains where specific settings are disabled. The +<h:code>-vanilla</h:code> one is a toolchain with no hardened patches. +</h:p> +<h:pre> +# <h:b>gcc-config -l</h:b> +[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</h:pre> +</description> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_installation-toolchain-hardened" selected="false" severity="low" weight="0.0"> +<title>The hardened toolchain is used</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_installation-toolchain-hardened"> +Use a hardened Gentoo profile and select the default compiler (not vanilla +nor any of the hardenedno* ones). +</fixtext> +<check system="http://open-scap.org/page/SCE"> +<check-import import-name="stdout" /> +<check-content-ref href="bin/gentoo-sce_installation-toolchain-hardened.sh" /> +</check> +</Rule> + +</Group> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_installation-boot"> +<title>Boot-critical services</title> +<description> +<h:p> +Before finishing a Gentoo Linux installation, a number of boot-critical services are installed. +This includes the boot loader itself as well as the Linux kernel. +</h:p> +<h:p> +Building a Linux kernel with the right set of security-related settings is moved outside the scope of this +benchmark. Please refer to the Kernel hardening benchmark for more information. +</h:p> +</description> +<reference href="http://dev.gentoo.org/~swift/docs/security_benchmarks/guide-kernel-xccdf.html">Gentoo Linux Kernel hardening benchmark</reference> + +<Group id="xccdf_org.gentoo.dev.swift_group_installation-boot-bootloader"> +<title>Bootloader configuration</title> +<description> +<h:p> +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. +</h:p> +</description> + +<Group id="xccdf_org.gentoo.dev.swift_group_installation-boot-bootloader-uefi"> +<title>UEFI settings</title> +<description> +<h:p> +TODO: Use UEFI boot mode +</h:p> +<h:p> +TODO: Password required to enter UEFI configuration +</h:p> +<h:p> +TODO: UEFI level password to boot system +</h:p> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_installation-boot-bootloader-grub2pass"> +<title>Password protect GRUB 2</title> +<description> +<h:p> +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. +</h:p> +<h:p> +TODO looks like this has become a lot more difficult to obtain +</h:p> +</description> +<reference href="https://help.ubuntu.com/community/Grub2/Passwords">GRUB2 Passwords (Ubuntu wiki)</reference> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_installation-boot-bootloader-grub1pass"> +<title>Password protect GRUB (legacy)</title> +<description> +<h:p> +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. +</h:p> +<h:p> +This can be accomplished by inserting <h:code>password abc123</h:code> +in <h:code>/boot/grub/grub.conf</h:code> (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 <h:b>grub</h:b> +and, in the grub-shell, type <h:b>md5crypt</h:b>. +</h:p> +<h:pre> +# <h:b>grub</h:b> + +GRUB version 0.92 (640K lower / 3072K upper memory) + +[ Minimal BASH-like line editing is supported. ... ] + +grub> <h:b>md5crypt</h:b> + +Password: <h:em>abc123</h:em> +Encrypted: $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY. + +grub> <h:b>quit</h:b></h:pre> +<h:p> +This hashed password can now be used in <h:code>grub.conf</h:code> +using <h:code>password --md5 $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.</h:code>. +</h:p> +</description> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_grubconf-password-md5" selected="false" severity="low" weight="6.9"> +<title>Grub legacy (if it exists) has a password entry with md5 hash</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_grubconf-password-md5"> +Edit /boot/grub/grub.conf and set a password entry with md5 hash +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:34" href="gentoo-oval.xml" /> +</check> +</Rule> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_installation-boot-bootloader-lilopass"> +<title>Password protect LILO</title> +<description> +<h:p> +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. +</h:p> +<h:p> +This can be accomplished by inserting <h:code>password=abc123</h:code> +followed by <h:code>restricted</h:code> in the +<h:code>/etc/lilo.conf</h:code> file. It is also possible to do this +on a per-image level. +</h:p> +<h:pre> +password=abc123 +restricted +delay=3 + +image=/boot/bzImage +read-only +password=def456 +restricted</h:pre> +<h:p> +The <h:code>restricted</h:code> 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. +</h:p> +<h:p> +Rerun <h:code>lilo</h:code> after updating the configuration file. +</h:p> +</description> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_liloconf-password" selected="false" severity="low" weight="6.9"> +<title>LILO (if it exists) has a password entry</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_liloconf-password"> +Edit /etc/lilo.conf and set a password entry +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:35" href="gentoo-oval.xml" /> +</check> +</Rule> + +</Group> + +</Group> + +</Group> + +</Group> <!-- End of installation related --> + +<Group id="xccdf_org.gentoo.dev.swift_group_system"> +<title>Portage and system settings</title> +<description> +<h:p> +After a succesful Gentoo Linux installation, there are still various settings which need to be +adjusted in order to create a properly hardened system. +</h:p> +</description> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-fs"> +<title>File system related settings</title> +<description> +Servers and systems are about manipulating data. In this chapter, the security settings +for file systems are explained. +</description> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-fs-quotas"> +<title>Disk quota support</title> +<description> +<h:p> +Most file systems support the notion of <h:em>quotas</h:em> - limits +on the amount of data / files that are allowed on that particular file system. +</h:p> +<h:p> +To enable quotas, first configure the Linux kernel to include +<h:code>CONFIG_QUOTA</h:code>. +</h:p> +<h:p> +Next, install the <h:code>sys-fs/quota</h:code> package. +</h:p> +<h:pre> # <h:b>emerge quota</h:b></h:pre> - <h:p> - Then add <h:code>usrquota</h:code> and <h:code>grpquota</h:code> to - the partitions (in <h:code>/etc/fstab</h:code>) where quotas need to be - enabled on. For instance, the following snippet from - <h:code>/etc/fstab</h:code> enables quotas on <h:code>/var</h:code> - and <h:code>/home</h:code>. - </h:p> - <h:pre> +<h:p> +Then add <h:code>usrquota</h:code> and <h:code>grpquota</h:code> to +the partitions (in <h:code>/etc/fstab</h:code>) where quotas need to be +enabled on. For instance, the following snippet from +<h:code>/etc/fstab</h:code> enables quotas on <h:code>/var</h:code> +and <h:code>/home</h:code>. +</h:p> +<h:pre> /dev/mapper/volgrp-home /home ext4 noatime,nodev,nosuid,<h:b>usrquota,grpquota</h:b> 0 0 /dev/mapper/volgrp-var /var ext4 noatime,<h:b>usrquota,grpquota</h:b> 0 0</h:pre> - <h:p> - Finally, add the <h:code>quota</h:code> service to the boot runlevel. - </h:p> - <h:pre> +<h:p> +Finally, add the <h:code>quota</h:code> service to the boot runlevel. +</h:p> +<h:pre> # <h:b>rc-update add quota boot</h:b></h:pre> - <h:p> - 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. - </h:p> - </description> - <reference - href="http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch28_:_Managing_Disk_Usage_with_Quotas">Managing - Disk Usage with Quotas (LinuxHomeNetworking)</reference> - <reference href="http://www.gentoo.org/doc/en/kernel-config.xml#shorthand">Gentoo Linux Kernel Configuration - shorthand notation information</reference> - <Rule id="xccdf_org.gentoo.dev.swift_rule_kernel-quota" selected="false" severity="low" weight="1.7"> - <title>The kernel supports quota (CONFIG_QUOTA)</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_kernel-quota">Rebuild the Linux kernel with quota support (CONFIG_QUOTA)</fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:18" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_var-quota" selected="false" severity="low" weight="1.7"> - <title>The /var file system is mounted with usrquota or grpquota</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_var-quota">Mount /var with usrquota and/or grpquota</fixtext> - <fix id="xccdf_org.gentoo.dev.swift_fix_partition-var-quota" - system="urn:xccdf:fix:system:commands" - platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> +<h:p> +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. +</h:p> +</description> +<reference +href="http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch28_:_Managing_Disk_Usage_with_Quotas">Managing +Disk Usage with Quotas (LinuxHomeNetworking)</reference> +<reference href="http://www.gentoo.org/doc/en/kernel-config.xml#shorthand">Gentoo Linux Kernel Configuration - shorthand notation information</reference> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_kernel-quota" selected="false" severity="low" weight="1.7"> +<title>The kernel supports quota (CONFIG_QUOTA)</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_kernel-quota">Rebuild the Linux kernel with quota support (CONFIG_QUOTA)</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:18" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_var-quota" selected="false" severity="low" weight="1.7"> +<title>The /var file system is mounted with usrquota or grpquota</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_var-quota">Mount /var with usrquota and/or grpquota</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_partition-var-quota" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> mount -o remount,usrquota,grpquota /var - </fix> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:25" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_home-quota" selected="false" severity="low" weight="1.7"> - <title>The /home file system is mounted with usrquota or grpquota</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_home-quota">Mount /home with usrquota and/or grpquota</fixtext> - <fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-quota" - system="urn:xccdf:fix:system:commands" - platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:25" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_home-quota" selected="false" severity="low" weight="1.7"> +<title>The /home file system is mounted with usrquota or grpquota</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_home-quota">Mount /home with usrquota and/or grpquota</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-quota" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> mount -o remount,usrquota,grpquota /home - </fix> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:26" href="gentoo-oval.xml" /> - </check> - </Rule> - </Group> <!-- system-fs-quotas --> - <Group id="xccdf_org.gentoo.dev.swift_group_system-fs-hidepid"> - <title>Hiding process information through hidepid</title> - <description> - <h:p> - In order to hide process information from other users, the <h:code>/proc</h:code> file system needs to be - mounted with the <h:code>hidepid</h:code> option. With value 0, the default behavior is used, meaning that - all process information is world readable. - </h:p> - <h:p> - When the value 1 is passed, the process information is not readable, but process directories are still shown - in the <h:code>/proc</h:code> mount. In order to truly hide this information, pass on the value 2. - </h:p> - <h:p> - In order to allow a particular group of people to see other people's processes, the <h:code>gid=</h:code> - option can be used to exempt this group from the PID hiding. - </h:p> - </description> - <reference href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0499680a42141d86417a8fbaa8c8db806bea1201">Kernel commit introducing - the hidepid support</reference> - <Rule id="xccdf_org.gentoo.dev.swift_rule_proc-hidepid" selected="false" severity="medium" weight="1.7"> - <title>The /proc file system is mounted with hidepid=1 or hidepid=2</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_proc-hidepid">Mount /proc with hidepid=1 or hidepid=2</fixtext> - <fix id="xccdf_org.gentoo.dev.swift_fix_proc-hidepid" - system="urn:xccdf:fix:system:commands" - platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:26" href="gentoo-oval.xml" /> +</check> +</Rule> + +</Group> <!-- system-fs-quotas --> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-fs-hidepid"> +<title>Hiding process information through hidepid</title> +<description> +<h:p> +In order to hide process information from other users, the <h:code>/proc</h:code> file system needs to be +mounted with the <h:code>hidepid</h:code> option. With value 0, the default behavior is used, meaning that +all process information is world readable. +</h:p> +<h:p> +When the value 1 is passed, the process information is not readable, but process directories are still shown +in the <h:code>/proc</h:code> mount. In order to truly hide this information, pass on the value 2. +</h:p> +<h:p> +In order to allow a particular group of people to see other people's processes, the <h:code>gid=</h:code> +option can be used to exempt this group from the PID hiding. +</h:p> +</description> +<reference href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0499680a42141d86417a8fbaa8c8db806bea1201">Kernel commit introducing +the hidepid support</reference> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_proc-hidepid" selected="false" severity="medium" weight="1.7"> +<title>The /proc file system is mounted with hidepid=1 or hidepid=2</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_proc-hidepid">Mount /proc with hidepid=1 or hidepid=2</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_proc-hidepid" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> mount -o remount,hidepid=2 /proc - </fix> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:33" href="gentoo-oval.xml" /> - </check> - </Rule> - </Group> - </Group> <!-- system-fs --> - <Group id="xccdf_org.gentoo.dev.swift_group_system-services"> - <title>System services</title> - <description> - <h:p> - 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. - </h:p> - <h:p> - 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. - </h:p> - </description> - <reference href="http://www.cisecurity.org">Center for Internet Security, - host of many service benchmarks</reference> - <Group id="xccdf_org.gentoo.dev.swift_group_system-services-disable"> - <title>Disable unsafe services</title> - <description> - <h:p> - 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. - </h:p> - <h:ul> - <h:li>Telnet service</h:li> - <h:li>FTP Service</h:li> - </h:ul> - <h:p> - It is recommended to substitute these services with their more secure - counterparts (like sFTP, SSH, ...). - </h:p> - </description> - <!-- Max score: password in clear text and your system is compromised (if it is root) --> - <Rule id="xccdf_org.gentoo.dev.swift_rule_telnetd-notrunning" selected="false" severity="high" weight="10.0"> - <title>No telnet daemons are running</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_telnetd-notrunning">Stop telnet services</fixtext> - <fix id="xccdf_org.gentoo.dev.swift_fix_telnetd-notrunning" - system="urn:xccdf:fix:system:commands" - platform="cpe:/o:gentoo:linux" complexity="low" disruption="high" reboot="false"> +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:33" href="gentoo-oval.xml" /> +</check> +</Rule> + +</Group> + +</Group> <!-- system-fs --> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-services"> +<title>System services</title> +<description> +<h:p> +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. +</h:p> +<h:p> +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. +</h:p> +</description> +<reference href="http://www.cisecurity.org">Center for Internet Security, +host of many service benchmarks</reference> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-services-disable"> +<title>Disable unsafe services</title> +<description> +<h:p> +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. +</h:p> +<h:ul> +<h:li>Telnet service</h:li> +<h:li>FTP Service</h:li> +</h:ul> +<h:p> +It is recommended to substitute these services with their more secure +counterparts (like sFTP, SSH, ...). +</h:p> +</description> +<!-- Max score: password in clear text and your system is compromised (if it is root) --> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_telnetd-notrunning" selected="false" severity="high" weight="10.0"> +<title>No telnet daemons are running</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_telnetd-notrunning">Stop telnet services</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_telnetd-notrunning" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="high" reboot="false"> for service in /etc/init.d/*telnet*; do - test -f ${service} && run_init rc-service ${service##*/} stop; +test -f ${service} && run_init rc-service ${service##*/} stop; done - </fix> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:19" href="gentoo-oval.xml" /> - </check> - </Rule> - <!-- Partial breach, assuming accounts are not system accounts --> - <Rule id="xccdf_org.gentoo.dev.swift_rule_ftpd-notrunning" selected="false" severity="medium" weight="7.5"> - <title>No FTP daemons are running</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_ftpd-notrunning">Stop FTPd services</fixtext> - <fix id="xccdf_org.gentoo.dev.swift_fix_ftpd-notrunning" - system="urn:xccdf:fix:system:commands" - platform="cpe:/o:gentoo:linux" complexity="low" disruption="high" reboot="false"> +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:19" href="gentoo-oval.xml" /> +</check> +</Rule> + +<!-- Partial breach, assuming accounts are not system accounts --> +<Rule id="xccdf_org.gentoo.dev.swift_rule_ftpd-notrunning" selected="false" severity="medium" weight="7.5"> +<title>No FTP daemons are running</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_ftpd-notrunning">Stop FTPd services</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_ftpd-notrunning" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="high" reboot="false"> for service in /etc/init.d/*ftp*; do - test -f ${service} && run_init rc-service ${service##*/} stop; +test -f ${service} && run_init rc-service ${service##*/} stop; done - </fix> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:20" href="gentoo-oval.xml" /> - </check> - </Rule> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-services-sulogin"> - <title>Require single-user boot to give root password</title> - <description> - <h:p> - 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. - </h:p> - <h:p> - 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 - <h:code>rc_shell</h:code> variable in <h:code>/etc/rc.conf</h:code>. - </h:p> - <h:p> - Administrators should also make sure that no direct shells are provided - in <h:code>/etc/inittab</h:code> for single-user mode. Gentoo's - <h:code>/etc/inittab</h:code> definition should look like so: - </h:p> - <h:pre> +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:20" href="gentoo-oval.xml" /> +</check> +</Rule> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-services-sulogin"> +<title>Require single-user boot to give root password</title> +<description> +<h:p> +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. +</h:p> +<h:p> +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 +<h:code>rc_shell</h:code> variable in <h:code>/etc/rc.conf</h:code>. +</h:p> +<h:p> +Administrators should also make sure that no direct shells are provided +in <h:code>/etc/inittab</h:code> for single-user mode. Gentoo's +<h:code>/etc/inittab</h:code> definition should look like so: +</h:p> +<h:pre> su0:S:wait:/sbin/rc single <h:b>su1:S:wait:/sbin/sulogin</h:b></h:pre> - </description> - <!-- CVSS2: AV:L/AC:H/Au:S/C:C/I:C/A:C (high attack complexity due to console access) --> - <Rule id="xccdf_org.gentoo.dev.swift_rule_rcconf-sulogin" selected="false" severity="medium" weight="6.0"> - <title>sulogin is used for single-user boot (/etc/rc.conf)</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_rcconf-sulogin">Set /sbin/sulogin for rc_shell</fixtext> - <fix id="xccdf_org.gentoo.dev.swift_fix_rcconf-sulogin" - system="urn:xccdf:fix:system:commands" - platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> +</description> + +<!-- CVSS2: AV:L/AC:H/Au:S/C:C/I:C/A:C (high attack complexity due to console access) --> +<Rule id="xccdf_org.gentoo.dev.swift_rule_rcconf-sulogin" selected="false" severity="medium" weight="6.0"> +<title>sulogin is used for single-user boot (/etc/rc.conf)</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_rcconf-sulogin">Set /sbin/sulogin for rc_shell</fixtext> +<fix id="xccdf_org.gentoo.dev.swift_fix_rcconf-sulogin" +system="urn:xccdf:fix:system:commands" +platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false"> sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf - </fix> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:21" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_inittab-sulogin" selected="false" severity="medium" weight="6.0"> - <title>sulogin is used for single-user boot (/etc/inittab)</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_inittab-sulogin"> - Set /sbin/sulogin or '/sbin/rc single' for single-user boot in /etc/inittab - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:22" href="gentoo-oval.xml" /> - </check> - </Rule> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-services-tcpwrappers"> - <title>Properly Configure TCP Wrappers</title> - <description> - <h:p> - With TCP wrappers, services that support TCP wrappers (or those - started through <h:b>xinetd</h:b>) should be configured to only accept - communication with trusted hosts. With the use of - <h:code>/etc/hosts.allow</h:code> and <h:code>/etc/hosts.deny</h:code>, - proper access control lists can be created. - </h:p> - <h:p> - More information on the format of these files can be obtained through - <h:b>man 5 hosts_access</h:b>. - </h:p> - </description> - <Rule id="xccdf_org.gentoo.dev.swift_rule_hostsallow-exists" selected="false" severity="info" weight="0.0"> - <title>/etc/hosts.allow exists</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_hostsallow-exists"> - Create and properly configure /etc/hosts.allow - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:23" href="gentoo-oval.xml" /> - </check> - </Rule> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-services-ssh"> - <title>SSH service</title> - <description> - <h:p> - 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. - </h:p> - <h:p> - Please use the "Hardening OpenSSH" guide for the necessary instructions. - </h:p> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-services-cron"> - <title>Cron service</title> - <description> - A cron service is used to schedule tasks and processes on predefined - times. Cron is most often used for regular maintenance tasks. - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_system-services-cron-acl"> - <title>Only allow trusted accounts cron access</title> - <description> - <h:p> - Only allow trusted accounts to use cron. How to achieve this depends on the cron service - installed. - </h:p> - <h:p> - If vixie-cron or cronie is installed, then have (only) those users that need cron access - take part in the <h:em>cron</h:em> unix group. - </h:p> - <h:p> - If dcron is used, then make sure <h:code>/usr/sbin/crontab</h:code> is only executable by - root and the cron unix group, and make sure (only) those users that need cron access take part - in the <h:em>cron</h:em> unix group. - </h:p> - </description> - </Group> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-services-at"> - <title>At service</title> - <description> - 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. - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_system-services-at-acl"> - <title>Only allow trusted accounts at access</title> - <description> - <h:p> - Only allow trusted accounts to use at. Unlike cron access, at access is governed through - the <h:code>/etc/at/at.allow</h:code> file. If the <h:code>at.allow</h:code> file does not - exist but <h:code>/etc/at/at.deny</h:code> does, then all names <h:em>not</h:em> mentioned in - the file are allowed to run at. The most secure method is to use the <h:code>at.allow</h:code> - method. - </h:p> - <h:p> - The format of these files is one username per line. - </h:p> - </description> - <Rule id="xccdf_org.gentoo.dev.swift_rule_atallow-exists" selected="false" severity="low" weight="0.0"> - <title>/etc/at/at.allow exists</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_atsallow-exists"> - Create and properly configure /etc/at/at.allow - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:24" href="gentoo-oval.xml" /> - </check> - </Rule> - </Group> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-services-ntp"> - <title>NTP service</title> - <description> - <h:p> - 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. - </h:p> - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_system-services-ntp-sync"> - <title>Synchronise the system clock</title> - <description> - <h:p> - Synchronise the systems' clock with an authorative NTP server, and - use the same NTP service for all other systems. - </h:p> - <h:p> - This can be accomplished by regularly executing <h:b>ntpdate</h:b>, - but can also be handled using a service like <h:code>net-misc/ntp</h:code>'s - <h:b>ntpd</h:b>. - </h:p> - </description> - </Group> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog"> - <title>Syslog service</title> - <description> - <h:p> - 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. - </h:p> - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog-logintervals"> - <title>Configure the system logger to log intervals</title> - <description> - <h:p> - 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. - </h:p> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog-remotelogging"> - <title>Enable remote logging</title> - <description> - <h:p> - 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. - </h:p> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog-terminal"> - <title>Decide which events to send to user terminals</title> - <description> - <h:p> - 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. - </h:p> - </description> - </Group> - </Group> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-portage"> - <title>Portage settings</title> - <description> - <h:p> - 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. - </h:p> - <h:p> - 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. - </h:p> - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_system-portage-use"> - <title>USE flags</title> - <description> - <h:p> - USE flags in Gentoo are used to tune the functionality of many - components and enable or disable features. - </h:p> - <h:p> - For a well secured environment, there are a couple of USE flags that - should be set in a global manner. These USE flags are - </h:p> - <h:ul> - <h:li> - <h:code>pam</h:code> to enable Pluggable Authentication - Modules support - </h:li> - <h:li> - <h:code>tcpd</h:code> for TCP wrappers support - </h:li> - <h:li> - <h:code>ssl</h:code> for SSL/TLS support - </h:li> - </h:ul> - <h:p> - <h:b>Pluggable Authentication Modules</h:b> 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. - </h:p> - <h:p> - With <h:b>TCP wrappers</h:b>, 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. - </h:p> - <h:p> - Finally, leveraging <h:b>Secure Sockets Layer</h:b> (or the - standardized <h:b>Transport Layer Security</h:b>) allows applications - to encrypt network communication or even implement a - client-certificate based authentication mechanism. - </h:p> - <h:p> - Set the USE flags globally in <h:code>/etc/portage/make.conf</h:code> - so they are applicable to all installed software. - </h:p> - <h:pre> +</fix> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:21" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_inittab-sulogin" selected="false" severity="medium" weight="6.0"> +<title>sulogin is used for single-user boot (/etc/inittab)</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_inittab-sulogin"> +Set /sbin/sulogin or '/sbin/rc single' for single-user boot in /etc/inittab +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:22" href="gentoo-oval.xml" /> +</check> +</Rule> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-services-tcpwrappers"> +<title>Properly Configure TCP Wrappers</title> +<description> +<h:p> +With TCP wrappers, services that support TCP wrappers (or those +started through <h:b>xinetd</h:b>) should be configured to only accept +communication with trusted hosts. With the use of +<h:code>/etc/hosts.allow</h:code> and <h:code>/etc/hosts.deny</h:code>, +proper access control lists can be created. +</h:p> +<h:p> +More information on the format of these files can be obtained through +<h:b>man 5 hosts_access</h:b>. +</h:p> +</description> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_hostsallow-exists" selected="false" severity="info" weight="0.0"> +<title>/etc/hosts.allow exists</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_hostsallow-exists"> +Create and properly configure /etc/hosts.allow +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:23" href="gentoo-oval.xml" /> +</check> +</Rule> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-services-ssh"> +<title>SSH service</title> +<description> +<h:p> +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. +</h:p> +<h:p> +Please use the "Hardening OpenSSH" guide for the necessary instructions. +</h:p> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-services-cron"> +<title>Cron service</title> +<description> +A cron service is used to schedule tasks and processes on predefined +times. Cron is most often used for regular maintenance tasks. +</description> +<Group id="xccdf_org.gentoo.dev.swift_group_system-services-cron-acl"> +<title>Only allow trusted accounts cron access</title> +<description> +<h:p> +Only allow trusted accounts to use cron. How to achieve this depends on the cron service +installed. +</h:p> +<h:p> +If vixie-cron or cronie is installed, then have (only) those users that need cron access +take part in the <h:em>cron</h:em> unix group. +</h:p> +<h:p> +If dcron is used, then make sure <h:code>/usr/sbin/crontab</h:code> is only executable by +root and the cron unix group, and make sure (only) those users that need cron access take part +in the <h:em>cron</h:em> unix group. +</h:p> +</description> +</Group> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-services-at"> +<title>At service</title> +<description> +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. +</description> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-services-at-acl"> +<title>Only allow trusted accounts at access</title> +<description> +<h:p> +Only allow trusted accounts to use at. Unlike cron access, at access is governed through +the <h:code>/etc/at/at.allow</h:code> file. If the <h:code>at.allow</h:code> file does not +exist but <h:code>/etc/at/at.deny</h:code> does, then all names <h:em>not</h:em> mentioned in +the file are allowed to run at. The most secure method is to use the <h:code>at.allow</h:code> +method. +</h:p> +<h:p> +The format of these files is one username per line. +</h:p> +</description> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_atallow-exists" selected="false" severity="low" weight="0.0"> +<title>/etc/at/at.allow exists</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_atsallow-exists"> +Create and properly configure /etc/at/at.allow +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:24" href="gentoo-oval.xml" /> +</check> +</Rule> + +</Group> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-services-ntp"> +<title>NTP service</title> +<description> +<h:p> +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. +</h:p> +</description> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-services-ntp-sync"> +<title>Synchronise the system clock</title> +<description> +<h:p> +Synchronise the systems' clock with an authorative NTP server, and +use the same NTP service for all other systems. +</h:p> +<h:p> +This can be accomplished by regularly executing <h:b>ntpdate</h:b>, +but can also be handled using a service like <h:code>net-misc/ntp</h:code>'s +<h:b>ntpd</h:b>. +</h:p> +</description> +</Group> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog"> +<title>Syslog service</title> +<description> +<h:p> +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. +</h:p> +</description> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog-logintervals"> +<title>Configure the system logger to log intervals</title> +<description> +<h:p> +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. +</h:p> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog-remotelogging"> +<title>Enable remote logging</title> +<description> +<h:p> +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. +</h:p> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-services-syslog-terminal"> +<title>Decide which events to send to user terminals</title> +<description> +<h:p> +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. +</h:p> +</description> +</Group> + +</Group> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-portage"> +<title>Portage settings</title> +<description> +<h:p> +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. +</h:p> +<h:p> +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. +</h:p> +</description> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-portage-use"> +<title>USE flags</title> +<description> +<h:p> +USE flags in Gentoo are used to tune the functionality of many +components and enable or disable features. +</h:p> +<h:p> +For a well secured environment, there are a couple of USE flags that +should be set in a global manner. These USE flags are +</h:p> +<h:ul> +<h:li> +<h:code>pam</h:code> to enable Pluggable Authentication +Modules support +</h:li> +<h:li> +<h:code>tcpd</h:code> for TCP wrappers support +</h:li> +<h:li> +<h:code>ssl</h:code> for SSL/TLS support +</h:li> +</h:ul> +<h:p> +<h:b>Pluggable Authentication Modules</h:b> 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. +</h:p> +<h:p> +With <h:b>TCP wrappers</h:b>, 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. +</h:p> +<h:p> +Finally, leveraging <h:b>Secure Sockets Layer</h:b> (or the +standardized <h:b>Transport Layer Security</h:b>) allows applications +to encrypt network communication or even implement a +client-certificate based authentication mechanism. +</h:p> +<h:p> +Set the USE flags globally in <h:code>/etc/portage/make.conf</h:code> +so they are applicable to all installed software. +</h:p> +<h:pre> USE="... pam tcpd ssl"</h:pre> - </description> - <Rule id="xccdf_org.gentoo.dev.swift_rule_USE-pam" selected="false" severity="low" weight="0.0"> - <title>USE="pam" is set</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_USE-pam"> - Edit /etc/portage/make.conf and make sure that 'pam' is in the USE declaration - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:27" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_USE-tcpd" selected="false" severity="low" weight="0.0"> - <title>USE="tcpd" is set</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_USE-tcpd"> - Edit /etc/portage/make.conf and make sure that 'tcpd' is in the USE declaration - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:28" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_USE-ssl" selected="false" severity="low" weight="0.0"> - <title>USE="ssl" is set</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_USE-ssl"> - Edit /etc/portage/make.conf and make sure that 'ssl' is in the USE declaration - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:29" href="gentoo-oval.xml" /> - </check> - </Rule> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-portage-webrsync"> - <title>Fetching signed portage tree</title> - <description> - <h:p> - Gentoo Portage supports fetching signed tree snapshots using - <h:b>emerge-webrsync</h:b>. This is documented in the Gentoo Handbook, - but as it is quite easy, here are the instructions again: - </h:p> - <h:pre> +</description> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_USE-pam" selected="false" severity="low" weight="0.0"> +<title>USE="pam" is set</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_USE-pam"> +Edit /etc/portage/make.conf and make sure that 'pam' is in the USE declaration +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:27" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_USE-tcpd" selected="false" severity="low" weight="0.0"> +<title>USE="tcpd" is set</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_USE-tcpd"> +Edit /etc/portage/make.conf and make sure that 'tcpd' is in the USE declaration +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:28" href="gentoo-oval.xml" /> +</check> +</Rule> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_USE-ssl" selected="false" severity="low" weight="0.0"> +<title>USE="ssl" is set</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_USE-ssl"> +Edit /etc/portage/make.conf and make sure that 'ssl' is in the USE declaration +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:29" href="gentoo-oval.xml" /> +</check> + +</Rule> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-portage-webrsync"> +<title>Fetching signed portage tree</title> +<description> +<h:p> +Gentoo Portage supports fetching signed tree snapshots using +<h:b>emerge-webrsync</h:b>. This is documented in the Gentoo Handbook, +but as it is quite easy, here are the instructions again: +</h:p> +<h:pre> # <h:b>mkdir -p /etc/portage/gpg</h:b> # <h:b>chmod 0700 /etc/portage/gpg</h:b> # <h:b>export SRV="subkeys.pgp.net"</h:b> # <h:b>export KEY="0x96D8BF6D"</h:b> # <h:b>gpg --homedir /etc/portage/gpg --keyserver ${SRV} --recv-keys ${KEY}</h:b> # <h:b>gpg --homedir /etc/portage/gpg --edit-key ${KEY} trust</h:b></h:pre> - <h:p> - After this, edit <h:code>/etc/portage/make.conf</h:code>: - </h:p> - <h:pre> +<h:p> +After this, edit <h:code>/etc/portage/make.conf</h:code>: +</h:p> +<h:pre> FEATURES="webrsync-gpg" PORTAGE_GPG_DIR="/etc/portage/gpg" </h:pre> - <h:p> - In the repository configuration (<h:code>/etc/portage/repos.conf</h:code> or a - file inside it) <h:code>sync-uri</h:code> has to be commented out, or set to an - empty value. - </h:p> - </description> - <Rule id="xccdf_org.gentoo.dev.swift_rule_FEATURES-webrsync-gpg" selected="false" severity="low" weight="0.0"> - <title>FEATURES="webrsync-gpg" is set</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_FEATURES-webrsync-gpg"> - Edit /etc/portage/make.conf and make sure that 'webrsync-gpg' is in the FEATURES declaration. - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:30" href="gentoo-oval.xml" /> - </check> - </Rule> - <Rule id="xccdf_org.gentoo.dev.swift_rule_PORTAGE_GPG_DIR-nonempty" selected="false" severity="low" weight="0.0"> - <title>PORTAGE_GPG_DIR is set</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_PORTAGE_GPG_DIR-nonempty"> - Edit /etc/portage/make.conf and make sure that PORTAGE_GPG_DIR is set correctly. - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:31" href="gentoo-oval.xml" /> - </check> - </Rule> - - </Group> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-kernel"> - <title>Kernel configuration</title> - <description> - <h:p> - The Linux kernel should be configured using a sane security standard in - mind. When using grSecurity, additional security-enhancing settings can - be enabled. - </h:p> - <h:p> - For further details, please refer to the "Hardening the Linux kernel" guide. - </h:p> - </description> - <reference href="http://www.gentoo.org/doc/en/kernel-config.xml#shorthand">Gentoo Kernel Configuration Guide - Shorthand notation information</reference> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader"> - <title>Bootloader configuration</title> - <description> - <h:p> - 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. - </h:p> - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader-grub2pass"> - <title>Password protect GRUB 2</title> - <description> - <h:p> - 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. - </h:p> - <h:p> - TODO looks like this has become a lot more difficult to obtain - </h:p> - </description> - <reference href="https://help.ubuntu.com/community/Grub2/Passwords">GRUB2 Passwords (Ubuntu wiki)</reference> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader-grub1pass"> - <title>Password protect GRUB (legacy)</title> - <description> - <h:p> - 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. - </h:p> - <h:p> - This can be accomplished by inserting <h:code>password abc123</h:code> - in <h:code>/boot/grub/grub.conf</h:code> (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 <h:b>grub</h:b> - and, in the grub-shell, type <h:b>md5crypt</h:b>. - </h:p> - <h:pre> -# <h:b>grub</h:b> +<h:p> +In the repository configuration (<h:code>/etc/portage/repos.conf</h:code> or a +file inside it) <h:code>sync-uri</h:code> has to be commented out, or set to an +empty value. +</h:p> +</description> -GRUB version 0.92 (640K lower / 3072K upper memory) +<Rule id="xccdf_org.gentoo.dev.swift_rule_FEATURES-webrsync-gpg" selected="false" severity="low" weight="0.0"> +<title>FEATURES="webrsync-gpg" is set</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_FEATURES-webrsync-gpg"> +Edit /etc/portage/make.conf and make sure that 'webrsync-gpg' is in the FEATURES declaration. +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:30" href="gentoo-oval.xml" /> +</check> +</Rule> -[ Minimal BASH-like line editing is supported. ... ] +<Rule id="xccdf_org.gentoo.dev.swift_rule_PORTAGE_GPG_DIR-nonempty" selected="false" severity="low" weight="0.0"> +<title>PORTAGE_GPG_DIR is set</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_PORTAGE_GPG_DIR-nonempty"> +Edit /etc/portage/make.conf and make sure that PORTAGE_GPG_DIR is set correctly. +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:31" href="gentoo-oval.xml" /> +</check> +</Rule> -grub> <h:b>md5crypt</h:b> +</Group> -Password: <h:em>abc123</h:em> -Encrypted: $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY. +</Group> -grub> <h:b>quit</h:b></h:pre> - <h:p> - This hashed password can now be used in <h:code>grub.conf</h:code> - using <h:code>password --md5 $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.</h:code>. - </h:p> - </description> - <Rule id="xccdf_org.gentoo.dev.swift_rule_grubconf-password-md5" selected="false" severity="low" weight="6.9"> - <title>Grub legacy (if it exists) has a password entry with md5 hash</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_grubconf-password-md5"> - Edit /boot/grub/grub.conf and set a password entry with md5 hash - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:34" href="gentoo-oval.xml" /> - </check> - </Rule> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader-lilopass"> - <title>Password protect LILO</title> - <description> - <h:p> - 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. - </h:p> - <h:p> - This can be accomplished by inserting <h:code>password=abc123</h:code> - followed by <h:code>restricted</h:code> in the - <h:code>/etc/lilo.conf</h:code> file. It is also possible to do this - on a per-image level. - </h:p> - <h:pre> -password=abc123 -restricted -delay=3 +<Group id="xccdf_org.gentoo.dev.swift_group_system-kernel"> +<title>Kernel configuration</title> +<description> +<h:p> +The Linux kernel should be configured using a sane security standard in +mind. When using grSecurity, additional security-enhancing settings can +be enabled. +</h:p> +<h:p> +For further details, please refer to the "Hardening the Linux kernel" guide. +</h:p> +</description> +<reference href="http://www.gentoo.org/doc/en/kernel-config.xml#shorthand">Gentoo Kernel Configuration Guide - Shorthand notation information</reference> +</Group> -image=/boot/bzImage - read-only - password=def456 - restricted</h:pre> - <h:p> - The <h:code>restricted</h:code> 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. - </h:p> - <h:p> - Rerun <h:code>lilo</h:code> after updating the configuration file. - </h:p> - </description> - <Rule id="xccdf_org.gentoo.dev.swift_rule_liloconf-password" selected="false" severity="low" weight="6.9"> - <title>LILO (if it exists) has a password entry</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_liloconf-password"> - Edit /etc/lilo.conf and set a password entry - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:35" href="gentoo-oval.xml" /> - </check> - </Rule> - </Group> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-auth"> - <title>Authentication and authorization settings</title> - <description> - <h:p> - 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. - </h:p> - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-securetty"> - <title>Restrict root system logon</title> - <description> - <h:p> - To restrict where the root user can directly log on, edit - <h:code>/etc/securetty</h:code> and specify the supported terminals - for the root user. - </h:p> - <h:p> - When properly configured, any attempt to log on as the root user from - a non-defined terminal will result in logon failure. - </h:p> - <h:p> - A recommended setting is to only allow root user login through the - console and the physical terminals (<h:code>tty0-tty12</h:code>). - </h:p> - <h:pre> +<Group id="xccdf_org.gentoo.dev.swift_group_system-auth"> +<title>Authentication and authorization settings</title> +<description> +<h:p> +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. +</h:p> +</description> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-auth-securetty"> +<title>Restrict root system logon</title> +<description> +<h:p> +To restrict where the root user can directly log on, edit +<h:code>/etc/securetty</h:code> and specify the supported terminals +for the root user. +</h:p> +<h:p> +When properly configured, any attempt to log on as the root user from +a non-defined terminal will result in logon failure. +</h:p> +<h:p> +A recommended setting is to only allow root user login through the +console and the physical terminals (<h:code>tty0-tty12</h:code>). +</h:p> +<h:pre> console tty0 tty1 ... tty12</h:pre> - </description> - <Rule id="xccdf_org.gentoo.dev.swift_rule_securetty-limitentries" selected="false" severity="low" weight="0.0"> - <title>/etc/securetty is limited to console and tty's</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_securetty-limitentries"> - Edit /etc/securetty and make sure only 'console' and 'tty[0-9]*' are defined. - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:32" href="gentoo-oval.xml" /> - </check> - </Rule> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-userlogin"> - <title>Allow only known users to login</title> - <description> - <h:p> - When PAM is enabled, the <h:code>/etc/security/access.conf</h:code> - file is used to check which users are allowed to log on and not - (through the <h:b>login</h:b> application). These limits are based on - username, group and host, network or tty that the user is trying to - log on from. - </h:p> - <h:p> - By enabling these settings, the risk is reduced that a functional - account (say <h:code>apache</h:code>) is abused to log on with, or - that a new account is created as part of an exploit. - </h:p> - <h:p> - The following example setting allows only local root logins on tty1, - and only the <h:em>swift</h:em> account to log on on the system. - </h:p> - <h:pre> +</description> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_securetty-limitentries" selected="false" severity="low" weight="0.0"> +<title>/etc/securetty is limited to console and tty's</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_securetty-limitentries"> +Edit /etc/securetty and make sure only 'console' and 'tty[0-9]*' are defined. +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:32" href="gentoo-oval.xml" /> +</check> +</Rule> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-auth-userlogin"> +<title>Allow only known users to login</title> +<description> +<h:p> +When PAM is enabled, the <h:code>/etc/security/access.conf</h:code> +file is used to check which users are allowed to log on and not +(through the <h:b>login</h:b> application). These limits are based on +username, group and host, network or tty that the user is trying to +log on from. +</h:p> +<h:p> +By enabling these settings, the risk is reduced that a functional +account (say <h:code>apache</h:code>) is abused to log on with, or +that a new account is created as part of an exploit. +</h:p> +<h:p> +The following example setting allows only local root logins on tty1, +and only the <h:em>swift</h:em> account to log on on the system. +</h:p> +<h:pre> + : root : tty1 - : ALL EXCEPT swift : ALL - </h:pre> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-resources"> - <title>Restrict user resources</title> - <description> - <h:p> - 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. - </h:p> - <h:p> - In Gentoo Linux, the following methods are available to limit - resources. - </h:p> - <h:ul> - <h:li> - <h:code>/etc/security/limits.conf</h:code> defines the - resource limits for logins that are done through a PAM-aware - component (default in our setup) - </h:li> - <h:li> - <h:code>/etc/limits</h:code> defines the resource limits for - logins that are done through login programs that are not - PAM-aware. - </h:li> - </h:ul> - <h:p> - Generally, it should suffice to set up - <h:code>/etc/security/limits.conf</h:code>, which is the configuration - file used by the <h:code>pam_limits.so</h:code> module. - </h:p> - <h:p> - Note that the settings are applicable on a <h:em>per login - session</h:em> basis. - </h:p> - <h:p> - More information on these files and their syntax can be obtained - through their manual pages. - </h:p> - <h:pre> +</h:pre> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-auth-resources"> +<title>Restrict user resources</title> +<description> +<h:p> +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. +</h:p> +<h:p> +In Gentoo Linux, the following methods are available to limit +resources. +</h:p> +<h:ul> +<h:li> +<h:code>/etc/security/limits.conf</h:code> defines the +resource limits for logins that are done through a PAM-aware +component (default in our setup) +</h:li> +<h:li> +<h:code>/etc/limits</h:code> defines the resource limits for +logins that are done through login programs that are not +PAM-aware. +</h:li> +</h:ul> +<h:p> +Generally, it should suffice to set up +<h:code>/etc/security/limits.conf</h:code>, which is the configuration +file used by the <h:code>pam_limits.so</h:code> module. +</h:p> +<h:p> +Note that the settings are applicable on a <h:em>per login +session</h:em> basis. +</h:p> +<h:p> +More information on these files and their syntax can be obtained +through their manual pages. +</h:p> +<h:pre> # <h:b>man limits.conf</h:b> # <h:b>man limits</h:b></h:pre> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-password"> - <title>Enforce password policy</title> - <description> - <h:p> - 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. - </h:p> - <h:p> - Enforcing password policies is (partially) part of the - <h:code>sys-apps/shadow</h:code> package (which is installed by - default) and can be configured through the - <h:code>/etc/login.defs</h:code> file. This file is well documented - (using comments) and it has a full manual page as well. - </h:p> - <h:p> - A second important player when dealing with password policies is the - <h:code>pam_cracklib.so</h:code> library. This can be used in the - appropriate <h:code>/etc/pam.d/*</h:code> files. For instance, for the - <h:code>/etc/pam.d/passwd</h:code> definition: - </h:p> - <h:pre> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-auth-password"> +<title>Enforce password policy</title> +<description> +<h:p> +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. +</h:p> +<h:p> +Enforcing password policies is (partially) part of the +<h:code>sys-apps/shadow</h:code> package (which is installed by +default) and can be configured through the +<h:code>/etc/login.defs</h:code> file. This file is well documented +(using comments) and it has a full manual page as well. +</h:p> +<h:p> +A second important player when dealing with password policies is the +<h:code>pam_cracklib.so</h:code> library. This can be used in the +appropriate <h:code>/etc/pam.d/*</h:code> files. For instance, for the +<h:code>/etc/pam.d/passwd</h:code> definition: +</h:p> +<h:pre> auth required pam_unix.so shadow nullok account required pam_unix.so <h:b>password required pam_cracklib.so difok=3 retry=3 \ - minlen=8 dcredit=-2 \ - ocredit=-2</h:b> +minlen=8 dcredit=-2 \ +ocredit=-2</h:b> password required pam_unix.so md5 use_authok session required pam_unix.so</h:pre> - <h:p> - 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. - </h:p> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-ripper"> - <title>Review password strength regularly</title> - <description> - <h:p> - Regularly check the strength of the users' passwords. There are tools - out there, like <h:code>app-crypt/johntheripper</h:code> which, given - a <h:code>/etc/shadow</h:code> file (or sometimes even LDAP dump) try - to find the passwords for the users. - </h:p> - <h:p> - 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. - </h:p> - </description> - </Group> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-session"> - <title>Session settings</title> - <description> - <h:p> - Unlike authentication and authorization settings, a <h:em>session</h:em> - setting is one that is applicable to an authenticated and authorized - user when he is logged on to the system. - </h:p> - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_system-session-mesg"> - <title>Disable access to user terminals</title> - <description> - <h:p> - By default, user terminals are accessible by others to write messages - to (using <h:b>write</h:b>, <h:b>wall</h:b> or <h:b>talk</h:b>). It is - adviseable to disable this unless explicitly necessary. - </h:p> - <h:p> - Messages can confuse users and trick them into performing malicious - actions. - </h:p> - <h:p> - This can be disabled by setting <h:code>mesg n</h:code> in - <h:code>/etc/profile</h:code>. A user-friendly method for doing so in - Gentoo is to create a file <h:code>/etc/profile.d/disable_mesg</h:code> which - contains this command. - </h:p> - </description> - </Group> - </Group> - <Group id="xccdf_org.gentoo.dev_group_system-fileprivileges"> - <title>File and directory privileges and integrity</title> - <description> - 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. - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-worldrw"> - <title>Limit world writable files and locations</title> - <description> - <h:p> - 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 <h:code>/tmp</h:code>). - </h:p> - <h:p> - Use <h:code>find</h:code> to locate such files or directories. - </h:p> - <h:pre> +<h:p> +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. +</h:p> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-auth-ripper"> +<title>Review password strength regularly</title> +<description> +<h:p> +Regularly check the strength of the users' passwords. There are tools +out there, like <h:code>app-crypt/johntheripper</h:code> which, given +a <h:code>/etc/shadow</h:code> file (or sometimes even LDAP dump) try +to find the passwords for the users. +</h:p> +<h:p> +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. +</h:p> +</description> +</Group> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-session"> +<title>Session settings</title> +<description> +<h:p> +Unlike authentication and authorization settings, a <h:em>session</h:em> +setting is one that is applicable to an authenticated and authorized +user when he is logged on to the system. +</h:p> +</description> +<Group id="xccdf_org.gentoo.dev.swift_group_system-session-mesg"> +<title>Disable access to user terminals</title> +<description> +<h:p> +By default, user terminals are accessible by others to write messages +to (using <h:b>write</h:b>, <h:b>wall</h:b> or <h:b>talk</h:b>). It is +adviseable to disable this unless explicitly necessary. +</h:p> +<h:p> +Messages can confuse users and trick them into performing malicious +actions. +</h:p> +<h:p> +This can be disabled by setting <h:code>mesg n</h:code> in +<h:code>/etc/profile</h:code>. A user-friendly method for doing so in +Gentoo is to create a file <h:code>/etc/profile.d/disable_mesg</h:code> which +contains this command. +</h:p> +</description> +</Group> + +</Group> + +<Group id="xccdf_org.gentoo.dev_group_system-fileprivileges"> +<title>File and directory privileges and integrity</title> +<description> +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. +</description> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-worldrw"> +<title>Limit world writable files and locations</title> +<description> +<h:p> +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 <h:code>/tmp</h:code>). +</h:p> +<h:p> +Use <h:code>find</h:code> to locate such files or directories. +</h:p> +<h:pre> # <h:b>find / -perm +o=w ! \( -type d -perm +o=t \) ! -type l -print</h:b></h:pre> - <h:p> - 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). - </h:p> - </description> - <Rule id="xccdf_org.gentoo.dev.swift_rule_worldwritedir-stickybit" selected="false" severity="medium" weight="4.3"> - <title>All world writable directories have the sticky bit set</title> - <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_worldwritedirs-stickybit"> - Make sure all world-writable directories have the sticky bit set - </fixtext> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref name="oval:org.gentoo.dev.swift:def:36" href="gentoo-oval.xml" /> - </check> - </Rule> - - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-suidsgid"> - <title>Limit setuid and setgid file and directory usage</title> - <description> - <h:p> - The <h:em>setuid</h:em> and <h:em>setgid</h:em> 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. - </h:p> - <h:p> - 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 <h:b>su</h:b> or - <h:b>sudo</h:b>. - </h:p> - <h:p> - 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. - </h:p> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-caps"> - <title>Limit capability enabled files</title> - <description> - <h:p> - Capabilities within Linux allow users to perform certain privileged tasks. - </h:p> - <h:p> - Unlike <h:em>setuid</h:em> 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 <h:em>setuid</h:em> - binaries). - </h:p> - <h:p> - Files with particular capabilities set (through the <h:b>setcap</h:b> - application) should be regularly reviewed. Capability-enabled files - can be found through the following command: - </h:p> - <h:pre> +<h:p> +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). +</h:p> +</description> + +<Rule id="xccdf_org.gentoo.dev.swift_rule_worldwritedir-stickybit" selected="false" severity="medium" weight="4.3"> +<title>All world writable directories have the sticky bit set</title> +<fixtext fixref="xccdf_org.gentoo.dev.swift_fix_worldwritedirs-stickybit"> +Make sure all world-writable directories have the sticky bit set +</fixtext> +<check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> +<check-content-ref name="oval:org.gentoo.dev.swift:def:36" href="gentoo-oval.xml" /> +</check> +</Rule> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-suidsgid"> +<title>Limit setuid and setgid file and directory usage</title> +<description> +<h:p> +The <h:em>setuid</h:em> and <h:em>setgid</h:em> 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. +</h:p> +<h:p> +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 <h:b>su</h:b> or +<h:b>sudo</h:b>. +</h:p> +<h:p> +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. +</h:p> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-caps"> +<title>Limit capability enabled files</title> +<description> +<h:p> +Capabilities within Linux allow users to perform certain privileged tasks. +</h:p> +<h:p> +Unlike <h:em>setuid</h:em> 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 <h:em>setuid</h:em> +binaries). +</h:p> +<h:p> +Files with particular capabilities set (through the <h:b>setcap</h:b> +application) should be regularly reviewed. Capability-enabled files +can be found through the following command: +</h:p> +<h:pre> # <h:b>getcap -r /</h:b> - </h:pre> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-logs"> - <title>Logs only readable by proper group</title> - <description> - No log file in <h:code>/var/log</h:code> should be world readable. Log - files should be limited by particular groups (either the group - representing the service, like <h:code>apache</h:code> or - <h:code>portage</h:code>, or a specific administrative group like - <h:code>wheel</h:code>). - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-rootonly"> - <title>Files only used by root should be root-only</title> - <description> - <h:p> - Some files, like <h:code>/etc/shadow</h:code>, are meant to be read - (and perhaps modified) by root only. These files should never have - privileges for group- or others. - </h:p> - <h:p> - A nonexhaustive list of such files is: - </h:p> - <h:ul> - <h:li> - <h:code>/etc/shadow</h:code> which contains account password - information (including password hashes) - </h:li> - <h:li> - <h:code>/etc/securetty</h:code> which contains the list of - terminals where root is allowed to log on from - </h:li> - </h:ul> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-hids"> - <title>Review file integrity regularly</title> - <description> - Deploy intrusion detection tool(s) to validate the integrity and - privileges on important files. <h:code>app-forensics/aide</h:code> is - an example of such a tool. - </description> - </Group> - </Group> - </Group> <!-- system --> - <Group id="xccdf_org.gentoo.dev.swift_group_data"> - <title>Data flows</title> - <description> - 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. - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_data-backup"> - <title>Backup the data</title> - <description> - 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. - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_data-backup-automate"> - <title>Automated backups</title> - <description> - <h:p> - Automate backups on the system. If the backups are performed manually - then they are done wrong and someone will eventually forget it. - </h:p> - <h:p> - Use scheduling software like <h:code>cron</h:code> to - automatically take backups on regular intervals, or use a central - backup solution like <h:code>bacula</h:code>. - </h:p> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-coverage"> - <title>Full data coverage</title> - <description> - 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. - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-history"> - <title>Retention</title> - <description> - <h:p> - 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. - </h:p> - <h:p> - 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. - </h:p> - <h:p> - In most cases, introduce a "layered" approach on retention. For instance: - </h:p> - <h:ul> - <h:li>keep daily backups for a week</h:li> - <h:li> - keep weekly backups (say each monday backup) for a month - </h:li> - <h:li> - keep monthly backups (say each first monday) for a year - </h:li> - <h:li> - keep yearly backups for 30 years - </h:li> - </h:ul> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-location"> - <title>Off-site backups</title> - <description> - <h:p> - 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). - </h:p> - <h:p> - Also ensure that the backups are stored securely. If necessary, - encrypt the backups. - </h:p> - </description> - </Group> - <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-validate"> - <title>Validate and test</title> - <description> - 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. - </description> - </Group> - </Group> - </Group> <!-- Data flows --> - <Group id="xccdf_org.gentoo.dev.swift_group_removal"> - <title>Decommissioning servers</title> - <description> - When a server needs to be decommissioned, make sure that its data - is safeguarded from future extraction. - </description> - <Group id="xccdf_org.gentoo.dev.swift_group_removal-wipedisk"> - <title>Wipe disks</title> - <description> - <h:p> - Clear all data from the disks on the server in a secure manner. - Applications like <h:b>shred</h:b> (part of - <h:code>sys-apps/coreutils</h:code>) can be used to security wipe data - or even entire partitions or disks. - </h:p> - <h:p> - 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. - </h:p> - </description> - <reference href="http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf">NIST Publication "Guidelines for Media Sanitization" (PDF)</reference> - </Group> - </Group> <!-- Removal --> +</h:pre> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-logs"> +<title>Logs only readable by proper group</title> +<description> +No log file in <h:code>/var/log</h:code> should be world readable. Log +files should be limited by particular groups (either the group +representing the service, like <h:code>apache</h:code> or +<h:code>portage</h:code>, or a specific administrative group like +<h:code>wheel</h:code>). +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-rootonly"> +<title>Files only used by root should be root-only</title> +<description> +<h:p> +Some files, like <h:code>/etc/shadow</h:code>, are meant to be read +(and perhaps modified) by root only. These files should never have +privileges for group- or others. +</h:p> +<h:p> +A nonexhaustive list of such files is: +</h:p> +<h:ul> +<h:li> +<h:code>/etc/shadow</h:code> which contains account password +information (including password hashes) +</h:li> +<h:li> +<h:code>/etc/securetty</h:code> which contains the list of +terminals where root is allowed to log on from +</h:li> +</h:ul> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-hids"> +<title>Review file integrity regularly</title> +<description> +Deploy intrusion detection tool(s) to validate the integrity and +privileges on important files. <h:code>app-forensics/aide</h:code> is +an example of such a tool. +</description> +</Group> + +</Group> + +</Group> <!-- system --> + +<Group id="xccdf_org.gentoo.dev.swift_group_hardening"> +<title>Hardening and risk mitigation</title> +<description> +<h:p> +This chapter focuses on additional hardening instructions and risk mitigation. Unlike the previous +chapters, this one focuses on <h:em>additional software</h:em> and configuration concerns rather than +tuning and tweaking existing ones. +</h:p> +</description> + +<Group id="xccdf_org.gentoo.dev.swift_group_hardening-secureboot"> +<title>SecureBoot</title> +<description> +<h:p> +TODO +</h:p> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_hardening-firewall"> +<title>Firewall</title> +<description> +<h:p> +TODO: Firewall +</h:p> +</description> +</Group> + +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_data"> +<title>Data flows</title> +<description> +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. +</description> + +<Group id="xccdf_org.gentoo.dev.swift_group_data-backup"> +<title>Backup the data</title> +<description> +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. +</description> + +<Group id="xccdf_org.gentoo.dev.swift_group_data-backup-automate"> +<title>Automated backups</title> +<description> +<h:p> +Automate backups on the system. If the backups are performed manually +then they are done wrong and someone will eventually forget it. +</h:p> +<h:p> +Use scheduling software like <h:code>cron</h:code> to +automatically take backups on regular intervals, or use a central +backup solution like <h:code>bacula</h:code>. +</h:p> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_data-backups-coverage"> +<title>Full data coverage</title> +<description> +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. +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_data-backups-history"> +<title>Retention</title> +<description> +<h:p> +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. +</h:p> +<h:p> +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. +</h:p> +<h:p> +In most cases, introduce a "layered" approach on retention. For instance: +</h:p> +<h:ul> +<h:li>keep daily backups for a week</h:li> +<h:li> +keep weekly backups (say each monday backup) for a month +</h:li> +<h:li> +keep monthly backups (say each first monday) for a year +</h:li> +<h:li> +keep yearly backups for 30 years +</h:li> +</h:ul> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_data-backups-location"> +<title>Off-site backups</title> +<description> +<h:p> +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). +</h:p> +<h:p> +Also ensure that the backups are stored securely. If necessary, +encrypt the backups. +</h:p> +</description> +</Group> + +<Group id="xccdf_org.gentoo.dev.swift_group_data-backups-validate"> +<title>Validate and test</title> +<description> +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. +</description> +</Group> + +</Group> + +</Group> <!-- Data flows --> + +<Group id="xccdf_org.gentoo.dev.swift_group_removal"> +<title>Decommissioning servers</title> +<description> +When a server needs to be decommissioned, make sure that its data +is safeguarded from future extraction. +</description> + +<Group id="xccdf_org.gentoo.dev.swift_group_removal-wipedisk"> +<title>Wipe disks</title> +<description> +<h:p> +Clear all data from the disks on the server in a secure manner. +Applications like <h:b>shred</h:b> (part of +<h:code>sys-apps/coreutils</h:code>) can be used to security wipe data +or even entire partitions or disks. +</h:p> +<h:p> +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. +</h:p> +</description> +<reference href="http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf">NIST Publication "Guidelines for Media Sanitization" (PDF)</reference> +</Group> + +</Group> <!-- Removal --> + </Benchmark> |