février 2026

CrowdSec – Protection intelligente des serveurs Linux contre les botnets, les attaques brute-force et le scan Internet

Posted on février 27, 2026février 27, 2026 by soban

Si vous utilisez un serveur Linux avec Nginx, SSH ou WordPress, vous connaissez probablement déjà Fail2Ban. C’est un bon outil, mais il fonctionne localement — il bloque uniquement les adresses IP ayant attaqué votre serveur.

CrowdSec fonctionne de manière totalement différente. Il s’agit d’un système de protection basé sur une réputation IP partagée. Si des milliers de serveurs dans le monde détectent une adresse IP malveillante, votre serveur peut la bloquer avant même qu’une attaque ne soit tentée.

Comment fonctionne CrowdSec ?

analyse les journaux système (nginx, ssh, wordpress)
détecte les comportements suspects
partage les informations sur les IP attaquantes avec d’autres serveurs
bloque le trafic au niveau du pare-feu

Résultat ? La majorité des bots et scanners Internet n’atteignent jamais votre serveur Nginx.

Installation de CrowdSec sur Debian / Ubuntu

L’installation de CrowdSec est très simple et disponible directement depuis les dépôts Debian.

apt update
apt install crowdsec

1 2	apt update apt install crowdsec

Pendant l’installation, CrowdSec :

crée une API locale (LAPI)
enregistre le serveur dans l’API centrale CrowdSec
télécharge les scénarios de sécurité de base

Installation du firewall bouncer

CrowdSec détecte les menaces, mais nécessite un composant d’exécution — appelé bouncer — qui bloque le trafic au niveau du pare-feu.

apt install crowdsec-firewall-bouncer

1	apt install crowdsec-firewall-bouncer

Par défaut, le bouncer utilise nftables et ajoute automatiquement des règles bloquant les adresses IP malveillantes.

Installation des collections de sécurité

Les collections contiennent des analyseurs de logs ainsi que des scénarios de détection d’attaques.

cscli collections install crowdsecurity/nginx
cscli collections install crowdsecurity/wordpress
cscli collections install crowdsecurity/base-http-scenarios
cscli collections install crowdsecurity/sshd

cscli collections install crowdsecurity/nginx

cscli collections install crowdsecurity/wordpress

cscli collections install crowdsecurity/base-http-scenarios

cscli collections install crowdsecurity/sshd

Rechargez ensuite la configuration :

systemctl reload crowdsec

1	systemctl reload crowdsec

Configuration des logs Nginx

Pour permettre à CrowdSec d’analyser le trafic HTTP, vous devez indiquer les fichiers de logs Nginx.

Éditez le fichier :

nano /etc/crowdsec/acquis.yaml

1	nano /etc/crowdsec/acquis.yaml

Ajoutez la configuration suivante :

filenames:
- /var/log/nginx/access*.log
- /var/log/nginx/error*.log
labels:
type: nginx

filenames:

- /var/log/nginx/access*.log

- /var/log/nginx/error*.log

labels:

type: nginx

Puis redémarrez le service :

systemctl restart crowdsec

1	systemctl restart crowdsec

Vérification du fonctionnement de CrowdSec

Statut du service :

systemctl status crowdsec

1	systemctl status crowdsec

Liste des bannissements actifs :

cscli decisions list

1	cscli decisions list

Statistiques :

cscli metrics

1	cscli metrics

Résultat final

Après une installation correcte de CrowdSec :

le serveur bloque automatiquement les botnets connus
les attaques WordPress et brute-force SSH sont arrêtées au niveau du pare-feu
Nginx traite beaucoup moins de trafic malveillant
la charge CPU et IO du serveur est significativement réduite

CrowdSec peut être considéré comme une évolution de Fail2Ban — un système qui ne réagit pas seulement localement, mais qui exploite une intelligence globale des menaces.

Fail2Ban : comment détecter les récidivistes et les bannir pendant une semaine (recidive)

