Tuesday, 10 January 2012

SSH Port Forwarding

WAY back in 1998-2002 when I was with DeMorgan still, we had a project with F-Secure in Australia and a few overseas people (it never got anywhere, but it could have been great). The idea was to have an end to end secure tunnel, malware detection and control system. Basically much as NAP in windows does now.

The project was called “Triple-S” and “BlackNet”. It was under the radar fairly well, but was listed with the Australian Government for research and development funding. A small deployment of the concept was used with CUSCAL and the ASX.

The idea and concept was a little advanced for the time and many in F-Secure that I spoke to (mostly non-technical people) saw it as a threat. They wanted the sales leads but not the concept. This is a reason I like SourceFire at the moment, they have a great integrated anti-malware and IDS approach .
I guess a little of why this failed was the use of third party products to make things better. We used Snort as an IDS and integrated this and a couple other products. Back then, F-Secure could have bought out SNORT for a small stock swap. Now…

As I have said, it is not always easy getting people to see what the future can bring.

Well, here is a little from the project, just a snippet of SSH forwarding (originally using F-Secure SSH). This is now completed using open-ssh. The project involved automating SSH tunnels for Windows with software to see if the host was running the latest anti-malware definitions and was patched. All this is of course achievable using NAP in a Windows domain now. I have modified the post below using this material.

We can use Port forwarding, or tunneling, as a means to forward otherwise insecure TCP traffic through SSH Secure Shell. Using an SSH tunnel, the host can communicate securely using common unprotected protocols (these can include POP3, SMTP, SMB and HTTP). That is, connections and communications that would otherwise be send across insecure channels. Through encryption, the tunnel allows us to ensure that all traffic is protected from eavesdropping and interception.
 
Figure: Making insecure TCP connections secure using channels inside the encrypted ssh2 tunnel

SSH allows for two varieties of port forwarding. These are:

  • local tunneling ( aka an outgoing tunnel), and
  • remote forwarding (aka an incoming tunnel).
Local port forwarding forwards traffic coming to a local port to a specified remote port.
As an example, we could send the following command to set a local forwarder:
ssh -L [local_port:remote_port] user@remote
or…
ssh -L [bind_address:]local_port:remote_host:remote_port] user@remote

This command will send any (and all) traffic destined for the port set as local_port on the local host and it will forward this to the port we have set as remote_port on the remote host.

Remote port forwarding does the opposite to local forwarding. That is, remote forwarding forwards any traffic that is destined for a remote port to be sent to specified local port.

As an example, we could use the following command:

ssh -R [remote_port:local_port] user@remote

or…

ssh -R [bind_address:]remote_port:host:local_port] user@remote 

In this example, any traffic destined to go to the port defined as remote_port on the remote host will be forwarded to the port defined on the local host by the value local_port.

In an event where there are three (3) or more hosts ( we will call these client, sshdserver, and appserver). We can forward the traffic securely taking the traffic coming to client's port x to appserver's port y. Heree we create a gateway as we you connect through the system sshdserver.

The connection between client and sshdserver is secure and that between the systems sshdserver and appserver remains as clear text and can be monitored and scanned using an IDS.

In order to create this type of tunnel, we can issue the following command on client:

ssh -L x:appserver:y user@sshdserver





Figure : Forwarding to a third host

These days of course, we have IPSec (and also SSL/TLS) so these types of SSH sessions are becoming less common. They do still offer an administrator an effective (and simple) means of securely connecting to remote servers and should not be discounted fully yet.

No comments: