What changed in BIND 9.x STIG V3R4V3R4 changes

Discussion

Without the capability to generate audit records, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one. The actual auditing is performed by the OS/NDM, but the configuration to trigger the auditing is controlled by the DNS server. The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records. The DODDoW 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 DODDoW 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. 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-000275-DNS-000040, SRG-APP-000226-DNS-000032

V-272371 in V3R4

Check text

If the server is not a caching server, this is not applicable. Note: The use of the Defense Research and Engineering Network (DREN) Enterprise Recursive DNS servers, as mandated by the DODINDOWIN service provider DREN, meets the intent of this requirement. Verify that the server is configured to forward all DNS traffic to the DISA ERS anycast IP addresses ( &ltIP_ADDRESS_LIST>; ). Inspect the "named.conf" file for the following: forward only; forwarders { &ltIP_ADDRESS_LIST>; }; If the "named.conf" options are not set to forward queries only to the ERS anycast IPs, this is a finding.

Discussion

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

V-272392 in V3R4

Check text

If this is a recursive name server, this is not applicable. Note: A recursive name server must 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.

Discussion

A potential vulnerability of DNS is that an attacker can poison a name server's cache by sending queries that will cause the server to obtain host-to-IP address mappings from bogus name servers that respond with incorrect information. Once a name server has been poisoned, legitimate clients may be directed to nonexistent 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 DODDoW, 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-000383-DNS-000047, SRG-APP-000246-DNS-000035

V-272394 in V3R4

Check text

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 &ltCrypto_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 &ltDNSSEC_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 information system security officer (ISSO)/information system security manager (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.

Discussion

Configuration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the system. Security-related parameters are those parameters impacting the security state of the application, including the parameters required to satisfy other security control requirements. Configuring the DNS server implementation to follow organizationwide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DODDoW that reflects the most restrictive security posture consistent with operational requirements.

V-272414 in V3R4

Check text

Verify that the DNSSEC and TSIG keys used by the BIND 9.x implementation are FIPS 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 ( &ltKEY HASH> ) ; KSK; 86400 DNSKEY 256 3 8 ( &ltKEY HASH> ) ; ZSK; The fifth field in the above example identifies what algorithm was used to create the DNSKEY. IfIn the fifth field, if 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.

V-272436 in V3R4