fail2ban et l'art de verrouiller SSH sans vous verrouiller dehors

La menace est ennuyeuse, et c’est bien le point

Tout port SSH sur l’Internet public se fait marteler. Pas par un adversaire ciblé — par une marée de fond constante de devinettes de mots de passe automatisées contre root et un dictionnaire de noms d’utilisateur courants. La plupart est du bruit, et la plupart est inoffensive contre un serveur correctement configuré. Le danger, c’est que « correctement configuré » est une chaîne d’étapes, et chacune de ces étapes a un moyen de verrouiller l’administrateur dehors plutôt que l’attaquant.

Cet article porte donc moins sur fail2ban qu’il n’y paraît. fail2ban est une couche parmi trois — l’authentification par clé uniquement, un pare-feu qui garde SSH joignable, et fail2ban qui bannit les bruteforceurs — et chacune renforce les autres. Ce qui les relie est une seule discipline : ne jamais prendre une action qui pourrait couper votre propre connexion sans qu’un filet de sécurité soit en place d’abord. Mauvais ordre et c’est vous qui êtes banni, d’une machine que vous ne pouvez plus atteindre.

Avant de toucher quoi que ce soit : prouvez que vous pouvez encore entrer

L’hypothèse la plus dangereuse dans le durcissement d’un serveur est de croire que vous avez un accès par clé qui fonctionne. La reconnaissance n’est pas optionnelle ici ; c’est ce qui empêche tout l’exercice de finir sur une porte verrouillée.

• Y a-t-il seulement des clés autorisées ? ls ~/.ssh/authorized_keys /root/.ssh/authorized_keys. C’est la vérification la plus importante, parce que la section suivante désactive le login par mot de passe — et désactiver les mots de passe avec zéro clé installée est la façon dont on se verrouille dehors pour de bon.
• Que dit la config SSH actuelle ? grep -E '^(PermitRootLogin|PasswordAuthentication|Port)' /etc/ssh/sshd_config montre la posture actuelle avant que vous ne la changiez — et si quelqu’un a déjà durci cette machine.
• La config est-elle seulement valide ? sshd -t avant de commencer, pour ne pas empiler un changement sur un fichier qui ne parse déjà pas.

1. Auth par clé uniquement : la couche qui arrête réellement la marée

fail2ban reçoit l’attention, mais la couche qui met fin au brute force de mot de passe d’un coup, c’est de couper les mots de passe. La manœuvre est de sauvegarder sshd_config d’abord — cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%s) — puis de mettre PermitRootLogin no et PasswordAuthentication no, en gardant l’authentification par clé comme seule voie d’entrée.

Deux règles gouvernent cette étape, et les deux sont non négociables :

• Refuser de désactiver les mots de passe s’il n’y a aucune clé autorisée. Sans clé installée, couper l’auth par mot de passe supprime toute voie de connexion. C’est un guardrail, pas une suggestion : l’étape doit avorter plutôt que s’exécuter.
• Toujours sshd -t avant de recharger. Cela valide la config avant que le démon en marche n’y bascule. Alors seulement systemctl reload ssh (ou sshd) — un reload, qui garde votre session courante vivante, jamais un restart aveugle qui pourrait vous larguer contre un mauvais fichier.

2. Le pare-feu : autorisez SSH avant de tout refuser

Un pare-feu en deny-par-défaut est la bonne base, et c’est aussi le moyen le plus facile de vous verrouiller dehors — parce que si vous l’activez avant d’autoriser SSH, la règle qui jette le trafic entrant jette votre trafic aussi, en pleine commande. L’ordre n’est pas une préférence :

1. Autorisez SSH d’abord. ufw allow OpenSSH avant tout le reste, et confirmez que la règle est présente avant de continuer.
2. posez les défauts — ufw default deny incoming et ufw default allow outgoing — pour que seul ce que vous permettez explicitement entre ;
3. alors seulement ufw --force enable, avec ufw --force reset comme rollback si une règle se révèle mauvaise.

La règle à graver dans la mémoire : ne jamais activer le pare-feu sans SSH déjà autorisé. Ouvrez par-dessus les ports dont vos services ont réellement besoin — mais SSH vient en premier, toujours, parce que c’est le port sur lequel vous êtes debout.

3. fail2ban : bannir le bruit, par-dessus les vraies défenses

