[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:
- 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:
[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:
- 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
[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.
- 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.
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