21

I've just seen a talk about tunnelling TCP/IP over DNS requests, because port 53 UDP is usually open and unfiltered. What techniques exist to detect and block such tunnels, and have you ever seen that tunnelling on a real network?

The technique uses base32-encoded requests for TXT records which result in base64-encoded responses in the answer. Banning TXT records outright seems a bit harsh, so perhaps anomalous traffic needs to be searched for. I don't know of any tool that specifically handles this case.

AviD
  • 72,138
  • 22
  • 136
  • 218
  • Please specify your question. On what type of network are you looking for this? What type of limitations have it already? Or is this only theoretical? – KilledKenny Apr 20 '11 at 21:29
  • This is a question about what _you_ have seen on _your_ network. I'm interested to know whether this is done in the real world, whether it's perceived as a problem, and how you react. –  Apr 22 '11 at 09:40
  • Ok so you are more interested in information leaking then the free wireless issue i brought up – KilledKenny Apr 22 '11 at 09:58
  • @WZeberaFFS yeah, imagine that a company has a web content filter in place, but allows unfettered DNS access. –  Apr 22 '11 at 10:38

5 Answers5

13

The most systematic answer is to implement split horizon DNS in your infrastructure, such that only internal addresses resolve; clients then must use a proxy server to connect out to the internet, and the proxy server resolves external DNS for them. This is particularly effective if your core network doesn't have a default route, so that packets destined outside your network are dropped.

The downside, obviously, is that retrofitting those controls into a running environment is likely to be an expensive and complex proposition...

caelyx
  • 310
  • 1
  • 5
7

Can't recall the name, but I know there's been at least one commercial product which used port 53 to phone home (not a full TCP/IP tunnel though).

I would seriously question the (f)utility of trying to prevent this kind of thing by attempting to block specific outbound traffic though. Firewalls were never intended to filter outbound traffic, tunnels, covert channels etc in this way. As long as communication is allowed at all, people will find a way - HTTP(s) is the obvious means, but people have even built proof-of-concept full TCP/IP stacks using email as the transport.

Maybe you can detect this kind of thing by monitoring for anomalous traffic, but that seems like a secondary concern to me. It's probably a better use of resources to directly address the primary issue which triggers the concern - e.g. malware or data leakage.

frankodwyer
  • 1,907
  • 12
  • 13
6

I realize this is an old question, but I just ran across it and thought I'd post my perspective for sake of the next guy.

The best answer is caelyx's response: architect the network so only the proxy can resolve external DNS hostnames. As he points out, retrofitting this into a production environment is difficult.

A compromise is to block all udp/53 outbound unless it originates from your internal DNS server and/or allow only to your external DNS server. This mitigates applications that simply throw data over udp/53 to an arbitrary external server. It does not reduce the risk of DNS tunneling, since your internal and external DNS servers will happily forward any RFC-compliant traffic.

I research this in 2009 and posted my findings at armatum.com. The first post was to characterize "routine" DNS traffic and compare with typical DNS tunnel implementations. The second phase was to build an algorithm to detect the unusual behavior; it started as a clustering algorithm and ended up as a simple visualization of key characteristics:

Visualization of typical DNS traffic

(click through and check out the video, see the app working in real-time) Those key characteristics ended up focusing on length of hostname queried, type of request and count of unique characters in the hostname requested. Most RFC-compliant DNS tunnel implementations maximize these values to maximize upstream bandwidth, resulting in significantly increased values over typical DNS traffic.

As I noted in the update to the second post, if I were to re-do that work today I'd include the research that's been published since and also use count of subdomains per domain as a key characteristic. That's a clever technique.

I built this as a tool I wanted at my enterprise network perimeter, based on my years serving in that role. As far as I know there are no enterprise-class industry applications/hardware that provide this depth of insight. The most common are "application level firewalls" that ensure RFC compliance --- something you can (usually) enforce with the simpler split DNS network architecture described above.

Of note, I have seen TXT response records banned outright at a large (450k hosts) enterprise perimeter with no significant reduction in utility. Your mail gateways need TXT records for SPF, but the other common uses rarely have a place in the enterprise. I don't advocate this approach, because it "breaks the internet" -- but in dire circumstances I cannot argue with it's practicality.

And finally, yes -- I've seen this technique used live, though it is unusual. (referring to enterprises, not pay-per-use public access points)

Community
  • 1
J.J.
  • 161
  • 1
  • 2
3

I have seen this happen.

