fail2ban contre les tentatives de connexion par force brute

Module 5: Protéger le réseau · Temps de lecture : 10 minutes

Objectif pédagogique : À l'issue de cette leçon, vous saurez configurer fail2ban pour SSH, lire son état et son journal, débloquer une adresse et expliquer ce que fail2ban protège et ne protège pas.

Notions clés : force brute, jail, filtre, action (banaction), maxretry, findtime, bantime, bantime.increment, ignoreip, backend systemd, jail.conf, jail.local et jail.d, fail2ban-client, recidive

Ceux qui secouent les poignées de porte d'Internet

Consultez le journal de SSH un jour après l'installation et vous le verrez : des centaines de tentatives de connexion, avec des noms comme root, admin, test, ubuntu et oracle, depuis des adresses du monde entier.

anna@web1:~$ sudo journalctl -u ssh --since today | grep -c "Invalid user"
412
anna@web1:~$ sudo journalctl -u ssh --since today | grep "Invalid user" | tail -n 3
nov 09 14:02:11 web1 sshd-session[20311]: Invalid user admin from 203.0.113.77 port 51522
nov 09 14:02:13 web1 sshd-session[20313]: Invalid user oracle from 203.0.113.77 port 51544
nov 09 14:02:16 web1 sshd-session[20315]: Invalid user test from 203.0.113.77 port 51560

