dns tunneling slides with notes

7/17/2019 DNS Tunneling Slides With Notes

http://slidepdf.com/reader/full/dns-tunneling-slides-with-notes 1/29



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, he’s going to look at you like he’s crazy.

The existing approaches that we’ve found to block tunnels are mostly theoretical or requirebuilding 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 it’s possible to do

and if so, how would someone go about implementing such a system



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 weren’t 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 acombination of HyperVisors, including VMWare, VirtualBox and an instance on Amazon’s

Elastic Compute Cloud.



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 Amazon’s Cloud. We used EC2 to host the server, since we

didn’t 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



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 aren’t 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 it’s related to DNS tunneling. The reason the tools like to useNULL records, is because the record has no defined structure, you don’t 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 don’t 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.



Our next strategy was to try and identify DNS tunnel packets based on the packet signature.

It’s not an easy task to do. It would be like separating good HTTP traffic from bad HTTP

traffic. There’s 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 didn’t want to respond to a real DNS query. They also didn’t want to tunnel traffic for

an unauthorized client. The first few versions of the tunneling software didn’t 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.



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.



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

bits set



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 rulesets. The rule is telling snort to generate an alert, it’s 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 shouldn’t match this pattern. We can’t state that

definitively, but in our testing we didn’t come encounter any false positives



So this is what the log file looks like. When Snort detects tunneling traffic matching the

rules, it logs the alerts. It’s 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



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 anHTTP request for, the packet is sent to the registration server. You can do DNS redirection

where you are returned the registration server’s 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.



So we had 3 techniques for identifying and blocking DNS tunneling. We’ll 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 createdsome 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



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 TUNShad the lowest throughput and highest latency. So the best we could do was slow it down a

little more. That’s what the asterisk for the blocking TUNS shows. We weren’t able to block

it but we made it even more unusable



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.

There’s 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 weren’t 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.



So, in conclusion, we’ve 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.

dns tunneling slides with notes

Documents