It is mainly used by cheap geeks to avoid having to pay for public wireless. What they do is that they set up a server at home ether a fake DNS or just a random VPN at home. And when they are out and about they might have to connect to the internet so they look for any open wireless and connect and if it wants you to pay then you try to connect to your fake DNS server and tada, free internet :). I have seen this done in the "real world".

This is also doable with ICMP or more known as PING that you create a ping tunnel between the client and home server and send the data that way.

But if you see this on a "open" network like an office LAN then there's probably some type of malware or similar that doesn't want you to mess with it. If this is the case then I suggest that you take a look at it.

bstpierre
  • 4,868
  • 1
  • 21
  • 34
KilledKenny
  • 1,662
  • 4
  • 19
  • 28
1

Palo Alto Networks next generation firewall is used regularly to limit the use of a port to a specific application. DNS is a supported application. Two rules are needed in this specific order: (1) Application=DNS, Port=53, Allow (2) Application=any, Port=53, Deny

The only way you could be sure if your specific tunneling approach would be denied would be to test it.

New tunneling methods are developed all the time and there is surely no guarantee that a new method won't require some work on Palo Alto's part. This is evidenced by the recent TCP split handshake evasion method which Palo Alto addressed this week.

I am not aware of any other firewall that enables you to implement a positive enforcement model at the application level at this time as I have described above.

Full disclosure: I provide network security services including reselling Palo Alto Networks, Check Point, and Juniper firewalls.

Bill Frank
  • 509
  • 2
  • 5
  • 1
    That terminology always bugged me... they dont limit a port to an *application*, but they may limit it to a specific *protocol*. Might not be a huge difference for DNS (though there might be), but e.g. HTTP - is that *really* considered a single application? – AviD Apr 21 '11 at 00:39
  • 2
    @Bill - where you have a connection with a product or organisation, please state your affiliation, otherwise this looks a little like spam. See http://security.stackexchange.com/faq : May I promote products or websites I am affiliated with here?, near the bottom – Rory Alsop Apr 21 '11 at 11:37
  • @Rory - I amended my answer in two ways. I made it more specific and disclosed my relationship with Palo Alto Networks (as well as Check Point and Juniper). – Bill Frank Apr 21 '11 at 23:13
  • @AviD Actually they do identify applications within protocols. HTTP is surely not considered one application. If it were, there would be little added value. – Bill Frank Apr 21 '11 at 23:20
  • Really? How do they detect what application is handling the network connection at the endpoint? – AviD Apr 21 '11 at 23:33
  • @AviD guessing here, but I'd say a combination of stateful tracking and content inspection. –  Apr 22 '11 at 09:42
  • @Graham, that's still examining the *protocol*, unless a certain application has a distinct signature it can't really say anything about the endpoint application. – AviD Apr 22 '11 at 12:08
  • @AviD but application-layer firewalls don't care about the endpoint application, they care about the application traffic on the network. For example, if I'm happy with most HTTP but don't want XMPP over HTTP because I don't want people using Jabber, then I don't care _what_ Jabber client I don't let people use. –  Apr 22 '11 at 12:29
  • @Graham, ah see, that's still the protocol - you're blocking XMPP, not a specific Jabber application. As I understand it, they're referring to the *application layer*, a.k.a layer 7 in OSI model... That's not really the same thing... – AviD Apr 22 '11 at 13:12
  • @AviD: agreed. The word "application" means different things depending on whether you're selling software products or filtering network traffic. Related: if I asked for a "tool" to open the case on a PC, I wouldn't expect someone to give me a copy of Visual Studio ;-) –  Apr 22 '11 at 13:22
  • Some applications can be detected over the network as well. Browsers are a good example (they send that user agent thing), as are most servers (SSH servers, for example, will say "SSH-2.0-OpenSSH_4.3". RHEL even patches that to say that it's RedHat, or at least it did). Tracking that at the firewall level is left to deep magic :) – Bill Weiss Apr 23 '11 at 06:21
  • 1
    Note that DNS tunneling is actually using valid DNS requests - `TXT` records, most commonly (so it's not "non-DNS traffic, just on `53/udp`"). Thus, the rules you specify would likely allow this. – Piskvor left the building Oct 26 '11 at 07:51
  • 1
    IMO, speaking of applications at this layer only makes sense for "desktop firewalls", i.e., cases where you can actually associate a socket with an application. Everything else is educated guesswork. – pepe Oct 26 '11 at 09:25