Fail2ban contre le brute force SSH : installation, jail sshd et dépannage

1Installer fail2ban

Sur Debian et Ubuntu : sudo apt update puis sudo apt install fail2ban. Selon la distribution, le paquet active déjà une jail sshd par défaut ; la section suivante vous donne la main sur ses réglages. Vérifiez que le service tourne avec sudo systemctl status fail2ban.

2Configurer la jail sshd dans jail.local

Ne modifiez jamais /etc/fail2ban/jail.conf : une mise à jour du paquet peut l’écraser. Créez /etc/fail2ban/jail.local, qui prend le dessus. Dans la section [sshd], les options utiles sont :

• enabled = true pour activer la jail ;
• maxretry = 5, le nombre d’échecs qui déclenche un bannissement ;
• findtime = 10m, la fenêtre de temps pendant laquelle ces échecs sont comptés ;
• bantime = 1h, la durée du bannissement (secondes, ou suffixes m, h, d) ;
• port = ssh, à remplacer par le numéro si vous avez changé le port d’écoute.

Dans la section [DEFAULT], ignoreip = 127.0.0.1/8 ::1 VOTRE_IP liste les adresses qui ne seront jamais bannies : séparez-les par des espaces et ajoutez la vôtre si elle est fixe. Testez la syntaxe avec sudo fail2ban-client -t, puis appliquez avec sudo systemctl restart fail2ban.

3Vérifier que la jail fonctionne

sudo fail2ban-client status liste les jails actives, dont sshd. sudo fail2ban-client status sshd détaille la jail : les compteurs d’échecs (Currently failed, Total failed) et les adresses bannies (Currently banned, Banned IP list). Si le compteur d’échecs reste à zéro alors que auth.log se remplit, la jail ne lit pas le bon journal : voyez l’étape de dépannage plus bas.

4Débloquer une adresse IP bannie

Pour libérer une adresse, la vôtre ou celle d’un collaborateur : sudo fail2ban-client set sshd unbanip ADRESSE_IP. Si vous êtes bloqué vous-même, passez par la console web de l’hébergeur ou son mode rescue, puis ajoutez votre adresse à ignoreip pour que cela ne se reproduise pas. Vérifiez ensuite avec sudo fail2ban-client status sshd que l’adresse a quitté la liste.

5Lire les journaux de fail2ban et de SSH

Fail2ban écrit par défaut dans /var/log/fail2ban.log : sudo grep -E "Ban|Unban" /var/log/fail2ban.log | tail -20 montre les bannissements récents. Pour les messages du service, utilisez sudo journalctl -u fail2ban --since today --no-pager. Côté SSH, sudo grep -c "Failed password" /var/log/auth.log compte les échecs ; sans ce fichier, utilisez sudo journalctl -u ssh --since today --no-pager (le service s’appelle ssh sur Debian et Ubuntu, sshd ailleurs).

Des « Failed password » ou « Invalid user » depuis de nombreuses adresses, avec des comptes génériques, sont normaux. Est préoccupante une ligne « Accepted » depuis une adresse ou à une heure inconnues : sudo grep "Accepted" /var/log/auth.log, à croiser avec last -aiF | head -30. Contrôlez aussi ~/.ssh/authorized_keys, y compris celui de root. Une seule connexion non identifiée suffit à traiter le serveur comme compromis.

6Dépanner fail2ban qui ne bannit personne

Passez en revue les causes dans cet ordre :

• Backend et journal. Sur une installation récente sans auth.log, ajoutez backend = systemd dans la section [sshd] de jail.local. À l’inverse, si logpath est défini, il doit pointer vers un fichier qui existe. Avec le backend systemd, logpath n’est pas utilisé.
• Adresse ignorée. Vos tests depuis votre propre adresse ne déclenchent rien si elle figure dans ignoreip : fail2ban ignore aussi par défaut les adresses de la machine.
• Seuils trop larges. Un robot qui espace ses essais au-delà de findtime n’atteint jamais maxretry.
• Port modifié. Si Port a changé dans sshd_config, adaptez l’option port de la jail.
• Filtre. fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf indique combien de lignes le filtre reconnaît ; pour le journal systemd, remplacez le premier argument par systemd-journal.

Relancez ensuite le service et relisez fail2ban-client status sshd. Pour une panne de connexion liée à ces réglages, voyez la page sur SSH refusé.

7Passer aux clés SSH et interdire les mots de passe

Sur votre poste, ssh-keygen -t ed25519 crée une paire de clés : protégez la clé privée par une phrase secrète. Envoyez la clé publique avec ssh-copy-id -i ~/.ssh/id_ed25519.pub utilisateur@serveur et testez une nouvelle connexion. Sauvegardez ensuite sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.sauvegarde, puis réglez dans /etc/ssh/sshd_config :

• PasswordAuthentication no
• PermitRootLogin prohibit-password (ou no si vous passez par un utilisateur et sudo)
• PubkeyAuthentication yes
• MaxAuthTries 3

Sur certaines images Ubuntu, un fichier de /etc/ssh/sshd_config.d/ comme 50-cloud-init.conf peut activer PasswordAuthentication yes, et la première valeur rencontrée l’emporte. Vérifiez avec sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin', validez avec sudo sshd -t, puis sudo systemctl reload ssh, sans fermer votre session ouverte. Testez une seconde connexion avant de quitter.

8Filtrer SSH au pare-feu

Si vous administrez depuis une adresse fixe ou un VPN, limitez l’accès : sudo ufw allow from VOTRE_IP to any port 22 proto tcp. Autorisez SSH avant d’activer le pare-feu (sudo ufw enable), sans quoi vous perdez l’accès. Changer le port d’écoute allège les journaux, mais n’arrête pas un attaquant qui scanne : ce n’est pas une mesure de sécurité. Installez enfin les mises à jour de sécurité avec unattended-upgrades et relisez de temps en temps les « Accepted » de auth.log.