1

10

11

12

13

14

As you saw in the previous slide, there are existing ways to identify DNS tunnels, however
they mostly make use of advanced statistical analysis techniques. If you ask a network
administrator to setup a neural network or perform n-gram frequency analysis of DNS
traffic, hes going to look at you like hes crazy.

The existing approaches that weve found to block tunnels are mostly theoretical or require
building advanced analytical systems that are beyond the capabilities of a regular IT tech.
So our goal was to come up with a way of identifying and blocking DNS tunnels using
existing open source tools that are freely available. We wanted to see if its possible to do
and if so, how would someone go about implementing such a system

15

This is just an overview of some of the software and services we used. We used the latest
Ubuntu release 11.10 Oneric Ocelot as the operating system for all our servers and clients.
Bind9 was used as our DNS server. We stared off with Bind 9.8.0 but we had to upgrade to
a development release of 9.9.0 since some of the features we needed werent available in
the production release. We used PFSense as our Firewall. PacketFence as our Network
Access Control server, Snort for intrusion detection, the virtual machines were hosted in a
combination of HyperVisors, including VMWare, VirtualBox and an instance on Amazons
Elastic Compute Cloud.

16

This is what our network topology looked like. The dns tunneling client was running on a
Ubuntu workstation, isolated on the network behind the PacketFence Server. All DNS
packets were sent to our Bind server. The virtual switch forwarded a copy of all traffic that
went through the router to a server running Snort. PFSense performed packet inspection
and traffic shaping.

The DNS tunnel server ran on Amazons Cloud. We used EC2 to host the server, since we
didnt want in to the same network as the client. To more accurately simulate a real-world
scenario we wanted to deploy it on the Internet somewhere and Amazon lets your run low
powered EC2 instances for free. They give you a public IP with port forwarding so we could
run a DNS tunneling server on there. The server would also forward packets out on the
Internet for the client and send the responses back to the client as DNS records.

The first half of our time was spent deploying and testing the different DNS tools,
performing lots of packets captures and examining logs and traffic to see how exactly all
the different tools operated and to look for ways we can identify the traffic they generated.
Once we had a handle on that, we began to implement different strategies and test them
to see what worked and what didn't

17

Okay, so first we looked for some easy ways. Many of the tools, like iodine make use of DNS
NULL records to send and receive data.
Normally you have DNS records like A, quad A, NS, MX, TXT, CNAME etc. NULL records are
actually defined in the RFC as an experimental data type, but they arent actually used in
the real world for anything. So anytime you see a query or response using a NULL record,
you can be pretty certain its related to DNS tunneling. The reason the tools like to use
NULL records, is because the record has no defined structure, you dont have to use any
encoding. Domain names can only have letters, numbers and a hyphen, so to send traffic
back and forth you have to encode it using Base32 or Base64. This adds overhead and
reduces your usable bandwidth, but for NULL records you dont have to encode the data,
so you can increase your bandwidth. Fortunately for us, we were able to find a way to block
NULL records in bind. This just slows the tools down a little though, since most of them will
switch to a different record type like TXT or CNAME. We could block TXT records too,
however there are legitimate uses for a TXT record if you run a mail server, so we decided
not to do that.

18

Our next strategy was to try and identify DNS tunnel packets based on the packet signature.
Its not an easy task to do. It would be like separating good HTTP traffic from bad HTTP
traffic. Theres no outright way to classify traffic. However, you can look at traffic that you
know is malicious and try to identify patterns from it. So we tried to do something similar.
We examined traffic generated by all the various tools and tried to look at patterns and
with some of the tools we got lucky.
So this diagram shows you the structure of a DNS packet and you have a header with some
fields for flags and codes. What we noticed was that some of the tools always set certain
flags and bits in the header and elsewhere in the packet. It was partly done so that the DNS
tunneling server could recognize and identify the traffic as being legitimate tunnel traffic.
They didnt want to respond to a real DNS query. They also didnt want to tunnel traffic for
an unauthorized client. The first few versions of the tunneling software didnt have any
authentication features. So if you found a machine running the tunneling server software
you can just start using it. So to prevent this from happening, they added some
mechanisms for using password authentication and other identifying characteristics, which
we could take advantage of too, to recognize those packets.

19

So here you see a request from an Iodine client. The highlighted portion shows some of
signature bits that are present in every iodine query packet.

20

Similarly, the response from the Iodine server in most cases has some unique identifying
bits set

21

So based on those signatures, we created some snort rules.

