SSH jump server access control?
-
@triple9 said in SSH jump server access control?:
@scottalanmiller Pete-S wants control once user is logged in or I misunderstood request? IPtables kicks in when user jumps to destination server.
Oh, are we thinking IPTables blocking OUTBOUND traffic from the Jump Server, so that a UID is present?
-
@Pete-S said in SSH jump server access control?:
The point of security measures is to give access only to what they need - least privilege. So to give jump box users access to the entire network makes no sense, unessesary risk.
I get that point, but in theory the limits on what they are allowed to access are already controlled by user level security, so the IP level security while not entirely pointless, should be essentially pointless. Access isn't granted to anything. IP tables is making "double sure" and I can appreciate "use all layers available to me" but it isn't like there is some access being taken away, right? They are already totally limited as to what they can access before doing this.
-
@Pete-S said in SSH jump server access control?:
I can't see how a VPN solution would be less secure than a ssh jump box. That makes zero sense to me. They are effectivly the same - encrypted links / tunnels. A ssh jump server would be more practical in a lot of cases though.
A VPN tunnels traffic without knowing what the traffic is. It can be limited to certain IPs, ports and so forth, but beyond that it's a blind tunnel. And it is direct, if there was to be a breach, it goes both directions in what we call "open air".
SSH with tunneling off is "closed air". There's never a time that the two endpoints communicate. Everything is done through a proxy. If there is a breach, it is between an end point and the jump box, not the two end points. So the jump box always represents an additional "firewall" type point of control and has more opportunity for tight security than most other points of access. So there is a lot more protection against a breach.
VPNs can, in theory, log all packets but that's very difficult to deal with. SSH can easily log all commands. There's a reason that the world's most secure environments use SSH in this way through jump boxes, and VPNs are banned in any high security environment unless it is purely for "additional" access control not "providing access" control.
The open window / closed window concept is huge. VPNs extend the LAN and any security is additional to limit had risky that is. SSH doesn't extend the LAN so all that extra security on the VPN is only to approach, but never reach, what SSH already does in this case (when tunneling is off, if tunneling is on, it's literally a VPN.)
-
@Pete-S said in SSH jump server access control?:
So the question is just how to restrict network access on a user by user basis. If you can't do it in the jump server directly, you could potentially have several jump servers for different users.
I think this is a factor of scale. Are we talking two users? Heck, yeah, two jump servers is SO easy. Are we talking 2,000 with a large degree of "everyone is unique", then ick, that's going to be a lot of work.
To do this, containers would be the way to go. LXC on Ubuntu as an example, super lean and other than consuming IPs it's essentially no overhead. You might just want to make one for every user, in fact.
-
I've seen a few different projects / services built around Apache Guacamole that might suit your needs.
Basically the user connects to the Guacamole / jump box but you would have to administratively create the "bookmarks" or connections that their user would be able to use from there.
For the life of me, I can't seem to find anything today, but unless I was imagining things I'd come across a couple of setups that could possibly meet your needs about a month or 2 ago.
-
Blocking by user sounds like a complete fucking mess.
Why not just add TOTP based 2FA to your
sshor something? It is available on pretty much everything.You have key based auth only access already right? How much cost are you wanting to add here? Versus how much actual risk?
I mean the only purpose of this is to protect from a compromised internal user that uses
ssh. The threat level should mean something extremely targeted is already the only credible attack vector. -
@JaredBusch said in SSH jump server access control?:
Blocking by user sounds like a complete fucking mess.
Why not just add TOTP based 2FA to your
sshor something? It is available on pretty much everything.You have key based auth only access already right? How much cost are you wanting to add here? Versus how much actual risk?
I mean the only purpose of this is to protect from a compromised internal user that uses
ssh. The threat level should mean something extremely targeted is already the only credible attack vector.A lot of threats are internal. But internal could also mean contractor or another external party. Or someone getting hold of their credentials, like in the uber attack (search "mfa fatigue").
It's very common to limit network access on a user basis, I just didn't know how it was done on an ssh jump server.
PS. I actually think outgoing access control can be done in the jump servers sshd_config directly. Keywords are ProxyJump, PermitOpen, Match on user and disable shell.
In theory the jump server can then only be used to jump to other servers and only the ones that are allowed for each user.
-
@Pete-S said in SSH jump server access control?:
It's very common to limit network access on a user basis, I just didn't know how it was done on an ssh jump server.
Not that common, even on Wall St. and Federal Government I've never seen it used. So much complication for essentially no value. Since you already limit by user, what additional benefit does it add? In theory, it's a MFA that says "X user will only exist at Y address" and yes, that's not a non-zero value. But it's a really low value. In the modern world, being able to limit users to a pre-determined set of network addresses AND correctly identifying those addresses (instead of identifying the jump server for example) is both impractical and ineffective. Exceptions exist, but it's... weird.
-
@Pete-S said in SSH jump server access control?:
PS. I actually think outgoing access control can be done in the jump servers sshd_config directly. Keywords are ProxyJump, PermitOpen, Match on user and disable shell.
That's possible, too. But outbound can be done at the firewall.
-
@scottalanmiller said in SSH jump server access control?:
@Pete-S said in SSH jump server access control?:
It's very common to limit network access on a user basis, I just didn't know how it was done on an ssh jump server.
Not that common, even on Wall St. and Federal Government I've never seen it used. So much complication for essentially no value. Since you already limit by user, what additional benefit does it add? In theory, it's a MFA that says "X user will only exist at Y address" and yes, that's not a non-zero value. But it's a really low value. In the modern world, being able to limit users to a pre-determined set of network addresses AND correctly identifying those addresses (instead of identifying the jump server for example) is both impractical and ineffective. Exceptions exist, but it's... weird.
Nowadays we see it all the time when given access to enterprise server infrastructure. Everything is completely locked down to just the IPs and ports needed. That wasn't the case say 5-6 years ago.
So it seems standard to me, but who knows? They probably have it in their admin tools so no extra work needed. I highly doubt there is any manual work involved.
-
@Pete-S said in SSH jump server access control?:
Nowadays we see it all the time when given access to enterprise server infrastructure. Everything is completely locked down to just the IPs and ports needed. That wasn't the case say 5-6 years ago.
We see that as a standard limitation by company, not by user, and "to" site, not to resource within a site.
So for example, NTG's Jump IP address is provided to customers who allow access to the entry point at the site (outside firewall) to a resource only from that IP address.
But they don't check users at that time, they check user ID at a different time (since they don't know the user till after the connection is made) and it's not such a wild pool.
-
@Pete-S said in SSH jump server access control?:
So it seems standard to me, but who knows? They probably have it in their admin tools so no extra work needed. I highly doubt there is any manual work involved.
Seems like their must be. Somehow you have to track every potential IP of every potential user and map that to resources inside the network which would likely require all kinds of special code on every service. But it also has to be done BEFORE access to exist. HOW do they do it, I wonder?
Dollars to donuts most vendors claiming this don't actually do it and no one knows how to check so they don't realize it isn't happening and so there are lots of people verifying it and so it seems reasonable that it's happening. But I bet it isn't.
-
The challenge is really that you have to identify a person on the network separately from their identity to applications. Generally networks are not user aware.
-
@scottalanmiller said in SSH jump server access control?:
The challenge is really that you have to identify a person on the network separately from their identity to applications. Generally networks are not user aware.
I believe the user-based network restrictions only extends to the target server(s). So outbound from the jump server. (As you said one jump server / IP per user and then firewalled off would be one way to do it).
So someone could potentially move laterally efter they have logged in to the target server. But other servers will probably only accept connections from jump servers so it would be hard. Which is on purpose of course.
-
@Pete-S said in SSH jump server access control?:
So someone could potentially move laterally efter they have logged in to the target server. But other servers will probably only accept connections from jump servers so it would be hard. Which is on purpose of course.
If that's the limitation you/they are looking for, outside edge IP detection to network access as a whole, then it's a totally different game and I think it makes total sense. THAT you can control with SSH itself no problem.
-
-
