Prévenir les attaques par force brute contre SSH?


49

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ù.

Réponses:


25

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

39

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.


4
Fail2ban est excellent. Il était simple de l' étendre à écran / var / log / maillog et obtenir d'interdire les spammeurs persistants de frapper mon serveur de messagerie
Dave Cheney

Fail2ban peut être combiné avec une chaîne iptables qui envoie du trafic TCP à la TARPITcible, si vous vous sentez vilain (de xtables-addons).
Tobu



15

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


1
Si, bien sûr, votre système peut le supporter.
C. Ross

13
Sécurité à travers l'obscurité, efficace à chaque fois.
Chris Ballance

1
Cela ne me dérangerait pas trop de changer le port, mais j’ai appris que la plupart des pare-feu (autres que le mien) ont tendance à verrouiller tous les ports autres que les ports courants (80,22, 443, etc.). Si je suis derrière ces pare-feu, je ne peux pas accéder à mon serveur domestique sur ce port non standard. Pour moi c'est un non-aller.
affliger

@grieve puis changez notre pare-feu pour laisser ce port sortir?
Rory

@Roy Je parle de pare-feu autres que ceux que je possède. Par exemple, si je veux utiliser ssh sur mon ordinateur personnel depuis Starbucks, leur pare-feu bloque le port sortant. Je ne peux pas changer ça. (Je viens juste d'utiliser Starbucks comme exemple. Je n'ai aucune idée des ports bloqués ou non).
deuil

12

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.


2
La liste blanche est extrêmement importante si vous faites une liste noire à moins que vous ne vouliez être en lock-out.
Ryaner

2
+1 pour une liste blanche proactive.
Chris Ballance

3
+1 pour avoir la meilleure réponse absolue. Ces deux choses sont les seules mesures raisonnables et elles sont très efficaces. Soit seul vaut la peine, et les deux ensemble plus. Boo sur les autres réponses préconisant la sécurité par l'obscurité!
DWC

11

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

Je peux peut-être mal comprendre quelque chose, mais de nombreux navigateurs grand public se connectent entre 4 et 6 connexions à la fois, même si la norme HTTP le fixe à 2.
Joshua Enfield

1
Oui, cela poserait un problème si vous tentiez de limiter le port 80. Vous ne vous connectez pas à ssh avec votre navigateur Web. Les sessions ssh sont des sessions de longue durée qui conservent l'état et non des sessions sans état de courte durée, comme http. Mettre en parallèle des sessions ssh comme ça n'a pas de sens. Cela ne veut pas dire qu'il n'y a pas une utilisation de niche de SSH que cela briserait, mais c'est rare.
Sherbang

Cette solution n’est pas très bonne si, comme moi, vous utilisez Subversion via ssh. Une seule requête SVN peut établir rapidement un grand nombre de connexions. Si vous fournissez ce service, vous pouvez utiliser un deuxième service sshd sur un autre port ou ajouter les adresses IP connues à la liste blanche. Je pense utiliser fail2ban ou sshdfilter pour attraper des attaques évidentes la première fois, sans punir mes utilisateurs légitimes.
paddy

bon à savoir cette option aussi ...
ZEE

6

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.


3

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)


2

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.


J'ai essayé ceci et les utilisateurs le trouvent ennuyeux. S'il n'y a qu'une ou deux personnes, cela pourrait être une bonne option et éliminerait presque les attaques par force brute
Brent

2

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

2

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 ...


1

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


-1 Avez-vous déjà entendu parler d'attaques DoS?
Chris Ballance

8
Oui, parce que SSH est le seul service susceptible d'attaques par force brute. Si vous avez un port ouvert sur Internet, vous pouvez l’utiliser pour enfoncer votre machine dans l’oubli. Vous avez probablement aussi mis votre serveur HTTP sur des ports étranges aussi, et derrière l'
appel

1

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;)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.