5 ms·

Just a quick note on this excerpt: > Disallowing root login is also frequently recommended. I believe this has limited merit in our current landscape since 95%

by jsd1982 5y ago

Just a quick note on this excerpt: > Disallowing root login is also frequently recommended. I believe this has limited merit in our current landscape since 95% of the time, the user you log in with has sudo privileges. Then it adds no extra security. But you should really judge this for your own situation. Disallowing explicit `root` login makes it harder for attackers to guess the usernames which have sudo access, thus I'd say it decreases the attack surface area. Yes, sudo gives them the same level of access as root but the path to get there from an attacker's perspective is not the same.

sam_lowry_ 5y ago
The link to Mozilla infosec gives a better reason to disallow root login in ssh: auditing in multi-user environments. I am still unconvinced, though. Auditing can by done by recording the IP address, for instance.
- AviationAtom 5y ago
  Even easier: key signature
- castillar76 5y ago
  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.
aljarry 5y ago
I haven't seen anyone changing the default user logins for their instances in AWS, though - everyone uses ubuntu, ec2-user, or whatever is the default of their distribution.
- flatiron 5y ago
  But the default for ec2-user doesn’t allow logging into ssh with a password.
R0b0t1 5y ago
You're right. Also, you also need to know the password to give sudo.
adamzochowski 5y ago
The goal is to avoid password sharing. if 20 people have root password, and server supports root login, then you can't know which of the 20 people had their machines compromised. if 20 people each have to sudo, then you can trace which user was compromised.
- AviationAtom 5y ago
  If all users have a unique key for root access, and only keyed authentication is possible, then you can match the key fingerprint in the logs to a physical user.
