Pourquoi la connexion root via SSH est-elle si mauvaise que tout le monde recommande de la désactiver?

83

Tout le monde sur Internet conseille de désactiver la connexion root via SSH car il s’agit d’une mauvaise pratique et d’une faille de sécurité dans le système, mais personne n’explique pourquoi.

Qu'est-ce qui est si dangereux dans l'activation de la connexion root (en particulier avec la connexion par mot de passe désactivé)?

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é, dans le cas où l'authentification par mot de passe est autorisée?

ssh security root

— se ruer
source

2

Avoir un utilisateur root dans la plupart des systèmes est mauvais en soi, laissez-le seul pour permettre une connexion SSH pour ledit utilisateur!

— Suman

1

Une connexion racine via ssh est nécessaire pour ehealth-aussie.blogspot.com/2012/01/… . Tout est un compromis.

— emory

2

Umm ... devrions-nous déplacer cette question à la sécurité? Étant donné que le sujet est davantage axé sur la sécurité que les systèmes * nix.

— Braiam

1

Il y a une raison administrative pour désactiver la racine. Sur les serveurs commerciaux, vous voulez toujours contrôler l'accès par personne. la 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 -iafin que leur connexion réelle puisse être enregistrée. Cela simplifie beaucoup la révocation de tout accès à une personne, de sorte que même s'ils ont le mot de passe root, ils ne peuvent rien faire avec.

— Philip Couling

62

Pourquoi root sur SSH est mauvais

Il y a beaucoup de robots qui essaient de se connecter à votre ordinateur via SSH. Ces robots fonctionnent de la manière suivante.

Ils exécutent quelque chose comme ssh root@$IPet ensuite ils essayent 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 assez de temps) et trouvent un mot de passe, ils ont un accès root et cela signifie que vous êtes en difficulté.

Mais lorsque vous n'autorisez pas root à se connecter via SSH, le bot doit d'abord deviner un nom d'utilisateur, puis le mot de passe correspondant. Supposons donc que la liste des mots de passe plausibles comporte des Nentrées et que la liste des utilisateurs plausibles comporte de Mgrandes entrées. Le bot a un ensemble d' N*Mentrées à tester, ce qui le rend un peu plus difficile par rapport au cas racine où il ne s'agit que d'un ensemble de taille N.

Certaines personnes diront que cet ajout Mn’est pas un réel gain de sécurité et je conviens que ce n’est qu’une petite amélioration de la sécurité. Mais je pense plus à cela que ces petits cadenas qui, en soi, ne sont pas sécurisés, mais empêchent beaucoup de gens d’y avoir facilement accès. Bien entendu, cela n’est valable que si votre ordinateur ne possède aucun autre nom d’utilisateur standard, tel que tor ou apache.

La meilleure raison de ne pas autoriser root est que root peut causer beaucoup plus de dégâts à la machine qu'un utilisateur standard. Donc, si par hasard 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 sudoet que si son mot de passe était deviné, le système serait totalement perdu.

En résumé, je dirais que le mot de passe d'un attaquant n'a pas d'importance. 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, pourrait également exploiter une faiblesse de votre système et obtenir les privilèges root. Si un attaquant avait accès à votre système, vous ne pouvez plus lui faire confiance.

Ce qu'il faut retenir ici, c'est que chaque utilisateur de votre système autorisé à se connecter via SSH constitue une faiblesse supplémentaire. En désactivant root, vous supprimez une faiblesse évidente.

Pourquoi les mots de passe sur SSH sont mauvais

La raison pour désactiver les mots de passe est très 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 a le mot de passe "pw123", votre système devient instable. Un autre problème avec les mots de passe choisis par les utilisateurs est que leurs mots de passe ne sont jamais vraiment aléatoires, car il serait alors difficile de s'en souvenir.

En outre, les utilisateurs ont tendance à réutiliser leurs mots de passe, en se connectant à Facebook ou à leurs comptes Gmail et à votre serveur. Ainsi, lorsqu'un pirate informatique obtiendra le mot de passe du compte Facebook de cet utilisateur, il pourra accéder à votre serveur. L'utilisateur pourrait facilement le perdre par le biais de l'hameçonnage ou le serveur de 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 allant de 1024 bits à 4096 bits (mot de passe ~ 128 - 512 caractères). De plus, ce certificat est uniquement là pour vous connecter à votre serveur et n'est utilisé avec aucun service extérieur.

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 la question des réseaux de zombies qui essaient de se connecter via SSH, comment ils le font, comment les fichiers de log se présentent et que peut-on faire pour les en empêcher? Il a été écrit par Peter Hansteen.

— Raphael Ahrens
source

10

Bon résumé. Mais les clés privées ssh peuvent également être volées.

— Faheem Mitha

16

