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

Durante uma auditoria /var/log/auth.logem um dos meus servidores públicos, eu encontrei 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 um sshspam de login típico de hackers aleatórios; no entanto, quando olhei mais de perto, notei outra coisa. A maioria das /var/log/auth.logentradas com falha diz invalid usernelas, 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 início de sessão falhou por biné que ele é um usuário válido no /etc/passwdque ainda tem um shell de login:

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

Eu pensei que eu tinha coberto os todos os nomes de usuário padrão que poderia fazer o login remotamente quando eu desativado PermitRootLoginem /etc/ssh/sshd_config; descobrir essa entrada abriu novas possibilidades em minha mente paranóica. Se, de alguma forma, os serviços funcionarem abaixo bin, é remotamente possível que alguém possa, de alguma forma, inserir uma chave ssh no bindiretório do usuário a partir de um serviço em execução na caixa, então eu gostaria de desativar completamente o login do binusuário, se possível.

Questões

• Esse servidor é remoto e caro de consertar (ou seja, pagarei por mãos remotas para conectar um KVM, mais o aluguel do KVM). Estou tentando descobrir o que posso quebrar se alterar a /etc/passwdentrada para binficar assim:

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

• Executei os seguintes comandos tentando descobrir o que biné necessário para ... No entanto, esses comandos surgiram sem arquivos e não encontrei nenhum processo de propriedade bin. O que o binusuário faz assim mesmo?

  $ sudo find / -group bin

  $ sudo find / -user bin

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

• Estou sendo muito paranóico?

Estou executando o Debian, se isso importa.

Um usuário que possui um shell válido e sem 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 cron. Um shell válido também é necessário para su bin -c 'wibble'funcionar (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 binna operação normal, portanto, definir o shell para /bin/falseok.

Não há risco de qualquer ataque direto permitir o binlogon no SSH, pois isso exigiria a criação /bin/.ssh/authorized_keyscomo usuário binou como root. Em outras palavras, a única maneira de entrar é entrar. No entanto, ter um shell válido aumenta o risco de erros de configuração. Também pode permitir alguns ataques remotos com outros serviços que não o SSH; por exemplo, um usuário relata que um invasor pode definir uma senha daemonremotamente via Samba e, em seguida, usar essa senha para efetuar login através de SSH.

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

Existem erros arquivados sobre esse problema no Debian ( # 274229 , # 330882 , # 581899 ), atualmente abertos e classificados como "lista de desejos". Costumo concordar que esses são erros e os usuários do sistema devem ter /bin/falsecomo shell, a menos que pareça necessário fazer o contrário.

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 "logar e usar" pessoas. Se você procurar em "/ etc / shadow", verá que todos esses "usuários" não possuem senhas ("x" ou "!" Em vez de um hash muito salgado). Isso significa que esses usuários não podem fazer login, não importa o quê.

Dito isto, não sei se é uma boa ideia alterar "/ bin / sh" para "/ bin / false" para todos esses usuários. Como os programas são executados sob esses grupos, pode não permitir que eles executem os comandos necessários. Eu os deixaria como "/ bin / sh".

Você não precisa se preocupar com esses usuários. Apenas se preocupe com os usuários que você cria (e com hashes em "/ etc / shadow")

Acredito que isso não seja um problema, pois, para configurar uma chave pública SSH no bindiretório inicial do ( /bin), o invasor precisará ter acesso root ao sistema de arquivos, o que significa que você está ferrado.

Se desejar, você pode desativar todos os métodos de autenticação para o binusuário na configuração do sshd usando o MatchUserbloco

Dito isto, parece que o usuário bin não é utilizado nos sistemas modernos derivados do Debian e é puramente um aceno à tradição ou existe para conformidade com alguns padrões.