Est-ce que / usr / sbin / nologin en tant que shell de connexion sert un objectif de sécurité?

Dans mon /etc/passwddossier, je peux voir que l’ www-datautilisateur utilisé par Apache, ainsi que toutes sortes d’utilisateurs du système, ont un shell /usr/sbin/nologinou /bin/falseun 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 d'utiliser l'un de ces utilisateurs (ce que j'aimerais parfois faire pour vérifier ma compréhension de leurs autorisations et qu'il existe probablement d'autres raisons au moins à moitié saines), 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 simplement à me demander à quoi sert cet objectif en refusant à ces utilisateurs un shell de connexion. En cherchant une explication sur Internet, de nombreuses personnes prétendent que cela a un rapport avec la sécurité, et tout le monde semble convenir qu'il serait en quelque sorte une mauvaise idée de changer les coques 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é (en réalité, tous les utilisateurs de services qui ne doivent pas se connecter de manière interactive devraient avoir leur shell configuré sur quelque chose de non-interactif).

- https://serverfault.com/a/559315/147556

Le shell de 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

[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/sh

• Bien

  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 l'exécution du 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 publications soient unanimes pour dire que le fait de ne pas donner aux utilisateurs du système de véritables shells de connexion est bon pour la sécurité, aucun d’eux ne justifie cette affirmation, et je ne trouve aucune explication à ce sujet.

À quelle attaque essayons-nous de nous protéger en ne donnant pas à ces utilisateurs de véritables coquilles de connexion?

Si vous consultez la nologinpage de manuel, vous verrez la description suivante.

extrait

nologin affiche un message indiquant qu'un compte n'est pas disponible et quitte différent de zéro. Il est conçu comme un champ shell de remplacement pour refuser l’accès de connexion à 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.

Par conséquent, l’intention réelle de nologinest simplement que, lorsqu'un utilisateur tente de se connecter avec un compte qui en fait usage, il /etc/passwdse voit présenter un message convivial, et que tous les scripts / commandes qui tentent de s’en servir cette connexion reçoit le code de sortie de 1.

Sécurité

En ce qui concerne la sécurité, vous verrez généralement l'un /sbin/nologinou l' autre /bin/false, parfois , dans ce domaine. Les deux servent le même but, mais /sbin/nologinest 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 le fait de limiter le compte d’un utilisateur de cette manière réside dans le fait qu’il bloque l’accès direct via l’ loginapplication lorsque vous tentez d’obtenir un accès à l’aide dudit compte.

En utilisant soit nologinou /bin/falseaccomplit ceci. Limiter 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 nologin. Par exemple, scpne fonctionnera plus avec un compte d'utilisateur qui ne désigne pas un shell réel, comme décrit dans cette Q & R ServerFault intitulée: Quelle est la différence entre / sbin / nologin et / bin / false? .

Certainement, cela sert un objectif de sécurité. Par exemple, regardez le bogue ci-dessous pour un utilisateur du système qui avait un shell.

Mon serveur Debian a été compromis du fait que le compte démon possède un shell de connexion valide et que samba est ouvert pour un accès Internet. L'introduction 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 de la racine locale a ensuite été utilisé pour OWN mon serveur.

Je vous recommanderais de lire cette réponse merveilleuse de Gilles dans laquelle il a également fourni des liens vers certains bugs.

Des bogues ont été répertoriés sur ce problème dans Debian (274229, 330882, 581899), actuellement ouverts et classés dans la liste «liste de souhaits». J'ai tendance à penser que ce sont des bogues et que les utilisateurs du système devraient avoir / bin / false comme shell, à moins que cela ne semble nécessaire.

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

Oui, comme vous l'avez fait remarquer, vous pouvez toujours basculer vers les utilisateurs avec nologin comme shell par défaut en s'exécutant sudoavec un shell défini, mais dans ce cas, vous avez dû:

1. Connectez-vous en tant qu'utilisateur disposant d'un shell valide
2. Avoir les autorisations sudo configurées pour que cet utilisateur puisse exécuter la sucommande, et
3. Avez-vous tenté de vous connecter au journal sudoers (en supposant bien entendu que la journalisation sudo est activée).

Les utilisateurs pour lesquels nologin est défini comme shell par défaut disposent souvent de privilèges plus élevés / et sont en mesure de causer plus de dommages au système qu'un utilisateur habituel. Par conséquent, s’ils ne peuvent pas se connecter directement, cela tente de limiter les dommages qu'une violation de votre système pourrait subir. .

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, celui-ci vérifie le shell de connexion des utilisateurs qui tentent de se connecter. Si le shell ne figure pas dans la liste /etc/shells, cela 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.

Outre les 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 sous cet utilisateur. Ce fichier peut être ~ / .ssh / registered_keys.

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

Désactiver un shell de connexion rendrait cette option beaucoup plus difficile.

En règle générale, je dirais que / bin / false et / sbin / nologin sont identiques, mais je suppose que cela dépend du serveur SSH que vous utilisez.

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

Exploit affecte la plupart des versions:

7.2p1 et moins (toutes les versions; remontant à environ 20 ans) avec la transmission X11 activée

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

Donc, sur cette base, je ferais personnellement / 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 veuillez le faire à vos risques et périls! Je suppose que dans le pire des cas, vous pouvez simplement le rétablir et redémarrer tout service affectant. Personnellement, j'ai plusieurs entrées qui utilisent / bin / false - Je ne suis pas sûr de vouloir déranger cela, car le transfert X11 n'est pas quelque chose que j'ai activé;)

Si vous utilisez OpenSSH (beaucoup de gens le pensent, je pense ...) ET que le transfert X11 est activé - vous pouvez envisager de / sbin / nologin (ou peut-être basculer vers Dropbear).

En règle générale, il est 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 via SU ou SUDO, mais toutes leurs actions sont suivies dans les fichiers journaux de Sudoers et peuvent être retracées jusqu'à l'utilisateur qui a exécuté des commandes avec les privilèges de 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 ne puissent pas modifier les fichiers journaux. L'utilisateur qui exécute des commandes sous SU ou SUDO est déjà autorisé à accéder au système.

D'autre part, un utilisateur externe ou non autorisé sur le système n'aura aucun accès à la connexion à l'aide de ces comptes, ce qui constitue une mesure de sécurité.

Oui, cela sert un objectif de sécurité. C'est une mesure de défense en profondeur.

La raison principale en est que plusieurs logiciels permettent de valider certaines informations d'identification de connexion pour un utilisateur spécifié, puis d'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 correctement en tant qu'utilisateur via SSH, SSH lance alors le shell de connexion de l'utilisateur (ou l'utilise pour exécuter la commande que vous indiquez, si vous utilisez la ssh someuser@example.com 'command to run'syntaxe).

Bien sûr, idéalement, un attaquant ne pourra pas 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 de base 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 de base de l'utilisateur

Désormais, votre attaquant peut écrire une clé publique SSH sur ~/.ssh/authorized_keys, puis sur SSH et - boum! - Ils ont un accès shell à votre serveur.

Si, au lieu de cela, l’utilisateur a /usr/sbin/nologinpour shell de connexion, même après que l’attaquant ait écrit la clé publique avec succès authorized_keys, cela ne leur est pas utile. Tout ce que cela leur permet de faire est de les exécuter à distance nologin, ce qui n’est pas très utile. Ils ne peuvent pas obtenir d'obus et leur attaque a été atténuée.

Au cas où ce scénario vous semblerait très hypothétique, j'aimerais préciser que cette attaque m'a ciblé précisément en 2015, environ un an après avoir posé cette question. Comme un putain d'idiot, j'avais laissé une instance Redis sans mot de passe ouvert au monde. Il a été pris pour cible par l' attaque Redis crackit , dans laquelle l'attaquant a inséré une clé publique SSH dans votre base de données Redis, puis envoyé une commande demandant à Redis d'écrire le contenu de la base de données .ssh/authorized_keys, puis tenté de SSH in. J'ai été épargné des conséquences de ma propre incompétence que par le fait que les responsables du redis-serverpaquetage Apt (que j'avais utilisé pour installer Redis) avaient la sagesse de le faire exécuter Redis en tant queredisutilisateur qui n'a ni répertoire de base ni shell de connexion; Sans eux, mon serveur aurait probablement été rançonné ou aurait fait partie du botnet de certains pirates.

Cette expérience m'a apporté une certaine humilité et m'a fait comprendre l'importance de la défense en profondeur et, en particulier, de ne pas attribuer de shells de connexion aux comptes qui exploitent des serveurs Web, des bases de données et d'autres services en arrière-plan.