On 2022-02-28T18:55, Whit Blauvelt <whit@xxxxxxxxxxxxx> wrote: > Hi, > > If this is not the right place to ask this, please redirect me. Hopefully it > is a known vulnerability, due to out of date software. We had a server > running OpenSSH_8.6p1 compiled on Ubuntu 16.04.7 which was compromised last > week. The intruder managed to achieve this: > > Feb 24 08:13:52 localhost sshd[32276]: Accepted password for backup from 5.161.47.185 port 37962 ssh2 > > This despite that /etc/passwd has: > > backup:x:34:34:backup:/var/backups:/usr/sbin/nologin > > And /etc/shadow has: > > backup:*:16359:0:99999:7::: > > Either the /usr/bin/nologin or the "*" in the second field of /etc/shadow > should have been enough to prevent "Accepted password for backup." The > /usr/sbin/nologin is the standard version for that Ubuntu generation, byte > identical. There are a few more mechanisms that may allow password logins despite the measures you named: When using PAM authentication (which I would assume, since you are talking about Ubuntu) all the configuration in /etc/pam.d regarding ssh logins, so /etc/pam.d/ssh and /etc/pam.d/common* will be in effect. If e.g. some module there specifies a different password and shell for backup, e.g. from LDAP, NIS, ActiveDirectory or different passwd/shadow files, those might apply. You said below that pam.d is "standard", but installed packages might modify configuration there, so I'd suggest having another look there. Also, depending on your configuration, /usr/sbin/nologin may not be sufficient to prevent port-forwarding without an open shell, thus enabling a spammer to forward some SMTP port for sending spam without authentication by "looking like" coming from an internal server. This is also hard to see and distinguish from an attacker having a shell in the logs. > Adding this to sshd_config was effective: > > DenyUsers backup > > If that's still not the default for system-level users like "backup", would > adding it be a reasonble feature request? Or is that on the distros to > define their default sshd_config settings? I'd consider it good practice to selectively 'AllowGroup ssh-login' or something to that effect for any internet-exposed system. But common distros are far more open than that. I don't think OpenSSH is the right place for a policy change, since as mentioned before, there is a lot going on in PAM that will affect what OpenSSH does here, without being part of OpenSSH. Ciao, Alexander Würstlein. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
