Attaques SSH par force brute : comment les détecter et les bloquer
Ouvrez le journal d'authentification de n'importe quel serveur exposé sur Internet et vous verrez la même chose : des centaines, souvent des milliers de tentatives de connexion SSH par jour, avec des noms d'utilisateur comme root, admin, ubuntu, test ou oracle.
C'est une attaque par force brute : des robots essaient des combinaisons d'identifiants et de mots de passe en espérant tomber sur la bonne.
Comment voir les tentatives sur votre serveur
Sur Debian et Ubuntu, avec systemd :
sudo journalctl -u ssh --since "24 hours ago" | grep -E "Failed password|Invalid user" | wc -l
Pour lister les adresses IP les plus actives :
sudo journalctl -u ssh --since "24 hours ago" \
| grep -oE "from ([0-9]{1,3}\.){3}[0-9]{1,3}" | sort | uniq -c | sort -rn | head
Si vous voyez quelques dizaines de tentatives, c'est le bruit de fond normal d'Internet. Si une même adresse revient des centaines de fois, ou si les tentatives portent sur des comptes qui existent réellement chez vous, l'attaque est plus ciblée.
Pourquoi c'est dangereux même si vos mots de passe sont solides
- Un seul compte faible suffit : un compte de test oublié, un utilisateur créé par un prestataire, un mot de passe réutilisé.
- Les identifiants fuités : les robots testent des combinaisons issues de fuites de données réelles.
- La charge : des milliers de connexions consomment des ressources et noient les événements importants dans les journaux.
Les quatre mesures qui suffisent
1. Interdire les mots de passe
Dans /etc/ssh/sshd_config :
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
Avec une authentification par clé uniquement, la force brute devient sans objet : il n'y a plus de mot de passe à deviner. Vérifiez que votre clé fonctionne avant de redémarrer le service, dans une seconde session ouverte.
2. Interdire root
PermitRootLogin no
Les robots ciblent root en priorité. Connectez-vous avec un compte nominatif, puis utilisez sudo.
3. Bannir automatiquement
Un outil de bannissement lit les journaux en continu et bloque au pare-feu toute adresse qui échoue plusieurs fois en peu de temps. Une bonne configuration :
- 5 échecs en 10 minutes : bannissement de 10 minutes à 1 heure ;
- récidive : une adresse bannie plusieurs fois dans la journée est bannie plusieurs jours ;
- liste blanche : vos propres adresses fixes, pour ne jamais vous bloquer vous-même.
4. Limiter l'exposition
Si votre équipe se connecte depuis des adresses connues, n'ouvrez SSH qu'à ces adresses au niveau du pare-feu. Sinon, un port non standard réduit le bruit dans les journaux, sans être une protection en soi.
Surveiller dans la durée
Les mesures ci-dessus bloquent l'attaque. La surveillance vous dit si quelque chose a changé :
- le nombre de tentatives augmente brutalement ;
- les tentatives visent désormais vos vrais noms d'utilisateurs ;
- une connexion réussie apparaît depuis un pays inhabituel ;
- une nouvelle clé apparaît dans un fichier
authorized_keys.
Ces signaux méritent une alerte. Le reste peut être résumé dans un rapport quotidien.
Questions fréquentes
Changer le port SSH suffit-il ?
Non. Cela réduit le volume de tentatives automatiques, mais un scan de ports retrouve le nouveau port en quelques secondes. C'est un complément, pas une protection.
Le bannissement automatique peut-il me bloquer moi-même ?
Oui, si vous échouez plusieurs fois. Ajoutez vos adresses fixes en liste blanche et gardez un accès de secours (console de l'hébergeur).
Combien de tentatives par jour est-ce normal ?
Il n'y a pas de norme : cela dépend de l'exposition de votre adresse IP. Ce qui compte, c'est l'évolution d'un jour à l'autre et la présence d'adresses récurrentes.
FondateurMode installe le bannissement automatique des IP sur SSH et vous dit chaque jour combien d'attaques ont été bloquées, d'où elles viennent et lesquelles reviennent. Essai gratuit 14 jours.