A few weeks ago (Episode 329 http://secweekly2.wpengine.com/wiki/index.php/Episode329#Tech_Segment:_Free_Amazon_Socks_Proxy_by_Allison) Allison gave a great segment on avoiding firewalls using port forwarding and SOCKS proxy via ssh with a server on port 443 using free Amazon AWS instance. Something struck me:
1) you could have a proxy block SSH traffic going over 443.
2) you could haven IDS detect and, if inline, block since any IDS will detect SSH over non-standard ports.Â
So how do we fix this problem? Encapsulate SSH traffic inside SSL of course. In comes stunnel! Stunnel creates a SSL tunnel to pass almost any traffic through it. All you need is the same AWS instance that Allison talked about with stunnel installed and a client on the other end also with stunnel.
The setup:
yum or apt-get install stunnel – Both server and client (there is a macport of stunnel as well as Android and Windows installers at stunnel.org)
Server side configuration, create file stunnel.config with the contents below:
cert=/path/to/stunnel.pem
pid=/tmp/stunnel.pid
[ssh]
accept = <serverip>:443
connect = 127.0.0.1:22
Create Self Signed certificate.
Create a key
 $ openssl genrsa 1024 > stunnel.key
Generating RSA private key, 1024 bit long modulus
………………………++++++
……..++++++
e is 65537 (0x10001)
Generate the self signed certificate.
$ openssl req -new -key stunnel.key -x509 -days 1000 -out stunnel.crt
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
—–
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:
Next up create the PEM file which just contains the key and the crt contents
$ cat stunne.crt stunnel.key > stunnel.pem
Now you can start the tunnel — in Debian there is a perl wrapper for stunnel4 that is /usr/local/bin/stunnel — when I envoked stunnel this way the tunnel would not start. When I bypassed the wrapper and called stunnel4 directly it worked fine.
$ stunnel4 stunnel.config
verify with netstat that the port is running (netstat -tanp) or you can test it with an openssl command: $ openssl s_client -connect <ip>:443
Now over on the client side copy over the .pem certificate from the server and place it somewhere. Then create your client configuration file stunnelclient.config
cert=/home/ghetrick/stunnel/stunnel.pem
pid=/tmp/stunnel.pid
client=yes
[ssh]
accept=2200
;protocol=connect
;protocolHost=<ip:port>
;protocolUsername=<username>
;protocolPassword=<pass>
connect=<ip: port>
*If you need to go through a proxy you can uncomment the “protocol” lines and fill out the information accordingly. Where protocolHost is the server you want to connect to, and connect becomes the ip and port of the proxy device. If there is no proxy present the connect line is the ip and port of the remote host to connect to.
Now fire up stunnel on the client machine
$ stunnel4 stunnelclient.config
netstat -tapn to verify it is running on the assigned local port, in this example it is 2200
Now you can simply use ssh to the localhost
$ ssh -p 2200 localhost
and you are on the remote server, all hidden in nice SSL packets. I was able to run through a web proxy on port 443 with this config and did not trip signatures on the IDS that was otherwise tripping without stunnel in the middle.
You should be able to follow Allison’s documentation for getting port forwarding working properly for full enjoyment.
Go forth and evade.
