soban - IT, Linux, Servers, Security

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.

Configuration Fail2Ban pour Nginx – bloquer les scanners et les tentatives d’exploitation sans bloquer l’administration WordPress

Posted on février 16, 2026mars 2, 2026 by soban

Ce guide présente une installation et une configuration complètes de Fail2Ban pour Nginx, conçues pour :

bloquer les véritables scanners et tentatives d’exploitation (par exemple les requêtes vers /.env, /.git, /phpmyadmin, etc.),
éviter le blocage accidentel des administrateurs (problème fréquent lorsque le bannissement repose uniquement sur les erreurs HTTP),
bannir les adresses IP après des activités suspectes répétées,
utiliser une courte durée de bannissement (5 minutes) afin de réduire le risque de s’auto-bloquer.

Pourquoi bannir uniquement sur la base des erreurs HTTP peut poser problème

De nombreux guides recommandent de bannir les adresses IP uniquement selon les codes de statut HTTP (4xx/499). En pratique, cela provoque souvent des auto-blocages, car les applications modernes génèrent de nombreuses requêtes (AJAX, panneaux d’administration, reconstruction du cache), ce qui peut entraîner des erreurs HTTP lors d’une utilisation normale.

Cette configuration adopte une approche plus sûre :

les chemins d’exploitation sont toujours considérés comme suspects,
les erreurs HTTP ne sont comptabilisées que lorsque la requête ne contient pas d’en-tête Referer (comportement typique des scanners),
les User-Agents malveillants connus sont pris en compte.

É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 son fonctionnement :

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|adminer)(?:/|$)|/(?:\.git|\.svn|\.hg)(?:/|$)|/vendor/phpunit/|/cgi-bin/).*" \d{3} .*
^<HOST> - .* "(?:GET|POST|HEAD|PUT|DELETE|OPTIONS|PATCH|PROPFIND|CONNECT) [^"]*" (?:400|403|404|405|408|413|414|429|444) [^"]* "-" ".*"
^<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|adminer)(?:/|$)|/(?:\.git|\.svn|\.hg)(?:/|$)|/vendor/phpunit/|/cgi-bin/).*" \d{3} .*

^<HOST> - .* "(?:GET|POST|HEAD|PUT|DELETE|OPTIONS|PATCH|PROPFIND|CONNECT) [^"]*" (?:400|403|404|405|408|413|414|429|444) [^"]* "-" ".*"

^<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 le jail nginx-secure

Créez le fichier de configuration du jail :

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 = 20
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 = 20

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 l’intégration avec le pare-feu

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 depuis une machine externe

Test du chemin d’exploitation :

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

Test de la logique des erreurs sans Referer :

for i in 1 2 3 4 5; do
curl -sS -o /dev/null -w "%{http_code}\n" https://soban.pl/this-path-should-not-exist-$i
done

for i in 1 2 3 4 5; do

curl -sS -o /dev/null -w "%{http_code}\n" https://soban.pl/this-path-should-not-exist-$i

done

Après plusieurs requêtes suspectes, l’adresse IP sera bannie pendant 5 minutes.

Vérifier les adresses IP bannies

fail2ban-client status nginx-secure

1	fail2ban-client status nginx-secure

Débannir une adresse IP

Retirer un bannissement manuellement :

fail2ban-client set nginx-secure unbanip YOUR_IP

1	fail2ban-client set nginx-secure unbanip YOUR_IP

Résumé

bloque les véritables scanners et tentatives d’exploitation,
réduit le risque d’auto-blocage des administrateurs,
utilise un bannissement court de 5 minutes,
compatible avec iptables-nft,
facile à tester et à débannir.

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

Proxmox Mises à jour automatiques des VM (qm + vzdump) avec tests réseau et restauration automatique

Posted on janvier 23, 2026janvier 23, 2026 by soban

Dans cet article, je présente un script simple (mais très efficace) pour automatiser les mises à jour des machines virtuelles sur Proxmox VE. Le script peut :

créer une sauvegarde de la VM (optionnel),
démarrer la VM si elle était arrêtée au départ,
effectuer une mise à niveau complète via apt et redémarrer la VM,
lancer des tests réseau avant et après la mise à jour,
restaurer automatiquement depuis la sauvegarde en cas de problème (optionnel),
éteindre la VM à la fin si elle était initialement arrêtée.

Où télécharger le script

Vous pouvez télécharger le script directement depuis mon site :

soban.pl/bash/upgrade_proxmox_qm.sh

Dossiers requis

Avant de lancer l’automatisation, créez deux dossiers : un pour les scripts et un pour les logs :

mkdir -p /root/automate_scripts /root/logs

1	mkdir -p /root/automate_scripts /root/logs

Installer le script

Téléchargez le script dans /root/automate_scripts/ et rendez-le exécutable :

cd /root/automate_scripts
curl -fsSL -o upgrade_proxmox_qm.sh "https://soban.pl/bash/upgrade_proxmox_qm.sh"
chmod +x /root/automate_scripts/upgrade_proxmox_qm.sh

cd /root/automate_scripts

curl -fsSL -o upgrade_proxmox_qm.sh "https://soban.pl/bash/upgrade_proxmox_qm.sh"

chmod +x /root/automate_scripts/upgrade_proxmox_qm.sh

Comment ça marche (version courte)

D’abord, une sauvegarde est créée (vzdump snapshot + zstd) si l’option est activée.
Si la VM était en état stopped, le script la démarre et attend WAIT_TIME secondes.
Ensuite, le script exécute des tests réseau AVANT la mise à jour :
Le script exécute apt update/upgrade/dist-upgrade/autoremove/clean puis redémarre la VM (reboot).
Après le redémarrage, il attend à nouveau (WAIT_TIME) et relance les tests APRÈS la mise à jour.
Si les tests échouent et qu’une sauvegarde est disponible, la VM est restaurée automatiquement via qmrestore.
Enfin, la VM est arrêtée si elle était initialement arrêtée.

Lancer le script manuellement

Le script attend exactement deux arguments :

VMID – l’ID de la VM dans Proxmox
TIME_SEC – le temps d’attente après démarrage/redémarrage (en secondes)

/root/automate_scripts/upgrade_proxmox_qm.sh 901 500

1	/root/automate_scripts/upgrade_proxmox_qm.sh 901 500

Astuce : adaptez WAIT_TIME au temps réel de démarrage de la VM et à la durée de la mise à jour. En pratique, 300 à 1000 secondes fonctionnent très bien selon la VM.

Script complet (référence)

Ci-dessous, le script complet (code et commentaires restent en anglais) :

