Pourquoi la connexion root via SSH est-elle si mauvaise que tout le monde conseille de la désactiver?
Tout le monde sur Internet conseille de désactiver la connexion root via SSH car c'est une mauvaise pratique et une faille de sécurité dans le système, mais personne n'explique pourquoi.
Qu'est-ce qui est si dangereux d'activer la connexion root (en particulier avec la connexion par mot de passe désactivée)?
Et quelle est la différence entre le nom d'utilisateur du symbole X et le mot de passe du symbole Y ou le nom d'utilisateur racine et le mot de passe du symbole X + Y du point de vue de la sécurité au cas où l'authentification par mot de passe est autorisée?
Pourquoi rooter sur SSH est mauvais
Il existe de nombreux robots qui tentent de se connecter à votre ordinateur via SSH. Ces robots fonctionnent de la manière suivante.
Ils exécutent quelque chose comme ssh root@$IP puis ils essaient des mots de passe standard comme "root" ou "password123". Ils le font aussi longtemps qu'ils le peuvent, jusqu'à ce qu'ils trouvent le bon mot de passe. Sur un serveur accessible dans le monde entier, vous pouvez voir de nombreuses entrées de journal dans vos fichiers journaux. Je peux aller jusqu'à 20 par minute ou plus.
Lorsque les attaquants ont de la chance (ou suffisamment de temps) et trouvent un mot de passe, ils ont un accès root et cela signifie que vous avez des ennuis.
Mais lorsque vous interdisez à root de se connecter via SSH, le bot doit d'abord deviner un nom d'utilisateur, puis le mot de passe correspondant. Disons donc que la liste des mots de passe plausibles contient N entrées et que la liste des utilisateurs plausibles est M entrées grande. Le bot a un ensemble de N*M entrées à tester, donc cela rend un peu plus difficile pour le bot par rapport au cas racine où il ne s'agit que d'un ensemble de taille N.
Certaines personnes diront que ce M supplémentaire n'est pas un vrai gain de sécurité et je conviens qu'il ne s'agit que d'une petite amélioration de la sécurité. Mais je pense plus à ces petits cadenas qui ne sont pas sécurisés en eux-mêmes, mais ils empêchent beaucoup de gens d'accéder facilement. Bien sûr, cela n'est valable que si votre machine n'a pas d'autres noms d'utilisateur standard, comme tor ou Apache.
La meilleure raison de ne pas autoriser root est que root peut faire beaucoup plus de dégâts sur la machine qu'un utilisateur standard. Donc, si par stupide chance ils trouvent votre mot de passe, tout le système est perdu alors qu'avec un compte utilisateur standard, vous ne pouvez manipuler que les fichiers de cet utilisateur (ce qui est toujours très mauvais).
Dans les commentaires, il a été mentionné qu'un utilisateur normal pourrait avoir le droit d'utiliser Sudo et si le mot de passe de cet utilisateur devait être deviné, le système serait également totalement perdu.
En résumé, je dirais que peu importe le mot de passe de l'utilisateur qu'un attaquant obtient. Quand ils devinent un mot de passe, vous ne pouvez plus faire confiance au système. Un attaquant pourrait utiliser les droits de cet utilisateur pour exécuter des commandes avec Sudo, l'attaquant pourrait également exploiter une faiblesse de votre système et obtenir des privilèges root. Si un attaquant avait accès à votre système, vous ne pouvez plus lui faire confiance.
La chose à retenir ici est que chaque utilisateur de votre système autorisé à se connecter via SSH est une faiblesse supplémentaire. En désactivant root, vous supprimez une faiblesse évidente.
Pourquoi les mots de passe sur SSH sont mauvais
La raison de désactiver les mots de passe est vraiment simple.
- Les utilisateurs choisissent de mauvais mots de passe!
L'idée d'essayer des mots de passe ne fonctionne que lorsque les mots de passe sont devinables. Ainsi, lorsqu'un utilisateur possède le mot de passe "pw123", votre système devient peu sûr. Un autre problème avec les mots de passe choisis par les gens est que leurs mots de passe ne sont jamais vraiment aléatoires car cela serait alors difficile à retenir.
De plus, les utilisateurs ont tendance à réutiliser leurs mots de passe, à les utiliser pour se connecter à Facebook ou à leurs comptes Gmail et pour votre serveur. Ainsi, lorsqu'un pirate obtient le mot de passe du compte Facebook de cet utilisateur, il peut accéder à votre serveur. L'utilisateur pourrait facilement le perdre par phishing ou le serveur Facebook pourrait être piraté.
Mais lorsque vous utilisez un certificat pour vous connecter, l'utilisateur ne choisit pas son mot de passe. Le certificat est basé sur une chaîne aléatoire très longue de 1024 Bits à 4096 Bits (~ 128 - 512 caractères mot de passe). De plus, ce certificat n'est là que pour se connecter à votre serveur et n'est utilisé avec aucun service extérieur.
Surveillance de l'accès root
Le commentaire de @ Philip Couling qui aurait dû être une réponse:
Il y a une raison administrative pour désactiver root. Sur les serveurs commerciaux, vous voulez toujours contrôler l'accès par personne. racine n'est jamais une personne. Même si vous autorisez certains utilisateurs à avoir un accès root, vous devez les forcer à se connecter via leur propre utilisateur, puis su - ou Sudo -i pour que leur connexion réelle puisse être enregistrée. Cela rend la révocation de tous les accès à une personne beaucoup plus simple, de sorte que même s'ils ont le mot de passe root, ils ne peuvent rien faire avec. - Philip Couling
J'ajouterais également que cela permet à l'équipe d'appliquer le principe du moindre privilège , avec une configuration Sudo appropriée (mais écrire un son semble plus facile qu'il ne l'est). Cela permet à l'équipe de mieux distribuer sans critique, sans donner la clé du château.
Liens
http://bsdly.blogspot.de/2013/10/the-hail-mary-cloud-and-lessons-learned.html
Cet article provient des commentaires et je voulais lui donner une position un peu plus importante, car il approfondit un peu plus la question des botnets qui essaient de se connecter via SSH, comment ils le font, à quoi ressemblent les fichiers journaux et ce que l'on peut faire pour les arrêter. Il a été écrit par Peter Hansteen.
Cela pourrait être l'une des raisons pour lesquelles la connexion root directe ne devrait pas être autorisée.
- Tentatives de Bruteforce. La connexion directe à la racine pourrait entraîner plus de dégâts lors d'une attaque bruteforce réussie.
- Une mauvaise configuration des clés SSH "sans mot de passe" (une erreur humaine se produit) pourrait exposer votre machine à Internet
Mais ce n'est que la pointe de l'iceberg. Vous devez configurer d'autres restrictions et configurations comme:
- Changer le port par défaut (22)
- Mots de passe et mots de passe forts
- Désactiver l'authentification basée sur l'hôte
- Créer une liste d'utilisateurs autorisés
- Configurer le délai d'inactivité
- Forcer le protocole SSHv2
- Désactiver les mots de passe vides
- Utiliser fail2ban comme mesure contre bruteforce
- Enregistrez tout
- Configurez les clés SSH et faites confiance uniquement aux clés publiques à .ssh/authorized_keys
Vous avez raison: le nom d'utilisateur racine et le mot de passe du symbole X + Y sont cryptographiquement au moins aussi sûrs qu'un nom d'utilisateur du symbole X + mot de passe du symbole Y. En fait, il est encore plus sécurisé, car les noms des gens sont faciles à deviner (les bots peuvent juste essayer john, mike, bill, etc ... et btw: c'est ce que beaucoup d'entre eux font au lieu d'essayer root). Et vous n'avez surtout pas de chance s'il s'agit d'une attaque ciblée, car si quelqu'un veut casser le serveur d'une entreprise, il ne serait pas difficile de trouver le nom (pseudo) du sysadmin.
Et dès que l'attaquant a accès au compte que l'administrateur système utilise pour les connexions ssh (puis utilise su ou Sudo pour effectuer ses tâches), il peut infecter la session de cet utilisateur avec un programme qui envoyer le mot de passe root de l'attaquant lorsque le sysadmin le tapera la prochaine fois.
C'est tout type de connexions root qui sont (ou devraient être) considérées comme de mauvaises pratiques du point de vue de la sécurité. La connexion utilisateur "normale" -> chaîne su/Sudo ajoute une piste d'audit. En langage simple: il permet de savoir qui a fait quoi.
Un cas spécial peut être celui où une seule personne a un accès root. Dans ce cas, l'utilisation de l'utilisateur "normal" supplémentaire n'ajoutera pas beaucoup de valeur (au moins, je n'ai jamais pu voir cette valeur). Mais de toute façon - vous êtes censé avoir un utilisateur simple sur le système de toute façon (pour les tâches non administratives, l'exécution de wget, etc ;-)).
Qu'est-ce qui est si dangereux d'activer la connexion root (en particulier avec la connexion par mot de passe désactivée)?
L'attaquant (bot/botnet/hacker) n'a qu'à deviner le mot de passe et a un contrôle total sur votre système, si vous êtes ouvert à Internet. De plus, aucun des comptes systèmes (www-data, proxy, etc.) ne devrait pouvoir se connecter via SSH, pour les mêmes raisons.
Si vous avez désactivé la connexion par mot de passe (à l'aide de la clé publique, par exemple), tenez compte du fait que celui qui détient la clé privée obtient un contrôle total sur votre système. Découvrez pourquoi l'utilisation de la clé publique avec un utilisateur est préférable ci-dessous.
Et quelle est la différence entre le nom d'utilisateur du symbole X et le mot de passe du symbole Y ou le nom d'utilisateur racine et le mot de passe du symbole X + Y du point de vue de la sécurité au cas où l'authentification par mot de passe est autorisée?
Le nom d'utilisateur supplémentaire peut ajouter une couche de sécurité car: a) l'attaquant doit connaître à la fois la paire, le nom d'utilisateur et le mot de passe; b) au cas où l'attaquant violerait votre système, il n'aurait pas immédiatement accès à un compte privilégié ajoutant un peu de nuance à l'attaquant.
Dans ce cas, la clé publique est également un plus, car:
- L'attaquant a besoin de votre clé publique
- L'attaquant a besoin du mot de passe (ou de la méthode d'authentification) pour obtenir des privilèges élevés
Ce n'est pas vraiment mauvais tant que vous prenez des précautions de sécurité. À titre d'exemple, vous pouvez installer CSF (Configurer le pare-feu du serveur) et définir le nombre de tentatives d'échec autorisées, donc si quelqu'un essaie, disons plus de 5 tentatives d'échec?, Alors elles sont automatiquement bloquées. Ainsi, la première partie entière du meilleur répondeur ne sera pas du tout un problème. Cela m'est arrivé plusieurs fois, et heureusement, tous les introducteurs ont été bloqués de façon permanente. Je suppose que pour un serveur, ce n'est pas un gros problème si vous êtes la seule personne qui gère le serveur, mais bien sûr s'il y a beaucoup d'administrateurs système, ou si vous travaillez dans une organisation, alors évidemment n'utilisez pas racine. Aussi pour un PC de bureau, je suppose que l'utilisation d'un autre compte est meilleure car il y a un risque de sécurité car vous utilisez beaucoup de logiciels, mais dans un serveur, vous n'allez pas pour un logiciel aléatoire auquel vous ne faites pas confiance, vous vous assurez pour les maintenir le plus bas possible. Donc, la conclusion est non, ce n'est pas vraiment dangereux si vous savez gérer correctement un serveur.