The other day, I found myself behind a fairly draconian firewall. There are really two philosophies when setting up a corporate network. One is to block everything inbound while allowing everything outbound. The other one is just to block everything except ports 80 (HTTP) and 443 (HTTPS) and only allow dedicated mail servers to use 110 (POP) and 25 (SMTP). This is of course more secure, but can also be quite annoying when you for example you have an IMAP email account, or when you are trying to SFTP some files to a remote machine.
That’s ok though. What do we have ssh for? Am I right guys? Let me just whip out a nice little tunnel that will bounce my IMAP traffic off the home server and I will be back in busine… Oh. Right. Port 22 is also closed. Granted, there is not much use for that port at a location that is running nothing but Windows both on the desktop and the server side. Leaving it open would probably drive the anal retentive admin insane with doubt, and uncertainty. I was foolish for thinking it could be that easy.
Of course I’m not a person who takes closing port 22 lightly. In fact I’m quite attached to that port, and not being able to used it makes me cranky. So I decided to figure out a way to bypass this firewall silliness and share the solution with you.
Lets sum up what we know about this network. It’s locked down pretty tight, but the two ports they can’t lock are 80 and 443. I mean, they could and then force you to use a proxy server but they didn’t. So we have our window – we can send packets out of the network on one or both of these ports unrestricted. Now we just have to jerry-rig something to allow us to redirect ssh to one of those ports. To do that, you will need two things:
- A corcscrew
- A HTTP proxy with SSL support
I’m running ubuntu, so installing corkscrew was easy:
sudo aptitude install corkscrew
Alternatively you can just download it from the homepage (linked above) and compile it yourself. This tool will allow you to proxy your ssh traffic (or any traffic really) over a HTTP proxy. The problem of course is finding a proxy that will work. I recommend not even bothering with basic HTTP proxies. Corkscrew uses the CONNECT command that is usually disabled on most servers. Look for SSL enabled proxies instead since they will usually leave that feature on by default since the SSL protocol itself uses it. This narrows down your search a little bit.
You can test prospective proxies like this:
corkscrew prospective.proxy.server 80 your.ssh.server 22
If the CONNECT command is disabled you will usually get an error message, at this point or the connection will simply time out. If the proxy does relay ssh data you will get some feedback. For example, I saw this SSH-2.0-OpenSSH_5.1p1. Once you have a working proxy, add the following lines to your ~/.ssh/config file:
Host your.ssh.server ProxyCommad corkscrew working.proxy.server 80 %h %
This tells your ssh to route any connection to your.ssh.server via the working.proxy.server on port 80, bypassing the draconian firewall. From now on, you can simply log in like this:
No other setup is necessary. This should also work for tunnels, scp and anything else you can think of. Of course the connection will be slower, and you are routing your traffic through an unknown machine (unless you actually own the proxy) which is obviously a security issue. Still, if you are stuck and you need to ssh somewhere and the syadmin is either a BOFH or simply MIA, this trick will work.