Coxios

Blog

Fail2ban expliqué simplement : ce qu'il fait et comment le vérifier

Jails, bantime, findtime et maxretry, fichier jail.local, fail2ban-client status sshd, débannir une IP : comprendre fail2ban et vérifier qu'il protège ton VPS.

Équipe Coxios4 min de lecture

  • Sécurité
  • fail2ban
  • SSH
Tous les articles

Ouvre les journaux SSH d'un VPS exposé sur Internet : tu y verras des centaines de tentatives de connexion par jour, avec des noms comme admin, test ou ubuntu. Ce sont des robots qui essaient des mots de passe en boucle. fail2ban est l'outil qui les met à la porte.

Le principe tient en une phrase : fail2ban lit les journaux, repère les échecs, et quand une même adresse IP échoue trop souvent, il la bloque dans le pare-feu pendant un certain temps. Voyons comment il fonctionne, comment le régler, et surtout comment vérifier qu'il fait vraiment son travail.

Les trois pièces : filtre, jail, action

fail2ban assemble trois éléments, chacun dans son dossier sous /etc/fail2ban/ :

  • Le filtre (filter.d/) : des expressions régulières qui reconnaissent une ligne d'échec, par exemple « Failed password for root from 203.0.113.42 ». Il en existe pour SSH, nginx, Postfix, et des dizaines d'autres services.
  • L'action (action.d/) : ce qu'on fait d'une adresse fautive. Par défaut, une règle de pare-feu (iptables ou nftables) qui rejette ses paquets.
  • La jail (une « prison ») : elle relie un filtre, une source de journaux et une action, avec ses propres réglages. La jail sshd surveille SSH, une jail nginx-http-auth surveillerait les mots de passe d'un site.

bantime, findtime, maxretry

Trois réglages décident de tout. Avec maxretry = 5, findtime = 10m et bantime = 1h, la règle se lit ainsi : 5 échecs en 10 minutes depuis la même IP, et elle est bannie pendant une heure. À la fin du bannissement, fail2ban la libère tout seul.

  • maxretry : le nombre d'échecs tolérés. Trop bas, tu te bannis toi-même à la moindre faute de frappe ; 3 à 5 est un bon compromis.
  • findtime : la fenêtre de temps dans laquelle les échecs sont comptés. Les unités m, h et d sont acceptées.
  • bantime : la durée du bannissement. -1 bannit pour toujours, ce qui est rarement une bonne idée (les adresses changent de main).

Pour les récidivistes, bantime.increment = true allonge le bannissement à chaque retour de la même adresse : une heure la première fois, puis deux, puis quatre, et ainsi de suite.

Où se trouve la configuration

Ne modifie jamais /etc/fail2ban/jail.conf : une mise à jour du paquet peut l'écraser. Tes réglages vont dans /etc/fail2ban/jail.local (ou dans des fichiers de /etc/fail2ban/jail.d/), qui sont lus après et prennent le dessus. Sur Debian et Ubuntu, le paquet active déjà la jail sshd via jail.d/defaults-debian.conf.

Voici un jail.local complet pour SSH. Remplace 198.51.100.7 par ton adresse IP fixe, si tu en as une : ignoreip liste les adresses qui ne seront jamais bannies.

ini
[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
bantime.increment = true
ignoreip = 127.0.0.1/8 ::1 198.51.100.7

[sshd]
enabled = true
# Lit le journal systemd : nécessaire sur Debian 12, sans /var/log/auth.log
backend = systemd
/etc/fail2ban/jail.local. Le backend systemd demande le paquet python3-systemd.
bash
# Vérifie la configuration, puis recharge
sudo fail2ban-client -t
sudo fail2ban-client reload

Vérifier qu'il fonctionne

Un fail2ban installé mais mal réglé ne bannit personne, et rien ne te prévient. Trois commandes suffisent à t'en assurer. D'abord, le service tourne-t-il, et quelles jails sont actives ?

bash
sudo systemctl status fail2ban
sudo fail2ban-client status

Ensuite, le détail de la jail SSH :

text
$ sudo fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 2
|  |- Total failed:     143
|  `- Journal matches:  _SYSTEMD_UNIT=sshd.service + _COMM=sshd
`- Actions
   |- Currently banned: 3
   |- Total banned:     27
   `- Banned IP list:   203.0.113.42 192.0.2.77 198.51.100.23
Total failed qui reste à 0 sur un serveur exposé depuis des jours est suspect : le filtre ne lit probablement pas le bon journal.

Enfin, si tu as un doute sur le filtre, fail2ban-regex le rejoue sur les journaux existants et compte les lignes reconnues. Le journal de fail2ban lui-même, /var/log/fail2ban.log, montre chaque bannissement en direct.

bash
sudo fail2ban-regex systemd-journal sshd
sudo tail -f /var/log/fail2ban.log

Débannir une adresse IP

Ça arrive : un collègue se trompe de mot de passe cinq fois, ou c'est toi. Pour libérer l'adresse sans attendre la fin du bannissement :

bash
# Dans une jail précise
sudo fail2ban-client set sshd unbanip 203.0.113.42

# Dans toutes les jails
sudo fail2ban-client unban 203.0.113.42

# Bannir à la main une adresse qui insiste
sudo fail2ban-client set sshd banip 203.0.113.42

Ce que fail2ban ne fait pas

fail2ban réduit le bruit et ralentit les attaques par force brute, mais il ne remplace pas une connexion par clé SSH. Si les mots de passe sont désactivés, ces robots n'avaient de toute façon aucune chance : fail2ban leur fait simplement perdre leur temps ailleurs. Il ne protège pas non plus contre une faille dans une application web, et une attaque répartie sur des milliers d'adresses passe sous ses seuils.

Pense aussi aux services dans Docker : leurs ports ne passent pas par les règles habituelles du pare-feu, une jail qui les protège doit agir sur la chaîne DOCKER-USER.

À lire aussi