diff options
author | Sven Vermeulen <sven.vermeulen@siphos.be> | 2014-03-26 22:06:50 +0100 |
---|---|---|
committer | Sven Vermeulen <sven.vermeulen@siphos.be> | 2014-03-26 22:06:50 +0100 |
commit | e776b21bb7b10d185eeaebb8a97686a932a3b78c (patch) | |
tree | a13d29e13a01be27ed8f28f91f78fa9116f83937 | |
parent | Add in hidepid information (yes I know, grsec can also do this) (diff) | |
download | hardened-docs-e776b21bb7b10d185eeaebb8a97686a932a3b78c.tar.gz hardened-docs-e776b21bb7b10d185eeaebb8a97686a932a3b78c.tar.bz2 hardened-docs-e776b21bb7b10d185eeaebb8a97686a932a3b78c.zip |
Add syslog rules and enhance security/access.conf with an example
-rw-r--r-- | xml/SCAP/gentoo-xccdf.xml | 80 |
1 files changed, 76 insertions, 4 deletions
diff --git a/xml/SCAP/gentoo-xccdf.xml b/xml/SCAP/gentoo-xccdf.xml index d2bf154..5fe590d 100644 --- a/xml/SCAP/gentoo-xccdf.xml +++ b/xml/SCAP/gentoo-xccdf.xml @@ -1,13 +1,13 @@ <?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-20130917-1" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 xccdf-1.2.xsd" resolved="0"> - <status date="2014-02-01">draft</status> +<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-20140326-1" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 xccdf-1.2.xsd" resolved="0"> + <status date="2014-03-26">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>20140201.1</version> + <version>20140326.1</version> <model system="urn:xccdf:scoring:default" /> <model system="urn:xccdf:scoring:flat" /> <model system="urn:xccdf:scoring:flat-unweighted" /> @@ -355,7 +355,7 @@ </Group> </Group> <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation"> - <title>Before startng</title> + <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 @@ -1244,6 +1244,48 @@ sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf </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> @@ -1551,6 +1593,14 @@ tty12</h:pre> 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"> @@ -1731,6 +1781,28 @@ session required pam_unix.so</h:pre> </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> |