Si vous utilisez Fail2Ban avec Nginx et WordPress, vous remarquerez tôt ou tard une chose : les mêmes adresses IP reviennent. Elles sont bannies pendant quelques minutes ou une heure, disparaissent… puis reviennent essayer /.env, /wp-login.php, /phpmyadmin ou d’autres chemins d’attaque populaires.

La solution n’est pas de rendre les filtres plus agressifs. La solution est recidive — un deuxième niveau de protection dans Fail2Ban qui analyse l’historique des bannissements et bloque à long terme les récidivistes.

Référence à la configuration précédente

Si vous n’avez pas encore la configuration de base de Fail2Ban pour Nginx et WordPress, je l’ai décrite ici :

Fail2Ban + Nginx + WordPress – configuration de base

Dans cet article, nous configurons des jail comme nginx-exploit, nginx-secure ou sshd. Recidive ne remplace pas cette configuration — il la renforce.

Comment trouver les récidivistes dans les logs

Il est d’abord utile de vérifier si le problème existe réellement. Nous extrayons des logs Fail2Ban la liste des IP qui ont été bannies le plus souvent :

grep "Ban " /var/log/fail2ban.log | awk '{print $NF}' | sort | uniq -c | sort -nr | head

Exemple de résultat (adresses partiellement anonymisées) :

13 204.76.203.18
9 41.142.XXX.XXX
8 64.89.XXX.XXX
8 50.82.XXX.XXX
8 35.243.XXX.XXX
8 34.24.XXX.XXX
7 45.166.XXX.XXX
7 34.83.XXX.XXX
7 176.42.XXX.XXX
6 49.36.XXX.XXX

Si vous voyez des nombres comme 8, 9, 13 — cela signifie que ces IP reviennent après la levée du bannissement. Un bantime court n’est pour elles qu’une simple pause technique.

Pourquoi recidive est meilleur que l’augmentation du bantime

• Vous n’avez pas besoin de bannir tout le monde pendant 24h pour une simple faute de frappe dans une URL.
• Vous ne augmentez pas le risque de bloquer des utilisateurs légitimes.
• La sanction est progressive et concerne uniquement les adresses qui reviennent.

Recidive analyse /var/log/fail2ban.log et compte combien de fois une IP a été bannie par d’autres jail. Cela permet de “neutraliser” uniquement celles qui ont déjà été bloquées à plusieurs reprises.

Configuration de recidive (5 bannissements en 24h = 7 jours de bannissement)

Ajoutez le bloc suivant dans /etc/fail2ban/jail.local :

nano /etc/fail2ban/jail.local

À la fin du fichier, collez :

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
bantime  = 7d
findtime = 1d
maxretry = 5

Enregistrez le fichier et redémarrez Fail2Ban :

systemctl restart fail2ban

Vérifiez le statut du jail :

fail2ban-client status recidive

Comment vérifier qui est proche du seuil recidive

Si vous souhaitez voir les IP qui ont déjà plusieurs bannissements et s’approchent du seuil recidive :

grep "Ban " /var/log/fail2ban.log | awk '{print $NF}' | sort | uniq -c | awk '$1 >= 3 {print}' | sort -nr

Résumé

Recidive est l’un des moyens les plus simples et les plus efficaces pour limiter les scanners et bots récurrents. Au lieu de bannir agressivement tout le monde — vous bloquez uniquement ceux qui reviennent à plusieurs reprises.

Dans un environnement avec plusieurs domaines, un reverse proxy Nginx et WordPress, c’est pratiquement un élément incontournable de la configuration : moins de bruit dans les logs, moins d’attaques répétitives et moins d’analyse manuelle.

Artykuł Fail2Ban : comment détecter les récidivistes et les bannir pendant une semaine (recidive) pochodzi z serwisu soban.

La mise à niveau de Debian de la version 12 (bookworm) vers 13 (trixie) est une opération qui doit être effectuée de manière reproductible et sans surprises, en particulier sur les serveurs et les conteneurs (par exemple Proxmox LXC ou machines virtuelles). Ci-dessous, vous trouverez un guide simple ainsi que des commandes prêtes à l’emploi pour télécharger et exécuter le script de mise à niveau.

Avant de lancer la mise à niveau : créez une sauvegarde ou un snapshot. Dans Proxmox, la meilleure option est vzdump ou un snapshot. Sur bare metal, sauvegardez au minimum /etc, les applications et les bases de données.

• Proxmox LXC / VM : sauvegarde avec vzdump ou snapshot.
• Serveur : sauvegarde de /etc, /var/www, bases de données (MySQL/PostgreSQL) et certificats SSL.

Téléchargement du script :

https://soban.pl/bash/upgrade_to_debian13.sh

1) Sauvegarde avant la mise à niveau (exemples)

Exemple de sauvegarde dans Proxmox (exécuter sur l’hôte Proxmox, remplacez CTID/VMID) :

vzdump 101 --mode snapshot --compress zstd --storage local

Exemple de sauvegarde simple du système de fichiers sur un serveur (cela ne remplace pas un snapshot complet, mais c’est mieux que rien) :

tar czf /root/backup_before_upgrade.tar.gz /etc /var/www /root

2) Télécharger le script (wget / curl)

La méthode la plus simple consiste à utiliser wget. Si la commande wget ne fonctionne pas malgré l’installation du paquet, utilisez le chemin complet /usr/bin/wget.

Variante A (wget standard) :

apt update
apt install -y wget
cd /root
wget -O upgrade_to_debian13.sh https://soban.pl/bash/upgrade_to_debian13.sh
chmod +x upgrade_to_debian13.sh

Variante B (wget avec chemin complet – utile si PATH est incorrect) :

apt update
apt install -y wget
cd /root
/usr/bin/wget -O upgrade_to_debian13.sh https://soban.pl/bash/upgrade_to_debian13.sh
chmod +x upgrade_to_debian13.sh

Variante C (curl) :

apt update
apt install -y curl
cd /root
curl -fsSL -o upgrade_to_debian13.sh https://soban.pl/bash/upgrade_to_debian13.sh
chmod +x upgrade_to_debian13.sh

3) Aide du script (paramètres)

Avant d’exécuter la mise à niveau, affichez la liste des paramètres disponibles et des exemples d’utilisation :

cd /root
./upgrade_to_debian13.sh --help

4) Mise à niveau Debian 12 → Debian 13 (système uniquement)

Si vous utilisez actuellement Debian 12 (bookworm) et souhaitez effectuer la mise à niveau du système :

cd /root
./upgrade_to_debian13.sh

Le script sauvegarde /etc/apt/sources.list, remplace les dépôts par trixie, exécute apt update et apt full-upgrade, puis autoremove et autoclean.

5) Détection automatique PHP/nginx et mise à jour si nécessaire

Si le conteneur ou la VM utilise une stack web et que vous souhaitez que le script détecte automatiquement PHP (nginx + fastcgi_pass) et mette à jour PHP et nginx si nécessaire :

cd /root
./upgrade_to_debian13.sh --auto

6) Forcer la mise à niveau de PHP et nginx (correction du socket PHP-FPM)

Si vous souhaitez forcer l’installation ou la mise à niveau de PHP et corriger automatiquement la configuration nginx pour utiliser le bon socket PHP-FPM :

cd /root
./upgrade_to_debian13.sh --with-php --with-nginx --php-version 8.2

Cette commande installe PHP 8.2 (php-fpm et modules courants) et remplace les anciens chemins de socket PHP-FPM dans nginx par /run/php/php8.2-fpm.sock. Ensuite, elle exécute nginx -t et recharge ou redémarre les services.

7) Déjà sur Debian 13 ? Mode PHP/nginx uniquement

Si le système est déjà sous Debian 13 (trixie) et que vous souhaitez uniquement mettre à jour PHP et nginx sans modifier les dépôts système :

cd /root
./upgrade_to_debian13.sh --php-nginx-only --with-php --with-nginx --php-version 8.2

8) Mode test (dry-run)

Si vous souhaitez voir ce que le script fera sans effectuer de modifications :

cd /root
./upgrade_to_debian13.sh --auto --dry-run

9) Diagnostic : wget installé mais ne fonctionne pas

Si apt indique que wget est installé mais que le shell affiche command not found, il s’agit généralement d’un problème PATH. La solution la plus simple est d’utiliser le chemin complet : /usr/bin/wget.

echo "$PATH"
command -v wget || true
ls -l /usr/bin/wget || true
/usr/bin/wget --version || true

Résumé

Cette solution permet de mettre à niveau Debian 12 → Debian 13 et de corriger automatiquement les problèmes courants PHP/nginx après la mise à niveau (socket PHP-FPM, test de configuration nginx, redémarrage des services). Créez toujours une sauvegarde avant la mise à niveau et commencez par exécuter --help.

Script : https://soban.pl/bash/upgrade_to_debian13.sh

Artykuł Mise à niveau automatique Debian 12 → Debian 13 avec mise à jour optionnelle de PHP et nginx pochodzi z serwisu soban.

iftop propose différentes options de filtrage permettant de limiter l’affichage à des hôtes, réseaux ou ports spécifiques. Il prend en charge IPv6 et peut afficher les adresses IP source et destination, les numéros de ports ainsi que les protocoles utilisés.

