SSH jump server access control?
-
If you REALLY want to do user IP limits FROM the jump machine....
Then the only option is to completely restrict essentially everything happening on the jump box and write your own software that is the only thing allowed to run and that software will track Users to IPs and a table of who is allowed to do what from where and dole out access based on that system. I think this makes zero sense, but it is the only means of accomplishing what I think is the spirit of the original statement, but is world's beyond what is actually there now.
-
@scottalanmiller said in SSH jump server access control?:
@Pete-S said in SSH jump server access control?:
Or is there a possibility to limit network access depending on the user account as well?
This is complex because in the case of a jump box, everyone's IP is the same... it's the IP of the jump box. The source of the jump is unknown to anything after the jump. That's part of the point to give everyone the same IP address so that you can limit ALL connections to that one IP (or set of IPs.)
The VPN approach is far less secure. The jump box would already be more secure than the VPN with IP restrictions. In that spirit, yes, you can restrict anything to the IP of the user and meet the stated requirement (assuming it's a political thing) AND increase security while doing so.
Weird and clearly not what people mean, but so often security "rules" are made without any security in mind and that would apply here.
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 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.
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.
-
@scottalanmiller Pete-S wants control once user is logged in or I misunderstood request? IPtables kicks in when user jumps to destination server.
-
@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.
Yeah, I want to control what IPs and ports the user is allowed to access once logged in.
I don't want unautherized users to be able access anything except what they are allowed to.
PS. Had a look at
--uid-owneron iptables and it seems like it could be used to limit network access on a user by user basis.We actually use debian and iptables is now replaced by nftables, but I'm sure it has similar capabilities.
-
@scottalanmiller said in SSH jump server access control?:
Using /etc/ssh/sshd_config you can limit a user's access TO the jump system in the first place before they can access anything on the network.
I'll have a closer look at the config file.
I know you can disable tunneling and such things. And I want limits on who is allowed to use the jump server.
-
I also came across Teleport which is especially intended as a jump server.
I've seen it before but never had closer look.
-
@Pete-S said in SSH jump server access control?:
@scottalanmiller said in SSH jump server access control?:
Using /etc/ssh/sshd_config you can limit a user's access TO the jump system in the first place before they can access anything on the network.
I'll have a closer look at the config file.
I know you can disable tunneling and such things. And I want limits on who is allowed to use the jump server.
Yes, lots of things to disable for sure. But there is a feature for user@IP permissions that I think will work for you.
-
@Pete-S said in SSH jump server access control?:
I also came across Teleport which is especially intended as a jump server.
I've seen it before but never had closer look.
There is another too. And of course, I can't remember its name.
-
@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.
