DNS security appliances in Azure

Overview

Malware and botnets (such as ZeroAccess, Conficker and Storm) need to be able to propagate and communicate. They use several communication techniques, including DNS, IRC and Peer-to-Peer networks. Normally the DNS protocol resolves human-friendly domain names into machine-friendly IP addresses. However, the fact that most organizations do not filter DNS queries means that it can be used as a covert communication channel. Data leaving a compromised system can be encoded in the DNS query and instructions can be sent back to the malware in the DNS responses without raising suspicions.

This article gives an overview of this threat and describes some ways of protecting your network from it.

How DNS works

DNS is a highly distributed system, i.e. no single server or organization has the answers to all DNS queries. The “.com” DNS servers know which Microsoft servers have DNS data for “microsoft.com” but they do not have the DNS records themselves. These authoritative DNS servers only store data for their own domains and traversal of a number of authoritative DNS servers may be required to find a particular DNS record.

When an application needs to lookup a DNS record, a query is sent to a local recursive resolver. This server navigates the hierarchy of authoritative DNS servers to find the required DNS record. This process is called recursive resolution and is usually handled by a fleet of resolvers within your infrastructure, or in this case, within the Azure infrastructure. The IP addresses of the recursive resolvers are either statically configured in the operating system (by the network admin) or dynamically configured through systems such as DHCP. Azure uses DHCP.

 

Most of the time, recursive resolvers do not filter the queries they are resolving. While your network administrator might not allow you to open a http connection to an outside resource, chances are the admin will allow arbitrary DNS requests to be resolved. Sure, what harm can a DNS query do?

DNS-based threats

The DNS system doesn’t just map domain names to IP addresses. There are a number of different DNS record types. For example, MX records are used to locate the mail servers for a domain and TXT records can store arbitrary text. Records such as TXT records make it easier for the malware to retrieve data, e.g. instructions or payload.

Bad actors can use DNS queries within their malware to contact command and control servers. The malware does a DNS query and then interprets the response as a set of instructions, such as “this target is interesting, install the key logger”. They can also use DNS queries to download malware updates and additional modules. To make them harder to block, malware often uses a domain generation algorithm (DGA) to generate a large number of new domains each day. To keep the communication channel open, attackers only need to register a small number of these domains, but, to block communications, law enforcement needs to block nearly all of them. This stacks the deck in favour of the bad guys.

Ok, so that’s inbound communication. What about exporting data from infected servers? The DNS protocol allows a domain name to be up to 253 characters long and queries for “<something>.mydomain.com” will land on the DNS servers for “mydomain.com”. Data can be exported by crafting DNS queries on the infected host (e.g. “the_password_for_joeblogs_gmail_com_is_letMeIn.mydomain.com”) and using custom DNS server software to interpret the message on the other end. This method has been generalized into the TCP-over-DNS protocol (not to be confused with DNS-over-TCP), which tunnels TCP traffic through the DNS infrastructure.

It’s important to note that the malware needs to have infected the server before it can start using these communication channels. Therefore, filtering DNS is primarily a layered defense mechanism–a mitigation for when other techniques have failed to prevent the initial infection. In desktop environments, DNS filtering can also help prevent malicious links in emails or on websites from initiating the infection process.

Best practices

There is no substitute for good security and good security always uses a layered approach. The primary focus should be on preventing malware infections and propagation. An additional layer is to monitor and/or filter DNS traffic to detect and/or block communication of malware on infected machines. A balanced defense strategy should consider the following:

• Keep servers patched and up to date.
• Expose only the endpoints that are truly necessary.
• Use Network Security Groups (network ACLs) to restrict communication to/from/within your network, e.g. block DNS traffic (port 53) to servers other than trusted recursive resolvers.
• Use firewalls (DNS, application and IP) to detect and filter malicious traffic and see 3rd-party appliances available in the Azure Marketplace.
• Separate critical and risky workloads (e.g. don’t surf the web from your database server).
• Run anti-virus/anti-malware on your servers (e.g. Antimalware for Azure).
• Run a smart DNS resolver (a DNS firewall) that scans DNS traffic for malware activity. See the Azure Marketplace for available 3rd-party DNS firewalls.

While the Azure infrastructure provides the core set of security features, Azure is also building a large ecosystem of 3rd-party security products. They’re available through the Azure Marketplace (e.g firewall, waf, antivirus, DNS firewall) and can be deployed with just a few clicks. Many offer a free trial, after which they can be billed either directly through the supplier or hourly through your Azure subscription.

A growing trend is for enterprises to deploy DNS firewalls in their infrastructure and we’ve started adding 3rd-party DNS firewalls to the Azure Marketplace. These are special DNS servers that inspect DNS queries for signs of malware activity and alert and/or block the traffic. For example, a query to a command and control (C&C) server can be identified by either the domain being queried or the IP address of the DNS server. A DNS firewall is deployed as a DNS server within your virtual network and often uses a threat intelligence feed to keep up to date with the changing threat landscape. So your virtual network will look something like this: