Misuse of DNS – and how to prevent it

The DNS infrastructure is fundamental to Internet communications, so it is not surprising that it is abused in so many different ways by so many different activities that threaten IT security. Let’s look at some examples and possible solutions.

Some malware, when it gets into a network, is so primitive that it does not even contain the code needed for its real activity – it has to be downloaded first, and since the DNS protocol is in many places almost unrestricted, the traffic between the bot and its command control (C2) server can be disguised as DNS requests and responses (DNS tunneling, infiltration).

A company’s internal DNS servers can also be misused for reconnaissance. If you see that some clients are systematically querying entire subnets and lots of domain names, you should be suspicious. Of course, if data can be smuggled in via DNS protocol, it can also be sent out (DNS exfiltration).

Well-developed malware can also be used to target known vulnerabilities in DNS servers to cause damage, or even to hijack internal clients to, e.g., websites with additional threats.

Name servers also play a significant role in DDoS attacks. The consequences of attacking our own public servers are obvious, but it is not a good thing to unwittingly participate in such attacks either. A popular technique is the reflection attack, where the source address is spoofed so that our server sends its response to the target under attack rather than the original client. This unnecessarily consumes our servers’ resources, and those of our colleagues, who later have to remove our names and server addresses from all sorts of reputation lists…

Some recent IT security incidents have shown that, however sophisticated the malware’s activity itself, it could be identified by a few typical DNS queries and could be disabled based on them. (It could have been, if the operators had been informed in time.) However, this immediately becomes much more difficult if the malware does not look for its C2 server on hard-coded IP addresses or domain names, but instead a domain generation algorithm (DGA) generates the domain names to be used. If one is blocked, it tries the next one until it succeeds. In parallel, of course, it is also ensured that these new and even newer name records are available in the public DNS service when needed.

So what should we do? Keep your DNS traffic under control!

• Use the Threat Prevention feature on your next-gen firewall; if it looks into the DNS payload, it can catch a significant amount of DNS tunneling and in/exfiltration traffic. In some cases, such activity can be spotted on a quantitative basis, although newer malware is now trying to avoid attracting attention.

• Use separate DDoS protection, too, if needed.

• Harden your DNS servers. As much as possible, limit what queries they accept, allow zone transfers only with legitimate partners, encrypted if possible.

• Recursive queries to the Internet should preferably be filtered on the DNS servers or forwarded to a cloud service that provides protection. There are a number of lists and feeds available, some free and some paid, to help block unwanted DNS traffic.

• In general, it is very rare that an organization wants to use recently (say 0-72 hours) registered domain names. These should be filtered with specialized lists and any exceptions should be explicitly allowed.

• DGA can be trickier, not sure if it can be identified either by lists or on a quantitative basis. There are, however, specific DNS security tools that can block even these based on data patterns and client behavior.

As with everything in IT security, the same is true for DNS: assess the potential threats, determine which of them can be effectively protected by which means, and then design a protection system that is tailored to your needs and can be operated ergonomically.