Posted on février 26, 2026février 26, 2026 by soban

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

1	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

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

1	nano /etc/fail2ban/jail.local

À la fin du fichier, collez :

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

[recidive]

enabled = true

logpath = /var/log/fail2ban.log

bantime = 7d

findtime = 1d

maxretry = 5

Enregistrez le fichier et redémarrez Fail2Ban :

systemctl restart fail2ban

1	systemctl restart fail2ban

Vérifiez le statut du jail :

fail2ban-client status recidive

1	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

1	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.

Debian 13 (Trixie) → Proxmox VE 9 – Installation simplifiée sur un Debian pur

Posted on février 23, 2026février 24, 2026 by soban

Proxmox VE 9 est basé sur Debian 13 (Trixie) et introduit un noyau plus récent, des versions mises à jour de LXC et QEMU ainsi qu’une pile de virtualisation améliorée. Ce guide présente une méthode simplifiée et automatisée pour installer Proxmox VE 9 sur un système Debian 13 propre à l’aide de deux scripts d’installation.

La méthode suit la même approche que mon précédent guide Proxmox 8 sur Debian 12, mais adaptée à Debian 13 et Proxmox VE 9.

Prérequis

Installation fraîche de Debian 13 (Trixie)
Accès root
Connexion Internet

Toutes les commandes doivent être exécutées en tant que root.

Partie 1 – Préparation du système & installation du noyau Proxmox

Téléchargez le premier script :

wget http://soban.pl/bash/install-proxmox9-part1.sh
chmod +x install-proxmox9-part1.sh
./install-proxmox9-part1.sh

wget http://soban.pl/bash/install-proxmox9-part1.sh

chmod +x install-proxmox9-part1.sh

./install-proxmox9-part1.sh

Ce script :

Définit le nom d’hôte et met à jour le fichier /etc/hosts
Installe le trousseau (keyring) d’archives Proxmox (vérifié via SHA512)
Ajoute le dépôt Proxmox VE 9 pour Debian 13
Effectue une mise à niveau complète du système
Installe proxmox-default-kernel
Redémarre le système

Contenu de install-proxmox9-part1.sh

#!/usr/bin/env bash
set -euo pipefail
# Part 1/2: Debian 13 (Trixie) -> Proxmox VE 9
# - sets /etc/hosts
# - adds PVE repo + installs Proxmox archive keyring (verified by SHA512)
# - full-upgrade
# - installs proxmox-default-kernel
# - reboots
log() { echo "[$(date '+%F %T')] $*"; }
die() { echo "ERROR: $*" >&2; exit 1; }
if [[ "$(id -u)" -ne 0 ]]; then
die "Run as root."
fi
log "=== Proxmox VE 9 install (part 1/2) on Debian 13 Trixie ==="
if ! grep -qi 'trixie' /etc/os-release; then
log "WARNING: This does not look like Debian 13 (Trixie). Continue at your own risk."
fi
log "Network interfaces (for reference):"
ip -br -c a || true
CURRENT_HOSTNAME="$(hostname)"
CURRENT_IP="$(hostname -I | awk '{print $1}')"
read -r -p "Hostname for this node [${CURRENT_HOSTNAME}]: " HOSTNAME
HOSTNAME="${HOSTNAME:-$CURRENT_HOSTNAME}"
read -r -p "Primary IP for /etc/hosts [${CURRENT_IP}]: " IPADDR
IPADDR="${IPADDR:-$CURRENT_IP}"
if [[ -z "${HOSTNAME}" || -z "${IPADDR}" ]]; then
die "Hostname/IP cannot be empty."
fi
log "Setting hostname to: ${HOSTNAME}"
hostnamectl set-hostname "${HOSTNAME}"
log "Backing up /etc/hosts -> /etc/hosts.backup"
cp -a /etc/hosts /etc/hosts.backup
log "Writing /etc/hosts (makes hostname resolvable locally)"
cat > /etc/hosts <<EOT
127.0.0.1       localhost
${IPADDR}       ${HOSTNAME}
# IPv6
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
EOT
log "Installing prerequisites"
apt update
apt install -y wget ca-certificates gnupg
log "Installing Proxmox archive keyring to /usr/share/keyrings/proxmox-archive-keyring.gpg"
KEYRING="/usr/share/keyrings/proxmox-archive-keyring.gpg"
wget -q https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg -O "${KEYRING}"
log "Verifying SHA512 of keyring"
EXPECTED_SHA512="8678f2327c49276615288d7ca11e7d296bc8a2b96946fe565a9c81e533f9b15a5dbbad210a0ad5cd46d361ff1d3c4bac55844bc296beefa4f88b86e44e69fa51"
ACTUAL_SHA512="$(sha512sum "${KEYRING}" | awk '{print $1}')"
if [[ "${ACTUAL_SHA512}" != "${EXPECTED_SHA512}" ]]; then
die "Keyring SHA512 mismatch!
Expected: ${EXPECTED_SHA512}
Actual:   ${ACTUAL_SHA512}"
fi
log "Adding Proxmox VE 9 no-subscription repo (Trixie)"
cat > /etc/apt/sources.list.d/pve-install-repo.list <<EOT
deb [arch=amd64 signed-by=/usr/share/keyrings/proxmox-archive-keyring.gpg] http://download.proxmox.com/debian/pve trixie pve-no-subscription
EOT
log "Updating + full-upgrade"
apt update
apt full-upgrade -y
log "Installing Proxmox kernel meta-package: proxmox-default-kernel"
apt install -y proxmox-default-kernel
log "Part 1 done. Rebooting now. After reboot run: ./install-proxmox9-part2.sh"
reboot

#!/usr/bin/env bash

set -euo pipefail

# Part 1/2: Debian 13 (Trixie) -> Proxmox VE 9

# - sets /etc/hosts

# - adds PVE repo + installs Proxmox archive keyring (verified by SHA512)

# - full-upgrade

# - installs proxmox-default-kernel

# - reboots

log() { echo "[$(date '+%F %T')] $*"; }

die() { echo "ERROR: $*" >&2; exit 1; }

if [[ "$(id -u)" -ne 0 ]]; then

die "Run as root."

log "=== Proxmox VE 9 install (part 1/2) on Debian 13 Trixie ==="

if ! grep -qi 'trixie' /etc/os-release; then

log "WARNING: This does not look like Debian 13 (Trixie). Continue at your own risk."

log "Network interfaces (for reference):"

ip -br -c a || true

CURRENT_HOSTNAME="$(hostname)"

CURRENT_IP="$(hostname -I | awk '{print $1}')"

read -r -p "Hostname for this node [${CURRENT_HOSTNAME}]: " HOSTNAME

HOSTNAME="${HOSTNAME:-$CURRENT_HOSTNAME}"

read -r -p "Primary IP for /etc/hosts [${CURRENT_IP}]: " IPADDR

IPADDR="${IPADDR:-$CURRENT_IP}"

if [[ -z "${HOSTNAME}" || -z "${IPADDR}" ]]; then

die "Hostname/IP cannot be empty."

log "Setting hostname to: ${HOSTNAME}"

hostnamectl set-hostname "${HOSTNAME}"

log "Backing up /etc/hosts -> /etc/hosts.backup"

cp -a /etc/hosts /etc/hosts.backup

log "Writing /etc/hosts (makes hostname resolvable locally)"

cat > /etc/hosts <<EOT

127.0.0.1 localhost

${IPADDR} ${HOSTNAME}

# IPv6

::1 localhost ip6-localhost ip6-loopback

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

EOT

log "Installing prerequisites"

apt update

apt install -y wget ca-certificates gnupg

log "Installing Proxmox archive keyring to /usr/share/keyrings/proxmox-archive-keyring.gpg"

KEYRING="/usr/share/keyrings/proxmox-archive-keyring.gpg"

wget -q https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg -O "${KEYRING}"

log "Verifying SHA512 of keyring"

EXPECTED_SHA512="8678f2327c49276615288d7ca11e7d296bc8a2b96946fe565a9c81e533f9b15a5dbbad210a0ad5cd46d361ff1d3c4bac55844bc296beefa4f88b86e44e69fa51"

ACTUAL_SHA512="$(sha512sum "${KEYRING}" | awk '{print $1}')"

if [[ "${ACTUAL_SHA512}" != "${EXPECTED_SHA512}" ]]; then

die "Keyring SHA512 mismatch!

Expected: ${EXPECTED_SHA512}

Actual: ${ACTUAL_SHA512}"

log "Adding Proxmox VE 9 no-subscription repo (Trixie)"

cat > /etc/apt/sources.list.d/pve-install-repo.list <<EOT

deb [arch=amd64 signed-by=/usr/share/keyrings/proxmox-archive-keyring.gpg] http://download.proxmox.com/debian/pve trixie pve-no-subscription

EOT

log "Updating + full-upgrade"

apt update

apt full-upgrade -y

log "Installing Proxmox kernel meta-package: proxmox-default-kernel"

apt install -y proxmox-default-kernel

log "Part 1 done. Rebooting now. After reboot run: ./install-proxmox9-part2.sh"

reboot

Partie 2 – Installation de Proxmox VE 9

Après le redémarrage, téléchargez et exécutez :

wget http://soban.pl/bash/install-proxmox9-part2.sh
chmod +x install-proxmox9-part2.sh
./install-proxmox9-part2.sh

wget http://soban.pl/bash/install-proxmox9-part2.sh

chmod +x install-proxmox9-part2.sh

./install-proxmox9-part2.sh

Contenu de install-proxmox9-part2.sh

