Est-ce que / usr / sbin / nologin en tant que shell de connection sert à des fins de security?

Si vous jetez un oeil à la page de manuel de nologin , vous verrez la description suivante.

extrait

nologin affiche un message indiquant qu'un count n'est pas disponible et sort non-zéro. Il est conçu comme un champ de shell de rlocation pour refuser l'access à un count.

Si le file /etc/nologin.txt existe, nologin affiche son contenu à l'user au lieu du message par défaut.

Le code de sortie renvoyé par nologin est toujours 1.

Donc, l'intention réelle de nologin est juste de sorte que lorsqu'un user tente de se connecter avec un count qui l'utilise dans le /etc/passwd , il se présente avec un message convivial et que tout script / tenter de faire usage de cette connection recevoir le code de sortie de 1.

Sécurité

En ce qui concerne la security, vous verrez généralement /sbin/nologin ou parfois /bin/false , entre autres dans ce champ. Ils servent tous les deux le même but, mais /sbin/nologin est probablement la méthode préférée. En tout cas, ils limitent l'access direct à un shell comme ce count d'user particulier.

Pourquoi est-ce considéré comme précieux en matière de security?

Le «pourquoi» est difficile à décrire complètement, mais la limitation du count d'un user de cette manière est qu'elle empêche l'access direct via l'application de login lorsque vous tentez d'accéder à ce count d'user.

Utiliser nologin ou /bin/false accomplit ceci. Limiter la surface d'attaque de votre système est une technique courante dans le monde de la security, qu'il s'agisse de désactiver des services sur des ports spécifiques ou de limiter la nature des connections sur ses systèmes.

Il y a encore d'autres rationalisations pour utiliser nologin . Par exemple, scp ne fonctionnera plus avec un count d'user qui ne désigne pas un shell réel, comme décrit dans cette FAQ sur ServerFault intitulée: Quelle est la différence entre / sbin / nologin et / bin / false? .

Définitivement, il sert un but de security. Par exemple, regardez le bug ci-dessous déposé pour un user du système qui avait un shell.

Mon server debian a été compromis en raison du count démon ayant un shell de connection valide et ayant samba ouvert pour l'access internet. La pause a été faite en définissant un mot de passe à distance via samba pour le count du démon et la connection via ssh. Un exploit root local a ensuite été utilisé pour PROPRE mon server.

Je vous recommand de lire cette merveilleuse réponse de Gilles où il a également fourni des liens vers certains des bugs.

Il y a des bogues déposés sur ce problème dans Debian (274229, 330882, 581899), actuellement ouvert et classé comme "list de souhaits". J'ai tendance à convenir que ce sont des bugs et que les users du système devraient avoir / bin / false comme shell, à less qu'il ne semble nécessaire de faire autrement.

Pour append aux excellentes réponses de @slm et @ramesh:

Oui, comme vous l'avez souligné, vous pouvez toujours passer aux users avec nologin comme shell par défaut en exécutant sudo avec un shell défini, mais dans ce cas, vous devez:

1. Connectez-vous en tant qu'user possédant un shell valide
2. Avoir sudo permissions configurées pour que cet user exécute la command su , et
3. Si votre tentative su a été enregistrée dans le journal sudoers (en supposant bien sûr que la consignation sudo est activée).

Les users 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 user régulier, les empêchant ainsi de se connecter directement tente de limiter les dommages qu'une violation de votre système pourrait subir .

À côté des grandes réponses déjà données, je peux penser au scénario suivant.

Un bogue de security dans un service s'exécutant en tant qu'user restreint permet d'écrire un file en tant qu'user. Ce file peut être ~ / .ssh / authorized_keys.

Cela permet à l'attaquant de se connecter directement dans un shell ce qui faciliterait l'exécution d'une escalade de privilèges.

Refuser un shell de connection rendrait cette option beaucoup plus difficile.

En plus des excellentes réponses qui ont été données, cela a un autre but.

Si vous exécutez un démon FTP sur votre server, il vérifie le shell de connection des users 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 des counts démons un shell spécial empêche quelqu'un de modifier le count via FTP.

En général, je dirais / bin / false et / sbin / nologin sont les mêmes – mais je suppose que cela dépend du server SSH que vous utilisez.

Il serait prudent pour moi de souligner que cet exploit récent sur OpenSSH semble affecter / bin / false les connections mais PAS / sbin / nologin. Cependant, il indique que Dropbear est différent de cette manière (aussi l'exploit s'applique spécifiquement à OpenSSH).

Exploit affecte la plupart des versions:

7.2p1 et inférieur (toutes les versions datant de ~ 20 ans) Avec le transfert X11 activé

https://www.exploit-db.com/exploits/39569/

Donc, sur la base de cela – personnellement je ferais / sbin / nologin cependant je ne suis pas sûr si cela pourrait affecter les services qui créent l'input / bin / false dans / etc / passwd. Vous pouvez expérimenter et voir vos résultats, mais veuillez le faire à vos risques et périls! Je suppose que dans le pire des cas, vous pouvez simplement le changer et redémarrer tout service (s). J'ai personnellement quelques inputs 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 (beaucoup de gens estiment que …) et que le transfert X11 est activé, vous pouvez envisager / sbin / nologin (ou passer à Dropbear).

Il est généralement recommandé de définir des counts de service et d'application pour une connection non interactive. Un user autorisé peut toujours avoir access à ces counts en utilisant SU ou SUDO, mais toutes leurs actions sont suivies dans les files journaux Sudoers et peuvent être retracées à l'user qui a exécuté des commands sous les privilèges de count de service. C'est pourquoi il est important de stocker les files journaux dans un système de gestion des journaux centralisé afin que les administrateurs système n'aient pas access à la modification des files journaux. L'user exécutant des commands sous SU ou SUDO est déjà autorisé à accéder au système.

D'autre part, un user externe ou non autorisé du système n'aura pas access à la connection en utilisant ces counts et c'est une mesure de security.