CISCO CSS DNS
| Version 4 Release 1.18 |
| 2016-01-22 |
| U_CISCO_CSS_DNS_V4R1-18_Manual-xccdf.xml |
| The CISCO CSS DNS Security Technical Implementation Guide (STIG) is published as a tool to improve the security of Department of Defense (DoD) information systems. Comments or proposed revisions to this document should be sent via e-mail to the following address: disa.stig_spt@mail.mil. |
Vulnerabilities (10)
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.
Discussion
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.
Fix Text
Working with DNS Administrators and other appropriate technical personnel, the IAO should attempt to validate the hosts with expired validation dates. If these cannot be validated within a reasonable period of time, they should be removed. A zone file should contain adequate documentation that would allow an IAO or newly assigned administrator to quickly learn the scope and structure of that zone. In particular, each record (or related set of records, such as a group of LAN workstations) should be accompanied by a notation of the date the record was created, modified, or validated and record the owner’s name, title, and organizational affiliation. The owner of a record is an individual with the authority to request that the record be modified or deleted.
Check Content
BIND DNS zone record documentation will preferably reside in the zone file itself through comments, but if this is not feasible, the DNS database administrator will maintain a separate database for this purpose. The zone file location can be found by examining the named.conf and searching for the zone statement. Within the zone statement will be a file option that will display the name of the zone file. The reviewer should check that the record’s last verified date is less than one year prior to the date of the review. If this is not the case for any host or group of hosts, then this is a finding. Windows Ask the DNS database administrator if they maintain a separate database with record documentation. Windows DNS does not provide the capability to insert comments for records in a zone. The reviewer should check that the record’s last verified date is less than one year prior to the date of the review. If this is not the case for any host or group of hosts, then this is a finding.
Responsibility
Information Assurance Officer
IA Controls
ECSC-1
Zone-spanning CNAME records, that point to a zone with lesser security, are active for more than six months.
Discussion
The use of CNAME records for exercises, tests or zone-spanning aliases should be temporary (e.g., to facilitate a migration). When a host name is an alias for a record in another zone, an adversary has two points of attack the zone in which the alias is defined and the zone authoritative for the 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.
Fix Text
The DNS database administrator should remove any zone-spanning CNAME records that have been active for more than six months.
Check Content
BIND The zone file location can be found by examining the named.conf and searching for the zone statement. Within the zone statement will be a file option that will display the name of the zone file. The record type column will display CNAME. This is usually the third or fourth field in a record depending if the TTL value is utilized. Without a TTL value, the CNAME type will be in the third field, otherwise it will display as the fourth field. Review the zone files and the DNS zone record documentation to confirm that there are no CNAME records, pointing to a zone with lesser security, older than 6 months. 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 zone-spanning CNAME records older than 6 months and the CNAME records resolve to anything other than fully qualified domain names for 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 with an AO-approved and documented mission need, this is a finding. Windows Open the DNS management snap in for the Administrative Tools menu. Expand the Forward Lookup Zones folder. Review the type column for each record to locate those with a type of Alias (CNAME). Ask the DNS administrator to see the database with the record documentation is stored to confirm there are not CNAME records, pointing to a zone with lesser security, older than 6 months. 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 zone-spanning CNAME records older than 6 months and the CNAME records resolve to anything other than fully qualified domain names for 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 with an AO-approved and documented mission need, this is a finding.
Responsibility
System Administrator
IA Controls
ECSC-1
The shared secret in the APP session(s) was not a randomly generated 32 character text string.
Discussion
The core requirements related to zone transfers are that an authoritative name server transfers zone information only to designated zone partners and that name servers only accept zone data when it is cryptographically authenticated. CSS APP provides means to designate which devices it can share zone data and to authenticate those transactions. CSS devices can define their peers using IP addresses and authenticate them using Challenge Handshake Authentication Protocol (CHAP) with a shared secret. This setup also can be supplemented with MD5 hashing encryption. While this configuration does not provide the equivalent strength of cryptographic authentication as BINDs TSIG HMAC-MD5, it does provide a satisfactory level of information assurance when CSS DNS operates within a trusted network environment.
Fix Text
The CSS DNS administrator should use the following command while in global command mode; app session ip_address authChallenge shared_secret encryptMd5hash. In this command, ip_address refers to the IP address of the designated peer and the shared_secret is a text string up to 32 characters in length.
Check Content
Interview the SA and determine if the key was randomly generated 32-character text string.
Responsibility
System Administrator
IA Controls
DCNR-1
The Cisco CSS DNS is utilized to host the organizations authoritative records and DISA Computing Services does not support that host in its csd.disa.mil domain and associated high-availability server infrastructure.
Discussion
The primary security concern with regard to the type of delegation discussed is that to implement this approach, an organization would have to migrate its authoritative records from a well-known DNS implementation with proven, tested security controls to a relatively new DNS implementation without similar controls. Therefore, this migration should only occur when the performance and availability advantages of CSS significantly outweigh the increased residual security risk of using a less mature technology.
Fix Text
The CSS DSN administrator should use the following command while in global command mode; no dns-record, to remove domain records that do not support hosts in the csd.disa.mil domain.
Check Content
Determine whether the CSS DNS device is used as an authoritative name server. If the CSS DNS does maintain authoritative records, then this is a finding. The exception to this is if this CSS DNS device supports authoritative records for a host(s) within the csd.disa.mil domain, which is not a finding. Instruction: In the presence of the reviewer, the CSS DNS administrator should enter the following command while in global configuration mode: show dns-record statistics If any of the hosts have domain names outside of the csd.disa.mil domain, then this is a finding.
Responsibility
System Administrator
IA Controls
ECSC-1
Zones are delegated with the CSS DNS.
Discussion
Although it is technically possible to delegate zones within CSS DNS, there is almost never a rationale to do so because such delegation could be achieved as easily with BIND, which offers security features not present in CSS DNS. Moreover, the performance enhancing features of CSS typically would not apply to name server records because these records are obtained easily and quickly across the wide area without significant impact on a users experience
Fix Text
The CSS DNS administrator should remove any NS records with the following command while in global configuration mode; no dns-record ns domain_name.
Check Content
In the presence of the reviewer, the CSS DNS administrator should enter the following command while in global configuration mode: show dns-record statistics There should be no DNS record types of NS. If there are NS records, then this is a finding.
Responsibility
Information Assurance Officer
IA Controls
ECSC-1
The CSS DNS does not transmit APP session data over an out-of-band network if one is available.
Discussion
One can also limit APP communication to an out of band network, which would make it considerably more difficult for adversaries to spoof the addresses of peers or hijack APP sessions.
Fix Text
The CSS DNS administrator should use the following command while in global configuration mode; app session 1.2.3.4 (sample IP address), to configure CSS to only transmit session data over an out-of-band network, if one is available.
Check Content
In the presence of the reviewer, the CSS DNS administrator should enter the following command while in global configuration mode: show app session Instruction: Ensure Application Peering Protocol (APP) session data is not sent over an out-of-band network. If APP session data is sent over an out-of-band network, then this is a finding.
Responsibility
System Administrator
IA Controls
ECSC-1
Forwarders are not disabled on the CSS DNS.
Discussion
CSS DNS is not vulnerable to attacks associated with recursion because it does not support recursion, but does offer a forwarder feature that sends un-resolvable or unsupported requests to another name server. This feature poses a risk because the forwarder feature merely redirects potential attacks to another name server.
Fix Text
The CSS DNS administrator should disable forwarders by entering the following command while in global configuration mode: no dns-server forwarder primary (if a primary) or no dns-server forwarder secondary (if a secondary).
Check Content
In the presence of the reviewer, the CSS DNS administrator should enter the following command while in global configuration mode: show dns-server forwarder Confirm the DNS server forwarder primary and DNS server forwarder secondary are “Not Configured.” If either of these is configured, then this is a finding.
Responsibility
System Administrator
IA Controls
ECSC-1
CSS DNS does not cryptographically authenticate APP sessions.
Discussion
The risk to the CSS DNS in this situation is the CSS DNS peers do not authenticate each other, the sending and receiving of APP session data and peer communication may be with an adversary rather than the intended peer, thereby sending sensitive network architecture data and receiving ill intended zone data. To protect against this possibility, the CSS DNS peers must cryptographically authenticate each other.
Fix Text
The command, show app session, displays that the authentication type is not set to authChallenge and the encryption type is not set to encryptMd5hash.
Check Content
In the presence of the reviewer, the CSS DNS administrator should enter the following command while in global configuration mode: show app session Confirm the authentication type is set to “authChallenge” and the encryption type is set to “encryptMd5hash.” This will confirm APP CHAP authentication and MD5 hashing features for APP sessions are configured between peers, if this is not the case, then this is a finding. The only exception would be if the CSS DNS administrator uses an IPSEC VPN between each peer couple. Review the IPSEC VPN with the CSS DNS administrator and validate the IPSEC VPN is configured between peers, if this is not the case, then this is a finding.
Responsibility
System Administrator
IA Controls
DCNR-1
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”.
Discussion
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.
Fix Text
The SA should remove any link-local addresses and replace with appropriate Site-Local or Global scope addresses.
Check Content
BIND • Instruction: Examine all zone statements contained in the named.conf file for a line containing the word file designating the actual file that stores the zones records. Examine the file that contains zones records for any IPv6 addresses containing the prefixes “FE8”, “FE9”, “FEA”, or “FEB”. If any link-local scope addresses are found, then this is a finding. Windows DNS • Instruction: From the windows task bar, select Start, Programs/All Programs, Administrative Tools, DNS to open the DNS management console. Expand the Forward Lookup Zones folder. Expand each zone folder and examine the host record entries. The third column titled Data will display the IP. Verify this column does not contain any IP address that begin with the prefixes “FE8”, “FE9”, “FEA”, or “FEB”.
Responsibility
System Administrator
IA Controls
ECSC-1
AAAA addresses are configured on a host that is not IPv6 aware.
Discussion
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.
Fix Text
The SA should remove the IPv6 records from the IPv4 zone and create a second zone with all IPv6 records.
Check Content
BIND • Instruction: Examine all zone statements contained in the named.conf file for a line containing the word file designating the actual file that stores the zones records. Examine the file that contains zones records and verify IPv6 and IPv4 resource records are not in the same file. If the records are found in the same file, then this is a finding. Windows DNS Instruction: From the Windows task bar, select Start, Programs/All Programs, Administrative Tools, DNS to open the DNS management console. Expand the Forward Lookup Zones folder. Expand each zone folder and examine the host record entries. The third column titled Data will display the IP. Verify this column does not contain both IPv4 and IPv6 addresses.
Responsibility
Other
IA Controls
ECSC-1