@Faheem Mitha Ouais, mais volé est différent de deviné, ce que les bots font. De plus, votre clé privée est uniquement entre vos mains (ou disque dur) et non entre les mains de tiers tels que Stack Exchange ou Google.

— Raphael Ahrens

2

+1 Cette réponse pourrait en fait se résumer simplement N*M > N. Comme la plupart des * nix hôtes ont un rootutilisateur, si vous autorisez root à se connecter directement à partir d'un hôte distant, la taille de la matrice de test correspond au nombre de mots de passe à essayer. En refusant les connexions directes à la racine, le nombre de combinaisons possibles est multiplié par le nombre de noms d'utilisateur que vous souhaitez tester (et rien ne garantit que vous testerez des noms d'utilisateur valides!).

— un CVn

3

@ MichaelKjörling J'ajouterais qu'il n'est pas difficile d'obtenir le nom d'utilisateur, car normalement le nom d'utilisateur n'est pas un secret et je pourrais probablement demander à n'importe qui de l'obtenir. Mais cela aide contre les Bots et d'essayer simplement.

— Raphael Ahrens

2

@ Tout le monde, si le nom d'utilisateur a X symboles et le mot de passe Y il y a # of X length words* # of Y length wordscombinaisons possibles à essayer. Lorsque le nom d'utilisateur est fixe (par exemple, root) mais que le mot de passe est composé de symboles X + Y longs, il existe # of X+Y length wordsdes mots de passe possibles. Et # of X+Y length words=# of X length words * # of Y length words

— skarap

10

Cela pourrait être une des raisons pour lesquelles la connexion directe à la racine ne devrait pas être autorisée.

Tentatives Bruteforce. La connexion directe à la racine pourrait causer plus de dégâts lors d’une attaque réussie par bruteforce.
Une configuration erronée sur des clés SSH "sans mot de passe" (une erreur humaine se produit) pourrait exposer votre machine à Internet.

Mais ce n’est que le TIP de l’iceberg. Vous devez configurer d'autres restrictions et configurations telles que:

Changer le port par défaut (22)
Mots de passe forts et phrase secrète
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
Utilisez fail2ban comme mesure contre la force brutale
Tout enregistrer
Configurez les clés SSH et ne faites confiance qu'aux clés publiques de .ssh / allowed_keys

5

"La connexion directe à la racine pourrait causer plus de dégâts lors d’une attaque réussie par bruteforce." Pas vraiment, comparé à une sudoconfiguration par défaut . Le véritable tueur est l'effet multiplicatif lorsque vous ne possédez aucun nom d'utilisateur sur lequel vous pouvez compter pour être valide sur un hôte donné.

— un CVn

@ MichaelKjörling - Ouais, c'est sûr que ce sudo en désordre pourrait être aussi nuisible que PermitRoot;)

Voir unix.stackexchange.com/a/2944/9454

— Monica - M. Schröder

1

Changer de port est en réalité préjudiciable dans de nombreux scénarios. Et ce n’est rien d’autre que la sécurité par l’obscurité.

— 0xC0000022L

+1 pour mentionner fail2ban, car les attaques par force brute ne concernent pas uniquement SSH, mais tout ce qui se trouve sur la machine. Vous n’avez pas besoin d’obtenir les autorisations root ou système nécessaires pour "prendre le contrôle" d’une machine à des fins pratiques (accès à des données privées, utilisation en tant que vidage de fichiers, utilisation pour le phishing, etc.).

— Eric Grange

8

Vous avez raison de dire que le nom d'utilisateur racine et le mot de passe du symbole X + Y sont cryptographiquement au moins aussi sûr qu'un nom d'utilisateur du symbole X + mot de passe du symbole Y. En fait, il est encore plus sûr, car les noms des personnes sont faciles à deviner (les robots peuvent simplement essayer de john, mike, bill, etc., et d'ailleurs: c'est ce que beaucoup d'entre eux font au lieu d'essayer root). Et vous n'avez vraiment 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) de l'administrateur système.

Et dès que l'attaquant a accès au compte utilisé par sysadmin pour les connexions ssh (puis utilise suou sudoeffectue ses tâches), il peut infecter la session de cet utilisateur avec un programme qui enverra le mot de passe root de l'attaquant lorsque ce dernier temps.

C'est n'importe quel type de login racine qui est (ou devrait être) considéré comme une mauvaise pratique du point de vue de la sécurité. La connexion "normale" de l'utilisateur -> su / sudo ajoute un journal d'audit. En clair: cela permet de savoir qui a fait quoi.

Un cas particulier 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 (du moins, je ne pourrais jamais voir cette valeur). Quoi qu'il en soit, vous êtes censé avoir un utilisateur simple sur le système (pour les tâches non administratives, exécuter wget, etc. ;-)).

