tl;dr - Effectively the goal would be that if you grant someone access to a server via an overlay VPN that they can’t jump to other boxes on the same VLAN from it.
In VLOG Thursday 448 at 17:20 (link below), Tom addresses a question from Christopher Schlacta regarding overlay VPNs. He discusses a zero trust approach to managing permissions for devices connected to the overlay VPN.
While I understand the mechanics of this from a VPN perspective, I have concerns about the security implications when some of the servers connected to the VPN are on the same VLAN. Specifically, if a user gains access to one machine within the VLAN, they could potentially move laterally to other devices.
For example, consider a scenario where we have three database servers (DB 1, DB 2, and DB 3) and one replication server. Different users are granted access to DB 1, DB 2, or DB 3 for various purposes, including SSH access, while only I have access to the replication database. All these servers communicate over the same VLAN/subnet.
Given this setup, what strategies or best practices can be implemented to ensure that users with access to DB 1, DB 2, or DB 3 cannot access the replication database? How can we effectively enforce security measures to prevent unauthorized lateral movement within the VLAN while still allowing necessary access for legitimate users?
Would it be a good idea to firewall off the servers completely and re-do connections to only have access via the Overlay VPN, even the database connections with replication channels. Then have a “break glass” SSH option from an “admin” VM on the VLAN?
With overlay VPN setups you shold be using the overlay IP attached to the server, this would mean they are not on the same VLAN as the server, but only have access via the granted permissions in the overlay VPN and then only to the applications on the server they should have access too. Obviously if the server is some type of development server and you are granting SSH access to that server you will have to create further rules within the serve, have firewall rules on the adjacent servers, or put them on separate networks.
Ya, I think to fully use overlay VPNs as a zero trust setup you need to fully lock down the servers from all networks and only allow access via the overlay VPN. This way you can only possibly connect to the servers’ services via the overlay net, and it’s authorised and authenticated at that level.
I guess if you are only giving say MySQL service access on a particular server via the overlay then you don’t necessarily have to lock down the machines on the VLAN/subnet.
It’s an interesting concept nonetheless, especially when you can effectively place the servers anywhere or move them around after and still have access.
What about blocking admin access to the replication server via SSH? This is kind of an old school way of doing zero trust, but it basically does the same thing and only takes 5 minutes. Right?
I employed this setup for a similar situation to the one you describe. I had a bunch of servers in a vlan and one server in particular that had admin access via HTTPS. For whatever reason I felt the need to protect this authentication system from rogue servers in this vlan (probably out of boredom & paranoia), so I put a key-based SSH server in front of it. This obviously only works for containers with an init system, which was always my case.
Actually, I eventually did this in my phone vlan too. I certainly didn’t trust devices on that vlan, so I put my PBX admin authentication behind SSH. At first I had the PBX on another vlan so routing could filter it, but I moved it over to same broadcast domain to improve performance.
Ya, it’s definitely possible to lock down the server itself that way.
I was thinking having “everything” done via the overlay VPN would allow for a “single pane of glass” approach to connection and authorisation of all services globally. A bit like UniFi I guess.
At first pass I thought, yep, that makes sense.
But then I thought about my old setup and realized a third party single pane of glass for authentication wouldn’t have made much difference to me. My workstation with it’s LAN IP and SSH key already was my single pane of glass for zero trust authentication. I feel like I am relearning why I never got excited about this stuff when it first came out.
Maybe I’m wrong, feel free to correct me.