#!/bin/bash
WAIT_TIME=$2  # wait time for VM start/restart (in seconds)
DO_BACKUP="y" # 'y' - create backup, 'n' - skip backup
DO_UPDATE="y" # 'y' - run system update, 'n' - skip update
echo "---------------START---------------"
date
echo "-----------------------------------"
# Argument check
if [ "$#" -ne 2 ]; then
echo "Usage: $0 <VMID> <TIME_SEC>"
exit 1
fi
VMID="$1"
TARGET_HOSTNAME=$(/usr/sbin/qm list | grep -w "$VMID" | awk '{print $2}')
VM_STATUS=$(/usr/sbin/qm status "$VMID" | awk '{print $2}')
HOST_MACHINE=$(hostname)
WAS_STOPPED=0
if [ "$VM_STATUS" = "stopped" ]; then
WAS_STOPPED=1
else
WAS_STOPPED=0
fi
# Create backup if DO_BACKUP is set to 'y'
backup_result="Backup not attempted"
if [ "$DO_BACKUP" = "y" ]; then
echo "Creating backup for VM $VMID..."
BACKUP_OUTPUT=$(/usr/bin/vzdump "$VMID" --storage local --mode snapshot --compress zstd)
BACKUP_FILE=$(echo "$BACKUP_OUTPUT" | grep -oP 'vzdump-qemu-[^\s]+' | tr -d "'")
if [ -z "$BACKUP_FILE" ]; then
echo "Backup failed: No backup file created."
backup_result="Backup created: NOK"
exit 1
else
echo "Backup created successfully: $BACKUP_FILE"
backup_result="Backup created: OK"
fi
else
echo "Backup not attempted (backup is disabled)."
fi
# Start VM if it was originally stopped
if [ "$WAS_STOPPED" -eq 1 ]; then
echo "Starting VM $VMID for update..."
/usr/sbin/qm start "$VMID"
echo "Waiting $WAIT_TIME seconds for VM to start..."
sleep "$WAIT_TIME"
fi
# Test functions
perform_ping_test() {
source="$1"
target="$2"
if ssh root@"$source" "ping -c 3 -W 2 $target" >/dev/null 2>&1; then
echo "Ping from $source to $target: OK"
return 0
else
echo "Ping from $source to $target: NOK"
return 1
fi
}
test_curl() {
source="$1"
target="$2"
if ssh root@"$source" "curl -s --head --connect-timeout 5 $target" >/dev/null 2>&1; then
echo "Curl from $source to $target: OK"
return 0
else
echo "Curl from $source to $target: NOK"
return 1
fi
}
perform_local_ping_test() {
source="$1"
target="$2"
if ping -c 3 -W 2 "$target" >/dev/null 2>&1; then
echo "Ping from $source to $target: OK"
return 0
else
echo "Ping from $source to $target: NOK"
return 1
fi
}
DEFAULT_GW=$(/sbin/ip route | grep default | awk '{print $3}')
perform_tests() {
status=0
perform_local_ping_test "$HOST_MACHINE" "$TARGET_HOSTNAME" || status=1
perform_ping_test "$TARGET_HOSTNAME" "8.8.8.8" || status=1
perform_ping_test "$TARGET_HOSTNAME" "$DEFAULT_GW" || status=1
test_curl "$TARGET_HOSTNAME" "http://google.com" || status=1
return ${status:-0}
}
# General tests before update
echo "--- General tests BEFORE update ---"
if perform_tests; then
echo "All network tests before update: OK"
echo "$backup_result"
if [ "$backup_result" == "Backup created: OK" ] || [ "$backup_result" == "Backup not attempted" ]; then
echo "BEFORE status: OK"
else
echo "BEFORE status: NOK"
fi
else
echo "Some network tests before update: NOK"
echo "$backup_result"
echo "BEFORE status: NOK"
[ "$WAS_STOPPED" -eq 1 ] && /usr/sbin/qm shutdown "$VMID"
exit 1
fi
echo "-----------------------------------"
# System update and reboot
update_result="Upgrade system: NOK"
if [ "$DO_UPDATE" = "y" ]; then
echo "--- Updating VM $VMID ---"
if ssh root@"$TARGET_HOSTNAME" "/usr/bin/apt update && \
/usr/bin/apt upgrade -y && \
/usr/bin/apt dist-upgrade -y && \
/usr/bin/apt autoremove -y && \
/usr/bin/apt autoclean && \
/usr/bin/apt clean && \
/usr/bin/apt --purge autoremove && \
/sbin/reboot"; then
echo "---END Updating VM $VMID ---"
echo "Upgrade system: OK"
update_result="Upgrade system: OK"
else
echo "Upgrade system: NOK"
update_result="Upgrade system: NOK"
[ "$WAS_STOPPED" -eq 1 ] && /usr/sbin/qm shutdown "$VMID"
echo "Update failed. Exiting."
exit 1
fi
fi
# Wait for VM reboot if update was performed
if [ "$DO_UPDATE" = "y" ]; then
echo "Waiting $WAIT_TIME seconds for VM to reboot..."
sleep "$WAIT_TIME"
fi
# Tests after reboot if update was performed
if [ "$DO_UPDATE" = "y" ]; then
echo "--- Network tests AFTER update ---"
if perform_tests; then
echo "All network tests after update: OK"
echo "$update_result"
echo "AFTER status: OK"
else
echo "Some network tests after update: NOK"
echo "$update_result"
echo "Attempting to restore from backup..."
if [ "$DO_BACKUP" = "y" ]; then
/usr/sbin/qm stop "$VMID"
/usr/sbin/qmrestore "/var/lib/vz/dump/$BACKUP_FILE" "$VMID" --force
if [ "$WAS_STOPPED" -eq 1 ]; then
/usr/sbin/qm shutdown "$VMID"
fi
echo "Restore attempt finished. Please check VM status."
echo "AFTER status: NOK"
else
echo "No backup available for restoration. The VM might not function properly after failed update."
echo "AFTER status: NOK"
fi
fi
echo "-----------------------------------"
fi
# Shut down VM if it was originally stopped
if [ "$WAS_STOPPED" -eq 1 ]; then
echo "Shutting down VM $VMID (originally stopped)."
/usr/sbin/qm shutdown "$VMID"
fi
echo "---------------END---------------"
date
echo "-----------------------------------"

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

#!/bin/bash

WAIT_TIME=$2 # wait time for VM start/restart (in seconds)

DO_BACKUP="y" # 'y' - create backup, 'n' - skip backup

DO_UPDATE="y" # 'y' - run system update, 'n' - skip update

echo "---------------START---------------"

date

echo "-----------------------------------"

# Argument check

if [ "$#" -ne 2 ]; then

echo "Usage: $0 <VMID> <TIME_SEC>"

exit 1

VMID="$1"

TARGET_HOSTNAME=$(/usr/sbin/qm list | grep -w "$VMID" | awk '{print $2}')

VM_STATUS=$(/usr/sbin/qm status "$VMID" | awk '{print $2}')

HOST_MACHINE=$(hostname)

WAS_STOPPED=0

if [ "$VM_STATUS" = "stopped" ]; then

WAS_STOPPED=1

else

WAS_STOPPED=0

# Create backup if DO_BACKUP is set to 'y'

backup_result="Backup not attempted"

if [ "$DO_BACKUP" = "y" ]; then

echo "Creating backup for VM $VMID..."

BACKUP_OUTPUT=$(/usr/bin/vzdump "$VMID" --storage local --mode snapshot --compress zstd)

BACKUP_FILE=$(echo "$BACKUP_OUTPUT" | grep -oP 'vzdump-qemu-[^\s]+' | tr -d "'")

if [ -z "$BACKUP_FILE" ]; then

echo "Backup failed: No backup file created."

backup_result="Backup created: NOK"

exit 1

else

echo "Backup created successfully: $BACKUP_FILE"

backup_result="Backup created: OK"

else

echo "Backup not attempted (backup is disabled)."

# Start VM if it was originally stopped

if [ "$WAS_STOPPED" -eq 1 ]; then

echo "Starting VM $VMID for update..."

/usr/sbin/qm start "$VMID"

echo "Waiting $WAIT_TIME seconds for VM to start..."

sleep "$WAIT_TIME"

# Test functions

perform_ping_test() {

source="$1"

target="$2"

if ssh root@"$source" "ping -c 3 -W 2 $target" >/dev/null 2>&1; then

echo "Ping from $source to $target: OK"

return 0

else

echo "Ping from $source to $target: NOK"

return 1

}

test_curl() {

source="$1"

target="$2"

if ssh root@"$source" "curl -s --head --connect-timeout 5 $target" >/dev/null 2>&1; then

echo "Curl from $source to $target: OK"

return 0

else

echo "Curl from $source to $target: NOK"

return 1

}

perform_local_ping_test() {

source="$1"

target="$2"

if ping -c 3 -W 2 "$target" >/dev/null 2>&1; then

echo "Ping from $source to $target: OK"

return 0

else

echo "Ping from $source to $target: NOK"

return 1

}

DEFAULT_GW=$(/sbin/ip route | grep default | awk '{print $3}')

perform_tests() {

status=0

perform_local_ping_test "$HOST_MACHINE" "$TARGET_HOSTNAME" || status=1

perform_ping_test "$TARGET_HOSTNAME" "8.8.8.8" || status=1

perform_ping_test "$TARGET_HOSTNAME" "$DEFAULT_GW" || status=1

test_curl "$TARGET_HOSTNAME" "http://google.com" || status=1

return ${status:-0}

}

# General tests before update

echo "--- General tests BEFORE update ---"

if perform_tests; then

echo "All network tests before update: OK"

echo "$backup_result"

if [ "$backup_result" == "Backup created: OK" ] || [ "$backup_result" == "Backup not attempted" ]; then

echo "BEFORE status: OK"

else

echo "BEFORE status: NOK"

else

echo "Some network tests before update: NOK"

echo "$backup_result"

echo "BEFORE status: NOK"