(Sur Ubuntu, le service s'appelle ssh, sur AlmaLinux et Rocky sshd. Le nom du processus peut être sshd ou sshd-session, selon la version d'OpenSSH.) C'est une attaque par force brute : des robots qui essaient tout simplement tous les noms et mots de passe courants. Avec la connexion par clé et la connexion par mot de passe désactivée (leçon 2.2), ils n'entreront jamais, quel que soit le nombre de tentatives. Mais ils remplissent votre journal, consomment un peu de puissance de calcul, et sur les services qui exigent encore un mot de passe (un webmail, un panneau d'administration), ils peuvent être réellement dangereux.

fail2ban lit les journaux, reconnaît les tentatives échouées et bloque pour un temps dans le pare-feu une adresse qui échoue trop souvent.

La logique de fail2ban : les jails

fail2ban fonctionne avec des jails (cellules). Une jail combine trois éléments :

• un filtre : des expressions régulières qui reconnaissent les tentatives échouées dans un journal (par exemple la ligne "Invalid user ... from <adresse>") ;
• une action : ce qui se passe en cas de tentatives trop nombreuses, généralement une règle de pare-feu qui bloque l'adresse (banaction, sur Debian 13 par défaut via nftables) ;
• des seuils : combien de tentatives échouées (maxretry) dans quel délai (findtime) entraînent un blocage de quelle durée (bantime).

Les valeurs par défaut de jail.conf sont : maxretry = 5, findtime = 10m, bantime = 10m. Autrement dit : cinq tentatives échouées en dix minutes entraînent un blocage de dix minutes.

Installation et le piège de Debian 12

anna@web1:~$ sudo apt install fail2ban
anna@web1:~$ sudo systemctl status fail2ban

Sur Debian et Ubuntu, la jail pour SSH ([sshd]) est déjà active après l'installation, grâce au fichier /etc/fail2ban/jail.d/defaults-debian.conf.

Il existe un piège bien connu. fail2ban doit savoir où se trouve le journal. Autrefois, c'était le fichier texte /var/log/auth.log. Depuis Debian 12, rsyslog n'est plus installé par défaut et les messages se trouvent uniquement dans le journal de systemd (leçon 6.2). Le paquet fail2ban de Debian 12 cherchait encore /var/log/auth.log, ne le trouvait pas et ne démarrait pas. Debian 13 a corrigé cela en définissant backend = systemd pour SSH dans defaults-debian.conf. Sur Debian 12, vous corrigez vous-même le problème (voir ci-dessous) en faisant la même chose. Ubuntu dispose encore de rsyslog par défaut, mais backend = systemd y fonctionne aussi.

Vos propres réglages : jail.local

Ne modifiez jamais jail.conf : ce fichier est remplacé lors d'une mise à jour. Placez vos propres réglages dans /etc/fail2ban/jail.local ou dans un fichier de /etc/fail2ban/jail.d/ avec l'extension .local :

# /etc/fail2ban/jail.d/eigen.local
[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5
bantime.increment = true
ignoreip = 127.0.0.1/8 ::1 198.51.100.20

[sshd]
enabled = true
backend = systemd

Ce que font ces lignes :

• bantime = 1h : une heure de blocage au lieu de dix minutes.
• bantime.increment = true : celui qui revient après un blocage reçoit à chaque fois un blocage plus long.
• ignoreip : les adresses qui ne sont jamais bloquées. Indiquez ici l'adresse IP fixe de votre bureau, si vous en avez une. N'y mettez pas de grandes plages d'adresses "par précaution".
• backend = systemd : lire le journal de systemd au lieu d'un fichier texte (nécessaire sur Debian 12, recommandé partout). Le paquet python3-systemd doit pour cela être installé ; c'est généralement déjà le cas en tant que dépendance.

Recharger et vérifier :

anna@web1:~$ sudo fail2ban-client -t            # tester la configuration
OK: configuration test is successful
anna@web1:~$ sudo systemctl reload fail2ban
anna@web1:~$ sudo fail2ban-client status
Status
|- Number of jail:      1
`- Jail list:   sshd

Lire l'état, bannir et débloquer

anna@web1:~$ sudo fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed: 3
|  |- Total failed:     1288
|  `- Journal matches:  _SYSTEMD_UNIT=ssh.service + _COMM=sshd
`- Actions
   |- Currently banned: 2
   |- Total banned:     117
   `- Banned IP list:   203.0.113.77 198.51.100.140

"Currently failed" désigne les adresses qui ont déjà fait des tentatives mais n'ont pas encore dépassé le seuil. "Currently banned" désigne les adresses actuellement bloquées.

Si vous vous êtes bloqué vous-même (par exemple en essayant plusieurs fois avec la mauvaise clé ou le mauvais nom d'utilisateur), connectez-vous depuis un autre réseau ou via la console et débloquez votre adresse :

anna@web1:~$ sudo fail2ban-client set sshd unbanip 198.51.100.20

Le journal de fail2ban lui-même se trouve dans /var/log/fail2ban.log et indique quand quelle adresse a été bloquée puis débloquée :

2026-11-09 14:02:16,903 fail2ban.actions [811]: NOTICE  [sshd] Ban 203.0.113.77
2026-11-09 15:02:17,120 fail2ban.actions [811]: NOTICE  [sshd] Unban 203.0.113.77

Les récidivistes : recidive

Certains robots reviennent tout simplement après chaque blocage. Il existe deux moyens pour y remédier. bantime.increment (ci-dessus) allonge le blocage à chaque fois. Il y a aussi la jail recidive : elle lit le journal de fail2ban lui-même et bloque pendant une semaine, sur tous les ports, une adresse qui a été bloquée souvent en une journée. Pour l'activer dans votre fichier .local :

[recidive]
enabled = true

Ce que fail2ban fait et ne fait pas

fail2ban est utile, mais ce n'est pas la serrure de la porte. La serrure, c'est la connexion par clé, avec les mots de passe désactivés (leçon 2.2). Sachez donc aussi ce que fail2ban ne peut pas faire :

• Une attaque distribuée depuis des milliers d'adresses, avec une ou deux tentatives chacune, ne dépasse jamais maxretry.
• Un mot de passe faible reste faible. fail2ban ralentit les tentatives de devinette, rien de plus.
• Uniquement ce qui figure dans un journal : un service qui n'enregistre pas les tentatives échouées, ou un journal que fail2ban ne lit pas, lui échappe.
• Docker : les blocages dans la chaîne de pare-feu habituelle ne s'appliquent pas aux ports de conteneurs publiés (leçon 9.3). Pour les services en conteneur, un réglage distinct est nécessaire (action sur la chaîne DOCKER-USER).

Ce que fail2ban fait bien : garder le journal lisible, réduire la charge due aux robots et protéger les services où vous utilisez (encore) des mots de passe, comme un webmail ou un panneau d'administration. Pour ces services, il existe des filtres pour nginx, Postfix, Dovecot et bien d'autres.

Sur AlmaLinux et Rocky Linux

fail2ban y provient d'EPEL : dnf install epel-release puis dnf install fail2ban. Le paquet fail2ban installe également l'intégration avec firewalld. Le service SSH s'appelle sshd. Activez vous-même la jail dans un fichier .local ; contrairement à Debian, elle n'est pas activée automatiquement.

Résumé

• Des robots tentent de se connecter toute la journée ; avec les clés et la connexion par mot de passe désactivée, ils n'entrent pas, et fail2ban les tient en plus à distance.
• Une jail combine filtre, action et seuils (maxretry, findtime, bantime) ; par défaut 5 tentatives en 10 minutes, 10 minutes de blocage.
• Vos propres réglages vont dans jail.local ou jail.d/*.local, jamais dans jail.conf ; utilisez backend = systemd (nécessaire sur Debian 12).
• fail2ban-client status sshd affiche les adresses bannies, set sshd unbanip les débloque ; recidive et bantime.increment s'occupent des récidivistes.
• fail2ban n'arrête ni les attaques distribuées ni les mots de passe faibles, et ne voit pas d'office les ports Docker.

Quiz

Exercice

Exercice Z5.3: Lire un journal d'intrusion. Le fichier d'exemple ssh-journal-1.txt contient un extrait du journal d'un serveur SSH avec fail2ban, ainsi que la sortie de fail2ban-client status sshd. Répondez aux questions suivantes : quelle adresse a essayé le plus de noms d'utilisateur, quelle adresse a réussi à se connecter avec une clé et sous quel utilisateur, quelle adresse a été bannie et à quelle heure, et cette adresse aurait-elle aussi été bannie avec les réglages par défaut (maxretry = 5, findtime = 10m) ? Le programme compare vos réponses avec la clé de correction. Si vous avez votre propre serveur avec fail2ban, consultez-y aussi fail2ban-client status sshd.

Pour aller plus loin

• Sécuriser votre VPS : les cinq premières minutes
• Suis-je bloqué ? Votre adresse IP et notre pare-feu
• fail2ban, configuration par défaut jail.conf : https://github.com/fail2ban/fail2ban/blob/master/config/jail.conf
• Manuel jail.conf(5) : https://manpages.debian.org/trixie/fail2ban/jail.conf.5.en.html