Hijacking DNS look up is not a new attack vector. Massive DNS hijacking instances were observed a decade ago. But DNSChanger botnet was known to be the largest in terms of number of computers affected. This article explains the DNS hijacking attack technique in general, possible measures to prevent it and a technique to detect this attack in the LAN.
What is DNS Hijacking?
Domain Name System, built upon IP protocol, is one of the most essential auxiliary protocols of IP networking. It provides convenience to users and flexibility to application and network designers. DNS protocol essentially helps to resolve a textual name to an IP address which computers and networks use to route IP traffic. In this process there are three parties involved: The operating system/application program (the Client) that tries to resolve a textual name into an IP address, a DNS resolver/DNS cache system, and the authoritative DNS server.
In a hijacked scenario the first one becomes the victim and the second one is replaced by hijacker’s DNS Resolvers. A Trojan–for example DNSChanger–changes the resolver IP addresses in the Client so that the attacker can take the DNS loook up traffic to a DNS resolver/cache that he wants and provide any IP address he wants in response to a DNS look up.
Though DNSChanger botnet was taken down, DNS hijacking is likely to continue to be a favorite technique among viruses/trojans writers. So it will be wise to keep the networks prepared to prevent and detect this in future.
How to Prevent DNS Hijacking?
In Local Area Networks, either there will be a local DNS resolver/cache service running or will be using an external, third-party DNS resolver/cache (mostly provided by the ISPs and other DNS service providers). In either case, it will be one or more known IP addresses. Clients in the LAN must be using this service for DNS name resolution in the normal course. This means that Clients should not be sending the look up traffic to any other IP addresses. The best point in the network to ensure this is the LAN gateway. So, with an appropriate policy, ensure at the LAN gateway that no DNS look up traffic goes to arbitrary IP addresses from the LAN. With this policy, you can enforce how DNS resolution is performed on behalf of all the Clients in the LAN. Even if a Client is infected, as long as they are located inside the LAN, its DNS look ups cannot be hijacked now.
To go one step further, it is possible to divert DNS look up traffic to arbitrary IP addresses at the gateway to the designated DNS server IP addresses of the LAN. This would happen transparently to the Client and thus avoid any service disruption to infected Clients. The downside is that the infection would go unnoticed. But it is possible to detect hijacked traffic in the network.
Detecting DNS Hijacking
Hijacked DNS traffic is unintended traffic in the network. Intrusion Detection Systems (IDS) are designed for detecting unintended traffic. If there is an IDS service running in your gateway, or an IDS device installed in your network, it will be easy to set up DNS hijack monitoring. Create a policy to generate alert in the IDS if DNS look up traffic is going to arbitrary IP addresses from the LAN. When the IDS generates an alert, it is almost certain that a hijack incident occurred in the LAN. Now trace the infected Client and verify it.
While setting up the IDS rule for this, ensure that the designated DNS resolvers’ traffic is exempted. Your LAN may have services/servers running which need to send out legitimate DNS traffic to arbitrary IP addresses across the gateway; exempt that too.
These are not fool-proof techniques to prevent DNS hijacking but it can help in most cases. If you are running Mettle SE Integrated Network Services Engine, follow the Knowledge Base articles listed below to set up this.