Pourquoi est-ce si grave?

Parce qu'il y a des tonnes de robots qui recherchent simplement sur le Web des ports ouverts et essaient de se connecter, une fois qu'un robot d'analyse trouve un SSH ouvert port, il peut être mis en file d'attente pour qu'un autre bot (ou botnet) tente de forcer le mot de passe. L'un des risques ici est que finalement, ils peuvent réussir à trouver le mot de passe et à prendre le contrôle du serveur.

Je comprends que le mot de passe peut être forcé, mais que se passe-t-il s'il s'agit d'un mot de passe qui prendrait des éternités à craquer?

Avoir un mot de passe long est une technique d'atténuation, cependant les ressources (bande passante, espace disque utilisé pour les logs et CPU par exemple) consomment une force brute l'attaque peut également être dommageable.

Atténuation

Quelques techniques pour atténuer une attaque par force brute sur SSH:

• Utilisez un autre port, ne faites pas ' t obtenir un faux sentiment de sécurité avec cela, mais de nombreux robots recherchent exclusivement 22. ( Question connexe)
• Désactiver les mots de passe SSH
• Exiger une clé privée pour se connecter
• Throttle connections
• Implémenter un IPS ( Fail2ban et Snort me vient à l’esprit)
• Restreindre la connexion par adresse IP
• Restreindre les utilisateurs qui peuvent se connecter (différent de la vérification de l’adresse IP )

Le principal risque est que la connexion initiale puisse être interceptée par un Man-In-The-Middle, donc un attaquant peut récupérer le mot de passe.

La première fois qu'un utilisateur se connecte à un serveur SSH, quelque chose de similaire à ce qui suit s'affiche:

  $ ssh scanme.nmap.org L'authenticité de l'hôte 'scanme.nmap.org (45.33.32.156)' ne peut pas être établie.L'empreinte digitale de la clé ECDSA est SHA256: 8iz5L6iZxKJ6YONmad4oMbC + m / + vI9vx5C5f + qTTGDc.Êtes-vous sûr de vouloir continuer à vous connecter (oui / non)?  

Maintenant, à moins que chaque utilisateur ne vérifie cette empreinte digitale pour s'assurer que c'est votre serveur, alors il y a un risque que leur connexion ait été interceptée (par exemple, MITM sur leur réseau interceptant directement le trafic, ou un type de piratage DNS).

