{"id":2199,"date":"2016-07-28T10:46:11","date_gmt":"2016-07-28T09:46:11","guid":{"rendered":"http:\/\/emtunc.org\/blog\/?p=2199"},"modified":"2016-07-28T10:46:11","modified_gmt":"2016-07-28T09:46:11","slug":"reverse-ssh-tunnelling-ssl-raspberry-pi","status":"publish","type":"post","link":"https:\/\/emtunc.org\/blog\/07\/2016\/reverse-ssh-tunnelling-ssl-raspberry-pi\/","title":{"rendered":"Reverse SSH Tunnelling over SSL with the Raspberry Pi"},"content":{"rendered":"

In this blog I will go through the steps necessary to set-up an automatic reverse SSH tunnel between\u00a0a client machine sitting in a restricted environment and\u00a0a server that you control in your home\/office\/cloud<\/em>. The reverse SSH tunnel will be encapsulated within a SSL tunnel over port 443 to evade network security appliances\/firewalls.<\/p>\n

<\/p>\n

In my set-up I used the Raspberry Pi 3<\/a> as the client because it’s small,\u00a0inexpensive and inconspicuous<\/a>;\u00a0great for penetration testers in the field who want to be in and out of an environment in under\u00a0a minute. You don’t even need a power socket nearby as you can use a powerbank<\/a> with enough capacity to last you a good few hours; enough time to find an exploit\/vulnerability on the network and\u00a0hop<\/em> on to a more permanent host.<\/p>\n

First let me start off by saying that this post is for educational purposes only and that you should always seek permission to use\/abuse a network that you are not responsible for. The post was written with the intention of aiding security researchers, testers and people who are simply intrigued and want to learn the technology in order to improve the security stature of their own networks.<\/p>\n

Let’s begin…<\/p>\n

A reverse tunnel is one where the client (Raspberry Pi in this case) makes a connection\u00a0out<\/em> from the target network to your server. You can then piggyback off this connection to talk\u00a0directly to the client on the network; all without\u00a0NAT’ing\/opening any ports on the firewall.<\/p>\n

Now you’ll find that most (I hope) IT departments will have port 22 blocked. You’ll find a subset of those IT departments\u00a0will have the resources available to use some sort of IDS\/IPS\/NGFW to do deep packet inspection so even if you SSH’d over port 443, the device performing\u00a0the inspection will identify the traffic as\u00a0SSH and drop it.<\/p>\n

This is where stunnel comes in handy – stunnel acts as a SSL wrapper which you can use to tunnel almost\u00a0anything through. We’ll be using it to tunnel our SSH connection so that it looks like normal SSL traffic. In other words it’ll work like this:<\/p>\n

    \n
  1. Client establishes SSL tunnel with server over port 443. Firewall permits the traffic as it looks like normal SSL traffic<\/li>\n
  2. Client establishes reverse SSH tunnel with the server. Firewall knows no better as the SSH connection is established within the SSL tunnel.<\/li>\n
  3. Server can now talk to and take control of Client using the reverse SSH tunnel<\/li>\n<\/ol>\n

    Prerequisites<\/h3>\n

    Before we begin configuring the client and server we should get some basics out of the way first.<\/p>\n