Iodine – tunneling IP over DNS(github.com)
github.com
Iodine – tunneling IP over DNS
https://github.com/yarrick/iodine
16 comments
I like using dns2tcp, it's a lot easier to set up as it works on the transport layer (TCP), not the network layer (IP), and it seems a bit more reliable in my experience.
http://blog.rootshell.be/2007/03/22/dns2tcp-how-to-bypass-fi...
http://www.hsc.fr/ressources/outils/dns2tcp/download/README
http://www.hsc.fr/ressources/outils/dns2tcp/download/
http://blog.rootshell.be/2007/03/22/dns2tcp-how-to-bypass-fi...
http://www.hsc.fr/ressources/outils/dns2tcp/download/README
http://www.hsc.fr/ressources/outils/dns2tcp/download/
Second dns2tcp, although there's also Heyoka http://heyoka.sourceforge.net/, Netcross http://www.primianotucci.com/os/netcross-ip-over-dns-tunneli..., and a rather interesting presentation from Defcon a few years back that showed a more detailed and realistic scenario of using DNS tunneling to punch through a firewall and retrieve database records. I can't locate it right now, but I'll take a look if anyone's interested.
Yes please, I'd be super interested in watching that talk!
Haha, fifteen minutes of Googling later, here you go:
Slides: https://www.defcon.org/images/defcon-16/dc16-presentations/d...
Talk: https://www.youtube.com/watch?v=IkXG14MA3M4
I kept missing the search term. It was "data exfiltration" not "dns tunneling."
I kept missing the search term. It was "data exfiltration" not "dns tunneling."
I've had some good experience with iodine in the past, it's been useful at airports and on trains to bypass captive portals.
It's extremely variable in performance, and can sometimes require a bit of tuning on the client side to work reliably; however, for the most part the auto-detection works well, and will upgrade to raw UDP on port 53 if it is possible.
It's extremely variable in performance, and can sometimes require a bit of tuning on the client side to work reliably; however, for the most part the auto-detection works well, and will upgrade to raw UDP on port 53 if it is possible.
The biggest downside with DNS tunneling is the high latency and low bandwidth - many "responsive" web apps feel like molasses, even long static pages take a surprisingly long time to download, and streaming video/audio becomes almost impossible. Of course it's better than no connectivity as a last-resort; SSH sessions are still quite usable and you can do basic things like email and forums.
An HN user is trying to tunnel IP over Facebook Chat, which is free (as in beer) to access on some mobile plans: https://news.ycombinator.com/item?id=7256477
IP over SMS would be even more useful in the US.
Interesting idea. A few obstacles we'd need to overcome:
- Although SMS messages may be free/bundled for the mobile subscriber, they probably wouldn't be free for the other end (unless you set up the other end yourself, using another mobile device)
- The latency for SMS seems to be high (at least in places where I've lived: UK and China). I'm not sure about in the US. If latency is an issue then maybe somehow increasing the 'MTU', i.e. sending lots of SMS at the same time, would make the throughput OK.
On the other hand, maybe application-level gateways (email-to-SMS, web-to-SMS) would work better, albeit at the cost of flexibility.
- Although SMS messages may be free/bundled for the mobile subscriber, they probably wouldn't be free for the other end (unless you set up the other end yourself, using another mobile device)
- The latency for SMS seems to be high (at least in places where I've lived: UK and China). I'm not sure about in the US. If latency is an issue then maybe somehow increasing the 'MTU', i.e. sending lots of SMS at the same time, would make the throughput OK.
On the other hand, maybe application-level gateways (email-to-SMS, web-to-SMS) would work better, albeit at the cost of flexibility.
[deleted]
You can usw iodine to ger free internet access when your 4G mobile plan runs out of GBs and your ISP blocks you.
Example from sweden, I got around 200kbit after my 4G was supposed to block further internet due to unpaid bill. Hehe.
Example from sweden, I got around 200kbit after my 4G was supposed to block further internet due to unpaid bill. Hehe.
Plug for my dns tunnel not nearly complete as iodine, but it works and is very easy to setup.
https://github.com/callesg/dns-tunnler
https://github.com/callesg/dns-tunnler
How do these avoid captive portals? I thought the thing about captive portals was that they intercepted DNS queries: that's what caused you to get the portal when you typed in "google.com". (i.e., it resolves all DNS entries to the portal's IP until you authenticate) Is this not correct? (I can receive arbitrary DNS, not just send?)
I think most of them use HTTP, not DNS, given that DNS is often previously cached.
Yes in the case of Bluecoat for example, which also is used to setup paywalls sometimes, you hijack all HTTP/HTTPS traffic and redirect it to the bluecoat server. So DNS goes through and when the portal is submit nothing is done to permit DNS traffic in any type of firewall.
But maybe this is an example of a poor paywall.
But maybe this is an example of a poor paywall.
Captive portals typically only capture A records, but custom servers like iodine will return results for any request type if the request starts with 'z'. As long as the captive portal supports unauthed recursing (which 99% of them do), you can still tunnel IP over DNS.
Almost all captive portals simply use MAC addresses for auth, so in practice it's much easier to spoof a host's MAC/IP and piggyback their authed session. IP over DNS is more useful for things like mobile providers where it's harder to spoof hardware identifiers, or networks that allow outbound DNS or have a DNS recursing resolver.
Somebody mentioned something about assuming networks that have deep packet inspection (really, it's almost always just application proxies on common ports) might not allow outbound DNS. Don't ever assume that the person who set up the network was smart, or that they didn't leave a hole for backwards compatibility with some legacy application. Almost all consumer-oriented networks have some hole you can use to get out to the internet.
Almost all captive portals simply use MAC addresses for auth, so in practice it's much easier to spoof a host's MAC/IP and piggyback their authed session. IP over DNS is more useful for things like mobile providers where it's harder to spoof hardware identifiers, or networks that allow outbound DNS or have a DNS recursing resolver.
Somebody mentioned something about assuming networks that have deep packet inspection (really, it's almost always just application proxies on common ports) might not allow outbound DNS. Don't ever assume that the person who set up the network was smart, or that they didn't leave a hole for backwards compatibility with some legacy application. Almost all consumer-oriented networks have some hole you can use to get out to the internet.
HTTP hijacking is much more common than DNS. The reason for this is that hosts cache DNS results, so clients that just joined your network wouldn't get the redirect at all.
And yes, they probably should block excessive DNS traffic, but this is technically sophisticated to implement (now you're getting all stateful to determine what's excessive) and generally unnecessary.
And yes, they probably should block excessive DNS traffic, but this is technically sophisticated to implement (now you're getting all stateful to determine what's excessive) and generally unnecessary.
It doesn't. You are correct. For any unencrypted WiFi but with a paywall / login page for actual usage - if the software is worth anything, DNS is hijacked and re-routed for unapproved clients.
It is really terrible software if it does hijack the DNS queries. That messes with all kinds of clients that cache DNS records.
A good system will allow DNS instead of poisoning the clients with thresholds to block DNS tunneling.
A good system will allow DNS instead of poisoning the clients with thresholds to block DNS tunneling.
I would think non-NXDOMAIN answers with very short TTLs (to avoid contaminating the negative lookup cache) ought to be harmless to all but the very sloppiest clients, no?
No. First, clients may be sloppy or may have alerts triggered if the IP doesn't fall into the right range. The latter has nothing to do with poor code quality. That's the problem with hijacking DNS, you've moved well beyond web browsers into all kinds of applications that are loaded with custom code that have completely undefined behavior from your perspective. For all you know, the DNS responses you've tweaked will make the user's software completely unusable until the whole thing is restarted.
Second, what do you do when the client is configured to require DNSSEC responses?
Second, what do you do when the client is configured to require DNSSEC responses?
I have been running OpenVPN on UDP/53 for a few years now. I figure that any network operator sophisticated enough to do deep packet inspection to detect real DNS traffic is also sophisticated enough to block outbound UDP/53 traffic.
Nope. Public paywalled hotspots often have ip whitelists while you didn't pay. So they'll let everything trough that goes to THEIR dns. Openvpn on 53 won't help you here. Iodine will.
I don't know why they serve full dns to unpaid users. Maybe to avoid os dns cache issues.
I've used iodine a few times in the past while traveling. Works like a charm.
I don't know why they serve full dns to unpaid users. Maybe to avoid os dns cache issues.
I've used iodine a few times in the past while traveling. Works like a charm.
I see. You can use Iodine to tunnel through any arbitrary DNS server, even ones not under your control. I didn't appreciate that when I posted the above comment. Very neat.
They serve full DNS because then it's a single configuration to bother with - regular DNS. Until tools like this are factored for, there's no reason to do anything stateful with the DNS response. It'd just be extra work.
IP over DNS, TCP over DNS, IP over ICMP... surely somebody is running a service with all of these for maximum captive portal avoidance?
ICMP is often blocked nowadays even when HTTP is allowed, so I don't think IP over ICMP is very useful.
It is possible to filter Iodine requests given that they use NULL records, which are inexistent in the real world. Some other well-known tools use TXT, which is a bit more common. TUNS (http://www.loria.fr/~lnussbau/tuns.html) uses CNAME and respects the DNS standard, which should have near-100% success. It's quite a bit slower though.
It is possible to filter Iodine requests given that they use NULL records, which are inexistent in the real world. Some other well-known tools use TXT, which is a bit more common. TUNS (http://www.loria.fr/~lnussbau/tuns.html) uses CNAME and respects the DNS standard, which should have near-100% success. It's quite a bit slower though.
It is possible to filter Iodine requests given that they use NULL records, which are inexistent in the real world.
Iodine actually also uses TXT, SRV, MX, CNAME and A, in this order, if it detects that the better choices are blocked.
Iodine actually also uses TXT, SRV, MX, CNAME and A, in this order, if it detects that the better choices are blocked.
Iodine is pretty cool, but do keep in mind that even though this repo looks new and novel, the project has been around since 2006.
There's a network-manager plugin too: https://honk.sigxcpu.org/piki/projects/network-manager-iodin...
Also tangential to it: IP-over-ICMP
http://thomer.com/icmptx/ though never got to play with it.
Iodine is cool. If you plan on using it soon remember to set up your DNS records beforehand cause it might take a bit to propagate. I literally spent a whole airplane flight sending DNS requests to see if it propagated yet.
Iodine is cool. If you plan on using it soon remember to set up your DNS records beforehand cause it might take a bit to propagate. I literally spent a whole airplane flight sending DNS requests to see if it propagated yet.
You can avoid the propagation time by creating a new DNS record that hasn't been cached anywhere yet.
This project reminds me of ptunnel
http://www.cs.uit.no/~daniels/PingTunnel/
I've used it to get free internet at universities and hotels, slow but gets the job done. ICMP usually isn't filtered by those kinds of firewalls and I've yet to find a place that blocked it.
I've used it to get free internet at universities and hotels, slow but gets the job done. ICMP usually isn't filtered by those kinds of firewalls and I've yet to find a place that blocked it.
This is another intriguing example of a covert communication channel [1] [2].
[1] http://en.wikipedia.org/wiki/Covert_channel
[2] File Transfer OverDNS - https://news.ycombinator.com/item?id=7370917
[1] http://en.wikipedia.org/wiki/Covert_channel
[2] File Transfer OverDNS - https://news.ycombinator.com/item?id=7370917
Nice project. I've been curious about internet (TCP, IP, whatever) over DNS for a while, but it always seems like a lot of work. Is there an X-over-DNS that's trivial to set up for Mac and phones? I'm aware that iodine works for those, it just looks .. complex.
What's the legal side of this?
I can imagine tunnelling your traffic through DNS to avoid a captive portal (i.e. actually paying for it) counts as circumventing a security measure, which is illegal in a lot of places including the country where I live in.
I can imagine tunnelling your traffic through DNS to avoid a captive portal (i.e. actually paying for it) counts as circumventing a security measure, which is illegal in a lot of places including the country where I live in.
Cool.