[ "$WAS_STOPPED" -eq 1 ] && /usr/sbin/qm shutdown "$VMID"

exit 1

echo "-----------------------------------"

# System update and reboot

update_result="Upgrade system: NOK"

if [ "$DO_UPDATE" = "y" ]; then

echo "--- Updating VM $VMID ---"

if ssh root@"$TARGET_HOSTNAME" "/usr/bin/apt update && \

/usr/bin/apt upgrade -y && \

/usr/bin/apt dist-upgrade -y && \

/usr/bin/apt autoremove -y && \

/usr/bin/apt autoclean && \

/usr/bin/apt clean && \

/usr/bin/apt --purge autoremove && \

/sbin/reboot"; then

echo "---END Updating VM $VMID ---"

echo "Upgrade system: OK"

update_result="Upgrade system: OK"

else

echo "Upgrade system: NOK"

update_result="Upgrade system: NOK"

[ "$WAS_STOPPED" -eq 1 ] && /usr/sbin/qm shutdown "$VMID"

echo "Update failed. Exiting."

exit 1

# Wait for VM reboot if update was performed

if [ "$DO_UPDATE" = "y" ]; then

echo "Waiting $WAIT_TIME seconds for VM to reboot..."

sleep "$WAIT_TIME"

# Tests after reboot if update was performed

if [ "$DO_UPDATE" = "y" ]; then

echo "--- Network tests AFTER update ---"

if perform_tests; then

echo "All network tests after update: OK"

echo "$update_result"

echo "AFTER status: OK"

else

echo "Some network tests after update: NOK"

echo "$update_result"

echo "Attempting to restore from backup..."

if [ "$DO_BACKUP" = "y" ]; then

/usr/sbin/qm stop "$VMID"

/usr/sbin/qmrestore "/var/lib/vz/dump/$BACKUP_FILE" "$VMID" --force

if [ "$WAS_STOPPED" -eq 1 ]; then

/usr/sbin/qm shutdown "$VMID"

echo "Restore attempt finished. Please check VM status."

echo "AFTER status: NOK"

else

echo "No backup available for restoration. The VM might not function properly after failed update."

echo "AFTER status: NOK"

echo "-----------------------------------"

# Shut down VM if it was originally stopped

if [ "$WAS_STOPPED" -eq 1 ]; then

echo "Shutting down VM $VMID (originally stopped)."

/usr/sbin/qm shutdown "$VMID"

echo "---------------END---------------"

date

echo "-----------------------------------"

Cron (planning hebdomadaire + logs séparés par VM)

Voici un exemple de crontab : une VM différente est mise à jour chaque jour de la semaine, et les logs sont enregistrés dans des fichiers séparés sous /root/logs/.

Modifier le crontab root :

crontab -e

1	crontab -e

Collez les règles ci-dessous (les commentaires restent en anglais) :

15 0 * * 1 /root/automate_scripts/upgrade_proxmox_qm.sh 901 500 > /root/logs/kali.log 2>&1                 # Monday: upgrade Kali Linux (VMID 901)
15 0 * * 2 /root/automate_scripts/upgrade_proxmox_qm.sh 903 500 > /root/logs/proxmox-test-01.log 2>&1      # Tuesday: upgrade proxmox-test-01 (VMID 903)
15 0 * * 3 /root/automate_scripts/upgrade_proxmox_qm.sh 904 500 > /root/logs/ubuntu-lte.log 2>&1           # Wednesday: upgrade ubuntu-lte (VMID 904)
15 0 * * 4 /root/automate_scripts/upgrade_proxmox_qm.sh 905 1000 > /root/logs/backup-machine.log 2>&1      # Thursday: upgrade backup-machine (VMID 905)

15 0 * * 1 /root/automate_scripts/upgrade_proxmox_qm.sh 901 500 > /root/logs/kali.log 2>&1 # Monday: upgrade Kali Linux (VMID 901)

15 0 * * 2 /root/automate_scripts/upgrade_proxmox_qm.sh 903 500 > /root/logs/proxmox-test-01.log 2>&1 # Tuesday: upgrade proxmox-test-01 (VMID 903)

