Pourquoi l'utilisateur «bin» a-t-il besoin d'un shell de connexion?

Lors d'un audit /var/log/auth.logsur l'un de mes serveurs Web publics, j'ai trouvé ceci:

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

À première vue, cela ressemble à un sshspam de connexion typique de pirates aléatoires; cependant, en regardant de plus près, j'ai remarqué autre chose. La plupart des /var/log/auth.logentrées qui ont échoué disent invalid useren elles, comme celle-ci:

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

Ce qui est inquiétant à propos de ce message de connexion échoué, binc'est qu'il s'agit d'un utilisateur valide dans /etc/passwdlequel il a même un shell de connexion:

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

Je pensais avoir couvert les tous les noms d' utilisateur par défaut qui pourrait se connecter à distance quand je désactivé PermitRootLogindans /etc/ssh/sshd_config; découvrir cette entrée a ouvert de nouvelles possibilités dans mon esprit paranoïaque. Si les services fonctionnaient sous bin, il est possible à distance que quelqu'un insère en quelque sorte une clé ssh dans le binrépertoire de l' utilisateur à partir d'un service en cours d'exécution sur la boîte, donc je voudrais désactiver complètement la connexion pour l' binutilisateur, si possible.

Des questions

• Ce serveur est distant et coûteux à réparer (c'est-à-dire que je paierai des mains distantes pour brancher un KVM, plus la location de KVM). J'essaie de comprendre ce que je pourrais casser si je change l' /etc/passwdentrée pour binressembler à ceci:

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

• J'ai exécuté les commandes suivantes en essayant de comprendre ce qui binest nécessaire pour ... Cependant, ces commandes n'ont fourni aucun fichier et je n'ai trouvé aucun processus appartenant à bin. Que fait l' binutilisateur de toute façon?

  $ sudo find / -group bin

  $ sudo find / -user bin

• Y a-t-il d'autres utilisateurs qui devraient configurer leurs shells de connexion /bin/false? Pour votre information, je suis déjà /bin/falsesur www-data.

• Suis-je trop paranoïaque?

J'utilise Debian, si cela importe.

Un utilisateur possédant un shell valide et aucun mot de passe peut toujours se connecter par des méthodes non basées sur un mot de passe, la plus courante étant une clé ssh. Un shell valide est nécessaire pour exécuter les tâches cron. Un shell valide est également nécessaire pour su bin -c 'wibble'fonctionner (sous Linux au moins, su bin -s /bin/sh -c 'wibble'fonctionnera également).

Dans le cas de bin, la plupart des systèmes n'exécutent jamais de commande comme binen fonctionnement normal, donc définir le shell /bin/falseserait correct.

Il n'y a aucun risque d'attaque directe permettant binde se connecter via SSH, car cela nécessiterait de créer en /bin/.ssh/authorized_keystant qu'utilisateur binou en tant que root. En d'autres termes, la seule façon d'entrer est d'être. Cependant, avoir un shell valide augmente le risque de mauvaise configuration. Il peut également permettre certaines attaques à distance avec des services autres que SSH; par exemple, un utilisateur signale qu'un attaquant pourrait définir un mot de passe à daemondistance via Samba, puis utiliser ce mot de passe pour se connecter via SSH.

Vous pouvez boucher le trou SSH en répertoriant les noms des utilisateurs du système dans une DenyUsersdirective /etc/ssh/sshd_config(malheureusement, vous ne pouvez pas utiliser une plage numérique). Ou, à l'inverse, vous pouvez mettre une AllowGroupsdirective et autoriser uniquement les groupes qui contiennent des utilisateurs physiques (par exemple, userssi vous accordez à tous vos utilisateurs physiques cette appartenance à un groupe).

Il y a des bogues déposés sur ce problème dans Debian ( # 274229 , # 330882 , # 581899 ), actuellement ouverts et classés comme «liste de souhaits». J'ai tendance à convenir qu'il s'agit de bogues et que les utilisateurs du système devraient avoir /bin/falseleur shell à moins qu'il ne semble nécessaire de faire autrement.

Vous n'avez pas à vous en préoccuper en tant qu'utilisateurs. Ce sont des «utilisateurs» au sens de groupes de sécurité, et non des utilisateurs au sens de «se connecter et utiliser» des personnes. Si vous regardez dans "/ etc / shadow", vous verrez que tous ces "utilisateurs" n'ont pas de mots de passe ("x" ou "!" Au lieu d'un long hachage salé). Cela signifie que ces utilisateurs ne peuvent pas se connecter, quoi qu'il arrive.

Cela dit, je ne sais pas si c'est une bonne idée de changer "/ bin / sh" en "/ bin / false" pour tous ces utilisateurs. Étant donné que les programmes s'exécutent sous ces groupes, il peut ne pas leur permettre d'exécuter les commandes dont ils ont besoin. Je les laisserais comme "/ bin / sh".

Vous n'avez pas à vous soucier de ces utilisateurs. Ne vous souciez que des utilisateurs que vous créez (et de ceux avec des hachages dans "/ etc / shadow")

Je pense que ce n'est pas un problème, car pour configurer une clé publique SSH dans le binrépertoire personnel de ( /bin), l'attaquant devrait avoir un accès root au système de fichiers, ce qui signifie que vous êtes de toute façon vissé.

Si vous le souhaitez, vous pouvez désactiver toutes les méthodes d'authentification pour l' binutilisateur dans la configuration de sshd en utilisant le MatchUserbloc.

Cela dit, il semble que l'utilisateur bin ne soit pas utilisé sur les systèmes modernes dérivés de Debian et soit purement un clin d'œil à la tradition ou soit conforme à certaines normes.