← Short technical articles

Welcome to this page on DNS tunneling. The goal is to keep track of the state of the art in its execution and prevention, more importantly the security impact these have on large organizations.

Tunneling arbitrary data through DNS
General approach to DNS tunneling
Detection of DNS tunneling
Countermeasures against DNS tunneling
Articles and discussions on DNS tunneling, Links, Resources, ...

To the contrary of popular belief, DNS tunneling is not new. It was first suggested in this Bugtraq posting in April of 1998. Its real break to fame though was in Dan Kaminsky's 2004 Defcon presentation. In between, there was also a tool called NTSX, which allowed you to do DNS tunneling without any difficulty. However, Dan added a new thing to the mix: entertainment. His tool allowed one to segment audio in small chunks and distribute it, and have it cached, in DNS servers. After this presentation, everything changed, and suddenly DNS tunneling was a major concern. Not so much for the radio though, but the tunneling itself - which wasn't new.

The concept: tunneling arbitrary data through DNS

The interesting aspect of DNS tunneling is that it is a usable covert channel which is in fact operating system independent. It allows someone to move data out of a network by using a regular, mostly unfiltered internet protocol. At the time of writing, May 2006, there are two DNS tunneling applications in common use. These are NSTX and OzyManDNS.

General Approach to DNS tunneling

DNS Tunneling works by abusing DNS records to traffic data in and out of a network. In principle, every type of record can be used, but the speed of the connection differs by the amount of data that can be stored in a single record. Below are some obvious ones:

• TXT records allow free-form data and can even include spaces. You can as such store information in it encoded with base64, allowing 220 bytes of data per record. TXT records are intended for "generic" use within the DNS framework. Users can place whichever data in it, as long as it meets the protocol requirements: a maximum length of 255 octets according to RFC 1035. In the recent past, TXT records had virtually been depreciated, which would have enabled highly security conscious environments to discard them at the enterprise DNS server. Today however, they have regained use as the carrier of the antispam-related SPF record.
• CNAME records allow only the characters A through Z, digits 0-9 and the hyphen. As such you require base32 encoding and are limited to about 110 bytes per record.
• EDNS0 messages can be larger than the 512 byte maximum for UDP DNS, and can carry a 1280 byte payload by default. OzyManDNS uses a 768 byte payload for stability
• A and MX records can be used as well, but with more limitations. These cannot store all types of data.

Tunneling data

In order to tunnel data up, so from your client on the protected network to the external server, your machine will encode the data using Base32 (due to the limited character set allowed in the queries). It will then launch a DNS request as follows:

Detection of DNS tunneling

The best way of detecting DNS tunneling is by performing statistical anomaly detection on the network. Some characteristics of a DNS tunnel include:

• High volume of DNS requests from internal clients where little usually take place;
• Significant difference in the format of these lookups as compared to regular ones. Each of the requests is usually long and contains higher entropy than usual. Hostnames are usually formatted using a language. All languages contain redundancy. Base64 or Base3 "looks" different;
• The total amount of data transferred over port 53 is much higher than usual. This is much easier to detect on the internal network than it is on the perimeter (from main DNS relays to outside)

Software which has functionality to detect this is unfortunately in scarce supply. As an alternative, some opensource snort signatures are listed below that could assist. These signatures can easily be translated into similar languages.

Please note that these signatures have not been very well tested. They are not meant to "install and forget", as they may trigger false positives. I would advise a phased approach in implementing them: install them and have them trigger to a severity which is not handled realtime. After two weeks, they can be evaluated.

Known false positives are mail servers that do a high amount of lookups to ascertain SPF records, when receiving particularly high amounts of e-mail from a certain e-mail domain.

This signature is developed for the Snort IDS and triggers on 20 requests for TXT records within a 60 second timeframe. This is typical for DNS tunneling tools in that they require repeated requests to maintain the tunnel. Do note that these can be defeated by lowering the throughput of the tunnel (Last update: May 27th, 2006).

alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"Potential DNS Tunneling"; content:"|01 00|"; offset:2; within
:4; content:"|00 00 10 00 01|"; offset:12; within:255; classtype:bad-unknown; threshold: type threshold, track
by_dst, count 20, seconds 60;  sid:1000001;)

The following signature triggers on use of the NSTX tool. (Last update: May 27th, 2006)

alert udp $EXTERNAL_NET any -> $HOME_NET 53 (msg:"Potential NSTX DNS Tunneling"; content:"|01 00|"; offset:2; w
ithin:4; content:"cT"; offset:12; depth:3; content:"|00 10 00 01|"; within:255; classtype:bad-unknown; sid:1000
2;)

Where improvement is required, these signatures will be tuned regularly. Check back in to see whether updates have been made.

Countermeasures against DNS tunneling

• If you are running a for-a-fee access point, consider having your DNSserver answer all queries with a local IP address until payment has been completed. Only afterwards should a client be able to perform DNS lookups that your server resolves to the internet.
  
  Many organizations do this currently by having HTTP requests rewritten to a local web server on which payment is due. This however still allows the client to resolve external domains, and as such, does not alleviate the covert channel. A potential solution is to set up a BIND server which has a local entry for all TLD's: get lists here and here. Set up a wildcard entry for each of these domains that points to your local webserver that processes payments. Requests to any other domains or zones should not be handled recursively.
  
  Upon payment, you could provide your user with a WEP or WPA key that they can use to connect to a secondary network; or automate this through software. Users on this secondary network should have an IP address within a different range. This range can then be used to add a second "view" to BIND, allowing full recursive lookups.
  
  
• Corporate networks could consider performing DNS resolution on the proxies. By giving your users access to only the internal DNS network, so they can only resolve internal hosts, they are not able to tunnel any traffic to the internet through queries. Next, have them connect directly to the proxy server by using configured proxy settings in their browser. When browsing, they will connect to the proxy and provide the hostname to this device. The proxy server will then do DNS resolution and make the necessary connection. This is one of the few effective means of preventing DNS tunneling. In general, users do not require direct DNS resolution of the internet for most other purposes.
• You could develop a reactive or responsive ability by implementing an intrusion detection or intrusion prevention system. Many systems now have signatures that attempt to detect this traffic:
  (i) The Cisco Secure IDS system has a signature that triggers on a large number of TXT DNS requests;
  (ii) A community rule is available for Snort that triggers on specific traffic generated by NSTX. This rule however did not work in my test setup. Please also review the rule above if you have similar issues.
  
  

Articles and discussions on DNS tunneling

Links to DNS tunneling tools and services

Reference works

Books that contain information on DNS Tunneling