A feature of Apache Web Server allows anyone to establish an SSH connection through the boundaries of any enterprise network. This is done completly stealthy and undetectably, fooling firewalls, proxyes, and any other enterprise network filtering wildlife. As a matter of fact, virtually any protocol might be tunnelized this way -except, of course, for IPoAC 
. But I will take the example of SSH since it opens a very interesting, wide-spectrum, vector to further analisys.
Quite esoteric, ah? This is how all this black magic work
It is simple, most proxyes will allow outgoing HTTP trafic to any website. Proxys want the users to surf the web. That is their purpose to exist. And that is what we will expliot. But most of the proxyes will only let their users through the paths they know safe (or whatever filtering their administrators may have set). In the best scenario, the proxy will not allow one particular HTTP method called CONNECT. This method is the one used for SSL/TLS protocol. It establishes a tunneled connection between the client and a remote server, through the proxy server. Since it is used by SSL/TLS, some proxys will let the CONNECT method free to certain sites, and most probably only on port 443. This, plus some L7 filtering and maybe some DPI, describes the most secure environment one might ever find inside any enterprise network. On the other hand we have lazy-administrated proxys that will allow you do whatever you want. If this last is your scenario, don’t waste your time reading any further, go use it for some SSH simple tunneling
Back to our stuff, there is free access to any website listening on port 80 for some plain HTTP. And this is what we are going to do, talk plain HTTP to some server waiting for us on port 80.
Apache plus mod_proxy module will let us set up an HTTP server listening on port 80, and at the very same time an HTTP proxy. The proxying part is done by mod_proxy. This module turns Apache into a fully functional HTTP forward-proxy and reverse-proxy. For our purpose reverse-proxy is not necessary and will not be explained, sorry (I’ve wrote a tutorial explaining reverse-proxying with Apache here if interested). So, the exciting feature of mod_proxy is its ability to handle the CONNECT method. It will even handle it if the transparent proxy, at the boundaries of our enterprise network, does not allow the CONNECT method. This, because we will talk GET and POST with Apache, the CONNECT thing happens inside Apache, and outside of the control of the enterprise proxy. The end result: we can use the CONNECT method. This is good and not good, we will see further.
What is needed
A list of thing needed to achieve this implementation.
Client side
Server side
- Apache Web Server 2.x (1.3 branch might work as well but it’s not tested)
- A proxy server: for this test I used tinyproxy for its simplicity.
- GNU/Linux Operating System: I will focus on the Ubuntu distribution.
- A domain name (this is optional).
- An Internet connection.
The server side: Apache configuration
This is an example virtual host configuration which I used for testing this implementation.
<VirtualHost *:80>
ServerName proxy.mydomain.com
This directive enables DNS lookups so that host names can be logged. The value Double refers to doing double-reverse DNS lookup. That is, after a reverse lookup is performed, a forward lookup is then performed on that result. At least one of the IP addresses in the forward lookup must match the original address. It is paranoid but is a good security measure:
HostnameLookups Double
This allows Apache to function as a forward proxy server answering requests:
ProxyRequests On
This is the most important directive here. Here we set the list of ports we will let Apache to use the method CONNECT against. In this case we set only port 22, which is the OpenSSH server default:
AllowCONNECT 22
This setting will deny access to anyone. Don’t worry, we will allow access to ourselves later:
<Proxy *>
Order deny,allow
Deny from all
</Proxy>
This directive tells Apache what hosts we are allowed to access to. Note that we can specify more than one using regular expressions. On this example we are allowing access to host1 and host2:
<ProxyMatch (host1|host2)\.mydomain\.com>
Order deny,allow
Deny from all
Now we allow only our IP to access. Note that this IP must be the public IP address of the enterprise proxy:
Allow from 200.5.26.161
</ProxyMatch>
Now we set the log files (this is optional):
ErrorLog /var/log/apache2/proxy.error.log
CustomLog /var/log/apache2/proxy.access.log common
</VirtualHost>
And that is all with Apache configuration. Once started the proxy is ready.
Some extra security layer: Using SSL
It is possible to use SSL instead of plain HTTP. This would give us an extra security layer since ALL traffic would go encrypted. And a big advantage: ALL traffic will be indistinguishable from any other allowed normal HTTPS website browsing. Whoever can see our packets will se nothing but unreadable encrypted data anyway.
The disadvantages are two: HTTPS might be retricted to only a couple of sites, or disabled at all; to support SSL we will need more than a simple client that can talk to a web proxy, it will have to speak SSL.
Anyway if it is your desire, just add these directives to the VirtualHost config, as you would with any other HTTPS site:
SSLEngine On
SSLCertificateKeyFile ssl/apache.pem
SSLCertificateFile ssl/apache.pem
Of course you will need to generate your SSL certificates. If you don’t know how, look for my tutorial on reverse-proxying which I linked above, it is explained either.
The client side: Setting up you proxy client
On the client side the configuration is simple. Just set your OpenSSH client to connect to mydomain.com and to use as proxy the same, mydomain.com. We will use Corkscrew as proxy client. To do it you have to edit the file ~/.ssh/config. If it does not exist, don’t worry, just create it and edit with the editor that pleases you the most (I like vim, by the way). It should look like this:
Host mydomain.com ProxyCommand corkscrew mydomain.com 80 %h %p
That will make ssh use corkscrew to stablish the connection using mydomain.com as proxy.
Ok, now you red this a ~thousand times and believe have missed something. Where the hell is the devilish enterprise transparent proxy, that makes you have to take all this work to browse Facebook, in all this? You missed the "transparent" part. It will let us get to any plain HTTP webserver on port 80. Since our Apache proxy sits on port 80 doing plain HTTP, our transparent proxy can’t tell the difference. Hence, we got through it completely safe.
For the Windows users: You can do this in a easier way using PuTTy. Follow these instructions:
Set up the basic connection:
Set up the proxy connection:
If you will be using HTTPS, then you will need a proxy client than cant talk SSL/TLS. To the date, the ONLY proxy client I know capable of talking to an HTTPS proxy is proxytunnel. If you find another one, please let me know! 
A practical use: Surf the web unrestricted
Ok, now we have our tunnelized connection. We have a shell, we are happy. Most of us would be just fine with that. A lot more people will not :p So, here comes into scene tinyproxy. To achieve some useful stuff we will set a tunnel over SSH to access our tinyproxy at home and browse the web through it. We will be forwarding tinyproxy’s port to our PC using OpenSSH port forwarding feature. To do this we just launch the OpenSSH client this way:
user@pc$ ssh -L 8080:myserver:8080 mydomain.com
That will open port 8080 on your PC which actually will be the 8080 port of your remote tinyproxy installation (myserver). Literally a tunnel inside the tunnel
For the Windows users:
Set up the port forwarding on PuTTy:
Now click "Add" button, and should see something like this:
That’s it. Now we save the session, so we don’t need to set it all again, and open it.
And now, the final step: configure our browser to use 127.0.0.1 on port 8080 as proxy.
Finally we can login to our SSH server and try pointing our browser to any website we know blocked by the enterprise transparent proxy!
A hazardous use: Malware
Yes, this is a technic that can be very usefull for malware developmente. This can help them do wahtever they want, once inside an organization’s network. And it is a very high risk to take. Unfortunately there is no way of stopping it.
As far as I’ve been investigathing this, there have been only two approaches on the matter. But as you go further on their reading, you understand the better how difficult it is to detect these kind of tunnels: their approach is iseless unless you have control over all of the infraestructure components, which is not a real world scenario.
I’ll be investigating this a lot further, and will be publishing my findings here.
A stealthier twist: "Mask" your proxy as a simple http website
This is the BEST part of using Apache. You can set it up as normal web server, serving some webpage. This way whoever point to mydomain.com will see a normal and harmless website, and won’t be able to distiguish it from a non-proxying server.
For example, give it a fancy name like photoalbum.mydomain.com and mount some web image gallery manager on it.
To do this just add the DocumentRoot directive and set the ServerName directive like this:
ServerName photoalbum.mydomain.com
DocumentRoot /var/www/my_photoalbum
DocumentRoot should be the physical path, on the server filesystem, to the webpage you want to serve.
Voila! You have a completely unsuspected web site to the outside visitor’s eye
The world destruction use: GLOBAL THERMONUCLEAR WAR
(my tribute to an epic movie
Got your attention, ah? XD
I don’t put in doubt the fact that this article might help you achive such a super villain’s worthy development. But it is way far from this article’s scope
The End
As you can see for yourself, possibilities are limited only by imagination…
I hope you enjoyed reading and using this stuff.
Stay tunned!
Si te gustó esta nota, podés invitarme una cerveza en agradecimiento. Y algún día quizá pueda yo invitarte una :D
