At a former company, we needed to connect to customer's databases from our service. Many were understandably cagey about opening a public hole in their firewall to their DB, even if it's just for our single egress IP.
Our solution was to run a public host (the Reverse Bastion) that would, upon user request, generate a shell-less linux account for the user and install their public key. The user was then given an SSH command to run from inside their corp network that would connect to Reverse Bastion and establish a reverse tunnel pointing at their database. That way we could "connect" to that user's dedicated port on the Reverse Bastion and our traffic would traverse the tunnel and pop out inside their network, bound for their database. Since it's all TCP tunneling, JDBC drivers had no idea they were hopscotching around networks and did DB queries like usual. As long as you have the user accounts totally locked down and people's port assignments locked to their users via iptables, it was a walled (tunneled?) garden.
From experience I can tell you that such a setup is very brittle and will fail the moment the one employee of that customer who knows about this is on vacation or working at a different place.
The only thing that works reliably is a proper VPN (configured for machine to machine access, not based on username/password which has the same brittleness issue) which these days is available at every customer's site.
I agree with the reliability issue, but I can't stop myself from mentioning that I had an autossh connection set up on systemd that worked for an impossible five years until our support contract expired.
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.
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.
> 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.
This is a handy resource, SSH tunnels are something that I always find easier to grasp when displayed visually.
I use a reverse SSH tunnel to access my home network when traveling.
Ex:
- [Machine-A (on my LAN, behind NAT, with a dynamic IP address)] maintains a long lived SSH connection to [Machine-B (a VPS with a public IP)] with a reverse tunnel configuration.
- I can then SSH into Machine-B and follow the tunnel back into Machine-A, and from there access the rest of my home network.
It works pretty well. I can access files on my NAS and check on my Raspberry Pi cameras without needing to put either on "the cloud". Although I have to admit I always have to pull up a resource like the one in OP whenever I want to setup something like this, I've never learned it by heart and always need a refresher.
FWIW, none of this made any sense to me until I mentally ditched the concept of "tunnels." The metaphor was too physical for me?
Personally, the metaphor that made it work for me was "postcards going to a motel." As in AHA, when I'm doing SSH Tunnelling, Room 22 is the only one open and receiving mail, all the other rooms are locked. Now, there might be a website behind the door on locked room 443, and I can send my postcards to room 22 with the instructions to send them on over to 443 once they get there, and over at the motel they'll also know to do the reverse.
You wouldn't believe how difficult it is to teach the concept of tunneling to some students. It made my brain hurt at times. I guess once you get it you just get it.
Actually the concept is easy as those diagrams demostrate. It's the syntax in ssh that's hard to grasp. They should keep the current one forever but deprecate it. Then add a parallel syntax easier to understand. Example
ssh connect
remote myserver:80
to local 172.27.17.2:8080
one-way
The syntax should totally do away with the concept of tunneling, connecting ports is easier to grasp IMHO.
BTW I'm not sure that the "one-way" argument is really needed.
Your machine can also act as a bastion to a remote resource for the rest of your network through local port forwarding, e.g. -L 0.0.0.0:8080:localhost:8080
Then any local machine can e.g. curl yourip:8080 and the request will go through your machine, over the SSH tunnel, to the remote machine
Anyone know of an open source solution that is the same/similar to thing that some vendors build into their product to create “support tunnel”? Usually, it’s a toggle in the settings that establishes a connection that a support person can use to connect back to the appliance or virtual appliance. I imagine it’s a reverse tunnel or similar to one. However, the solution would need to pop up on a dashboard or screen so that support person knows it’s active and how to connect to it.
I am not seeing dynamic and the newish reverse dynamic tunnels here which are just setting up a socks proxy to access any network the client or server can access.
I wonder if it makes sense from the security perspective to access applications using ssh port forwarding, rather than opening ports for the applications?
Our solution was to run a public host (the Reverse Bastion) that would, upon user request, generate a shell-less linux account for the user and install their public key. The user was then given an SSH command to run from inside their corp network that would connect to Reverse Bastion and establish a reverse tunnel pointing at their database. That way we could "connect" to that user's dedicated port on the Reverse Bastion and our traffic would traverse the tunnel and pop out inside their network, bound for their database. Since it's all TCP tunneling, JDBC drivers had no idea they were hopscotching around networks and did DB queries like usual. As long as you have the user accounts totally locked down and people's port assignments locked to their users via iptables, it was a walled (tunneled?) garden.