Free DISA STIG and SRG Library | Vaulted

BIND 9.x Security Technical Implementation Guide

Version 1 Release 64
2019-04-262018-04-27
U_BIND_9-x_STIG_V1R64_Manual-xccdf.xml
This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DoD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil.

Compare Summary

Compare V1R6 to V1R4
  • All
  • Updated 9
  • Added 0
  • Removed 0

Vulnerabilities (70)

A BIND 9.x caching name server must implement DNSSEC validation to check all DNS queries for invalid input.

Finding ID
BIND-9X-001060
Rule ID
SV-87045r3_rule87045r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000447-DNS-000068
CCI
CCI-002754
Target Key
(None)
Documentable
No
Discussion

A common vulnerability of applications is unpredictable behavior when invalid inputs are received. This requirement guards against adverse or unintended system behavior caused by invalid inputs, where information system responses to the invalid input may be disruptive or cause the system to fail into an unsafe state. Attacks may be generated by entering invalid data into DNS transactions, in the hopes that the data will not be handled correctly and will allow a vulnerable condition to be exploited. To safeguard against this, all untrusted data entered in DNS transactions (e.g., DNS queries) should be checked for validity before being processed further.

Fix Text

Enable DNSSEC validation on the name server. Set the "dnssec-validation" sub statement in the global options block to "yes". Configure the "managed-keys" statement to use the root domains trust anchor. Restart the BIND 9.x process.

Check Content

If the server is not a caching name server, this is Not Applicable. If the server is in a classified network, this is Not Applicable. If the caching name server is only forwarding to the DISA ERS for query resolution and is not authoritative for any zones, DNSSEC awareness is not required since the ERS is validating. Verify that the server is configured to use DNSSEC validation for all DNS queries. Inspect the "named.conf" file for the following: options { dnssec-validation yes; }; managed-keys { "." initial-key 257 3 8 "<root-trust-anchor-data>"; }; If "dnssec-validation" is not set to "yes" or is missing, this is a finding. If the "managed-keys" statement is missing, this is a finding. Note: The <root-trust-anchor-data> should be replaced with the actual trust anchor.

The BIND 9.x server implementation must uniquely identify and authenticate the other DNS server before responding to a server-to-server transaction, zone transfer and/or dynamic update request using cryptographically based bidirectional authentication to protect the integrity of the information in transit.

Finding ID
BIND-9X-001100
Rule ID
SV-87053r2_rule87053r1_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000158-DNS-000015
CCI
CCI-002421
Target Key
(None)
Documentable
No
Discussion

Server-to-server (zone transfer) transactions are provided by TSIG, which enforces mutual server authentication using a key that is unique to each server pair (TSIG), thus uniquely identifying the other server. DNS does perform server authentication when TSIG is used, but this authentication is transactional in nature (each transaction has its own authentication performed). Enforcing mutually authenticated communication sessions during zone transfers provides the assurance that only authorized servers are requesting and receiving DNS zone data. Without authenticating devices, unidentified or unknown devices may be introduced, thereby facilitating malicious activity. Failure to properly implement transactional security may have significant effects on the overall security of the DNS infrastructure. The lack of mutual authentication between name servers during a DNS transaction would allow a threat actor to launch a Man-In-The-Middle attack against the DNS infrastructure. This attack could lead to unauthorized DNS zone data being introduced, resulting in network traffic being redirected to a rogue site. Satisfies: SRG-APP-000158-DNS-000015, SRG-APP-000390-DNS-000048, SRG-APP-000394-DNS-000049, SRG-APP-000395-DNS-000050, SRG-APP-000439-DNS-000063, SRG-APP-000440-DNS-000065

Fix Text

Configure the BIND 9.x server to use TSIG keys. Add a key statement to the "named.conf" file for TSIG that is being used: key tsig_example. { algorithm hmac-SHA1; include "tsig-example.key"; }; Add key statements to the allow-transfer statements on a master name server: allow-transfer { key tsig_example.; }; Add key statements to the server statements on a secondary name server: server <ip_address> { keys { tsig_example }; }; Restart the BIND 9.x process.

Check Content

If zone transfers are disabled with the "allow-transfer { none; };" directive, this is Not Applicable. If the server is in a classified network, this is Not Applicable. Verify that the BIND 9.x server is configured to uniquely identify a name server before responding to a zone transfer. Inspect the "named.conf" file for the presence of TSIG key statements: On the master name server, this is an example of a configured key statement: key tsig_example. { algorithm hmac-SHA1; include "tsig-example.key"; }; zone "disa.mil" { type master; file "db.disa.mil"; allow-transfer { key tsig_example.; }; }; On the slave name server, this is an example of a configured key statement: key tsig_example. { algorithm hmac-SHA1; include "tsig-example.key"; }; server &lt;ip_address> { keys { tsig_example }; }; zone "disa.mil" { type slave; masters { &lt;ip_address>; }; file "db.disa.mil"; }; If a master name server does not have a key defined in the “allow-transfer” block, this is a finding. If a secondary name server does not have a server statement that contains a "keys" sub statement, this is a finding.

The BIND 9.x server private key corresponding to the ZSK pair must be the only DNSSEC key kept on a name server that supports dynamic updates.

Finding ID
BIND-9X-001133
Rule ID
SV-87077r3_rule87077r2_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000176-DNS-000094
CCI
CCI-000186
Target Key
(None)
Documentable
No
Discussion

