Est-il ok de configurer un `sudo` sans mot de passe sur un serveur cloud ?

Vous pouvez avoir le meilleur des deux mondes : l'authentification SSH à la fois 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 lorsque vous utilisez sudo.

J'utilise cette méthode 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 sur votre système :

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys

Si vous le faites, assurez-vous de protéger vos clés sur votre ordinateur avec un mot de passe. De cette façon, quelqu'un devrait pirater votre ordinateur et voler les clés pour y accéder. Ils pourraient le faire en les extrayant de la mémoire lorsqu'elles sont déverrouillées s'ils ont accès à votre compte, en craquant votre mot de passe, ou en volant votre mot de passe via un enregistreur de frappe (keylogger) ou en l'observant par-dessus votre épaule lorsque vous le tapez (regardez derrière vous!).

Vous pouvez utiliser la même clé SSH que celle que vous utilisez pour vous connecter, ou vous pouvez configurer une clé distincte que vous n'ajoutez qu'à votre agent lorsque vous utilisez sudo. Donc, si vous voulez être particulièrement prudent, vous pouvez maintenir un fichier authorized_keys distinct qui contient une clé SSH séparée que vous n'ajoutez qu'à votre agent lorsque vous avez besoin de sudo :

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo

Je restreins 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 restreindre l'utilisation de sudo aux commandes requises.

Permettre NOPASSWORD pour des commandes générales permet à quiconque accède à votre identifiant d'utilisateur d'exécuter n'importe quelles commandes. Cela pourrait résulter d'une compromission de vos identifiants, mais pourrait être aussi simple que quelqu'un assis à votre bureau pendant que vous vous éloignez un instant.

Je trouve que je n'ai pas besoin d'entrer mon mot de passe si souvent. Une fois que vous avez saisi votre mot de passe, vous pouvez exécuter plusieurs commandes si vous n'attendez pas trop longtemps entre elles. Le délai d'expiration est configurable.

Je n'utiliserais ceci que dans deux circonstances :

• Lorsque c'est absolument nécessaire pour un script automatisé qui s'exécute en tant qu'utilisateur spécifique
• Pour des tâches d'administration spécifiques (des tâches d'administration en lecture seule, pas celles qui prennent des mesures pour modifier le système) et alors seulement pour des utilisateurs spécifiques bien sûr

Par défaut, la plupart des configurations de sudo ne vous demanderont pas à nouveau pendant un certain temps dans la même session (si vous ouvrez un nouveau shell, cela n'a aucun effet). Vous pouvez contrôler ce comportement dans une certaine mesure avec le paramètre timestamp_timeout.

Un sudo sans mot de passe n'est pas aussi dangereux qu'une clé ssh sans phrase secrète, car un attaquant distant a besoin de vos identifiants pour entrer en premier lieu, mais s'ils ont réussi à compromettre votre clé privée (ou s'ils sont physiquement proches de vous et que vous vous êtes laissé connecté et déverrouillé en étant loin de la machine), la demande de mot de passe est une défense supplémentaire précieuse entre eux et l'accès privilégié.

En ce qui concerne le suivi 2 :

Si j'ai aussi une clé pour me connecter en tant que root via ssh

Cela est également préférable d'éviter, pour exactement la raison que vous décrivez. Si une connexion distante doit avoir un accès privilégié, faites-la se connecter via un compte de service et donnez-lui juste assez de contrôle pour faire son travail via sudo. Cela est bien sûr plus fastidieux à configurer, donc beaucoup ne prennent pas la peine de le faire (ce qui fonctionne en votre faveur si vous le faites, car il y a beaucoup de cibles plus faciles pour les attaquants sur lesquelles dépenser leur temps!), donc cela revient au compromis ancestral entre sécurité et commodité (astuce professionnelle : choisissez la sécurité!).

Comme vous l'avez demandé, voici mes conseils généraux sur la manière de traiter le problème sudo.