— skarap
source

4

Qu'est-ce qui est si dangereux dans l'activation de la connexion root (en particulier avec la connexion par mot de passe désactivé)?

L'attaquant (bot / botnet / hacker) n'a besoin que de deviner le mot de passe et a le contrôle complet de votre système, si vous êtes ouvert à Internet. En outre, aucun des comptes système (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 d'une clé publique, par exemple), tenez compte du fait que quiconque obtient la clé privée a le contrôle complet de 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é, dans le cas où l'authentification par mot de passe est autorisée?

Le nom d'utilisateur supplémentaire peut ajouter une couche de sécurité puisque: a) l'attaquant devrait connaître à la fois la paire, le nom d'utilisateur et le mot de passe; b) au cas où un attaquant violerait votre système, il ne disposerait pas d'un accès immédiat à un compte privilégié, ce qui apporterait une nuance supplémentaire à l'attaquant.

Dans ce cas, la clé publique est également un atout, 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 les privilèges élevés

— Braiam
source

1

Très peu de mots de passe que j'utilise sont inférieurs à environ 20 caractères alphanumériques aléatoires (ensemble [A-Za-z0-9] plus quelques caractères spéciaux). 20 de ces caractères (donc 20 sur un ensemble de 40 caractères) vous donnent environ 10 ^ 32 combinaisons. 128 bits d'entropie sont de l'ordre de 10 ^ 38. Pas une énorme différence, tout compte fait, et le serveur SSH est libre d’implémenter tout type de limitation de débit qu’il préfère, de sorte que ce n’est pas comme si vous meniez une attaque par force brute hors ligne dans ce cas. Il n'y a rien de mal avec les mots de passe, si vous pouvez vivre avec eux étant aussi difficile à retenir qu'une clé de 128 bits.

— un CVn

@michael chut ... ne donnez pas la portée, maintenant les pirates savent qu'ils devraient utiliser des tables arc-en-ciel de l'ordre de 20 caractères ...?

— Braiam

6

Les tables @Braiam Rainbow ne sont utiles que si l'attaquant a accès aux hachages pour effectuer une recherche hors ligne. Dans le cas présent, l'attaquant ne peut vérifier que la réponse du serveur, ce qui est probablement limité à autant de tentatives - et beaucoup plus lente.

— Peter

@Peter ups, j'ai bousillé dictionnaire et hachages, mais de toute façon, l'OP a demandé pourquoi il ne devrait pas utiliser des mots de passe faibles ou vides, ce qui est ridicule, donc je suis venu avec des situations ridicules, pourquoi il ne devrait pas. Désolé de ne pas avoir été interprété de cette façon et d'avoir été pris pour FUD.

— Braiam

2

Si vous avez envie d'essayer des mots de passe de 1.8 * 10 ^ 35 (et ceci ne concerne que la plage de 18 à 22 caractères aléatoires sur un ensemble de 40, et que vous ne sachiez pas quels caractères se trouvent en dehors de cet ensemble [A-Za-z0- 9] J'utilise), j'ai presque dit amusez-vous. Cela équivaut à environ 117,1 bits d'entropie équivalents (2 ^ 117,1 ~ 1,78 * 10 ^ 35) et, comme @Peter l'a souligné, vous devrez probablement effectuer une attaque en ligne . Le stockage de tous ces mots de passe (sans recourir à la compression) nécessite environ 3,6 * 10 ^ 36 octets ou 3 * 10 ^ 24 TiB (et si ce chiffre est erroné de quelques ordres de grandeur, qui s'en soucie? ). Mot clé aléatoire .

— un CVn

1

Ce n'est pas vraiment mauvais tant que vous prenez des précautions de sécurité. Par exemple, vous pouvez installer CSF (Configure Server Firewall) et lui attribuer le nombre de tentatives d'échec autorisées. Ainsi, si quelqu'un tente d'exécuter plus de 5 tentatives d'échec?, Elles sont automatiquement bloquées. Ainsi, la première partie du meilleur répondeur ne posera pas de problème. Cela m'est arrivé à plusieurs reprises et, heureusement, tous les introducteurs ont été bloqués de manière permanente. Je suppose que pour un serveur ce n’est pas un gros problème si vous êtes la seule personne à gérer le serveur, mais bien sûr s’il ya beaucoup d’administrateurs système ou si vous travaillez dans une organisation, alors évidemment n’utilisez pas racine. Pour un ordinateur de bureau également, l’utilisation d’un autre compte est préférable, car il existe un risque pour la sécurité, car vous utilisez beaucoup de logiciels, mais sur un serveur, Ne choisissez pas des logiciels aléatoires auxquels vous ne faites pas confiance, mais veillez à 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.

— Don Dilanga
source