C'est parce que SSH est "Trust on First Use ". Si vous vous êtes déjà connecté à cet hôte et que la clé change soudainement, le message suivant s'affiche à la place, avertissant l'utilisateur.

  @@@@@@@@@@@@@ @@@@@@@@@@@@@@@@@@@@ AVERTISSEMENT: L'IDENTIFICATION DE L'HÔTE À DISTANCE A CHANGÉ! @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IL EST POSSIBLE QUE QUELQU'UN FAIT QUELQUE CHOSE DE NASTY! Quelqu'un pourrait espionner sur vous en ce moment (attaque de l'homme du milieu)! Il est également possible que la clé d'hôte RSA vient d'être modifiée.L'empreinte digitale de la clé RSA envoyée par l'hôte distant est 5c: 9b: 16: 56: a6: cd: 11: 10: 3a: cd: 1b: a2: 91: cd: e5: 1c.Veuillez contacter votre administrateur système.Ajoutez la clé d'hôte correcte dans /home/user/.ssh/known_hosts pour supprimer ce message. clé dans /home/user/.ssh/known_hosts:1 La clé d'hôte RSA pour ras.mydomain.com a changé et vous avez demandé une vérification stricte.La vérification de la clé d'hôte a échoué.  

L'avertissement atténuera cette attaque pour les utilisateurs qui se sont déjà connectés à partir de ce client particulier.

D'autres risques moins critiques liés à l'ouverture de SSH sur Internet sont que de nombreux robots trouvent et tentent de se connecter à de tels serveurs. Si vous avez un mot de passe fort sur tous les comptes, le risque de compromission est très faible (par fort, j'entends un mot qui ne figurera certainement pas dans une liste de mots que l'attaquant peut utiliser ou créer). Les règles habituelles s'appliquent - par exemple, pas de réutilisation du mot de passe, mot de passe stocké en toute sécurité, etc. un autre service, il y a une chance que des vulnérabilités soient découvertes qui pourraient être automatiquement exploitées par de tels robots. Cependant, le risque de ceci n'est pas plus grand que celui d'un serveur Web ou d'une application Web d'être exploité. Comme tout serveur avec des services publics, une bonne stratégie de gestion des vulnérabilités est recommandée.

Voir également cette réponse, la partie relative aux messages d'avertissement SSH et au risque de continuer, même avec le public authentification par clé.

J'ai entendu à plusieurs reprises ne jamais quitter SSH avec un mot de passe ouvert sur Internet. Pourquoi est-ce si mauvais?

Je comprends que le mot de passe peut être forcé, mais que se passe-t-il s'il s'agit d'un mot de passe très fort qui prendrait des éternités à se déchiffrer?

Le très Le fort avantage de la désactivation des connexions SSH par mot de passe est vraiment d'empêcher les comptes par défaut avec des mots de passe faibles ou les utilisateurs qui choisissent des mots de passe faibles d'être forcés. À l'heure actuelle, vous n'avez peut-être que quelques comptes sans mot de passe faible, mais quelque chose pourrait être installé à l'avenir où ce n'est pas le cas. Plus vous avez de systèmes ou de complexité au fil du temps, plus le risque augmente.

Cas anecdotique: une de mes connaissances a perdu son serveur et tout ce qu'il contient parce qu'il a donné à un ami un compte avec le mot de passe changeme qui n'a pas été changé. Aucune sauvegarde à distance n'a été créée non plus, il a donc tout perdu.

Les clés SSH sont considérablement plus sécurisées par défaut. À moins que la génération de clé ne soit interrompue, le niveau de compromis le plus bas nécessite l'obtention de la clé de l'utilisateur. Alors qu'avec les mots de passe, le niveau est juste deviner quand quelqu'un expose un mot de passe faible. Il s'agit de s'assurer que les futurs échecs humains sont protégés.

Une autre chose à considérer est la possibilité de vulnérabilités (bien que connues depuis un certain temps ou zero-day) dans le démon sshd lui-même, qui pourraient être exploitées par un attaquant. Pour atténuer cela, il est préférable d'ouvrir sshd uniquement aux utilisateurs travaillant à partir d'adresses IP connues auxquelles vous faites confiance, ou via un VPN, si possible.

Il y a plusieurs raisons différentes pour lesquelles il est plus sûr d'utiliser l'authentification par clé publique plutôt que l'authentification par mot de passe:

• La clé secrète ne quitte jamais la machine cliente, il est donc plus difficile d'intercepter le secret clé que le mot de passe. Ceci est important dans le cas où un attaquant effectuer une attaque mitm contre votre première connexion où la clé d'hôte n'est pas connue auparavant. Il est également important au cas où le serveur aurait été compromis par un attaquant.
• L'utilisation de l'authentification par clé publique vous protège contre les attaques mitm complètes. Si un attaquant devait effectuer une attaque mitm contre votre première connexion, vous risquez de ne pas vérifier la clé d'hôte. Cependant, si vous utilisez l'authentification par clé publique pour vous authentifier, l'authentification est liée à l'ID de session ssh, ce qui empêche l'attaquant d'utiliser la même authentification pour transmettre la connexion au serveur légitime. Cela réduit l'attaque d'une attaque mitm complète à l'interception uniquement de la connexion, ce qui sera souvent plus facile à remarquer pour l'utilisateur. (Par exemple, lorsque l'utilisateur recherche un fichier connu pour être sur le serveur réel, mais non connu de l'attaquant, alors l'utilisateur remarquera que quelque chose ne va pas.)

Étant donné que je recommande de ne pas utiliser l'authentification par mot de passe, je déconseillerai également de la laisser activée sur votre serveur ssh pour les raisons suivantes:

• Les attaquants tenteront des attaques par force brute par mot de passe. Si vous avez un utilisateur sur le système avec un mot de passe faible, il est possible qu'une telle attaque réussisse.
• Même si tous les utilisateurs du système ont des mots de passe forts, les attaquants essaieront toujours de forcer les mots de passe. . Cela consommera des ressources sur le serveur. Parfois, j'ai vu de telles attaques par force brute être si agressives que les connexions légitimes échouaient en raison de la surcharge du serveur.
• Si vous vous habituez à ce que les serveurs ssh n'acceptent jamais les mots de passe, vous serez plus susceptible de remarquer au cas où un attaquant tenterait un jour de vous lancer une attaque mitm et de vous présenter une invite de mot de passe.

Si je comprends bien, une clé n'est pas si différente d'un mot de passe; c'est juste beaucoup, beaucoup plus long et donc plus difficile à craquer. De plus, vous avez besoin d'un mot de passe en plus.

Mais je voudrais également dire qu'il est logique de n'autoriser que certaines adresses IP à se connecter même à votre port SSH. Cela réduit les fichiers journaux et il est généralement recommandé de n'autoriser l'accès (pas la connexion) à un service si nécessaire. Par exemple, à une plage d'adresses IP du VPN de votre entreprise. Mais ne vous fiez jamais simplement à cela.

Le déplacement du port SSH est parfois suggéré, mais je vois peu d'avantages à cela.

Aussi (hors sujet): ne jamais autoriser la connexion SSH pour root .