Sudo n'a pas été conçu pour fournir plus de sécurité (bien qu'il puisse le faire dans une certaine mesure)... mais plutôt pour fournir une bonne piste de vérification 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é selon ce dont l'utilisateur a spécifiquement besoin. Par exemple, si vous avez besoin qu'un utilisateur puisse se connecter et redémarrer un service bloqué, il n'a probablement pas besoin de pouvoir installer de nouveaux logiciels ou arrêter votre serveur, changer les règles du pare-feu, etc.

Il est parfois courant que les gens utilisent sudo pour s'élever au compte root, c'est-à-dire sudo su -. Une fois qu'ils font cela, vous cessez de voir qui fait quoi à partir du compte root (root peut être connecté plusieurs fois simultanément). Parfois, les gens veulent donc désactiver la commande sudo su - également. Mais, pour des raisons pratiques, si vous avez besoin d'un compte entièrement privilégié root pour l'administration, au minimum, le fait que quelqu'un émette la commande sudo su - enregistrera qui s'est élevé au rang de root et quand.

Comment je sécurise mes boîtes :

Changer le port SSH pour quelque chose d'autre que la valeur par défaut. Cela permet d'éviter les "bots" stupides qui cherchent des numéros de port puis tentent de se connecter jusqu'à ce qu'ils réussissent (ou non).

Interdire la connexion Root via SSH en utilisant le paramètre AllowRootLogin no dans votre sshd_config. Cela empêche quelqu'un de forcer l'entrée dans votre compte root. Il est généralement recommandé de ne jamais permettre à quelqu'un de se connecter directement au compte root/administrateur pour des raisons de vérification et de sécurité. Si vous autorisez la connexion directe de root, vous ne savez pas qui s'est connecté, d'où il a obtenu le mot de passe, etc. Mais, si quelqu'un se connecte avec le compte de Jimmy, puis élève ses permissions à root, vous avez une meilleure idée de par où commencer la recherche d'audit (et dont le compte réinitialiser).

Permettre uniquement aux utilisateurs nécessitant SSH d'y accéder Utilisez le paramètre AllowUsers et spécifiez explicitement les comptes qui ont besoin d'un accès SSH. Cela bloquera par défaut tous les autres comptes de SSH.

Éditez Sudoers via visudo et n'autorisez que les commandes nécessaires à l'utilisateur. Il existe de nombreux guides approfondis sur la manière de le faire, donc je ne vais pas détailler ici. Voici un début : http://ubuntuforums.org/showthread.php?t=1132821

L'idée principale est d'empêcher un compte compromis de compromettre votre machine. Par exemple, si le compte de Sally est compromis, et que Sally peut uniquement utiliser sudo pour redémarrer le serveur web, eh bien l'attaquant pourrait s'amuser à redémarrer votre serveur web en boucle, mais au moins il ne pourra pas rm -rf /votre/dossier/serveurweb ou ouvrir tous vos ports de pare-feu, etc.

Établir de bonnes règles de pare-feu qui ne permettent que les ports nécessaires pour le fonctionnement de votre boîte. En général, vous voulez tout bloquer et n'autoriser explicitement que ce dont vous avez besoin. Il existe de nombreux exemples de bonnes configurations iptables et autres pare-feu en ligne, en voici un que j'utilise (c'est un début 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 essentiel. Même si vous utilisez des clés SSH pour votre accès distant, vous devriez toujours exiger un mot de passe pour l'utilisation de Sudo. C'est un cas où sudo pourrait fournir une sécurité supplémentaire. Si quelqu'un venait à voler vos clés SSH, il serait tout de même empêché de faire quelque chose de significatif sur votre boîte s'il doit toujours forcer 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. Généralement, cela vous donnera quelque chose de plus de 8 caractères, offrant beaucoup d'entropie, mais aussi plus facile à retenir qu'un mot de passe aléatoire. Bien sûr, de bonnes pratiques en matière de mot de passe recommandent d'utiliser un mot de passe aléatoire généré par une machine pour tromper des outils de craquage comme John the Ripper, qui passera à travers la plupart des phrases de passe et des mots de passe. Non, changer E en 3 ne fonctionne pas, John détecte également ces permutations.