À quoi ressemble vraiment une attaque brute-force SSH

L'attaque, en clair

Une attaque brute-force SSH ne vous vise pas. C'est une opération de masse : quelqu'un loue un botnet, lui donne des plages d'adresses IP et lui fait tenter une connexion sur tout ce qui répond sur le port 22. La liste de noms est courte et ennuyeuse — root, admin, ubuntu, test, git, oracle, postgres, et les comptes de service à la mode cette année.

L'économie la maintient en marche. Un shell sur une machine Linux vaut de l'argent — pour miner, comme relais, comme point d'appui vers tout ce que la machine atteint — et une tentative ne coûte pratiquement rien. Mettez un serveur neuf sur une IP publique : la première sonde arrive généralement dans l'heure, et une semaine plus tard quelques milliers d'échecs par jour n'a rien de remarquable.

Le volume est l'essentiel. Une personne qui devine votre mot de passe est une anecdote. Cent mille tentatives par mois depuis des adresses tournantes est une condition de fond, et les défenses conçues pour la première ne font rien contre la seconde.

Ce qu'ils tentent réellement

Trois comportements distincts apparaissent dans le même journal, et ils appellent des réponses différentes.

Les tentatives de connexion root sont les plus bruyantes et les moins dangereuses, car tout serveur correctement configuré a PermitRootLogin à no ou prohibit-password. Des milliers par jour signifient que les bots n'ont pas encore compris que root est indisponible — ils ne le comprennent jamais, puisque continuer à demander ne leur coûte rien.

Vient ensuite l'énumération de noms : un passage sur les comptes courants à la recherche d'un qui existe. Sur OpenSSH moderne, les écarts de temps qui rendaient cela fiable ont largement disparu, mais les bots essaient quand même, et une touche leur donne une cible.

Le credential stuffing est celui qui réussit. Des paires identifiant / mot de passe issues de la fuite de quelqu'un d'autre, rejouées contre votre serveur. Cela ressemble à un petit nombre de tentatives, pas à un flot, et cela fonctionne quand un développeur a réutilisé un mot de passe. Aucune limitation de débit ne l'attrape, puisqu'il n'y a pas de débit à limiter.

Ce que SSH offre et que les autres protocoles n'ont pas

SSH dispose d'une échappatoire que la plupart des services exposés n'ont pas : l'authentification par clé publique. Désactivez complètement l'authentification par mot de passe et toute la catégorie des attaques par devinage devient non pas plus difficile, mais impossible. Il n'y a pas de mot de passe à deviner.

C'est réellement le geste le plus fort disponible, et si vous pouvez le faire, tout le reste de cet article est secondaire. Un guide entier lui est consacré.

Cela n'arrête pas le trafic pour autant. Les bots ignorent votre configuration ; ils continuent de se connecter, de proposer des mots de passe et d'être rejetés. Chaque tentative coûte toujours une connexion TCP, un fork de sshd, une ligne de journal et une part de CPU, et votre journal d'authentification tourne toujours assez vite pour perdre les événements dont vous aviez besoin. Le tout-clé supprime le risque. Il ne supprime pas la charge.

Pourquoi la limitation de débit seule ne suffit pas

La première réponse habituelle est fail2ban, et elle est raisonnable — il est dans les dépôts de toutes les distributions et il fonctionne. Ses limites méritent d'être comprises avant d'en faire toute votre défense.

Il bannit des adresses uniques. Les botnets tournent dans une plage : bannissez 203.0.113.47 et .48 démarre une heure plus tard. Bannir le /24 met fin au passage d'un seul geste, et fail2ban ne le fait pas nativement.

Ses bannissements expirent. La valeur par défaut se compte en minutes, et le même botnet revient ce soir. Vous pouvez les allonger, mais l'état vit en mémoire et dans un fichier qui ne survit pas à une reconstruction.

Il n'apprend de personne d'autre. Chaque serveur découvre chaque attaquant indépendamment, de zéro, au prix des N premières tentatives à chaque fois.

Et il échoue silencieusement. Une regex qui ne correspond plus après une montée de version, une jail désactivée par une mise à jour de paquet, un service qui n'est pas revenu après un redémarrage — rien de tout cela ne s'annonce, et la panne ressemble exactement au calme.

Ce qui réduit réellement le trafic

Une seule chose change le volume : refuser de parler à la source. Tout le reste négocie avec elle.

Cela veut dire surveiller le flux d'échecs et, dès qu'une source franchit un seuil, la jeter au pare-feu avant que sshd n'y consacre quoi que ce soit. Trois propriétés séparent une défense qui tient d'une défense qui fuit :

• Bannir le sous-réseau, pas l'adresse. Le trafic d'attaque vient de plages d'hébergement où les adresses voisines appartiennent au même opérateur ; les utilisateurs légitimes ne partagent presque jamais un /24 avec un scanner.
• Bannir définitivement et survivre aux redémarrages. La règle doit vivre dans nftables et être restaurée au démarrage, pas dans la mémoire d'un démon.
• Se mettre soi-même en liste blanche avant d'activer quoi que ce soit. La façon la plus fréquente de tout casser est un administrateur qui bloque sa propre adresse sur un serveur qu'il n'atteint que par SSH.

Obtenir cela sans entretenir la mécanique

SSH Protector est cette logique empaquetée en agent. Il lit le même flux journald ou auth.log que vous liriez, décide localement — il continue donc de fonctionner si le réseau tombe — et maintient un unique ensemble nftables consolidé contenant toutes les plages bannies.

À l'installation, il détecte le vrai port SSH depuis la configuration de sshd au lieu de supposer 22, et met en liste blanche l'adresse depuis laquelle vous êtes connecté avant de bloquer quoi que ce soit.

Ce que vous ne pouvez pas construire seul, c'est la réputation partagée : une adresse ayant attaqué un autre client est déjà bloquée avant de vous atteindre, vous n'absorbez donc jamais ses N premières tentatives. Un serveur est gratuit à vie, ce qui suffit à observer un vrai flux d'attaques sur votre propre machine et à décider sur preuves plutôt que d'après un article.