Prévenir les attaques par force brute contre SSH?

Quel outil ou quelle technique utilisez-vous pour prévenir les attaques par force brute contre votre port ssh? J'ai remarqué dans mes journaux de sécurité que des millions de tentatives de connexion en tant qu'utilisateur via ssh étaient effectuées.

Ceci est sur une boîte FreeBSD, mais j'imagine que cela serait applicable n'importe où.

Voici un bon article de Rainer Wichmann sur ce sujet .

Il explique les avantages et les inconvénients de ces méthodes:

• Mots de passe forts
• Authentification RSA
• Utiliser 'iptables' pour bloquer l'attaque
• Utiliser le journal sshd pour bloquer les attaques
• Utiliser tcp_wrappers pour bloquer les attaques
• Port frappant

J'utilise fail2ban qui verrouille une adresse IP après plusieurs tentatives infructueuses pendant un laps de temps configurable.

Combinez cela avec des tests de résistance du mot de passe (avec John (John the Ripper)) pour vous assurer que les attaques par force brute ne réussiront pas.

Une petite chose que vous pouvez faire est d’utiliser quelque chose comme DenyHosts:

http://denyhosts.sourceforge.net/

Il utilise le fichier hosts.allow / hosts.deny intégré pour bloquer les abuseurs SSH.

• Changer le port utilisé (comme mentionné par Trent )
• Exiger des clés de chiffrement au lieu de mots de passe. http://novosial.org/openssh/publickey-auth/
• Liste noire des attaquants
• Liste blanche des utilisateurs connus pour éviter les listes noires accidentelles. (comme mentionné Samiuela)

L’un des moyens les plus simples d’éviter ces attaques est de changer le port écouté par sshd.

Comme Chris le fait remarquer, utilisez des clés de chiffrement au lieu de mots de passe.

Ajouté à cela:

• utilisez une liste blanche si possible.

Combien de personnes ou d'emplacements (avec des adresses IP publiques flottantes) avez-vous vraiment besoin d'accéder à vos connexions ssh publiques?

En fonction du nombre d'hôtes ssh publics que vous gérez et de la précision de vos critères de connexion généraux, il peut s'agir d'une configuration plus simple et maintenable permettant de limiter l'accès à quelques hôtes externes.

Si cela fonctionne pour vous, cela peut vraiment simplifier vos frais administratifs.

En plus des autres suggestions intéressantes, une chose vraiment facile à faire est de limiter le nombre de connexions entrantes. Limite à 3 connexions par minute et par IP:

iptables -A INPUT -p tcp --dport 22 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m limit --limit 3/min --limit-burst 3 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

Utilisez l'option "AllowUsers" dans sshd_config pour vous assurer que seul un petit nombre d'utilisateurs peut se connecter. Tous les autres seront rejetés, même si leur nom d'utilisateur et leur mot de passe sont corrects.

Vous pouvez même limiter les utilisateurs à se connecter depuis un hôte particulier.

par exemple,

AllowUsers user1 user2@host.example.com

Cela réduira l'espace de recherche et évitera aux anciens utilisateurs laissés par hasard de rester inactifs ou activés (bien que ceux-ci doivent bien sûr être désactivés de toute façon, il s'agit d'un moyen facile de les empêcher d'être utilisés pour une entrée basée sur SSH).

Cela n'arrête pas complètement les attaques par force brute, mais aide à réduire le risque.

Utilisez quelque chose comme ça avec PF:

table <ssh-brute>
bloc persister dans le journal rapide de l'étiquette ssh_brute
passe sur $ ext_if proto tcp à ($ ext_if) port module l'état ssh \
(max-src-conn-rate 3/10, surcharge de vidage globale)

Le port-à-porte est un moyen assez solide de garder ce genre de chose. Légèrement compliqué, parfois agaçant, mais cela fait définitivement disparaître le problème.

Le contexte est important, mais je recommanderais quelque chose comme ceci:

• Puisque vous utilisez FreeBSD, pensez à utiliser le pare-feu PF et à utiliser ses fonctionnalités de limitation de débit de connexion. Cela vous permettra d’envoyer les forçats brutaux à une liste noire s’ils se connectent fréquemment.
• Si vous devez accéder à cette boîte depuis le monde extérieur, envisagez d'utiliser une règle PF rdr pour ne pas autoriser le trafic sur le port 22, mais pour rediriger un port obscur vers celui-ci. Cela signifie que vous devez vous connecter au port 9122 au lieu de 22. C'est obscur, mais cela éloigne les heurteurs
• envisagez de passer à l'authentification par clé uniquement, rendant les attaques par dictionnaire inutiles

Suite à la suggestion de sherbang visant à limiter le débit , la longueur du délai est importante. En augmentant le délai entre les groupes de 3 tentatives de connexion de 2 minutes à 20 minutes, le nombre d'adresses IP différentes ayant effectué plus de trois tentatives de connexion a diminué, en comparant les périodes d'une semaine sur une seule de mes machines, de 44 tentatives à 3. Aucune de ces trois adresses n’a essayé plus de 11 heures.

Très anecdotique, mais auth.log est devenu beaucoup plus lisible pour moi ...

Je m'en fous. Laissez-les débarquer au port, ils ne vont pas forcer une clé.

installer OSSEC. non seulement il surveille les connexions répétées, il entrera dans un bloc temporaire avec iptables pour l'ip incriminé. Et à la fin, il vous enverra un rapport contenant les détails. il enregistre tout, ce qui est agréable. Quelqu'un a déjà essayé plus de 8000 noms de connexion pour se connecter. J'ai analysé les journaux et obtenu une belle liste d'utilisateurs;)