#!/usr/bin/env bash
set -euo pipefail
# Part 2/2: Debian 13 (Trixie) -> Proxmox VE 9
# - verifies running PVE kernel (unless FORCE=1)
# - installs proxmox-ve + required packages
# - removes Debian kernel packages (keeps pve)
# - updates grub
# - removes os-prober
# - prints URL to GUI
log() { echo "[$(date '+%F %T')] $*"; }
die() { echo "ERROR: $*" >&2; exit 1; }
FORCE="${FORCE:-0}"
if [[ "$(id -u)" -ne 0 ]]; then
die "Run as root."
fi
log "=== Proxmox VE 9 install (part 2/2) ==="
KERNEL="$(uname -r || true)"
if ! echo "${KERNEL}" | grep -qi 'pve'; then
if [[ "${FORCE}" != "1" ]]; then
die "You are NOT running a PVE kernel (uname -r: ${KERNEL}).
Reboot and select the Proxmox kernel first.
If you really want to continue anyway: FORCE=1 ./install-proxmox9-part2.sh"
else
log "WARNING: Continuing despite not running PVE kernel because FORCE=1"
fi
else
log "OK: running PVE kernel: ${KERNEL}"
fi
log "Update package lists"
apt update
log "Install Proxmox VE packages"
# postfix is optional but commonly installed by docs; choose config during prompts
DEBIAN_FRONTEND=readline apt install -y proxmox-ve postfix open-iscsi chrony
log "Upgrade remaining packages"
apt full-upgrade -y
log "Removing Debian kernel meta-package and non-PVE kernels (best-effort)"
# Remove Debian meta kernel (keeps proxmox kernel)
apt remove -y linux-image-amd64 || true
# Purge any installed linux-image-* that is NOT a pve kernel
mapfile -t KPKGS < <(dpkg -l | awk '/^ii  linux-image-/{print $2}' | grep -vE 'pve|proxmox' || true)
if (( ${#KPKGS[@]} > 0 )); then
log "Purging non-PVE kernel packages: ${KPKGS[*]}"
apt purge -y "${KPKGS[@]}" || true
fi
log "Update grub"
update-grub || true
log "Remove os-prober (recommended for servers; avoids odd grub side effects)"
apt remove -y os-prober || true
log "Done. Proxmox UI should be available at:"
IP="$(hostname -I | awk '{print $1}')"
echo "https://${IP}:8006"
log "Login: root + your root password"

#!/usr/bin/env bash

set -euo pipefail

# Part 2/2: Debian 13 (Trixie) -> Proxmox VE 9

# - verifies running PVE kernel (unless FORCE=1)

# - installs proxmox-ve + required packages

# - removes Debian kernel packages (keeps pve)

# - updates grub

# - removes os-prober

# - prints URL to GUI

log() { echo "[$(date '+%F %T')] $*"; }

die() { echo "ERROR: $*" >&2; exit 1; }

FORCE="${FORCE:-0}"

if [[ "$(id -u)" -ne 0 ]]; then

die "Run as root."

log "=== Proxmox VE 9 install (part 2/2) ==="

KERNEL="$(uname -r || true)"

if ! echo "${KERNEL}" | grep -qi 'pve'; then

if [[ "${FORCE}" != "1" ]]; then

die "You are NOT running a PVE kernel (uname -r: ${KERNEL}).

Reboot and select the Proxmox kernel first.

If you really want to continue anyway: FORCE=1 ./install-proxmox9-part2.sh"

else

log "WARNING: Continuing despite not running PVE kernel because FORCE=1"

else

log "OK: running PVE kernel: ${KERNEL}"

log "Update package lists"

apt update

log "Install Proxmox VE packages"

# postfix is optional but commonly installed by docs; choose config during prompts

DEBIAN_FRONTEND=readline apt install -y proxmox-ve postfix open-iscsi chrony

log "Upgrade remaining packages"

apt full-upgrade -y

log "Removing Debian kernel meta-package and non-PVE kernels (best-effort)"

# Remove Debian meta kernel (keeps proxmox kernel)

apt remove -y linux-image-amd64 || true

# Purge any installed linux-image-* that is NOT a pve kernel

mapfile -t KPKGS < <(dpkg -l | awk '/^ii linux-image-/{print $2}' | grep -vE 'pve|proxmox' || true)

if (( ${#KPKGS[@]} > 0 )); then

log "Purging non-PVE kernel packages: ${KPKGS[*]}"

apt purge -y "${KPKGS[@]}" || true

log "Update grub"

update-grub || true

log "Remove os-prober (recommended for servers; avoids odd grub side effects)"

apt remove -y os-prober || true

log "Done. Proxmox UI should be available at:"

IP="$(hostname -I | awk '{print $1}')"

echo "https://${IP}:8006"

log "Login: root + your root password"

Accès à l’interface Web

Après avoir terminé le second script, ouvrez :

https://YOUR_SERVER_IP:8006

1	https://YOUR_SERVER_IP:8006

Connectez-vous avec l’utilisateur root et votre mot de passe root. Vous pouvez voir un avertissement de certificat — c’est normal pour une installation récente.

Dépannage – erreur 401 Unauthorized (dépôt pve-enterprise)

Si après l’installation ou lors de l’exécution de apt update vous obtenez l’erreur suivante :

Err:8 https://enterprise.proxmox.com/debian/pve trixie InRelease
401  Unauthorized [IP: 2001:41d0:b00:5900::34 443]
Error: Failed to fetch https://enterprise.proxmox.com/debian/pve/dists/trixie/InRelease  401  Unauthorized
Error: The repository 'https://enterprise.proxmox.com/debian/pve trixie InRelease' is not signed.
Notice: Updating from such a repository can't be done securely, and is therefore disabled by default.

Err:8 https://enterprise.proxmox.com/debian/pve trixie InRelease

401 Unauthorized [IP: 2001:41d0:b00:5900::34 443]

Error: Failed to fetch https://enterprise.proxmox.com/debian/pve/dists/trixie/InRelease 401 Unauthorized

Error: The repository 'https://enterprise.proxmox.com/debian/pve trixie InRelease' is not signed.

Notice: Updating from such a repository can't be done securely, and is therefore disabled by default.

Cela signifie que le dépôt enterprise est activé, mais que votre système ne dispose pas d’un abonnement Proxmox valide. Dans ce guide, nous utilisons le dépôt pve-no-subscription, il est donc nécessaire de désactiver le dépôt enterprise.

Corrigez le problème en exécutant :

mv /etc/apt/sources.list.d/pve-enterprise.sources \
/etc/apt/sources.list.d/pve-enterprise.sources.disabled
apt update

mv /etc/apt/sources.list.d/pve-enterprise.sources \

/etc/apt/sources.list.d/pve-enterprise.sources.disabled

apt update

Après cela, la mise à jour devrait s’exécuter correctement :

apt update && apt dist-upgrade -y && apt autoremove -y

1	apt update && apt dist-upgrade -y && apt autoremove -y

Si tout est correctement configuré, vous verrez le message :

All packages are up to date.

Conclusion

Cette méthode offre une manière propre et contrôlée de déployer Proxmox VE 9 directement sur Debian 13 sans utiliser l’installateur ISO. Elle est particulièrement utile pour les environnements automatisés, les laboratoires et les configurations d’infrastructure personnalisées.

Fail2Ban + Nginx (compatible WordPress) : 5 requêtes suspectes → bannissement de 5 minutes (correctif iptables-nft, tests et déblocage IP)

Posted on février 16, 2026 by soban

Ce guide montre une installation et configuration complètes de Fail2Ban pour Nginx et WordPress, afin de :

bloquer les scanners et bots (par exemple les tentatives d’accès à /.env, /.git, phpmyadmin, etc.),
ne pas bloquer l’administrateur WordPress,
bannir une adresse IP après 5 requêtes suspectes ou invalides,
appliquer un bannissement court de seulement 5 minutes (sans risque de vous bloquer longtemps).

Étape 1 : Installer Fail2Ban

Installez Fail2Ban :

apt update
apt install -y fail2ban

1 2	apt update apt install -y fail2ban

Activez et démarrez le service :

systemctl enable fail2ban
systemctl start fail2ban

1 2	systemctl enable fail2ban systemctl start fail2ban

Vérifiez qu’il fonctionne :

fail2ban-client ping
systemctl status fail2ban

1 2	fail2ban-client ping systemctl status fail2ban

Étape 2 : Créer le filtre nginx-secure

Créez le fichier de filtre :

nano /etc/fail2ban/filter.d/nginx-secure.conf

1	nano /etc/fail2ban/filter.d/nginx-secure.conf

Collez la configuration suivante :

[Definition]
failregex =
^<HOST> - .* "(?:GET|POST|HEAD|PUT|DELETE|OPTIONS|PATCH|PROPFIND|CONNECT) (?:/\.env|/wp-config\.php|/phpinfo\.php|/(?:phpmyadmin|pma|adminer)(?:/|$)|/(?:\.git|\.svn|\.hg)(?:/|$)|/vendor/phpunit/|/cgi-bin/).*" \d{3} .*
^<HOST> - .* "(?:GET|POST|HEAD|PUT|DELETE|OPTIONS|PATCH|PROPFIND|CONNECT) (?!/(?:wp-login\.php|wp-admin/))[^"]*" (?:400|403|405|408|413|414|429|444|499) .*
^<HOST> - .* "(?:GET|POST|HEAD|PUT|DELETE|OPTIONS|PATCH|PROPFIND|CONNECT) .*" \d{3} .* "(?:[^"]*)" "(?:[^"]*(?:sqlmap|nikto|masscan|zgrab|nmap|acunetix|wpscan|dirbuster|gobuster)[^"]*)" .*
ignoreregex =

[Definition]

failregex =

^<HOST> - .* "(?:GET|POST|HEAD|PUT|DELETE|OPTIONS|PATCH|PROPFIND|CONNECT) (?:/\.env|/wp-config\.php|/phpinfo\.php|/(?:phpmyadmin|pma|adminer)(?:/|$)|/(?:\.git|\.svn|\.hg)(?:/|$)|/vendor/phpunit/|/cgi-bin/).*" \d{3} .*

^<HOST> - .* "(?:GET|POST|HEAD|PUT|DELETE|OPTIONS|PATCH|PROPFIND|CONNECT) (?!/(?:wp-login\.php|wp-admin/))[^"]*" (?:400|403|405|408|413|414|429|444|499) .*

^<HOST> - .* "(?:GET|POST|HEAD|PUT|DELETE|OPTIONS|PATCH|PROPFIND|CONNECT) .*" \d{3} .* "(?:[^"]*)" "(?:[^"]*(?:sqlmap|nikto|masscan|zgrab|nmap|acunetix|wpscan|dirbuster|gobuster)[^"]*)" .*

