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:
ssh your.ssh.server
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.
If you have control over the ssh server config on the remote side, there’s an even easier way – just make sshd listen on port 443 as well as 22. You can do this by editing sshd_config (usually located in /etc/ssh/) and below this line:
Port 22
add a line like
Port 443
save, restart sshd, and you can then connect directly over port 443 using
ssh -p 443 user@host
@ reacocard:
Of course – that would work, but… How do you do that when you are at a location with a draconian firewall and your server is miles away at your house.
If you know ahead of time, then yes – you can set this up. But if the firewall caught you by surprise, or worse – if you don’t have root on the said server this workaround will likely save your life. :)
@ reacocard:
That’s how I do it too. Work’s nice because not many admins are going to block 443, so I should be able to tunnel home from anywhere (in theory).
SSH tunnels are wonderful things. They make holes big enough to fly an airplane through. On occasion I have even SSHed back through an SSH tunnel.
I too just run my home ssh server on port 443 all the time. That way I am always prepared to route around almost anything. This also has the added bonus of greatly reducing the attacks on my ssh server, especially when I run an ssh honeypot on 22.
I just noticed something: posting this tunneling information on your blog may have an annoying consequence. Your blog is suddenly blocked here at work by Websense under the category “Proxy Avoidance”. Maybe (hopefully) this isn’t permanent and will go away when the corkscrew link drops off the main page, or else people like me will always have to tunnel our way here when visiting from work.
I wouldn’t get too comfortable with this method. While it is a great way for you to be productive, it also allows malware to make it’s way out as well. Many companies are starting to pay attention to what goes through their proxies. SSH stands out like a sore thumb.
You should also consider setting up Ping Tunnel some time when you’re not behind the firewall. TCP tunnelled over ICMP.
It’s very useful for networks where even HTTP is blocked (or requires payment).
If you are looking to find a list of working http proxies, you can look here: http://www.pxylst.info
Proxies are scanned hourly to ensure that they are working!
@ Chris Wellons:
Aw, crap. Sigh… Well, it’s not like I wasn’t blocked before. I think some schools blocked me for obscene language and other similar infractions. :P
@ Craig A. Betts:
Yeah. I’m sure this can be exploited in various nasty ways.
@ Kenny:
Actually, the firewall I was behind was blocking outbound pings. You could ping stuff on the local network, but not outside. I’m fairly sure it was specifically to prevent this type of thing. :P
@ Brian:
Sigh… I’m 99.9% sure this is spam, but I’ll allow it because it’s on topic.
@ Luke Maciak:
Your main page is unblocked now, but the “Older Entries” link to the second page of articles is blocked since (I guess) it contains this article. The block seems to be automatically following that “offending” link. So it’s mostly back to normal.
Note, despite this, this specific post of yours isn’t blocked. Only when it appears along with other entries. Websense must not crawl very deeply.
Pingback: DanZei » Blog Archiv » SSH durch eine Firewall über HTTP tunneln
And what solution could be applied when SSL access is also blocked on proxy?