diff options
-rw-r--r-- | xml/SCAP/gentoo-oval.xml | 55 | ||||
-rw-r--r-- | xml/SCAP/gentoo-xccdf.xml | 381 |
2 files changed, 252 insertions, 184 deletions
diff --git a/xml/SCAP/gentoo-oval.xml b/xml/SCAP/gentoo-oval.xml index 4fe52b9..8cc1398 100644 --- a/xml/SCAP/gentoo-oval.xml +++ b/xml/SCAP/gentoo-oval.xml @@ -396,6 +396,37 @@ <criterion test_ref="oval:org.gentoo.dev.swift:tst:23" comment="/etc/inittab single user settings refers only to '/sbin/rc single' or '/sbin/sulogin'" /> </criteria> </definition> + + <definition id="oval:org.gentoo.dev.swift:def:23" version="1" class="compliance"> + <metadata> + <title>Verify that /etc/hosts.allow exists</title> + <affected family="unix"> + <platform>Gentoo Linux</platform> + </affected> + <description> + This definition tests if /etc/hosts.allow exists. + </description> + </metadata> + <criteria> + <criterion test_ref="oval:org.gentoo.dev.swift:tst:24" comment="/etc/hosts.allow exists" /> + </criteria> + </definition> + + <definition id="oval:org.gentoo.dev.swift:def:24" version="1" class="compliance"> + <metadata> + <title>Verify that /etc/at/at.allow exists</title> + <affected family="unix"> + <platform>Gentoo Linux</platform> + </affected> + <description> + This definition tests if /etc/at/at.allow exists. + </description> + </metadata> + <criteria> + <criterion test_ref="oval:org.gentoo.dev.swift:tst:25" comment="/etc/at/at.allow exists" /> + </criteria> + </definition> + </definitions> <tests> @@ -587,6 +618,20 @@ <ind-def:state state_ref="oval:org.gentoo.dev.swift:ste:6" /> </ind-def:textfilecontent54_test> + <unix-def:file_test id="oval:org.gentoo.dev.swift:tst:24" + version="1" check="all" check_existence="all_exist" + comment="Tests that /etc/hosts.allow exists"> + <!-- The /etc/hosts.allow file --> + <unix-def:object object_ref="oval:org.gentoo.dev.swift:obj:14" /> + </unix-def:file_test> + + <unix-def:file_test id="oval:org.gentoo.dev.swift:tst:25" + version="1" check="all" check_existence="all_exist" + comment="Tests that /etc/at/at.allow exists"> + <!-- The /etc/at/at.allow file --> + <unix-def:object object_ref="oval:org.gentoo.dev.swift:obj:15" /> + </unix-def:file_test> + </tests> <objects> @@ -664,6 +709,16 @@ <ind-def:instance operation="greater than or equal" datatype="int">1</ind-def:instance> </ind-def:textfilecontent54_object> + <unix-def:file_object id="oval:org.gentoo.dev.swift:obj:14" + version="1" comment="The /etc/hosts.allow file"> + <unix-def:filepath>/etc/hosts.allow</unix-def:filepath> + </unix-def:file_object> + + <unix-def:file_object id="oval:org.gentoo.dev.swift:obj:15" + version="1" comment="The /etc/at/at.allow file"> + <unix-def:filepath>/etc/at/at.allow</unix-def:filepath> + </unix-def:file_object> + </objects> <states> diff --git a/xml/SCAP/gentoo-xccdf.xml b/xml/SCAP/gentoo-xccdf.xml index bc6d977..6b3172e 100644 --- a/xml/SCAP/gentoo-xccdf.xml +++ b/xml/SCAP/gentoo-xccdf.xml @@ -71,6 +71,11 @@ <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" /> + </Profile> <Group id="xccdf_org.gentoo.dev.swift_group_intro"> <title>Introduction</title> @@ -161,14 +166,14 @@ To validate the tests, the following commands can be used: <h:pre># <h:b>oscap xccdf eval --profile xccdf_org.gentoo.dev.swift_profile_default gentoo-xccdf.xml</h:b></h:pre> <h:br /> - To generate a full report in HTML as well, you can use the next command: + To generate a full report in HTML as well, use the next command: <h:pre># <h:b>oscap xccdf eval --profile xccdf_org.gentoo.dev.swift_profile_default --results xccdf-results.xml --report report.html gentoo-xccdf.xml</h:b></h:pre> <h:br /> <h:br /> 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. We will try to document the reasoning behind - the settings but you are free to deviate from them. If that is the case, + 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. </description> @@ -278,9 +283,9 @@ Before we start deploying Gentoo Linux and start hardening it, it is wise to take a step back and think about what we want to accomplish. Setting up a more secured Gentoo Linux isn't a goal, but a means to reach - something. Most likely, you are considering setting up a Gentoo Linux - powered server. What is this server for? Where will you put it? What other - services will you want to run on the same OS? Etc. + 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> @@ -298,10 +303,10 @@ <h:br /> Security is about reducing risks, not about harassing people or making work for a system administrator harder. And reducing risks also means - that you need to keep a clear eye out on your architecture and all its - components. If you do not know what you are integrating, where you are - putting it or why, then you have more issues to consider than hardening - a system. + 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. </description> </Group> <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-requirements"> @@ -406,7 +411,7 @@ Let's start with the disadvantages: <h:ul> <h:li> - Separate file systems mean that you need to do better disk space control + 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 @@ -548,7 +553,7 @@ <Group id="xccdf_org.gentoo.dev.swift_group_installation-toolchain"> <title>Use a Hardened Toolchain</title> <description> - When you install Gentoo, use the hardened stages and hardened toolchain. + When Gentoo is installed, use the hardened stages and hardened toolchain. The hardened toolchain includes additional security patches, such as support for non-executable program stacks and buffer overflow detection. <h:br /> @@ -839,19 +844,18 @@ mount -o remount,noexec /dev/shm <title>Disk quota support</title> <description> Most file systems support the notion of <h:em>quotas</h:em> - limits - on the amount of data / files you are allowed to have on that - particular file system. + on the amount of data / files that are allowed on that particular file system. <h:br /> <h:br /> - To enable quotas, first configure your Linux kernel to include + To enable quotas, first configure the Linux kernel to include <h:code>CONFIG_QUOTA</h:code>. <h:br /> <h:br /> Next, install the <h:code>sys-fs/quota</h:code> package. <h:pre># <h:b>emerge quota</h:b></h:pre> Then add <h:code>usrquota</h:code> and <h:code>grpquota</h:code> to - the partitions (in <h:code>/etc/fstab</h:code>) where you want to - enable quotas on. For instance, the following snippet from + 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:pre>/dev/mapper/volgrp-home /home ext4 noatime,nodev,nosuid,<h:b>usrquota,grpquota</h:b> 0 0 @@ -861,8 +865,8 @@ mount -o remount,noexec /dev/shm <h:pre> # <h:b>rc-update add quota boot</h:b></h:pre> Reboot the system so that the partitions are mounted with the correct - mount options and that the quota service is running. Then you can - setup quotas for users and groups. + mount options and that the quota service is running. Then the quotas for + users and groups can be set up. </description> <reference href="http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch28_:_Managing_Disk_Usage_with_Quotas">Managing @@ -970,7 +974,9 @@ sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf </Rule> <Rule id="xccdf_org.gentoo.dev.swift_rule_inittab-sulogin" selected="false" severity="medium" weight="6.0"> <title>Test if 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</fixtext> + <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> @@ -990,49 +996,82 @@ sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf More information on the format of these files can be obtained through <h:b>man 5 hosts_access</h:b>. </description> + <Rule id="xccdf_org.gentoo.dev.swift_rule_hostsallow-exists" selected="false" severity="info" weight="0.0"> + <title>Tests if /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> + <title>SSH service</title> <description> 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 to proper hardening is definitely in place. + systems so proper hardening is definitely in place. <h:br /> <h:br /> Please use the "Hardening OpenSSH" guide for the necessary instructions. </description> </Group> <Group id="xccdf_org.gentoo.dev.swift_group_system-services-cron"> - <title>Cron Service</title> + <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> + <title>Only allow trusted accounts cron access</title> <description> - Only allow trusted accounts to use cron. You should list trusted - accounts in <h:code>/etc/cron.allow</h:code>. + Only allow trusted accounts to use cron. How to achieve this depends on the cron service + installed. + <h:br /> + <h:br /> + If vixie-cron is installed, then have (only) those users that need cron access take part in the + <h:em>cron</h:em> unix group. + <h:br /> + <h:br /> + 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. </description> </Group> </Group> <Group id="xccdf_org.gentoo.dev.swift_group_system-services-at"> - <title>At Service</title> + <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> + <title>Only allow trusted accounts at access</title> <description> - Only allow trusted accounts to use at. You should list trusted - accounts in <h:code>/etc/at.allow</h:code>. + 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:br /> + <h:br /> + The format of these files is one username per line. </description> + <Rule id="xccdf_org.gentoo.dev.swift_rule_atallow-exists" selected="false" severity="low" weight="0.0"> + <title>Tests if /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> + <title>NTP service</title> <description> With NTP, systems can synchronise their clocks, ensuring correct date and time information. This is important as huge clock drift could @@ -1040,26 +1079,21 @@ sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf commands. </description> <Group id="xccdf_org.gentoo.dev.swift_group_system-services-ntp-sync"> - <title>Synchronise The System Clock</title> + <title>Synchronise the system clock</title> <description> - Synchronise your systems' clock with an authorative NTP server, and - use the same NTP service for all your systems. + Synchronise the systems' clock with an authorative NTP server, and + use the same NTP service for all other systems. <h:br /> <h:br /> - You can accomplish this by regularly executing <h:b>ntpdate</h:b>, - but you can also use a service like <h:code>net-misc/ntp</h:code>'s + 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>. </description> </Group> </Group> </Group> - </Group> <!-- system --> - <!-- - <Group id="gt-system-services"> - - </Group> - <Group id="gt-system-portage"> - <title>Portage Settings</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-portage"> + <title>Portage settings</title> <description> The package manager of any system is a very important tool. It is responsible for handling proper software deployments, but also offers @@ -1068,11 +1102,11 @@ sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf <h:br /> 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 you use Portage as + secure environment within Portage (assuming that Portage is used as package manager) are important. </description> - <Group id="gt-system-portage-use"> - <title>USE Flags</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-portage-use"> + <title>USE flags</title> <description> USE flags in Gentoo are used to tune the functionality of many components and enable or disable features. @@ -1101,7 +1135,7 @@ sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf <h:br /> 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 you to identify allowed (and denied) hosts or + mechanism which allows configuring allowed (and denied) hosts or network segments on application level. <h:br /> <h:br /> @@ -1111,26 +1145,24 @@ sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf client-certificate based authentication mechanism. <h:br /> <h:br /> - You should set the USE flags globally in - <h:code>/etc/make.conf</h:code>. + Set the USE flags globally in <h:code>/etc/portage/make.conf</h:code> + so they are applicable to all installed software. <h:br /> - <h:pre> -USE="... pam tcpd ssl"</h:pre> + <h:pre>USE="... pam tcpd ssl"</h:pre> </description> </Group> - <Group id="gt-system-portage-webrsync"> - <title>Fetching Signed Portage Tree</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-portage-webrsync"> + <title>Fetching signed portage tree</title> <description> 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 you can find the instructions again: - <h:pre> -# <h:b>mkdir -p /etc/portage/gpg</h:b> + but as it is quite easy, here are the instructions again: + <h:pre># <h:b>mkdir -p /etc/portage/gpg</h:b> # <h:b>chmod 0700 /etc/portage/gpg</h:b> -# <h:b>gpg - -homedir /etc/portage/gpg - -keyserver subkeys.pgp.net - -recv-keys 0x239C75C4 0x96D8BF6D</h:b> -# <h:b>gpg - -homedir /etc/portage/gpg - -edit-key 0x239C75C4 trust</h:b> -# <h:b>gpg - -homedir /etc/portage/gpg - -edit-key 0x96D8BF6D trust</h:b></h:pre> - After this, you can edit <h:code>/etc/make.conf</h:code>: +# <h:b>gpg --homedir /etc/portage/gpg --keyserver subkeys.pgp.net --recv-keys 0x239C75C4 0x96D8BF6D</h:b> +# <h:b>gpg --homedir /etc/portage/gpg --edit-key 0x239C75C4 trust</h:b> +# <h:b>gpg --homedir /etc/portage/gpg --edit-key 0x96D8BF6D trust</h:b></h:pre> + After this, edit <h:code>/etc/portage/make.conf</h:code>: <h:pre> FEATURES="webrsync-gpg" PORTAGE_GPG_DIR="/etc/portage/gpg" @@ -1138,42 +1170,40 @@ SYNC=""</h:pre> </description> </Group> </Group> - <Group id="gt-system-kernel"> - <title>Kernel Configuration</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-kernel"> + <title>Kernel configuration</title> <description> The Linux kernel should be configured using a sane security standard in mind. When using grSecurity, additional security-enhancing settings can be enabled. <h:br /> <h:br /> - For further details, I refer to the "Hardening the Linux kernel" guide. + For further details, please refer to the "Hardening the Linux kernel" guide. </description> <reference href="http://www.gentoo.org/doc/en/kernel-config.xml#shorthand">Gentoo Kernel Configuration Guide - Shorthand notation information</reference> </Group> - <Group id="gt-system-bootloader"> - <title>Bootloader Configuration</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader"> + <title>Bootloader configuration</title> <description> 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. </description> - <Group id="gt-system-bootloader-grubpass"> - <title>Password Protect GRUB</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader-grub1pass"> + <title>Password protect GRUB (legacy)</title> <description> It is recommended to password-protect the GRUB configuration so that - you cannot modify boot options during a boot without providing the + the boot options cannot be modified during a boot without providing the valid password. <h:br /> <h:br /> - You can accomplish this by inserting <h:code>password abc123</h:code> + 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 if you do not like having a clear-text password in - the configuration file, you can hash it. Just start <h:b>grub</h:b> + 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:br /> - <h:pre> -# <h:b>grub</h:b> + <h:pre># <h:b>grub</h:b> GRUB version 0.92 (640K lower / 3072K upper memory) @@ -1186,26 +1216,24 @@ Encrypted: $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY. grub> <h:b>quit</h:b></h:pre> <h:br /> - You can then use this hashed password in <h:code>grub.conf</h:code> - using <h:code>password - -md5 - $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.</h:code>. + 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>. </description> </Group> - <Group id="gt-system-bootloader-lilopass"> - <title>Password Protect LILO</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader-lilopass"> + <title>Password protect LILO</title> <description> It is recommended to password-protect the LILO configuration so that - you cannot modify boot options during a boot without providing the - valid password. + modifying the boot options during a boot without providing the + valid password is not possible. <h:br /> <h:br /> - You can accomplish this by inserting <h:code>password=abc123</h:code> + 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:br /> - <h:pre> -password=abc123 + <h:pre>password=abc123 restricted delay=3 @@ -1223,8 +1251,8 @@ image=/boot/bzImage </description> </Group> </Group> - <Group id="gt-system-auth"> - <title>Authentication and Authorization Settings</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-auth"> + <title>Authentication and authorization settings</title> <description> An important part in a servers' security is its authentication and authorization support. We have already described how to build in PAM @@ -1232,8 +1260,8 @@ image=/boot/bzImage authorization settings are mode than just compiling in the necessary functionality. </description> - <Group id="gt-system-auth-securetty"> - <title>Restrict root System Logon</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-securetty"> + <title>Restrict root system logon</title> <description> To restrict where the root user can directly log on, edit <h:code>/etc/securetty</h:code> and specify the supported terminals @@ -1246,16 +1274,15 @@ image=/boot/bzImage <h:br /> A recommended setting is to only allow root user login through the console and the physical terminals (<h:code>tty0-tty12</h:code>). - <h:pre> -console + <h:pre>console tty0 tty1 ... tty12</h:pre> </description> </Group> - <Group id="gt-system-auth-userlogin"> - <title>Allow Only Known Users to Login</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-userlogin"> + <title>Allow only known users to login</title> <description> 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 @@ -1264,13 +1291,13 @@ tty12</h:pre> log on from. <h:br /> <h:br /> - By enabling these settings, you reduce the risk that a functional + 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. </description> </Group> - <Group id="gt-system-auth-resources"> - <title>Restrict User Resources</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-resources"> + <title>Restrict user resources</title> <description> When facing a DoS (Denial-of-Service) attack, reducing the impact of the attack can be done by limited resource consumption. Although the @@ -1293,7 +1320,7 @@ tty12</h:pre> PAM-aware. </h:li> </h:ul> - Generally, you should suffice with setting + 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:br /> @@ -1309,8 +1336,8 @@ tty12</h:pre> # <h:b>man limits</h:b></h:pre> </description> </Group> - <Group id="gt-system-auth-password"> - <title>Enforce Password Policy</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-password"> + <title>Enforce password policy</title> <description> Usually most organizations have a password policy, telling their users how long their passwords should be and how often the passwords should @@ -1322,16 +1349,14 @@ tty12</h:pre> <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 to help you en - route. + (using comments) and it has a full manual page as well. <h:br /> <h:br /> A second important player when dealing with password policies is the - <h:code>pam_cracklib.so</h:code> library. You can then use this in 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:pre> -auth required pam_unix.so shadow nullok + <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> password required pam_unix.so md5 use_authok @@ -1341,10 +1366,10 @@ session required pam_unix.so</h:pre> password, contain 2 digits and 2 non-alphanumeric characters. </description> </Group> - <Group id="gt-system-auth-ripper"> - <title>Review Password Strength Regularly</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-ripper"> + <title>Review password strength regularly</title> <description> - Regularly check the strength of your users' passwords. There are tools + 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. @@ -1356,15 +1381,15 @@ session required pam_unix.so</h:pre> </description> </Group> </Group> - <Group id="gt-system-session"> - <title>Session Settings</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-session"> + <title>Session settings</title> <description> 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. </description> - <Group id="gt-system-session-mesg"> - <title>Disable Access to User Terminals</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-session-mesg"> + <title>Disable access to user terminals</title> <description> 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 @@ -1375,45 +1400,37 @@ session required pam_unix.so</h:pre> actions. <h:br /> <h:br /> - You can disable this by setting <h:code>mesg n</h:code> in + 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. </description> </Group> </Group> - <Group id="gt-system-fileprivileges"> - <title>File and Directory Privileges and Integrity</title> + <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="gt-system-fileprivileges-worldrw"> - <title>Limit World Writable Files and Locations</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-worldrw"> + <title>Limit world writable files and locations</title> <description> Limit (or even remove) the use of world writable files and locations. - If a directory is world writable, you probably want to have the + 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:br /> <h:br /> - You can use <h:code>find</h:code> to locate such files or directories. - <h:pre> -# <h:b>find / -perm +o=w ! \( -type d -perm +o=t \) ! -type l -print</h:b></h:pre> + Use <h:code>find</h:code> to locate such files or directories. + <h:pre># <h:b>find / -perm +o=w ! \( -type d -perm +o=t \) ! -type l -print</h:b></h:pre> 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). </description> - <Rule id="rule-world-writeable-sticky" selected="false"> - <title>World writeable directories must have sticky bit set</title> - <description>World writeable directories must have sticky bit set</description> - <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5"> - <check-content-ref href="gentoo-oval.xml" name="oval:@@OVALNS@@.static:def:2" /> - </check> - </Rule> </Group> - <Group id="gt-system-fileprivileges-suidsgid"> - <title>Limit Setuid and Setgid File and Directory Usage</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-suidsgid"> + <title>Limit setuid and setgid file and directory usage</title> <description> 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 @@ -1433,8 +1450,8 @@ session required pam_unix.so</h:pre> the mentioned (parent) directory. </description> </Group> - <Group id="gt-system-fileprivileges-logs"> - <title>Logs Only Readable By Proper Group</title> + <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 @@ -1443,8 +1460,8 @@ session required pam_unix.so</h:pre> <h:code>wheel</h:code>). </description> </Group> - <Group id="gt-system-fileprivileges-rootonly"> - <title>Files Only Used By Root Should be Root-Only</title> + <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-rootonly"> + <title>Files only used by root should be root-only</title> <description> 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 @@ -1464,44 +1481,44 @@ session required pam_unix.so</h:pre> </h:ul> </description> </Group> - <Group id="gt-system-fileprivileges-hids"> - <title>Review File Integrity Regularly</title> + <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> - <Group id="gt-data"> - <title>Data Flows</title> + </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 your server (and which data - this is). You will need this anyhow when you want to add firewalls, but it + 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="gt-data-backup"> - <title>Backup Your Data</title> + <Group id="xccdf_org.gentoo.dev.swift_group_data-backup"> + <title>Backup the data</title> <description> - Make sure that your data is backed up. This is not only in case of - server loss, but also when you accidentally remove files or have an + 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="gt-data-backup-automate"> - <title>Automated Backups</title> + <Group id="xccdf_org.gentoo.dev.swift_group_data-backup-automate"> + <title>Automated backups</title> <description> - Automate backups on the system. If you need to perform a backup - manually, then you are doing it wrong and will start forgetting it. + Automate backups on the system. If the backups are performed manually + then they are done wrong and someone will eventually forget it. <h:br /> <h:br /> - You can use scheduling software like <h:code>cron</h:code> to + 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>. </description> </Group> - <Group id="gt-data-backups-coverage"> - <title>Full Data Coverage</title> + <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 @@ -1509,22 +1526,21 @@ session required pam_unix.so</h:pre> or even weeks. </description> </Group> - <Group id="gt-data-backups-history"> + <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-history"> <title>Retention</title> <description> - Ensure that your backups use a long enough retention. It is not wise + 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 - you might want to recover a file that was corrupted long before you - took your last backup. + there will be a time that a file needs to be recovered that was corrupted + long before the last backup was taken. <h:br /> <h:br /> - There is no perfect retention period however, as the more backups you - keep, the more storage you require and the more you need to invest in - managing your backups. + 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:br /> <h:br /> - In most cases, you will want to introduce a "layered" approach on - retention. For instance, you can + In most cases, introduce a "layered" approach on retention. For instance: <h:ul> <h:li>keep daily backups for a week</h:li> <h:li> @@ -1539,38 +1555,38 @@ session required pam_unix.so</h:pre> </h:ul> </description> </Group> - <Group id="gt-data-backups-location"> - <title>Off-site Backups</title> + <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-location"> + <title>Off-site backups</title> <description> - Keep your backups off-site in case of disaster. But consider this - location carefully. Investigate how fast you can put the backup there, - but also retrieve it in case you need it. Also investigate if this - location is juridically sane (are you allowed to put your location - there, and do you trust this off-site location). + 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:br /> <h:br /> Also ensure that the backups are stored securely. If necessary, - encrypt your backups. + encrypt the backups. </description> </Group> - <Group id="gt-data-backups-validate"> - <title>Validate and Test</title> + <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-validate"> + <title>Validate and test</title> <description> - Validate that your backup system works. Try recovering files (for + 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> - <Group id="gt-removal"> - <title>Decommissioning Servers</title> + </Group> <!-- Data flows --> + <Group id="xccdf_org.gentoo.dev.swift_group_removal"> + <title>Decommissioning servers</title> <description> - When you want to decommission a server, you should take care that its data + When a server needs to be decommissioned, make sure that its data is safeguarded from future extraction. </description> - <Group id="gt-removal-wipedisk"> - <title>Wipe Disks</title> + <Group id="xccdf_org.gentoo.dev.swift_group_removal-wipedisk"> + <title>Wipe disks</title> <description> Clear all data from the disks on the server in a secure manner. Applications like <h:b>shred</h:b> (part of @@ -1579,14 +1595,11 @@ session required pam_unix.so</h:pre> <h:br /> <h:br /> It is recommended to perform full disk wipes rather than file wipes. - If you need to do this on file level, see if you can disable file system - journaling during the wipe session as journaling might "buffer" the + 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. </description> - <reference - href="http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf">NIST - Publication "Guidelines for Media Sanitization" (PDF)</reference> + <reference href="http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf">NIST Publication "Guidelines for Media Sanitization" (PDF)</reference> </Group> - </Group> - --> + </Group> <!-- Removal --> </Benchmark> |