The private key in the ZSK key pair must be protected from unauthorized access. If possible, the private key should be stored off-line (with respect to the Internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. This strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file master copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets. Failure to protect the private ZSK opens it to being maliciously obtained and opens the DNS zone to being populated with invalid data. The integrity of the DNS zone would be compromised leading to a loss of trust whether a DNS response has originated from an authentic source, the response is complete, and has not been tampered with during transit.

Fix Text

Remove any non-ZSK private keyskey existingfrom on the name server other than the one corresponding to the active ZSK pair.

Check Content

If the server is in a classified network, this is Not Applicable. Determine if the BIND 9.x server is configured to allow dynamic updates. Review the "named.conf" file for any instance of the "allow-update" statement. The following example disables dynamic updates: allow-update {none;}; If the BIND 9.x implementation is not configured to allow dynamic updates, verify with the SA that the ZSK private key is stored offline. If it is not, this is a finding. If the BIND 9.x implementation is configured to allow dynamic updates, verify that the ZSK private key is the only key stored on the name server. For each signed zone file, identify the ZSK "key id" number: # cat &lt;signed_zone_file> | grep -i "zsk" ZSK; alg = RSASHA256; key id = 22335 Using the ZSK "key id", verify that the only private key stored on the system matches the "key id" Kexample.com.+008+22335.private If any non-ZSK private keys exist on the server other than the one corresponding to the active ZSK pair, this is a finding.

The BIND 9.x server validity period for the RRSIGs covering the DS RR for zones delegated children must be no less than two days and no more than one week.

Finding ID
BIND-9X-001311
Rule ID
SV-87099r2_rule87099r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000214-DNS-000079
CCI
CCI-001179
Target Key
(None)
Documentable
No
Discussion

The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and in the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a ZSK can use that key only during the KSK's signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing. To prevent the impact of a compromised KSK, a delegating parent should set the signature validity period for RRSIGs covering DS RRs in the range of a few days to 1 week. This re-signing does not require frequent rollover of the parent's ZSK, but scheduled ZSK rollover should still be performed at regular intervals.

Fix Text

Resign the child zone files and have the zone administrator provide updated DS resource records for the child zone.

Check Content

If the server is in a classified network, this is Not Applicable. With the assistance of the DNS Administrator, identify the RRSIGs that cover the DS resource records for each child zone. Each record will list an expiration and inception date, the difference of which will provide the validity period. The dates are listed in the following format: YYYYMMDDHHMMSS For each RRSIG identified, verify that the validity period is no less than two days and is no longer than seven days. If the validity period is outside of the specified range, this is a finding.

On the BIND 9.x server the private key corresponding to the ZSK, stored on name servers accepting dynamic updates, must be owned by root.

Finding ID
BIND-9X-001410
Rule ID
SV-87119r3_rule87119r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000111
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

The private ZSK key must be protected from unauthorized access. This strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file master copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets.

Fix Text

Change the ownership of the ZSK private key to the root account. # chown root <key_file>

Check Content

If the server is in a classified network, this is Not Applicable. Note: This check only verifies for ZSK key file ownership. Permissions for key files are required under V-72451, BIND-9X-001132 and V-72461, BIND-9X-001142. For each signed zone file, identify the ZSK "key id" number: # cat &lt;signed_zone_file> | grep -i "zsk" ZSK; alg = RSASHA256; key id = 22335 Using the ZSK "key id", identify the private ZSK. Kexample.com.+008+22335.private Verify that the private ZSK is owned by root: # ls -l &lt;ZSK_key_file> -r--------------- 1 root root 1776 Jul 3 17:56 Kexample.com.+008+22335.private If the key file is not owned by root, this is a finding.

On the BIND 9.x server the private key corresponding to the ZSK, stored on name servers accepting dynamic updates, must be group owned by root.

Finding ID
BIND-9X-001411
Rule ID
SV-87121r3_rule87121r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000111
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

The private ZSK key must be protected from unauthorized access. This strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file master copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets.

Fix Text

Change the group ownership of the ZSK private key to the root group account. # chgrp root <key_file>

Check Content

If the server is in a classified network, this is Not Applicable. Note: This check only verifies for ZSK key file ownership. Permissions for key files are required under V-72451, BIND-9X-001132 and V-72461, BIND-9X-001142. For each signed zone file, identify the ZSK "key id" number: # cat &lt;signed_zone_file> | grep -i "zsk" ZSK; alg = RSASHA256; key id = 22335 Using the ZSK "key id", verify the private ZSK. Kexample.com.+008+22335.private Verify that the private ZSK is owned by root: # ls -l &lt;ZSK_key_file> -r--------------- 1 root root 1776 Jul 3 17:56 Kexample.com.+008+22335.private If the key file is not group owned by root, this is a finding.

A BIND 9.x server validity period for the RRSIGs covering a zones DNSKEY RRSet must be no less than two days and no more than one week.

Finding ID
BIND-9X-001600
Rule ID
SV-87125r2_rule87125r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000078
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

The best way for a zone administrator to minimize the impact of a key compromise is by limiting the validity period of RRSIGs in the zone and in the parent zone. This strategy limits the time during which an attacker can take advantage of a compromised key to forge responses. An attacker that has compromised a ZSK can use that key only during the KSK's signature validity interval. An attacker that has compromised a KSK can use that key for only as long as the signature interval of the RRSIG covering the DS RR in the delegating parent. These validity periods should be short, which will require frequent re-signing.

Fix Text

Resign each zone that is outside of the validity period. Restart the BIND 9.x process.

Check Content

If the server is in a classified network, this is Not Applicable. With the assistance of the DNS Administrator, identify the RRSIGs that cover the DNSKEY resource record set for each zone. Each record will list an expiration and inception date, the difference of which will provide the validity period. The dates are listed in the following format: YYYYMMDDHHMMSS For each RRSIG identified, verify that the validity period is no less than two days and is no longer than seven days. If the validity period is outside of the specified range, this is a finding.

A BIND 9.x server NSEC3 must be used for all internal DNS zones.

Finding ID
BIND-9X-001610
Rule ID
SV-87127r4_rule87127r3_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000084
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

To ensure that RRs associated with a query are really missing in a zone file and have not been removed in transit, the DNSSEC mechanism provides a means for authenticating the nonexistence of an RR. It generates a special RR called an NSEC (or NSEC3) RR that lists the RRTypes associated with an owner name as well as the next name in the zone file. It sends this special RR, along with its signatures, to the resolving name server. By verifying the signature, a DNSSEC-aware resolving name server can determine which authoritative owner name exists in a zone and which authoritative RRTypes exist at those owner names.

Fix Text

Resign each zone that is missing NSEC records. Restart the BIND 9.x process.

Check Content

Note: If the server is in a classified network, this is Not Applicable. If the server is on an internal, restricted network with reserved IP space, this is Not Applicable. With the assistance of the DNS Administrator, identify each internal DNS zone listed in the "named.conf" file. For each internal zone identified, inspect the signed zone file for the NSEC resource records: 86400 NSEC example.com. A RRSIG NSEC If the zone file does not contain an NSEC record for the zone, this is a finding.

The BIND 9.x server implementation must prohibit the forwarding of queries to servers controlled by organizations outside of the U.S. Government.

Finding ID
BIND-9X-001702
Rule ID
SV-87143r2_rule87143r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000500
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

If remote servers to which DoD DNS servers send queries are controlled by entities outside of the U.S. Government the possibility of a DNS attack is increased. The Enterprise Recursive Service (ERS) provides the ability to apply enterprise-wide policy to all recursive DNS traffic that traverses the NIPRNet-to-Internet boundary. All recursive DNS servers on the NIPRNet must be configured to exclusively forward DNS traffic traversing NIPRNet-to-Internet boundary to the ERS anycast IPs. Organizations need to carefully configure any forwarding that is being used by their caching name servers. They should only configure "forwarding of all queries" to servers within the DoD. Systems configured to use domain-based forwarding should not forward queries for mission critical domains to any servers that are not under the control of the US Government.

Fix Text

Configure the BIND 9.x caching name server to utilize the DISA ERS anycast IP addresses. Edit the "named.conf" file and add the following to the global options statement: forward only; forwarders { <IP_ADDRESS_LIST>; }; Note: "<IP_ADDRESS_LIST>" should be replaced with the current ERS IP addresses. Restart the BIND 9.x process.

Check Content

If the server is not a caching server, this is Not Applicable. Note: The use of the DREN Enterprise Recursive DNS (Domain Name System) servers, as mandated by the DoDIN service provider Defense Research and Engineering Network (DREN), meets the intent of this requirement. Verify that the server is configured to forward all DNS traffic to the DISA Enterprise Recursive Service (ERS) anycast IP addresses ( &lt;IP_ADDRESS_LIST>; ): Inspect the "named.conf" file for the following: forward only; forwarders { &lt;IP_ADDRESS_LIST>; }; If the "named.conf" options are not set to forward queries only to the ERS anycast IPs, this is a finding. Note: "&lt;IP_ADDRESS_LIST>" should be replaced with the current ERS IP addresses.

A BIND 9.x server implementation must be running in a chroot(ed) directory structure.

Finding ID
BIND-9X-000001
Rule ID
SV-86987r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000243-DNS-000034
CCI
CCI-001090
Target Key
(None)
Documentable
No
Discussion

With any network service, there is the potential that an attacker can exploit a vulnerability within the program that allows the attacker to gain control of the process and even run system commands with that control. One possible defense against this attack is to limit the software to particular quarantined areas of the file system, memory or both. This effectively restricts the service so that it will not have access to the full file system. If such a defense were in place, then even if an attacker gained control of the process, the attacker would be unable to reach other commands or files on the system. This approach often is referred to as a padded cell, jail, or sandbox. All of these terms allude to the fact that the software is contained in an area where it cannot harm either itself or others. A more technical term is a chroot(ed) directory structure. BIND should be configured to run in a padded cell or chroot(ed) directory structure.

Fix Text

Configure the BIND 9.x server to operate in a chroot(ed) directory structure.

Check Content

Verify the directory structure where the primary BIND 9.x Server configuration files are stored is running in a chroot(ed) environment: # ps -ef | grep named named 3015 1 0 12:59 ? 00:00:00 /usr/sbin/named -u named -t /var/named/chroot If the output does not contain "-t <chroot_path>", this is a finding.

A BIND 9.x server implementation must be operating on a Current-Stable version as defined by ISC.

Finding ID
BIND-9X-001000
Rule ID
SV-86989r1_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000516-DNS-000097
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

The BIND STIG was written to incorporate capabilities and features provided in BIND version 9.9.x. However, it is recognized that security vulnerabilities in BIND are identified and then addressed on a regular, ongoing basis. Therefore it is required that the product be maintained at the latest stable versions in order to address vulnerabilities that are subsequently identified and can then be remediated via updates to the product. Failure to run a version of BIND that has the capability to implement all of the required security features and that does provide services compliant to the DNS RFCs can have a severe impact on the security posture of a DNS infrastructure. Without the required security in place, a DNS implementation is vulnerable to many types of attacks and could be used as a launching point for further attacks on the organizational network that is utilizing the DNS implementation. Satisfies: SRG-APP-000516-DNS-000097, SRG-APP-000516-DNS-000103

Fix Text

Update the BIND 9.x server to a version that is listed as “Current-Stable” by ISC.

Check Content

Verify that the BIND 9.x server is at a version that is considered "Current-Stable" by ISC. # named -v The above command should produce a version number similar to the following: BIND 9.9.4-RedHat-9.9.4-29.el7_2.3 If the server is running a version that is not listed as "Current-Stable" by ISC, this is a finding.

The platform on which the name server software is hosted must only run processes and services needed to support the BIND 9.x implementation.

Finding ID
BIND-9X-001002
Rule ID
SV-86991r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000109
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Hosts that run the name server software should not provide any other services. Unnecessary services running on the DNS server can introduce additional attack vectors leading to the compromise of an organization’s DNS architecture.

Fix Text

Disable or uninstall all non-DNS related applications from the BIND 9.x server.

Check Content

Verify that the BIND 9.x server is dedicated for DNS traffic: With the assistance of the DNS administrator, identify all of the processes running on the BIND 9.x server: # ps -ef | less If any of the identified processes are not in support of normal OS functionality or in support of the BIND 9.x process, this is a finding.

The BIND 9.x server software must run with restricted privileges.

Finding ID
BIND-9X-001003
Rule ID
SV-86993r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000105
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Failure to provide logical access restrictions associated with changes to application configuration may have significant effects on the overall security of the system. When dealing with access restrictions pertaining to change control, it should be noted that any changes to the hardware, software, and/or firmware components of the information system and/or application can have significant effects on the overall security of the system. Accordingly, only qualified and authorized individuals should be allowed to obtain access to application components for the purposes of initiating changes, including upgrades and modifications.

Fix Text

Configure the BIND 9.x process to run as a non-privileged user. Restart the BIND 9.x process.

Check Content

Verify the BIND 9.x process is not running as root: # ps -ef | grep named named 3015 1 0 12:59 ? 00:00:00 /usr/sbin/named -u named -t /var/named/chroot If the output shows "/usr/sbin/named -u root", this is a finding.

The host running a BIND 9.X implementation must implement a set of firewall rules that restrict traffic on the DNS interface.

Finding ID
BIND-9X-001004
Rule ID
SV-86995r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000109
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Configuring hosts that run a BIND 9.X implementation to only accept DNS traffic on a DNS interface allows a system firewall to be configured to limit the allowed incoming ports/protocols to 53/tcp and 53/udp. Sending outgoing DNS messages from a random port minimizes the risk of an attacker guessing the outgoing message port and sending forged replies. The TCP/IP stack in DNS hosts (stub resolver, caching/resolving/recursive name server, authoritative name server, etc.) could be subjected to packet flooding attacks (such as SYNC and smurf), resulting in disruption of communication. By implementing a specific set of firewall rules that limit accepted traffic to the interface, these risk of packet flooding and other TCP/IP based attacks is reduced.

Fix Text

Configure the OS firewall to only allow incoming DNS traffic on ports 53/tcp and 53/udp. Add the following rules to the host firewall rule set: # iptables -A INPUT -i [DNS Interface] -p tcp --dport 53 -j ACCEPT # iptables -A INPUT -i [DNS Interface] -p udp --dport 53 -j ACCEPT # iptables -A INPUT -i [DNS Interface] -j DROP Note: If the system is not using an IPTables firewall, the appropriate firewall rules that limit traffic to ports 53/tcp and 53/udp should be configured on the active firewall.

Check Content

With the assistance of the DNS administrator, verify that the OS firewall is configured to only allow incoming messages on ports 53/tcp and 53/udp. Note: The following rules are for the IPTables firewall. If the system is utilizing a different firewall, the rules may be different. Inspect the hosts firewall rules for the following rules: -A INPUT -i [DNS Interface] -p tcp --dport 53 -j ACCEPT -A INPUT -i [DNS Interface] -p udp --dport 53 -j ACCEPT -A INPUT -i [DNS Interface] -j DROP If any of the above rules do not exist, this is a finding. If there are rules listed that allow traffic on ports other than 53/tcp and 53/udp, this is a finding.

The host running a BIND 9.x implementation must use a dedicated management interface in order to separate management traffic from DNS specific traffic.

Finding ID
BIND-9X-001005
Rule ID
SV-86997r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000109
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Providing Out-Of-Band (OOB) management is the best first step in any management strategy. No production traffic resides on an out-of-band network. The biggest advantage to implementation of an OOB network is providing support and maintenance to the network that has become degraded or compromised. During an outage or degradation period the in band management link may not be available.

Fix Text

On the host machine, configure an interface that is dedicated to management traffic. Restart the host machine.

Check Content

Verify that the BIND 9.x server is configured to use a dedicated management interface: # ifconfig -a eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.0.1.252 netmask 255.255.255.0 broadcast 10.0.1.255 inet6 fd80::21c:d8ff:fab7:1dba prefixlen 64 scopeid 0x20<link> ether 00:1a:b8:d7:1a:bf txqueuelen 1000 (Ethernet) RX packets 2295379 bytes 220126493 (209.9 MiB) RX errors 0 dropped 31 overruns 0 frame 0 TX packets 70507 bytes 12284940 (11.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1458 inet 10.0.0.5 netmask 255.255.255.0 broadcast 10.0.0.255 inet6 fe81::21c:a8bf:fad7:1dca prefixlen 64 scopeid 0x20<link> ether 00:1d:d8:b5:1c:dd txqueuelen 1000 (Ethernet) RX packets 39090 bytes 4196802 (4.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 93250 bytes 18614094 (17.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 If one of the interfaces listed is not dedicated to only process management traffic, this is a finding.

The host running a BIND 9.x implementation must use an interface that is configured to process only DNS traffic.

Finding ID
BIND-9X-001006
Rule ID
SV-86999r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000109
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Configuring hosts that run a BIND 9.X implementation to only accept DNS traffic on a DNS interface allows a system to be configured to segregate DNS traffic from all other host traffic. The TCP/IP stack in DNS hosts (stub resolver, caching/resolving/recursive name server, authoritative name server, etc.) could be subjected to packet flooding attacks (such as SYNC and smurf), resulting in disruption of communication. The use of a dedicated interface for DNS traffic allows for these threats to be mitigated by creating a means to limit what types of traffic can be processed using a host based firewall solution.

Fix Text

On the host machine, configure an interface to only process DNS traffic. Restart the host machine.

Check Content

Verify that the BIND 9.x server is configured to use an interface that is configured to process only DNS traffic. # ifconfig -a eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.0.1.252 netmask 255.255.255.0 broadcast 10.0.1.255 inet6 fd80::21c:d8ff:fab7:1dba prefixlen 64 scopeid 0x20<link> ether 00:1a:b8:d7:1a:bf txqueuelen 1000 (Ethernet) RX packets 2295379 bytes 220126493 (209.9 MiB) RX errors 0 dropped 31 overruns 0 frame 0 TX packets 70507 bytes 12284940 (11.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1458 inet 10.0.0.5 netmask 255.255.255.0 broadcast 10.0.0.255 inet6 fe81::21c:a8bf:fad7:1dca prefixlen 64 scopeid 0x20<link> ether 00:1d:d8:b5:1c:dd txqueuelen 1000 (Ethernet) RX packets 39090 bytes 4196802 (4.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 93250 bytes 18614094 (17.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 If one of the interfaces listed is not dedicated to only process DNS traffic, this is a finding.

A BIND 9.x server implementation must be configured to allow DNS administrators to audit all DNS server components, based on selectable event criteria, and produce audit records within all DNS server components that contain information for failed security verification tests, information to establish the outcome and source of the events, any information necessary to determine cause of failure, and any information necessary to return to operations with least disruption to mission processes.

Finding ID
BIND-9X-001010
Rule ID
SV-87001r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000089-DNS-000004
CCI
CCI-001914
Target Key
(None)
Documentable
No
Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. The actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. The DoD has defined the list of events for which the application will provide an audit record generation capability as the following: (i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); (ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and (iii) All account creation, modification, disabling, and termination actions. The DoD has defined the data which the application will provide an audit record generation capability for an event as the following: (i) Establish the source of the event; (ii) The outcome of the event; and (iii) Identify the application itself as the source of the event. Without establishing the source of the event, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack. Associating information about the source of the event within the application provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured application. Without information about the outcome of events, security personnel cannot make an accurate assessment about whether an attack was successful or if changes were made to the security state of the system. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response." Failure to a known state can address safety or security in accordance with the mission/business needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving application state information helps to facilitate application restart and return to the operational mode of the organization with less disruption to mission-essential processes. The DNS server should be configured to generate audit records whenever a self-test fails. The OS/NDM is responsible for generating notification messages related to this audit record. If authorized individuals do not have the ability to modify auditing parameters in response to a changing threat environment, the organization may not be able to effectively respond, and important forensic information may be lost. This requirement enables organizations to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve information system resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting. Organizations can establish time thresholds in which audit actions are changed, for example, near real-time, within minutes, or within hours. In addition to logging where events occur within the application, the application must also produce audit records that identify the application itself as the source of the event. In order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know the source of the event, particularly in the case of centralized logging. In the case of centralized logging, the source would be the application name accompanied by the host or client name. Satisfies: SRG-APP-000089-DNS-000004, SRG-APP-000098-DNS-000009, SRG-APP-000099-DNS-000010, SRG-APP-000226-DNS-000032, SRG-APP-000275-DNS-000040, SRG-APP-000353-DNS-000045

Fix Text

Configure the logging statement in the "named.conf" file: logging { channel <channel_name> { file "<file_name>"; severity info; }; category default { <channel_name>; }; }; Replace <channel_name> and <file_name> with names that distinctively identify the purpose of the channel and the log file. Restart the BIND 9.x process.

Check Content

Verify the name server is configured to generate audit records: Inspect the "named.conf" file for the following: logging { channel channel_name { file "log.msgs"; severity info; }; category default { channel_name; }; }; If there is no "logging" statement, this is a finding. If the "logging" statement does not contain a "channel", this is a finding. If the "logging" statement does not contain a "category" that utilizes a "channel", this is a finding.

The BIND 9.x server implementation must not be configured with a channel to send audit records to null.

Finding ID
BIND-9X-001017
Rule ID
SV-87003r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000125-DNS-000012
CCI
CCI-001348
Target Key
(None)
Documentable
No
Discussion

DNS software administrators require DNS transaction logs for a wide variety of reasons including troubleshooting, intrusion detection, and forensics. Ensuring that the DNS transaction logs are recorded on the local system will provide the capability needed to support these actions. Sending DNS transaction data to the null channel would cause a loss of important data.

Fix Text

Edit the "named.conf" file. Remove any instance of the following: category null { null; }; Restart the BIND 9.x process.

Check Content

Verify that the BIND 9.x server is not configured to send audit logs to the null channel. Inspect the "named.conf" file for the following: category null { null; } If there is a category defined to send audit logs to the "null" channel, this is a finding.

The BIND 9.x server logging configuration must be configured to generate audit records for all DoD-defined auditable events to a local file by enabling triggers for all events with a severity of info, notice, warning, error, and critical for all DNS components.

Finding ID
BIND-9X-001020
Rule ID
SV-87005r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000089-DNS-000005
CCI
CCI-000169
Target Key
(None)
Documentable
No
Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. The actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. The DoD has defined the list of events for which the application will provide an audit record generation capability as the following: (i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); (ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and (iii) All account creation, modification, disabling, and termination actions.

Fix Text

Edit the "named.conf" file. Add the "severity" sub statement to the "channel" statement. Configure the "severity" sub statement to "info" Restart the BIND 9.x process.

Check Content

Verify the name server is configured to generate all DoD-defined audit records. Inspect the "named.conf" file for the following: logging { channel channel_name { file "log.msgs"; severity info; }; }; If a channel is not configured to log messages with the severity of info and higher, this is a finding. Note: "info" is the lowest severity level and will automatically log all messages with a severity of "info" or higher.

In the event of an error when validating the binding of other DNS servers identity to the BIND 9.x information, when anomalies in the operation of the signed zone transfers are discovered, for the success and failure of start and stop of the name server service or daemon, and for the success and failure of all name server events, a BIND 9.x server implementation must generate a log entry.

Finding ID
BIND-9X-001021
Rule ID
SV-87007r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000350-DNS-000044
CCI
CCI-002702
Target Key
(None)
Documentable
No
Discussion

Auditing and logging are key components of any security architecture. It is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered, in order to compile an accurate risk assessment. Logging the actions of specific events provides a means to investigate an attack, to recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS system. If auditing is not comprehensive, it will not be useful for intrusion monitoring, security investigations, and forensic analysis. The DNS server should audit all failed attempts at server authentication through DNSSEC and TSIG. The actual auditing is performed by the OS/NDM but the configuration to trigger the auditing is controlled by the DNS server. Failing to act on the validation errors may result in the use of invalid, corrupted, or compromised information. The validation of bindings can be achieved, for example, by the use of cryptographic checksums. Validations must be performed automatically. The DNS server does not have the capability of shutting down or restarting the information system. The DNS server can be configured to generate audit records when anomalies are discovered. Satisfies: SRG-APP-000350-DNS-000044, SRG-APP-000474-DNS-000073, SRG-APP-000504-DNS-000074, SRG-APP-000504-DNS-000082

Fix Text

Edit the "named.conf" file. Add the "severity" sub statement to the "channel" statement. Configure the "severity" sub statement to "info" Restart the BIND 9.x process.

Check Content

Verify the name server is configured to log error messages with a severity of “info”: Inspect the "named.conf" file for the following: logging { channel channel_name { file "log.msgs"; severity info; }; If the "severity" sub statement is not set to "info", this is a finding. Note: Setting the "severity" sub statement to "info" will log all messages for the following severity levels: Critical, Error, Warning, Notice, and Info.

The print-severity variable for the configuration of BIND 9.x server logs must be configured to produce audit records containing information to establish what type of events occurred.

Finding ID
BIND-9X-001030
Rule ID
SV-87009r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000095-DNS-000006
CCI
CCI-000130
Target Key
(None)
Documentable
No
Discussion

Auditing and logging are key components of any security architecture. It is essential for security personnel to know what is being performed on the system, where an event occurred, when an event occurred, and by whom the event was triggered, in order to compile an accurate risk assessment. Logging the actions of specific events provides a means to investigate an attack, recognize resource utilization or capacity thresholds, or to simply identify an improperly configured DNS implementation. Without log records that aid in the establishment of what types of events occurred and when those events occurred, there is no traceability for forensic or analytical purposes, and the cause of events is severely hindered.

Fix Text

Edit the "named.conf" file. Add the "print-severity" sub statement to the "channel" statement. Configure the "print-severity" sub statement to "yes" Restart the BIND 9.x process.

Check Content

For each logging channel that is defined, verify that the "print-severity" sub statement is listed: Inspect the "named.conf" file for the following: logging { channel channel_name { print-severity yes; }; }; If the "print-severity" statement is missing, this is a finding. If the "print-severity" statement is not set to "yes", this is a finding.

The print-time variable for the configuration of BIND 9.x server logs must be configured to establish when (date and time) the events occurred.

Finding ID
BIND-9X-001031
Rule ID
SV-87011r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000096-DNS-000007
CCI
CCI-000131
Target Key
(None)
Documentable
No
Discussion

Without establishing when events occurred, it is impossible to establish, correlate, and investigate the events relating to an incident. Associating event types with detected events in the application and audit logs provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured application. In order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know when events occurred (date and time).

Fix Text

Edit the "named.conf" file. Add the "print-time" sub statement to the "channel" statement. Configure the "print-time" sub statement to "yes" Restart the BIND 9.x process.

Check Content

For each logging channel that is defined, verify that the "print-time" sub statement is listed. Inspect the "named.conf" file for the following: logging { channel channel_name { print-time yes; }; }; If the "print-time" statement is missing, this is a finding. If the "print-time" statement is not set to "yes", this is a finding.

The print-category variable for the configuration of BIND 9.x server logs must be configured to record information indicating which process generated the events.

Finding ID
BIND-9X-001032
Rule ID
SV-87013r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000097-DNS-000008
CCI
CCI-000132
Target Key
(None)
Documentable
No
Discussion

Without establishing where events occurred, it is impossible to establish, correlate, and investigate the events relating to an incident. Associating information about where the event occurred within the application provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured application. In order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know where events occurred, such as application components, modules, session identifiers, filenames, host names, and functionality.

Fix Text

Edit the "named.conf" file. Add the "print-category" sub statement to the "channel" statement. Configure the "print-category" sub statement to "yes" Restart the BIND 9.x process.

Check Content

For each logging channel that is defined, verify that the "print-category" sub statement is listed. Inspect the "named.conf" file for the following: logging { channel channel_name { print-category yes; }; }; If the "print-category" statement is missing, this is a finding. If the "print-category" statement is not set to "yes", this is a finding.

The BIND 9.x server implementation must be configured with a channel to send audit records to a remote syslog.

Finding ID
BIND-9X-001040
Rule ID
SV-87015r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000125-DNS-000012
CCI
CCI-001348
Target Key
(None)
Documentable
No
Discussion

Protection of log data includes assuring log data is not accidentally lost or deleted. Backing up audit records to a different system or onto separate media than the system being audited on a defined frequency helps to assure, in the event of a catastrophic system failure, the audit records will be retained. This helps to ensure a compromise of the information system being audited does not also result in a compromise of the audit records.

Fix Text

Configure the "logging" statement to send audit logs to the syslog daemon. logging { channel <syslog_channel> { syslog <syslog_facility>; }; category <category_name> { <syslog_channel>; }; }; Note: It is recommended to use a local syslog facility (i.e. local0 -7) when configuring the syslog channel. Restart the BIND 9.x process. Configure the (r)syslog daemon to send audit logs to a remote server.

Check Content

Verify that the BIND 9.x server is configured to send audit logs to the syslog service. Inspect the "named.conf" file for the following: logging { channel <syslog_channel> { syslog <syslog_facility>; }; category <category_name> { <syslog_channel>; }; If a logging channel is not defined for syslog, this is a finding. If a category is not defined to send messages to the syslog channel, this is a finding. Ensure audit records are forwarded to a remote server: # grep "\*.\*" /etc/syslog.conf |grep "@" | grep -v "^#" (for syslog) or: # grep "\*.\*" /etc/rsyslog.conf | grep "@" | grep -v "^#" (for rsyslog) If neither of these lines exist, this is a finding.

The BIND 9.x server implementation must be configured with a channel to send audit records to a local file.

Finding ID
BIND-9X-001041
Rule ID
SV-87017r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000125-DNS-000012
CCI
CCI-001348
Target Key
(None)
Documentable
No
Discussion

DNS software administrators require DNS transaction logs for a wide variety of reasons including troubleshooting, intrusion detection, and forensics. Ensuring that the DNS transaction logs are recorded on the local system will provide the capability needed to support these actions.

Fix Text

Edit the "named.conf" file and add the following: logging { channel local_file_channel { file "path_name" versions 3; print-time yes; print-severity yes; print-category yes; }; category category_name { local_file_channel; }; }; Restart the BIND 9.x process.

Check Content

Verify that the BIND 9.x server is configured to send audit logs to a local log file. Inspect the "named.conf" file for the following: logging { channel local_file_channel { file "path_name" versions 3; print-time yes; print-severity yes; print-category yes; }; category category_name { local_file_channel; }; If a logging channel is not defined for a local file, this is a finding. If a category is not defined to send messages to the local file channel, this is a finding.

The BIND 9.x server implementation must maintain at least 3 file versions of the local log file.

Finding ID
BIND-9X-001042
Rule ID
SV-87019r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000125-DNS-000012
CCI
CCI-001348
Target Key
(None)
Documentable
No
Discussion

DNS software administrators require DNS transaction logs for a wide variety of reasons including troubleshooting, intrusion detection, and forensics. Ensuring that the DNS transaction logs are recorded on the local system will provide the capability needed to support these actions.

Fix Text

Edit the "named.conf" file. Add the "versions" variable to the end of the "file" sub statement in the channel statement. Configure the "versions" sub statement to a number that is greater or equal to 3. Restart the BIND 9.x process.

Check Content

Verify that the BIND 9.x server is configured to retain at least 3 versions of the local log file. Inspect the "named.conf" file for the following: logging { channel local_file_channel { file "path_name" versions 3; }; If the "versions" variable is not defined, this is a finding. If the "versions" variable is configured to retain less than 3 versions of the local log file, this is a finding.

The BIND 9.x secondary name server must limit the number of zones requested from a single master name server.

Finding ID
BIND-9X-001050
Rule ID
SV-87021r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000001-DNS-000001
CCI
CCI-000054
Target Key
(None)
Documentable
No
Discussion

Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) to the DNS implementation. Name servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed denial of service, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements.

Fix Text

Edit the "named.conf" file. Add the "transfers-per-ns" sub statement to the "options" statement block. The value of the "transfers-per-ns" option can be increased to a value greater than two based on organizational requirements needed to support DNS operations. Restart the BIND 9.x process.

Check Content

If this is not a secondary name server, this requirement is Not Applicable. Verify that the secondary name server is configured to limit the number of zones requested from a single master name server. Inspect the "named.conf" file for the following: options { transfers-per-ns 2; }; If the "options" statement does not contain a "transfers-per-ns" sub statement, this is a finding.

The BIND 9.x secondary name server must limit the total number of zones the name server can request at any one time.

Finding ID
BIND-9X-001051
Rule ID
SV-87023r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000001-DNS-000001
CCI
CCI-000054
Target Key
(None)
Documentable
No
Discussion

Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) to the DNS implementation. Name servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed denial of service, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements.

Fix Text

Edit the "named.conf" file. Add the "transfers-in" sub statement to the "options" statement block. The value of the "transfers-in" will be based on organizational requirements needed to support DNS operations. Restart the BIND 9.x process.

Check Content

If this is not a secondary name server, this requirement is Not Applicable. Verify the name server is configured to limit the total number of zones that can be requested at one time: Inspect the "named.conf" file for the following: options { transfers-in 10; }; If the "options" statement does not contain a "transfers-in" sub statement, this is a finding.

The BIND 9.x server implementation must limit the number of concurrent session client connections to the number of allowed dynamic update clients.

Finding ID
BIND-9X-001052
Rule ID
SV-87025r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000001-DNS-000115
CCI
CCI-000054
Target Key
(None)
Documentable
No
Discussion

Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) to the DNS implementation. Name servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed denial of service, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements.

Fix Text

Edit the "named.conf" file. Add the "transfers-out" sub statement to the "options" statement block. The value of the "transfers-out" will be based on organizational requirements needed to support DNS operations. Restart the BIND 9.x process.

Check Content

Verify the name server is configured to limit the number of concurrent client connections to the number of allowed dynamic update clients: Inspect the "named.conf" file for the following: options { transfers-out 10; }; If the "options" statement does not contain a "transfers-out" sub statement, this is a finding.

The BIND 9.x server implementation must be configured to use only approved ports and protocols.

Finding ID
BIND-9X-001053
Rule ID
SV-87027r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000142-DNS-000014
CCI
CCI-000382
Target Key
(None)
Documentable
No
Discussion

In order to prevent unauthorized connection of devices, unauthorized transfer of information, or unauthorized tunneling (i.e., embedding of data types within data types), organizations must disable or restrict unused or unnecessary physical and logical ports/protocols on information systems. Applications are capable of providing a wide variety of functions and services. Some of the functions and services provided by default may not be necessary to support essential organizational operations. To support the requirements and principles of least functionality, the application must support the organizational requirements by providing only essential capabilities and limiting the use of ports, protocols, and/or services.

Fix Text

Edit the "named.conf" file. Add the following line to the "options" statement: listen-on port 53 { <ip_address>; }; Replace "<ip_address>" with the IP of the name server. Restart the BIND 9.x process.

Check Content

Verify the BIND 9.x server is configured to listen on UDP/TCP port 53. Inspect the "named.conf" file for the following: options { listen-on port 53 { <ip_address>; }; }; If the "port" variable is missing, this is a finding. If the "port" variable is not set to "53", this is a finding. Note: "<ip_address>" should be replaced with the DNS server IP address.

A BIND 9.x server implementation must manage excess capacity, bandwidth, or other redundancy to limit the effects of information flooding types of Denial of Service (DoS) attacks.

Finding ID
BIND-9X-001054
Rule ID
SV-87029r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000247-DNS-000036
CCI
CCI-001095
Target Key
(None)
Documentable
No
Discussion

A DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity. A denial of service (DoS) attack against the DNS infrastructure has the potential to cause a DoS to all network users. As the DNS is a distributed backbone service of the Internet, various forms of amplification attacks resulting in DoS, while utilizing the DNS, are still prevalent on the Internet today. Some potential DoS flooding attacks against the DNS include malformed packet flood, spoofed source addresses, and distributed DoS. Without the DNS, users and systems would not have the ability to perform simple name to IP resolution. Configuring the DNS implementation to defend against cache poisoning, employing increased capacity and bandwidth, building redundancy into the DNS architecture, utilizing DNSSEC, limiting and securing recursive services, DNS black holes, etc., may reduce the susceptibility to some flooding types of DoS attacks.

Fix Text

Configure the authoritative name server to prohibit recursion. Edit the "named.conf" file and add the following sub statements to the options statement: recursion no; allow-query { none }; Configure each zone to limit queries to authorized hosts: Edit the "named.conf" file and add the following sub statement to each zone definition: allow-query { address_match_list; }; Restart the BIND 9.x process

Check Content

If this is a recursive name server, this is not applicable. Note: A recursive name server should NOT be configured as an authoritative name server for any zone. Verify that the BIND 9.x server is configured to prohibit recursion on authoritative name servers. Inspect the "named.conf" file for the following: options { recursion no; allow-query {none;}; }; If the "recursion" sub statement is missing, or set to "yes", this is a finding. If the "allow-query" sub statement under the "options statement" is not set to "none", this is a finding. Verify that an "allow-query" sub statement under each zone statement is configured to authorized hosts: zone "example.com" { type master; file "db.example.com"; allow-query { (address_match_list | <ip_address>) }; }; If the "allow-query" sub statement under each zone statement is not restricted to authorized hosts, this is a finding.

A BIND 9.x server implementation must prohibit recursion on authoritative name servers.

Finding ID
BIND-9X-001055
Rule ID
SV-87031r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000246-DNS-000035
CCI
CCI-001094
Target Key
(None)
Documentable
No
Discussion

A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. Once a name server has been poisoned, legitimate clients may be directed to non-existent hosts (which constitutes a denial of service), or, worse, hosts that masquerade as legitimate ones to obtain sensitive data or passwords. To guard against poisoning, name servers authoritative for .mil domains should be separated functionally from name servers that resolve queries on behalf of internal clients. Organizations may achieve this separation by dedicating machines to each function or, if possible, by running two instances of the name server software on the same machine: one for the authoritative function and the other for the resolving function. In this design, each name server process may be bound to a different IP address or network interface to implement the required segregation. DNSSEC ensures that the answer received when querying for name resolution actually comes from a trusted name server. Since DNSSEC is still far from being globally deployed external to DoD, and many resolvers either have not been updated or do not support DNSSEC, maintaining cached zone data separate from authoritative zone data mitigates the gap until all DNS data is validated with DNSSEC. Since DNS forwarding of queries can be accomplished in some DNS applications without caching locally, DNS forwarding is the method to be used when providing external DNS resolution to internal clients. Satisfies: SRG-APP-000246-DNS-000035, SRG-APP-000383-DNS-000047

Fix Text

Configure the authoritative name server to prohibit recursion. Edit the "named.conf" file and add the following sub statements to the options statement: recursion no; allow-recursion {none;}; allow-query { none }; Configure each zone to limit queries to authorized hosts: Edit the "named.conf" file and add the following sub statement to each zone definition: allow-query { address_match_list; }; Restart the BIND 9.x process

Check Content

If this is a recursive name server, this is not applicable. Note: A recursive name server should NOT be configured as an authoritative name server for any zone. Verify that the BIND 9.x server is configured to prohibit recursion on authoritative name servers. Inspect the "named.conf" file for the following: options { recursion no; allow-recursion {none;}; allow-query {none;}; }; If the "recursion" sub statement is missing, or set to "yes", this is a finding. If the “allow-recursion” sub statement is missing or is not set to “none”, this is a finding. If the "allow-query" sub statement under the "options statement" is missing or is not set to "none", this is a finding. Verify that an "allow-query" sub statement under each zone statement is configured to authorized hosts: zone "example.com" { type master; file "db.example.com"; allow-query { (address_match_list | <ip_address>) }; }; If the "allow-query" sub statement under each zone statement is not restricted to authorized hosts, this is a finding.

The master servers in a BIND 9.x implementation must notify authorized secondary name servers when zone files are updated.

Finding ID
BIND-9X-001057
Rule ID
SV-87033r3_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000516-DNS-000088
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

It is important to maintain the integrity of a zone file. The serial number of the SOA record is used to indicate to secondary name server that a change to the zone has occurred and a zone transfer should be performed. The serial number used in the SOA record provides the DNS administrator a method to verify the integrity of the zone file based on the serial number of the last update and ensure that all slave servers are using the correct zone file. When a primary master name server notices that the serial number of a zone has changed, it sends a special announcement to all of the slave name servers for that zone. The primary master name server determines which servers are the slaves for the zone by looking at the list of NS records in the zone and taking out the record that points to the name server listed in the MNAME field of the zone's SOA record as well as the domain name of the local host. When a secondary name server receives a NOTIFY announcement for a zone from one of its configured master name servers, it responds with a NOTIFY response. The response tells the master that the slave received the NOTIFY announcement so that the master can stop sending it NOTIFY announcements for the zone. Then the slave proceeds just as if the refresh timer for that zone had expired: it queries the master name server for the SOA record for the zone that the master claims has changed. If the serial number is higher, the slave transfers the zone. The slave should next issue its own NOTIFY announcements to the other authoritative name servers for the zone. The idea is that the primary master may not be able to notify all of the slave name servers for the zone itself, since it's possible some slaves can't communicate directly with the primary master (they use another slave as their master). Older BIND 8 slaves don't send NOTIFY messages unless explicitly configured to do so.

Fix Text

Edit the "named.conf" file. Configure the "notify" sub statement in the "options" statement block to "no": options { notify no; }; Configure the “notify explicit” and "also-notify" sub statements in the zone statement block to limit zone transfer notifications to authorized secondary name servers: zone example.com { notify explicit; also-notify { <ip_address>; | <address_match_list>; }; Restart the BIND 9.x process

Check Content

If this is a secondary name server, this is Not Applicable. On a master name server, verify that the global notify is disabled. The global entry for the name server is under the “Options” section and notify should be disabled at this section. Inspect the "named.conf" file for the following: options { notify no; }; If the "notify" statement is missing, this is a finding. If the "notify" statement is set to "yes", this is a finding. Verify that each zone is configured to notify authorized secondary name servers when a zone file has been updated. Each zone has its own Zone section. Inspect the "named.conf" file for the following: zone example.com { notify explicit; also-notify { <ip_address>; | <address_match_list>; }; If an "address match list" is used, verify that each ip address listed is an authorized secondary name server for that zone. If the “notify explicit” statement is missing, this is a finding. If the "also-notify" statement is missing, this is a finding. If the "also-notify" statement is configured to notify name servers that are not authorized for that zone, this is a finding.

The secondary name servers in a BIND 9.x implementation must be configured to initiate zone update notifications to other authoritative zone name servers.

Finding ID
BIND-9X-001058
Rule ID
SV-87035r2_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000516-DNS-000088
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

It is important to maintain the integrity of a zone file. The serial number of the SOA record is used to indicate to secondary name server that a change to the zone has occurred and a zone transfer should be performed. The serial number used in the SOA record provides the DNS administrator a method to verify the integrity of the zone file based on the serial number of the last update and ensure that all slave servers are using the correct zone file. When a primary master name server notices that the serial number of a zone has changed, it sends a special announcement to all of the slave name servers for that zone. The primary master name server determines which servers are the slaves for the zone by looking at the list of NS records in the zone and taking out the record that points to the name server listed in the MNAME field of the zone's SOA record as well as the domain name of the local host. When a secondary name server receives a NOTIFY announcement for a zone from one of its configured master name servers, it responds with a NOTIFY response. The response tells the master that the slave received the NOTIFY announcement so that the master can stop sending it NOTIFY announcements for the zone. Then the slave proceeds just as if the refresh timer for that zone had expired: it queries the master name server for the SOA record for the zone that the master claims has changed. If the serial number is higher, the slave transfers the zone. The slave should next issue its own NOTIFY announcements to the other authoritative name servers for the zone. The idea is that the primary master may not be able to notify all of the slave name servers for the zone itself, since it's possible some slaves can't communicate directly with the primary master (they use another slave as their master). Older BIND 8 slaves don't send NOTIFY messages unless explicitly configured to do so.

Fix Text

Edit the "named.conf" file. Configure the "notify" sub statement in the "options" statement block to "no": options { notify no; }; Configure the “notify explicit” and "also-notify" sub statements in the zone statement block to limit zone transfer notifications to authorized secondary name servers: zone example.com { notify explicit; also-notify { <ip_address>; | <address_match_list>; }; Restart the BIND 9.x process.

Check Content

If this is a master name server, this is Not Applicable. On a secondary name server, verify that the global notify is disabled. The global entry for the name server is under the “Options” section and notify should be disabled at this section. Inspect the "named.conf" file for the following: options { notify no; }; If the "notify" statement is missing, this is a finding. If the "notify" statement is set to "yes", this is a finding. Verify that zones for which the secondary server is authoritative is configured to notify other authorized secondary name servers when a zone file update has been received from the master name server for the zone. Each zone has its own Zone section. Inspect the "named.conf" file for the following: zone example.com { notify explicit; also-notify { <ip_address>; | <address_match_list>; }; If an "address match list" is used, verify that each ip address listed is an authorized secondary name server for that zone. If the “notify explicit” statement is missing, this is a finding. If the "also-notify" statement is missing, this is a finding. If the "also-notify" statement is configured to notify name servers that are not authorized for that zone, this is a finding.

On the BIND 9.x server the platform on which the name server software is hosted must be configured to send outgoing DNS messages from a random port.

Finding ID
BIND-9X-001059
Rule ID
SV-87043r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000516-DNS-000110
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Hosts that run the name server software should not provide any other services and therefore should be configured to respond to DNS traffic only. Outgoing DNS messages should be sent from a random port to minimize the risk of an attacker's guessing the outgoing message port and sending forged replies.

Fix Text

Edit the "named.conf" file. Configure the BIND 9.x server to only use the "port" flag with the "listen-on" and "listen-on-v6" statements: options { listen-on port 53 { <ip_address>; }; listen-on-v6 port 53 { <ip_v6_address>; }; }; Restart the BIND 9.x process.

Check Content

Verify that the BIND 9.x server does not limit outgoing DNS messages to a specific port. Inspect the "named.conf" file for the any instance of the "port" flag: options { listen-on port 53 { <ip_address>; }; listen-on-v6 port 53 { <ip_v6_address>; }; }; If any "port" flag is found outside of the "listen-on" or "listen-on-v6" statements, this is a finding.

A BIND 9.x master name server must limit the number of concurrent zone transfers between authorized secondary name servers.

Finding ID
BIND-9X-001070
Rule ID
SV-87047r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000001-DNS-000001
CCI
CCI-000054
Target Key
(None)
Documentable
No
Discussion

Limiting the number of concurrent sessions reduces the risk of Denial of Service (DoS) to the DNS implementation. Name servers do not have direct user connections but accept client connections for queries. Original restriction on client connections should be high enough to prevent a self-imposed denial of service, after which the connections are monitored and fine-tuned to best meet the organization's specific requirements. Primary name servers also make outbound connection to secondary name servers to provide zone transfers and accept inbound connection requests from clients wishing to provide a dynamic update. Primary name servers should explicitly limit zone transfers to only be made to designated secondary name servers. Because zone transfers involve the transfer of entire zones and use TCP connections, they place substantial demands on network resources relative to normal DNS queries. Errant or malicious frequent zone transfer requests on the name servers of the enterprise can overload the master zone server and result in DoS to legitimate users. Primary name servers should be configured to limit the hosts from which they will accept dynamic updates. Additionally, the number of concurrent clients, especially TCP clients, needs to be kept to a level that does not risk placing the system in a DoS state.

Fix Text

Edit the "named.conf" file. Add the "transfers" sub statement to each "server" statement block. The value of the "transfers" option can be increased to a value greater than two based on organizational requirements needed to support DNS operations. Restart the BIND 9.x process.

Check Content

If this is not a master name server, this requirement is Not Applicable Verify that the name server is configured to limit the number of zone transfers from authorized secondary name servers. Inspect the "named.conf" file for the following: server <ip_address> { transfers 2; }; If each "server" statement does not contain a "transfers" sub statement, this is a finding.

A BIND 9.x implementation configured as a caching name server must restrict recursive queries to only the IP addresses and IP address ranges of known supported clients.

Finding ID
BIND-9X-001080
Rule ID
SV-87049r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000246-DNS-000035
CCI
CCI-001094
Target Key
(None)
Documentable
No
Discussion

Any host that can query a resolving name server has the potential to poison the servers name cache or take advantage of other vulnerabilities that may be accessed through the query service. The best way to prevent this type of attack is to limit queries to internal hosts, which need to have this service available to them. To guard against poisoning, name servers authoritative for .mil domains should be separated functionally from name servers that resolve queries on behalf of internal clients. Organizations may achieve this separation by dedicating machines to each function or, if possible, by running two instances of the name server software on the same machine; one for the authoritative function and the other for the resolving function. In this design, each name server process may be bound to a different IP address or network interface to implement the required segregation.

Fix Text

Configure the caching name server to accept recursive queries only from the IP addresses and address ranges of known supported clients. Edit the "named.conf" file and add the following to the options statement: allow-query {trustworthy_hosts;}; allow-recursion {trustworthy_hosts;}; Restart the BIND 9.x process

Check Content

This check is only applicable to caching name servers. Verify the allow-query and allow-recursion phrases are properly configured. Inspect the "named.conf" file for the following: allow-query {trustworthy_hosts;}; allow-recursion {trustworthy_hosts;}; The name of the ACL does not need to be "trustworthy_hosts" but the name should match the ACL name defined earlier in "named.conf" for this purpose. If not, this is a finding. Verify non-internal IP addresses do not appear in either the referenced ACL (e.g., trustworthy_hosts) or directly in the statements themselves. If non-internal IP addresses appear, this is a finding.

The BIND 9.x server implementation must utilize separate TSIG key-pairs when securing server-to-server transactions.

Finding ID
BIND-9X-001106
Rule ID
SV-87055r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000158-DNS-000015
CCI
CCI-000778
Target Key
(None)
Documentable
No
Discussion

Server-to-server (zone transfer) transactions are provided by TSIG, which enforces mutual server authentication using a key that is unique to each server pair (TSIG), thus uniquely identifying the other server. Enforcing separate TSIG key-pairs provides another layer of protection for the BIND implementation in the event that a TSIG key is compromised. This additional layer of security provides the DNS administrators with the ability to change a compromised TSIG key with a minimal disruption to DNS operations. Failure to identify devices and authenticate devices can lead to malicious activity, such as a Man-In-The-Middle attack where an attacker could pose as an authorized name server, and redirect legitimate customers to malicious websites. A failure on this part could also lead to a Denial of Service of any and all DNS services provided to an organizations network infrastructure.

Fix Text

Create a separate TSIG key-pair for each key statement listed in the named.conf file. Configure the name server to utilize separate TSIG key-pairs for each key statement listed in the named.conf file. Restart the BIND 9.x process.

Check Content

Verify that the BIND 9.x server is configured to utilize separate TSIG key-pairs when securing server-to-server transactions. Inspect the "named.conf" file for the presence of TSIG key statements: On the master name server, this is an example of a configured key statement: key tsig_example. { algorithm hmac-SHA1; include "tsig-example.key"; }; zone "disa.mil" { type master; file "db.disa.mil"; allow-transfer { key tsig_example.; }; }; On the slave name server, this is an example of a configured key statement: key tsig_example. { algorithm hmac-SHA1; include "tsig-example.key"; }; server <ip_address> { keys { tsig_example }; }; zone "disa.mil" { type slave; masters { <ip_address>; }; file "db.disa.mil"; }; Verify that each TSIG key-pair listed is only used by a single key statement: # cat <tsig_key_file> If any TSIG key-pair is being used by more than one key statement, this is a finding.

The TSIG keys used with the BIND 9.x implementation must be owned by a privileged account.

Finding ID
BIND-9X-001110
Rule ID
SV-87061r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000176-DNS-000018
CCI
CCI-000186
Target Key
(None)
Documentable
No
Discussion

Incorrect ownership of a TSIG key file could allow an adversary to modify the file, thus defeating the security objective.

Fix Text

Change the ownership of the TSIG keys to the named process is running as. # chown <named_proccess_owner> <TSIG_key_file>.

Check Content

With the assistance of the DNS Administrator, identify all of the TSIG keys used by the BIND 9.x implementation. Identify the account that the "named" process is running as: # ps -ef | grep named named 3015 1 0 12:59 ? 00:00:00 /usr/sbin/named -u named -t /var/named/chroot With the assistance of the DNS Administrator, determine the location of the TSIG keys used by the BIND 9.x implementation. # ls –al <TSIG_Key_Location> -rw-------. 1 named named 76 May 10 20:35 tsig-example.key If any of the TSIG keys are not owned by the above account, this is a finding.

The TSIG keys used with the BIND 9.x implementation must be group owned by a privileged account.

Finding ID
BIND-9X-001111
Rule ID
SV-87063r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000176-DNS-000018
CCI
CCI-000186
Target Key
(None)
Documentable
No
Discussion

Incorrect ownership of a TSIG key file could allow an adversary to modify the file, thus defeating the security objective.

Fix Text

Change the group ownership of the TSIG keys to the named process group. # chgrp <named_proccess_group> <TSIG_key_file>

Check Content

With the assistance of the DNS Administrator, identify all of the TSIG keys used by the BIND 9.x implementation. Identify the account that the "named" process is running as: # ps -ef | grep named named 3015 1 0 12:59 ? 00:00:00 /usr/sbin/named -u named -t /var/named/chroot With the assistance of the DNS Administrator, determine the location of the TSIG keys used by the BIND 9.x implementation. # ls –al <TSIG_Key_Location> -rw-------. 1 named named 76 May 10 20:35 tsig-example.key If any of the TSIG keys are not group owned by the above account, this is a finding.

The read and write access to a TSIG key file used by a BIND 9.x server must be restricted to only the account that runs the name server software.

Finding ID
BIND-9X-001112
Rule ID
SV-87065r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000176-DNS-000019
CCI
CCI-000186
Target Key
(None)
Documentable
No
Discussion

Weak permissions of a TSIG key file could allow an adversary to modify the file, thus defeating the security objective.

Fix Text

Change the permissions of the TSIG key files: # chmod 600 <TSIG_key_file>

Check Content

Verify permissions assigned to the TSIG keys enforce read-write access to the key owner and deny access to group or system users: With the assistance of the DNS Administrator, determine the location of the TSIG keys used by the BIND 9.x implementation: # ls –al <TSIG_Key_Location> -rw-------. 1 named named 76 May 10 20:35 tsig-example.key If the key files are more permissive than 600, this is a finding.

The BIND 9.X implementation must not utilize a TSIG or DNSSEC key for more than one year.

Finding ID
BIND-9X-001113
Rule ID
SV-87067r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000500
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Cryptographic keys are the backbone of securing DNS information over the wire, maintaining DNS data integrity, and the providing the ability to validate DNS information that is received. When a cryptographic key is utilized by a DNS server for a long period of time, the likelihood of compromise increases. A compromised key set would allow an attacker to intercept and possibly inject comprised data into the DNS server. In this compromised state, the DNS server would be vulnerable to DoS attacks, as well as being vulnerable to becoming a launching pad for further attacks on an organizations network.

Fix Text

Generate new DNSSEC and TSIG keys. For DNSSEC keys: Use the newly generated keys to resign all of the zone files on the name server. For TSIG keys: Update the named.conf file with the new keys. Restart the BIND 9.X process.

Check Content

With the assistance of the DNS Administrator, identify all of the cryptographic key files used by the BIND 9.x implementation. With the assistance of the DNS Administrator, determine the location of the cryptographic key files used by the BIND 9.x implementation. # ls –al <Crypto_Key_Location> -rw-------. 1 named named 76 May 10 20:35 crypto-example.key If the server is in a classified network, the DNSSEC portion of the requirement is Not Applicable. For DNSSEC Keys: Verify that the “Created” date is less than one year from the date of inspection: Note: The date format will be displayed in YYYYMMDDHHMMSS. # cat <DNSSEC_Key_File> | grep -i “created” Created: 20160704235959 If the “Created” date is more than one year old, this is a finding. For TSIG Keys: Verify with the ISSO/ISSM that the TSIG keys are less than one year old. If a TSIG key is more than one year old, this is a finding.

A BIND 9.x server must implement NIST FIPS-validated cryptography for provisioning digital signatures and generating cryptographic hashes.

Finding ID
BIND-9X-001120
Rule ID
SV-87069r3_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000514-DNS-000075
CCI
CCI-002450
Target Key
(None)
Documentable
No
Discussion

The use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data. The application must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated. The choice of digital signature algorithm will be based on recommended algorithms in well-known standards. NIST's Digital Signature Standard (DSS) [FIPS186] provides three algorithm choices: - Digital Signature Algorithm (DSA) - RSA - Elliptic Curve DSA (ECDSA) Of these three algorithms, RSA and DSA are more widely available and hence are considered candidates of choice for DNSSEC. In terms of performance, both RSA and DSA have comparable signature generation speeds, but DSA is much slower for signature verification. Hence, RSA is the recommended algorithm as far as this guideline is concerned. It can be expected that name servers and clients will be able to use the RSA algorithm at the minimum. NIST's Secure Hash Standard (SHS) (FIPS 180-3) specifies SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 as approved hash algorithms to be used as part of the algorithm suite for generating digital signatures using the digital signature algorithms in NIST's DSS[FIPS186]. Satisfies: SRG-APP-000514-DNS-000075, SRG-APP-000516-DNS-000090

Fix Text

Create new DNSSEC and TSIG keys using a FIPS 180-3 approved cryptographic algorithm that meets or exceeds the strength of SHA256

Check Content

Verify that the DNSSEC and TSIG keys used by the BIND 9.x implementation are FIPS 180-3 compliant. If the server is in a classified network, the DNSSEC portion of the requirement is Not Applicable. DNSSEC KEYS: Inspect the "named.conf" file and identify all of the DNSSEC signed zone files: zone "example.com" { file "signed_zone_file"; }; For each signed zone file identified, inspect the file for the "DNSKEY" records: 86400 DNSKEY 257 3 8 ( <KEY HASH> ) ; KSK; 86400 DNSKEY 256 3 8 ( <KEY HASH> ) ; ZSK; The fifth field in the above example identifies what algorithm was used to create the DNSKEY. If the fifth field the KSK DNSKEY is less than “8” (SHA256), this is a finding. If the algorithm used to create the ZSK is less than “8” (SHA256), this is a finding. TSIG KEYS: Inspect the "named.conf" file and identify all of the TSIG key statements: key tsig_example. { algorithm hmac-SHA256; include "tsig-example.key"; }; If each key statement does not use "hmac-SHA256" or a stronger algorithm, this is a finding.

The DNSSEC keys used with the BIND 9.x implementation must be owned by a privileged account.

Finding ID
BIND-9X-001130
Rule ID
SV-87071r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000231-DNS-000033
CCI
CCI-001199
Target Key
(None)
Documentable
No
Discussion

Information at rest refers to the state of information when it is located on a secondary storage device within an organizational information system. Mobile devices, laptops, desktops, and storage devices can be either lost or stolen, and the contents of their data storage (e.g., hard drives and non-volatile memory) can be read, copied, or altered. Applications and application users generate information throughout the course of their application use. The DNS server must protect the confidentiality and integrity of the DNSSEC keys and must protect the integrity of DNS information. There is no need to protect the confidentiality of DNS information because it is accessible by all devices that can contact the server.

Fix Text

Change the ownership of the DNSSEC keys to the named process is running as. # chown <named_proccess_owner> <DNSSEC_key_file>.

Check Content

If the server is in a classified network, this is Not Applicable. With the assistance of the DNS Administrator, identify all of the DNSSEC keys used by the BIND 9.x implementation. Identify the account that the "named" process is running as: # ps -ef | grep named named 3015 1 0 12:59 ? 00:00:00 /usr/sbin/named -u named -t /var/named/chroot With the assistance of the DNS Administrator, determine the location of the DNSSEC keys used by the BIND 9.x implementation. # ls –al <DNSSEC_Key_Location> -r--------. 1 named named 76 May 10 20:35 DNSSEC-example.key If any of the DNSSEC keys are not owned by the above account, this is a finding.

The DNSSEC keys used with the BIND 9.x implementation must be group owned by a privileged account.

Finding ID
BIND-9X-001131
Rule ID
SV-87073r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000231-DNS-000033
CCI
CCI-001199
Target Key
(None)
Documentable
No
Discussion

Information at rest refers to the state of information when it is located on a secondary storage device within an organizational information system. Mobile devices, laptops, desktops, and storage devices can be either lost or stolen, and the contents of their data storage (e.g., hard drives and non-volatile memory) can be read, copied, or altered. Applications and application users generate information throughout the course of their application use. The DNS server must protect the confidentiality and integrity of the DNSSEC keys and must protect the integrity of DNS information. There is no need to protect the confidentiality of DNS information because it is accessible by all devices that can contact the server.

Fix Text

Change the group ownership of the DNSSEC keys to the named process is running as. # chgrp <named_proccess_group> <DNSSEC_key_file>.

Check Content

If the server is in a classified network, this is Not Applicable. With the assistance of the DNS Administrator, identify all of the DNSSEC keys used by the BIND 9.x implementation. Identify the account that the "named" process is running as: # ps -ef | grep named named 3015 1 0 12:59 ? 00:00:00 /usr/sbin/named -u named -t /var/named/chroot With the assistance of the DNS Administrator, determine the location of the DNSSEC keys used by the BIND 9.x implementation. # ls –al <DNSSEC_Key_Location> -r--------. 1 named named 76 May 10 20:35 DNSSEC-example.key If any of the DNSSEC keys are not group owned by the above account, this is a finding.

Permissions assigned to the DNSSEC keys used with the BIND 9.x implementation must enforce read-only access to the key owner and deny access to all other users.

Finding ID
BIND-9X-001132
Rule ID
SV-87075r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000231-DNS-000033
CCI
CCI-001199
Target Key
(None)
Documentable
No
Discussion

Information at rest refers to the state of information when it is located on a secondary storage device within an organizational information system. Mobile devices, laptops, desktops, and storage devices can be either lost or stolen, and the contents of their data storage (e.g., hard drives and non-volatile memory) can be read, copied, or altered. Applications and application users generate information throughout the course of their application use. The DNS server must protect the confidentiality and integrity of the DNSSEC keys and must protect the integrity of DNS information. There is no need to protect the confidentiality of DNS information because it is accessible by all devices that can contact the server.

Fix Text

Change the permissions of the DNSSEC key files: # chmod 400 <DNSSEC_key_file>

Check Content

If the server is in a classified network, this is Not Applicable. Verify permissions assigned to the DNSSEC keys enforce read-only access to the key owner and deny access to group or system users: With the assistance of the DNS Administrator, determine the location of the DNSSEC keys used by the BIND 9.x implementation: # ls –al <DNSSEC_Key_Location> -r--------. 1 named named 76 May 10 20:35 DNSSEC-example.key If the key files are more permissive than 400, this is a finding.

On the BIND 9.x server the private keys corresponding to both the ZSK and the KSK must not be kept on the BIND 9.x DNSSEC-aware primary authoritative name server when the name server does not support dynamic updates.

Finding ID
BIND-9X-001134
Rule ID
SV-87079r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000112
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

The private keys in the KSK and ZSK key pairs must be protected from unauthorized access. If possible, the private keys should be stored off-line (with respect to the Internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. This strategy is not feasible in situations in which the DNSSEC-aware name server has to support dynamic updates. To support dynamic update transactions, the DNSSEC-aware name server (which usually is a primary authoritative name server) has to have both the zone file master copy and the private key corresponding to the zone-signing key (ZSK-private) online to immediately update the signatures for the updated RRsets. The private key corresponding to the key-signing key (KSK-private) can still be kept off-line.

Fix Text

Remove any ZSK or KSK private key from any BIND 9.x server that does not support dynamic updates. Note: Any ZSK or KSK that is not needed to support dynamic updates should be stored offline in a secure location.

Check Content

If the server is in a classified network, this is Not Applicable. Determine if the BIND 9.x server is configured to allow dynamic updates. Review the "named.conf" file for any instance of the "allow-update" statement. The following example disables dynamic updates: allow-update {none;}; If the BIND 9.x implementation is not configured to allow dynamic updates, verify with the SA that the private ZSKs and private KSKs are stored offline, if not, this is a finding.

The two files generated by the BIND 9.x server dnssec-keygen program must be owned by the root account, or deleted, after they have been copied to the key file in the name server.

Finding ID
BIND-9X-001140
Rule ID
SV-87081r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000086
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64-encoded. A TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.

Fix Text

Change the ownership of the keys to the root account. # chown root <key_file>.

Check Content

If the server is in a classified network, this is Not Applicable. With the assistance of the DNS Administrator, identify all dnssec-keygen key files that reside on the BIND 9.x server. An example dnssec-keygen key file will look like: Kns1.example.com_ns2.example.com.+161+28823.key OR Kns1.example.com_ns2.example.com.+161+28823.private For each key file identified, verify that the key file is owned by "root": # ls -al -r-------- 1 root root 77 Jul 1 15:00 Kns1.example.com_ns2.example.com+161+28823.key If the key file(s) are not owned by root, this is a finding.

The two files generated by the BIND 9.x server dnssec-keygen program must be group owned by the server administrator account, or deleted, after they have been copied to the key file in the name server.

Finding ID
BIND-9X-001141
Rule ID
SV-87083r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000086
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64-encoded. A TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message.

Fix Text

Change the group ownership of the keys to the root group. # chgrp root <key_file>.

Check Content

If the server is in a classified network, this is Not Applicable. With the assistance of the DNS Administrator, identify all dnssec-keygen key files that reside on the BIND 9.x server. An example dnssec-keygen key file will look like: Kns1.example.com_ns2.example.com.+161+28823.key OR Kns1.example.com_ns2.example.com.+161+28823.private For each key file identified, verify that the key file is group-owned by "root": # ls –la -r-------- 1 root root 77 Jul 1 15:00 Kns1.example.com_ns2.example.com+161+28823.key If the key file(s) are not group owned by root, this is a finding.

Permissions assigned to the dnssec-keygen keys used with the BIND 9.x implementation must enforce read-only access to the key owner and deny access to all other users.

Finding ID
BIND-9X-001142
Rule ID
SV-87085r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000086
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

To enable zone transfer (requests and responses) through authenticated messages, it is necessary to generate a key for every pair of name servers. The key also can be used for securing other transactions, such as dynamic updates, DNS queries, and responses. The binary key string that is generated by most key generation utilities used with DNSSEC is Base64-encoded. A TSIG is a string used to generate the message authentication hash stored in a TSIG RR and used to authenticate an entire DNS message. Weak permissions could allow an adversary to modify the file(s), thus defeating the security objective.

Fix Text

Change the permissions of the dnssec-keygen key files: # chmod 400 <key_file>

Check Content

If the server is in a classified network, this is Not Applicable. With the assistance of the DNS Administrator, identify all dnssec-keygen key files that reside on the BIND 9.x server. An example dnssec-keygen key file will look like: Kns1.example.com_ns2.example.com.+161+28823.key OR Kns1.example.com_ns2.example.com.+161+28823.private For each key file identified, verify that the key file is owned by "root": # ls -al -r-------- 1 root root 77 Jul 1 15:00 Kns1.example.com_ns2.example.com+161+28823.key If the key files are more permissive than 400, this is a finding.

The BIND 9.x server signature generation using the KSK must be done off-line, using the KSK-private key stored off-line.

Finding ID
BIND-9X-001150
Rule ID
SV-87093r2_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000176-DNS-000096
CCI
CCI-000186
Target Key
(None)
Documentable
No
Discussion

The private key in the KSK key pair must be protected from unauthorized access. The private key should be stored off-line (with respect to the Internet-facing, DNSSEC-aware name server) in a physically secure, non-network-accessible machine along with the zone file master copy. Failure to protect the private KSK may have significant effects on the overall security of the DNS infrastructure. A compromised KSK could lead to an inability to detect unauthorized DNS zone data resulting in network traffic being redirected to a rogue site.

Fix Text

Remove all private KSKs from the name server and ensure that they are stored offline in a secure location.

Check Content

If the server is in a classified network, this is Not Applicable. Ensure that there are no private KSKs stored on the name sever. With the assistance of the DNS Administrator, obtain a list of all DNSSEC private keys that are stored on the name server. Inspect the signed zone files(s) and look for the KSK key id: DNSKEY 257 3 8 ( <hash_algorithm) ; KSK ; alg = RSASHA256; key id = 52807 Verify that none of the identified private keys, are KSKs. An example private KSK would look like the following: Kexample.com.+008+52807.private If there are private KSKs stored on the name server, this is a finding.

A BIND 9.x server implementation must maintain the integrity and confidentiality of DNS information while it is being prepared for transmission, in transmission, and in use and t must perform integrity verification and data origin verification for all DNS information.

Finding ID
BIND-9X-001200
Rule ID
SV-87095r3_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000213-DNS-000024
CCI
CCI-002468
Target Key
(None)
Documentable
No
Discussion

DNSSEC is required for securing the DNS query/response transaction by providing data origin authentication and data integrity verification through signature verification and the chain of trust Failure to accomplish data origin authentication and data integrity verification could have significant effects on DNS Infrastructure. The resultant response could be forged, it may have come from a poisoned cache, the packets could have been intercepted without the resolver's knowledge, or resource records could have been removed that would result in query failure or denial of service Failure to validate name server replies would cause many networking functions and communications to be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its subdomain, from the top of the DNS hierarchy down. Failure to validate the chain of trust used with DNSSEC would have a significant impact on the security posture of the DNS server. Non-validated trust chains may contain rouge DNS servers and allow those unauthorized servers to introduce invalid data into an organizations DNS infrastructure. A compromise of this type would be difficult to detect and may have devastating effects on the validity and integrity of DNS zone information. Satisfies: SRG-APP-000213-DNS-000024, SRG-APP-000215-DNS-000026, SRG-APP-000219-DNS-000028, SRG-APP-000219-DNS-000029, SRG-APP-000219-DNS-000030, SRG-APP-000347-DNS-000041, SRG-APP-000348-DNS-000042, SRG-APP-000349-DNS-000043, SRG-APP-000420-DNS-000053, SRG-APP-000421-DNS-000054, SRG-APP-000422-DNS-000055, SRG-APP-000423-DNS-000056, SRG-APP-000424-DNS-000057, SRG-APP-000425-DNS-000058, SRG-APP-000426-DNS-000059, SRG-APP-000441-DNS-000066, SRG-APP-000442-DNS-000067, SRG-APP-000516-DNS-000089

Fix Text

Set the "dnssec-enable" option to yes. Sign each zone file that the name server is responsible for. Configure each zone the name server is responsible for to use a DNSSEC signed zone.

Check Content

If the server is in a classified network, this is Not Applicable. Verify that DNSSEC is enabled. Inspect the "named.conf" file for the following: dnssec-enable yes; If "dnssec-enable" does not exist or is not set to "yes", this is a finding. Verify that each zone on the name server has been signed. Identify each zone file that the name sever is responsible for and search each file for the "DNSKEY" entries: # less <signed_zone_file> 86400 DNSKEY 257 3 8 ( HASHED_KEY ) ; KSK; alg = RSASHA256; key id = 31225 86400 DNSKEY 256 3 8 ( HASHED_KEY ) ; ZSK; alg = RSASHA256; key id = 52179 Ensure that there are separate "DNSKEY" entries for the "KSK" and the "ZSK" If the "DNSKEY" entries are missing, the zone file is not signed. If the zone files are not signed, this is a finding.

A BIND 9.x server implementation must provide the means to indicate the security status of child zones.

Finding ID
BIND-9X-001310
Rule ID
SV-87097r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000214-DNS-000025
CCI
CCI-001179
Target Key
(None)
Documentable
No
Discussion

If name server replies are invalid or cannot be validated, many networking functions and communication would be adversely affected. With DNS, the presence of Delegation Signer (DS) records associated with child zones informs clients of the security status of child zones. These records are crucial to the DNSSEC chain of trust model. Each parent domain's DS record is used to verify the DNSKEY record in its subdomain, from the top of the DNS hierarchy down. A DNS server is an example of an information system providing name/address resolution service. Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are examples of authoritative data. Applications other than the DNS, to map between host/service names and network addresses, must provide other means to assure the authenticity and integrity of response data. In DNS, trust in the public key of the source is established by starting from a trusted name server and establishing the chain of trust down to the current source of response through successive verifications of signature of the public key of a child by its parent. A trust anchor is an authoritative entity represented via a public key and associated data. It is used in the context of public key infrastructures, X.509 digital certificates, and Domain Name System Security Extensions (DNSSEC). When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor. A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate. In DNS, a trust anchor is a DNSKEY that is placed into a validating resolver so the validator can cryptographically validate the results for a given request back to a known public key (the trust anchor). An example means to indicate the security status of child subspaces is through the use of delegation signer (DS) resource records in the DNS. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Without path validation and a chain of trust, there can be no trust that the data integrity authenticity has been maintained during a transaction.

Fix Text

Sign each child zone. During the zone signing process, ensure that a DS record is created and is stored on the Parent zone name server.

Check Content

If the server is in a classified network, this is Not Applicable. Verify that there is a DS record set for each child zone defined in "/etc/named.conf" file. For each child zone listed in "/etc/named.conf" file, verify there is a corresponding "dsset-zone_name" file. If any child zone does not have a corresponding DS record set, this is a finding.

The core BIND 9.x server files must be owned by the root or BIND 9.x process account.

Finding ID
BIND-9X-001320
Rule ID
SV-87101r2_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000099
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Discretionary Access Control (DAC) is based on the premise that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. In a DNS implementation, DAC should be granted to a minimal number of individuals and objects because DNS does not interact directly with users and users do not store and share data with the DNS application directly.

Fix Text

Change the ownership of the files to the root or BIND 9.x process account. # chown <account_name> <file>

Check Content

Verify that the core BIND 9.x server files are owned by the root or BIND 9.x process account. With the assistance of the DNS administrator, identify the following files: named.conf root hints master zone file(s) slave zone files(s) Note: The name of the root hints file is defined in named.conf. Common names for the file are root.hints, named.cache, or db.cache. If the identified files are not owned by the root or BIND 9.x process account, this is a finding.

The core BIND 9.x server files must be group owned by a group designated for DNS administration only.

Finding ID
BIND-9X-001321
Rule ID
SV-87103r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000099
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Discretionary Access Control (DAC) is based on the premise that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. In a DNS implementation, DAC should be granted to a minimal number of individuals and objects because DNS does not interact directly with users and users do not store and share data with the DNS application directly.

Fix Text

Change the ownership of the core BIND 9.x server files to the process account group. # chgrp (BIND 9.x process account) <file>

Check Content

Verify that the core BIND 9.x server files are group owned by a group designated for DNS administration only. With the assistance of the DNS administrator, identify the following files: named.conf root hints master zone file(s) slave zone file(s) Note: The name of the root hints file is defined in named.conf. Common names for the file are root.hints, named.cache, or db.cache. If the identified files are not group owned by a group designated for DNS administration, this is a finding.

The permissions assigned to the core BIND 9.x server files must be set to utilize the least privilege possible.

Finding ID
BIND-9X-001322
Rule ID
SV-87105r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000099
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Discretionary Access Control (DAC) is based on the premise that individual users are "owners" of objects and therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. In a DNS implementation, DAC should be granted to a minimal number of individuals and objects because DNS does not interact directly with users and users do not store and share data with the DNS application directly.

Fix Text

Configure the permissions of each file to the following: named.conf : rw-r----- root hints : rw-r----- master zone file(s): rw-r----- slave zone file(s): rw-rw----

Check Content

With the assistance of the DNS administrator, identify the following files: named.conf : rw-r----- root hints : rw-r----- master zone file(s): rw-r----- slave zone file(s): rw-rw---- Note: The name of the root hints file is defined in named.conf. Common names for the file are root.hints, named.cache, or db.cache. Verify that the permissions for the core BIND 9.x server files are at least as restrictive as listed above. If the identified files are not as least as restrictive as listed above, this is a finding.

On a BIND 9.x server for zones split between the external and internal sides of a network, the RRs for the external hosts must be separate from the RRs for the internal hosts.

Finding ID
BIND-9X-001400
Rule ID
SV-87107r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000091
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Authoritative name servers for an enterprise may be configured to receive requests from both external and internal clients. External clients need to receive RRs that pertain only to public services (public Web server, mail server, etc.) Internal clients need to receive RRs pertaining to public services as well as internal hosts. The zone information that serves the RRs on both the inside and the outside of a firewall should be split into different physical files for these two types of clients (one file for external clients and one file for internal clients).

Fix Text

Edit the "named.conf" file. Configure the internal and external view statements to use separate zone files. Edit the internal and external zone files. Configure the zone file to use RRs designated for internal or external use. The zone files should not share any RR.

Check Content

If the BIND 9.x name server is not configured for split DNS, this is Not Applicable. Verify that the BIND 9.x server is configured to use separate views and address space for internal and external DNS operations when operating in a split configuration. Inspect the "named.conf" file for the following: view "internal" { match-clients { <ip_address> | <address_match_list> }; zone "example.com" { type master; file "internals.example.com"; }; }; view "external" { match-clients { <ip_address> | <address_match_list> }; zone "example.com" { type master; file "externals.db.example.com"; allow-transfer { slaves; }; }; }; If the internal and external view statements are configured to use the same zone file, this is a finding. Inspect the zone file defined in the internal and external view statements. If any resource record is listed in both the internal and external zone files, this is a finding.

On a BIND 9.x server in a split DNS configuration, where separate name servers are used between the external and internal networks, the external name server must be configured to not be reachable from inside resolvers.

Finding ID
BIND-9X-001401
Rule ID
SV-87109r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000092
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authoritative name servers. One set, called external name servers, can be located within a DMZ; these would be the only name servers that are accessible to external clients and would serve RRs pertaining to hosts with public services (Web servers that serve external Web pages or provide B2C services, mail servers, etc.) The other set, called internal name servers, is to be located within the firewall and should be configured so they are not reachable from outside and hence provide naming services exclusively to internal clients.

Fix Text

Edit the "named.conf" file. Configure the external view statement to server external hosts only: view "external" { match-clients { <ip_address> | <address_match_list>; }; }; Restart the BIND 9.x process.

Check Content

If the BIND 9.x name server is not configured for split DNS, this is Not Applicable. Verify that the external view of the BIND 9.x server is configured to only serve external hosts. Inspect the "named.conf" file for the following: view "external" { match-clients { <ip_address> | <address_match_list>; }; }; If the "match-clients" sub statement does not limit the external view to external hosts only, this is a finding.

On a BIND 9.x server in a split DNS configuration, where separate name servers are used between the external and internal networks, the internal name server must be configured to not be reachable from outside resolvers.

Finding ID
BIND-9X-001402
Rule ID
SV-87111r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000093
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Instead of having the same set of authoritative name servers serve different types of clients, an enterprise could have two different sets of authoritative name servers. One set, called external name servers, can be located within a DMZ; these would be the only name servers that are accessible to external clients and would serve RRs pertaining to hosts with public services (Web servers that serve external Web pages or provide B2C services, mail servers, etc.) The other set, called internal name servers, is to be located within the firewall and should be configured so they are not reachable from outside and hence provide naming services exclusively to internal clients.

Fix Text

Edit the "named.conf" file. Configure the internal view statement to limit use authorized internal hosts: view "internal" { match-clients { <ip_address> | <address_match_list>; }; }; Remove any IP address that is assigned to an external host from the internal view statement. Restart the BIND 9.x process.

Check Content

If the BIND 9.x name server is not configured for split DNS, this is Not Applicable. Verify that the BIND 9.x server is configured to use the "match-clients" sub statement to limit the reach of the internal view from the external view. Inspect the "named.conf" file for the following: view "internal" { match-clients { <ip_address> | <address_match_list>; }; }; If the "match-clients" sub statement is missing for the internal view, this is a finding. If the "match-clients" sub statement for the internal view does not limit the view to authorized hosts, this is a finding. If any of the IP addresses defined for the "match-clients" sub statement in the internal view are assigned to external hosts, this is a finding.

A BIND 9.x server implementation must implement internal/external role separation.

Finding ID
BIND-9X-001403
Rule ID
SV-87113r1_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000516-DNS-000101
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

DNS servers with an internal role only process name/address resolution requests from within the organization (i.e., internal clients). DNS servers with an external role only process name/address resolution information requests from clients external to the organization (i.e., on the external networks, including the Internet). The set of clients that can access an authoritative DNS server in a particular role is specified by the organization using address ranges, explicit access control lists, etc. In order to protect internal DNS resource information, it is important to isolate the requests to internal DNS servers. Failure to separate internal and external roles in DNS may lead to address space that is private (e.g., 10.0.0.0/24) or is otherwise concealed by some form of Network Address Translation from leaking into the public DNS system. Allowing private IP space to leak into the public DNS system may provide a person with malicious intent the ability to footprint your network and identify potential attack targets residing on your private network.

Fix Text

Edit the "named.conf" file. Configure the internal and external view statements to use separate network segments. Configure all internal view statements to be listed before any external view statement. Restart the BIND 9.x process.

Check Content

Severity Override Guidance: If the internal and external views are on separate network segments, this finding may be downgraded to a CAT II. If the BIND 9.x name server is not configured for split DNS, this is Not Applicable. Verify that the BIND 9.x server is configured to use separate views and address space for internal and external DNS operations when operating in a split configuration. Inspect the "named.conf" file for the following: view "internal" { match-clients { <ip_address> | <address_match_list> }; zone "example.com" { type master; file "internals.example.com"; }; }; view "external" { match-clients { <ip_address> | <address_match_list> }; zone "example.com" { type master; file "externals.db.example.com"; allow-transfer { slaves; }; }; }; If an external view is listed before an internal view, this is a finding. If the internal and external views are on the same network segment, this is a finding. Note: BIND 9.x reads the "named.conf" file from top to bottom. If a less stringent "match-clients" statement is processed before a more stringent "match-clients" statement, the more stringent statement will be ignored. With this in mind, all internal view statements should be listed before any external view statement in the "named.conf" file.

On the BIND 9.x server the IP address for hidden master authoritative name servers must not appear in the name servers set in the zone database.

Finding ID
BIND-9X-001404
Rule ID
SV-87115r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000108
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

A hidden master authoritative server is an authoritative DNS server whose IP address does not appear in the name server set for a zone. All of the name servers that do appear in the zone database as designated name servers get their zone data from the hidden master via a zone transfer request. In effect, all visible name servers are actually secondary slave servers. This prevents potential attackers from targeting the master name server because its IP address may not appear in the zone database.

Fix Text

Edit the zone file(s). Remove all references to the hidden master name server. Restart the BIND 9.x process.

Check Content

If the BIND 9.x name server is not configured for split DNS, this is Not Applicable. With the assistance of the DNS administrator, identify if the BIND 9.x implementation is using a hidden master name server, if it is not, this is Not Applicable. In a split DNS configuration that is using a hidden master name server, verify that the name server IP address is not listed in the zone file. With the assistance of the DNS administrator, obtain the IP address of the hidden master name server. Inspect each zone file used by the hidden master name server and its slave zones. If the IP address for the hidden master name server is listed in any of the zone files, this is a finding.

A BIND 9.x implementation operating in a split DNS configuration must be approved by the organizations Authorizing Official.

Finding ID
BIND-9X-001405
Rule ID
SV-87117r1_rule
Severity
Cat I
CCE
(None)
Group Title
SRG-APP-000516-DNS-000500
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

BIND 9.x has implemented an option to use "view" statements to allow for split DNS architecture to be configured on a single name server. If the split DNS architecture is improperly configured there is a risk that internal IP addresses and host names could leak into the external view of the DNS server. Allowing private IP space to leak into the public DNS system may provide a person with malicious intent the ability to footprint your network and identify potential attack targets residing on your private network.

Fix Text

Obtain approval for the split DNS implementation from the Authorizing Official.

Check Content

If the BIND 9.x name server is not configured for split DNS, this is Not Applicable. Verify that the split DNS implementation has been approved by the organizations Authorizing Official. With the assistance of the DNS administrator, obtain the Authorizing Official’s letter of approval for the split DNS implementation. If the split DNS implementation has not been approved by the organizations Authorizing Official, this is a finding.

A BIND 9.x server implementation must enforce approved authorizations for controlling the flow of information between authoritative name servers and specified secondary name servers based on DNSSEC policies.

Finding ID
BIND-9X-001510
Rule ID
SV-87123r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000215-DNS-000003
CCI
CCI-001663
Target Key
(None)
Documentable
No
Discussion

A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. The flow of all application information must be monitored and controlled so it does not introduce any unacceptable risk to the systems or data. Within the context of DNS, this is applicable in terms of controlling the flow of DNS information between systems, such as DNS zone transfers. Authoritative name servers (especially primary name servers) should be configured with an allow-transfer access control sub statement designating the list of hosts from which DNS information, such as zone transfers, can be accepted. These restrictions address the denial-of-service threat and potential exploits from unrestricted dissemination of information about internal resources. Zone transfer from primary name servers should be restricted to secondary name servers. The zone transfer should be completely disabled in the secondary name servers. The address match list argument for the allow-transfer sub statement should consist of IP addresses of secondary name servers and stealth secondary name servers. Satisfies: SRG-APP-000215-DNS-000003, SRG-APP-000516-DNS-000095

Fix Text

For an authoritative name server: Configure each zone statement to allow transfers from authorized hosts: allow-transfer { <ip_address_list>; }; Restart the BIND 9.x process. For a secondary server: Configure each zone to deny zone transfer requests: allow-transfer { none; }; Restart the BIND 9.x process.

Check Content

On an authoritative name sever, verify that each zone statement defined in the "named.conf" file contains an "allow-transfer" statement. Inspect the "named.conf" file for the following: zone example.com { allow-transfer { <ip_address_list>; }; }; If there is not an "allow-transfer" statement for each zone defined, or the list contains IP addresses that are not authorized for that zone, this is a finding. On a slave name server, verify that each zone statement defined in the "named.conf" file contains an "allow-transfer" statement. Inspect the "named.conf" file for the following: zone example.com { allow-transfer { none; }; }; If there is not an "allow-transfer" statement, or the statement is not set to "none", this is a finding.

Every NS record in a zone file on a BIND 9.x server must point to an active name server and that name server must be authoritative for the domain specified in that record.

Finding ID
BIND-9X-001611
Rule ID
SV-87129r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000085
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Poorly constructed NS records pose a security risk because they create conditions under which an adversary might be able to provide the missing authoritative name services that are improperly specified in the zone file. The adversary could issue bogus responses to queries that clients would accept because they learned of the adversary's name server from a valid authoritative name server, one that need not be compromised for this attack to be successful. The list of slave servers must remain current within 72 hours of any changes to the zone architecture that would affect the list of slaves. If a slave server has been retired or is not operational but remains on the list, then an adversary might have a greater opportunity to impersonate that slave without detection, rather than if the slave were actually online. For example, the adversary may be able to spoof the retired slave's IP address without an IP address conflict, which would not be likely to occur if the true slave were active.

Fix Text

Edit the zone file(s). Remove any name server that the BIND 9.x server is not authoritative for. Restart the BIND 9.x process.

Check Content

Verify that each name server listed on the BIND 9.x server is authoritative for the domain it supports. Inspect the "named.conf" file and identify all of the zone files that the BIND 9.x server is using. zone "example.com" { file "zone_file"; }; Inspect each zone file and identify each NS record listed. 86400 NS ns1.example.com 86400 NS ns2.example.com With the assistance of the DNS Administrator, verify that each name server listed is authoritative for that domain. If there are name servers listed in the zone file that are not authoritative for the specified domain, this is a finding.

On a BIND 9.x server all authoritative name servers for a zone must be located on different network segments.

Finding ID
BIND-9X-001612
Rule ID
SV-87131r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000087
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

Most enterprises have an authoritative primary server and a host of authoritative secondary name servers. It is essential that these authoritative name servers for an enterprise be located on different network segments. This dispersion ensures the availability of an authoritative name server not only in situations in which a particular router or switch fails but also during events involving an attack on an entire network segment.

Fix Text

Edit the zone file and configure each name server on a separate network segment.

Check Content

Verify that each name server listed on the BIND 9.x server is on a separate network segment. Inspect the "named.conf" file and identify all of the zone files that the BIND 9.x server is using. zone "example.com" { file "zone_file"; }; Inspect each zone file and identify each A record for each NS record listed: ns1.example.com 86400 IN A 192.168.1.4 ns2.example.com 86400 IN A 192.168.2.4 If there are name servers listed in the zone file that are not on different network segments for the specified domain, this is a finding.

On a BIND 9.x server all authoritative name servers for a zone must have the same version of zone information.

Finding ID
BIND-9X-001613
Rule ID
SV-87133r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000088
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

It is important to maintain the integrity of a zone file. The serial number of the SOA record is used to indicate to secondary name server that a change to the zone has occurred and a zone transfer should be performed. The serial number used in the SOA record provides the DNS administrator a method to verify the integrity of the zone file based on the serial number of the last update and ensure that all slave servers are using the correct zone file.

Fix Text

Edit the zone file. Update the SOA record serial number.

Check Content

Verify that the SOA record is at the same version for all authoritative servers for a specific zone. With the assistance of the DNS administrator, identify each name server that is authoritative for each zone. Inspect each zone file that the server is authoritative for and identify the following: example.com. 86400 IN SOA ns1.example.com. root.example.com. (17760704;serial) If the SOA "serial" numbers are not identical on each authoritative name server, this is a finding.

On a BIND 9.x server all root name servers listed in the local root zone file hosted on a BIND 9.x authoritative name server must be valid for that zone.

Finding ID
BIND-9X-001620
Rule ID
SV-87135r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000516-DNS-000102
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

All caching name servers must be authoritative for the root zone because, without this starting point, they would have no knowledge of the DNS infrastructure and thus would be unable to respond to any queries. The security risk is that an adversary could change the root hints and direct the caching name server to a bogus root server. At that point, every query response from that name server is suspect, which would give the adversary substantial control over the network communication of the name servers' clients.

Fix Text

Edit the local root zone file. Remove any reference to a domain that is outside of the name server’s primary domain. Restart the BIND 9.x process.

Check Content

If this is an authoritative name server, this is Not Applicable. Identify the local root zone file in named.conf: zone "." IN { type hint; file "<file_name>" }; Examine the local root zone file. If the local root zone file lists domains outside of the name server’s primary domain, this is a finding.

On a BIND 9.x server all root name servers listed in the local root zone file hosted on a BIND 9.x authoritative name server must be empty or removed.

Finding ID
BIND-9X-001621
Rule ID
SV-87137r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000516-DNS-000102
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

A potential vulnerability of DNS is that an attacker can poison a name servers cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. The DNS architecture needs to maintain one name server whose zone records are correct and the cache is not poisoned, in this effort the authoritative name server may not forward queries, one of the ways to prevent this, the root hints file is to be deleted. When authoritative servers are sent queries for zones that they are not authoritative for, and they are configured as a non-caching server (as recommended), they can either be configured to return a referral to the root servers or they can be configured to refuse to answer the query. The requirement is to configure authoritative servers to refuse to answer queries for any zones for which they are not authoritative. This is more efficient for the server, and allows it to spend more of its resources doing what its intended purpose is; answering authoritatively for its zone.

Fix Text

Remove the local root zone file from the name server.

Check Content

If this server is a caching name server, this is Not Applicable. Ensure there is not a local root zone on the name server. Inspect the "named.conf" file for the following: zone "." IN { type hint; file "<file_name>" }; If the file name identified is not empty or does exist, this is a finding.

On the BIND 9.x server a zone file must not include resource records that resolve to a fully qualified domain name residing in another zone.

Finding ID
BIND-9X-001700
Rule ID
SV-87139r1_rule
Severity
Cat II
CCE
(None)
Group Title
SRG-APP-000516-DNS-000113
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

If a name server were able to claim authority for a resource record in a domain for which it was not authoritative, this would pose a security risk. In this environment, an adversary could use illicit control of a name server to impact IP address resolution beyond the scope of that name server (i.e., by claiming authority for records outside of that server's zones). Fortunately, all but the oldest versions of BIND and most other DNS implementations do not allow for this behavior. Nevertheless, the best way to eliminate this risk is to eliminate from the zone files any records for hosts in another zone.

Fix Text

In the case of third-party CDNs or cloud offerings, document the mission need with the AO. Edit the zone file. Remove any record that points to a different zone, with the exception of approved CDNs or cloud offerings. Restart the BIND 9.x process.

Check Content

Verify that the zone files used by the BIND 9.x server do not contain resource records for a domain in which the server is not authoritative. The exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated. Inspect the "named.conf" file to identify the zone files, for which the server is authoritative: zone example.com { file "db.example.com.signed"; }; Inspect each zone file for which the server is authoritative. If there are CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms without an AO-approved and documented mission need, this is a finding. If a zone file contains records that resolve to another zone, excluding the above, this is a finding.

On the BIND 9.x server CNAME records must not point to a zone with lesser security for more than six months.

Finding ID
BIND-9X-001701
Rule ID
SV-87141r1_rule
Severity
Cat III
CCE
(None)
Group Title
SRG-APP-000516-DNS-000114
CCI
CCI-000366
Target Key
(None)
Documentable
No
Discussion

The use of CNAME records for exercises, tests, or zone-spanning aliases should be temporary (e.g., to facilitate a migration). When a host name is an alias for a record in another zone, an adversary has two points of attack: the zone in which the alias is defined and the zone authoritative for the alias's canonical name. This configuration also reduces the speed of client resolution because it requires a second lookup after obtaining the canonical name. Furthermore, in the case of an authoritative name server, this information is promulgated throughout the enterprise to caching servers and thus compounds the vulnerability.

Fix Text

In the case of third-party CDNs or cloud offerings, document the mission need with the AO. Edit the zone file. Remove CNAME records that are older than six months that do not meet the CDN or cloud offering criteria. Restart the BIND 9.x process.

Check Content

Verify that the zone files used by the BIND 9.x server do not contain resource records for a domain in which the server is not authoritative. Inspect the "named.conf" file for the following: zone example.com { file "db.example.com.signed"; }; Inspect each zone file for "CNAME" records and verify with the DNS administrator that these records are less than 6 months old. The exceptions are glue records supporting zone delegations, CNAME records supporting a system migration, or CNAME records that point to third-party Content Delivery Networks (CDN) or cloud computing platforms. In the case of third-party CDNs or cloud offerings, an approved mission need must be demonstrated. If there are CNAME records that point to third-party Content Delivery Networks (CDNs) or cloud computing platforms without an AO-approved and documented mission need, this is a finding. If a CNAME record is more than six months old, excluding the above, this is a finding.