4 ms·

Basing things on source IP is really inexact and easily muddied, though. For instance, the source IP is a workstation or a laptop—now we have to go through DHCP

Basing things on source IP is really inexact and easily muddied, though. For instance, the source IP is a workstation or a laptop—now we have to go through DHCP logs to figure out who had that IP address at the time the incident occurred. Or if we've properly implemented source limitations through a bastion host, all we'll see on the end server is the source IP of the bastion host, so we'll need to go to the bastion to figure out who was logged in at that time and what they were doing—hopefully there was only one engineer logged in at the time! And that assumes they didn't just SSH-jump through, in which case we just have the transitory SSH logs...which leaves us with the DHCP problem above unless they used their own userID to connect to the bastion itself. If it's a publicly available AWS host (which...oy gevalt), was that login from "dhcp-host-X.Y.Z.Q-suspiciouscablehosting.regionalisp.net" a hack, or an engineer trying to fix something by logging in from his home Internet connection? Ultimately, it's just much easier to force individual logins and require sudo. Even just an engineer logging in and doing 'sudo su -' is significantly more traceable than everyone logging in directly as root. Even better if you can force the individual logins and sudo sessions to use multi-factor auth—then you can keep root non-multi-factored and get in with just a password on the console when your MFA solution has gone pear-shaped. :)

sam_lowry_ 5y ago
`sudo su -` is always a nuisance. As an individual developer I prefer to ssh as root directly. Even more, I use mosh and connect to hosts with something like `mosh root@host -- screen -xRR -D`. Enterprisey server management tools issue short-lived keys that they push through backchannels to hosts. Hosts do not have users aside from system or applicaiton users. Anything else is quickly becoming outdated.
- castillar76 5y ago
  If you have the sort of system that has automated key issuance and low interactivity on hosts, I agree that makes sense. But then, that's exactly the 'ssh as yourself and then sudo to root' model, just abstracted in a different way, isn't it? In both cases you're authenticating to some intermediary as yourself first and then being given access to the local root account—it's just that in my system the 'intermediary' is a local unique user account, whereas in yours it would be the individual authenticating to the temporary-ssh-key-issuance system like Vault. As long as that system does a unique authentication, the two are more-or-less identical, although you'd have to be careful to ensure you can untangle the auth logs to the intermediary system and associate them with local root sessions.

sam_lowry_ 5y ago

`sudo su -` is always a nuisance. As an individual developer I prefer to ssh as root directly. Even more, I use mosh and connect to hosts with something like `mosh root@host -- screen -xRR -D`. Enterprisey server management tools issue short-lived keys that they push through backchannels to hosts. Hosts do not have users aside from system or applicaiton users. Anything else is quickly becoming outdated.

castillar76 5y ago
If you have the sort of system that has automated key issuance and low interactivity on hosts, I agree that makes sense. But then, that's exactly the 'ssh as yourself and then sudo to root' model, just abstracted in a different way, isn't it? In both cases you're authenticating to some intermediary as yourself first and then being given access to the local root account—it's just that in my system the 'intermediary' is a local unique user account, whereas in yours it would be the individual authenticating to the temporary-ssh-key-issuance system like Vault. As long as that system does a unique authentication, the two are more-or-less identical, although you'd have to be careful to ensure you can untangle the auth logs to the intermediary system and associate them with local root sessions.