What’s The Cache?

Domain Name System (DNS) cache poisoning attacks are becoming more common. The attacks involve manipulating the Internet’s directory service to mimic sites and trick users into conducting financial transactions or installing adware and other unwanted programs. They are becoming an increasingly common problem for the large number of outdated or poorly implemented DNS servers that are still in use today. Certain Symantec gateway security appliances, among other commonly used devices, have also become victims of DNS cache poisoning in recent months, and there is no indication that the problem will let up any time soon.Hackers use a DNS server, which they control, to send fake addresses to other DNS servers to perform malicious attacks.

“Government workers could be directed to the wrong Web site where they could be tricked into giving up personal information or worse, have their money taken,” says Michael Hyatt, president and CEO of BlueCat Networks, Richmond Hill, Ont., Canada. “The government is as vulnerable as anybody.“

As a result of these attacks, Web surfers can unknowingly become re-directed to the poisoned DNS server simply by entering the URL of a well-known, commonly used Web site. Given the power of DNS cache poisoning, many believe it will ultimately become a powerful tool for online identity theft.

BlueCat Networks manufactures DNS and Dynamic Host Configuration Protocol appliances for the conveniently centralized administration and enterprise-wide management of IP addresses, configurations and hostnames. Clients include the U.S. federal government, military and state governments of Utah, Arizona Department of Housing, Regional Transportation of Nevada and Minnesota Department of Health.

Here are some steps suggested by BlueCat networks that organizations can take to minimize the risk of cache poisoning:

• Ensure that DNS servers are running the latest version of DNS software: BIND 9.2.x or MS Windows 2003.

• Limit recursion to internal DNS servers. Ensure that DNS servers are not fully open to recursive queries (especially externally facing name servers).

• Use forwarders if possible. Have internal name servers forward all non-authoritative queries to a set of forwarders and ensure that the forwarders are upgraded (latest version of DNS software) and locked down.

• If possible, split external authoritative name servers and forwarders. External authoritative name servers need to accept queries from almost any address, but forwarders do not (they should be configured to accept queries from internal addresses only).

• Make use of firewall services both at the network perimeter and on the DNS servers themselves.

• Make use of TSIG (Transaction Signatures) to digitally “sign” zone transfers and zone updates.

• Hide the version of BIND being run on the servers (do not advertise too much information).

• Run separate nameservers (for redundancy) on “different” networks (best if different physical locations are possible).

• Remove any unnecessary services running on the DNS servers (FTP, telnet, HTTP, etc).

• If possible, use dedicated appliances in place of multi-purpose servers.