IpOverDns

http://www.trash.net/~beaver/nstx.txt

================================================================================ IP-over-DNS - HOWTO by Beaver trash.net> - Sat May 15 2004 ================================================================================ +

---

+ | Setting up a DNS tunnel via NSTX | +

---

+ Scenario:

---

Alice wants to send a message to Bob. Unfortunately she's not authorized to access the internet. Give up? Alice never gives up. She figures out, she's abled to do DNS-queries to a nameserver called Dave. Dave can be a fixed nameserver in the intranet, or a common friend of Alice and Bob somewhere on the internet. If he's the intranet's nameserver you need to have a registered domain, e.g this-is-bob.net. If you do not have one (like me) you can just set up your own nameserver Dave (Alice then must be allowed to choose Dave as her nameserver!). Alice now want's to tunnel IP over the DNS channel.

There's already an implementation for Linux called "nstx". Unfortunaletly not much documentation around, so perhaps someone will find this usefull.

here's how it works:

---

Alice

---

who is [encoded-ip-packet?.tun.bob.nonexistent]

---

> Dave Dave does not know the address of that one, but he has a zonefile that says? bob.nonexistent knows - so he just asks that one (which is Bob)? Dave

---

who is [encoded-ip-packet?.tun.bob.nonexistent]

---

> Bob Bob

---

well, the answer is [another encoded-ip-packet?

---

> Dave Dave

---

hi there, answer is [another encoded-ip-packet?

---

> Alice

name function system address tunnel address

---

Alice nstx client GNU/Linux 2.4 (internal only) 192.168.0.2 Bob nstx server GNU/Linux 2.4 1.1.1.2 - Dave authoritative NS OpenBSD 3.3 1.1.1.1 192.168.0.1

Note: it should be possible to use Alice and Dave's fuctions on the same host. i haven not tried it; the addresses 1.1.1.x are are just some public IPs kernel 2.4 was used - i'm not sure if things do work on 2.6 (ethertap?)

Setup:

---

If you do not yet have an ethertap device (/dev/tap0) on Alice and Bob you need to build a new kernel. Set these entries in your /usr/src/linux/.config: CONFIG_EXPERIMENTAL=y CONFIG_NETLINK_DEV=y CONFIG_ETHERTAP=y then do a "make oldconfig", compile and install the kernel.

After rebooting, do: bob# mknod /dev/tap0 c 36 16 alice# mknod /dev/tap0 c 36 16

Now you can configure the ethertap device: bob# ifconfig tap0 inet 192.168.0.1 netmask 255.255.255.0 alice# ifconfig tap0 inet 192.168.0.2 netmask 255.255.255.0

Alice and Bob's netroute should look like this: Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 * 255.255.255.0 U 0 0 0 tap0

If you have an authorative nameserver, Bob then you don't need to do the next step. But since i have no domain on my own i set up a nameserver, Dave:

edit your /var/named/etc/named.conf:

---

acl clients { any; // answer queries from anybody (set alice's address here) ::1; };

options { version ""; // remove this to allow version queries listen-on { any; }; allow-recursion { clients; }; };

logging { category lame-servers { null; }; };

// Standard zones zone "." { type hint; file "standard/root.hint"; };

zone "localhost" { type master; file "standard/localhost"; allow-transfer { localhost; }; };

zone "127.in-addr.arpa" { type master; file "standard/loopback"; allow-transfer { localhost; }; };

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" { type master; file "standard/loopback6.arpa"; allow-transfer { localhost; }; };

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" { type master; file "standard/loopback6.int"; allow-transfer { localhost; }; };

// Master zones zone "bob.nonexistent" in { type master; file "master/bob.nonexistent"; };

create a zonefile /var/named/master/bob.nonexistent:

---

bob.nonexistent. 1800 IN SOA ns.bob.nonexistent. mail.bob.nonexistent. ( 100 ;serial secs 300 ;refresh 100 ;retry 6000 ;expire 1800 ;ttl ) bob.nonexistent. 1800 IN NS ns.bob.nonexistent. tun 1800 IN NS ns.bob.nonexistent. ns.bob.nonexistent. 1800 IN A 1.1.1.2 ;Bob's adress

Now, run the nameserver which regulates communication between Alice and Bob: dave# named

Check if everything went well: dave# tail /var/log/messages ..? May 15 15:44:48 router named883?: starting BIND 9.2.2 May 15 15:44:48 router named883?: command channel listening on 127.0.0.1#953 May 15 15:44:48 router named883?: command channel listening on ::1#953

start the server: bob# ./nstxd tun.example.com Opening tun/tap-device… using device tap0 Please configure this device appropriately (IP, routes, etc.) Opening nameserver-socket… listening on 53/UDP

start the client: alice# ./nstxcd bla.de 127.0.0.1 Opening tun/tap-device… using device tap0 Please configure this device appropriately (IP, routes, etc.) Opening nameserver-socket… Using nameserver 127.0.0.1

try to connect: alice# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=156.2 ms

Voila, IP over DNS :)

Speed:

---

Do not expect to much. The official ntsx README file says you won't get more than 4KB even on fast lines. This might not sound that fast, but remember the DNS protocol was never intened for such (ab)use. Fetching mail or doing ssh sessions works quite okay.

Stability:

---

Not that good:

alice# ping 192.168.0.1 PING 192.168.0.1 (192.168.0.1): 56 data bytes 64 bytes from 192.168.0.1: icmp_seq=1 ttl=255 time=130.4 ms 64 bytes from 192.168.0.1: icmp_seq=6 ttl=255 time=176.9 ms 64 bytes from 192.168.0.1: icmp_seq=11 ttl=255 time=206.1 ms

• 192.168.0.1 ping statistics ---

13 packets transmitted, 3 packets received, 76% packet loss round-trip min/avg/max = 130.4/171.1/206.1 ms

Have a look at the packet loss...

Security:

---

First of all, nstx needs root priviledges. A remote DoS vulnerability has been discovered in nstx-1.1-beta3 which was fixed in version nstx-1.1-beta4. In my tests the server could also be simply crashed by the command: $ dig @dave's IP? When you set up a firewall rule to block everyone but alice don't forget that UDP IP addresses can be easily faked!

Detection:

---

Network administrators should get suspicious if there's an unusual increase in DNS traffic, especially with cryptic hostnames all pointing to the same domain. TODO: write a snort rule for this.

References:

---

http://nstx.dereference.de/ http://slashdot.org/articles/00/09/10/2230242.shtml http://www.heise.de/security/artikel/print/43716 (german) http://www.aei.ca/~pmatulis/pub/dns/obsd_dns1.html http://archives.neohapsis.com/archives/bugtraq/2004-03/0275.html