Por que o usuário 'bin' precisa de um shell de login?

Question

Durante uma auditoria de /var/log/auth.log em um dos meus servidores públicos, descobri o seguinte:

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

À primeira vista, isso parece típico spam de login de ssh de hackers aleatórios; No entanto, quando olhei mais de perto, notei outra coisa. A maioria das entradas /var/log/auth.log com falha diz invalid user , como esta:

Jan  9 10:45:23 Bucksnort sshd[3006]: Failed password for invalid user sales 
    from 123.212.43.5 port 10552 ssh2

A coisa inquietante sobre essa mensagem de login com falha para bin é que é um usuário válido em /etc/passwd que ainda tem um shell de login:

[mpenning@Bucksnort ~]$ grep ^bin /etc/passwd
bin:x:2:2:bin:/bin:/bin/sh

Pensei ter coberto todos os nomes de usuário padrão que puderam acessar remotamente quando desabilitei PermitRootLogin in /etc/ssh/sshd_config ; Descobrir essa entrada abriu novas possibilidades em minha mente paranóica. Se de alguma forma os serviços fossem executados em bin , seria remotamente possível que alguém pudesse de alguma forma inserir uma chave ssh no diretório bin do usuário a partir de um serviço em execução na caixa, então eu gostaria de desabilitar completamente o login do bin usuário, se possível.

Perguntas

• Este servidor é remoto e caro de consertar (ou seja, eu pago por mãos remotas para conectar um KVM, além de aluguel de KVM). Eu estou tentando descobrir o que eu poderia quebrar se eu mudar a entrada /etc/passwd para bin para ficar assim:

  bin:x:2:2:bin:/bin:/bin/false

• Eu executei os seguintes comandos tentando descobrir para que bin é necessário ... No entanto, esses comandos não tinham arquivos e não encontrei nenhum processo de propriedade de bin . O que o usuário bin faz de qualquer maneira?

  $ sudo find / -group bin

  $ sudo find / -user bin

• Existem outros usuários que devem colocar seus shells de login em /bin/false ? FYI, eu já tenho /bin/false em www-data .

• Estou sendo muito paranóico?

Estou usando o Debian, se isso for importante.

Pós-script

Esta pergunta foi inesperadamente popular. Eu esclareceria para os leitores após o fato de que a principal preocupação era impedir logins não autorizados dos usuários do sistema padrão; Eu já havia assumido que root era a principal ameaça, antes de formar a questão. Algumas respostas abordam como outros usuários podem ou não obter credenciais de login, mas isso é irrelevante para o foco principal da questão.

    

Answer 1

Um usuário que possui um shell válido e nenhuma senha ainda pode efetuar login por métodos não baseados em senha, sendo o mais comum uma chave ssh. Um shell válido é necessário para executar tarefas agendadas. Um shell válido também é necessário para que su bin -c 'wibble' funcione (no Linux, pelo menos, su bin -s /bin/sh -c 'wibble' também funcionará).

No caso de bin , a maioria dos sistemas nunca executa um comando como bin em operação normal, portanto, configurar o shell para /bin/false seria ok.

Não há risco de ataque direto permitindo que bin efetue login via SSH, pois isso exigiria a criação de /bin/.ssh/authorized_keys como usuário bin ou como raiz. Em outras palavras, a única maneira de entrar é estar dentro. No entanto, ter um shell válido aumenta o risco de configuração incorreta. Também pode permitir alguns ataques remotos com serviços diferentes de SSH; por exemplo, um usuário informa que um invasor pode definir uma senha para daemon remotamente via Samba, em seguida, use essa senha para efetuar login no SSH.

Você pode conectar o furo SSH listando os nomes dos usuários do sistema em uma diretiva DenyUsers em /etc/ssh/sshd_config (infelizmente, você não pode usar um intervalo numérico). Ou, inversamente, você pode colocar uma diretiva AllowGroups e permitir apenas os grupos que contêm usuários físicos (por exemplo, users se você conceder a todos os seus usuários físicos essa associação de grupo).

Existem bugs sobre este assunto no Debian ( # 274229 , # 330882 , # 581899 ), atualmente aberto e classificado como" wishlist ". Eu tenho a tendência de concordar que estes são bugs e os usuários do sistema devem ter /bin/false como seu shell, a menos que pareça necessário fazer o contrário.

    

Answer 2

Você não precisa se preocupar com isso como usuário. Eles são "usuários" no sentido de grupos de segurança, não usuários no sentido de "fazer login e usar" pessoas. Se você olhar em "/ etc / shadow", verá que todos esses "usuários" não possuem senhas ("x" ou "!" Em vez de um longo hash salgado). Isso significa que esses usuários não podem fazer login, não importa o que aconteça.

Dito isso, não sei se é uma boa idéia alterar "/ bin / sh" para "/ bin / false" para todos esses usuários. Como os programas são executados nesses grupos, eles podem não permitir a execução dos comandos necessários. Eu os deixaria como "/ bin / sh".

Não há necessidade de você se preocupar com esses usuários. Apenas se preocupe com os usuários que você cria (e aqueles com hashes em "/ etc / shadow")

    

Answer 3

Acredito que esse não é um problema, pois para configurar uma chave pública SSH no diretório inicial bin ( /bin ), o invasor teria que ter acesso raiz ao sistema de arquivos, o que significa que você está ferrado de qualquer maneira.

Se quiser, você pode desabilitar todos os métodos de autenticação para o usuário bin na configuração do sshd usando o bloco MatchUser .

Dito isto, parece que o usuário bin está sem uso em sistemas modernos derivados do Debian e é puramente um aceno à tradição ou está lá para conformidade com alguns padrões.