15 0 * * 3 /root/automate_scripts/upgrade_proxmox_qm.sh 904 500 > /root/logs/ubuntu-lte.log 2>&1 # Wednesday: upgrade ubuntu-lte (VMID 904)

15 0 * * 4 /root/automate_scripts/upgrade_proxmox_qm.sh 905 1000 > /root/logs/backup-machine.log 2>&1 # Thursday: upgrade backup-machine (VMID 905)

Vérifications rapides / Dépannage

Assurez-vous que root peut se connecter en SSH depuis l’hôte Proxmox vers la VM (le script utilise ssh root@<vm-hostname>).
Vérifiez que DNS (ou /etc/hosts) résout correctement le hostname de la VM sur l’hôte Proxmox.
Si apt demande des confirmations, configurez des mises à niveau non interactives ou bloquez les paquets problématiques.

Voilà ! Déposez le script dans /root/automate_scripts/, envoyez les journaux dans /root/logs/, et la maintenance hebdomadaire de votre machine virtuelle devient quasiment automatique.

Dell WD19/WD19S : mise à jour du firmware sur Proxmox/Debian sans timeouts USB (fwupd + correctif autosuspend)

Posted on janvier 18, 2026janvier 18, 2026 by soban

Si vous essayez de mettre à jour le firmware d’une station d’accueil Dell WD19/WD19S sur Proxmox (ou Debian) via fwupdmgr, vous pouvez tomber sur l’erreur classique Operation timed out pendant l’étape Erasing…. En pratique, la mise à jour échoue à cause de la gestion d’énergie USB (autosuspend). Ci-dessous, vous trouverez un correctif simple et efficace, ainsi qu’un script prêt à l’emploi à lancer sur un serveur ou un ordinateur portable.

Symptômes

Le plus souvent, pendant la mise à jour du firmware du dock (WD19/WD19S), vous verrez une erreur similaire à :

failed to write-firmware: failed to erase bank: failed after 5 retries: failed to SetReport: USB error: Operation timed out [-7]

1	failed to write-firmware: failed to erase bank: failed after 5 retries: failed to SetReport: USB error: Operation timed out [-7]

À ce stade, fwupdmgr peut afficher le périphérique WD19S en Update State: Failed ou continuer à indiquer pending activation, mais le flash ne se termine jamais complètement.

Pourquoi cela arrive-t-il ?

Pendant le flash, le dock effectue des opérations longues. Si le système tente d’économiser de l’énergie sur l’USB (autosuspend), les transferts de contrôle USB peuvent échouer. Résultat : un timeout exactement lors de l’effacement de la banque de firmware (erase bank).

Correctif rapide : désactiver l’autosuspend USB pendant la mise à jour

La solution la plus simple consiste à définir temporairement l’autosuspend à -1 (désactivé). Ce paramètre reste actif jusqu’au redémarrage (sauf si vous le rendez permanent via la cmdline du noyau), mais cela suffit largement le temps de la mise à jour.

echo -1 > /sys/module/usbcore/parameters/autosuspend

1	echo -1 > /sys/module/usbcore/parameters/autosuspend

Ensuite, lancez la mise à jour :

fwupdmgr refresh --force
fwupdmgr update

1 2	fwupdmgr refresh --force fwupdmgr update

Après la mise à jour : “pending activation” et nécessité de débrancher le câble

Après une installation réussie du firmware pour WD19/WD19S, fwupdmgr affiche souvent le message suivant :

The update will continue when the device USB cable has been unplugged.
WD19S is pending activation; use fwupdmgr activate to complete the update.

1 2	The update will continue when the device USB cable has been unplugged. WD19S is pending activation; use fwupdmgr activate to complete the update.

Procédez dans cet ordre précis :

Débranchez le câble USB-C du dock (côté ordinateur).
(Optionnel) Débranchez l’alimentation du dock pendant 10–15 secondes, puis rebranchez-la.
Rebranchez le câble USB-C.
Lancez l’activation :

fwupdmgr activate

1	fwupdmgr activate

Enfin, vérifiez le statut :

fwupdmgr get-updates
fwupdmgr get-devices | less

1 2	fwupdmgr get-updates fwupdmgr get-devices \| less

Script prêt à l’emploi : installation + mise à jour + désactivation autosuspend (avec restauration)

