Est-ce que / usr / sbin / nologin en tant que shell de connexion sert à la sécurité?
Dans mon /etc/passwd fichier, je peux voir que le www-data l'utilisateur utilisé par Apache, ainsi que toutes sortes d'utilisateurs du système, ont soit /usr/sbin/nologin ou /bin/false comme shell de connexion. Par exemple, voici une sélection de lignes:
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin games:x:5:60:games:/usr/games:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin syslog:x:101:104::/home/syslog:/bin/false whoopsie:x:109:116::/nonexistent:/bin/false mark:x:1000:1000:mark,,,:/home/mark:/bin/bash
Par conséquent, si j'essaie de passer à l'un de ces utilisateurs (ce que j'aimerais parfois faire pour vérifier ma compréhension de leurs autorisations, et pour lequel il existe probablement d'autres raisons au moins à moitié sensées), j'échoue:
mark@lunchbox:~$ Sudo su www-data
This account is currently not available.
mark@lunchbox:~$ Sudo su syslog
mark@lunchbox:~$
Bien sûr, ce n'est pas vraiment un inconvénient, car je peux toujours lancer un Shell pour eux via une méthode comme celle-ci:
mark@lunchbox:~$ Sudo -u www-data /bin/bash
www-data@lunchbox:~$ Mais cela me laisse juste me demander à quoi sert but en refusant à ces utilisateurs un shell de connexion. En regardant autour d'Internet pour une explication, beaucoup de gens prétendent que cela a quelque chose à voir avec la sécurité, et tout le monde semble d'accord que ce serait en quelque sorte une mauvaise idée de changer les coquilles de connexion de ces utilisateurs. Voici une collection de citations:
Définir le shell de l'utilisateur Apache sur quelque chose de non interactif est généralement une bonne pratique de sécurité (vraiment tous les utilisateurs de services qui n'ont pas à se connecter de manière interactive devraient avoir leur Shell défini sur quelque chose qui n'est pas interactif).
- https://serverfault.com/a/559315/147556
le shell pour l'utilisateur www-data est défini sur/usr/sbin/nologin, et il est défini pour une très bonne raison.
- https://askubuntu.com/a/486661/119754
[les comptes système] peuvent être des failles de sécurité , surtout s'ils ont un shell activé:
Mauvais
bin:x:1:1:bin:/bin:/bin/shBien
bin:x:1:1:bin:/bin:/sbin/nologin
- https://unix.stackexchange.com/a/78996/29001
Pour des raisons de sécurité J'ai créé un compte utilisateur sans shell de connexion pour exécuter le serveur Tomcat:
# groupadd Tomcat # useradd -g Tomcat -s /usr/sbin/nologin -m -d /home/Tomcat tomcat
- http://www.puschitz.com/InstallingTomcat.html
Bien que ces messages soient unanimement d'accord pour dire que ne pas donner aux utilisateurs du système de véritables identifiants de connexion est bon pour la sécurité, aucun d'eux ne justifie cette affirmation, et je ne trouve aucune explication à ce sujet nulle part.
Contre quelle attaque essayons-nous de nous protéger en ne donnant pas à ces utilisateurs de véritables coquilles de connexion?
Si vous jetez un œil à la page de manuel nologin, vous verrez la description suivante.
extrait
nologin affiche un message indiquant qu'un compte n'est pas disponible et quitte non nul. Il est conçu comme un champ Shell de remplacement pour refuser l'accès à un compte.
Si le fichier
/etc/nologin.txtexiste,nologinaffiche son contenu à l'utilisateur au lieu du message par défaut.Le code de sortie renvoyé par
nologinest toujours 1.
Ainsi, l'intention réelle de nologin est juste pour que lorsqu'un utilisateur tente de se connecter avec un compte qui l'utilise dans le /etc/passwd est pour qu'ils reçoivent un message convivial et que tous les scripts/commandes qui tentent d'utiliser cette connexion reçoivent le code de sortie 1.
Sécurité
En ce qui concerne la sécurité, vous verrez généralement soit /sbin/nologin ou parfois /bin/false, entre autres dans ce domaine. Ils ont tous deux le même objectif, mais /sbin/nologin est probablement la méthode préférée. Dans tous les cas, ils limitent l'accès direct à un shell en tant que compte d'utilisateur particulier.
Pourquoi est-ce considéré comme précieux en matière de sécurité?
Le "pourquoi" est difficile à décrire complètement, mais l'intérêt de limiter le compte d'un utilisateur de cette manière est qu'il empêche l'accès direct via l'application login lorsque vous essayez d'accéder à l'aide dudit compte d'utilisateur.
Utilisation de nologin ou /bin/false accomplit cela. La limitation de la surface d'attaque de votre système est une technique courante dans le monde de la sécurité, qu'il s'agisse de désactiver des services sur des ports spécifiques ou de limiter la nature des connexions sur ses systèmes.
Il existe encore d'autres rationalisations pour l'utilisation de nologin. Par exemple, scp ne fonctionnera plus avec un compte d'utilisateur qui ne désigne pas un shell réel, comme décrit dans ce Q&R ServerFault intitulé: Quelle est la différence entre/sbin/nologin et/bin/faux? .
Certainement, il sert à des fins de sécurité. Par exemple, regardez ci-dessous bug déposé pour un utilisateur système qui avait un Shell.
Mon serveur Debian a été compromis en raison du compte démon ayant un shell de connexion valide et de l'ouverture de samba pour l'accès à Internet. L'effraction a été effectuée en définissant un mot de passe à distance via samba pour le compte démon et la connexion via ssh. Un exploit root local a ensuite été utilisé pour POSSÉDER mon serveur.
Je vous recommande de lire ce merveilleux réponse de Gilles où il a également fourni des liens vers certains bugs.
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/false comme shell, à moins qu'il ne semble nécessaire de faire autrement.
Pour ajouter aux excellentes réponses de @slm et @ramesh:
Oui, comme vous l'avez souligné, vous pouvez toujours passer aux utilisateurs avec nologin comme shell par défaut en exécutant Sudo avec un shell défini, mais dans ce cas, vous avez dû:
- Connectez-vous en tant qu'un autre utilisateur disposant d'un shell valide
- Avoir des autorisations Sudo configurées pour cet utilisateur pour exécuter la commande
su, et - Votre tentative su s'est-elle connectée au journal sudoers (en supposant bien sûr que la journalisation Sudo est activée).
Les utilisateurs qui ont défini nologin comme leur shell par défaut ont souvent des privilèges plus élevés/sont capables de faire plus de dégâts au système qu'un utilisateur normal, donc le fait qu'ils ne puissent pas se connecter directement tente de limiter les dommages qu'une violation de votre système pourrait subir .
À côté des bonnes réponses déjà données, je peux penser au scénario suivant.
Un bogue de sécurité dans un service exécuté en tant qu'utilisateur restreint permet d'écrire un fichier en tant que cet utilisateur. Ce fichier peut être ~/.ssh/authorized_keys.
Cela permet à l'attaquant de se connecter directement dans un shell, ce qui faciliterait considérablement l'exécution d'une élévation de privilèges.
Interdire un shell de connexion rendrait cette option beaucoup plus difficile.
En plus des excellentes réponses qui ont été données, cela sert un autre objectif.
Si vous exécutez un démon FTP sur votre serveur, il vérifie le shell de connexion des utilisateurs qui tentent de se connecter. Si le shell n'est pas répertorié dans /etc/shells, il ne leur permet pas de se connecter. Donc, donner aux comptes démons un Shell spécial empêche quelqu'un de modifier le compte via FTP.
En général, je dirais que/bin/false et/sbin/nologin sont les mêmes - mais je suppose que cela dépend du serveur SSH que vous utilisez.
Il serait prudent pour moi de souligner que cet exploit récent sur OpenSSH semble affecter/bin/false logins mais PAS/sbin/nologin. Cependant, il indique que Dropbear est différent de cette manière (l'exploit s'applique également spécifiquement à OpenSSH).
L'exploit affecte la plupart des versions:
7.2p1 et inférieur (toutes les versions; remontant à environ 20 ans) avec le transfert X11 activé
https://www.exploit-db.com/exploits/39569/
Donc, sur cette base - personnellement, je ferais/sbin/nologin mais je ne suis pas sûr que cela puisse affecter les services qui créent l'entrée/bin/false dans/etc/passwd. Vous pouvez expérimenter et voir vos résultats, mais faites-le à vos risques et périls! Je suppose que dans le pire des cas, vous pouvez simplement le modifier et redémarrer tout service affecté. Personnellement, j'ai quelques entrées en utilisant/bin/false - Je ne sais pas si je veux m'embêter avec cela car le transfert X11 n'est pas quelque chose que j'ai activé;)
Si vous utilisez OpenSSH (je pense que beaucoup de gens ...) ET que le transfert X11 est activé - vous voudrez peut-être envisager/sbin/nologin (ou peut-être passer à Dropbear).
Il est généralement recommandé de définir des comptes de service et d'application sur une connexion non interactive. Un utilisateur autorisé peut toujours avoir accès à ces comptes en utilisant SU ou Sudo, mais toutes leurs actions sont suivies dans les fichiers journaux Sudoers et peuvent être retracées jusqu'à l'utilisateur qui a exécuté les commandes avec les privilèges du compte de service. C'est pourquoi il est important de stocker les fichiers journaux dans un système de gestion des journaux centralisé afin que les administrateurs système n'aient pas accès aux fichiers journaux de modification. L'utilisateur exécutant des commandes sous SU ou Sudo est déjà autorisé à accéder au système.
D'un autre côté, un utilisateur externe ou non autorisé du système n'aura complètement aucun accès à la connexion en utilisant ces comptes et c'est une mesure de sécurité.
Oui, cela sert à des fins de sécurité. C'est une mesure de défense en profondeur.
La raison principale pour laquelle il sert un objectif est qu'il existe différents bits de logiciel qui valideront une certaine forme d'informations d'identification de connexion pour un utilisateur spécifié, puis utiliser le shell de connexion de cet utilisateur pour exécuter une commande. L'exemple le plus notable est peut-être SSH. Si vous vous authentifiez avec succès en tant qu'utilisateur via SSH, SSH lance ensuite le shell de connexion de l'utilisateur (ou l'utilise pour exécuter la commande que vous fournissez, si vous utilisez le ssh [email protected] 'command to run' syntaxe).
Bien sûr, idéalement, un attaquant ne pourra pas du tout s'authentifier en tant qu'utilisateur. Mais supposons que la situation suivante se produise:
- Un serveur que vous contrôlez exécute un service Web en tant qu'utilisateur disposant d'un répertoire personnel et d'un shell de connexion
- Un attaquant découvre une vulnérabilité dans ce service qui lui permet d'écrire des fichiers dans le répertoire personnel de l'utilisateur
Désormais, votre attaquant peut écrire une clé publique SSH dans ~/.ssh/authorized_keys, puis SSH dedans, et - boum! - ils ont un accès Shell à votre serveur.
Si l'utilisateur a à la place /usr/sbin/nologin comme shell de connexion, puis même après que l'attaquant a réussi à écrire la clé publique dans authorized_keys, cela ne leur est pas utile. Tout ce qu'il leur permet de faire est d'exécuter à distance nologin, ce qui n'est pas très utile. Ils ne peuvent pas obtenir Shell et leur attaque a été atténuée.
Dans le cas où ce scénario semble très hypothétique, je voudrais noter que j'ai été ciblé par précisément cette attaque à un moment donné en 2015, environ un an après J'ai posé cette question. Comme un putain d'idiot, j'avais laissé une instance de Redis sans mot de passe ouverte au monde. Il a été ciblé par l'attaque Redis crackit , dans laquelle l'attaquant insère une clé publique SSH dans votre base de données Redis, puis envoie une commande indiquant à Redis d'écrire le contenu de la base de données dans .ssh/authorized_keys, puis essaie de se connecter à SSH. Je n'ai été sauvé des conséquences de ma propre incompétence que par le fait que les responsables du redis-server Le paquet Apt (que j'avais utilisé pour installer Redis) avait la sagesse de le faire exécuter Redis en tant qu'utilisateur redis qui n'a pas de répertoire personnel ni de shell de connexion; sans eux, mon serveur aurait probablement été rançonné ou aurait fini par faire partie du botnet d'un pirate.
Cette expérience m'a donné un certain degré d'humilité et m'a fait apprécier l'importance de défense en profondeur , et, en particulier, de ne pas accorder de shell de connexion aux comptes qui exécutent des serveurs Web, des bases de données et d'autres services d'arrière-plan.