A less sensational title for this post would have been “SSH Remote Forwarding,” but that’s not nearly as fun.
I used to be responsible for one of the few entry points into a global network. The company had actual manufacturing secrets — their products included various machines of war. We had internal firewalls to protect sites from each other, even when the site didn’t have Internet access. All Internet connections had to go through proxies. We did not allow external DNS to reach the desktop. If you typed ping google.com on your desktop, you’d get a “host unknown” error. The company had invested in VPN technology that blocked all but approved clients, and only permitted clients on the approved list if they were running the approved anti-virus scanners and other security software.
I was frequently asked to open direct Internal access for random applications. Most of these requests were rejected unless the user could explain what they wanted and why it was business-critical. Some of the people who asked were technically literate, and became indignant when I rejected their request for outbound SSH to external servers or equipment. After all, SSH is “Secure Shell.” It says secure RIGHT IN THE NAME. They just want to check their personal email. How could I possibly reject this eminently sensible request?
I’ve since had left this job, but I’ve had the same discussion more than once afterwards.
Most SSH users have no idea of SSH’s flexibility. Arbitrary SSH connections are a nightmare for maintaining any sort of secure information perimeter. Remote port forwarding is one reason why.
When most people mention SSH port forwarding, they’re thinking of local port forwarding. You forward a TCP port on your client to a TCP port on the SSH server. This lets you, say, tunnel SMTP inside SSH, so your client can relay mail through your server without any complicated Sendmail rules.
Remote forwarding lets you do the reverse: forward a TCP port on the SSH server to a TCP port on the SSH client.
Suppose I permit a user to SSH to an external server. The desktop is behind a NAT. There are no port mappings from the NAT to the desktop; it has the same connectivity you might give a secretary, except for the outbound SSH access to a single host. That user sets up remote port forwarding from a TCP port attached to the server’s public IP to the client’s SSH daemon. I’m using an OpenBSD desktop, but you can get SSH clients for most other operating systems, including Windows. I’m using OpenSSH, of course, but most clients (including PuTTY) does remote port forwarding.
To do remote port forwarding in OpenSSH, run:
$ ssh -R remoteIP:remoteport:localIP:localport hostname
If you don’t specify an IP address to attach to the SSH server, the server attaches to 127.0.0.1. (You can also skip the first colon in this case.)
My desktop runs sshd. I want to attach port 2222 on the SSH server pride.blackhelicopters.org to port 22 on my SSH client using remote port forwarding.
client$ ssh -R 2222:localhost:22 pride
I leave this connection up and go home. Perhaps I run top in the command window, to prevent the SSH session from timing out at the corporate firewall. Now at home, I log into the SSH server and run:
pride$ ssh -p 2222 localhost
My SSH request to the local machine will get tunneled inside the existing SSH connection out of the network. I will get a logon prompt for my client inside the secure network. When I can access one supposedly secure machine, I can start ripping data out of the local file servers and maybe even access other internal sites. All of the trouble the company expended to prevent unauthorized access is now moot.
If you attach the remote port forwarding to the server’s public IP, then anyone on the Internet can attack your desktop’s SSH daemon. People are attacking SSH servers, even on odd ports.
Of course, remote port forwarding in this environment would violate company policy. If caught, you’d lose your job. But to catch this abuse, the network administrator would need to realize that large data transfers were taking place in off hours over these limited-use channels. You could, say, use flow analysis to write automated reports that notice and alarm when large amounts of traffic pass over these “rarely-used” channels. You’d have to be a real bastard to think of that. But the reports are easy to write, and the look on the abuser’s face when you confront them with graphs and numbers is priceless.
The point is, the next time your employer’s network administrator rejects your sensible request for SSH access to your home server, don’t be too hard on the poor slob.
Want more SSH fun? Check out the book recommended by the OpenSSH project, SSH Mastery.
I feel your pain, but you probably have not approached the issue correctly. I do agree that sshd is a double edge sword, so the decision should not be taken lightly to allow forwarding. However, there are sshd versions that audit every action of the ssh user. Check out http://code.google.com/p/auditing-sshd/ For a version that will audit just about every action. If you use a version like this and you inform the users of the impacts, I think you will find them behaving apropriately. If not, you will have all the data you need to call in Donald Trump to tell them “Your Fired”!!!!!
Answer me a question, is there anyway it can be block?
For examples, normally all de high ports are acessible, but when this ports are block, there’s noway to do this, right?
Thanks
Thanks for posting this. Googling ‘dyanmic forwarding ssh’ brought me here, and I was working on something that would have utilized forwarding to access isolated networks. I proceeded to review company policy which, albeit vague, would probably not take too kindly to this. You may have saved my job =)
Always happy to help.