Content

SSH over Stunnel for IDS evasion

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.

[email protected]

Paul Asadoorian

Paul Asadoorian is currently the Principal Security Evangelist for Eclypsium, focused on firmware and supply chain security awareness. Paul’s passion for firmware security extends back many years to the WRT54G hacking days and reverse engineering firmware on IoT devices for fun. Paul and his long-time podcast co-host Larry Pesce co-authored the book “WRTG54G Ultimate Hacking” in 2007, which fueled the firmware hacking fire even more.

Paul has worked in technology and information security for over 20 years, holding various security and engineering roles in a lottery company, university, ISP, independent penetration tester, and security product companies such as Tenable.
In 2005 Paul founded Security Weekly, a weekly podcast dedicated to hacking and information security. Paul grew Security Weekly into a network of security podcasts spanning multiple topics, such as application security and business. It has been estimated that Paul has conducted over 1,000 interviews with security professionals and hosted more than 1,000 podcast episodes in cybersecurity. In 2020 Security Weekly was acquired by the Cyberrisk Alliance.

Paul is still the host of one of the longest-running security podcasts, Paul’s Security Weekly, he enjoys coding in Python, telling everyone he uses Linux as his daily driver, poking at the supply chain, and reading about UEFI and other firmware-related technical topics.

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms and Conditions and Privacy Policy.