Bypass all corporate Internet filtering at work, without admin rights
6 comments
"If anyone can see any flaws, please comment."
If you get caught, you'll probably get fired. If your company is bureaucratic enough to have internet filtering, they'd probably take this kind of unauthorized circumvention of their policies rather seriously.
If you get caught, you'll probably get fired. If your company is bureaucratic enough to have internet filtering, they'd probably take this kind of unauthorized circumvention of their policies rather seriously.
Hence my disclaimer at the top of my post.
However, having been a software engineer at multiple Fortune 500 companies that don't even allow their software engineers local admin rights or relaxed proxy filtering - things that we need to do our jobs - I've had to use this workaround to, well, do my job. Sometimes there's a patch or a workaround for an esoteric bug on someone's private blog that you can't access because it's on a .nl domain and your workplace blocks all .nl domains unless specifically white listed, and it would take you weeks to file and get approved a request to get it white listed.
If you happen to be at a company that doesn't trust you to be on the internet and to administer your own computer, this is one way you can use to access what you need while you look for a better place to be employed. I've found it useful and thought I'd share.
However, having been a software engineer at multiple Fortune 500 companies that don't even allow their software engineers local admin rights or relaxed proxy filtering - things that we need to do our jobs - I've had to use this workaround to, well, do my job. Sometimes there's a patch or a workaround for an esoteric bug on someone's private blog that you can't access because it's on a .nl domain and your workplace blocks all .nl domains unless specifically white listed, and it would take you weeks to file and get approved a request to get it white listed.
If you happen to be at a company that doesn't trust you to be on the internet and to administer your own computer, this is one way you can use to access what you need while you look for a better place to be employed. I've found it useful and thought I'd share.
Why run the risk of getting fired? Just use your smartphone and data plan to get to a blocked website. Most companies don't jam cellphone transmissions, or make you work inside a Faraday cage.
Web filters doing deep inspection on the HTTPS traffic should catch this I believe - using a fake cert to decrypt the HTTPS.
You'd have to bypass a nasty warning from your browser before this could happen.
Not on a company machine that has the root certificate installed, which is standard procedure if you deploy a system like that.
A really good IDS might be able to catch tunneled traffic purely by looking at the traffic patterns, but I don't know how corkscrew works exactly and if such detection is possible without creating too many false alerts.
A really good IDS might be able to catch tunneled traffic purely by looking at the traffic patterns, but I don't know how corkscrew works exactly and if such detection is possible without creating too many false alerts.
Unfortunately, this requires having root on a server that is associated with a .com domain that is not blocked by your corporation's proxy/firewall.
1) Set up your SSH server to listen on port 443.
2) Install corkscrew. If you are on Windows, Cygwin's install has a --no-admin option you can pass from the command line, which will allow you to install it to some local directory. Once you have Cygwin, you can install corkscrew with no problems.
3) Set up ~/.ssh/config to route all outgoing non-local SSH connections over corkscrew to port 443 on your .com.
4) Run an SSH tunnel via corkscrew through your server on port 443.
5) Set up Firefox to use a local SOCKS5 proxy through your tunnel, making sure to check the DNS prefetching checkbox.
6) Browse away.
What is happening here is that the firewall/proxy will not block outgoing HTTP connections to port 443 on a non-blocked domain because they look like a normal web browsing request. Since you are routing SSH over HTTP (using corkscrew) and accessing the default HTTPS port (443), your SSH connection will look like a regular HTTPS request to a website. Since your connection is encrypted, it is undistinguishable from normal web traffic, and it is highly unlikely that it will be blocked unless someone specifically looks into your traffic patterns and is sharp enough to recognize it (nobody has every caught me). None of port blocking, protocol filtering, or DNS filtering will be able to block your internet access (unless you leak DNS queries, which you will not if you use Firefox.)
I believe that this is foolproof and have had 100% success with it so far. If anyone can see any flaws, please comment. Otherwise, considering the plethora of partial solutions I found while establishing this method, I thought I might contribute my final workaround here.