Maintenant, et seulement maintenant, fail2ban mérite sa place. Il surveille le journal d’auth et bannit temporairement une IP qui échoue à s’authentifier trop de fois — maxretry tentatives dans une fenêtre valent un bantime. L’installation est ordinaire : apt-get install -y fail2ban, puis systemctl enable --now fail2ban, et le défaut livre une jail sshd qui surveille déjà SSH.

La vérification honnête n’est pas que le service soit active — c’est fail2ban-client status sshd qui affiche la jail, son filtre, et sa liste de bans courante. Cela prouve que fail2ban surveille réellement SSH, et pas seulement qu’il tourne. Un démon en marche mais sans jail attachée au port qui vous importe est un faux sentiment de sécurité.

Ce que fail2ban ne fait pas

fail2ban est un limiteur de débit pour les échecs visibles dans les logs, et comprendre ses limites est ce qui le garde à sa juste proportion. Ce n’est pas un substitut à l’authentification par clé uniquement — il ralentit le brute force, il ne rend pas un mot de passe devinable sûr. Il ne peut bannir que ce qui apparaît dans les logs, donc une attaque qui ne déclenche jamais le filtre n’est jamais bannie. Un attaquant distribué qui tourne à travers des milliers d’IP passe sous n’importe quel seuil par IP. Et il ne fait absolument rien contre un identifiant valide — une clé volée ou fuitée passe tout droit, parce que du point de vue du log c’est une connexion légitime et réussie. fail2ban rogne le bruit ; c’est la plus faible des trois couches, pas la fondation.

La vérification qui prouve que vous êtes verrouillé, pas enfermé dehors

Dans l’ordre, et cet ordre compte : sshd -t qui revient proprement après le changement de config ; une toute nouvelle connexion SSH testée et fonctionnelle avant que l’ancienne session ne soit fermée ; ufw status montrant SSH autorisé et le pare-feu active ; fail2ban-client status sshd montrant la jail attachée et en surveillance ; et le fichier de sauvegarde présent pour qu’un rollback soit à une commande. La preuve finale d’un verrouillage SSH est toujours un nouveau login qui marche — ne supposez jamais, reconnectez toujours.

Ce que Servor apporte là-dedans

Servor livre le durcissement SSH, la baseline UFW et fail2ban comme des recettes — parmi 150+ playbooks vérifiés — et la forme d’une recette est exactement ce dont une tâche aussi facile à rater catastrophiquement a besoin. Aucune n’est un script tiré à l’aveugle : chacune commence par la reconnaissance, en lisant la config SSH courante, si des clés autorisées existent, et quels ports écoutent, pour que le run s’adapte à la machine réelle. Chaque étape porte sa propre vérification — le sshd -t, le ufw status, le fail2ban-client status sshd — si bien que le verrouillage est prouvé, pas affirmé, et les playbooks sont idempotents : une machine déjà durcie est rapportée, pas re-durcie à l’aveugle.

Les guardrails sont écrits parce que les défauts sont dangereux : la recette SSH refuse de désactiver le login par mot de passe quand il n’y a aucune clé autorisée, la recette pare-feu autorise toujours SSH avant d’activer, et les deux gardent un rollback prêt. Parce que ces étapes touchent à votre propre accès, elles sont traitées comme les opérations destructrices qu’elles sont — proposées, expliquées, et approuvées par un humain, avec une sauvegarde prise d’abord.

Et l’exécution ne quitte jamais le chemin zero-knowledge : chaque commande est signée dans votre navigateur avec une clé dérivée de votre clé de vault, relayée verbatim, et vérifiée par l’agent sur la machine avant de s’exécuter. Fait crucial, l’agent atteint le plan de contrôle via une connexion sortante — si bien que resserrer le port SSH et le pare-feu que vous durcissez ne coupe jamais votre chemin d’administration, même si vous vous êtes bel et bien verrouillé hors de SSH lui-même. La marche approfondie dans le durcissement SSH est dans l’article sur le durcissement SSH, pourquoi la plateforme ne peut pas lancer une commande que vous n’avez pas approuvée est dans l’article sur l’exécution signée, et la boucle autour de chaque commande est dans l’article Plan-Execute-Verify. Parcourez le reste du catalogue de recettes, ou voyez le tableau opérationnel dans notre guide d’exploitation des serveurs.