Aspera heavily leverages the SecureSHell (ssh) technology, developed to access Unix and Linux systems, to provide secure communications and authentication for session initiation. Along with core protocol functionality, ssh can be used to provide secure communication for other TCP traffic, like that used by Aspera Central's SOAP service. This tutorial will provide the basic understanding of SSH tunnels needed to setup a tunnel. This article will also describe the security implications of running tunnels and how to shut them down.
While tunnel use in Aspera software is done automatically in Console 1.5 and above, it is useful to know these concepts for earlier Console deployments, and to understand the technologies deployed on your network. For simplicity, these examples will assume a linux server, but the examples can easily be ported to a Windows system as well.
Manually creating an SSH tunnel
Setting up a tunnel is quite easy. From any command window a user can use a command like the following to create the tunnel:
$ ssh -L 40001:localhost:40001 someuser@somehost
Once the password has been entered for the someuseruser on the somehost server the tunnel is setup. What does this command do and how does a tunnel work?
To answer this question we need to understand what we are trying to achieve. In a normal connection a server connects to an IP address and the port the service is running on. This combination ofIP:port is called a socket and represents a network endpoint of some type (local or remote); this info is important later.
In a way, a tunnel is exactly what the name implies.ssh sets up an encrypted path between two systems -- a connection to the remote server that takes in data on one end, and ssh encrypts it as it travels over an unprotected medium to the other side. Alone this path is useless. The mechanism ssh uses to provide access to this is to create new sockets at each end of the tunnel, which an application can use to access the TCP service. These new sockets replace the the old sockets one would normally use.
Tunnels secure data, but also allow the user to "punch holes" in networks that can be used to access restricted services.
Tunnels used by Aspera
The most common use of SSH tunnels with Aspera software is theAspera Central service. Central providesSOAP services on port 40001. This SOAPdata is not natively encrypted, so transmission over an insecure medium is done through the use of tunnels. This is done automatically in Console 1.5 and above, but in essence what happens is the following:
- On the client side: Since traffic to the localhost does not pass through the unsecured network,
sshis used to connect to the remote/server host via port 22, and a tunnel is setup bound to a local port. Port 50000 will be used for uniqueness and clarity of example. On the remote end the tunnel will funnel traffic to the remote end's port 40001.
- The server end does not require any changes to accommodate this.
- The client service (like a SOAP consumer), instead of usingremote_IP:40001, will attempt connections tolocalhost:50000.
As shown in the above example, this tunnel is done, using the example ports, like so:
$ ssh -L 50000:localhost:40001 user@remote_ip
you will know the tunnel works by using
netstat and filtering out for port 50000 on the side that created the tunnel:
$ netstat -an | grep 50000
tcp4 0 0 127.0.0.1.50000 *.* LISTEN
tcp6 0 0 ::1.50000 *.* LISTEN
The service that needs to use the tunnel can now make connections to the local socket (on port 50000).
It should also be noted the
-L option is what sets up the local socket. There is a corresponding
-Roption to setup sockets on the remote host as well. The concepts are the same, but relevant depending on access to the system.
The Security Implications of SSH Tunnels
While tunnels can be useful, as evidenced in how Aspera uses them, it should be apparent that they also pose security problems. By providing a channel that can effectively bypass normal firewall protections, it is easy for an unscrupulous user to setup back-channels that are not monitored. Another thing to note: while the examples shown use
localhost, tunnels can also be bound to public interfaces, providing another avenue of abuse.
Securing your SSH Server
SSH tunneling can open up your system to many security problems if some thought and sane defaults are not put in place. Namely, the
sshd configuration (controlled by
/etc/ssh/sshd_config) should employ a "default deny" stance for allowing SSH tunnels. The general method for setting user level restrictions work on OpenSSH 4.4p1 and above. The specific steps outlined here were tested on OpenSSH 5.3p1. To test your version, use the following command:
# ssh -v
OpenSSH_5.3p1, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-e escape_char] [-F configfile]
[-i identity_file] [-L [bind_address:]port:host:hostport]
[-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
[-R [bind_address:]port:host:hostport] [-S ctl_path]
[-w local_tun[:remote_tun]] [user@]hostname [command]
To setup a default deny configuration, edit to have values like below:
Match User asperatunnel
As can be seen in the example, TCP Forwarding (aka tunneling) is off in the global config. The
Match statement then says for user "asperatunnel" enable tunneling, force use of the
aspshell, and also only allow localhost binding to the desired port (40001).
If you have an old version of OpenSSH (Centos/RedHat 5.3 uses version 4.3p2) you should upgrade from source or check with your Linux distribution for details on how to get a newer OpenSSH portable.
This just scratches the surface of what can be done with tunnels. A simple Google search for any of these topics can show a wealth of examples.