Remember the old saying “What goes up must come down”, referring to the gravitational pull? Well, I have a similar saying for firewalls: What goes out can come back in. This is a cool SSH trick that will stump even the most seasoned network administrators.
The trick is port forwarding. The idea is that a box will be listening for connections on a port that you specify. If a connection is made, the packets are then transferred through the SSH connection to the box at the other end on a different port that you have specified. So, the obvious is, you need access to an SSH server to make this possible. Let’s take a specific example.
I’m at work. The company mail server is not accessible from the Internet, so when I get home, I can’t read my corporate mail. One specific day during the week, however, I need access. I try to convince the network administrator to punch a hole in the firewall, or at least give me VPN access, but nothing. No ports open for tightest security is his approach. So, seeing as though I have access to an SSH server at home, I open an outbound port that will allow me to connect back in. In otherwords, piggy-backing off of the SSH connection to my home SSH server. I issue the following command from work, just before I leave:
ssh -R 22225:mail.company.com:25 -fN ssh.home.com
What is this saying exactly? It’s saying that the SSH server on ssh.home.com will be listening for mail traffic on port 22225. When a connection is made, the packets will be forwarded through the SSH connection to mail.company.com in the corporate office on port 25. As far as the connection is concerned, mail.company.com received a port 25 packet as if it came from the box internally on the corporate LAN. All I need to do, is launch my favorite email client that supports TCP proxies, and connect to ssh.home.com on port 22225 to make the connection. Simple as pie.
Let’s look at another example:
ssh -R 22222:foo.example.com:22 -fN ssh.home.com
This example is saying that the SSH server on ssh.home.com will be listening for SSH traffic on port 22222. If a connection is made, the packets will be forwarded through the SSH connection to foo.example.com in the corporate office on port 22. This is a great way to get SSH access to machines in the office that are not accessible to the Internet.
Cool, eh? Who would’ve thought that the developers of the most secure-by-default Unix, OpenBSD, would be providing me with simple tools to bypass firewalls?
Now, the question remains, what about the firewall? My only response- what about it? If you have an outbound Internet connection, your only task may be to find out what port is open for the outbound connections. If you have access to an SSH server that you can configure, then change the port on the SSH box to match your corporate outbound port, and you’ve effectively bypassed any and all firewalls that may be in place, both out an in. The only way, the ONLY way you can keep me from bypassing your firewall is to completely cut outbound connections to the Inertnet. Completely, and totally isolate the corporate network. Then, you have a impenetrable firewall.
So, as I mentioned earlier, “What goes out can come back in”.