Doing a reverse ssh tunnel the embedded way

Having a large number of asterisk pbx installations creates some interesting problems to people who provide support for them.
One of tha major issues is how do you get access to the PBX if it is sitting behind a firewall/nat where you have little on no control and/or has a dynamic ip.
In most cases you could forward the ssh port from the vpn/router to the the asterisk machine but there are several problem that can come up with this way.
1) More and more companies have a strict "no incoming ports open" policy.
2) Having a permanent "unrestricted" access to the pbx equipment and its logs and functions,might make some companies very skeptic.
On the other having to send a tech person to a 2 hour drive to add an extension or make a minor modification to the dialplan is rather expensive and would create a real support nightmare.

After thinking about it and discussing with our clients (and their clients), we came up with the idea of a customer triggered solution that would create some form of secure "tunnel" from the Hermes e-IPBX to the suport center of the company that is providing support for the PBX.

The idea is simple.
If a tech needs to access the PBX remotely, a person in the company calls an extension, enters a password and the the pbx creates a secure tunnel to the server of the support company giving them access.
Once support has finished, the person in the company calls again the same extension shutting down the tunnel, and everything goes back to normal.
No open ports, no "unauthorized" access.

The question then came, to what type of secure tunnel we would use.
The solution had to provide a secure login and also access to web interface (port 80) of the pbx
Since Hermes e-IPBX runs on embedded devices also it had to be something small in size.
With this in mind we started investigating two options.
A PPTP vpn and a reverse ssh tunnel.

We started with the ssh option first, as almost all of the required pieces of software where in place,as Hermes e-IPBX is using dropbear as an ssh client/server.

One very little know fact about the ssh is that on top of providing secure logins to remote hosts, it can create secure tunnels between two points and forward ports between them.
Another even less known fact is that it can create reverse tunnels, where machine A which is behind a firewall/nat can be accessed by machine B without having to change anything in machine's A firewall/nat.
For this to work, machine B must have a publicly accessible ssh server.

It goes like this

Machine A initiated a reverse ssh tunnel connection to machines B ssh serv
er.

# ssh -fNR [bind_address:]port:host:hostport] [user@]hostname

Once this is done machine B initiates a LOCAL connection to the port machine A is using as forward.

# ssh localhost -p port

As example we want to access the target node (name: localhost) from our node (name: www.support-example.org). The port we want to access is port 22 and it will be accessible from our node at port 2222.

# ssh -fNR 2222:localhost:22 www.support-example.com

After that, the you are prompted password as usual. After successful login, the command quit but it will remains in background.To access the target node, use our node to access the forwarded port (2222). So let say, if you want to ssh into the machine (because we have forwarded ssh port), we can use this command

# ssh localhost -p 2222

That is all. You now have loged in to the remote machine.

We had this example tested using our Ubuntu desktops but when we tried to implemented to the Hermes e-IPBX a few problems come up.

First, dropbear requires slightly modified commands
so the

# ssh -fNR 2222:localhost:22 www.support-example.com

becomes

# ssh -f - N -R 2222:localhost:22 www.support-example.com

Second and most important, the moment we had machine's B 22 port open (the one with the publicly accessible ssh server) we received a number of brute force ssh password guessing attacks.
Normally this would not be much of a security problem (unless of course your root password is "sex" or "god" :) but it is both annoying having to switft over large logs with failed attempts and also could work as a potential DOS attack.

The good thing about this ssh brute force attacks is that in most cases are started by "script kiddies" and the only port they scan is 22.
So if you move your ssh server to another higher port the problem pretty much disappears.
Off course as an added protection to your extra-secure-ssh-password :) it would make sense to put the machine with the ssh server on the dmz zone of your network. In the case your extra-secure-ssh-password is not so secure or a security hole is found in your ssh server.

So assuming you move the ssh server to port 3333 the command on machine A should become

# ssh -p 3333 -f - N -R 2222:localhost:22 www.support-example.com

In a following post i'll show how to merge all the above with the asterisk dialplan and create a neat support feature.