[PATCH 09/16] changed coarse-grained recommendations to Groups for BIND

David Smith dsmith at eclipse.ncsc.mil
Fri Sep 21 22:11:10 UTC 2012


Signed-off-by: David Smith <dsmith at 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" />-->
-- 
1.7.1



More information about the scap-security-guide mailing list