Cet outil est particulièrement utile pour surveiller le trafic en temps réel et identifier les services ou machines consommant le plus de bande passante. Il peut également aider à détecter des problèmes de performance réseau et faciliter le dépannage.

En résumé, iftop est un outil léger mais puissant, constituant un excellent complément à la boîte à outils de tout administrateur système ou réseau.

L’un des outils de surveillance réseau que j’utilise le plus est iftop. Il devient particulièrement utile lorsque la liaison réseau est saturée. En pratique, il peut aussi aider à détecter des schémas de trafic anormaux, notamment des attaques de type DoS. Dans l’exemple ci-dessous, je vais transférer un fichier volumineux vers une machine distante avec une limitation de bande passante et observer le trafic à l’aide de iftop.

Commençons par installer iftop sur la machine locale (dans cet exemple, Kali Linux) :

# apt install iftop

La distribution importe peu — iftop est disponible dans la plupart des dépôts Linux, notamment sous Debian.

Installons maintenant iftop sur la machine distante (Debian Linux) :

# apt install iftop

Pour commencer la surveillance du trafic réseau, exécutez iftop avec les paramètres -PpNn :

# iftop -PpNn

Comme je suis connecté à la machine distante via SSH, je peux voir ma session SSH active dans la liste des connexions.

Revenons maintenant à la machine locale et créons un fichier volumineux :

# truncate -s 1G 1G-file.txt

Après avoir créé le fichier de 1 Go, transférons-le vers la machine distante avec une limitation de bande passante :

# scp -l 800 -P2222 1G-file.txt soban@soban.pl:~

L’option -l 800 limite le débit à 800 Kbit/s. Pour convertir en KB/s, il faut diviser par 8, soit environ 100 KB/s.

De cette manière, il est possible d’observer à la fois le trafic sortant et entrant en temps réel. Bien que simple, iftop offre une excellente visibilité sur l’activité réseau en direct.

Lors d’attaques par force brute, on observe généralement un grand nombre de connexions de courte durée. En revanche, une attaque DoS vise à saturer la bande passante, ce qui se traduit par un trafic entrant élevé. Si l’augmentation du trafic est légitime, il est possible d’envisager une limitation du débit — des outils comme iptables peuvent être utilisés à cet effet.

Artykuł iftop comme un bon outil de surveillance du trafic réseau pochodzi z serwisu soban.

Dans cet exemple, nous utilisons Debian 11 (Bullseye). Commençons par vérifier la version du système :

# cat /etc/issue
Debian GNU/Linux 11 \n \l

Nmap est l’un des outils les plus puissants pour l’analyse réseau et les audits de sécurité. Il permet de scanner les ports ouverts, détecter les services actifs, identifier les versions logicielles et analyser les protocoles SSL/TLS ainsi que les suites de chiffrement supportées par un serveur.

L’installation sous Debian 11 est simple :

# apt install nmap

Une fois installé, nous pouvons analyser un serveur HTTPS distant. Par exemple :

# nmap -sV --script ssl-enum-ciphers -p 443 google.com

L’option -sV active la détection de version des services, tandis que --script ssl-enum-ciphers analyse les versions TLS et les suites de chiffrement disponibles. Cela permet de vérifier :

• les versions TLS activées (TLS 1.0, 1.1, 1.2, 1.3),
• la présence de chiffrements faibles comme 3DES,
• les vulnérabilités cryptographiques potentielles.

Nmap est plus lent que des outils comme sslscan, mais il fournit des informations très détaillées, particulièrement utiles pour tester une infrastructure interne.

TLS 1.0 :

TLS 1.1 :

TLS 1.2 :

L’élément essentiel lors d’une analyse SSL/TLS est de vérifier l’absence de chiffrements faibles ou obsolètes.

Si vous voyez le message suivant :

« 64-bit block cipher 3DES vulnerable to SWEET32 attack »

cela signifie que le serveur prend encore en charge 3DES, vulnérable à l’attaque SWEET32. En environnement de production, ces chiffrements doivent être désactivés.

Pour analyser un site public, vous pouvez également utiliser :

https://www.ssllabs.com/ssltest/

Cependant, pour des serveurs internes, des environnements de test ou une infrastructure privée, utiliser Nmap directement depuis Debian reste une solution efficace.

Une analyse régulière SSL/TLS permet de maintenir un niveau de sécurité élevé et d’éliminer les protocoles obsolètes ainsi que les chiffrements faibles.

Artykuł Analyse SSL et suites de chiffrement avec Nmap sous Debian 11 pochodzi z serwisu soban.