Ci-dessous, un script prêt à l’emploi qui :

installe fwupd
rafraîchit les métadonnées LVFS
désactive temporairement l’autosuspend USB (pour éviter les timeouts sur WD19S)
lance les mises à jour du firmware
restaure ensuite la valeur précédente d’autosuspend (même en cas d’échec)

Vous pouvez copier le script directement depuis cet article, mais si vous préférez aller plus vite, vous pouvez le télécharger ici :

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

Exemple de téléchargement et d’exécution :

cd /root/scripts
curl -fsSL https://soban.pl/bash/dell_updage.sh -o dell_updage.sh
chmod +x dell_updage.sh
./dell_updage.sh

cd /root/scripts

curl -fsSL https://soban.pl/bash/dell_updage.sh -o dell_updage.sh

chmod +x dell_updage.sh

./dell_updage.sh

Si vous voulez prévisualiser le script avant de l’exécuter :

curl -fsSL https://soban.pl/bash/dell_updage.sh | less

1	curl -fsSL https://soban.pl/bash/dell_updage.sh \| less

Si less n’est pas installé :

apt update
apt install -y less

1 2	apt update apt install -y less

Script (contenu complet)

#!/bin/bash
set -euo pipefail
# dell upgrade:
# - installs fwupd
# - refreshes metadata
# - runs fwupdmgr update
# - TEMPORARILY disables USB autosuspend to avoid WD19/WD19S timeouts
# - restores autosuspend setting after update
echo "[INFO] Installing fwupd..."
apt update
apt install -y fwupd
echo "[INFO] Refreshing firmware metadata..."
fwupdmgr refresh --force
fwupdmgr get-updates || true
# Save current autosuspend value (if exists)
AUTOSUSPEND_PATH="/sys/module/usbcore/parameters/autosuspend"
OLD_AUTOSUSPEND=""
if [[ -f "$AUTOSUSPEND_PATH" ]]; then
OLD_AUTOSUSPEND="$(cat "$AUTOSUSPEND_PATH" || true)"
echo "[INFO] Current usbcore autosuspend: ${OLD_AUTOSUSPEND}"
else
echo "[WARN] autosuspend sysfs file not found: $AUTOSUSPEND_PATH"
fi
restore_autosuspend() {
if [[ -f "$AUTOSUSPEND_PATH" && -n "${OLD_AUTOSUSPEND}" ]]; then
echo "[INFO] Restoring usbcore autosuspend back to: ${OLD_AUTOSUSPEND}"
echo "${OLD_AUTOSUSPEND}" > "$AUTOSUSPEND_PATH" || true
fi
}
trap restore_autosuspend EXIT
# Disable autosuspend to prevent USB timeout during dock firmware erase/write
if [[ -f "$AUTOSUSPEND_PATH" ]]; then
echo "[INFO] Disabling USB autosuspend (set to -1) to avoid dock update timeouts..."
echo -1 > "$AUTOSUSPEND_PATH"
fi
read -p ""Do you want to update the entire device? (y/n): " answer
if [[ "$answer" == "y" || "$answer" == "Y" ]]; then
echo "[INFO] Running fwupdmgr update..."
fwupdmgr update || {
echo "[ERROR] fwupdmgr update failed."
echo "[HINT] If this is Dell dock (WD19/WD19S), try: unplug USB-C, replug, then run: fwupdmgr activate"
exit 1
}
echo "[INFO] Update finished."
echo "[INFO] If you updated a Dell dock and it says 'pending activation':"
echo "       1) Unplug USB-C cable from the dock"
echo "       2) (Optional) Unplug dock power for 10 seconds, plug back"
echo "       3) Run: fwupdmgr activate"
else
echo "[INFO] Skipping firmware update."
fi
echo "[INFO] Done."

#!/bin/bash

set -euo pipefail

# dell upgrade:

# - installs fwupd

# - refreshes metadata

# - runs fwupdmgr update

# - TEMPORARILY disables USB autosuspend to avoid WD19/WD19S timeouts

# - restores autosuspend setting after update

echo "[INFO] Installing fwupd..."

apt update

apt install -y fwupd

echo "[INFO] Refreshing firmware metadata..."

