This may affect some profiles, which will be addressed next week.
David Smith (16): quick fix to make things validate content editing for CUPS changed a rule to a group removed obsolete settings added new transform to validly order nodes inside Groups style updates to software updates section changing coarse-grained recommendations to Groups for DHCP changing HOWTO information about OpenSSL into Groups changed coarse-grained recommendations to Groups for BIND changed coarse-grained discussion to Groups for FTP changed HOWTO information for OpenLDAP server to Groups changed discussions about Postfix to Groups changed firewall discussion about SSH to a Group fixed indenting, reassigned Groups/Rules in Samba guidance changed a coarse discussion about SNMP to a Group changed wide-ranging discussion about IPtables rules to Group
RHEL6/input/services/avahi.xml | 4 +- RHEL6/input/services/dhcp.xml | 41 +++++--- RHEL6/input/services/dns.xml | 164 +++++++++++++++++++++--------- RHEL6/input/services/ftp.xml | 8 +- RHEL6/input/services/ldap.xml | 22 ++-- RHEL6/input/services/mail.xml | 16 ++-- RHEL6/input/services/obsolete.xml | 21 +++-- RHEL6/input/services/printing.xml | 122 +++++++++------------- RHEL6/input/services/smb.xml | 124 ++++++++++++++++------- RHEL6/input/services/snmp.xml | 11 +- RHEL6/input/services/ssh.xml | 4 +- RHEL6/input/services/xorg.xml | 61 +----------- RHEL6/input/system/network/iptables.xml | 12 +- RHEL6/input/system/network/ssl.xml | 106 ++++++++++++-------- RHEL6/input/system/software/updating.xml | 74 +++++++------- RHEL6/transforms/shorthand2xccdf.xslt | 14 +++ 16 files changed, 445 insertions(+), 359 deletions(-)
From: David Smith dsmith@fornax.eclipse.ncsc.mil
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil --- RHEL6/input/services/obsolete.xml | 21 +++++++++++++-------- 1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/RHEL6/input/services/obsolete.xml b/RHEL6/input/services/obsolete.xml index f5e086a..383b19d 100644 --- a/RHEL6/input/services/obsolete.xml +++ b/RHEL6/input/services/obsolete.xml @@ -176,14 +176,19 @@ stolen by eavesdroppers on the network. <title>Remove Rsh Trust Files</title> <description>The files <tt>/etc/hosts.equiv</tt> and <tt>~/.rhosts</tt> (in each user's home directory) list remote hosts and users that are trusted by the -local system when using the rshd daemon.</description> -<ocil>cd to the directories in question, and delete them one at a time, or -perform the following commands to delete them from any location: -<pre> # rm /etc/hosts.equiv</pre> -<pre> $ rm ~/.rhosts</pre></ocil> -The output will -<rationale>These files are not needed and should be removed if they exist. -When used in conjunction with the R-services, they can allow +local system when using the rshd daemon. +To remove these files, run the following command to delete them from any +location: +<pre># rm /etc/hosts.equiv</pre> +<pre>$ rm ~/.rhosts</pre> +</description> +<ocil> +The existence of the file <tt>/etc/hosts.equiv</tt> or a file named +<tt>.rhosts</tt> inside a user home directory indicates the presence +of an Rsh trust relationship. +</ocil> +<rationale>Trust files are convenient, but when +used in conjunction with the R-services, they can allow unauthenticated access to a system.</rationale> <ident cce="TODO" /> <oval id="no_rsh_trusted_host_files" />
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil --- RHEL6/input/services/printing.xml | 122 +++++++++++++++---------------------- 1 files changed, 49 insertions(+), 73 deletions(-)
diff --git a/RHEL6/input/services/printing.xml b/RHEL6/input/services/printing.xml index 0daae0f..459aeac 100644 --- a/RHEL6/input/services/printing.xml +++ b/RHEL6/input/services/printing.xml @@ -1,117 +1,93 @@ <Group id="printing"> <title>Print Support</title> -<description>The Common Unix Printing System (CUPS) service provides both local and network printing support. A system running -the CUPS service can accept print jobs from other systems, process them, and send them to the appropriate printer. It also provides an -interface for remote administration through a web browser. The CUPS service is installed and activated by default. The project homepage -and more detailed documentation are available at http://www.cups.org. -<br /><br /> -</description> - - - - -<Group id="disable_printing"> -<title>Disable CUPS if Possible</title> -<description>If not needed, CUPS should be disabled to reduce attack surface.</description> - -<Rule id="service_cups_disabled2"><!-- Redundant w/ base services check but kept for equivalence with the RHEL5 NSA guidance --> -<title>Disable the CUPS Service if Possible</title> -<description>Do you need the ability to print from this machine or to allow others to print to it? If not, disable it. +<description>The Common Unix Printing System (CUPS) service provides both local +and network printing support. A system running the CUPS service can accept +print jobs from other systems, process them, and send them to the appropriate +printer. It also provides an interface for remote administration through a web +browser. The CUPS service is installed and activated by default. The project +homepage and more detailed documentation are available at http://www.cups.org. +<br /><br /> </description> + +<Rule id="service_cups_disabled"> +<title>Disable the CUPS Service</title> +<description> <service-disable-macro service="cups" /> </description> <ocil><service-disable-check-macro service="cups" /></ocil> <rationale>Turn off unneeded services to reduce attack surface. </rationale> -<ident cce="CCE-4112-9" /> -<ident cce="CCE-3755-6" /> +<ident cce="3755-6" /> <oval id="service_cups_disabled" /> <ref nist="CM-7" /> </Rule>
<Rule id="iptables_cupsd_disabled"> <title>Disable Firewall Access to Printing Service</title> -<description>Does this system need to operate as a network print server? If not, edit the files <tt>/etc/sysconfig/iptables</tt> and <tt>/etc/sysconfig/ip6tables</tt> (if IPv6 is in use). In each file, locate and delete the lines: +<description>If the system does not need to act as a network print server, edit +the files <tt>/etc/sysconfig/iptables</tt> and +<tt>/etc/sysconfig/ip6tables</tt> (if IPv6 is in use). In each file, locate and +delete the lines: <pre>-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT</pre> </description> -<rationale>By default, inbound connections to the Internet Printing Protocol port are allowed. If the print server does not need to be accessed, either because the machine is not running the print service at all or because the machine is not providing a remote network printer to other machines, this exception should be removed from the firewall configuration. +<rationale>By default, inbound connections to the Internet Printing Protocol +port are allowed. If the print server does not need to be accessed, either +because the machine is not running the print service at all or because the +machine is not providing a remote network printer to other machines, this +exception should be removed from the firewall configuration. </rationale> -<ident cce="CCE-3649-1" /> +<ident cce="3649-1" /> <oval id="iptables_cupsd_disabled" /> <ref nist="CM-7" /> </Rule>
-</Group><!--End <Group id="disable_printing"> -->
<Group id="configure_printing"> <title>Configure the CUPS Service if Necessary</title> <description>CUPS provides the ability to easily share local printers with other machines over the network. It does this by allowing machines to share lists of available printers. Additionally, each machine that runs the CUPS service can potentially act as a print server. Whenever possible, the printer sharing and print server capabilities of CUPS should be limited or disabled. The following recommendations should demonstrate how to do just that. </description>
-<Group id="limit_printer_browsing"> -<title>Limit Printer Browsing</title> -<description>By default, CUPS listens on the network for printer list broadcasts on UDP port 631. This functionality is called -printer browsing. -</description> - <Rule id="cups_disable_browsing"> <title>Disable Printer Browsing Entirely if Possible</title> -<description>To disable printer browsing entirely, edit the CUPS configuration file, located at <tt>/etc/cups/cupsd.conf</tt>, to include the following: -<pre>Browsing Off -BrowseAllow none</pre> +<description>By default, CUPS listens on the network for printer list +broadcasts on UDP port 631. This functionality is called printer browsing. +To disable printer browsing entirely, edit the CUPS configuration +file, located at <tt>/etc/cups/cupsd.conf</tt>, to include the following: +<pre>Browsing Off</pre> </description> -<rationale>The CUPS print service can be configured to broadcast a list of available printers to the network. Other machines on the network, also running the CUPS print service, can be configured to listen to these broadcasts and add and configure these printers for immediate use. By disabling this browsing capability, the machine will no longer generate or receive such broadcasts. +<rationale>The CUPS print service can be configured to broadcast a list of +available printers to the network. Other machines on the network, also running +the CUPS print service, can be configured to listen to these broadcasts and add +and configure these printers for immediate use. By disabling this browsing +capability, the machine will no longer generate or receive such broadcasts. </rationale> -<ident cce="CCE-4420-6" /> -<ident cce="CCE-4407-3" /> +<ident cce="4420-6" /> <oval id="cups_disable_browsing" /> -<!--<ref nist="TODO:NIST" />--> </Rule>
-<Rule id="cups_limit_browsing"> -<title>Limit Printer Browsing to a Particular Subnet if Necessary</title> -<description>It is possible to disable outgoing printer list broadcasts without affecting incoming broadcasts from other machines. To do so, open the CUPS configuration file, located at <tt>/etc/cups/cupsd.conf</tt>. Look for the line that begins with BrowseAddress and remove it. The line will look like the following: -<pre>BrowseAddress @LOCAL</pre> -If the intent is not to block printer sharing, but to limit it to a particular set of machines, you can limit the UDP printer broadcasts to trusted network addresses. -<pre>BrowseAddress ip-address :631</pre> -Likewise, to ignore incoming UDP printer list broadcasts, or to limit the set of machines to listen to, use the BrowseAllow and BrowseDeny directives. -<pre>BrowseDeny all -BrowseAllow ip-address</pre> -This combination will deny incoming broadcasts from any machine except those that are explicitly allowed with BrowseAllow. -</description> -<rationale>By default, when printer sharing is enabled, CUPS will broadcast to every network that its host machine is connected to through all available network interfaces on port 631. It will also listen to incoming broadcasts from other machines on the network. Either list one BrowseAddress line for each client machine and one BrowseAllow line for each print server or use one of the supported shorthand notations that the CUPS service recognizes. Please see the cupsd.conf(5) man page or the documentation provided at http://www.cups.org for more information on other ways to format these directives. -</rationale> -<!--<ident cce="TODO:CCE" />--> -<oval id="cups_limit_browsing" /> -<!--<ref nist="TODO:NIST" />--> -</Rule> - -</Group><!--End <Group id="limit_printer_browsing"> --> - <Rule id="cups_disable_printserver"> -<title>Disable Printer Server Capabilities if Possible</title> -<description>To prevent remote users from potentially connecting to and using locally configured printers, disable the CUPS print server sharing capabilities. To do so, limit how the server will listen for print jobs by removing the more generic port directive from /etc/cups/cupsd.conf: +<title>Disable Print Server Capabilities</title> +<description>To prevent remote users from potentially connecting to and using +locally configured printers, disable the CUPS print server sharing +capabilities. To do so, limit how the server will listen for print jobs by +removing the more generic port directive from /etc/cups/cupsd.conf: <pre>Port 631</pre> and replacing it with the Listen directive: <pre>Listen localhost:631</pre> -This will prevent remote users from printing to locally configured printers while still allowing local users on the machine to print normally. +This will prevent remote users from printing to locally configured printers +while still allowing local users on the machine to print normally. </description> -<rationale>By default, locally configured printers will not be shared over the network, but if this functionality has somehow been enabled, these recommendations will disable it again. Be sure to disable outgoing printer list broadcasts, or remote users will still be able to see the locally configured printers, even if they cannot actually print to them. To limit print serving to a particular set of users, use the Policy directive. +<rationale>By default, locally configured printers will not be shared over the +network, but if this functionality has somehow been enabled, these +recommendations will disable it again. Be sure to disable outgoing printer list +broadcasts, or remote users will still be able to see the locally configured +printers, even if they cannot actually print to them. To limit print serving to +a particular set of users, use the Policy directive. </rationale> -<!--<ident cce="CCE-4420-6, CCE-4407-3" /> TODO:CCE --> +<ident cce="4407-3" /> <oval id="cups_disable_printserver" /> <ref nist="TODO:NIST" /> </Rule> +</Group>
-<Rule id="cups_limit_web_interface"> -<title>Limit Access to the Web Administration Interface</title> -<description>By default, access to the CUPS web administration interface is limited to the local machine. It is recommended that this not be changed, especially since the authentication mechanisms that CUPS provides are limited in their effectiveness. Host-based authentication has known limitations, especially since IP addresses are easy to spoof. Requiring users to authenticate themselves can alleviate this problem, but it cannot eliminate it. -</description> -<!--<ident cce="CCE-4420-6, CCE-4407-3" /> TODO:CCE --> -<oval id="cups_limit_web_interface" /> -<!--<ref nist="TODO:NIST" />--> -</Rule> - -</Group><!--End <Group id="configure_printing"> --> - -</Group><!--End <Group id="printing"> --> +</Group>
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil --- RHEL6/input/services/avahi.xml | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/RHEL6/input/services/avahi.xml b/RHEL6/input/services/avahi.xml index 5e4d7d3..24b0544 100644 --- a/RHEL6/input/services/avahi.xml +++ b/RHEL6/input/services/avahi.xml @@ -109,7 +109,7 @@ that port on the system. </Rule>
-<Rule id="avahi_restrict_published_information"> +<Group id="avahi_restrict_published_information"> <title>Restrict Information Published by Avahi</title> <description> If it is necessary to publish some information to the network, it should not be joined @@ -136,7 +136,7 @@ the types of published information in the event that some information must be published. </rationale> <ref nist="AC-4, CM-6, CM-7" /> -</Rule> +</Group>
</Group>
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil --- RHEL6/input/services/xorg.xml | 61 +---------------------------------------- 1 files changed, 1 insertions(+), 60 deletions(-)
diff --git a/RHEL6/input/services/xorg.xml b/RHEL6/input/services/xorg.xml index 5b60568..f55c2fc 100644 --- a/RHEL6/input/services/xorg.xml +++ b/RHEL6/input/services/xorg.xml @@ -36,65 +36,6 @@ To do so, run the following command: <oval id="package_xorg-x11-server-common_removed" /> </Rule>
-<Group id="xwindows_startx"> -<title>Lock Down X Windows startx Configuration if Necessary</title> -<description>If X is not to be started at boot time but the -software must remain installed, users will be able to run X -manually using the <tt>startx</tt> command. In some cases, this runs -X with a configuration which is less safe than the default. Follow these -instructions to mitigate risk from this -configuration.</description> - -<Group id="xwindows_no_listen"> -<title>Disable X Window System Listening</title> -<description>To prevent X.org from listening for remote -connections, create the file <tt>/etc/X11/xinit/xserverrc</tt> and -fill it with the following line: -<pre>exec X :0 -nolisten tcp $@</pre> -One of X.org's features is the ability to provide remote -graphical display. This feature should be disabled unless it is -required. If the system uses <tt>runlevel 5</tt>, which is the default, -the GDM display manager starts X safely, with remote listening -disabled. However, if X is started from the command line with the -<tt>startx</tt> command, then the server will listen for new connections -on X's default port, 6000. -<br /><br /> -See the <tt>xinit(1)</tt>, <tt>startx(1)</tt>, and <tt>Xserver(1)</tt> -man pages for more information.</description> - -<Rule id="xwindows_remote_listening"> -<title>Disable X Window System Listening</title> -<description>Disable the ability to provide remote graphical -display</description> -<ident cce="4074-1" /> -<oval id="xwindows_remote_listening" /> -</Rule> -</Group> -</Group> - -</Group> - -<Group id="xwindows_configuration"> -<title>Configure X Windows if Necessary</title> -<description>If there is an operational need for the system -to run a GUI, apply the following guidance. -</description> - -<Rule id="set_gdm_login_banner"> -<title>Create Warning Banners for GUI Login -Users</title> -<description>To ensure the GNOME display manager displays a warning banner prior to login, -edit the file <tt>/etc/gdm/custom.conf</tt>. Locate the -<tt>[greeter]</tt> section, and correct that section to contain the lines: -<pre>[greeter] -InfoMsgFile=/etc/issue</pre> -This setting will cause the system greeting banner to be displayed in a box -prior to GUI login. If the default banner font is inappropriate, it can be -changed by specifying the <tt>InfoMsgFont</tt> directive as well, for instance: -<pre>InfoMsgFont=Sans 12</pre> -</description> -<ident cce="3717-6" /> -<oval id="banner_gui_gdm" /> -</Rule> +<!-- to add: guidance in /etc/gdm/custom.conf for xdmcp disable, tcplisten disable --> </Group> </Group>
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil --- RHEL6/transforms/shorthand2xccdf.xslt | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/RHEL6/transforms/shorthand2xccdf.xslt b/RHEL6/transforms/shorthand2xccdf.xslt index d899f48..0d8f56e 100644 --- a/RHEL6/transforms/shorthand2xccdf.xslt +++ b/RHEL6/transforms/shorthand2xccdf.xslt @@ -48,6 +48,20 @@ exclude-result-prefixes="xccdf xhtml"> </xsl:copy> </xsl:template>
+ + <xsl:template match="Group"> + xsl:copy + <xsl:apply-templates select="@*" /> + <xsl:apply-templates select="title"/> + <xsl:apply-templates select="description"/> + <xsl:apply-templates select="warning"/> + <xsl:apply-templates select="ref"/> + <xsl:apply-templates select="rationale"/> + <xsl:apply-templates select="node()[not(self::title|self::description|self::warning|self::ref|self::rationale)]"/> + </xsl:copy> + </xsl:template> + + <!-- expand reference to ident types --> <xsl:template match="Rule/ident"> <xsl:for-each select="@*">
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil --- RHEL6/input/system/software/updating.xml | 74 ++++++++++++++--------------- 1 files changed, 36 insertions(+), 38 deletions(-)
diff --git a/RHEL6/input/system/software/updating.xml b/RHEL6/input/system/software/updating.xml index 34b18f5..99b6520 100644 --- a/RHEL6/input/system/software/updating.xml +++ b/RHEL6/input/system/software/updating.xml @@ -45,44 +45,23 @@ are from Red Hat. <!-- REMINDER: Before telling people to update their systems via the security_patches_up_to_date rule, we must ensure they have configured an update source! --> - -<Rule id="security_patches_up_to_date"> -<title>Ensure Software Patches Installed</title> -<description>The following command prints a list of packages that -need to be updated: -<pre># yum check-update</pre> -To actually install these updates, run: -<pre># yum update</pre> -</description> -<ocil> -After running the update command, you can reinvoke the same command -to determine if updates were applied. If you run the command and -nothing comes back as needing to be updated, then your system is up -to date. -<pre># yum update</pre> -</ocil> -<rationale> -Installing software updates is a fundamental mitigation against -the exploitation of publicly-known vulnerabilities. -</rationale> -<ref nist="SI-2" disa="1232"/> -</Rule> <Rule id="ensure_gpgcheck_globally_activated"> <title>Ensure gpgcheck Enabled In Main Yum Configuration</title> <description>The <tt>gpgcheck</tt> option should be used to ensure that checking of an RPM package’s signature always occurs prior to its -installation. To force yum to check package signatures before installing +installation. To configure yum to check package signatures before installing them, ensure that the following line appears in <tt>/etc/yum.conf</tt> in the <tt>[main]</tt> section: <pre>gpgcheck=1</pre> </description> <ocil> -By performing a simple grep, one can determine if the value is set in -the file or not. Run the following command to deterine the status of -the variable in the file. -<pre># grep gpgcheck=1 /etc/yum.conf</pre> -If it reurns a value, then it is enabled. ex: -<pre># gpgcheck=1 <--- Returned value from the grep command</pre> +To determine whether <tt>yum</tt> is configured to use <tt>gpgcheck</tt>, +inspect <tt>/etc/yum.conf</tt> and ensure that the following appears in the +<tt>[main]</tt> section: +<pre>gpgcheck=1</pre> +A value of <tt>1</tt> indicates that <tt>gpgcheck</tt> is enabled. Absence of a +<tt>gpgcheck</tt> line or a setting of <tt>0</tt> indicates that it is +disabled. </ocil> <rationale> Ensuring the validity of packages' cryptographic signatures prior to @@ -97,18 +76,16 @@ protects against malicious tampering. <Rule id="ensure_gpgcheck_never_disabled"> <title>Ensure gpgcheck Enabled For All Yum Package Repositories</title> <description>To ensure that signature checking is not disabled for -any repos, ensure that the following line DOES NOT appear in any -repo configuration files in <tt>/etc/yum.repos.d</tt> or elsewhere: +any repos, remove any lines from files in <tt>/etc/yum.repos.d</tt> of the form: <pre>gpgcheck=0</pre> </description> <ocil> -By performing a simple grep, one can determine if the value is set -in the file or not. Run the following command to deterine the status -of the variable in the file. -<pre># grep gpgcheck=0 /etc/yum.conf</pre> -If it doesn't reurn a value, then it hasn't been disabled. ex: -<pre># grep gpgcheck=0 /etc/yum.conf</pre> -<pre># <---Flashing cursor</pre> +To determine whether <tt>yum</tt> has been configured to disable +<tt>gpgcheck</tt> for any repos, inspect all files in +<tt>/etc/yum.repos.d</tt> and ensure that the following does not appear in any +sections: +<pre>gpgcheck=0</pre> +A value of <tt>0</tt> indicates that <tt>gpgcheck</tt> has been disabled for that repo. </ocil> <rationale> Ensuring that all packages' cryptographic signatures are valid prior to @@ -119,4 +96,25 @@ protects against malicious tampering. <oval id="yum_gpgcheck_never_disabled" /> <ref nist="SI-2" disa="352,663"/> </Rule> + +<Rule id="security_patches_up_to_date"> +<title>Ensure Software Patches Installed</title> +<description>The following command prints a list of packages that +need to be updated: +<pre># yum check-update</pre> +To actually install these updates, run: +<pre># yum update</pre> +</description> +<ocil> +After running the update command, invoking the update command again can be used +to determine success of the updates. If nothing is returned, the update was +successful. +<pre># yum update</pre> +</ocil> +<rationale> +Installing software updates is a fundamental mitigation against +the exploitation of publicly-known vulnerabilities. +</rationale> +<ref nist="SI-2" disa="1232"/> +</Rule> </Group>
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil --- RHEL6/input/services/dhcp.xml | 41 ++++++++++++++++++++++++++--------------- 1 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/RHEL6/input/services/dhcp.xml b/RHEL6/input/services/dhcp.xml index cc0631a..8417bb0 100644 --- a/RHEL6/input/services/dhcp.xml +++ b/RHEL6/input/services/dhcp.xml @@ -190,11 +190,13 @@ DHCP is inherently insecure and should not be used unless it presents an unaccep
<Group id="dhcp_client_configuration"> <title>Configure DHCP Client if Necessary</title> -<description>If DHCP must be used, then certain configuration changes can minimize the amount of information it receives and applies from the network, and thus the amount of incorrect information a rogue DHCP server could successfully distribute. -For more information on configuring dhclient, see the dhclient(8) and dhclient.conf(5) man pages. -</description> +<description>If DHCP must be used, then certain configuration changes can +minimize the amount of information it receives and applies from the network, +and thus the amount of incorrect information a rogue DHCP server could +successfully distribute. For more information on configuring dhclient, see the +dhclient(8) and dhclient.conf(5) man pages. </description>
-<Rule id="dhcp_client_restrict_options"> +<Group id="dhcp_client_restrict_options"> <title>Minimize the DHCP-Configured Options</title> <description>Create the file <tt>/etc/dhclient.conf</tt>, and add an appropriate setting for each of the ten configuration settings which can be obtained via DHCP. For each setting, setting , do one of the following: If the setting should not be configured remotely by the DHCP server, select an appropriate static value, and add the line: @@ -213,20 +215,29 @@ supersede routers 192.168.1.1; supersede time-offset -18000; request subnet-mask; require subnet-mask;</pre></description> -<rationale>By default, the DHCP client program, dhclient, requests and applies ten configuration options (in addition to the -IP address) from the DHCP server: subnet-mask, broadcast-address, time-offset, routers, domain-name, -domain-name-servers, host-name, nis-domain, nis-servers, and ntp-servers. -Many of the options requested and applied by dhclient may be the same for every system on a network. It is -recommended that almost all configuration options be assigned statically, and only options which must vary on -a host-by-host basis be assigned via DHCP. This limits the damage which can be done by a rogue DHCP server. -If appropriate for your site, it is also possible to supersede the host-name directive in <tt>/etc/dhclient.conf</tt>, -establishing a static hostname for the machine. However, dhclient does not use the host name option provided -by the DHCP server (instead using the value provided by a reverse DNS lookup).</rationale> -<warning category="general">In this example, the options nis-servers and nis-domain are set to empty strings, on the assumption that the deprecated NIS protocol is not in use. It is necessary to supersede settings for unused services so that they cannot be set by a hostile DHCP server. If an option is set to an empty string, dhclient will typically not attempt to configure the service.</warning> +<rationale>By default, the DHCP client program, dhclient, requests and applies +ten configuration options (in addition to the IP address) from the DHCP server: +subnet-mask, broadcast-address, time-offset, routers, domain-name, +domain-name-servers, host-name, nis-domain, nis-servers, and ntp-servers. Many +of the options requested and applied by dhclient may be the same for every +system on a network. It is recommended that almost all configuration options be +assigned statically, and only options which must vary on a host-by-host basis +be assigned via DHCP. This limits the damage which can be done by a rogue DHCP +server. If appropriate for your site, it is also possible to supersede the +host-name directive in <tt>/etc/dhclient.conf</tt>, establishing a static +hostname for the machine. However, dhclient does not use the host name option +provided by the DHCP server (instead using the value provided by a reverse DNS +lookup).</rationale> +<warning category="general">In this example, the options nis-servers and +nis-domain are set to empty strings, on the assumption that the deprecated NIS +protocol is not in use. It is necessary to supersede settings for unused +services so that they cannot be set by a hostile DHCP server. If an option is +set to an empty string, dhclient will typically not attempt to configure the +service.</warning> <!--<ident cce="4464-4" /> --> <!--<oval id="dhcp_client_restrict_options" /> --> <!--<ref nist="CM-6, CM-7" /> --> -</Rule> +</Group>
</Group> <!-- <Group id="dhcp_client_configuration"> -->
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil --- RHEL6/input/system/network/ssl.xml | 106 ++++++++++++++++++++++-------------- 1 files changed, 64 insertions(+), 42 deletions(-)
diff --git a/RHEL6/input/system/network/ssl.xml b/RHEL6/input/system/network/ssl.xml index 2ba4c6e..cf8b9da 100644 --- a/RHEL6/input/system/network/ssl.xml +++ b/RHEL6/input/system/network/ssl.xml @@ -1,50 +1,72 @@ <Group id="network_ssl"> <title>Secure Sockets Layer Support</title> <description> -The Secure Sockets Layer (SSL) protocol provides encrypted and authenticated network communications, and -many network services include support for it. Using SSL is recommended, especially to avoid any plaintext -transmission of sensitive data, even over a local network. The SSL implementation included with the system is -called OpenSSL. Recent implementations of SSL may also be referred to as Transport Layer Security (TLS). -SSL uses public key cryptography to provide authentication and encryption. +The Secure Sockets Layer (SSL) protocol provides encrypted and authenticated +network communications, and many network services include support for it. Using +SSL is recommended, especially to avoid any plaintext transmission of sensitive +data, even over a local network. The SSL implementation included with the +system is called OpenSSL. Recent implementations of SSL may also be referred to +as Transport Layer Security (TLS). SSL uses public key cryptography to provide +authentication and encryption. <br /><br /> -Public key cryptography involves two keys, one called the public key and the other called the private key. These keys are mathematically related such that data encrypted with one key can only be decrypted by the other, and vice versa. As their names -suggest, public keys can be distributed to anyone while a private key must remain known only to its owner. -SSL uses certificates, which are files that hold cryptographic data: a public key, and a signature of that public -key. In SSL authentication, a server presents a client with its certificate as a means of demonstrating that it -is who it claims it is. +Public key cryptography involves two keys, one called the public key and the +other called the private key. These keys are mathematically related such that +data encrypted with one key can only be decrypted by the other, and vice versa. +As their names suggest, public keys can be distributed to anyone while a +private key must remain known only to its owner. SSL uses certificates, which +are files that hold cryptographic data: a public key, and a signature of that +public key. In SSL authentication, a server presents a client with its +certificate as a means of demonstrating that it is who it claims it is. + <br /><br /> -If everything goes correctly, the client can verify the server’s certificate by determining -that the signature inside the certificate could only have been generated by a third party whom the client trusts. -This third party is called a Certificate Authority (CA). Each client system should also have certificates from -trusted CAs, and the client uses these CA certificates to verify the authenticity of the server’s certificate. After -authenticating a server using its certificate and a CA certificate, SSL provides encryption by using the server -certificate to securely negotiate a shared secret key. +If everything goes correctly, the client can verify the server’s certificate by +determining that the signature inside the certificate could only have been +generated by a third party whom the client trusts. This third party is called +a Certificate Authority (CA). Each client system should also have certificates +from trusted CAs, and the client uses these CA certificates to verify the +authenticity of the server’s certificate. After authenticating a server using +its certificate and a CA certificate, SSL provides encryption by using the +server certificate to securely negotiate a shared secret key. + <br /><br /> -If your server must communicate using SSL with systems that might not be able to securely accept a new CA -certificate prior to any SSL communication, then paying an established CA (whose certificates your clients already -have) to sign your server certificates is recommended. The steps for doing this vary by vendor. Once the signed -certificates have been obtained, configuration of the services is the same whether they were purchased from a -vendor or signed by your own CA. +If your server must communicate using SSL with systems that might not be able +to securely accept a new CA certificate prior to any SSL communication, then +paying an established CA (whose certificates your clients already have) to sign +your server certificates is recommended. The steps for doing this vary by +vendor. Once the signed certificates have been obtained, configuration of the +services is the same whether they were purchased from a vendor or signed by +your own CA. + <br /><br /> -For setting up an internal network and encrypting local traffic, creating your own CA to sign SSL certificates -can be appropriate. The major steps in this process are: +For setting up an internal network and encrypting local traffic, creating your +own CA to sign SSL certificates can be appropriate. The major steps in this +process are: + <ol> <li>Create a CA to sign certificates</li> <li>Create SSL certificates for servers using that CA</li> <li>Enable client support by distributing the CA’s certificate</li> </ol> </description> + + <ref disa="1141,1148,1130,1131,1127,1128,1135,1129,1132,1142,1147,187" />
-<Rule id="network_ssl_create_ca"> +<Group id="network_ssl_create_ca"> <title>Create a CA to Sign Certificates</title> -<description>The following instructions apply to OpenSSL since it is included with the system, but creating a CA is possible -with any standards-compliant SSL toolkit. The security of certificates depends on the security of the CA that -signed them, so performing these steps on a secure machine is critical. The system used as a CA should be -physically secure and not connected to any network. It should receive any certificate signing requests (CSRs) via +<description>The following instructions apply to OpenSSL since it is included +with the system, but creating a CA is possible with any standards-compliant SSL +toolkit. The security of certificates depends on the security of the CA that +signed them, so performing these steps on a secure machine is critical. The +system used as a CA should be physically secure and not connected to any +network. It should receive any certificate signing requests (CSRs) via removable media and output certificates onto removable media. <br /><br /> -The script <tt>/etc/pki/tls/misc/CA</tt> is included to assist in the process of setting up a CA. This script uses many settings in <tt>/etc/pki/tls/openssl.cnf</tt>. The settings in this file can be changed to suit your needs and allow easier selection of default settings, particularly in the <tt>[req distinguished name]</tt> section. +The script <tt>/etc/pki/tls/misc/CA</tt> is included to assist in the process +of setting up a CA. This script uses many settings in +<tt>/etc/pki/tls/openssl.cnf</tt>. The settings in this file can be changed to +suit your needs and allow easier selection of default settings, particularly in +the <tt>[req distinguished name]</tt> section. <br /><br /> To create the CA: <pre># cd /etc/pki/tls/misc @@ -81,9 +103,9 @@ of the server certificate. <!--<ident cce="TODO" />--> <!--TODO:MANUAL<oval id="network_ssl_create_ca" />--> <ref nist="SC-12, SC-13" /> -</Rule> +</Group>
-<Rule id="network_ssl_create_ssl_certs"> +<Group id="network_ssl_create_ssl_certs"> <title>Create SSL Certificates for Servers</title> <description>Creating an SSL certificate for a server involves the following steps: <ol> @@ -103,9 +125,9 @@ Instructions on how to generate and sign SSL certificates are provided for the f <!--<ident cce="TODO" />--> <!--TODO:MANUAL<oval id="network_ssl_create_ssl_certs" />--> <ref nist="CM-6, SC-12, SC-13" /> -</Rule> +</Group>
-<Rule id="network_ssl_enable_client_support"> +<Group id="network_ssl_enable_client_support"> <title>Enable Client Support</title> <description>The system ships with certificates from well-known commercial CAs. If your server certificates were signed by one of these established CAs, then this step is not necessary since the clients should include the CA certificate already. If your servers use certificates signed by your own CA, some user applications will warn that the server’s certificate @@ -116,9 +138,9 @@ application on every client system that will be connecting to an SSL-enabled ser <!--<ident cce="TODO" />--> <!--TODO:MANUAL<oval id="network_ssl_enable_client_support" />--> <ref nist="AC-3, AC-17, CM-6, SC-12, SC-13" disa="185" /> -</Rule> +</Group>
-<Rule id="network_ssl_add_ca_firefox"> +<Group id="network_ssl_add_ca_firefox"> <title>Adding a Trusted CA for Firefox</title> <description>To import a new CA certificate into Firefox: <ol> @@ -135,9 +157,9 @@ web sites, e-mail users, and software developers and trust it for each according <!--<ident cce="TODO" />--> <!--TODO:MANUAL<oval id="network_ssl_add_ca_firefox" />--> <ref nist="AC-3, AC-17, CM-6, SC-12, SC-13" /> -</Rule> +</Group>
-<Rule id="network_ssl_add_ca_thunderbird"> +<Group id="network_ssl_add_ca_thunderbird"> <title>Adding a Trusted CA for Thunderbird</title> <description>To import a new CA certificate into Thunderbird: <ol> @@ -154,9 +176,9 @@ web sites, e-mail users, and software developers and trust it for each according <!--<ident cce="TODO" />--> <!--TODO:MANUAL<oval id="network_ssl_add_ca_thunderbird" />--> <ref nist="AC-3, AC-17, CM-6, SC-12, SC-13" /> -</Rule> +</Group>
-<Rule id="network_ssl_add_ca_evolution"> +<Group id="network_ssl_add_ca_evolution"> <title>Adding a Trusted CA for Evolution</title> <description>To import a new CA certificate into Evolution: <ol> @@ -173,9 +195,9 @@ web sites, e-mail users, and software developers and trust it for each according <!--<ident cce="TODO" />--> <!--TODO:MANUAL<oval id="network_ssl_add_ca_evolution" />--> <ref nist="AC-3, AC-17, CM-6, SC-12, SC-13" /> -</Rule> +</Group>
-<Rule id="network_ssl_remove_certs"> +<Group id="network_ssl_remove_certs"> <title>Remove Certificate Authorities, if Appropriate</title> <description>Survey the certificate authorities trusted by Firefox, Thunderbird, Evolution, or other network clients. The list of certificate authorities for each program can be found via GUI, as described in the previous sections. Remove the certificate authorities which are not appropriate for your network connectivity needs. @@ -185,6 +207,6 @@ Internet-connected system. <!--<ident cce="TODO" />--> <!--TODO:MANUAL<oval id="network_ssl_remove_certs" />--> <ref nist="AC-3, AC-17, CM-6, SC-12, SC-13" /> -</Rule> +</Group>
</Group><!--<Group id="network_ssl">-->
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil --- RHEL6/input/services/dns.xml | 164 +++++++++++++++++++++++++++++------------- 1 files changed, 114 insertions(+), 50 deletions(-)
diff --git a/RHEL6/input/services/dns.xml b/RHEL6/input/services/dns.xml index 4ee17bb..619f99f 100644 --- a/RHEL6/input/services/dns.xml +++ b/RHEL6/input/services/dns.xml @@ -33,8 +33,8 @@ implementation flaws and should be disabled if possible.
<Rule id="uninstall_bind"> <title>Uninstall bind Package</title> -<description>To remove the <tt>bind</tt> package, which contains the <tt>named</tt> service, -run the following command: +<description>To remove the <tt>bind</tt> package, which contains the +<tt>named</tt> service, run the following command: <pre># yum erase bind</pre> </description> <ocil><package-remove-macro package="package_bind_removed" /> </ocil> @@ -56,7 +56,7 @@ from interfering with other services. This is done both to protect the remainder of the network should a nameserver be compromised, and to make direct attacks on nameservers more difficult.</description>
-<Rule id="dns_server_dedicated"> +<Group id="dns_server_dedicated"> <title>Run DNS Software on Dedicated Servers</title> <description>Since DNS is a high-risk service which must frequently be made available to the entire Internet, it is strongly recommended that no other services be offered by @@ -64,7 +64,7 @@ machines which act as organizational DNS servers.</description> <!--<ident cce="4219-2" />--> <!--<oval id="dns_server_dedicated" />--> <!--<ref nist="CM-6, CM-7" />--> -</Rule> +</Group>
<Rule id="dns_server_chroot"> <title>Run DNS Software in a chroot Jail</title> @@ -74,7 +74,8 @@ Place a valid named.conf file inside the chroot jail: <pre># cp /etc/named.conf /var/named/chroot/etc/named.conf # chown root:root /var/named/chroot/etc/named.conf # chmod 644 /var/named/chroot/etc/named.conf</pre> -Create and populate an appropriate zone directory within the jail, based on the options directive. If your <tt>named.conf</tt> includes: +Create and populate an appropriate zone directory within the jail, based on the +options directive. If your <tt>named.conf</tt> includes: <pre>options { directory "/path/to/DIRNAME "; ... @@ -84,11 +85,17 @@ then copy that directory and its contents from the original zone directory: Edit the file <tt>/etc/sysconfig/named</tt>. Add or correct the line: <pre>ROOTDIR=/var/named/chroot</pre> </description> -<rationale>Chroot jails are not foolproof. However, they serve to make it more difficult for a compromised program to be -used to attack the entire host. They do this by restricting a program’s ability to traverse the directory upward, -so that files outside the jail are not visible to the chrooted process. Since RHEL supports a standard mechanism -for placing BIND in a chroot jail, you should take advantage of this feature.</rationale> -<warning category="general">If you are running BIND in a chroot jail, then you should use the jailed <tt>named.conf</tt> as the primary nameserver configuration file. That is, when this guide recommends editing <tt>/etc/named.conf</tt>, you should instead edit <tt>/var/named/chroot/etc/named.conf</tt>. +<rationale>Chroot jails are not foolproof. However, they serve to make it more +difficult for a compromised program to be used to attack the entire host. They +do this by restricting a program’s ability to traverse the directory upward, so +that files outside the jail are not visible to the chrooted process. Since RHEL +supports a standard mechanism for placing BIND in a chroot jail, you should +take advantage of this feature.</rationale> +<warning category="general">If you are running BIND in a chroot jail, then you +should use the jailed <tt>named.conf</tt> as the primary nameserver +configuration file. That is, when this guide recommends editing +<tt>/etc/named.conf</tt>, you should instead edit +<tt>/var/named/chroot/etc/named.conf</tt>. </warning> <ident cce="3985-9" /> <ident cce="4487-5" /> @@ -97,30 +104,37 @@ for placing BIND in a chroot jail, you should take advantage of this feature.</r <!--<ref nist="CM-6, CM-7" />--> </Rule>
-<Rule id="dns_server_firewall"> +<Group id="dns_server_firewall"> <title>Configure Firewalls to Protect the DNS Server</title> -<description>Edit the file <tt>/etc/sysconfig/iptables</tt>. Add the following lines, ensuring that they appear before the final LOG and DROP lines for the RH-Firewall-1-INPUT chain: +<description>Edit the file <tt>/etc/sysconfig/iptables</tt>. Add the following +lines, ensuring that they appear before the final LOG and DROP lines for the +RH-Firewall-1-INPUT chain: <pre>-A RH-Firewall-1-INPUT -m state --state NEW -p udp --dport 53 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 53 -j ACCEPT</pre> </description> -<rationale>These lines are necessary in order to allow remote machines to contact the DNS server. If this server is only -available to the local network, it may be appropriate to insert a -s flag into this rule to allow traffic only from -packets on the local network.</rationale> +<rationale>These lines are necessary in order to allow remote machines to +contact the DNS server. If this server is only available to the local network, +it may be appropriate to insert a -s flag into this rule to allow traffic only +from packets on the local network.</rationale> <!--<ident cce="3985-9, 4487-5, 4258-0" /> --> <!--<oval id="dns_server_firewall" />--> <!--<ref nist="CM-6, CM-7" />--> -</Rule> +</Group>
</Group> <!--<Group id="dns_server_isolation">-->
<Group id="dns_server_protection"> <title>Protect DNS Data from Tampering or Attack</title> -<description>This section discusses DNS configuration options which make it more difficult for attackers to gain access to -private DNS data or to modify DNS data.</description> +<description>This section discusses DNS configuration options which make it +more difficult for attackers to gain access to private DNS data or to modify +DNS data.</description>
-<Rule id="dns_server_seperate_internal_external"> +<Group id="dns_server_seperate_internal_external"> <title>Run Separate DNS Servers for External and Internal Queries</title> -<description>Is it possible to run external and internal nameservers on separate machines? If so, follow the configuration guidance in this section. On the external nameserver, edit <tt>/etc/named.conf</tt>. Add or correct the following directives: +<description>Is it possible to run external and internal nameservers on +separate machines? If so, follow the configuration guidance in this section. On +the external nameserver, edit <tt>/etc/named.conf</tt>. Add or correct the +following directives: <pre>options { allow-query { any; }; recursion no; @@ -129,7 +143,9 @@ private DNS data or to modify DNS data.</description> zone "example.com " IN { ... };</pre> -On the internal nameserver, edit <tt>/etc/named.conf</tt>. Add or correct the following directives, where SUBNET is the numerical IP representation of your organization in the form xxx.xxx.xxx.xxx/xx: +On the internal nameserver, edit <tt>/etc/named.conf</tt>. Add or correct the +following directives, where SUBNET is the numerical IP representation of your +organization in the form xxx.xxx.xxx.xxx/xx: <pre>acl internal { SUBNET ; localhost; @@ -142,23 +158,39 @@ zone "internal.example.com " IN { ... };</pre> </description> -<rationale>Enterprise nameservers generally serve two functions. One is to provide public information about the machines in a domain for the benefit of outside users who wish to contact those machines, for instance in order to send mail to users in the enterprise, or to visit the enterprise’s external web page. The other is to provide nameservice to client machines within the enterprise. Client machines require both private information about enterprise machines (which may be different from the public information served to the rest of the world) and public information about machines outside the enterprise, which is used to send mail or visit websites outside of the organization. +<rationale>Enterprise nameservers generally serve two functions. One is to +provide public information about the machines in a domain for the benefit of +outside users who wish to contact those machines, for instance in order to send +mail to users in the enterprise, or to visit the enterprise’s external web +page. The other is to provide nameservice to client machines within the +enterprise. Client machines require both private information about enterprise +machines (which may be different from the public information served to the rest +of the world) and public information about machines outside the enterprise, +which is used to send mail or visit websites outside of the organization. <br /> -In order to provide the public nameservice function, it is necessary to share data with untrusted machines which request it — otherwise, the enterprise cannot be conveniently contacted by outside users. However, internal data should be protected from disclosure, and serving irrelevant public name queries for outside domains leaves the DNS server open to cache poisoning and other attacks. Therefore, local network nameservice functions should not be provided to untrusted machines. +In order to provide the public nameservice function, it is necessary to share +data with untrusted machines which request it — otherwise, the enterprise +cannot be conveniently contacted by outside users. However, internal data +should be protected from disclosure, and serving irrelevant public name queries +for outside domains leaves the DNS server open to cache poisoning and other +attacks. Therefore, local network nameservice functions should not be provided +to untrusted machines. <br /> Separate machines should be used to fill these two functions whenever possible. </rationale> + <!--<ident cce="3985-9, 4487-5, 4258-0" /> --> <!--<oval id="dns_server_seperate_internal_external" />--> <!--<ref nist="CM-6, CM-7" />--> -</Rule> +</Group>
-<Rule id="dns_server_partition_with_views"> +<Group id="dns_server_partition_with_views"> <title>Use Views to Partition External and Internal Information</title> -<description>If it is not possible to run external and internal nameservers on separate physical machines, run BIND9 and -simulate this feature using views. -Edit <tt>/etc/named.conf</tt>. Add or correct the following directives (where SUBNET is the numerical IP represen- -tation of your organization in the form xxx.xxx.xxx.xxx/xx): +<description>If it is not possible to run external and internal nameservers on +separate physical machines, run BIND9 and simulate this feature using views. +Edit <tt>/etc/named.conf</tt>. Add or correct the following directives (where +SUBNET is the numerical IP representation of your organization in the form +xxx.xxx.xxx.xxx/xx): <pre>acl internal { SUBNET ; localhost; @@ -182,18 +214,28 @@ view "external-view" { }; };</pre> </description> -<rationale>The view feature is provided by BIND9 as a way to allow a single nameserver to make different sets of data available to different sets of clients. If possible, it is always better to run external and internal nameservers on separate machines, so that even complete compromise of the external server cannot be used to obtain internal data or confuse internal DNS clients. However, this is not always feasible, and use of a feature like views is preferable to leaving internal DNS data entirely unprotected.</rationale> -<warning category="general">As shown in the example, database files which are required for recursion, such as the root hints file, must be available to any clients which are allowed to make recursive queries. Under typical circumstances, this includes -only the internal clients which are allowed to use this server as a general-purpose nameserver.</warning> +<rationale>The view feature is provided by BIND9 as a way to allow a single +nameserver to make different sets of data available to different sets of +clients. If possible, it is always better to run external and internal +nameservers on separate machines, so that even complete compromise of the +external server cannot be used to obtain internal data or confuse internal DNS +clients. However, this is not always feasible, and use of a feature like views +is preferable to leaving internal DNS data entirely unprotected.</rationale> +<warning category="general">As shown in the example, database files which are +required for recursion, such as the root hints file, must be available to any +clients which are allowed to make recursive queries. Under typical +circumstances, this includes only the internal clients which are allowed to use +this server as a general-purpose nameserver.</warning> <!--<ident cce="3985-9, 4487-5, 4258-0" /> --> <!--<oval id="dns_server_partition_with_views" />--> <!--<ref nist="CM-6, CM-7" />--> -</Rule> +</Group>
-<Rule id="dns_server_disable_zone_transfers"> +<Group id="dns_server_disable_zone_transfers"> <title>Disable Zone Transfers from the Nameserver</title> -<description>Is it necessary for a secondary nameserver to receive zone data via zone transfer from the primary server? -If not, follow the instructions in this section. If so, see the next section for instructions on protecting zone +<description>Is it necessary for a secondary nameserver to receive zone data +via zone transfer from the primary server? If not, follow the instructions in +this section. If so, see the next section for instructions on protecting zone transfers. Edit <tt>/etc/named.conf</tt>. Add or correct the following directive: <pre>options { @@ -201,23 +243,26 @@ Edit <tt>/etc/named.conf</tt>. Add or correct the following directive: ... }</pre> </description> -<rationale>If both the primary and secondary nameserver are under your control, or if you have only one nameserver, it may -be possible to use an external configuration management mechanism to distribute zone updates. In that case, it -is not necessary to allow zone transfers within BIND itself, so they should be disabled to avoid the potential for -abuse.</rationale> +<rationale>If both the primary and secondary nameserver are under your control, +or if you have only one nameserver, it may be possible to use an external +configuration management mechanism to distribute zone updates. In that case, it +is not necessary to allow zone transfers within BIND itself, so they should be +disabled to avoid the potential for abuse.</rationale> <!--<ident cce="3985-9, 4487-5, 4258-0" /> --> <!--<oval id="dns_server_disable_zone_transfers" />--> <!--<ref nist="CM-6, CM-7" />--> -</Rule> +</Group>
-<Rule id="dns_server_authenticate_zone_transfers"> +<Group id="dns_server_authenticate_zone_transfers"> <title>Authenticate Zone Transfers</title> -<description>If it is necessary for a secondary nameserver to receive zone data via zone transfer from the primary server, follow the instructions here. -Use dnssec-keygen to create a symmetric key file in the current directory: +<description>If it is necessary for a secondary nameserver to receive zone data +via zone transfer from the primary server, follow the instructions here. Use +dnssec-keygen to create a symmetric key file in the current directory: <pre># cd /tmp # dnssec-keygen -a HMAC-MD5 -b 128 -n HOST dns.example.com Kdns.example.com .+aaa +iiiii</pre> -This output is the name of a file containing the new key. Read the file to find the base64-encoded key string: +This output is the name of a file containing the new key. Read the file to find +the base64-encoded key string: <pre># cat Kdns.example.com .+NNN +MMMMM .key dns.example.com IN KEY 512 3 157 base64-key-string</pre> Edit <tt>/etc/named.conf</tt> on the primary nameserver. Add the directives: @@ -246,23 +291,42 @@ zone "example.com " IN { ... };</pre> </description> -<rationale>The BIND transaction signature (TSIG) functionality allows primary and secondary nameservers to use a shared secret to verify authorization to perform zone transfers. This method is more secure than using IP-based limiting to restrict nameserver access, since IP addresses can be easily spoofed. However, if you cannot configure TSIG between your servers because, for instance, the secondary nameserver is not under your control and its administrators are unwilling to configure TSIG, you can configure an allow-transfer directive with numerical IP addresses or ACLs as a last resort. +<rationale>The BIND transaction signature (TSIG) functionality allows primary +and secondary nameservers to use a shared secret to verify authorization to +perform zone transfers. This method is more secure than using IP-based limiting +to restrict nameserver access, since IP addresses can be easily spoofed. +However, if you cannot configure TSIG between your servers because, for +instance, the secondary nameserver is not under your control and its +administrators are unwilling to configure TSIG, you can configure an +allow-transfer directive with numerical IP addresses or ACLs as a last resort. </rationale> -<warning category="general">The purpose of the dnssec-keygen command is to create the shared secret string base64-key-string. Once this secret has been obtained and inserted into named.conf on the primary and secondary servers, the key files Kdns.example.com .+NNN +MMMMM .key and Kdns.example.com .+NNN +MMMMM .private are no longer needed, and may safely be deleted.</warning> +<warning category="general">The purpose of the dnssec-keygen command is to +create the shared secret string base64-key-string. Once this secret has been +obtained and inserted into named.conf on the primary and secondary servers, the +key files Kdns.example.com .+NNN +MMMMM .key and Kdns.example.com .+NNN +MMMMM +.private are no longer needed, and may safely be deleted.</warning> <!--<ident cce="3985-9, 4487-5, 4258-0" /> --> <!--<oval id="dns_server_authenticate_zone_transfers" />--> <!--<ref nist="CM-6, CM-7" />--> -</Rule> +</Group>
<Rule id="dns_server_disable_dynamic_updates"> <title>Disable Dynamic Updates</title> -<description>Is there a mission-critical reason to enable the risky dynamic update functionality? If not, edit <tt>/etc/named.conf</tt>. For each zone specification, correct the following directive if necessary: +<description>Is there a mission-critical reason to enable the risky dynamic +update functionality? If not, edit <tt>/etc/named.conf</tt>. For each zone +specification, correct the following directive if necessary: <pre>zone "example.com " IN { allow-update { none; }; ... };</pre> </description> -<rationale>Dynamic updates allow remote servers to add, delete, or modify any entries in your zone file. Therefore, they should be considered highly risky, and disabled unless there is a very good reason for their use. If dynamic updates must be allowed, IP-based ACLs are insufficient protection, since they are easily spoofed. Instead, use TSIG keys (see the previous section for an example), and consider using the update-policy directive to restrict changes to only the precise type of change needed.</rationale> +<rationale>Dynamic updates allow remote servers to add, delete, or modify any +entries in your zone file. Therefore, they should be considered highly risky, +and disabled unless there is a very good reason for their use. If dynamic +updates must be allowed, IP-based ACLs are insufficient protection, since they +are easily spoofed. Instead, use TSIG keys (see the previous section for an +example), and consider using the update-policy directive to restrict changes to +only the precise type of change needed.</rationale> <ident cce="4399-2" /> <!--<oval id="dns_server_disable_dynamic_updates" />--> <!--<ref nist="CM-6, CM-7" />-->
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil --- RHEL6/input/services/ftp.xml | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/RHEL6/input/services/ftp.xml b/RHEL6/input/services/ftp.xml index da1bc7a..da0a476 100644 --- a/RHEL6/input/services/ftp.xml +++ b/RHEL6/input/services/ftp.xml @@ -114,7 +114,7 @@ these logins as much as possible.</description> <!--<ref nist="CM-6, CM-7" /> --> </Rule>
-<Rule id="ftp_limit_users"> +<Group id="ftp_limit_users"> <title>Limit Users Allowed FTP Access if Necessary</title> <description>If there is a mission-critical reason for users to access their accounts via the insecure FTP protocol, limit the set of users who are allowed this access. Edit the vsftpd configuration file. Add or correct the following configuration options: <pre>userlist_enable=YES @@ -130,7 +130,7 @@ ftp</pre> <!--<ident cce="4443-8" />--> <!--<oval id="ftp_limit_users" />--> <!--<ref nist="CM-6, CM-7" /> --> -</Rule> +</Group>
</Group> <!-- <Group id="ftp_restrict_users"> -->
@@ -161,7 +161,7 @@ these users from filling a disk used by other services.</rationale> <!--<ref nist="CM-6, CM-7" /> --> </Rule>
-<Rule id="ftp_configure_firewall"> +<Group id="ftp_configure_firewall"> <title>Configure Firewalls to Protect the FTP Server</title> <description>Edit the file <tt>/etc/sysconfig/iptables</tt>. Add the following lines, ensuring that they appear before the final LOG and DROP lines for the RH-Firewall-1-INPUT chain: @@ -178,7 +178,7 @@ FTP server to operate on a machine which is running a firewall.</rationale> <!--<ident cce="4443-8" />--> <!--<oval id="ftp_configure_firewall" />--> <!--<ref nist="CM-6, CM-7" /> --> -</Rule> +</Group>
</Group> <!-- <Group id="ftp_configure_vsftpd"> --> </Group> <!-- <Group id="ftp"> -->
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil --- RHEL6/input/services/ldap.xml | 22 +++++++++++----------- 1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/RHEL6/input/services/ldap.xml b/RHEL6/input/services/ldap.xml index 6c2bebf..3ee8b64 100644 --- a/RHEL6/input/services/ldap.xml +++ b/RHEL6/input/services/ldap.xml @@ -188,7 +188,7 @@ LDAP server process would need to be restarted manually whenever the server rebo <ref nist="AC-6, CM-7, SC-11, SC-12, SC-13, SC-17" /> </Rule>
-<Rule id="ldap_server_config_directory_domain"> +<Group id="ldap_server_config_directory_domain"> <title>Create Top-level LDAP Structure for Domain</title> <description>Create a structure for the domain itself with at least the following attributes: <pre>dn: dc=example,dc=com @@ -202,9 +202,9 @@ any other entries for the domain. <!--<ident cce="TODO:CCE" />--> <!--oval id="MANUAL AUDIT" /--> <ref nist="AC-2" /> -</Rule> +</Group>
-<Rule id="ldap_server_config_directory_users_groups"> +<Group id="ldap_server_config_directory_users_groups"> <title>Create LDAP Structures for Users and Groups</title> <description>Create LDAP structures for people (users) and for groups with at least the following attributes: <pre>dn: ou=people,dc=example,dc=com @@ -221,9 +221,9 @@ These organizational units are used to identify the two categories within LDAP. <!--<ident cce="TODO:CCE" />--> <!--oval id="MANUAL AUDIT" /--> <ref nist="AC-2, AC-6, SC-2" /> -</Rule> +</Group>
-<Rule id="ldap_server_config_directory_accounts"> +<Group id="ldap_server_config_directory_accounts"> <title>Create Unix Accounts</title> <description>For each Unix user, create an LDAP entry with at least the following attributes (others may be appropriate for your site as well), using variable values appropriate to that user. @@ -251,9 +251,9 @@ but only for user accounts which are to be shared across machines, and which hav <!--<ident cce="TODO:CCE" />--> <!--oval id="MANUAL AUDIT" /--> <ref nist="AC-2, CM-7, SC-2" /> -</Rule> +</Group>
-<Rule id="ldap_server_config_directory_groups"> +<Group id="ldap_server_config_directory_groups"> <title>Create Unix Groups</title> <description>For each Unix group, create an LDAP entry with at least the following attributes: <pre>dn: cn=groupname ,ou=groups,dc=example,dc=com @@ -274,11 +274,11 @@ or which are shared across systems. <!--<ident cce="TODO:CCE" />--> <!--oval id="MANUAL AUDIT" /--> <ref nist="AC-2, CM-7, SC-2" /> -</Rule> +</Group>
-<Rule id="ldap_server_config_directory_admin_group"> +<Group id="ldap_server_config_directory_admin_group"> <title>Create Groups to Administer LDAP</title> -<description>If a group of LDAP administrators, admins , is desired, that group must be created somewhat differently. +<description>If a group of LDAP administrators is desired, that group must be created somewhat differently. The specification should have these attributes: <pre>dn: cn=admins ,ou=groups,dc=example,dc=com cn: admins @@ -297,7 +297,7 @@ auditing and error detection, it is recommended that LDAP administrators have un <!--<ident cce="TODO:CCE" />--> <!--oval id="MANUAL AUDIT" /--> <ref nist="AC-2, CM-7, SC-2" /> -</Rule> +</Group>
<Rule id="ldap_server_config_olcaccess"> <title>Configure slapd to Protect Authentication Information</title>
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil --- RHEL6/input/services/mail.xml | 16 ++++++++-------- 1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/RHEL6/input/services/mail.xml b/RHEL6/input/services/mail.xml index 61a9f70..d0016bc 100644 --- a/RHEL6/input/services/mail.xml +++ b/RHEL6/input/services/mail.xml @@ -87,7 +87,7 @@ and not from the network, which protects it from network attack. <description>The guidance in this section is appropriate for any host which is operating as a site MTA, whether the mail server runs using Sendmail, Postfix, or some other software. </description>
-<Rule id="postfix_seperate_internal_external"> +<Group id="postfix_seperate_internal_external"> <title>Use Separate Hosts for External and Internal Mail if Possible</title> <description>The mail server is a frequent target of network attack from the outside. However, since all site users receive mail, the mail server must be open to some connection from each inside users. It is strongly recommended that these @@ -96,9 +96,9 @@ mail, then forwards internal mail to a separate machine from which users can acc </description> <!-- <ident cce="TODO:CCE" /> --> <ref nist="CM-7, SC-5, SC-7" /> -</Rule> +</Group>
-<Rule id="postfix_restrict_user_access"> +<Group id="postfix_restrict_user_access"> <title>Protect the MTA Host from User Access</title> <description>The mail server contains privileged data belonging to all users and performs a vital network function. Preventing users from logging into this server is a precaution against @@ -107,9 +107,9 @@ steps to ensure that only system administrators are allowed shell access to the </description> <!-- <ident cce="TODO:CCE" /> --> <ref nist="AC-6, SC-2" /> -</Rule> +</Group>
-<Rule id="postfix_restrict_mail_spool_access"> +<Group id="postfix_restrict_mail_spool_access"> <title>Restrict Remote Access to the Mail Spool</title> <description>The mail server contains privileged data belonging to all users and performs a vital network function. Preventing users from logging into this server is a precaution against privilege @@ -118,7 +118,7 @@ ensure that only system administrators are allowed shell access to the MTA host. </description> <!-- <ident cce="TODO:CCE" /> --> <ref nist="AC-2, AC-4, CM-7, SC-2" /> -</Rule> +</Group>
<Rule id="iptables_smtp_enabled"> <title>Configure iptables to Allow Access to the Mail Server</title> @@ -157,7 +157,7 @@ though such configurations are beyond the scope of this guide. In either event, an SSL certificate are independent of the MTA in use, and are described here. </description>
-<Rule id="postfix_create_cert"> +<Group id="postfix_create_cert"> <title>Create an SSL Certificate</title> <description> Change into the CA certificate directory: @@ -181,7 +181,7 @@ CA sign certificates, then this step should be performed on a separate, physical purpose.</warning> <!-- <ident cce="TODO:CCE" /> --> <ref nist="CM-7, SC-12" /> -</Rule> +</Group>
<Rule id="postfix_install_ssl_cert"> <title>Install the SSL Certificate</title>
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil --- RHEL6/input/services/ssh.xml | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/RHEL6/input/services/ssh.xml b/RHEL6/input/services/ssh.xml index aece8f3..19c17f0 100644 --- a/RHEL6/input/services/ssh.xml +++ b/RHEL6/input/services/ssh.xml @@ -312,7 +312,7 @@ implementation. These are also required for compliance. <ref disa="803,1144,1145,1146,196" /> </Rule>
-<Rule id="sshd_strengthen_firewall"> +<Group id="sshd_strengthen_firewall"> <title>Strengthen Firewall Configuration if Possible</title> <description>If the SSH server is expected to only receive connections from the local network, then strengthen the default firewall rule for the SSH service @@ -332,7 +332,7 @@ Restricting SSH access to only trusted network segments reduces exposure of the server to attacks from unauthorized networks.</rationale> <!-- <ident cce="14491-5" /> --> <!-- <oval id="sshd_strengthen_firewall" /> --> -</Rule> +</Group>
</Group> </Group>
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil --- RHEL6/input/services/smb.xml | 124 ++++++++++++++++++++++++++++++------------ 1 files changed, 89 insertions(+), 35 deletions(-)
diff --git a/RHEL6/input/services/smb.xml b/RHEL6/input/services/smb.xml index 80481b5..7c54e33 100644 --- a/RHEL6/input/services/smb.xml +++ b/RHEL6/input/services/smb.xml @@ -53,8 +53,10 @@ additional limitations be set in place.</description> <tt>guest ok</tt> to <tt>yes</tt>. If so remove or set to: <pre>[share] guest ok = no</pre> -Note that setting a share to <tt>guest ok = yes</tt> will override the global settings. Ensure no share contains <tt>guest ok = yes</tt>. -It is safe to disable local login support for remote Samba users. Consider changing the add user account script to set remote user shells to /sbin/nologin. +Note that setting a share to <tt>guest ok = yes</tt> will override the global +settings. Ensure no share contains <tt>guest ok = yes</tt>. It is safe to +disable local login support for remote Samba users. Consider changing the add +user account script to set remote user shells to /sbin/nologin. </description> <rationale> Do not allow guest users to access local file or printer shares.</rationale>--> @@ -64,12 +66,18 @@ Do not allow guest users to access local file or printer shares.</rationale>-->
<Rule id="smb_server_disable_root"> <title>Disable Root Access</title> -<description>Administrators should not use administrator accounts to access Samba file and printer shares. Disable the root user and the wheel administrator group: +<description>Administrators should not use administrator accounts to access +Samba file and printer shares. Disable the root user and the wheel +administrator group: <pre>[share] invalid users = root @wheel</pre> -If administrator accounts cannot be disabled, ensure that local machine passwords and Samba service passwords do not match.</description> +If administrator accounts cannot be disabled, ensure that local machine +passwords and Samba service passwords do not match.</description> <rationale> -Typically, administrator access is required when Samba must create user and machine accounts and shares. Domain member servers and standalone servers may not need administrator access at all. If that is the case, add the invalid users parameter to [global] instead. +Typically, administrator access is required when Samba must create user and +machine accounts and shares. Domain member servers and standalone servers may +not need administrator access at all. If that is the case, add the invalid +users parameter to [global] instead. </rationale> <!--<ident cce="TODO:CCE" />--> <!--<oval id="smb_server_disable_root" />--> @@ -77,62 +85,96 @@ Typically, administrator access is required when Samba must create user and mach
<Rule id="smb_set_auth_levels"> <title>Disable Root Access</title> -<description>By default, Samba will attempt to negotiate with Microsoft Windows machines to set a common communication protocol. -Newer versions of Microsoft Windows may require the use of NTLMv2. NTLMv2 is the preferred protocol for authentication, but since older machines do not support it, Samba has disabled it by default. Enable it with the following: +<description>By default, Samba will attempt to negotiate with Microsoft Windows +machines to set a common communication protocol. Newer versions of Microsoft +Windows may require the use of NTLMv2. NTLMv2 is the preferred protocol for +authentication, but since older machines do not support it, Samba has disabled +it by default. Enable it with the following: <pre>[global] client ntlmv2 auth = yes</pre> -<!-- This is the default: Whenever possible, be sure to disable LANMAN authentication, as it is far weaker than the other supported protocols. +<!-- This is the default: Whenever possible, be sure to disable LANMAN + authentication, as it is far weaker than the other supported protocols. <pre>[global] - client lanman auth = no</pre>--> -</description> -<rationale> -For the sake of backwards compatibility, most modern Windows machines will still allow other machines to communicate with them over weak protocols such as LANMAN. On Samba, by enabling NTLMv2, you are also disabling LANMAN and NTLMv1. If NTLMv1 is required, it is still possible to individually disable LANMAN.</rationale> + client lanman auth = no</pre>--> </description> +<rationale> For the sake of backwards compatibility, most modern Windows +machines will still allow other machines to communicate with them over weak +protocols such as LANMAN. On Samba, by enabling NTLMv2, you are also disabling +LANMAN and NTLMv1. If NTLMv1 is required, it is still possible to individually +disable LANMAN. +</rationale> <!--<ident cce="TODO:CCE" />--> <!--<oval id="smb_set_auth_levels" />--> </Rule>
-<Rule id="smb_add_machine_script"> +<Group id="smb_add_machine_script"> <title>Let Domain Controllers Create Machine Trust Accounts On-the-Fly</title> -<description>Add or correct an add machine script entry to the <tt>[global]</tt> section of <tt>/etc/samba/smb.conf</tt> to allow -Samba to dynamically create Machine Trust Accounts: +<description>Add or correct an add machine script entry to the +<tt>[global]</tt> section of <tt>/etc/samba/smb.conf</tt> to allow Samba to +dynamically create Machine Trust Accounts: <pre>[global] add machine script = /usr/sbin/useradd -n -g machines -d /dev/null -s /sbin/nologin %u</pre> Make sure that the group machines exists. If not, add it with the following command: <pre># /usr/sbin/groupadd machines</pre> </description> -<rationale>When acting as a PDC, it becomes necessary to create and store Machine Trust Accounts for each machine that joins the domain. On a Microsoft Windows PDC, this account is created with the Server Manager tool, but on a Samba PDC, two accounts must be created. The first is the local machine account, and the second is the Samba account. For security purposes, it is recommended to let Samba create these accounts on-the-fly. When Machine Trust Accounts are created manually, there is a small window of opportunity in which a rogue machine could join the domain in place of the new server.</rationale> +<rationale>When acting as a PDC, it becomes necessary to create and store +Machine Trust Accounts for each machine that joins the domain. On a Microsoft +Windows PDC, this account is created with the Server Manager tool, but on a +Samba PDC, two accounts must be created. The first is the local machine +account, and the second is the Samba account. For security purposes, it is +recommended to let Samba create these accounts on-the-fly. When Machine Trust +Accounts are created manually, there is a small window of opportunity in which +a rogue machine could join the domain in place of the new server.</rationale> <!--<ident cce="TODO:CCE" />--> <!--<oval id="smb_add_machine_script" />--> -</Rule> +</Group>
-<Rule id="smb_restrict_access_ipc"> +<Group id="smb_restrict_access_ipc"> <title>Restrict Access to the [IPC$] Share</title> -<description>Limit access to the <tt>[IPC$]</tt> share so that only machines in your network will be able to connect to it: +<description>Limit access to the <tt>[IPC$]</tt> share so that only machines in +your network will be able to connect to it: <pre>[IPC$] hosts allow = 192.168.1. 127.0.0.1 hosts deny = 0.0.0.0/0</pre> </description> -<rationale>The <tt>[IPC$]</tt> share allows users to anonymously fetch a list of shared resources from a server. It is intended to allow users to browse the list of available shares. It also can be used as a point of attack into a system. Disabling it completely may break some functionality, so it is recommended that you merely limit access to it instead.</rationale> +<rationale>The <tt>[IPC$]</tt> share allows users to anonymously fetch a list +of shared resources from a server. It is intended to allow users to browse the +list of available shares. It also can be used as a point of attack into a +system. Disabling it completely may break some functionality, so it is +recommended that you merely limit access to it instead. +</rationale> <!--<ident cce="TODO:CCE" />--> <!--<oval id="smb_restrict_access_ipc" />--> -</Rule> +</Group>
-<Rule id="smb_restrict_file_sharing"> +<Group id="smb_restrict_file_sharing"> <title>Restrict File Sharing</title> -<description>Only users with local user accounts will be able to log in to Samba shares by default. Shares can be limited to particular users or network addresses. Use the <tt>hosts allow</tt> and <tt>hosts deny</tt> directives accordingly, and consider setting the valid users directive to a limited subset of users or to a group of users. Separate each -address, user, or user group with a space as follows: +<description>Only users with local user accounts will be able to log in to +Samba shares by default. Shares can be limited to particular users or network +addresses. Use the <tt>hosts allow</tt> and <tt>hosts deny</tt> directives +accordingly, and consider setting the valid users directive to a limited subset +of users or to a group of users. Separate each address, user, or user group +with a space as follows: <pre>[share] hosts allow = 192.168.1. 127.0.0.1 valid users = userone usertwo @usergroup</pre> -It is also possible to limit read and write access to particular users with the read list and write list options, though the permissions set by the system itself will override these settings. Set the read only attribute for each share to ensure that global settings will not accidentally override the individual share settings. Then, as with the valid users directive, separate each user or group of users with a space: +It is also possible to limit read and write access to particular users with the +read list and write list options, though the permissions set by the system +itself will override these settings. Set the read only attribute for each share +to ensure that global settings will not accidentally override the individual +share settings. Then, as with the valid users directive, separate each user or +group of users with a space: <pre>[share] read only = yes write list = userone usertwo @usergroup</pre> </description> -<rationale>The Samba service is only required for sharing files and printers with Microsoft Windows workstations, and even then, other options may exist. Do not use the Samba service to share files between Unix or Linux machines. </rationale> + +<rationale>The Samba service is only required for sharing files and printers +with Microsoft Windows workstations, and even then, other options may exist. Do +not use the Samba service to share files between Unix or Linux machines. +</rationale> <!--<ident cce="TODO:CCE" />--> <!--<oval id="smb_restrict_file_sharing" />--> -</Rule> +</Group>
<Rule id="require_smb_client_signing"> <title>Require Client SMB Packet Signing, if using @@ -157,8 +199,7 @@ transit.
<Rule id="require_smb_client_signing_mount.cifs"> -<title>Require Client SMB Packet Signing, if using -mount.cifs</title> +<title>Require Client SMB Packet Signing, if using mount.cifs</title> <description>Require packet signing of clients who mount Samba shares using the <tt>mount.cifs</tt> program (e.g., those who specify shares in <tt>/etc/fstab</tt>). To do so, ensure that signing options (either @@ -176,9 +217,13 @@ attacks which modify SMB packets in transit. <oval id="mount_option_smb_client_signing" /> </Rule>
-<Rule id="smb_disable_printing"> +<Group id="smb_disable_printing"> <title>Restrict Printer Sharing</title> -<description>By default, Samba utilizes the CUPS printing service to enable printer sharing with Microsoft Windows workstations. If there are no printers on the local machine, or if printer sharing with Microsoft Windows is not required, disable the printer sharing capability by commenting out the following lines, found in <tt>/etc/samba/smb.conf</tt>: +<description>By default, Samba utilizes the CUPS printing service to enable +printer sharing with Microsoft Windows workstations. If there are no printers +on the local machine, or if printer sharing with Microsoft Windows is not +required, disable the printer sharing capability by commenting out the +following lines, found in <tt>/etc/samba/smb.conf</tt>: <pre>[global] load printers = yes cups options = raw @@ -189,15 +234,24 @@ attacks which modify SMB packets in transit. guest ok = no writable = no printable = yes</pre> -There may be other options present, but these are the only options enabled and uncommented by default. Removing the <tt>[printers]</tt> share should be enough for most users. -If the Samba printer sharing capability is needed, consider disabling the Samba network browsing capability or restricting access to a particular set of users or network addresses. Set the <tt>valid users</tt> parameter to a small subset of users or restrict it to a particular group of users with the shorthand <tt>@</tt>. Separate each user or group of users with a space. For example, under the <tt>[printers]</tt> share: +There may be other options present, but these are the only options enabled and +uncommented by default. Removing the <tt>[printers]</tt> share should be enough +for most users. If the Samba printer sharing capability is needed, consider +disabling the Samba network browsing capability or restricting access to a +particular set of users or network addresses. Set the <tt>valid users</tt> +parameter to a small subset of users or restrict it to a particular group of +users with the shorthand <tt>@</tt>. Separate each user or group of users with +a space. For example, under the <tt>[printers]</tt> share: <pre>[printers] valid users = user @printerusers</pre> </description> -<rationale>The Samba service is only required for sharing files and printers with Microsoft Windows workstations, and even then, other options may exist. Do not use the Samba service to share files between Unix or Linux machines. </rationale> +<rationale>The Samba service is only required for sharing files and printers +with Microsoft Windows workstations, and even then, other options may exist. Do +not use the Samba service to share files between Unix or Linux machines. +</rationale> <!--<ident cce="TODO:CCE" />--> <!--<oval id="smb_disable_printing" />--> -</Rule> +</Group>
</Group> <!--<Group id="configuring_samba">--> </Group> <!--<Group id="smb">-->
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil --- RHEL6/input/services/snmp.xml | 11 ++++++----- 1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/RHEL6/input/services/snmp.xml b/RHEL6/input/services/snmp.xml index 820270e..927119b 100644 --- a/RHEL6/input/services/snmp.xml +++ b/RHEL6/input/services/snmp.xml @@ -44,11 +44,12 @@ activation.
</Group> <!-- <Group id="disabling_snmp_service"> -->
-<Rule id="snmp_configure_server"> +<Group id="snmp_configure_server"> <title>Configure SNMP Server if Necessary</title> -<description>If it is necessary to run the snmpd agent on the system, some best practices should be followed to minimize the -security risk from the installation. The multiple security models implemented by SNMP cannot be fully covered -here so only the following general configuration advice can be offered: +<description>If it is necessary to run the snmpd agent on the system, some best +practices should be followed to minimize the security risk from the +installation. The multiple security models implemented by SNMP cannot be fully +covered here so only the following general configuration advice can be offered: <ul> <li>use only SNMP version 3 security models and enable the use of authentication and encryption</li> <li>write access to the MIB (Management Information Base) should be allowed only if necessary</li> @@ -62,6 +63,6 @@ stations</li> </description> <!--<ident cce="14081-4" /> --> <!--<oval id="snmp_configure_server" /> --> -</Rule> +</Group>
</Group> <!-- <Group id="snmp"> -->
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil --- RHEL6/input/system/network/iptables.xml | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/RHEL6/input/system/network/iptables.xml b/RHEL6/input/system/network/iptables.xml index dc3a584..31237b7 100644 --- a/RHEL6/input/system/network/iptables.xml +++ b/RHEL6/input/system/network/iptables.xml @@ -161,7 +161,7 @@ accepted.</rationale> <ref nist="AC-4, CM-6" disa="1109" /> </Rule>
-<Rule id="iptables_icmp_disabled"> +<Group id="iptables_icmp_disabled"> <title>Restrict ICMP Message Types</title> <description>In <tt>/etc/sysconfig/iptables</tt>, the accepted ICMP messages types can be restricted. To accept only ICMP echo reply, destination unreachable, and time exceeded messages, remove the line:<br /> <pre>-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT</pre> @@ -179,14 +179,14 @@ If you are going to statically configure the machine’s address, it should igno could add another IPv6 address to the interface or alter important network settings: <pre>-A RH-Firewall-1-INPUT -p icmpv6 --icmpv6-type router-advertisement -j DROP</pre> </description> +<ref nist="AC-4, CM-6" /> <rationale>Restricting other ICMPv6 message types in <tt>/etc/sysconfig/ip6tables</tt> is not recommended because the oper- ation of IPv6 depends heavily on ICMPv6. Thus, more care must be taken when blocking ICMPv6 types.</rationale> <!--<ident cce="14264-6" />--> -<oval id="iptables_icmp_disabled" /> -<ref nist="AC-4, CM-6" /> -</Rule> +<!--<oval id="iptables_icmp_disabled" />--> +</Group>
-<Rule id="iptables_log_and_drop_suspicious"> +<Group id="iptables_log_and_drop_suspicious"> <title>Log and Drop Packets with Suspicious Source Addresses</title> <description>Packets with non-routable source addresses should be rejected, as they may indicate spoofing. Because the modified policy will reject non-matching packets, you only need to add these rules if you are interested in also @@ -232,7 +232,7 @@ The following rule will log all traffic originating from a site-local address, w <!--<ident cce="14264-6" />--> <!--MANUAL<oval id="iptables_log_and_drop_suspicious" />--> <ref nist="AC-4, AC-17, CM-6" /> -</Rule> +</Group>
</Group><!--<Group id="ruleset_modifications">--> </Group><!--<Group id="network-iptables">-->
ACK to all 16 -- looks like a good, long grind towards our common goal. Thank you David!!
Can't wait to see it pushed, and download it / try it.
MM
On 09/21/2012 03:11 PM, David Smith wrote:
Signed-off-by: David Smith dsmith@eclipse.ncsc.mil
RHEL6/input/system/network/iptables.xml | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/RHEL6/input/system/network/iptables.xml b/RHEL6/input/system/network/iptables.xml index dc3a584..31237b7 100644 --- a/RHEL6/input/system/network/iptables.xml +++ b/RHEL6/input/system/network/iptables.xml @@ -161,7 +161,7 @@ accepted.</rationale>
<ref nist="AC-4, CM-6" disa="1109" /> </Rule>
-<Rule id="iptables_icmp_disabled"> +<Group id="iptables_icmp_disabled">
<title>Restrict ICMP Message Types</title> <description>In <tt>/etc/sysconfig/iptables</tt>, the accepted ICMP messages types can be restricted. To accept only ICMP echo reply, destination unreachable, and time exceeded messages, remove the line:<br /> <pre>-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT</pre> @@ -179,14 +179,14 @@ If you are going to statically configure the machine’s address, it should igno could add another IPv6 address to the interface or alter important network settings: <pre>-A RH-Firewall-1-INPUT -p icmpv6 --icmpv6-type router-advertisement -j DROP</pre> </description> +<ref nist="AC-4, CM-6" /> <rationale>Restricting other ICMPv6 message types in <tt>/etc/sysconfig/ip6tables</tt> is not recommended because the oper- ation of IPv6 depends heavily on ICMPv6. Thus, more care must be taken when blocking ICMPv6 types.</rationale> <!--<ident cce="14264-6" />--> -<oval id="iptables_icmp_disabled" /> -<ref nist="AC-4, CM-6" /> -</Rule> +<!--<oval id="iptables_icmp_disabled" />--> +</Group>
-<Rule id="iptables_log_and_drop_suspicious"> +<Group id="iptables_log_and_drop_suspicious">
<title>Log and Drop Packets with Suspicious Source Addresses</title> <description>Packets with non-routable source addresses should be rejected, as they may indicate spoofing. Because the modified policy will reject non-matching packets, you only need to add these rules if you are interested in also @@ -232,7 +232,7 @@ The following rule will log all traffic originating from a site-local address, w <!--<ident cce="14264-6" />--> <!--MANUAL<oval id="iptables_log_and_drop_suspicious" />--> <ref nist="AC-4, AC-17, CM-6" /> -</Rule> +</Group>
</Group><!--<Group id="ruleset_modifications">--> </Group><!--<Group id="network-iptables">-->
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
Looks good, please push!
A lot of this was very badly overdue QA.
On 09/21/2012 06:11 PM, David Smith wrote:
This may affect some profiles, which will be addressed next week.
David Smith (16): quick fix to make things validate content editing for CUPS changed a rule to a group removed obsolete settings added new transform to validly order nodes inside Groups style updates to software updates section changing coarse-grained recommendations to Groups for DHCP changing HOWTO information about OpenSSL into Groups changed coarse-grained recommendations to Groups for BIND changed coarse-grained discussion to Groups for FTP changed HOWTO information for OpenLDAP server to Groups changed discussions about Postfix to Groups changed firewall discussion about SSH to a Group fixed indenting, reassigned Groups/Rules in Samba guidance changed a coarse discussion about SNMP to a Group changed wide-ranging discussion about IPtables rules to Group
RHEL6/input/services/avahi.xml | 4 +- RHEL6/input/services/dhcp.xml | 41 +++++--- RHEL6/input/services/dns.xml | 164 +++++++++++++++++++++--------- RHEL6/input/services/ftp.xml | 8 +- RHEL6/input/services/ldap.xml | 22 ++-- RHEL6/input/services/mail.xml | 16 ++-- RHEL6/input/services/obsolete.xml | 21 +++-- RHEL6/input/services/printing.xml | 122 +++++++++------------- RHEL6/input/services/smb.xml | 124 ++++++++++++++++------- RHEL6/input/services/snmp.xml | 11 +- RHEL6/input/services/ssh.xml | 4 +- RHEL6/input/services/xorg.xml | 61 +----------- RHEL6/input/system/network/iptables.xml | 12 +- RHEL6/input/system/network/ssl.xml | 106 ++++++++++++-------- RHEL6/input/system/software/updating.xml | 74 +++++++------- RHEL6/transforms/shorthand2xccdf.xslt | 14 +++ 16 files changed, 445 insertions(+), 359 deletions(-)
scap-security-guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
scap-security-guide@lists.fedorahosted.org
-
David Smith -
Jeffrey Blank -
Michael J. McConachie