DNS and ICMP Tunneling

Getting around protections with tunnels is very easy, but there are things you can do to detect and prevent them.  A few are outlined at the bottom of this post.

DNS Tunneling:
First you need to set up DNS.  Create an A record for the tunnel server, e.g. ‘lab.yourdomain.com’.  Then create an NS record, e.g. ‘tunnel.yourdomain.com’ and point to the A record as its nameserver.

dig -t NS yourdomain.com

;; ANSWER SECTION:
yourdomain.com. 233 IN NS ns1.somehost.net.

dig @ns1.somehost.net -t NS tunnel.yourdomain.com

;; AUTHORITY SECTION:
tunnel.yourdomain.com. 300 IN NS lab.yourdomain.com.

Next install iodine on the server and run it.

apt-get install iodine
iodined -f -c -P yourpassword 10.0.0.1 tunnel.yourdomain.com

Then install iodine on the client and run it.

apt-get install iodine
sudo iodine -f -P yourpassword tunnel.yourdomain.com

SSH to the tunnel IP (10.0.0.1) and create a tunnel.

ssh -D 52513 root@10.0.0.1

Set your SOCKS proxy to localhost and port 52513.

ICMP tunneling:
Download ‘hans’ on the client and server.
https://sourceforge.net/projects/hanstunnel/files/source/
Unzip cd in and run make.

Server:

./hans -s 10.0.1.1 -p yourpassword

Client:

./hans -c yourhost.com -p yourpassword

SSH to the tunnel IP (10.0.1.1) and create a tunnel.

ssh -D 44251 root@10.0.1.1

Set your SOCKS proxy to localhost and port 44251.

You could route all traffic over either tunnel, but it’s super slow and unencrypted.

Detection:
For ICMP, look for large amounts of bytes over durations.  With bro, you can see this in the conn.log as a single connection.

cat conn.log | bro-cut id.orig_h id.resp_h proto duration orig_bytes resp_bytes | grep -F "my.bad.ip" | grep icmp | grep -v -
my.host.ip tunnel.server.ip icmp 82.146061 383775 5138402

For top durations:
zcat conn.* | bro-cut uid id.orig_h id.resp_h proto duration | grep icmp | sort -nr -k5 | head -n 10

DNS is more complicated.  You’d need to look for domain queries with a lot of subdomains from a single source IP.  Or source IPs that make an excessive amount of queries over a short window.

Here’s a bro script that works. https://github.com/mattclemons/bro/blob/master/dns-tunneling.bro

1507263236.546116 C9Gvpu4Y30dwE9C4wf tunnel.server.ip 53 my.host.ip 54282 - - - udp DNS::Tunneling Payload length: 1149 tunnel.server.ip my.host.ip 54282 - bro Notice::ACTION_LOG 300.000000 F - - - - -

If you check the dns.log you’ll see some crazy subdomains like this.

1507263456.486470 CGSzOv20h4GdpDTs3c my.host.ip 45477 tunnel.server.ip 53 udp 58627 0.048001 rbhadn2afn49fn49fn49fn49fn49fn49fn49fn49fn49fn49fn49fn49fn49fn.49fn49fn49fn49fn49fn49fn49fn49fn49fn49fn49fn49fn49fn49fn4.9fn49fn49fn49fn49fn49fn49fn49fn49fn49fn49fn49fn49fn49fn49.fn49fn49fn49fn49fn49fn49fn49fn49fn49fn49fn49fn49fn49f.lab.mydomain.com 1 C_INTERNET 10 NULL 0 NOERROR T F T F 0 <unknown type=10> 0.000000 F

Prevention:
To prevent DNS and ICMP tunneling, there are several methods.  You could block outbound UDP 53 except for authorized nameservers and then rate limit it to the point that tunneling is severely painful.  Tunneling could still occur and data could be exfilled although slowly.

A better way would be to implement a proxy solution for all web traffic.  Then you could block DNS completely at the edge and clients could use their local DNS to resolve what they need internally.  Then the only system(s) that can resolve externally would be the proxy(s).  For ICMP, you can block it outbound for specific subnets.  I use ICMP every day and I think it still needs to be allowed in certain parts of the network for troubleshooting purposes, but not for guest or user subnets.

Almost all of the next gen firewalls have application blocking policies for this, but they’re spotty.  Ever used NBAR?  I remember trying to block Bittorrent with NBAR and having to upgrade sigs constantly.  They couldn’t come out fast enough.  There are cheaper and more effective ways to lock down the network.