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? If that is the case, how is that done?
I bet you can, but we don't. So I'm not sure how. Generally you assume that access "to" the jump box means it is a trusted person already, then the additional access to the next device is limited to user access rather than network access. It's not that you trust them completely, but you don't limit their ability to launch a DoS attack or something at a network level.
-
@Pete-S said in SSH jump server access control?:
How is access control implemented?
Do the users actually have network access to your entire infrastructure but are only able to login to the servers where they actually have working credentials?Correct. Which is quite limited, of course. In many cases you can add user based network limits on the client machines, rather than the jump box. BUt that's application by application.
Typically we use SSH keys, which are super reliable and still fast. So access control from the jump box is quite good.
-
@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? If that is the case, how is that done?
I bet you can, but we don't. So I'm not sure how. Generally you assume that access "to" the jump box means it is a trusted person already, then the additional access to the next device is limited to user access rather than network access. It's not that you trust them completely, but you don't limit their ability to launch a DoS attack or something at a network level.
When we use VPN for remote access, each user is assigned his own unique IP address. Network access is then controlled by network firewall rules.
I was thinking about how to replicate that with a ssh jump server. We need that type of access restriction.
-
@Pete-S never tried it myself but I think it should be doable using uid-owner in iptables
iptables -A OUTPUT -s 127.0.0.1 -d x.x.x.x -m owner --uid-owner <USERNAME> -j ACCEPT/REJECT
-
@triple9 said in SSH jump server access control?:
@Pete-S never tried it myself but I think it should be doable using uid-owner in iptables
iptables -A OUTPUT -s 127.0.0.1 -d x.x.x.x -m owner --uid-owner <USERNAME> -j ACCEPT/REJECT
But the UID would not be known until after the fact. How would it know the user to open the port?
-
@Pete-S said in SSH jump server access control?:
When we use VPN for remote access, each user is assigned his own unique IP address. Network access is then controlled by network firewall rules.
So this is application level. Meaning, the port is open everywhere, access is blocked AFTER the connection. Which is how it would have to work, so that's fine. Anyone can attack your VPN, but access after getting into the VPN is limited by IP. So that's different than limiting at the SSH layer, it would be within the SSH transaction.
-
@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.
-
So what would be sensible is not limiting access "on the network" to an IP, since the IP is the jump box. It's the user's IP you want to limit TO the jump box. This is above and beyond the current or stated security, but probably more of what people were imagining when they made the requirement, but since likely whoever made the rule wasn't clear on how things worked, the rule didn't make any sense.
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.
-
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.
