27

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 for bin 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 by bin. What does the bin 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 on www-data.

  • Am I being too paranoid?

I am running Debian, if that matters.

Mike Pennington
  • 2,482

3 Answers3

24

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 as bin 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 user bin 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 for daemon 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 an AllowGroups 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.

Gilles 'SO- stop being evil'
  • 829,060
6

You don't have to worry about those as users. They are "users" in the sense of security groups, not users in the sense of "login and use" people. If you look in "/etc/shadow", you will see that all these "users" do not have passwords (either "x" or "!" instead of a long salted hash). This means that these users cannot login, no matter what.

That said, I don't know if it is a good idea to change "/bin/sh" to "/bin/false" for all these users. Because programs run under these groups, it might not allow them to execute the commands that they need to. I'd leave them as "/bin/sh".

There is no need for you to worry about these users. Only worry about the users you create (and ones with hashes in "/etc/shadow")

Chris
  • 223
  • 1
    Fair point about no hash in /etc/shadow, but if a service runs as a user, it's theoretically possible for someone to insert an ssh login key, no? – Mike Pennington Jan 11 '12 at 21:53
  • Only if they already were logged into your account with root privileges...in which case, these users are the least of your worries :-P – Chris Jan 11 '12 at 21:55
  • I'm not sure I agree with all the constraints you just listed. If that were true, then open rpcd ports wouldn't be a problem; however, I personally witnessed the results of a remote exploit on an old Solaris machine where the attacker gained access through an rpc exploit on the box. rhosts was enabled and writable by that rpc user (can't remember any more specifics... it was years ago)... Likewise if they can make an ~/.ssh/authorized_keys for a user that could login, then this still seems like a risk (even without a password in /etc/shadow) – Mike Pennington Jan 11 '12 at 22:01
  • Yes, but that exploit was not through SSH. Programs typically run under their own user (as you have said). An exploit in a program (for example, a buffer overflow exploit) can make the malicious user access the shell that that program has access to. However, that program needs that access to do whatever that program is meant to do (otherwise it can't access the things it needs to). This why its important to ensure that permissions are set correctly. An exploit in the rpc daemon is quite a big problem, which can be solved by updating the software (or by restricting it). – Chris Jan 11 '12 at 22:12
  • 1
    Sorry, ran out of room. Changing the shell that a program can access DOES fix that problem, but it makes more problems with what the program is actually supposed to do.

    I thought you originally meant that a malicious user could SSH in through that user, which they can't (unless they set a key, I believe, as you said).

    You can solve that small problem by, in sshd_config, put "AllowUsers ..." to only allow specific users SSH access.

     – Chris Jan 11 '12 at 22:14
1

I believe this is a non-issue, as in order to set up an SSH public key in the bin's home directory (/bin), the attacker would have to have root access to the file system, which means you're screwed anyway.

If you like, you could disable all authentication methods for the bin user in sshd's config using the MatchUser block.

That said, looks like the bin user is unused on modern Debian-derived systems and is purely a nod to tradition or is there for compliance with some standards.

user21217
  • 111