Quels sont les avantages / inconvénients des différentes méthodes pour bloquer les attaques SSH par force brute?

Il existe un certain nombre de packages différents pour bloquer les adresses IP à partir desquelles des attaques SSH par force brute sont lancées sur votre système. Par exemple:

• DenyHosts
• Sshguard
• fail2ban

Quels sont les avantages / inconvénients de ceux-ci ou d'autres?

Ma solution actuelle consiste à prendre l'e-mail que logwatch génère chaque jour et à vider les adresses IP flagrantes dans un fichier texte que j'alimente dans un script qui reconstruit ensuite iptables. C'est hacky, chronophage et manuel, et j'aimerais mieux.

(Notez que je n'ai pas demandé quelle était la "meilleure" façon de résoudre le problème, car il n'y a pas de "meilleure" façon de faire quoi que ce soit.)

J'utilise DenyHosts, donc je peux au moins répondre à cela:

Avantages

• C'est complètement automatique
• Il est configurable (combien de tentatives ont échoué avant la mise sur liste noire, pour les noms d'utilisateur qui n'existent pas, les noms d'utilisateur qui existent et une entrée spéciale pour root)
• Il peut vous envoyer par e-mail périodiquement une liste des nouveaux hôtes sur liste noire et / ou exécuter un programme donné chaque fois qu'un nouvel hôte est sur liste noire.
• Il prend en charge la suppression automatique de la liste noire des hôtes après un certain temps

Les inconvénients

Je n'ai aucun inconvénient irréparable, tant que vous l'utilisez correctement:

• Dans sa configuration par défaut, il ne vous alertera pas sur les nouveaux hôtes sur liste noire, donc si quelqu'un attaque votre réseau à partir de centaines d'adresses différentes, vous ne le remarquerez peut-être pas tout de suite comme vous le feriez si vous surveillez vos journaux manuellement, mais (comme mentionné dans la section pros) il peut vous envoyer un e-mail ou exécuter un exécutable pour vous alerter lorsque de nouveaux hôtes sont ajoutés
• Par défaut, il mettra vos hôtes sur liste noire comme tous les autres, vous voudrez donc probablement les ajouter /etc/hosts.allow. Je me suis bloqué une fois en échouant à taper mon mot de passe, et une fois que quelqu'un du travail a essayé de se connecter à mon compte root pour plaisanter et a mis ma liste d'adresses IP sur liste noire, et il m'a fallu quelques jours pour comprendre pourquoi je ne pouvais pas me connecter soudainement à mon réseau du travail plus

Un autre est fail2ban , qui repose sur iptables (donc il fonctionne avec n'importe quel service, pas seulement ssh). Avec fail2ban, vous pouvez:

• Spécifiez le chemin d'accès à n'importe quel fichier journal (apache, ssh, nginx, serveur de messagerie, ...).
• Spécifiez l'expression régulière pour les modèles d'attaque (par exemple, plus de 10 "404 erreurs" par la même adresse IP sur le journal d'accès nginx en 6 secondes)
• Spécifiez l'expression régulière pour ignorer certains modèles (très utile!)
• Spécifiez le temps d'interdiction
• Envoyer un email (ou toute autre alerte ...)
• Entièrement personnalisable (vous pouvez écrire vos propres alertes et filtres)

Un "inconvénient" de DenyHosts est qu'il nécessite des wrappers tcp, donc il ne fonctionnera qu'avec les services qui regardent le fichier /etc/hosts.deny. Mais pour être juste avec DenyHosts, sshd est compilé pour utiliser TCP Wrappers sur la plupart des distributions Linux. Je trouve également que DenyHosts est plus facile à configurer hors de la boîte que fail2ban (mais moins puissant).

Référence à une question SF similaire

Une protection simple et efficace contre les attaques basées sur l'analyse consiste à ne pas utiliser le port standard. 443 (le port https) vous expose à différentes attaques par force brute qui ne vont pas casser vos mots de passe faibles et peut éventuellement passer par plus de pare-feu que le port par défaut (22).

La plupart des méthodes pour empêcher les attaques par force brute ssh sont d'excellents moyens de s'auto-faire (oups, j'ai foiré la configuration! , l'attaquant vient de / a subverti une machine dans le même sous-réseau que moi (plage IP dynamique, réseau universitaire ...) et je suis banni aussi!).

Si vous ne vous connectez qu'à partir de quelques endroits, vous pouvez simplement mettre en liste blanche les adresses IP source. Ce n'est évidemment pas bon si vous voulez utiliser votre ordinateur portable ou votre téléphone portable en déplacement.

Avoir un démon ssh qui n'écoute que les connexions IPv6 devrait vous protéger des analyses pendant quelques années encore. Mais de nombreux pare-feu ne vous permettent pas de transporter IPv6 de manière raisonnable.

Une autre méthode que vous ne mentionnez pas est le portage . Il ne souffre pas de problèmes d'auto-DoS (autres qu'une mauvaise configuration), mais il ne traverse pas bien les pare-feu et peut ajouter plusieurs secondes de latence à l'établissement de la connexion.

Si vous avez de bons mots de passe ou si vous pouvez vivre sans authentification par mot de passe, désactivez l'authentification par mot de passe. (Les clés et les mots de passe à usage unique sont suffisants pour la plupart des cas d'utilisation: si vous ne faites pas suffisamment confiance à la machine cliente pour stocker une clé ssh, vous ne lui faites pas confiance non plus pour ne pas avoir un enregistreur de frappe). Ensuite, les attaques par force brute vous coûteront un peu de CPU et de bande passante mais ne vous exposent pas à une intrusion (tant que vous n'avez pas vérifié qu'aucune de vos clés ne provienne d'un OpenSSL Debian à faible entropie ).

Dans l'ensemble, notez que le changement de port ne réduit pas considérablement votre exposition. Vous obtiendrez moins d' analyse , mais tout ce que vous pouvez couper est le fruit bas qui cherche à exploiter les anciennes vulnérabilités et les mots de passe faibles. Tant que vous gardez votre démon à jour et appliquez des mots de passe raisonnables ou des limites de taux de tentatives raisonnables, le changement de port est plus une responsabilité qu'une mesure de sécurité.