What's in a Name?

The debate over creating a single, multivendor patch to shore up Domain Name System servers appears likely to continue into the fall. Meanwhile, agencies have begun Phase Two of the cutover of networks to Internet Protocol Version 6. So how can federal IT staffs keep their agencies secure from DNS vulnerabilities?

IPv6 Phase 2 began in July, after agencies proved that they had basic IPv6 capabilities to send and receive IPv6 traffic internally and externally.

According to Peter Tseronis, chairman of the Federal IPv6 Working Group, a chief action item during Phase 2 focuses on development of operational guidance for secure deployment of IPv6. But he also points out that agencies need to craft enterprise security plans that support end-to-end security: “Securing IPv6 not only depends on the protocol but also on integration planning and implementation.”

Given the revelation earlier this year that DNS servers can expose users to attacks (cache poisoning, malicious redirect and denial of service) and the lack of a singular solution, agencies must apply fixes to keep their data and IT assets safe. Government security organizations and standards bodies have issued some suggestions.

Recommendations From US-CERT and IETF

The U.S. Computer Emergency Readiness Team provided tips on how to stymie cache poisoning and redirect attacks. (By introducing forged DNS information into the cache of a caching nameserver, the attacker can gain control of a system to download malware or to redirect a client to a fake site.)

For starters, US-CERT offers these recommendations:

• Apply a patch: Vendors have released patches to implement source port randomization in the nameserver, which makes cache poisoning attacks much more difficult.

• Restrict access: By limiting sources that can request recursion, an agency also limits exposure to the vulnerability.

• Disable recursion: Don’t allow it on any nameserver responding to DNS requests made by untrusted systems.

The Internet Engineering Task Force has created a draft server configuration to help deflect a denial-of-service attack using a recursive nameserver. The main line of defense calls for providing recursive name look-up service only to the intended clients. IETF suggests several ways to authorize clients:

• IP address authorization: Filter DNS queries through an access control list (ACL) to service only the intended clients. This works well if the server has a reasonably fixed IP address range protected against external address spoofing, such as a local network.

• Incoming interface-based selection: Use the interface as a discriminator. This works well for broadband routers that include embedded recursive nameservers.

• Secret Key Transaction Authentication for DNS (TSIG) or DNS Request and Transaction Signatures (SIG(0)s. TSIG or SIG(0) signed queries make sense for clients that change IP addresses frequently, such as those of mobile users. Typically, this method requires running a local instance of a caching nameserver to sign the queries and forward them to the recursive nameserver.

• Local caching or VPN: Another approach for mobile users would be to run a local caching nameserver on the device or to use a virtual private network to connect to a trusted server.