Fail2ban avancé : protéger Nginx, WordPress et la messagerie

Si vous avez suivi sécuriser SSH, Fail2ban protège déjà votre accès SSH. Mais sur un serveur web, les robots s'attaquent surtout à tout le reste : formulaires de connexion, pages d'administration, fichiers de configuration oubliés. Ce guide étend Fail2ban à Nginx, WordPress et la messagerie, et ajoute un bannissement long pour ceux qui reviennent.

1. Comment Fail2ban décide

Fail2ban assemble trois éléments dans une jail :

• un filtre, une expression régulière qui reconnaît une tentative malveillante dans un journal ;
• des seuils : maxretry tentatives dans une fenêtre de findtime déclenchent un bannissement de bantime ;
• une action, en général une règle de pare-feu qui bloque l'adresse.

Fail2ban fournit des dizaines de filtres prêts à l'emploi dans /etc/fail2ban/filter.d/. Ne modifiez jamais les fichiers .conf fournis : placez vos réglages dans des fichiers .local, qui ne sont pas écrasés par les mises à jour.

2. Une base propre avec liste blanche

Commencez par /etc/fail2ban/jail.local :

[DEFAULT]
bantime   = 1h
findtime  = 10m
maxretry  = 5
banaction = ufw
ignoreip  = 127.0.0.1/8 ::1 VOTRE_IP_FIXE

ignoreip est essentiel : ajoutez-y l'adresse de votre bureau ou de votre serveur de supervision. Sans elle, une série de connexions légitimes rapprochées, comme un script de déploiement qui se reconnecte plusieurs fois, peut vous bannir de votre propre serveur.

3. Le piège du backend

Fail2ban lit soit des fichiers de journaux, soit le journal systemd. SSH écrit dans le journal systemd, surtout sur Debian 12, alors que Nginx écrit dans des fichiers. Si vous mettez backend = systemd dans la section [DEFAULT], les jails Nginx ignorent leur logpath et ne voient jamais rien, sans aucun message d'erreur. Réglez donc le backend par jail : systemd pour SSH, auto pour les services qui écrivent dans des fichiers, comme dans les exemples ci-dessous.

4. Protéger Nginx

Ajoutez à jail.local :

[sshd]
enabled = true
backend = systemd
maxretry = 3
bantime  = 24h

[nginx-http-auth]
enabled = true
backend = auto
port    = http,https
logpath = /var/log/nginx/error.log

[nginx-botsearch]
enabled  = true
backend  = auto
port     = http,https
logpath  = /var/log/nginx/access.log
maxretry = 2

[nginx-limit-req]
enabled = true
backend = auto
port    = http,https
logpath = /var/log/nginx/error.log
maxretry = 10

• nginx-http-auth bannit les échecs répétés sur les zones protégées par mot de passe Nginx.
• nginx-botsearch repère les robots qui cherchent des pages d'administration et des scripts connus sur votre site.
• nginx-limit-req bannit les adresses qui dépassent régulièrement la limite de requêtes de Nginx. Il ne fonctionne que si vous avez configuré une directive limit_req, décrite dans limiter l'impact d'une attaque DDoS.

5. Protéger le formulaire de connexion WordPress

Aucun filtre WordPress n'est fourni. Créez /etc/fail2ban/filter.d/wordpress.conf :

[Definition]
failregex = ^<HOST> .* "POST /wp-login\.php
            ^<HOST> .* "POST /xmlrpc\.php
ignoreregex =

Puis la jail correspondante :

[wordpress]
enabled  = true
backend  = auto
port     = http,https
filter   = wordpress
logpath  = /var/log/nginx/access.log
maxretry = 5
findtime = 10m
bantime  = 6h

Un utilisateur légitime soumet le formulaire une ou deux fois ; un robot, des dizaines. Si vous hébergez plusieurs sites avec des journaux séparés, listez-les tous sur plusieurs lignes dans logpath. Pour la configuration de WordPress elle-même, voir installer WordPress sur un VPS.

6. Protéger la messagerie

Si le serveur reçoit du courrier ou authentifie des utilisateurs en SMTP :

[postfix]
enabled = true
backend = systemd
mode    = aggressive

[postfix-sasl]
enabled = true
backend = systemd
maxretry = 3

Le mode aggressive repère aussi les tentatives de relais et les adresses inexistantes. Un serveur qui ne fait qu'envoyer des notifications n'a pas besoin de ces jails : voir configurer Postfix.

7. Punir les récidivistes

Beaucoup de robots reviennent dès la fin de leur bannissement. La jail recidive lit le propre journal de Fail2ban et bannit pour une semaine toute adresse bannie plusieurs fois en une journée :

[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 3

8. Tester un filtre avant de l'activer

Un filtre qui ne correspond à rien ne protège rien ; un filtre trop large bannit vos visiteurs. Testez-le sur le vrai journal :

fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/wordpress.conf

La commande indique combien de lignes correspondent. Appliquez ensuite la configuration :

fail2ban-client -t && systemctl restart fail2ban
fail2ban-client status

La première commande vérifie la syntaxe de toute la configuration, la dernière liste les jails actives.

9. Gérer les bannissements

fail2ban-client status wordpress                  # adresses bannies par une jail
fail2ban-client set wordpress unbanip 203.0.113.10 # débannir une adresse
fail2ban-client get sshd ignoreip                 # voir la liste blanche
fail2ban-client banned                            # toutes les adresses bannies

Si vous vous êtes banni vous-même, connectez-vous depuis une autre connexion, par exemple le partage de connexion de votre téléphone, ou par la console de secours, puis débannissez votre adresse et ajoutez-la à ignoreip.

Questions fréquentes