Internet by all means

(Sorry for the delay; doing now what I should have done a long time ago: split my article in two parts, as it is the second part that really keeps me back... What do you want? Being a perfectionist I can't publish a "From Maximum Risk To Maximum Security" article until I have everything covered :P)

What I describe here should be very useful to you if you can find yourself in at least one of the following situations:

• you can use an Internet access but it lacks security (e.g. free WiFi hotspots, campus Internet, etc)
• you want to demonstrate ineffective firewalling during a pentest
• you subscribed to a 2-years contract for "unlimited mobile Internet access" - so unlimited their marketing department even named it "Illimythics 3G+" in my case - asked every rep you could if it would indeed correspond to your needs, and while none of them seemed to know what SSH is, they all blatantly assured you that it was possible... until you realized, too late, that it is in fact HTTP-only
• you feel ripped-off by a hotel reservation that you chose specifically because it advertised Wi-Fi access for customers, but once there you realize they charge extra for it.
  

All in all, this comes down to a simple problem: how to get a full & secure Internet access in (almost) every case?

To address this problem, we'll rely on what I call a "stepping stone", i.e. a computer reachable by all means, preferably 24/7, with a private full Internet access and to which we will tunnel our Internet traffic by whatever mean we have available at some point.

Now, being able to reach your stepping stone depends on what kind of traffic you are allowed on the connection you try to reach it from... Let's enumerate them from best case to worst case in terms of usability:


1. IPSec traffic directly to the stepping stone

I cite IPSec first because it is THE standard for secure Virtual Private Network-ing and therefore available on all operating systems. However, you will only be able to use it if there is no firewall or if the firewall doesn't filter it (cf. paragraph on IPv6 below), and if behind a NAT router, if you're the sole IPSec user or if the router supports NAT-T.


2. any kind of traffic directly to at least one UDP port on the stepping stone

In this case the best is to use OpenVPN; if you know the port number in advance all you have to do is configure OpenVPN to bind on this port, otherwise you can redirect traffic arriving on other UDP ports to OpenVPN with Netfilter:

iptables -t nat -A PREROUTING -i eth0 -p udp -j REDIRECT --to-port 1194

I made my OpenVPN reachable on all UDP ports because every now and then I am surprised to see some exotic UDP port allowed through a firewall, no idea why... HD Moore wrote a very useful script to test that.


3. any kind of traffic directly to at least one TCP port on the stepping stone

Here you can use OpenVPN like above (but two separate configuration files are needed in order to get it to listen both to UDP and TCP) or OpenSSH tunneling.

I put TCP under UDP because TCP over TCP is considered a bad idea so OpenVPN over TCP or OpenSSH with its new VPN capability (ssh -w) won't work as well as OpenVPN over UDP.

Personally I chose OpenVPN on TCP too because:

• using OpenSSH to tunnel to a HTTP proxy (like Squid) on the stepping stone is definitely quick to setup (ssh -L 3128:127.0.0.1:3128, and adjust HTTP proxy parameters in your browser, instant messaging client, etc accordingly), or to act itself as a SOCKS proxy (ssh -D 1080) which is even quicker if your applications support SOCKS proxying (all browsers do), but that requires having a highly-privileged daemon facing the Internet for little reason
• it sure is nice to be able to administer your stepping stone remotely with OpenSSH, but you can always do that once you're connected with OpenVPN
  

And, same as above, if you know the port number in advance all you have to do is configure OpenVPN to bind on this port, otherwise you can redirect traffic arriving on other TCP ports to OpenVPN with Netfilter:

iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-port 1194

Like with UDP, you never know what crazy TCP port a firewall might allow. I once found a firewall that would allow me nothing but emailing the whole Internet (TCP port 25) : what the f... oh well.


4. IPv6 traffic directly to the stepping stone

While not answering the communications confidentialy aspect by itself (but it goes along with IPSec pretty well), if you're lucky enough to have IPv6 support on both sides and if the firewall administrators were as clueless as to have a default allow policy (yes... they're many) and as not to take IPv6 into account (usually that goes together), IPv6 is a firewall traversal mean deserving to be mentioned.


5. any kind of traffic or just SSL traffic to at least one TCP port (typically 443, the HTTPS port) on the stepping stone via a HTTP or SOCKS proxy

