Image of the glider from the Game of Life by John Conway
Skip to content

What Goes Out Can Come Back In

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".

{ 13 } Comments

  1. Asa using Firefox 3.0b5 on GNU/Linux | June 5, 2008 at 8:43 am | Permalink

    SSH is a nice way to get VNC access to your computer at home too. You probably have a router/firewall and you've opened port 22 for ssh. If you enable Remote Desktop in Ubuntu you can run "ssh -L 5910:localhost:5900 -fN ssh.home.com" from work to create a "forward connection" then you can run vnc and connect to "localhost:10", it will be forwarded over the SSH and connect to your desktop at home. I wrote some instructions for a friend of mine to do this from Windows or Linux. http://docs.google.com/Doc?id=ddv9rsfd_34dcs84p5d

  2. oliver using Firefox 3.0 on GNU/Linux | June 5, 2008 at 9:52 am | Permalink

    Neat, but: what would the admins say if they knew you made your home PC (not under corporate supervision, maybe malware-infested, on a LAN with other malware-infected systems, whatever) connect to the non-public mail server, probably violating company rules... Uh-oh...

    Seriously, I think there's a limit to how far one should go. When we had an internet-visible web mail access here, I sometimes used it, effectively working in my spare time. But when it was decided that the web interface must be shut down, it seemed weird to me to hack around these limitations.

  3. volksman using Firefox 3.0b5 on GNU/Linux | June 5, 2008 at 10:48 am | Permalink

    Hahah...Yeah I've been using this for years...local and remote. Recently the company I work for decided to stop all access to facebook and youtube. While I don't facebook I do check out a fair bit of Youtube vids throughout the day (I mean cammon! how am I supposed to get rick rolled at work!).

    So I setup a dynamic tunnel to use as a socks proxy and FoxyProxy so FF will only use the proxy with the sites I tell it (IE the sites my employer blocks):

    ssh -D myinternalipathome:8080 -fN home.mymachine.com

    Tell foxyproxy to use socks proxy on port 8080 (localhost) and presto; Firewall restrictions removed.

    My boss caught me on Youtube once and told me I could get fired for breaking the rules. I told him if I didn't know how to circumvent any firewall policy they put in place then I shouldn't have my job. He laughed and turned away and I've never heard about it since. ;)

    Happy firewall avoidance!

  4. Lonnie Olson using Firefox 3.0b5 on GNU/Linux | June 5, 2008 at 11:01 am | Permalink

    I thought I would voice my opinion as a corporate sysadmin.

    There are two main reasons for preventing outside access to mail. Traffic snooping, and external attacks. Your method is nice because it still prevents snooping due to the SSH encryption, and as long as you don't add any other options (like GatewayPorts and a bind_address) external attacks are still prevented, because the forwarded port only listens on localhost.

    If your company sysadmin had a problem with what you are doing, he couldn't technically block you, but he certainly can get disciplinary action taken against you. Be careful.

    The only option your sysadmin has to prevent both attack, and provide access to the outside is a VPN. Most companies will grant VPN access if it is deemed good for business reasons, usually with manager or above approval.

    I would suggest you be careful about what you do since you *are* breaking the rules, and corporate sysadmins can be spiteful at times. :)

  5. Jason using Firefox 3.0 on Windows Vista | June 5, 2008 at 5:49 pm | Permalink

    Don't let the BOFH catch you doing this :).

  6. David using SeaMonkey 1.1.9 on GNU/Linux | June 5, 2008 at 6:57 pm | Permalink

    Almost exclusively, I forward ports on demand by type something like "~C-L5901:mybox:5901" in an SSH session anytime after pressing the return key. Remote ports available that way, too.

  7. Aaron using Firefox 3.0 on GNU/Linux 64 bits | June 5, 2008 at 7:57 pm | Permalink

    ALL: Of course you should always get system administrator permission first before bypassing a firewall. However, if you didn't sign any computer usage policies, then you have a lot of give legally. Unfortunately, I've worked in too many environments where the IT administrator doesn't have a clue. Of course, it only takes once to ruin it for everybody. I'm certainly not condoning the use of bypassing firewalls, and getting fired over it. Rather, I'm just showing you what you can do given a set of freely available tools and little effort.

  8. Mike using Firefox 2.0.0.14 on Mac OS | June 7, 2008 at 3:16 pm | Permalink

    For me, if I'm in control of a network and had fire/hire abilities I would just fire irresponsible workers instead of putting asinine rules in place. If people aren't doing their jobs they should be fired, a question of some sort of measured productivity. It shouldn't be a question of appearances, what websites people visit during the day, etc.

    But of course we all know that's not how most companies run.

  9. Someone using Minefield 3.0pre on Mac OS | June 7, 2008 at 7:14 pm | Permalink

    There are many ways to block this. Application Firewalls (PF for example) or a simple IPS setup. While most people don't bother it is blockable just like many other methods to punching holes in firewalls.

  10. Aaron using Firefox 3.0 on GNU/Linux 64 bits | June 7, 2008 at 10:13 pm | Permalink

    @Mike- It's not whether employees are working or not, but whether or not they can bypass your corporate firewall from home to get access to the internal email or web server. We're not talking local port forwarding here- the ability to encrypt all TCP connections, so your boss doesn't know what you're doing, but remote forwarding- being able to get in the network.

    @Someone- As long as I can sniff an outbound port, your firewall is worthless. Application firewalls won't do anything here, unless of course you block all outbound encrypted traffic, but we all know that's the draconian. The *only* way to keep me from bypassing your firewall, is to *completely* cut Internet access.

  11. My name using Firefox 3.0 on GNU/Linux | July 6, 2008 at 4:22 am | Permalink

    I'm not very comfortable with calling this "bypassing the firewall". If the firewall allows me only outgoing access on port 80, fine, I'll use only that. No bypassing. I'm using what I'm allowed to use.

    Though yes, I also see the reason behind calling it bypassing. :-)

    -a big fan of ssh -D, -L, and -R

  12. numerodix using Shiretoko 3.5.2 on Ubuntu | August 15, 2009 at 4:23 am | Permalink

    This is soooo cool! I never knew you could do this with ssh.

  13. Saul using Firefox 3.5.8 on Windows 7 | February 22, 2010 at 12:06 pm | Permalink

    In response to point (9), even application firewalls have limitations and are easily circumvented - the use of a tool such as proxytunnel (http://proxytunnel.sourceforge.net/ & http://dag.wieers.com/howto/ssh-http-tunneling/) allows your SSH tunnels to be SSL-wrapped and become indistinguishable from normal HTTPS traffic no matter how well it is inspected (after all HTTPS is by design inpenetrable).

    As an admin unless you're going to block access to all external sites by default and operate a whitelist to define exactly what users can gain access to your firewall is completely irrelevant to anyone who knows what they're doing. Even with a policy as hard-nosed as this, it's a trviality for someone with a bit of web server knowledge to setup a site on their home/VPS system which looks like a work-related help site and have it added to the allowable sites and you're back to square one - what goes out can come back in. I know because I've done it.

    Personally I feel that effective education as to how much you'll tolerate users bending the rules is far better than draconian measures like restricting site access etc. I've pen-tested secuity in companies and exploited things like this and priv escalation to get root access on prod servers from outside of their firewall in less time than it'd take them to process a real user access request. Sad but true.

{ 1 } Trackback

  1. [...] What Goes Out Can Come Back In -- SSH tricks [...]

Post a Comment

Your email is never published nor shared.

Switch to our mobile site