Hacker News new | ask | show | jobs
by kentrf 1255 days ago
This.

Port forwarding goes both ways.

I may, or may not, have used ssh forwarding and reversing forwarding to create a shadow IT tunnel(s) between my home and work when VPN was acting up.

Also, SOCKS proxy is very useful if you can puncture a hole home and your work requires a proxy to access the World Wide Web from the office location.

2 comments

You were one of the reasons I wanted to block outbound non-web traffic from clients at the perimeter when I was a CISO. Unfortunate for me, but I guess fortunate for the developers, who wanted to SSH home, I got vetoed.
Networks with outbound SSH access blocked are depressing. It‘s not that hard (but still annoying) to tunnel through them via HTTPS or similar.
I do understand the pain when it's a public one, but in corporate land it really does make big difference for security.

If you have the funds the Deep Packet Inspection is a big way to defeat attempts to tunnel through HTTPS, DNS, or the like.

Only if you SSL inspect which is a god awful maintenance/support burden even if you already have full control of every system which accesses the web from your network (pretty much excluding any usable guest access otherwise that becomes the next hole). There are definitely places that level of security make sense to maintain but typically as a requirement not something someone wants to do.

Even then you haven’t really solved that particular issue as it’s a people problem not a tech problem. It’s like trying to stop an employee from robbing the bank by getting a thicker vault door in that it’s just not the right type of incentive/disincentive to make an impact.

There are also countless ways to evade this: iodide (tunnel over dns), encapsulating encryped traffic in non-encrypted http, etc.

DPI just makes it harder, so does terminating ssl earlier, or blocking outbound ports.

> in corporate land it really does make big difference for security.

When measuring security by "number of boxes checked", yes. Unfortunately, these boxes are often overly generic, years too old, or both.

> If you have the funds the Deep Packet Inspection is a big way to defeat attempts to tunnel through HTTPS, DNS, or the like.

What's there to inspect (unless you are decrypting all TLS in a middlebox with a root CA trusted by all clients)? How would you distinguish a "normal" WebSocket connection (as used by many sites these days) from a tunneled SSH connection, for example?

If you generally want to allow your users to reach the broader public internet (or even just web), this approach seems completely futile.

A cool feature in recent ssh is SOCKS5 remote forwarding.

Doing something like this from host B:

   ssh -N -R 1080 user@A
Will allow a browser running on A access network through a SOCKS5 proxy on B while setting the proxy as localhost:1080.