Est-il correct de configurer `Sudo sans mot de passe sur un serveur cloud?
J'aime l'idée d'accéder aux serveurs via des clés, pour ne pas avoir à taper mon mot de passe chaque fois que je ssh dans une boîte, je verrouille même le mot de passe de mon utilisateur (pas root) (passwd -l username) il est donc impossible de se connecter sans clé.
Mais tout cela se brise si je dois saisir le mot de passe pour les commandes Sudo. Je suis donc tenté de configurer sans mot de passe Sudo pour rendre les choses conformes à la connexion sans mot de passe.
Cependant, j'ai toujours le sentiment que cela peut se retourner contre moi d'une manière inattendue, cela semble juste en quelque sorte peu sûr. Y a-t-il des mises en garde avec une telle configuration? Recommanderiez-vous/déconseillez-vous de le faire pour un compte d'utilisateur sur un serveur?
Clarifications
- Je parle de l'utilisation de
Sudodans une session utilisateur interactive ici, pas pour les services ou les scripts administratifs - Je parle d'utiliser un serveur cloud (donc je n'ai pas d'accès local physique à une machine et je ne peux me connecter qu'à distance)
- Je sais que
Sudoa un délai d'expiration pendant lequel je n'ai pas à ressaisir mon mot de passe. Mais mon concert ne consiste pas vraiment à perdre le temps supplémentaire pour taper physiquement un mot de passe. Mon idée était cependant de ne pas avoir du tout à gérer un mot de passe, car je suppose que:- Si je dois le mémoriser, c'est probablement trop court pour être sécurisé ou réutilisé
- Si je génère un mot de passe long et unique pour mon compte distant, je devrai le stocker quelque part (un programme de gestion de mot de passe local ou un service cloud) et le récupérer chaque fois que je veux utiliser
Sudo. J'espérais pouvoir éviter ça.
Donc, avec cette question, je voulais mieux comprendre les risques, les mises en garde et les compromis d'une configuration possible par rapport aux autres.
Suivi 1
Toutes les réponses indiquent que Sudo sans mot de passe n'est pas sécurisé car il permet une escalade "facile" des privilèges si mon compte d'utilisateur personnel est compromis. Je comprends que. Mais d'un autre côté, si j'utilise un mot de passe, nous encourons tous les risques classiques avec des mots de passe (chaîne trop courte ou commune, répétée sur différents services, etc.). Mais je suppose que si je désactive l'authentification par mot de passe dans /etc/ssh/sshd_config pour que vous ayez toujours une clé pour vous connecter, je peux utiliser un mot de passe plus simple pour Sudo qui est plus facile à saisir? Est-ce une stratégie valable?
Suivi 2
Si j'ai également une clé pour me connecter en tant que root via ssh, si quelqu'un a accès à mon ordinateur et vole mes clés (elles sont toujours protégées par le mot de passe du trousseau de clés du système d'exploitation!), Elles pourraient aussi bien obtenir un accès direct au compte root, en contournant le chemin Sudo. Quelle devrait être alors la politique d'accès au compte root?
J'adore l'idée d'accéder aux serveurs via des clés, pour ne pas avoir à taper mon mot de passe chaque fois que je ssh dans une boîte, je verrouille même le mot de passe de mon utilisateur (pas root) (passwd -l nom d'utilisateur), il est donc impossible de connectez-vous sans clé ... Recommanderiez-vous/déconseillez-vous de le faire pour un compte d'utilisateur sur un serveur?
Vous allez désactiver les connexions par mot de passe dans le mauvais sens. Au lieu de verrouiller le compte d'un utilisateur, définissez PasswordAuthentication no dans ton /etc/ssh/sshd_config.
Avec cet ensemble, l'authentification par mot de passe est désactivée pour ssh, mais vous pouvez toujours utiliser un mot de passe pour Sudo.
Le temps uniquement , je recommande de définir NOPASSWD dans Sudo est pour les comptes de service, où les processus doivent pouvoir exécuter des commandes via Sudo par programmation. Dans ces circonstances, assurez-vous de ne mettre explicitement en liste blanche que les commandes spécifiques que le compte doit exécuter. Pour les comptes interactifs, vous devez toujours laisser les mots de passe activés.
Réponses à vos questions de suivi:
Mais je suppose que si je désactive l'authentification par mot de passe dans/etc/ssh/sshd_config afin que vous ayez toujours une clé pour vous connecter, je peux utiliser un mot de passe plus simple juste pour Sudo qui est plus facile à taper? Est-ce une stratégie valable?
Oui c'est correct. Je recommande toujours d'utiliser des mots de passe de compte local relativement solides, mais pas ridiculement forts. ~ 8 caractères, générés aléatoirement sont suffisants.
Si j'ai également une clé pour me connecter en tant que root via ssh, si quelqu'un a accès à mon ordinateur et vole mes clés (elles sont toujours protégées par le mot de passe du trousseau de clés du système d'exploitation!), Elles pourraient tout aussi bien avoir un accès direct à la compte root, contournant le chemin Sudo.
L'accès root via ssh doit être désactivé. Période. Ensemble PermitRootLogin no dans ton sshd_config.
Quelle devrait être alors la politique d'accès au compte root?
Vous devez toujours avoir un moyen d'obtenir un accès hors bande à la console de votre serveur. Plusieurs fournisseurs de VPS fournissent cela, tout comme les fournisseurs de matériel dédié. Si votre fournisseur n'accorde pas un accès réel à la console (par exemple, EC2 par exemple), vous pouvez généralement restaurer l'accès en utilisant un processus comme celui que je décris dans cette réponse .
Je limite généralement l'utilisation de NOPASSWORD aux commandes exécutées par un processus automatisé. Il est préférable d'avoir un compte de service pour ces commandes et de limiter l'utilisation de Sudo aux commandes requises.
Autoriser NOPASSWORD pour les commandes générales permet à toute personne ayant accès à votre ID utilisateur d'exécuter n'importe quelle commande. Cela pourrait résulter d'un compromis de vos informations d'identification, mais pourrait être aussi simple que quelqu'un assis à votre bureau lorsque vous vous éloignez une seconde.
Je constate que je n'ai pas besoin de saisir mon mot de passe aussi souvent. Une fois que vous avez entré votre mot de passe, vous pouvez exécuter plusieurs commandes si vous n'attendez pas trop longtemps entre elles. Le délai est configurable.
Vous pouvez avoir le meilleur des deux mondes: l'authentification SSH pour la connexion et pour Sudo. Si vous intégrez le module pam_ssh_agent_auth vous pouvez utiliser des clés SSH pour vous authentifier sans donner de mot de passe lors de votre Sudo.
Je l'utilise en production depuis plus de cinq ans.
Pour le configurer, installez le module PAM, puis ajoutez une ligne à /etc/pam.d/Sudo ou l'équivalent de votre système:
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys
Si vous faites cela, assurez-vous de protéger vos clés sur votre ordinateur avec un mot de passe. De cette façon, quelqu'un devrait pénétrer par effraction dans votre ordinateur et voler les clés pour entrer. un enregistreur de frappe ou une épaule le surfant pendant que vous le tapez (regardez derrière vous!).
Vous pouvez utiliser la même clé SSH que vous utilisez pour vous connecter, ou vous pouvez configurer une clé distincte que vous n'ajoutez à votre agent que lorsque vous Sudo. Donc, si vous voulez être extrêmement prudent, vous pouvez conserver un fichier authorized_keys distinct qui a une clé SSH distincte que vous n'ajoutez à votre agent que lorsque vous avez besoin de Sudo:
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_Sudo
Je n'utiliserais cela que dans deux circonstances:
- Quand c'est absolument requis pour un script automatisé qui s'exécute en tant qu'utilisateur spécifique
- Pour des tâches d'administration spécifiques (lecture uniquement des tâches d'administration, pas celles qui prennent des mesures pour modifier le système), puis uniquement pour des utilisateurs spécifiques bien sûr
Par défaut, la plupart des configurations Sudo ne vous demanderont pas à nouveau pendant un certain temps dans la même session (si vous ouvrez un nouveau Shell qui n'a aucun effet). Vous pouvez contrôler ce comportement dans une certaine mesure avec le timestamp_timeout réglage.
Sans mot de passe Sudo n'est pas aussi dangereux que les clés sans mot de passe ssh, car un attaquant distant a besoin de vos informations d'identification pour entrer en premier lieu, mais s'il est entré en compromettant d'une manière ou d'une autre votre clé privée (ou si elles sont physiquement locales pour vous et que vous vous êtes laissé connecté et déverrouillé alors que vous êtes loin de la machine), la demande de mot de passe est une défense supplémentaire précieuse entre elles et un accès privilégié.
Concernant le suivi 2:
Si j'ai également une clé pour me connecter en tant que root via ssh
Il vaut mieux éviter cela aussi, exactement pour la raison que vous décrivez. Si une connexion à distance doit avoir un accès privilégié, connectez-vous via un compte de service et donnez-lui juste le contrôle nécessaire pour faire son travail via Sudo. Bien sûr, cela est plus faf à configurer, donc beaucoup ne le dérangent pas (ce qui fonctionne en votre faveur si vous le faites, car il y a beaucoup de fruits suspendus plus bas que vous pour que les attaquants y passent du temps!), Donc cela revient au compromis séculaire entre sécurité et commodité (astuce pro: choisissez la sécurité!).
Depuis que vous avez demandé, voici mes conseils généraux sur la façon de résoudre le problème Sudo.
Sudo n'a pas été conçu pour fournir plus de sécurité (bien qu'il puisse à certains égards) ... mais plutôt fournir une bonne piste d'audit de qui fait quoi sur votre système avec quels privilèges.
Un Sudo correctement configuré n'utilisera pas le paramètre ALL=(ALL) ALL, mais plutôt quelque chose de plus limité à tout ce dont l'utilisateur a spécifiquement besoin. Par exemple, si vous avez besoin d'un utilisateur pour pouvoir se connecter et redémarrer un service bloqué, il n'a probablement pas besoin d'installer un nouveau logiciel ou d'arrêter votre serveur, de changer les règles du pare-feu, etc.
Il est parfois courant que les gens utilisent Sudo pour se hisser au compte root, c'est-à-dire. Sudo su -. Une fois qu'ils le font, vous arrêtez de voir qui fait quoi à partir du compte root (root peut être connecté plusieurs fois simultanément). Donc, parfois, les gens veulent également désactiver la commande Sudo su -. Mais, pour des raisons pratiques, si vous avez besoin d'un compte disposant de tous les privilèges root pour l'administration, au moins le fait que quelqu'un émette la commande Sudo su - Enregistrera qui est passé à root et quand.
Comment je sécurise mes boîtes:
Remplacez le port SSH par autre chose que le port par défaut. Ceci permet d'éviter les dumb-bots qui recherchent les numéros de port puis martèlent jusqu'à ce qu'ils entrent ( ou pas).
Interdisez la connexion root via SSH en utilisant le paramètre AllowRootLogin no Dans votre sshd_config. Cela empêche quelqu'un de forcer brutalement votre compte root. C'est généralement une bonne pratique de ne jamais permettre à quelqu'un de se connecter directement au compte root/administrateur pour des raisons d'audit ainsi que pour des raisons de sécurité. Si vous autorisez directement la connexion root, vous ne savez pas qui s'est connecté, qui a obtenu le mot de passe, etc. Mais, si quelqu'un se connecte au compte Jimmy, puis élève ses autorisations pour rooter, vous avez une meilleure idée par où commencer votre vérifier la recherche (et le compte à réinitialiser).
Autoriser uniquement les utilisateurs à SSH qui en ont besoin Utilisez le paramètre AllowUsers et explicitez spécifiez les comptes qui nécessitent un accès SSH. Cela bloquera par défaut tous les autres comptes de SSH.
Modifier les Sudoers via visudo et n'autoriser que les commandes dont l'utilisateur a besoin. Il existe de nombreux guides détaillés sur la façon de procéder, donc je ne vais pas détail ici. Voici une entrée: http://ubuntuforums.org/showthread.php?t=1132821
L'essentiel est d'empêcher un compte compromis de mettre en danger votre machine. c'est à dire. si le compte de Sally est piraté et que Sally ne peut utiliser Sudo que pour redémarrer le serveur Web, l'attaquant pourrait s'amuser à redémarrer votre serveur Web en boucle, mais au moins ils ne peuvent pas rm -rf /your/webserver/directory ou ouvrir tous vos ports de pare-feu, etc.
Configurez de bonnes règles de pare-feu qui n'autorisent que les ports nécessaires au fonctionnement de votre box. En général, vous voulez tout supprimer et n'autoriser explicitement que ce dont vous avez besoin. Il y a beaucoup d'iptables décents et d'autres pare-feu démarrent en ligne, en voici un que j'utilise (c'est un démarreur de base):
# Generated by iptables-save v1.4.7 on Mon Mar 3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar 3 17:55:02 2014
Un mot de passe fort est également une clé. Même si vous utilisez des clés SSH pour votre accès à distance, vous devez toujours demander un mot de passe pour l'utilisation de Sudo. C'est un cas où Sudo pourrait fournir un peu plus de sécurité. Si quelqu'un volait vos clés ssh, il serait toujours empêché de faire quoi que ce soit d'important sur votre boîte s'il devait toujours forcer brutalement le mot de passe de votre compte pour utiliser Sudo. Les mots de passe ne doivent pas être un mot, mais plutôt une phrase de passe. Pensez à une phrase et utilisez-la. Cela vous donnera généralement quelque chose de plus de 8 caractères, offrant beaucoup d'entropie, mais il est également plus facile à retenir qu'un mot de passe aléatoire. Bien sûr, les bonnes pratiques de mot de passe disent d'utiliser un mot de passe aléatoire généré par la machine pour tromper les outils de craquage comme John the Ripper, qui déchireront la plupart des mots de passe et des mots de passe. Non, changer E avec 3 ne fonctionne pas, John obtient également ces permutations.
Dans certains cas, cela est nécessaire. par exemple. certaines API d'hyperviseur nécessitent une connexion sans mot de passe et sans mot de passe Sudo. Mais vous pouvez toujours restreindre cela sans casser.
Pour ce que vous essayez de réaliser. Je dirais, habituez-vous à taper un mot de passe. La sécurité est plus pratique que la commodité ici. De plus, si vous avez vraiment besoin d'un accès root, vous pouvez utiliser Sudo et il mettra en cache les informations d'identification pendant un petit moment de sorte que si vous exécutez plusieurs commandes Sudo de suite, il ne demandera le mot de passe que la première fois . Ce n'est donc pas un gros inconvénient comme vous le supposez.
De plus, si vous saisissez un grand nombre de commandes root privilégiées et que vous ne voulez pas placer Sudo devant elles tout le temps, vous pouvez soit su ou Sudo -s pour obtenir un shell racine. Vous entrerez votre mot de passe une fois et c'est tout.
J'ai été mordu par Sudo sans mot de passe une fois. C'était un script Shell, un programme d'installation qui appelé Sudo en mon nom au lieu, vous savez, de simplement exiger Sudo ou une erreur.
Imaging en tapant 'make' et le script faisant la partie 'Sudo make install' pour vous, sans définir ou afficher le chemin de base, et le script étant si braindead en premier lieu que vous n'êtes pas sûr qu'ils connaissent/usr/local et donc vous commencez à vérifier/usr pour les modifications ...
J'ai juré de ne plus jamais utiliser NOPASSWD et j'ai également changé ce paramètre de délai d'attente à 0.
Les autres réponses ici sont excellentes et touchent à la plupart des points importants. Une chose que je n'ai pas vue mentionnée est le fait que toute sorte d'authentification que vous effectuez lorsque vous êtes connecté vous-même peut être capturée par un attaquant distant qui a déjà établi une présence dans votre compte. Ils peuvent modifier vos fichiers de connexion Shell ou PATH pour installer un enregistreur de frappe afin que tout ce que vous tapez, y compris votre mot de passe Sudo, leur soit envoyé. Ils pourraient ajouter un binaire Sudo piraté à votre CHEMIN pour récupérer votre mot de passe. Ils peuvent détourner la connexion de l'agent ssh à votre machine de connexion pour vaincre pam_ssh_agent_auth et devenir root eux-mêmes dès que vous vous connectez. Donc, en termes de sécurité absolue, je ne vois pas de différence entre l'utilisation d'un mot de passe pour Sudo et non. Bien sûr, cela en fait une attaquej plus compliquée, et ils ne deviennent root qu'une fois que vous avez utilisé Sudo une fois, plutôt que immédiatement.
En résumé, je crois que la seule façon d'empêcher absolument un compte d'utilisateur compromis de devenir root si vous avez un accès Sudo est de vous retirer l'accès Sudo ou de ne jamais l'utiliser. Si vous n'êtes pas d'accord, faites-le moi savoir, car j'aimerais me tromper!
Sans répondre strictement à votre question, une autre option peut consister à définir une durée timestamp_timeout vous n'avez donc pas besoin de taper votre mot de passe si souvent. Cela empêchera quiconque d'obtenir des privilèges d'administrateur, mais réduira votre ennui.
Depuis la page de manuel sudoers :
timestamp_timeout
Nombre de minutes qui peuvent s'écouler avant que Sudo demande à nouveau un mot de passe. Le délai d'attente peut inclure un composant fractionnaire si la granularité infime est insuffisante, par exemple 2,5. La valeur par défaut est 5. Définissez cette valeur sur 0 pour toujours demander un mot de passe. S'il est défini sur une valeur inférieure à 0, l'horodatage de l'utilisateur n'expirera jamais. Cela peut être utilisé pour permettre aux utilisateurs de créer ou de supprimer leurs propres horodatages via "Sudo -v" et "Sudo -k" respectivement.
Ce billet de blog montre quelques exemples en utilisant visudo pour définir le délai d'expiration en minutes, comme:
Defaults timestamp_timeout=60
Peut-être que c'est un juste milieu entre la sécurité et la facilité d'utilisation?