[Maarten Van Horenbeeck] [Information Security] [Resources]

DNS tunneling

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 [back]

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 [back]

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:

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:

[data].domainname.tld

What happens then, is that your client will request this to the local DNS server. It will contact .tld to obtain the nameservers for "domainname.tld", after which it connects to that nameserver with this request. The nameserver at "domainname.tld" is ofcourse under your control and instead of interpreting it as a regular query, it will store the data in the form it sees fit. The response it gives in the end, will be the downstream data to be tunneled back to you. This data is encoded using Base64, as the characters allowed in the data part of TXT records (the response) is much more liberal. This way it becomes possible for you to set up a session through DNS - you send data up in the form of queries, and get data back in the form of responses.

One more example, in this case we would like to tunnel out the command "The flowers are growing in November" and you receive the response "As they were growing in May".

DNS request:
k2qa6goccrreni9ej3826plc0pp4nnte9jre6g4de38sknpe5br4mi9e.domainname.tld

DNS response:
QXMgdGhleSB3ZXJlIGdyb3dpbmcgaW4gTWF5

Using this same mechanism, not only can innocent messages be tunneled, but a complete IP tunnel can be set up, or large files can be transferred. It just consists of converting the activity you want to complete into this format, afterwards re-interpreting them at the receiving end.
.

Detection of DNS tunneling [back]

The best way of detecting DNS tunneling is by performing statistical anomaly detection on the network. Some characteristics of a DNS tunnel include:
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 [back]

DNS Tunneling could actually be one of the best covert channels ever designed. In general, it proves quite challenging to stop this traffic, as there is no specific indication that it concerns IP over DNS tunneling. There are however a number of ways to mitigate the threat to a certain degree.

One solution which is sometimes considered is to deny all queries for TXT records. The impact of this will in most cases be limited, although certain functionality (such as SPF) may break. In general, only your incoming mailserver will need to perform these lookups: taken a general split-DNS service on multiple servers, it should be feasible to work around this issue. There are precious little reasons why the average internal client should be able to perform lookups for TXT records. This approach is however fairly naïve as tunneling will still be possible through other record types. You will not be able to disable these others, such as CNAME, due to the heavy production impact.


Articles and discussions on DNS tunneling [back]

Slashdot in 2000 on DNS tunneling
Information Security Magazine, May 2001
Compass Security releases DNS tunneling test tool
Discussion on the Firewall Wizards mailing list
Blog posting on the statistical detection of DNS tunneling (i)
Blog posting on the statistical detection of DNS tunneling (ii)
Tutorial on how to use OzyManDNS
PPP over SSH over DNS Howto
NSTX howto

Links to DNS tunneling tools and services

Dan Kaminsky's OzyManDNS
Tadeusz Pietraszek's DNScat
iodine, an IPv4-over-DNS tunnel
DeNiSe: an example of DNS tunneling using Python

DNSTunnel offers a DNS NS record to any IP address
Description of getting onto the Tor network using DNS tunneling

Reference works

RFC 1035 - Domain Names - Implementation and Specification
RFC 4034 - Resource records for the DNS Security Extensions
A guide to understanding covert channel analysis of trusted systems [Light Pink Book]

Books that contain information on DNS Tunneling

Hacker's Challenge 2 contains one case study on a DNS tunneling exercise