During an audit of /var/log/auth.log
on one of my public webservers, I found this:
Jan 10 03:38:11 Bucksnort sshd[3571]: pam_unix(sshd:auth): authentication failure;
logname= uid=0 euid=0 tty=ssh ruser= rhost=61.19.255.53 user=bin
Jan 10 03:38:13 Bucksnort sshd[3571]: Failed password for bin from 61.19.255.53
port 50647 ssh2
At first blush, this looks like typical ssh
login spam from random hackers; however, as I looked closer I noticed something else. Most failed /var/log/auth.log
entries say invalid user
in them, like this one:
Jan 9 10:45:23 Bucksnort sshd[3006]: Failed password for invalid user sales
from 123.212.43.5 port 10552 ssh2
The disquieting thing about that failed login message for bin
is that it is a valid user in /etc/passwd
that even has a login shell:
[mpenning@Bucksnort ~]$ grep ^bin /etc/passwd
bin:x:2:2:bin:/bin:/bin/sh
I thought I had covered the all the default usernames that could login remotely when I disabled PermitRootLogin
in /etc/ssh/sshd_config
; discovering this entry opened new possibilities in my paranoid mind. If somehow services ran under bin
, then it is remotely possible that someone could somehow insert an ssh key into the bin
user's directory from a running service on the box, so I would like to completely disable login for the bin
user, if possible.
Questions
-
This server is remote, and expensive to fix (i.e. I will pay for remote hands to hook up a KVM, plus KVM rental). I am trying to figure out what I might break if I change the
/etc/passwd
entry forbin
to look like this:bin:x:2:2:bin:/bin:/bin/false
-
I ran the following commands trying to figure out what
bin
is needed for… However, these commands came up with no files and I could find no processes owned bybin
. What does thebin
user do anyway?$ sudo find / -group bin
$ sudo find / -user bin
-
Are there any other users that should get their login shells set to
/bin/false
? FYI, I have already have/bin/false
onwww-data
. -
Am I being too paranoid?
I am running Debian, if that matters.
Best Answer
A user who has a valid shell and no password can still log in by non-password-based methods, the most common being an ssh key. A valid shell is necessary to run cron jobs. A valid shell is also necessary for
su bin -c 'wibble'
to work (on Linux at least,su bin -s /bin/sh -c 'wibble'
will also work).In the case of
bin
, most systems never run a command asbin
in normal operation, so setting the shell to/bin/false
would be ok.There is no risk of any direct attack allowing
bin
to log in over SSH, because that would require creating/bin/.ssh/authorized_keys
as the userbin
or as root. In other words, the only way to get in is to be in. However, having a valid shell does increase the risk of misconfiguration. It can also permit some remote attacks with services other than SSH; for example a user reports that an attacker could set a password fordaemon
remotely via Samba, then use that password to log in over SSH.You can plug the SSH hole by listing the names of the system users in a
DenyUsers
directive in/etc/ssh/sshd_config
(unfortunately, you can't use a numerical range). Or, conversely, you can put anAllowGroups
directive and only allow the groups that contain physical users (e.g.users
if you grant all your physical users that group membership).There are bugs filed over this issue in Debian (#274229, #330882, #581899), currently open and classified as “wishlist”. I tend to agree that these are bugs and system users should have
/bin/false
as their shell unless it appears necessary to do otherwise.