Dans mon /etc/passwd
dossier, je peux voir que l’ www-data
utilisateur utilisé par Apache, ainsi que toutes sortes d’utilisateurs du système, ont un shell /usr/sbin/nologin
ou /bin/false
un 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?
Réponses:
Si vous consultez la
nologin
page de manuel, vous verrez la description suivante.extrait
Par conséquent, l’intention réelle de
nologin
est simplement que, lorsqu'un utilisateur tente de se connecter avec un compte qui en fait usage, il/etc/passwd
se 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/nologin
ou l' autre/bin/false
, parfois , dans ce domaine. Les deux servent le même but, 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 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’
login
application lorsque vous tentez d’obtenir un accès à l’aide dudit compte.En utilisant soit
nologin
ou/bin/false
accomplit 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,scp
ne 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? .la source
They both serve the same purpose, but /sbin/nologin is probably the preferred method.
Du point de vue de la sécurité, `/ sbin / nologin`` n'est pas la méthode préférée; cela fait perdre du temps et des cycles fournissant une réponse. Bien que ni l'un ni l'autre ne fournissent une sécurité particulièrement bonne; Ce sont des mesures de défense en profondeur, mais elles n’empêchent pas réellement d’exécuter une commande en tant qu’utilisateur donné.nologin
c'est la méthode préférée pour les raisons UX, et non pour des raisons de sécurité - ne riensudo su someuser
avoir à se passer parce que leur shell de connexionfalse
est déroutant. , Ces deux aussi n'empêcher une personne d'exécuter une commande en tant qu'utilisateur donné dans certaines circonstances, décrites dans les réponses ici.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.
Je vous recommanderais de lire cette réponse merveilleuse de Gilles dans laquelle il a également fourni des liens vers certains bugs.
la source
ssh user@site
et que cela fonctionnait, il ne continuerait pas d'essayerssh user@site /bin/bash
, mais je suis à peu près sûr que cela fonctionnerait malgré le shell déclaré.ssh user@site /bin/bash
renvoie unThis account is currently not available.
message simple . En outre, cette réponse indique que nologin protège l'accès SSHPour 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
sudo
avec un shell défini, mais dans ce cas, vous avez dû:su
commande, etLes 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. .
la source
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.la source
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.
la source
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).
la source
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é.
la source
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 [email protected] '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:
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/nologin
pour shell de connexion, même après que l’attaquant ait écrit la clé publique avec succèsauthorized_keys
, cela ne leur est pas utile. Tout ce que cela leur permet de faire est de les exécuter à distancenologin
, 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 duredis-server
paquetage Apt (que j'avais utilisé pour installer Redis) avaient la sagesse de le faire exécuter Redis en tant queredis
utilisateur 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.
la source