Many people use OpenSSH tunneling with connect.c to get through such proxies; it is indeed convenient but once again, I'm not comfortable with the security implications. Fortunately, OpenVPN supports HTTP and SOCKS proxying out of the box. You can make OpenVPN reachable on TCP port 443 and other ports like explained above.

Note: some mobile Internet operators filter access to their proxy based on the User-Agent string of the web browser shipped with your smartphone; copy it to OpenVPN via the "http-proxy-option AGENT" parameter and off you go!


6. ICMP (like ping) traffic directly to the stepping stone

If for example you are able to ping 4.2.2.2 (one of the easiest publicly pingable IP address to remember), chances are you can use PingTunnel to connect to a TCP port on your stepping stone, and from there access the whole Internet securely by using OpenVPN or OpenSSH... There are issues with some NAT routers, so you might want to try "unprivileged mode" in PingTunnel, not for security reasons (I heavily patched PingTunnel to make it super tight; you'll see in next blog post) but because it then uses real ICMP Echo requests and replies (to the cost of throughput), which get through the NAT routers that don't like how PingTunnel normally operates.

Also, a firewall not allowing ICMP Echo doesn't mean it won't allow ICMP messages of other types... Come to think about it, I'll have to add this feature too to PingTunnel.


7. recursing DNS requests to the stepping stone via some DNS server

Now, about DNS tunneling: I put it among the last in this list because it provides less throughput than the previous solutions and really, from a protocol engineering point of view, it's ugly... Then again, it's AWESOME because it works almost everywhere!

In order to use it, you will need a domain name (or a subdomain at DNSTunnel.de, kindly offered by Julius Plenz) and one of the following: NSTX, Iodine, OzymanDNS, Heyoka...

Research is still active on the subject of DNS tunneling, this is why there are many tools already and more coming up. NSTX is the historical one, Iodine offers better throughput than NSTX and is available for most operating systems. OzymanDNS and Heyoka are less than a year old and still a bit proof-of-concept-ish but nonetheless interesting: the former is Dan Kaminsky's attempt, and the latter has the highest ambition.

Personally I'm more than happy with Iodine.

EDITED TO ADD: As Nicolas Ruff pointed out, DNS tunneling can "severely degrade network performance" of everybody else using the same DNS server, so be reasonable.



8. HTTP traffic to TCP port 80 on the stepping stone through a (transparent) HTTP proxy

As the name suggests, transparent proxies transparently redirect your connections to the Internet on TCP port 80 to a local HTTP proxy; it may look like you are simply allowed TCP port 80 to the Internet, but try sending anything else than HTTP on this port, it won't work. Good thing to know though: even if the transparent HTTP proxy doesn't let you through for some reason, you will most likely be able to do DNS tunneling (see above) as letting the clients perform their own DNS requests is mandatory in transparent HTTP proxy setups.

Now, allowing HTTP but not HTTPS is utterly suspicious, besides breaking many web authentication procedures. Fortunately it is very rare, but in case you end up in this situation, HTTPTunnel is the way out: it will give you the possibility to connect to another TCP port on your stepping stone (and thus reach OpenVPN or OpenSSH) while making your traffic look like HTTP.

Note: User-Agent filtering can happen in this case too, see paragraph on HTTP and SOCKS proxies for solution.



9. other means of relaying data to and from the stepping stone via some reachable server

Apparently my friend Mubix has a super-secret project coming on that... in addition to having a Hak5 episode on tunneling SSH over DNS :)

EDITED TO ADD: You were several to guess that what was left out in this list was email tunneling... I did so intentionally as I didn't want to give away Mubix's project. Now it appears Mourad Ben Lakhoua beat him to it, but only with HTTP, which we'll count as cheating because HTTP has basically the same transfer encodings as emails and the same request-response model :-P Sure, HTTPTunnel can most likely be stacked on top of that (and we would end up with TCP/IP over SSH over HTTP over SMTP&IMAP, heh) but it would be interesting to see if other, better methods of email tunneling are conceivable.



As you can see, if you want to maximize your chances to reach your stepping stone and thus get a full & secure Internet access, you basically have to make it face the Internet with all TCP ports open, all UDP ports open and even ICMP tied to a daemon... While I generally disagree with the people who say a computer with 10 ports open is more insecure than a computer with 4 ports open, I have to concede that we are kind of daring the devil here...

And that is why in the other half of this article (which I'll hopefully manage to find the time to finish within the week) I will explain how to achieve maximum security! :)