BIND 9.x Security Technical Implementation Guide

Version

BIND-9X-001000

Vuln IDs

V-207533
V-72365

Rule IDs

SV-207533r612253_rule
SV-86989

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

Checks: C-7788r283653_chk

Verify that the BIND 9.x server is at a version that is considered "Current-Stable" by ISC or latest supported version of BIND when BIND is installed as part of a specific vendor implementation where the vendor maintains the BIND patches. # 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.

Fix: F-7788r283654_fix

Update the BIND 9.x server to a version that is listed as “Current-Stable” by ISC or latest supported version of BIND when BIND is installed as part of a specific vendor implementation where the vendor maintains the BIND patches.

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

CM-6 - Medium - CCI-000366 - V-207534 - SV-207534r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001002

Vuln IDs

V-207534
V-72367

Rule IDs

SV-207534r612253_rule
SV-86991

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.

Checks: C-7789r283656_chk

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.

Fix: F-7789r283657_fix

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

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

CM-6 - Medium - CCI-000366 - V-207535 - SV-207535r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001003

Vuln IDs

V-207535
V-72369

Rule IDs

SV-207535r612253_rule
SV-86993

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.

Checks: C-7790r283659_chk

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.

Fix: F-7790r283660_fix

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

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

CM-6 - Medium - CCI-000366 - V-207536 - SV-207536r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001004

Vuln IDs

V-207536
V-72371

Rule IDs

SV-207536r612253_rule
SV-86995

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.

Checks: C-7791r283662_chk

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.

Fix: F-7791r283663_fix

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.

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

CM-6 - Medium - CCI-000366 - V-207537 - SV-207537r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001005

Vuln IDs

V-207537
V-72373

Rule IDs

SV-207537r612253_rule
SV-86997

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.

Checks: C-7792r283665_chk

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.

Fix: F-7792r283666_fix

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

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

CM-6 - Medium - CCI-000366 - V-207538 - SV-207538r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001006

Vuln IDs

V-207538
V-72375

Rule IDs

SV-207538r612253_rule
SV-86999

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.

Checks: C-7793r283668_chk

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.

Fix: F-7793r283669_fix

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

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.

SI-6 - Low - CCI-001294 - V-207539 - SV-207539r612253_rule

RMF Control

SI-6

Severity

CCI

CCI-001294

Version

BIND-9X-001010

Vuln IDs

V-207539
V-72377

Rule IDs

SV-207539r612253_rule
SV-87001

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

Checks: C-7794r539067_chk

