Any Safe Port in an Internet Packet Storm
SSH also offers another type of forwarding: port forwarding. SSH’s inventor, Tatu Ylönen, soon realized that the SSH tunnel might help to improve the security of other applications as well as end the risks of FTP, Telnet, rexec, rcp, rsh, and rlogin. If only there were a way to cram an application’s traffic into the SSH tunnel....
There are two types of port forwarding:
- Local forwarding. Allows the client to set up a
"hijacker" process. This will intercept your PC’s traffic and
shove it into the encrypted tunnel. The standard argument for local forwarding
is the use of POP3 (Post Office Protocol), a service that uses port 110/TCP.
Normally, this service sucks because it passes the ID and password in the clear.
That’s bad. Even worse, people set their POP3 clients to hammer the server
for new mail every five minutes or so. This makes POP3 a hacker favorite because
there are so many chances to grab that password.
But through the magic of local forwarding, I can use the SSH tunnel. POP3 traffic will go from my PC to the POP3 server with encryption. Without drowning a security article in SSH configuration details, here’s an abbreviated version of the process: The client configuration statements have SSH listening on the local host adapter on any port the user chooses. The user statement instructs the listener to grab all port 110 traffic and cram it into the SSH tunnel. On the other end, the SSH server honors the user’s configuration and sends the POP3 traffic to the destination the user dictates, on the POP3 port.
- Remote forwarding. This type of port forwarding has the user’s SSH client acting on the server’s behalf. In this case, those forwarding configuration statements have the client receive traffic on a non-privileged port coming in from the tunnel. It then places the traffic into the correct port, per the SSH client configuration statement, and sends it to the destination the user chooses.
Advantages of Port Forwarding
What is the practical, positive impact of these two capabilities?
Consider the needs of the system administrator (let’s call her Jo) who must patch servers in your company’s DMZ. Maybe you are the mean, rotten, lowlife firewall administrator who refuses to allow Internet-facing machines a direct, ad hoc connection to the intranet’s patching servers? What’s Jo to do? Use SSH port forwarding.
Assume that Jo’s client is Box A, the DMZ server is Box D, and the patching server is Box P. Here’s how our clever server administrator sets up SSH port forwarding:
- Jo creates a remote forwarding statement on Box A that allows traffic coming from port 6789 to be translated to port 22 and then be shuttled to Box P.
- Using SSH, Jo connects to Box D.
- Once at Box D, she creates a local forwarding statement to cram all port 22 traffic to the patching server into port 6789. Therefore, a script pulling files from the intranet patching server will go to port 6789, into the tunnel, and to Box A. At Box A, the remote forwarding statement will take the traffic arriving at 6789 and send it over port 22 to the patching server, Box P.
- Now that the tunnel is built, Jo sets up patching scripts launched on Box A to use SSH to send the processing to Box D for execution. As these scripts execute, commands will access the patching server as if it’s directly connectible. So the DMZ box gets patches and can kick off commands against the patching server itself. The patching server for the entire company. The one safe source for binaries for all servers and client PCs. That one.
At this point, many of you firewall administrators are shaking your heads. How is this possible? Go ahead and review your logs. The tunnel appears to be one outbound connection initiated from an internal "trusted" host to a host with less trust. This seems secure. The encryption certainly keeps hackers, thieves, and firewall and security administrators from determining just what was done and with whose account.