Tuesday, July 19, 2011

Do you detect/react to DNS tunnelling?

'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.

network firewalls ids dns tunneling
linkimprove this question
edited Apr 20 at 15:05
AviD♦
9,29811546
asked Apr 20 at 9:26
Graham Lee♦
5,0391136

100% accept rate
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? – WZeberaFFS Apr 20 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. – Graham Lee♦ Apr 22 at 9:40
Ok so you are more interested in information leaking then the free wireless issue i brought up – WZeberaFFS Apr 22 at 9:58
@WZeberaFFS yeah, imagine that a company has a web content filter in place, but allows unfettered DNS access. – Graham Lee♦ Apr 22 at 10:38
feedback
4 Answersactiveoldestvotes
up vote
5
down vote
accepted
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...

linkimprove this answer
answered Apr 21 at 0:35
caelyx
1704
feedback
up vote
4
down vote
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.

linkimprove this answer
answered Apr 20 at 10:23
frankodwyer
1,18311
feedback
up vote
1
down vote
I have seen this happen.

It is mainly used by cheep 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 the might have to connect to the internet so the look for any open wireless and connect and if it wants you to pay then you try to connect to your fake DNS server an tada free internet :). I have seen this done in the "real world"

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

But if you see this on a "open" network like a office lan then theres probably some type of walware or similar that dosen't what you to mess whit it. If this is the case then I suggest that you take a look at it.

linkimprove this answer
answered Apr 20 at 21:27
WZeberaFFS
483114
feedback
up vote
0
down vote
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.

linkimprove this answer
edited Apr 21 at 23:10

answered Apr 21 at 0:22
Bill Frank
2292
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 at 0:39
@Bill - where you have a connection with a product or organisation, please state your affiliation, otherwise this looks a little like spam. See security.stackexchange.com/faq : May I promote products or websites I am affiliated with here?, near the bottom – Rory Alsop♦ Apr 21 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 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 at 23:20
Really? How do they detect what application is handling the network connection at the endpoint?

http://security.stackexchange.com/questions/3206/do-you-detect-react-to-dns-tunnelling