Verify the name server is configured to generate audit records: Inspect the "named.conf" file for the following: logging { channel channel_name { 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.

Fix: F-7794r283672_fix

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.

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

AU-9 - Low - CCI-001348 - V-207540 - SV-207540r612253_rule

RMF Control

AU-9

Severity

CCI

Version

BIND-9X-001017

Vuln IDs

V-207540
V-72379

Rule IDs

SV-207540r612253_rule
SV-87003

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.

Checks: C-7795r283674_chk

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.

Fix: F-7795r283675_fix

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

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.

AU-12 - Low - CCI-000169 - V-207541 - SV-207541r612253_rule

RMF Control

AU-12

Severity

CCI

CCI-000169

Version

BIND-9X-001020

Vuln IDs

V-207541
V-72381

Rule IDs

SV-207541r612253_rule
SV-87005

Checks: C-7796r539069_chk

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 { 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.

Fix: F-7796r283678_fix

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.

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.

AU-10 - Low - CCI-001906 - V-207542 - SV-207542r612253_rule

RMF Control

AU-10

Severity

CCI

CCI-001906

Version

BIND-9X-001021

Vuln IDs

V-207542
V-72383

Rule IDs

SV-207542r612253_rule
SV-87007

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

Checks: C-7797r539071_chk

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 { 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.

Fix: F-7797r283681_fix

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.

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.

AU-3 - Low - CCI-000130 - V-207543 - SV-207543r612253_rule

RMF Control

AU-3

Severity

CCI

CCI-000130

Version

BIND-9X-001030

Vuln IDs

V-207543
V-72385

Rule IDs

SV-207543r612253_rule
SV-87009

Checks: C-7798r283683_chk

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.

Fix: F-7798r283684_fix

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.

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.

AU-3 - Low - CCI-000131 - V-207544 - SV-207544r612253_rule

RMF Control

AU-3

Severity

CCI

CCI-000131

Version

BIND-9X-001031

Vuln IDs

V-207544
V-72387

Rule IDs

SV-207544r612253_rule
SV-87011

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).

Checks: C-7799r283686_chk

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.

Fix: F-7799r283687_fix

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.

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.

AU-3 - Low - CCI-000132 - V-207545 - SV-207545r612253_rule

RMF Control

AU-3

Severity

CCI

CCI-000132

Version

BIND-9X-001032

Vuln IDs

V-207545
V-72389

Rule IDs

SV-207545r612253_rule
SV-87013

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.

Checks: C-7800r283689_chk

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.

Fix: F-7800r283690_fix

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.

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

AU-9 - Low - CCI-001348 - V-207546 - SV-207546r612253_rule

RMF Control

AU-9

Severity

CCI

Version

BIND-9X-001040

Vuln IDs

V-207546
V-72391

Rule IDs

SV-207546r612253_rule
SV-87015

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.

Checks: C-7801r283692_chk

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.

Fix: F-7801r283693_fix

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.

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

AU-9 - Low - CCI-001348 - V-207547 - SV-207547r612253_rule

RMF Control

AU-9

Severity

CCI

Version

BIND-9X-001041

Vuln IDs

V-207547
V-72393

Rule IDs

SV-207547r612253_rule
SV-87017

Checks: C-7802r283695_chk

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.

Fix: F-7802r283696_fix

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.

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

AU-9 - Low - CCI-001348 - V-207548 - SV-207548r612253_rule

RMF Control

AU-9

Severity

CCI

Version

BIND-9X-001042

Vuln IDs

V-207548
V-72395

Rule IDs

SV-207548r612253_rule
SV-87019

Checks: C-7803r283698_chk

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.

Fix: F-7803r283699_fix

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.

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

AC-10 - Medium - CCI-000054 - V-207549 - SV-207549r612253_rule

RMF Control

AC-10

Severity

CCI

Version

BIND-9X-001050

Vuln IDs

V-207549
V-72397

Rule IDs

SV-207549r612253_rule
SV-87021

Checks: C-7804r283701_chk

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.

Fix: F-7804r283702_fix

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.

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

AC-10 - Medium - CCI-000054 - V-207550 - SV-207550r612253_rule

RMF Control

AC-10

Severity

CCI

Version

BIND-9X-001051

Vuln IDs

V-207550
V-72399

Rule IDs

SV-207550r612253_rule
SV-87023

Checks: C-7805r283704_chk

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.

Fix: F-7805r283705_fix

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.

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

AC-10 - Medium - CCI-000054 - V-207551 - SV-207551r612253_rule

RMF Control

AC-10

Severity

CCI

Version

BIND-9X-001052

Vuln IDs

V-207551
V-72401

Rule IDs

SV-207551r612253_rule
SV-87025

Checks: C-7806r283707_chk

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.

Fix: F-7806r283708_fix

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.

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

CM-7 - Medium - CCI-000382 - V-207552 - SV-207552r612253_rule

RMF Control

CM-7

Severity

CCI

CCI-000382

Version

BIND-9X-001053

Vuln IDs

V-207552
V-72403

Rule IDs

SV-207552r612253_rule
SV-87027

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.

Checks: C-7807r283710_chk

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.

Fix: F-7807r283711_fix

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.

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.

SC-5 - Medium - CCI-001095 - V-207553 - SV-207553r612253_rule

RMF Control

SC-5

Severity

CCI

CCI-001095

Version

BIND-9X-001054

Vuln IDs

V-207553
V-72405

Rule IDs

SV-207553r612253_rule
SV-87029

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.

Checks: C-7808r283713_chk

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.

Fix: F-7808r283714_fix

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

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

SC-5 - Medium - CCI-001094 - V-207554 - SV-207554r612253_rule

RMF Control

SC-5

Severity

CCI

CCI-001094

Version

BIND-9X-001055

Vuln IDs

V-207554
V-72407

Rule IDs

SV-207554r612253_rule
SV-87031

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

Checks: C-7809r283716_chk

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.

Fix: F-7809r283717_fix

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

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

CM-6 - Low - CCI-000366 - V-207555 - SV-207555r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001057

Vuln IDs

V-207555
V-72409

Rule IDs

SV-207555r612253_rule
SV-87033

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.

Checks: C-7810r283719_chk

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.

Fix: F-7810r283720_fix

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

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

CM-6 - Low - CCI-000366 - V-207556 - SV-207556r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001058

Vuln IDs

V-207556
V-72411

Rule IDs

SV-207556r612253_rule
SV-87035

Checks: C-7811r283722_chk

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.

Fix: F-7811r283723_fix

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.

CM-6 - Low - CCI-000366 - V-207557 - SV-207557r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001059

Vuln IDs

V-207557
V-72419

Rule IDs

SV-207557r612253_rule
SV-87043

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.

Checks: C-7812r283725_chk

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.

Fix: F-7812r283726_fix

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.

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

SI-10 - Medium - CCI-002754 - V-207558 - SV-207558r612253_rule

RMF Control

SI-10

Severity

CCI

CCI-002754

Version

BIND-9X-001060

Vuln IDs

V-207558
V-72421

Rule IDs

SV-207558r612253_rule
SV-87045

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.

Checks: C-7813r612164_chk

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 the server is configured to use DNSSEC validation for all DNS queries. Inspect the "named.conf" file for the following: options { dnssec-validation yes; dnssec-enable yes; (this requirement is enforced with BIND-9X-001200. }; managed-keys { "." initial-key 257 3 8 "<root-trust-anchor-data>"; }; If "dnssec-enable" is not set to "yes" or is missing, this is a finding. 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.

Fix: F-7813r612165_fix

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

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

AC-10 - Medium - CCI-000054 - V-207559 - SV-207559r612253_rule

RMF Control

AC-10

Severity

CCI

Version

BIND-9X-001070

Vuln IDs

V-207559
V-72423

Rule IDs

SV-207559r612253_rule
SV-87047

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.

Checks: C-7814r283731_chk

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.

Fix: F-7814r283732_fix

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.

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.

SC-5 - Medium - CCI-001094 - V-207560 - SV-207560r612253_rule

RMF Control

SC-5

Severity

CCI

CCI-001094

Version

BIND-9X-001080

Vuln IDs

V-207560
V-72425

Rule IDs

SV-207560r612253_rule
SV-87049

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.

Checks: C-7815r283734_chk

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.

Fix: F-7815r283735_fix

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

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.

IA-3 - High - CCI-000778 - V-207561 - SV-207561r612253_rule

RMF Control

IA-3

Severity

CCI

CCI-000778

Version

BIND-9X-001100

Vuln IDs

V-207561
V-72429

Rule IDs

SV-207561r612253_rule
SV-87053

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

Checks: C-7816r283737_chk

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 <ip_address> { keys { tsig_example }; }; zone "disa.mil" { type slave; masters { <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.

Fix: F-7816r283738_fix

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.

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

IA-3 - Medium - CCI-000778 - V-207562 - SV-207562r612253_rule

RMF Control

IA-3

Severity

CCI

CCI-000778

Version

BIND-9X-001106

Vuln IDs

V-207562
V-72431

Rule IDs

SV-207562r612253_rule
SV-87055

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.

Checks: C-7817r283740_chk

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.

Fix: F-7817r283741_fix

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.

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

IA-5 - Medium - CCI-000186 - V-207563 - SV-207563r612253_rule

RMF Control

IA-5

Severity

CCI

Version

BIND-9X-001110

Vuln IDs

V-207563
V-72437

Rule IDs

SV-207563r612253_rule
SV-87061

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

Checks: C-7818r283743_chk

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.

Fix: F-7818r283744_fix

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

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

IA-5 - Medium - CCI-000186 - V-207564 - SV-207564r612253_rule

RMF Control

IA-5

Severity

CCI

Version

BIND-9X-001111

Vuln IDs

V-207564
V-72439

Rule IDs

SV-207564r612253_rule
SV-87063

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

Checks: C-7819r283746_chk

Fix: F-7819r283747_fix

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

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.

IA-5 - Medium - CCI-000186 - V-207565 - SV-207565r612253_rule

RMF Control

IA-5

Severity

CCI

Version

BIND-9X-001112

Vuln IDs

V-207565
V-72441

Rule IDs

SV-207565r612253_rule
SV-87065

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

Checks: C-7820r283749_chk

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.

Fix: F-7820r283750_fix

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

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

CM-6 - Medium - CCI-000366 - V-207566 - SV-207566r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001113

Vuln IDs

V-207566
V-72443

Rule IDs

SV-207566r612253_rule
SV-87067

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.

Checks: C-7821r283752_chk

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.

Fix: F-7821r283753_fix

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.

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

SC-13 - High - CCI-002450 - V-207567 - SV-207567r612253_rule

RMF Control

SC-13

Severity

CCI

CCI-002450

Version

BIND-9X-001120

Vuln IDs

V-207567
V-72445

Rule IDs

SV-207567r612253_rule
SV-87069

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

Checks: C-7822r283755_chk

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.

Fix: F-7822r283756_fix

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

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

SC-28 - Medium - CCI-001199 - V-207568 - SV-207568r612253_rule

RMF Control

SC-28

Severity

CCI

CCI-001199

Version

BIND-9X-001130

Vuln IDs

V-207568
V-72447

Rule IDs

SV-207568r612253_rule
SV-87071

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.

Checks: C-7823r283758_chk

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.

Fix: F-7823r283759_fix

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

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

SC-28 - Medium - CCI-001199 - V-207569 - SV-207569r612253_rule

RMF Control

SC-28

Severity

CCI

CCI-001199

Version

BIND-9X-001131

Vuln IDs

V-207569
V-72449

Rule IDs

SV-207569r612253_rule
SV-87073

Checks: C-7824r283761_chk

Fix: F-7824r283762_fix

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

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.

SC-28 - Medium - CCI-001199 - V-207570 - SV-207570r612253_rule

RMF Control

SC-28

Severity

CCI

CCI-001199

Version

BIND-9X-001132

Vuln IDs

V-207570
V-72451

Rule IDs

SV-207570r612253_rule
SV-87075

Checks: C-7825r283764_chk

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.

Fix: F-7825r283765_fix

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

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.

IA-5 - High - CCI-000186 - V-207571 - SV-207571r612253_rule

RMF Control

IA-5

Severity

CCI

Version

BIND-9X-001133

Vuln IDs

V-207571
V-72453

Rule IDs

SV-207571r612253_rule
SV-87077

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.

Checks: C-7826r283767_chk

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 <signed_zone_file> | grep -i "zsk" ZSK; alg = ECDSAP256SHA256; 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 ZSK private keys exist on the server other than the one corresponding to the active ZSK pair, this is a finding.

Fix: F-7826r283768_fix

Remove any ZSK private keys existing on the server other than the one corresponding to the active ZSK pair

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.

CM-6 - Medium - CCI-000366 - V-207572 - SV-207572r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001134

Vuln IDs

V-207572
V-72455

Rule IDs

SV-207572r612253_rule
SV-87079

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.

Checks: C-7827r283770_chk

Fix: F-7827r283771_fix

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.

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.

CM-6 - Medium - CCI-000366 - V-207573 - SV-207573r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001140

Vuln IDs

V-207573
V-72457

Rule IDs

SV-207573r612253_rule
SV-87081

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.

Checks: C-7828r283773_chk

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.

Fix: F-7828r283774_fix

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

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.

CM-6 - Medium - CCI-000366 - V-207574 - SV-207574r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001141

Vuln IDs

V-207574
V-72459

Rule IDs

SV-207574r612253_rule
SV-87083

Checks: C-7829r283776_chk

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.

Fix: F-7829r283777_fix

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

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.

CM-6 - Medium - CCI-000366 - V-207575 - SV-207575r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001142

Vuln IDs

V-207575
V-72461

Rule IDs

SV-207575r612253_rule
SV-87085

Checks: C-7830r283779_chk

Fix: F-7830r283780_fix

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

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

IA-5 - High - CCI-000186 - V-207576 - SV-207576r612253_rule

RMF Control

IA-5

Severity

CCI

Version

BIND-9X-001150

Vuln IDs

V-207576
V-72469

Rule IDs

SV-207576r612253_rule
SV-87093

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.

Checks: C-7831r283782_chk

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 = ECDSAP256SHA256; 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.

Fix: F-7831r283783_fix

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

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.

SC-20 - High - CCI-002462 - V-207577 - SV-207577r612253_rule

RMF Control

SC-20

Severity

CCI

CCI-002462

Version

BIND-9X-001200

Vuln IDs

V-207577
V-72471

Rule IDs

SV-207577r612253_rule
SV-87095

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

Checks: C-7832r283785_chk

If the server is in a classified network, this is Not Applicable. If the server is forwarding all queries to the ERS, this is Not Applicable as the ERS validates. 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 = ECDSAP256SHA256; key id = 31225 86400 DNSKEY 256 3 8 ( HASHED_KEY ) ; ZSK; alg = ECDSAP256SHA256; 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.

Fix: F-7832r283786_fix

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.

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

SC-20 - Medium - CCI-001179 - V-207578 - SV-207578r612253_rule

RMF Control

SC-20

Severity

CCI

CCI-001179

Version

BIND-9X-001310

Vuln IDs

V-207578
V-72473

Rule IDs

SV-207578r612253_rule
SV-87097

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.

Checks: C-7833r283788_chk

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.

Fix: F-7833r283789_fix

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.

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.

SC-20 - Medium - CCI-001179 - V-207579 - SV-207579r612253_rule

RMF Control

SC-20

Severity

CCI

CCI-001179

Version

BIND-9X-001311

Vuln IDs

V-207579
V-72475

Rule IDs

SV-207579r612253_rule
SV-87099

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.

Checks: C-7834r283791_chk

If the server is in a classified network, this is Not Applicable. Note: This requirement does not validate the sig-validity-interval. This requirement ensures the signature validity period (i.e., the time from the signature’s inception until the signature’s expiration). It is recommended to ensure the Start of Authority (SOA) expire period (how long a secondary will still treat its copy of the zone data as valid if it cannot contact the primary.) is configured to ensure the SOA does not expire during the period of signature inception and signature expiration. 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.

Fix: F-7834r283792_fix

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

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

CM-6 - Medium - CCI-000366 - V-207580 - SV-207580r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001320

Vuln IDs

V-207580
V-72477

Rule IDs

SV-207580r612253_rule
SV-87101

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.

Checks: C-7835r283794_chk

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.

Fix: F-7835r283795_fix

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

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

CM-6 - Medium - CCI-000366 - V-207581 - SV-207581r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001321

Vuln IDs

V-207581
V-72479

Rule IDs

SV-207581r612253_rule
SV-87103

Checks: C-7836r283797_chk

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.

Fix: F-7836r283798_fix

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

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

CM-6 - Medium - CCI-000366 - V-207582 - SV-207582r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001322

Vuln IDs

V-207582
V-72481

Rule IDs

SV-207582r612253_rule
SV-87105

Checks: C-7837r283800_chk

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.

Fix: F-7837r283801_fix

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----

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.

CM-6 - Medium - CCI-000366 - V-207583 - SV-207583r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001400

Vuln IDs

V-207583
V-72483

Rule IDs

SV-207583r612253_rule
SV-87107

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).

Checks: C-7838r283803_chk

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.

Fix: F-7838r283804_fix

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.

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.

CM-6 - Medium - CCI-000366 - V-207584 - SV-207584r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001401

Vuln IDs

V-207584
V-72485

Rule IDs

SV-207584r612253_rule
SV-87109

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.

Checks: C-7839r283806_chk

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.

Fix: F-7839r283807_fix

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.

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.

CM-6 - Medium - CCI-000366 - V-207585 - SV-207585r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001402

Vuln IDs

V-207585
V-72487

Rule IDs

SV-207585r612253_rule
SV-87111

Checks: C-7840r283809_chk

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.

Fix: F-7840r283810_fix

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.

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

CM-6 - High - CCI-000366 - V-207586 - SV-207586r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001403

Vuln IDs

V-207586
V-72489

Rule IDs

SV-207586r612253_rule
SV-87113

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.

Checks: C-7841r283812_chk

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.

Fix: F-7841r283813_fix

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.

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.

CM-6 - Medium - CCI-000366 - V-207587 - SV-207587r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001404

Vuln IDs

V-207587
V-72491

Rule IDs

SV-207587r612253_rule
SV-87115

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.

Checks: C-7842r283815_chk

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.

Fix: F-7842r283816_fix

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

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

CM-6 - High - CCI-000366 - V-207588 - SV-207588r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001405

Vuln IDs

V-207588
V-72493

Rule IDs

SV-207588r612253_rule
SV-87117

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.

Checks: C-7843r283818_chk

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.

Fix: F-7843r283819_fix

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

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.

CM-6 - Medium - CCI-000366 - V-207589 - SV-207589r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001410

Vuln IDs

V-207589
V-72495

Rule IDs

SV-207589r612253_rule
SV-87119

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.

Checks: C-7844r283821_chk

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 <signed_zone_file> | grep -i "zsk" ZSK; alg = ECDSAP256SHA256; 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 <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.

Fix: F-7844r283822_fix

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

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.

CM-6 - Medium - CCI-000366 - V-207590 - SV-207590r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001411

Vuln IDs

V-207590
V-72497

Rule IDs

SV-207590r612253_rule
SV-87121

Checks: C-7845r283824_chk

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 <signed_zone_file> | grep -i "zsk" ZSK; alg = ECDSAP256SHA256; 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 <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.

Fix: F-7845r283825_fix

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

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.

CM-6 - Medium - CCI-000366 - V-207591 - SV-207591r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001510

Vuln IDs

V-207591
V-72499

Rule IDs

SV-207591r612253_rule
SV-87123

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

Checks: C-7846r283827_chk

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.

Fix: F-7846r283828_fix

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.

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.

CM-6 - Medium - CCI-000366 - V-207592 - SV-207592r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001600

Vuln IDs

V-207592
V-72501

Rule IDs

SV-207592r612253_rule
SV-87125

Checks: C-7847r283830_chk

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.

Fix: F-7847r283831_fix

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

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

CM-6 - Medium - CCI-000366 - V-207593 - SV-207593r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001610

Vuln IDs

V-207593
V-72503

Rule IDs

SV-207593r612253_rule
SV-87127

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.

Checks: C-7848r283833_chk

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.

Fix: F-7848r283834_fix

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

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.

CM-6 - Medium - CCI-000366 - V-207594 - SV-207594r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001611

Vuln IDs

V-207594
V-72505

Rule IDs

SV-207594r612253_rule
SV-87129

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.

Checks: C-7849r283836_chk

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.

Fix: F-7849r283837_fix

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.

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

CM-6 - Medium - CCI-000366 - V-207595 - SV-207595r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001612

Vuln IDs

V-207595
V-72507

Rule IDs

SV-207595r612253_rule
SV-87131

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.

Checks: C-7850r283839_chk

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.

Fix: F-7850r283840_fix

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

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

CM-6 - Medium - CCI-000366 - V-207596 - SV-207596r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001613

Vuln IDs

V-207596
V-72509

Rule IDs

SV-207596r612253_rule
SV-87133

Checks: C-7851r283842_chk

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.

Fix: F-7851r283843_fix

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

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.

CM-6 - Low - CCI-000366 - V-207597 - SV-207597r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001620

Vuln IDs

V-207597
V-72511

Rule IDs

SV-207597r612253_rule
SV-87135

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.

Checks: C-7852r283845_chk

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.

Fix: F-7852r283846_fix

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.

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.

CM-6 - Low - CCI-000366 - V-207598 - SV-207598r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001621

Vuln IDs

V-207598
V-72513

Rule IDs

SV-207598r612253_rule
SV-87137

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.

Checks: C-7853r283848_chk

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.

Fix: F-7853r283849_fix

Remove the local root zone file from the name server.

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.

CM-6 - Medium - CCI-000366 - V-207599 - SV-207599r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001700

Vuln IDs

V-207599
V-72515

Rule IDs

SV-207599r612253_rule
SV-87139

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.

Checks: C-7854r283851_chk

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.

Fix: F-7854r283852_fix

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.

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

CM-6 - Low - CCI-000366 - V-207600 - SV-207600r612253_rule

RMF Control

CM-6

Severity

CCI

Version

BIND-9X-001701

Vuln IDs

V-207600
V-72517

Rule IDs

SV-207600r612253_rule
SV-87141

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.

Checks: C-7855r283854_chk

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.

Fix: F-7855r283855_fix

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.

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

CM-6 - Medium - CCI-000366 - V-207601 - SV-207601r612253_rule

RMF Control

CM-6

Severity

CCI