- rkeene2 5y ago
  I typically frame this as accounts are for accountability. Reducing accountability isn't typically a goal for organizations so it's strictly better to have 20 accounts with sudo versus everyone using a single shared account (shared accountability) UNLESS the accountability is managed some other way (I think this something Gravitational Teleport tries to sell on this forum often).
  - noinsight 5y ago
    You can use smart cards as plain SSH keypairs and sshd will of course log the fingerprint of the key used to authenticate. That's pretty foolproof accountability.
    - rkeene2 5y ago
      I in fact have done this (heavy user of smart cards and author of middleware), BUT what sshd logs (a fingerprint of the public key) requires a bit of work to match an authorized_keys format file (basically a stripped down PKCS#1 format with a header). I actually use a fork of OpenSSH called PKIXSSH which supports X.509 certificates in sshd, and this is far more reliable.
- croutonwagon 5y ago
  Also, at least in Ubuntu, sudo commands are logged in syslog and are thus auditable. That’s not necessarily the case if you su as root and run the same commands.
BiteCode_dev 5y ago
If you are logged in as root, you can do anything. If you are logged in as a sudo user, provided allowing only an ssh key, can you can't do anything unless: - you know the password - you trick the user into doing the action for you (E.G: a line in the bashrc) The first one will slow down the attaker, the second one may trigger the user BS detector.
- tadbit 5y ago
  > If you are logged in as a sudo user, provided allowing only an ssh key, can you can't do anything unless: > - you know the password This assumes one isn't using password-less sudo (NOPASSWD), which several distros do set by default and many users change to it for convenience.
  - aryhdrsfhzdf 5y ago
    What are some examples of these "several distros" that set it by default? Of the major ones I'm willing to use in production (Debian, Ubuntu, RHEL and derivs, SuSE, hesitantly Arch), none offer NOPASSWD sudo to users marked as administrative in each distro's normal way. (i.e. various group memberships) NOPASSWD is poor hygiene.
    - mhio 5y ago
      Amazon Linux
    - mastax 5y ago
      GCP sets it in Debian, apparently.
    - gerikson 5y ago
      Raspbian doesn't require a password when using sudo.
    - jschwartzi 5y ago
      Also Ubuntu in Azure.
dumpsterdiver 5y ago
> Disallowing explicit `root` login makes it harder for attackers to guess the usernames which have sudo access Or rather, it forces attackers to enumerate other usernames because the default root account isn't available to brute force. In general, when password authentication is in use (which it should never be for SSH), then disabling the default user account acts as a simple way of mitigating brute force attacks. If best practices are followed and passwords are not used to authenticate to SSH servers, then this additional measure might be moot. Even so, I can't think of a reason not to disable root SSH login anyway, even if password authentication is disabled. A layered defense assumes the possibility that other defenses might fail. Noone wants to be the person who wrote off an additional defense measure because they didn't think it was possible to exploit, only to have a new CVE come out to prove them wrong.
grosswait 5y ago
If shared logins are in use attribution can be problematic.
hnarn 5y ago
> Disallowing explicit `root` login makes it harder for attackers to guess the usernames (...) Technically correct I guess, but isn't password logins considered bad practice anyway? So if you have passphrase protected, key-based authentication only, is it really relevant whether you have it against root or a user with sudo permissions?

sam_lowry_ 5y ago

The link to Mozilla infosec gives a better reason to disallow root login in ssh: auditing in multi-user environments. I am still unconvinced, though. Auditing can by done by recording the IP address, for instance.

AviationAtom 5y ago
Even easier: key signature
castillar76 5y ago
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.

aljarry 5y ago

I haven't seen anyone changing the default user logins for their instances in AWS, though - everyone uses ubuntu, ec2-user, or whatever is the default of their distribution.

flatiron 5y ago
But the default for ec2-user doesn’t allow logging into ssh with a password.

R0b0t1 5y ago

You're right. Also, you also need to know the password to give sudo.

adamzochowski 5y ago

The goal is to avoid password sharing. if 20 people have root password, and server supports root login, then you can't know which of the 20 people had their machines compromised. if 20 people each have to sudo, then you can trace which user was compromised.

AviationAtom 5y ago
If all users have a unique key for root access, and only keyed authentication is possible, then you can match the key fingerprint in the logs to a physical user.
rkeene2 5y ago
I typically frame this as accounts are for accountability. Reducing accountability isn't typically a goal for organizations so it's strictly better to have 20 accounts with sudo versus everyone using a single shared account (shared accountability) UNLESS the accountability is managed some other way (I think this something Gravitational Teleport tries to sell on this forum often).
- noinsight 5y ago
  You can use smart cards as plain SSH keypairs and sshd will of course log the fingerprint of the key used to authenticate. That's pretty foolproof accountability.
  - rkeene2 5y ago
    I in fact have done this (heavy user of smart cards and author of middleware), BUT what sshd logs (a fingerprint of the public key) requires a bit of work to match an authorized_keys format file (basically a stripped down PKCS#1 format with a header). I actually use a fork of OpenSSH called PKIXSSH which supports X.509 certificates in sshd, and this is far more reliable.
croutonwagon 5y ago
Also, at least in Ubuntu, sudo commands are logged in syslog and are thus auditable. That’s not necessarily the case if you su as root and run the same commands.

BiteCode_dev 5y ago

If you are logged in as root, you can do anything. If you are logged in as a sudo user, provided allowing only an ssh key, can you can't do anything unless: - you know the password - you trick the user into doing the action for you (E.G: a line in the bashrc) The first one will slow down the attaker, the second one may trigger the user BS detector.

tadbit 5y ago
> If you are logged in as a sudo user, provided allowing only an ssh key, can you can't do anything unless: > - you know the password This assumes one isn't using password-less sudo (NOPASSWD), which several distros do set by default and many users change to it for convenience.
- aryhdrsfhzdf 5y ago
  What are some examples of these "several distros" that set it by default? Of the major ones I'm willing to use in production (Debian, Ubuntu, RHEL and derivs, SuSE, hesitantly Arch), none offer NOPASSWD sudo to users marked as administrative in each distro's normal way. (i.e. various group memberships) NOPASSWD is poor hygiene.
  - mhio 5y ago
    Amazon Linux
  - mastax 5y ago
    GCP sets it in Debian, apparently.
  - gerikson 5y ago
    Raspbian doesn't require a password when using sudo.
  - jschwartzi 5y ago
    Also Ubuntu in Azure.

dumpsterdiver 5y ago

> Disallowing explicit `root` login makes it harder for attackers to guess the usernames which have sudo access Or rather, it forces attackers to enumerate other usernames because the default root account isn't available to brute force. In general, when password authentication is in use (which it should never be for SSH), then disabling the default user account acts as a simple way of mitigating brute force attacks. If best practices are followed and passwords are not used to authenticate to SSH servers, then this additional measure might be moot. Even so, I can't think of a reason not to disable root SSH login anyway, even if password authentication is disabled. A layered defense assumes the possibility that other defenses might fail. Noone wants to be the person who wrote off an additional defense measure because they didn't think it was possible to exploit, only to have a new CVE come out to prove them wrong.

grosswait 5y ago

If shared logins are in use attribution can be problematic.

hnarn 5y ago

> Disallowing explicit `root` login makes it harder for attackers to guess the usernames (...) Technically correct I guess, but isn't password logins considered bad practice anyway? So if you have passphrase protected, key-based authentication only, is it really relevant whether you have it against root or a user with sudo permissions?