eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The seriousness of the recent DNS cache poisoning vulnerability, discovered by security researcher Dan Kaminsky, raises the bar for network security administrators and should provoke development of a comprehensive plan to address this insidious threat. Every enterprise has a caching DNS server and is thus a target of the Kaminsky DNS cache poisoning flaw.
A Kaminsky DNS cache poisoning attack consists of two steps:
Step No. 1: The attacker sends fake DNS queries, or questions, to internal caching DNS servers. These queries are for domains that the caching server will not have cached, so it will have to generate subsequent queries to authoritative servers on the Internet.
Step No. 2: The attacker then sends a barrage of fake answers to each fake question, attempting to spoof the answer from the authoritative server. To succeed, the attacker has to correctly guess various query parameters-such as Transaction ID and User Datagram Protocol (UDP) source port-before a valid response from the legitimate authoritative server reaches the caching DNS server. There are some additional technical details about the fake answer that will be discussed later in this article.
If the attacker succeeds in getting his or her fake answer accepted by the caching DNS server, the consequences are quite serious. The poisoned DNS entry can be used to redirect Web traffic, e-mail or any other IP application to a malicious server controlled by an attacker. Since the DNS points users to their destinations, it is completely unaware that the traffic is being diverted.
Protecting against the Kaminsky attack
As with any security vulnerability, the best approach for protecting against the Kaminsky attack is to employ multiple defenses. In this case, traditional firewalls and intrusion prevention systems (IPS) can be part of the solution, providing an initial defensive shield that will reduce the number of fake DNS query requests and responses.
But most firewalls and IPS will not stop a fake DNS response from poisoning the DNS cache if the DNS query parameters match. This means it is a primary consideration to ensure that the DNS server itself employs the best possible defenses. Put another way, DNS security starts with the DNS server.
DNS Security Starts with the DNS Server
DNS security starts with the DNS server
The DNS server is best equipped to deal with DNS threats since it is where all the DNS intelligence resides. The following are four capabilities that are necessary to protect the DNS. It is worth investigating the capabilities of your DNS server to make certain all of these defenses are available and enabled.
Defense No. 1: UDP source port randomization (UDP SPR) was specified by key DNS vendors as the initial response to the Kaminsky attack. Randomizing the UDP source port used in a query makes it harder for an attacker to guess the query parameters in a fake answer. Although UDP SPR is a useful defense, there is widespread concern that it is not an adequate long-term response to cache poisoning.
In addition, Network Address Translation (NAT), firewalls, load balancers and potentially other devices in the network may de-randomize UDP source ports, thus rendering this protection less effective. For these reasons, it is essential that other defenses are available and enabled.
Defense No. 2: A secure mode of DNS operation when a potential attack is detected is another useful defense. The DNS server should be able to switch from a UDP to a TCP connection when mismatched query parameters are observed (a sign an attack may be underway). This allows an attacker only one chance to send a fake DNS answer for each fake DNS question, which both slows the progress of an attack and significantly reduces the probability of success (potentially by hundreds of times).
Defense No. 3: The single most important defense provides protection when an attacker gets lucky and correctly guesses query parameters, thus beating other defenses. This defense screens DNS query responses and discards potentially harmful information in the response, such as additional information that delegates DNS answers to a server that is controlled by the attacker. This protects the DNS server in ways a firewall, IPS or any other external device cannot.
Defense No. 4: The last defense to enable is alerting IT of unusual DNS activity and providing specific details so remedial action can be taken.
Additional Defenses with Routers, Firewalls and IPS
Additional defenses with routers, firewalls and IPS
In the first step of the Kaminsky attack, fake questions are sent to a caching server. To succeed at sending fake questions, an attacker needs to spoof an address on the enterprise network. Firewalls and routers can be configured to provide excellent protection against external users spoofing an internal IP address. Keep the following in mind:
1. Be sure to configure the firewall rules, router Access Control Lists (ACLs) or Reverse Path Forwarding (RPF) check to prevent external users from spoofing an internal IP address. This will block external users from initiating internal, recursive DNS queries.
2. Another important consideration is verifying that firewalls in the path of the DNS server do not de-randomize the UDP source ports used in DNS queries coming from the caching DNS server out to the Internet. There may be configuration options on the firewall or it may be necessary to contact the vendor. This is important because one of the defenses against the Kaminsky attack relies on random UDP source ports.
IPS is another important part of the security equation and provides an additional layer of defense. IPS looks at application data flows and detects threats based on algorithms that detect anomalous behaviors and send alerts.
3. Sending multiple fake responses to the caching name server will increase the chances of a successful cache poisoning attack. IPS signatures can detect anomalous DNS packet rate behavior, and vendors are responding with features that will make it simple to implement such signatures. This will regulate the number of fake response packets to the DNS server.
4. Both firewalls and IPS to should be configured to send alerts to a Security Information and Event Management (SIEM) server or management server when they see multiple fake responses from a single source to a DNS query. This will help in alerting and remediation against cache poisoning attacks.
Properly implementing a defense-in-depth approach that includes a combination of firewalls, IPS and intelligent DNS servers with layers of defense will provide total protection against DNS cache poisoning.