fwupdmgr refresh --force

fwupdmgr get-updates || true

# Save current autosuspend value (if exists)

AUTOSUSPEND_PATH="/sys/module/usbcore/parameters/autosuspend"

OLD_AUTOSUSPEND=""

if [[ -f "$AUTOSUSPEND_PATH" ]]; then

OLD_AUTOSUSPEND="$(cat "$AUTOSUSPEND_PATH" || true)"

echo "[INFO] Current usbcore autosuspend: ${OLD_AUTOSUSPEND}"

else

echo "[WARN] autosuspend sysfs file not found: $AUTOSUSPEND_PATH"

restore_autosuspend() {

if [[ -f "$AUTOSUSPEND_PATH" && -n "${OLD_AUTOSUSPEND}" ]]; then

echo "[INFO] Restoring usbcore autosuspend back to: ${OLD_AUTOSUSPEND}"

echo "${OLD_AUTOSUSPEND}" > "$AUTOSUSPEND_PATH" || true

}

trap restore_autosuspend EXIT

# Disable autosuspend to prevent USB timeout during dock firmware erase/write

if [[ -f "$AUTOSUSPEND_PATH" ]]; then

echo "[INFO] Disabling USB autosuspend (set to -1) to avoid dock update timeouts..."

echo -1 > "$AUTOSUSPEND_PATH"

read -p ""Do you want to update the entire device? (y/n): " answer

if [[ "$answer" == "y" || "$answer" == "Y" ]]; then

echo "[INFO] Running fwupdmgr update..."

fwupdmgr update || {

echo "[ERROR] fwupdmgr update failed."

echo "[HINT] If this is Dell dock (WD19/WD19S), try: unplug USB-C, replug, then run: fwupdmgr activate"

exit 1

}

echo "[INFO] Update finished."

echo "[INFO] If you updated a Dell dock and it says 'pending activation':"

echo " 1) Unplug USB-C cable from the dock"

echo " 2) (Optional) Unplug dock power for 10 seconds, plug back"

echo " 3) Run: fwupdmgr activate"

else

echo "[INFO] Skipping firmware update."

echo "[INFO] Done."

Exécuter le script

Le plus simple :

chmod +x dell_updage.sh
./dell_updage.sh

1 2	chmod +x dell_updage.sh ./dell_updage.sh

FAQ & conseils

La mise à jour échoue encore ? Débranchez tous les périphériques du dock (écrans/LAN/USB), ne laissez que l’alimentation et l’USB-C, faites un hard reset (débranchez l’alimentation 30s), puis réessayez.
“pending activation” après la mise à jour – c’est normal pour WD19/WD19S. Vous devez débrancher l’USB-C, rebrancher, puis exécuter fwupdmgr activate.
Est-ce que ça met à jour le BIOS du laptop ? Pas forcément. fwupdmgr liste séparément “System Firmware” (BIOS/UEFI) et le dock. Cet article se concentre sur le dock et le problème de timeout USB.

Résumé

Si la mise à jour du firmware Dell WD19/WD19S échoue sur Proxmox/Debian pendant l’étape Erasing…, il suffit dans la plupart des cas de désactiver temporairement l’autosuspend USB. Le script ci-dessus le fait automatiquement, puis restaure le réglage précédent afin que le système continue de fonctionner normalement.

iftop comme un bon outil de surveillance du trafic réseau

Posted on novembre 4, 2021février 26, 2026 by soban

iftop est un outil en ligne de commande permettant de surveiller la bande passante réseau en temps réel. Il affiche une liste continuellement mise à jour des connexions réseau ainsi que la quantité de données transférées entre elles. Les connexions sont présentées sous forme de tableau et peuvent être triées selon l’utilisation de la bande passante.

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

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

1	# apt install iftop

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

# iftop -PpNn

1	# iftop -PpNn

iftop en cours de surveillance du trafic

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

1	# 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:~

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

Transfert de fichier avec limitation de débit via scp

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.

Analyse SSL et suites de chiffrement avec Nmap sous Debian 11

Posted on septembre 30, 2021février 26, 2026 by soban

Analyse SSL et suites de chiffrement avec Nmap sous Debian 11

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

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

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

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