Tunneling traffic through DNS, a.k.a free internet in cafes/airports(dnstunnel.de)
dnstunnel.de
Tunneling traffic through DNS, a.k.a free internet in cafes/airports
http://www.dnstunnel.de/
27 comments
This is also possible by tunneling through ICMP: http://www.cs.uit.no/~daniels/PingTunnel/
Generally though wireless hotspots allow DNS traffic out (the DNS server isn't filtered) but not ICMP. In fact if anything is filtered it tends to be ICMP. I'm not really aware of any situations where ICMP tunnelling is useful. Anyone know of any?
I use <a href=code.kryo.se/iodine>iodine</a> as a wrapper for this, and I use it very frequently (as I fly internationally at least once every few weeks). It usually sits as a service on my home server. So far the only airport where I didn't make it to work was in Miami (where I connected though a socks tunnel though my iphone 3g anyways).
dns tunelling is slow, but handy for console/screen situations. I usually use it to download the newspaper before getting into the plane (a bunch of wgets) and refresh the rss feeds on newsbeuter.
dns tunelling is slow, but handy for console/screen situations. I usually use it to download the newspaper before getting into the plane (a bunch of wgets) and refresh the rss feeds on newsbeuter.
Use Kismac to collect MAC addresses with significant packets in/out, clone a MAC, ssh -D9091 to my remote server, tunnel everything through my local SOCKS5 port 9091. Works well enough for me.
Just thinking off the top of my head, but wouldn't cloning the MAC cause conflicts with the existing MAC on the network?
I've done something similar with cloning my iPhone MAC to get free WiFi access on my laptop using the free AT&T WiFi provided to iPhones.
But if what you're saying actually works, this seems like a dead simple way of getting free access. I already have Kismac installed, so I'll definitely try it. Thanks!
I've done something similar with cloning my iPhone MAC to get free WiFi access on my laptop using the free AT&T WiFi provided to iPhones.
But if what you're saying actually works, this seems like a dead simple way of getting free access. I already have Kismac installed, so I'll definitely try it. Thanks!
I might be wrong, but wouldn't this not help the situation at airports where the AP resolves all DNS requests to a page that is like "pay for service!"?
I was under the impression that in those configurations the AP intercepts all the DNS packets and responds with a fixed IP.
It would be nice to get around port blocking filters though...
I was under the impression that in those configurations the AP intercepts all the DNS packets and responds with a fixed IP.
It would be nice to get around port blocking filters though...
No, I think that's the firewall modifying the headers. I still encounter the portal page when I use a different DNS (although the portal hostname doesn't resolve). I'm not sure if they have even figured out how to do DNS authentication yet.
Not exactly. The general term for the system that captures your first page is "captive portal". The short version is they intercept your first Internet-bound web request and send you a HTTP redirect to their login site. Once you give the portal whatever it needs to authorize you the local firewall is configured to allow your traffic out.
Generally captive portals will leave your DNS alone. They don't really have a lot of choice about this: if they poison your name cache you won't be able to get to your home page. Windows used to (still may) hold on to names for a minimum period regardless of TTL. A fair number of laptops have custom DNS. Combine those two and you can almost always get correct recursive DNS and frequently UDP 53 out.
Generally captive portals will leave your DNS alone. They don't really have a lot of choice about this: if they poison your name cache you won't be able to get to your home page. Windows used to (still may) hold on to names for a minimum period regardless of TTL. A fair number of laptops have custom DNS. Combine those two and you can almost always get correct recursive DNS and frequently UDP 53 out.
Not sure about this. I've tried to use OpenDNS behind a "buy my wireless for 24 hours" at an airport and I still got the page requesting me to buy a page.
Also, even when I pinged servers the IPs were resolving to their "purchase" page. Unfortunately, I didn't have an IP of a site on hand to see if I could request by IP out.
Also, even when I pinged servers the IPs were resolving to their "purchase" page. Unfortunately, I didn't have an IP of a site on hand to see if I could request by IP out.
If the captive portal is rerouting every IP packet (apart from DNS lookups) from an unauthorized MAC to the same central server (so that it can spoof the HTTP redirect to the payment page), this is exactly what you'd expect to see.
It doesn't matter what DNS you're using - the DNS lookups should resolve to correct IPs otherwise your local DNS cache would be poisoned.
It doesn't matter what DNS you're using - the DNS lookups should resolve to correct IPs otherwise your local DNS cache would be poisoned.
[deleted]
Huh? I don't see how you contradicted what I said.
The captive portals I've seen don't tamper with HTTP headers at all, or were you referring to IP headers? As for DNS, I don't think there's any safe way to avoid providing unauthenticated hosts with working DNS.
I may be getting things confused here, but I usually see captive portals do HTTP redirection (looking from a sniffer). That would involve tampering with the headers, correct?
Just IP NAT on the dest address sending you to the portal server. So actually they do tamper with headers, but only IP headers. You don't actually get any traffic to the real site until after your machine has been exempted from the NAT rule (and presumably a drop rule for non-HTTP traffic). There's an open source captive portal called NoCat that you can poke at if you ever want to set one up yourself.
I've set this up and it's pretty slow. Cool hack though. Better off with 3G card or tethering bluetooth on a 2G network. Useful with international travel though where phones get sketchy...
Won't this be too slow to be useful for anything except a proof of concept?
There's some overhead in each packet -- maybe a 4x increase in the number of bytes -- and bouncing between DNS servers will give you an increase in latency -- maybe an extra 500kbps -- but it won't be so bad as to make this unusable. I imagine IP-over-DNS-over-neighbour's-wireless would be much faster than IP-over-phone-line in most cases.
Plenty fast enough for IM.
>> I offer to set up a subdomain for you which delegates all requests (see above) to your fake nameserver.
Isn't that just like publishing-to-all-hackers your "not so secure" server?
Isn't that just like publishing-to-all-hackers your "not so secure" server?
Does anyone know how secure this is? I'm assuming that the traffic is unencrypted, so technically your packets could be intercepted.
pretty much as reliable as IP, and that is not reliable.
put TCP and UDP on top of it and it works fine.
use a VPN and go through that and you're good to go.
put TCP and UDP on top of it and it works fine.
use a VPN and go through that and you're good to go.
It's a great way to bypass firewalls. Wasn't this used in a worm in the 90s?
>...called OzymanDNS ...
Ozymandias? Haha, is that a Watchmen reference? If so, how apropos. "Quis custodiet ipsos custodes?" Not the folks running open hotspots.
Ozymandias? Haha, is that a Watchmen reference? If so, how apropos. "Quis custodiet ipsos custodes?" Not the folks running open hotspots.
I refuse to call myself a hacker until I can test this. Hot!
I have been toying with the idea of having the client part ported to my iPhone, so I can use paywall wifi directly from a mobile device. This would require porting the Perl client code over to C.