{
  "name": "stig_windows_dns",
  "date": "2015-12-28",
  "description": "None",
  "title": "Windows DNS",
  "version": "None",
  "item_syntax": "^\\w-\\d+$",
  "section_separator": null,
  "items": [
    {
      "id": "V-12479",
      "title": "Computer accounts for DHCP servers are members of the DNSUpdateProxy group.",
      "description": "A built-in security group, DNSUpdateProxy, is provided as of Windows 2000. This group can update DNS records for clients without becoming the owner of the records. When DHCP servers are added as members of this group, any of the (member) DHCP servers can update the records. The first user that is not a member of the DNSUpdateProxy group to modify the records associated with a client; becomes the owner. There is a vulnerability for all servers (even non-domain controllers) on which a DHCP service runs. The DNS records associated with the DHCP server host could be modified by other DHCP servers that are members of the DNSUpdateProxy group. In order to prevent this from occurring, DHCP should not be installed on a domain controller if the group DNSUpdateProxy is utilized.",
      "severity": "medium"
    },
    {
      "id": "V-14756",
      "title": "The DNS administrator will ensure non-routeable IPv6 link-local scope addresses are not configured in any zone.  Such addresses begin with the prefixes of “FE8”, “FE9”, “FEA”, or “FEB”.",
      "description": "IPv6 link local scope addresses are not globally routable and must not be configured in any DNS zone.  Similar to RFC1918, addresses, if a link-local scope address is inserted into a zone provided to clients, most routers will not forward this traffic beyond the local subnet.",
      "severity": "low"
    },
    {
      "id": "V-14757",
      "title": "AAAA addresses are configured  on a host that is not IPv6 aware.",
      "description": "DNS is only responsible for resolving a domain name to an ip address.  Applications and operating systems are responsible for processing the IPv6 or IPv4 record that may be returned.  With this in mind, a denial of service could easily be implemented for an application that is not IPv6 aware.  When the application receives an i.p. address in hexadecimal, it is up to the application/operating system to decide how to handle the response.  Combining both IPv6 and IPv4 records into the same domain can lead to application problems that are beyond the scope of the DNS administrator.",
      "severity": "low"
    },
    {
      "id": "V-14768",
      "title": "The IPv6 protocol is installed and the server is only configured to respond to IPv4 A records.",
      "description": "To prevent the possibility of a denial of service in relation to an IPv4 DNS server trying to respond to IPv6 requests, the server should be configured not to listen on any of its IPv6 interfaces unless it does contain IPv6 AAAA resource records in one of the zones.",
      "severity": "medium"
    },
    {
      "id": "V-3625",
      "title": "Shares other than the default administrative shares are enabled on a name server.",
      "description": "Non-administrative shares are unnecessary for name server operation and provide adversaries with an additional possible point of attack.",
      "severity": "medium"
    },
    {
      "id": "V-4467",
      "title": "Record owners will validate their zones no less than annually.  The DNS database administrator will remove all zone records that have not been validated in over a year.  ",
      "description": "If zone information has not been validated in over a year, then there is no assurance that it is still valid.  If invalid records are in a zone, then an adversary could potentially use their existence for improper purposes. An SOP detailing this process can resolve this requirement.\n",
      "severity": "low"
    },
    {
      "id": "V-4468",
      "title": "Resource records for a host in a zone file are included and their fully qualified domain name resides in another zone. The exception is a glue record or CNAME record supporting a system migration.",
      "description": " 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 servers 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.  The two key exceptions to this rule involve glue for NS records and CNAME records for legacy resolution support",
      "severity": "low"
    },
    {
      "id": "V-4469",
      "title": "Zone-spanning CNAME records, that point to a zone with lesser security, are active for more than six months. ",
      "description": "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 aliases 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 compounding the vulnerability.",
      "severity": "low"
    },
    {
      "id": "V-4470",
      "title": "The DNS database administrator has not ensured each NS record in a zone file points to an active name server authoritative for the domain specified in that record.",
      "description": "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.\n\nThe 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 likely not occur if the true slave were active.\n",
      "severity": "high"
    },
    {
      "id": "V-4473",
      "title": "DNS software does not run on dedicated (running only those services required for DNS) hardware. The only currently accepted exception of this requirement is Windows 2000/2003 DNS, which must run on a domain controller that is integrated with Active Directory services.\n\n",
      "description": "Even a securely configured operating system is vulnerable to the flaws of the programs that run on it.  To prevent DNS software from being subjected to the vulnerabilities of other programs and services, the DNS server will not run other programs and services at all,  or at least run only those programs that are necessary for either OS or DNS support.",
      "severity": "medium"
    },
    {
      "id": "V-4475",
      "title": "Permissions on files containing DNS encryption keys are inadequate.",
      "description": "Weak permissions could allow an intruder to view or modify DNS encryption key files. These keys should never be readable by Other or Everyone.",
      "severity": "medium"
    },
    {
      "id": "V-4476",
      "title": "Users and/or processes other than the DNS software Process ID (PID) and/or the DNS database administrator have edit/write access to the zone database files.",
      "description": "Weak permissions on key files could allow an intruder to view or modify DNS zone files. Permissions on these files will be 640 or more restrictive. ",
      "severity": "medium"
    },
    {
      "id": "V-4477",
      "title": "Users or processes other than the DNS software administrator and the DNS software PID have write access to these files. ",
      "description": "Weak permissions on key DNS configuration files could allow an intruder to view or modify DNS name server configuration files.",
      "severity": "medium"
    },
    {
      "id": "V-4478",
      "title": "The name server’s IP address is NOT statically defined and configured locally on the server. The name server has a DHCP address. ",
      "description": "Static IP addresses permit a machine to offer Internet services like web, ftp, DNS, and email. Because a specific, known address is associated with your connection, other machines on the Internet know where to send traffic destined for your server.  Required ACL restrictions at the router and or firewall are required to protect the DNS server from unauthorized access. Such ACLS  require a static IP address to be effective.",
      "severity": "medium"
    },
    {
      "id": "V-4479",
      "title": "An integrity checking tool is not installed or not monitoring for modifications to the root.hints and named.conf files.\n\n",
      "description": "An integrity checking tool compares file and directory integrity to the baseline. It can alert the system administrator to unauthorized changes in files or directories. Unauthorized changes in files and directories can give a user unauthorized access to system resources.  Undetected changes to DNS name server root hints and configuration files is the single greatest risk to the security and stability of the DNS name server.  An integrity checking tool (e.g., Tripwire) aids in effectively monitoring and controlling changes to ensure improved security and system availability.  This applies to both authoritative and caching name servers.",
      "severity": "medium"
    },
    {
      "id": "V-4481",
      "title": "Dynamic updates are not cryptographically authenticated.",
      "description": "The dynamic update capability has considerable appeal in an environment in which IP addresses change so frequently that it would be unacceptably burdensome or expensive to dedicate the time of a DNS database administrator to this function.  This condition would likely be met at sites that rely on the Dynamic Host Configuration Protocol (DHCP) to assign IP addresses to client devices such as workstations, laptops, and IP telephones.  It would also apply to sites that utilize frequently changing service (SRV) records.\n\nOn the other hand, dynamic updates can pose a security risk if the proper security controls are not implemented. When dynamic updates are permitted without any mitigating controls, a host with network access to the name server can modify any zone record with an appropriately crafted dynamic update request.  \n\nThe solution is to require cryptographic authentication of all dynamic update requests, but not all DNS software supports this functionality.  ",
      "severity": "high"
    },
    {
      "id": "V-4482",
      "title": "The DNS software administrator will configure each master/slave server supporting a zone to cryptographically authenticate zone transfers.",
      "description": "A slave updates its zone information by requesting a zone transfer from its master.  In this transaction, the risk for the slave is that the response to its request is not in fact from its authorized master but from an adversary posing as the master.  In this scenario, such an adversary would be able to modify and insert records into the slaves zone at will.  To protect against this occurrence, the slave must be able to authenticate the master to provide assurance that any zone updates are valid.",
      "severity": "high"
    },
    {
      "id": "V-4483",
      "title": "A zone master server does not limit zone transfers to a list of active slave name servers authoritative for that zone.",
      "description": "The risk to the master in this situation, is that it would honor a request from a host that is not an authorized slave, but rather an adversary seeking information about the zone.  To protect against this possibility, the master must first have knowledge of what machines are authorized slaves.",
      "severity": "medium"
    },
    {
      "id": "V-4485",
      "title": "A name server is not configured to only accept notifications of zone changes from a host authoritative for that zone.",
      "description": "A slave updates its zone information by requesting a zone transfer from its master.  In this transaction, the risk for the slave is that the response to its request is not in fact from its authorized master but from an adversary posing as the master.  In this scenario, such an adversary would be able to modify and insert records into the slaves zone at will.  To protect against this occurrence, the slave must be able to authenticate the master to provide assurance that any zone updates are valid.",
      "severity": "medium"
    },
    {
      "id": "V-4486",
      "title": "Recursion is not prohibited on an authoritative name server.",
      "description": "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.\n\nTo 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.",
      "severity": "medium"
    },
    {
      "id": "V-4487",
      "title": "A caching name server does not restrict recursive queries to only the IP addresses and IP address ranges of known supported clients.",
      "description": "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.",
      "severity": "medium"
    },
    {
      "id": "V-4488",
      "title": "The DNS software must log success and failure events when starting and stopping of the name server service daemon, zone transfers, zone update notifications, and dynamic updates. ",
      "description": "Logging must be comprehensive to be useful for both intrusion monitoring and security investigations. Setting logging at the severity notice should capture most relevant events without requiring unacceptable levels of data storage. The severity levels info and debug are also available to organizations that require additional logging for certain events or applications.",
      "severity": "high"
    },
    {
      "id": "V-4489",
      "title": "The DNS software administrator has not configured the DNS software to send all log data to either the system logging facility (e.g., UNIX syslog or Windows Application Event Log) or an alternative logging facility with security configuration equivalent to or more restrictive than the system logging facility.",
      "description": "On name servers, DNS log data is typically more sensitive than system log data and, consequently, should benefit from security controls at least as restrictive as those for the system logging facility.  DNS software administrators require DNS transaction logs for a wide variety of reasons including troubleshooting, intrusion detection, and forensics.  These logs should be appropriately secured, having file permissions that restrict unauthorized changes or viewing, and archived, being appropriately backed-up and stored in order for them to be examined at a future time.  Furthermore, it is required that the logs be reviewed daily.",
      "severity": "medium"
    },
    {
      "id": "V-4490",
      "title": "Entries in the name server logs do not contain timestamps and severity information.",
      "description": "Forensic analysis of security incidents and day-to-day monitoring are substantially more difficult if there are no timestamps on log entries.",
      "severity": "low"
    },
    {
      "id": "V-4492",
      "title": "The DNS software administrator has not removed the root hints file on an authoritative name server in order for it to resolve only those records for which it is authoritative, and ensure that all other queries are refused.",
      "description": "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.\nWhen 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.",
      "severity": "low"
    },
    {
      "id": "V-4501",
      "title": "The DHCP server service is not disabled on any Windows 2000/2003 DNS server that supports dynamic updates.",
      "description": "There is a significant vulnerability potential when the DHCP service runs using the computer account of a Windows Domain Controller, as in the default Windows configuration. This account has full control over all DNS objects stored in Active Directory. In this case the DHCP server has access to modify the SRV (and other) records for all the Domain Controllers. When these records were replicated to other domain controllers (when AD Integrated DNS is used as required by the STIG), all the Windows DNS servers could potentially be compromised. ",
      "severity": "high"
    },
    {
      "id": "V-4502",
      "title": "Zone transfers are not prohibited or a VPN solution is not implemented that requires cryptographic authentication of communicating devices and is used exclusively by name servers authoritative for the zone.",
      "description": "If zone transfers are not cryptographically authenticated, then there is the potential for an adversary to masquerade as a legitimate zone partner and update zone records without authorization.",
      "severity": "high"
    },
    {
      "id": "V-4503",
      "title": "Forwarders on an authoritative Windows 2000/2003 DNS server are not disabled.",
      "description": "Windows DNS has historically been more vulnerable to cache poisoning attacks than BIND as the algorithm used for answering recursive queries also makes it more prone to self-imposed denial of service attacks and as an amplification device for attacks on other DNS servers. Additionally, Windows DNS does not allow for the fine-grained access control restrictions (i.e., limiting the clients that are able to perform recursion) that are allowed by BIND and other recursive DNS appliances. Therefore, Windows 2000/2003 DNS should not be deployed as a caching name server.  Consequently, the use of forwarders and recursion is prohibited on Windows 2000/2003 DNS servers.  ",
      "severity": "medium"
    },
    {
      "id": "V-4505",
      "title": "WINS lookups is not prohibited on a Windows 2000 DNS server.",
      "description": "Integration of WINS and Windows 2000 DNS leaves Windows 2000 DNS open to all the vulnerabilities of WINS, including the ability to update records without authentication.",
      "severity": "high"
    }
  ]
}