IPoverDNS

Ausgangslage

(todo)

Motivation

(todo)

Anleitung

DNS Server Setup

(todo: much more explanation)

Setting up Iodine requires control over a domain, for which you have to register the following dns records.

You have to run your own server with a public IP that will function as nameserver for your domain “mydomain.com” managed by iodine.

Assume you have a domain called “mydomain.com” and it’s IP is “1.2.3.4”. You have to register a subdomain, e.g. “tunnel.mydomain.com”. Also, you need another subdomain “ns.mydomain.com” for your nameserver. For the tunnel subdomain, Iodine on your own server (1.2.3.4) will pretend to be the authoritative nameserver.

So you need to create an A record for the sub-domain (tunnel.mydomain.com) that point to IP of the private server.

dns IN A 1.2.3.4

And you need a NS recod that makes the dns sub-domain the authoritative name server for the tunnel sub domain.

tunnel IN NS dns.domain.tld.

The result could look like this:

Iodine Server Setup

install and start iodine

$ sudo apt install iodine

$ sudo iodined -c -f 10.0.0.1 -P 123456 tunnel.l0m.de

Test server

http://code.kryo.se/iodine/check-it/

Iodine Client Setup

install and start iodine

$ sudo apt install iodine

$ sudo iodine -f -P 123456 tunnel.l0m.de

Test tunnel

$ ping 10.0.0.1

Set up routes to go through the tunnel

Find out dns server: $ nmcli dev show | grep DNS

Find out gateway: $ netstat -rn|egrep "^0.0.0.0"

Find out your tunnel interface: ifconfig -> look for something like dns0 that wasn’t there before

$ route del default $ route add default dns0

and if dns server and gateway don’t have the the same IP adress anyway:

route add -host [DNS server IP] gw [gateway IP]

Put a ssh tunnel through the dns tunnel for encryption

Put a ssh tunnel through the dns tunnel to encrypt

$ ssh -D 5000 -N root@10.0.0.1

$ curl --socks5-hostname 127.0.0.1:5000 http://httpbin.org/ip

$ google-chrome --proxy-server="socks5://127.0.0.1:5000" http://httpbin.org/ip

Deactivating Iodine

stop iodine client on client and server (just by pressing ctrl+c)

Set routes back to ‘normal’

$ route del default

$ route add default [gateway ip]

or just restart your networking manually by using the network manager or restart the device entirely.

Metrics

Of course, tunneling IP over DNS does not allow for a very impressive bandwith.

Methods to prevent dns tunneling

Network architecture

The first method to prevent dns tunneling would be to block dns requests for arbitrary servers, so that the client that is not logged in yet can not resolve any dns request.

Tunneling Detection

Furthermore, tunneling of IP traffic over DNS results in unusual DNS traffic that can be spotted.

Implementations tend to use DNS types that can have a lot of bytes per packet, e.g. the experimental "NULL" type. We see those only when we use iodine, in regular DNS traffic this type does not appear at all.

Naturally, tunneld IP traffic causes a lot more DNS packets to be sent than normal use of the protocol. Also, because as much data as possible is crammed into every single packet, the packets get longer. See the following graphs for a comparison between normal DNS load (blue) and DNS metrics while using iodine for tunneling (green). We captured 9 times 30s of traffic and counted the number of DNS packets and the average length. As is clearly visible, the packets tend to get longer and there are decidedly more of them when tunneling is used.

Another method for detecting DNS tunneling is to analyze the fully qualified domain names (FQNs) that are resolved. Usually, domain names have somewhat meaningfull names like yourshop24.com or mywebsite.net. The fully qualified domain names that are resolved for the tunneling are very long and very arbitrary, containing a combination of many letters and numbers.

We counted the number of resolved FQNs per 30s, the average number of unique characters in the FQNs and also the length of the FQNs. The differences between tunneling and "innocent" DNS traffic are obvious. It is therefore definitely possible to use some kind of analyzing software to detect DNS tunneling as we did with a simple python script.

Problems with Captive Portals

Technical problems

It doesn't work with https, because it's basically a man in the middle attack. When people try to access https websites, it doesn't work at all.

It causes some strange problems (https://forum.piratebox.cc/read.php?9,8879)

forged DNS answers don't work with DNSSEC

fundamental problems

man in the middle