howto bypass the corporate firewall
This article provides a brief guide on circumventing the corporate firewall using an SSL tunnel. Why bother? Sometimes it blocks legitimate resources I need to access, and it is slow. Requesting a whitelist for each domain individually is time-consuming, so I decided to explore alternative methods. Most corporate firewalls are designed to be cost-effective, not maximally efficient. To bypass the restrictions, we could use a simple SSH tunnel wrapped inside the HTTPS session to the Internet server. Why do we use SSH inside the SSL tunnel? Some corporate firewalls perform man-in-the-middle attack by providing custom certificates installed on company computers, so that browsers would not complain about an untrusted certificate in the chain. Correctly configured SSH with public key authentication is used to mitigate the man-in-the-middle on the corporate side.
Our prerequisites are: A computer in the corporate network that can run a browser with custom proxy settings, an SSL tunnel software, and an SSH client. A cloud server outside the corporate network that runs HTTPS web server. The web server must allow "CONNECT" to port 22. Remember, we need to access the server's SSH service through SSL. The cloud server must be accessible through the corporate firewall on HTTPS port 443.
The diagram below depicts the typical session to the outside:
External server configuration
Let's start with an external system that terminates the tunnel. A cheap cloud shell hosting is a perfect choice. Our cloud server of choice runs Apache, performing HTTPS to SSH proxying. Here is an example of apache2 vhost config:
<VirtualHost *:80>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
RewriteEngine on
RewriteCond %{SERVER_NAME} =proxy.outside.com
RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
<Proxy *>
Order deny,allow
Allow from all
AuthType Basic
AuthName "Restricted Files"
AuthBasicProvider file
AuthUserFile "/etc/apache2/passwd/proxy"
Require user proxy
</Proxy>
ProxyRequests On
AllowCONNECT 22
ProxyVia on
</VirtualHost>
This Apache virtual host is responsible for proxying incoming connections to the SSH server. The proxy itself is protected with a simple HTTP password authentication. One could extend it to a complex dynamic authentication scheme.
Stunnel configuration (client side)
The stunnel configuration below accepts TCP connections on port 8022 and connects them to proxy.outside.com:443. Password resides in psk.txt
stunnel config:
[proxy]
client = yes
accept = 127.0.0.1:8022
connect = proxy.outside.com:443
verifyChain = no
PSKsecrets = psk.txt
Preshared key is defined within a psk.txt file like this: user:password
Putty (client side)
The Putty session connects to the OpenSSH server on the remote host through stunnel and creates a SOCKS proxy on the local port TCP 8980. Session's destination host is root@127.0.0.1 port 8022 (which is a tunnel to the SSH service on the outside host). A dynamic connection on port 8980 must be defined for that session in Connection> SSH> Tunnels. This would bring up a SOCKS service acting as a browser proxy. You can use the pageant SSH agent for the convenience of not having to type your SSH key password every time you start a session.
Firefox
My browser of choice is Firefox, but to use it in a corporate environment, you may need to override the configuration file to allow proxy configuration. I have named the file firefox.cfg and placed it in a Firefox directory next to the binary. The firefox.cfg file has following lines:
//first line is always a comment
pref("network.proxy.type", 1);
unlockPref("network.proxy.type");
Once the Firefox proxy settings are unlocked, you can define the SOCKS proxy and initiate the SSH session.
That's it. Once your stunnel is established an SSL connection to the cloud server is active, start the ssh session. Then use the Firefox with a socks proxy.