ignoreregex =

Étape 3 : Créer la jail nginx-secure

Créez le fichier de configuration :

nano /etc/fail2ban/jail.d/nginx-secure.conf

1	nano /etc/fail2ban/jail.d/nginx-secure.conf

Collez la configuration suivante :

[nginx-secure]
enabled  = true
port     = http,https
filter   = nginx-secure
logpath  = /var/log/nginx/access.log
/var/log/nginx/access-*.log
findtime = 600
maxretry = 5
bantime  = 300
action   = iptables-multiport[name=nginx-secure, port="http,https"]
ignoreip = 127.0.0.1/8 ::1

[nginx-secure]

enabled = true

port = http,https

filter = nginx-secure

logpath = /var/log/nginx/access.log

/var/log/nginx/access-*.log

findtime = 600

maxretry = 5

bantime = 300

action = iptables-multiport[name=nginx-secure, port="http,https"]

ignoreip = 127.0.0.1/8 ::1

Étape 4 : Redémarrer Fail2Ban

fail2ban-server -t
systemctl restart fail2ban

1 2	fail2ban-server -t systemctl restart fail2ban

Étape 5 : Vérifier le firewall

Vérifiez que la chaîne Fail2Ban existe :

iptables -S | grep f2b-nginx-secure
iptables -L f2b-nginx-secure -n -v

1 2	iptables -S \| grep f2b-nginx-secure iptables -L f2b-nginx-secure -n -v

Test externe

Exécutez depuis une autre machine :

for i in 1 2 3 4 5; do
curl -I https://soban.pl/.env
done

for i in 1 2 3 4 5; do

curl -I https://soban.pl/.env

done

Après 5 tentatives, l’adresse IP sera bannie pendant 5 minutes.

Voir les IP bannies

fail2ban-client status nginx-secure

1	fail2ban-client status nginx-secure

Débloquer une adresse IP

Débloquez votre IP manuellement :

fail2ban-client set nginx-secure unbanip VOTRE_IP

1	fail2ban-client set nginx-secure unbanip VOTRE_IP

Résumé

protège contre les scanners et les tentatives d’exploitation,
ne bloque pas le panneau d’administration WordPress,
bannissement court de seulement 5 minutes,
compatible avec iptables-nft,
facile à tester et à débloquer.

Mise à niveau automatique Debian 12 → Debian 13 avec mise à jour optionnelle de PHP et nginx

Posted on février 16, 2026février 16, 2026 by 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

1	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

1	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

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

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

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

1 2	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

1 2	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

1 2	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

1 2	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

1 2	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

1 2	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

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