Now, this probably looks like a bunch of gibberish, but believe me it works. We have proof
on the next slide.
Snort as I mentioned before is an Intrusion detection system. It analyzes network traffic
and looks for traffic patterns that matches predefined rule sets and carries out certain
actions if it finds a match. So based on the identifying data we found, we created some rule
sets. The rule is telling snort to generate an alert, its should look at udp traffic going from
any source on any port to any destination on port 53 and then look for the traffic patterns
we specify. The second rule is pretty similar. As far as we could tell, there should be no false
positives, since legitimate traffic shouldnt match this pattern. We cant state that
definitively, but in our testing we didnt come encounter any false positives

22

So this is what the log file looks like. When Snort detects tunneling traffic matching the
rules, it logs the alerts. Its may not seem very useful to just log an alert, but we did that
just as a proof of concept. In a real scenario you would have Snort drop the matching traffic
or tie into another system to take a different action

23

Our next approach was to block the use of DNS tunneling when captive portals are used.
Ashwathi talked about how you can create a tunnel to get free Internet access if you are at
an airport or a coffee shop where you have be authenticated before you can get Internet
access. Normally, what happens is that you open your browser and no matter what address
you type in, google.ca, or ucalgary.ca you are redirected to a login page. Usually there are 3
ways that is done. You do an IP redirection, so no matter what webserver IP you send an
HTTP request for, the packet is sent to the registration server. You can do DNS redirection
where you are returned the registration servers IP, regardless of the domain name queried
or you can do URL rewriting with a proxy server and all requests are sent to the registration
page. If you use DNS redirection, then you are fine, if you use any of the other two
mechanisms and you allow DNS requests to be resolved externally (which many networks
do), then someone can successfully create a dns tunnel to get Internet access.

So to prevent this we deployed an open source Network Access Control server called
PacketFence. It uses the DNS redirection technique called DNS Blackholing. So all DNS
responses are resolved internally with the IP address of the NAC server and no requests are
sent externally until you are authenticated. So this prevents any tunnels from beiing
created.

24

So we had 3 techniques for identifying and blocking DNS tunneling. Well see in the
evaluation slide that this helps block most of the tools but not all of them. So our last
strategy was to use traffic shaping to limit the amount of bandwidth a single client can
consume over UDP port 53.

We use PFSense as our firewall which has some traffic shaping capability. So we created
some limiters which limited upstream and downstream DNS traffic to 100 Kilobits / sec per
client. We choose the number rather arbitrarily. 100 Kilobits is large enough that the
latency for legitimate DNS traffic is not increased by much so the delay is barely noticeable,
but at the same time trying to surf the Internet at that speed should be painfully slow.
There are cases where it still might be useful, if you are using an SSH session or if you are
using the tunnel as a covert channel for data exfiltration, you might have small amounts of
data to send, or you might not care how long it takes. So the bandwidth limit can be
adjusted and you can also set bandwidth caps per hour or day and make the channel even
slower if you hit a certain cap

25

So this slides shows the results of our design is successfully identifying and blocking dns
tunneling. Out of the 4 tools we evaluated against our setup we were successful in stopping
3 of them. TUNS as we mentioned before was designed by researchers at a French
University where they wanted to make a tool designed especially to evade detection. They
do this by only using cname records for dns responses which greatly limits their bandwidth.
In a study done where they compare they most popular DNS tools, they found that TUNS
had the lowest throughput and highest latency. So the best we could do was slow it down a
little more. Thats what the asterisk for the blocking TUNS shows. We werent able to block
it but we made it even more unusable

26

Some future work for our project.

We ran snort it passive mode, where it just receives a copy of the traffic and generates
alerts when a match is found, but it could be run in inline mode where it would sit between
the router and the firewall and actually drop packets if there was a match. It just requires
more configuration and takes longer to setup.

Theres also a possibility to find some open source tools that will perform traffic analysis to
establish a baseline pattern for a network and then use anomaly detection to find instances
of dns tunneling being used. We werent able to find anything which did this exactly, but we
are fairly sure it would be possible by combining multiple different components.
Lastly, just try to spend more time analyzing Tuns and come up with a way to block it so
that we can claim that we were successful at blocking all the popular tools.

27

So, in conclusion, weve shown that DNS tunneling is a real security threat that needs to be
addressed.
There are many cases that DNS tunneling is allowed or goes unnoticed mainly because it is
too difficult to or too expensive to implement ways to block it.
So to solve that problem we have designed a system using freely available open source
software that is effective at both identifying and blocking DNS tunneling.

28

29