Wenn Sie einen Linux-Server mit Nginx, SSH oder WordPress betreiben, kennen Sie wahrscheinlich bereits Fail2Ban. Es ist ein gutes Tool, arbeitet jedoch lokal — es blockiert nur IP-Adressen, die Ihren Server angegriffen haben.

CrowdSec funktioniert völlig anders. Es handelt sich um ein Sicherheitssystem, das auf gemeinsamer IP-Reputation basiert. Wenn tausende Server weltweit eine angreifende IP-Adresse erkennen, kann Ihr Server diese blockieren, bevor überhaupt ein Angriff erfolgt.

Wie funktioniert CrowdSec?

• analysiert Systemlogs (nginx, ssh, wordpress)
• erkennt verdächtiges Verhalten
• tauscht Informationen über angreifende IP-Adressen mit anderen Servern aus
• blockiert den Datenverkehr auf Firewall-Ebene

Das Ergebnis? Die meisten Bots und Internet-Scanner erreichen Ihren Nginx-Server gar nicht erst.

Installation von CrowdSec auf Debian / Ubuntu

Die Installation von CrowdSec ist sehr einfach und direkt über die Debian-Repositories verfügbar.

apt update
apt install crowdsec

Während der Installation führt CrowdSec automatisch folgende Schritte aus:

• erstellt eine lokale API (LAPI)
• registriert den Server in der CrowdSec Central API
• lädt grundlegende Sicherheitsszenarien herunter

Installation des Firewall-Bouncers

CrowdSec erkennt Bedrohungen, benötigt jedoch eine ausführende Komponente — den sogenannten Bouncer, der den Datenverkehr in der Firewall blockiert.

apt install crowdsec-firewall-bouncer

Standardmäßig verwendet der Bouncer nftables und fügt automatisch Regeln zum Blockieren schädlicher IP-Adressen hinzu.

Installation der Sicherheitskollektionen

Kollektionen enthalten Log-Parser sowie Angriffserkennungs-Szenarien.

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

Laden Sie anschließend die Konfiguration neu:

systemctl reload crowdsec

Konfiguration der Nginx-Logs

Damit CrowdSec den HTTP-Verkehr analysieren kann, müssen die Nginx-Logdateien angegeben werden.

Datei bearbeiten:

nano /etc/crowdsec/acquis.yaml

Folgende Konfiguration hinzufügen:

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

Anschließend den Dienst neu starten:

systemctl restart crowdsec

Überprüfung der CrowdSec-Funktion

Dienststatus:

systemctl status crowdsec

Liste aktiver Sperren:

cscli decisions list

Systemmetriken:

cscli metrics

Endergebnis

Nach einer korrekten CrowdSec-Installation:

• blockiert der Server automatisch bekannte Botnetze
• werden WordPress- und SSH-Brute-Force-Angriffe bereits auf Firewall-Ebene gestoppt
• muss Nginx deutlich weniger schädlichen Traffic verarbeiten
• werden CPU- und IO-Ressourcen spürbar entlastet

CrowdSec kann als Weiterentwicklung von Fail2Ban betrachtet werden — ein System, das nicht nur lokal reagiert, sondern globale Bedrohungsinformationen nutzt.

Artykuł CrowdSec – Intelligenter Linux-Server-Schutz vor Botnetzen, Brute-Force-Angriffen und Internet-Scans pochodzi z serwisu soban.

Wenn du Fail2Ban zusammen mit Nginx und WordPress verwendest, wirst du früher oder später eine Sache bemerken: dieselben IP-Adressen kommen immer wieder zurück. Sie werden für einige Minuten oder eine Stunde gebannt, verschwinden … und versuchen kurz darauf erneut /.env, /wp-login.php, /phpmyadmin oder andere bekannte Angriffs-Pfade.

Die Lösung besteht nicht darin, die Filter aggressiver einzustellen. Die Lösung ist recidive — eine zweite Schutzebene in Fail2Ban, die die Bann-Historie analysiert und Wiederholungstäter langfristig blockiert.

Bezug zur vorherigen Konfiguration

Falls du noch keine grundlegende Fail2Ban-Konfiguration für Nginx und WordPress hast, habe ich sie hier beschrieben:

Fail2Ban + Nginx + WordPress – Grundkonfiguration

In diesem Artikel konfigurieren wir Jails wie nginx-exploit, nginx-secure oder sshd. Recidive ersetzt diese Konfiguration nicht — es verstärkt sie.

Wie man Wiederholungstäter in den Logs findet

Zunächst solltest du prüfen, ob das Problem tatsächlich besteht. Wir extrahieren aus den Fail2Ban-Logs die Liste der IP-Adressen, die am häufigsten gebannt wurden:

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

Beispielausgabe (Adressen teilweise anonymisiert):

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

Wenn du Zahlen wie 8, 9 oder 13 siehst, bedeutet das, dass diese IPs nach Ablauf des Banns zurückkehren. Eine kurze bantime ist für sie lediglich eine technische Pause.

Warum recidive besser ist als eine längere bantime

• Du musst nicht jeden für 24 Stunden bannen, nur wegen eines Tippfehlers in der URL.
• Du erhöhst nicht das Risiko, legitime Nutzer zu blockieren.
• Die Strafe ist progressiv und betrifft nur wiederkehrende Adressen.

Recidive analysiert /var/log/fail2ban.log und zählt, wie oft eine IP von anderen Jails gebannt wurde. Dadurch werden nur diejenigen „endgültig blockiert“, die bereits mehrfach aufgefallen sind.

Recidive-Konfiguration (5 Bans in 24h = 7 Tage Bann)

Füge folgenden Block in /etc/fail2ban/jail.local ein:

nano /etc/fail2ban/jail.local

Am Ende der Datei einfügen:

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

Datei speichern und Fail2Ban neu starten:

systemctl restart fail2ban

Status des Jails prüfen:

fail2ban-client status recidive

Wie man prüft, wer nahe am recidive-Schwellenwert ist

Wenn du IP-Adressen sehen möchtest, die bereits mehrere Bans haben und sich dem recidive-Schwellenwert nähern:

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

Zusammenfassung

Recidive ist eine der einfachsten und zugleich effektivsten Methoden, um wiederkehrende Scanner und Bots einzudämmen. Statt aggressiv alle zu bannen — blockierst du nur diejenigen, die mehrfach zurückkehren.

In einer Umgebung mit mehreren Domains, Nginx-Reverse-Proxy und WordPress ist es praktisch ein Pflichtbestandteil der Konfiguration: weniger Log-Rauschen, weniger wiederholte Angriffe und weniger manuelle Analyse.

Artykuł Fail2Ban: Wie man Wiederholungstäter erkennt und für eine Woche sperrt (Recidive) pochodzi z serwisu soban.

Proxmox VE 9 basiert auf Debian 13 (Trixie) und bringt einen neueren Kernel, aktualisierte Versionen von LXC und QEMU sowie einen verbesserten Virtualisierungs-Stack mit. Dieser Leitfaden beschreibt eine vereinfachte und automatisierte Methode zur Installation von Proxmox VE 9 auf einem sauberen Debian-13-System mithilfe von zwei Installationsskripten.

Die Methode folgt demselben Ansatz wie mein früherer Leitfaden zur Installation von Proxmox 8 auf Debian 12, wurde jedoch an Debian 13 und Proxmox VE 9 angepasst.

Voraussetzungen

• Frische Installation von Debian 13 (Trixie)
• Root-Zugriff
• Internetverbindung

Alle Befehle müssen als root ausgeführt werden.

Teil 1 – Systemvorbereitung & Installation des Proxmox-Kernels

Lade das erste Skript herunter:

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

Dieses Skript:

• Setzt den Hostnamen und aktualisiert die Datei /etc/hosts
• Installiert den Proxmox-Archive-Keyring (SHA512-verifiziert)
• Fügt das Proxmox VE 9 Repository für Debian 13 hinzu
• Führt ein vollständiges System-Upgrade durch
• Installiert proxmox-default-kernel
• Startet das System neu

Inhalt von 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 < /etc/apt/sources.list.d/pve-install-repo.list <

Teil 2 – Installation von Proxmox VE 9

Nach dem Neustart herunterladen und ausführen:

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

Inhalt von 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"
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)"
apt remove -y linux-image-amd64 || true

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"

Zugriff auf die Weboberfläche

Nach Abschluss des zweiten Skripts öffnen Sie:

https://YOUR_SERVER_IP:8006

Melden Sie sich mit dem Benutzer root und Ihrem Root-Passwort an. Eine Zertifikatswarnung ist bei einer frischen Installation normal.

Fehlerbehebung – 401 Unauthorized (pve-enterprise Repository)

Falls nach der Installation oder bei der Ausführung von apt update folgender Fehler erscheint:

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.

Dies bedeutet, dass das Enterprise-Repository aktiviert ist, aber Ihr System keine gültige Proxmox-Subskription besitzt. In diesem Leitfaden wird das pve-no-subscription-Repository verwendet, daher sollte das Enterprise-Repository deaktiviert werden.

Beheben Sie das Problem mit folgendem Befehl:

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

apt update

Danach sollte die Aktualisierung erfolgreich durchlaufen:

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

Wenn alles korrekt konfiguriert ist, erscheint die Meldung:

All packages are up to date.

Fazit

Diese Methode bietet eine saubere und kontrollierte Möglichkeit, Proxmox VE 9 direkt auf Debian 13 bereitzustellen, ohne den ISO-Installer zu verwenden. Besonders geeignet ist sie für automatisierte Umgebungen, Labore und individuelle Infrastruktur-Setups.

Artykuł Debian 13 (Trixie) → Proxmox VE 9 – Vereinfachte Installation auf einem reinen Debian-System pochodzi z serwisu soban.

Diese Anleitung zeigt die vollständige Installation und Konfiguration von Fail2Ban für Nginx und WordPress, um:

• Scanner und Bots zu blockieren (z. B. Zugriffe auf /.env, /.git, phpmyadmin usw.),
• den WordPress-Administrator nicht zu blockieren,
• eine IP nach 5 verdächtigen oder ungültigen Anfragen zu sperren,
• nur eine kurze Sperre von 5 Minuten anzuwenden (kein Risiko, sich selbst lange auszusperren).

Schritt 1: Fail2Ban installieren

Installieren Sie Fail2Ban:

apt update
apt install -y fail2ban

Aktivieren und starten Sie den Dienst:

systemctl enable fail2ban
systemctl start fail2ban

Überprüfen Sie den Status:

fail2ban-client ping
systemctl status fail2ban

Schritt 2: nginx-secure Filter erstellen

Erstellen Sie die Filterdatei:

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

Fügen Sie folgende Konfiguration ein:

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

Schritt 3: nginx-secure Jail erstellen

Erstellen Sie die Jail-Konfigurationsdatei:

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

Fügen Sie folgende Konfiguration ein:

[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

Schritt 4: Fail2Ban neu starten

fail2ban-server -t
systemctl restart fail2ban

Schritt 5: Firewall überprüfen

Überprüfen Sie, ob die Fail2Ban-Chain existiert:

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

Externer Test

Führen Sie dies von einer anderen Maschine aus:

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

Nach 5 Versuchen wird die IP-Adresse für 5 Minuten gesperrt.

Gesperrte IPs anzeigen

fail2ban-client status nginx-secure

IP entsperren

Entsperren Sie Ihre IP manuell:

fail2ban-client set nginx-secure unbanip IHRE_IP

Zusammenfassung

• schützt vor Scannern und Exploit-Versuchen,
• blockiert das WordPress-Admin-Panel nicht,
• verwendet eine kurze Sperrzeit von 5 Minuten,
• voll kompatibel mit iptables-nft,
• einfach zu testen und einfach zu entsperren.

Artykuł Fail2Ban + Nginx (WordPress-freundlich): 5 verdächtige Anfragen → 5-Minuten-Sperre (iptables-nft Fix, Tests und IP entsperren) pochodzi z serwisu soban.

Das Upgrade von Debian von Version 12 (bookworm) auf Version 13 (trixie) ist ein Vorgang, der auf Servern und Containern (z. B. Proxmox LXC oder virtuelle Maschinen) reproduzierbar und ohne Überraschungen durchgeführt werden sollte. Unten finden Sie eine einfache Anleitung sowie fertige Befehle zum Herunterladen und Ausführen des Upgrade-Skripts.

Vor dem Upgrade: erstellen Sie ein Backup oder einen Snapshot. In Proxmox ist die beste Option vzdump oder ein Snapshot. Auf Bare-Metal-Systemen sichern Sie mindestens /etc, Anwendungen und Datenbanken.

• Proxmox LXC / VM: Backup mit vzdump oder Snapshot.
• Server: Backup von /etc, /var/www, Datenbanken (MySQL/PostgreSQL) und SSL-Zertifikaten.

Download des Skripts:

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

1) Backup vor dem Upgrade (Beispiele)

Beispiel für ein Backup in Proxmox (auf dem Proxmox-Host ausführen, CTID/VMID ersetzen):

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

Beispiel für ein einfaches Dateisystem-Backup auf einem Server (ersetzt keinen vollständigen Snapshot, ist aber besser als nichts):

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

2) Skript herunterladen (wget / curl)

Am einfachsten verwenden Sie wget. Wenn der Befehl wget trotz installiertem Paket nicht funktioniert, verwenden Sie den vollständigen Pfad /usr/bin/wget.

Variante A (Standard wget):

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 mit vollständigem Pfad – hilfreich bei PATH-Problemen):

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

Variante C (curl):

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

3) Skripthilfe (Parameter)

Bevor Sie das Upgrade starten, zeigen Sie die verfügbaren Parameter und Beispiele an:

cd /root
./upgrade_to_debian13.sh --help

4) Upgrade Debian 12 → Debian 13 (nur System)

Wenn Sie derzeit Debian 12 (bookworm) verwenden und ein System-Upgrade durchführen möchten:

cd /root
./upgrade_to_debian13.sh

Das Skript erstellt ein Backup von /etc/apt/sources.list, wechselt die Repositories zu trixie, führt apt update und apt full-upgrade aus und anschließend autoremove und autoclean.

5) Automatische Erkennung von PHP/nginx und Update bei Bedarf

Wenn der Container oder die VM einen Webserver verwendet und das Skript automatisch PHP (nginx + fastcgi_pass) erkennen und PHP sowie nginx aktualisieren soll:

cd /root
./upgrade_to_debian13.sh --auto

6) PHP- und nginx-Upgrade erzwingen (PHP-FPM Socket Fix)

Wenn Sie die Installation oder das Upgrade von PHP erzwingen und die nginx-Konfiguration automatisch auf den richtigen PHP-FPM-Socket umstellen möchten:

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

Dieser Befehl installiert PHP 8.2 (php-fpm und gängige Module) und ersetzt alte PHP-FPM-Socket-Pfade in der nginx-Konfiguration durch /run/php/php8.2-fpm.sock. Anschließend wird nginx -t ausgeführt und die Dienste werden neu geladen oder neu gestartet.

7) Bereits Debian 13 installiert? Nur PHP/nginx Modus

Wenn das System bereits Debian 13 (trixie) verwendet und Sie nur PHP und nginx aktualisieren möchten, ohne die System-Repositories zu ändern:

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

8) Testmodus (Dry-Run)

Wenn Sie sehen möchten, was das Skript tun wird, ohne Änderungen vorzunehmen:

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

9) Diagnose: wget installiert, aber funktioniert nicht

Wenn apt meldet, dass wget installiert ist, aber die Shell command not found anzeigt, liegt meist ein PATH-Problem vor. Verwenden Sie in diesem Fall den vollständigen Pfad /usr/bin/wget.

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

Zusammenfassung

Diese Lösung ermöglicht ein sicheres Upgrade von Debian 12 → Debian 13 und behebt optional typische PHP/nginx-Probleme nach dem Upgrade. Erstellen Sie immer ein Backup vor dem Upgrade und beginnen Sie mit --help, um die verfügbaren Optionen zu prüfen.

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

Artykuł Automatisches Upgrade von Debian 12 → Debian 13 mit optionalem PHP – und nginx-Update pochodzi z serwisu soban.

Proxmox: Automatische VM-Updates (qm + vzdump) mit Netzwerktests und Auto-Wiederherstellung

In diesem Artikel zeige ich ein einfaches (aber sehr effektives) Skript zur Automatisierung von Updates für virtuelle Maschinen in Proxmox VE. Das Skript kann:

• ein Backup der VM erstellen (optional),
• die VM starten, falls sie vorher ausgeschaltet war,
• ein vollständiges System-Upgrade über apt durchführen und neu starten,
• Netzwerktests vor und nach dem Update ausführen,
• bei Problemen automatisch aus dem Backup wiederherstellen (optional),
• am Ende die VM wieder herunterfahren, wenn sie ursprünglich gestoppt war.

Woher bekommt man das Skript?

Du kannst das Skript direkt von meiner Webseite herunterladen:

soban.pl/bash/upgrade_proxmox_qm.sh

Benötigte Ordner

Bevor du die Automatisierung startest, erstelle zwei Ordner: einen für Skripte und einen für Logs:

mkdir -p /root/automate_scripts /root/logs

Skript installieren

Lade das Skript nach /root/automate_scripts/ herunter und mache es ausführbar:

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

Wie funktioniert es? (kurz erklärt)

• Zuerst wird ein Backup (vzdump snapshot + zstd) erstellt – wenn Backups aktiviert sind.
• Wenn die VM den Status stopped hatte, startet das Skript sie und wartet WAIT_TIME Sekunden.
• Danach werden Netzwerktests VOR dem Update ausgeführt:
• Das Skript führt apt update/upgrade/dist-upgrade/autoremove/clean aus und startet am Ende die VM neu (reboot).
• Nach dem Neustart wartet es erneut (WAIT_TIME) und führt die gleichen Tests NACH dem Update aus.
• Wenn die Tests fehlschlagen und ein Backup vorhanden ist, wird automatisch qmrestore ausgeführt.
• Am Ende fährt es die VM (optional) wieder herunter, wenn sie ursprünglich gestoppt war.

Manueller Start

Das Skript erwartet genau zwei Argumente:

• VMID – die VM-ID in Proxmox
• TIME_SEC – Wartezeit nach Start/Reboot (in Sekunden)

/root/automate_scripts/upgrade_proxmox_qm.sh 901 500

Tipp: Wähle WAIT_TIME passend zur realen Bootzeit der VM und der Dauer des Updates. In der Praxis sind 300 bis 1000 Sekunden meistens sinnvoll (je nach VM).

Vollständiges Skript (zum Einfügen / Nachschlagen)

Unten findest du das komplette Skript in der gleichen Form, wie es in dieser Automatisierung verwendet wird:

#!/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 "-----------------------------------"

Cron (wöchentlicher Zeitplan + separate Logs pro VM)

Unten ist ein Beispiel für crontab: Updates laufen einmal pro Woche (jeden Wochentag eine andere VM), und Logs werden in separate Dateien unter /root/logs/ geschrieben.

Bearbeite root crontab:

crontab -e

Füge folgende Regeln ein (Kommentare bleiben auf Englisch):

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)

Schnelle Checks / Troubleshooting

• Stelle sicher, dass root vom Proxmox-Host per SSH zur VM verbinden kann (das Skript nutzt ssh root@<vm-hostname>).
• Prüfe, ob DNS (oder /etc/hosts) den VM-Hostname auf dem Proxmox-Host korrekt auflöst.
• Wenn apt nach Bestätigungen fragt, stelle sicher, dass die VM non-interactive Upgrades unterstützt oder halte problematische Pakete zurück.

Das war’s. Legen Sie das Skript in /root/automate_scripts/ ab, senden Sie die Protokolle nach /root/logs/, und Ihre wöchentliche VM-Wartung wird größtenteils zu einer Routineaufgabe.

Artykuł Proxmox Automatische VM-Updates (qm + vzdump) mit Netzwerktests und Auto-Wiederherstellung pochodzi z serwisu soban.

Wenn du versuchst, die Firmware der Dell WD19/WD19S Dockingstation auf Proxmox (oder Debian) mit fwupdmgr zu aktualisieren, kannst du auf den klassischen Fehler Operation timed out während der Phase Erasing… stoßen. In der Praxis scheitert das Update oft wegen USB-Energieverwaltung (Autosuspend). Unten findest du einen einfachen, wirksamen Fix sowie ein fertiges Script zum Ausführen auf Server oder Laptop.

Symptome

Am häufigsten erscheint während des Dock-Updates (WD19/WD19S) ein Fehler ähnlich wie dieser:

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

In diesem Fall kann fwupdmgr das WD19S-Gerät als Update State: Failed anzeigen oder ständig pending activation melden – der Flash-Vorgang wird aber nicht vollständig abgeschlossen.

Warum passiert das?

Beim Flashen führt das Dock lang laufende Operationen aus. Wenn das System versucht, über USB Strom zu sparen (Autosuspend), können USB-Control-Transfers fehlschlagen. Das Ergebnis ist ein Timeout genau beim Löschen der Firmware-Bank (erase bank).

Schneller Fix: USB-Autosuspend während des Updates deaktivieren

Die einfachste Lösung ist, Autosuspend temporär auf -1 zu setzen (also deaktivieren). Diese Einstellung gilt bis zum Neustart (außer du machst sie dauerhaft per Kernel-Cmdline), reicht aber völlig für den Update-Prozess.

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

Danach startest du das Update:

fwupdmgr refresh --force
fwupdmgr update

Nach dem Update: „pending activation” und USB-Kabel trennen

Nach einer erfolgreichen Firmware-Installation für WD19/WD19S gibt fwupdmgr oft diese Meldung aus:

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

Dann gehst du genau so vor:

• USB-C-Kabel vom Dock trennen (vom Laptop).
• (Optional) Stromversorgung des Docks für 10–15 Sekunden trennen und wieder anschließen.
• USB-C-Kabel wieder einstecken.
• Aktivierung ausführen:

fwupdmgr activate

Am Ende überprüfst du den Status:

fwupdmgr get-updates
fwupdmgr get-devices | less

Fertiges Script: Installation + Update + Autosuspend deaktivieren (mit Restore)

Unten findest du ein fertiges Script, das:

• fwupd installiert
• LVFS-Metadaten aktualisiert
• USB-Autosuspend temporär deaktiviert (damit WD19S keine Timeouts wirft)
• Firmware-Updates ausführt
• danach den vorherigen Autosuspend-Wert wiederherstellt (auch wenn das Update fehlschlägt)

Du kannst das Script aus dem Artikel kopieren – oder schneller soll’s gehen: Du kannst es direkt herunterladen von:

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

Beispiel zum Download und Ausführen:

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

Wenn du den Inhalt vor dem Ausführen prüfen willst:

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

Falls less nicht installiert ist:

apt update
apt install -y less

Script (vollständiger Inhalt)

#!/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."

Script ausführen

Am einfachsten so:

chmod +x dell_updage.sh
./dell_updage.sh

FAQ & Tipps

• Update schlägt immer noch fehl? Trenne alle Geräte vom Dock (Monitore/LAN/USB), lasse nur Strom und USB-C, führe einen Hard-Reset durch (Strom 30s abziehen) und versuche es erneut.
• „pending activation” nach dem Update – das ist bei WD19/WD19S normal. Du musst USB-C abziehen, wieder einstecken und dann fwupdmgr activate ausführen.
• Aktualisiert das den Laptop-BIOS? Nicht immer. fwupdmgr zeigt „System Firmware” (BIOS/UEFI) separat vom Dock. Dieser Artikel konzentriert sich auf das Dock und das USB-Timeout-Problem.

Zusammenfassung

Wenn ein Dell WD19/WD19S Firmware-Update auf Proxmox/Debian während Erasing… scheitert, reicht es in den meisten Fällen, USB-Autosuspend temporär zu deaktivieren. Das Script oben macht das automatisch und stellt danach die vorherige Einstellung wieder her, damit dein System normal weiterläuft.

Artykuł Dell WD19/WD19S: Firmware-Update auf Proxmox/Debian ohne USB-Timeouts (fwupd + Autosuspend-Fix) pochodzi z serwisu soban.

iftop bietet verschiedene Filteroptionen, mit denen sich die Anzeige auf bestimmte Hosts, Netzwerke oder Ports beschränken lässt. Es unterstützt IPv6 und kann Quell- und Ziel-IP-Adressen, Portnummern sowie verwendete Protokolle anzeigen.

Das Tool ist besonders nützlich, um den Netzwerkverkehr in Echtzeit zu überwachen und Dienste oder Hosts zu identifizieren, die die meiste Bandbreite verbrauchen. Zudem hilft es dabei, Leistungsprobleme im Netzwerk zu erkennen und die Fehlersuche zu erleichtern.

Zusammenfassend ist iftop ein leichtgewichtiges, aber leistungsstarkes Werkzeug und eine wertvolle Ergänzung für das Toolkit jedes System- oder Netzwerkadministrators.

Eines der nützlichsten Netzwerk-Monitoring-Tools, das ich verwende, ist iftop. Besonders hilfreich ist es, wenn die Netzwerkverbindung ausgelastet oder gesättigt ist. In der Praxis kann es auch dabei helfen, ungewöhnliche Verkehrsmuster zu erkennen, beispielsweise DoS-Angriffe. Im folgenden Beispiel übertrage ich eine große Datei auf eine entfernte Maschine mit begrenzter Bandbreite und beobachte dabei den Datenverkehr mit iftop.

Zunächst installieren wir iftop auf der lokalen Maschine (in diesem Fall Kali Linux):

# apt install iftop

Die verwendete Distribution spielt keine große Rolle — iftop ist in den meisten Linux-Repositories verfügbar, unter anderem auch unter Debian.

Nun installieren wir iftop auf der entfernten Maschine (Debian Linux):

# apt install iftop

Um die Überwachung des Netzwerkverkehrs zu starten, führen wir iftop mit den Parametern -PpNn aus:

# iftop -PpNn

Da ich per SSH mit der entfernten Maschine verbunden bin, sehe ich meine aktive SSH-Sitzung in der Verbindungsübersicht.

Nun wechseln wir zurück zur lokalen Maschine und erstellen eine große Datei:

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

Nachdem die 1-GB-Datei erstellt wurde, übertragen wir sie mit einer Bandbreitenbegrenzung auf die entfernte Maschine:

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

Die Option -l 800 begrenzt die Übertragungsrate auf 800 Kbit/s. Um dies in KB/s umzurechnen, teilt man durch 8 — das ergibt ungefähr 100 KB/s.

Auf diese Weise lässt sich sowohl ausgehender als auch eingehender Datenverkehr in Echtzeit beobachten. Obwohl iftop ein einfaches Tool ist, bietet es eine sehr gute Transparenz der aktuellen Netzwerkaktivität.

Bei Brute-Force-Angriffen sieht man in der Regel viele kurzlebige Verbindungen. Ein DoS-Angriff hingegen zielt darauf ab, die Bandbreite zu saturieren, was sich durch hohen eingehenden Datenverkehr bemerkbar macht. Ist ein Traffic-Anstieg legitim, kann man eine Begrenzung der Verbindungsgeschwindigkeit in Betracht ziehen — beispielsweise mit iptables.

Artykuł iftop als gutes Tool zur Überwachung des Netzwerkverkehrs pochodzi z serwisu soban.

In diesem Beispiel verwenden wir Debian 11 (Bullseye). Zunächst überprüfen wir die Systemversion:

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

Nmap ist eines der leistungsfähigsten Open-Source-Tools für Netzwerkscans und Sicherheitsanalysen. Es ermöglicht das Scannen offener Ports, das Erkennen aktiver Dienste, die Identifikation von Softwareversionen sowie die Analyse unterstützter SSL/TLS-Protokolle und Cipher Suites.

Die Installation unter Debian 11 ist einfach:

# apt install nmap

Nach der Installation können wir einen entfernten HTTPS-Server analysieren. Zum Beispiel:

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

Die Option -sV aktiviert die Diensterkennung mit Versionsinformationen, während --script ssl-enum-ciphers die unterstützten TLS-Versionen und Cipher Suites analysiert. Dadurch können Sie überprüfen:

• welche TLS-Versionen aktiv sind (TLS 1.0, 1.1, 1.2, 1.3),
• ob schwache Verschlüsselungen wie 3DES unterstützt werden,
• ob potenzielle kryptografische Schwachstellen vorhanden sind.

Nmap ist langsamer als Tools wie sslscan, liefert jedoch sehr detaillierte Ergebnisse und eignet sich besonders für interne Infrastrukturtests.

TLS 1.0:

TLS 1.1:

TLS 1.2:

Der wichtigste Punkt bei der SSL/TLS-Analyse ist die Identifikation schwacher oder veralteter Verschlüsselungsverfahren.

Wenn folgende Meldung erscheint:

„64-bit block cipher 3DES vulnerable to SWEET32 attack“

bedeutet dies, dass der Server noch 3DES unterstützt, welches für die SWEET32-Attacke anfällig ist. In Produktionsumgebungen sollte diese Verschlüsselung deaktiviert werden.

Für die Analyse öffentlicher Websites können Sie zusätzlich folgenden Dienst nutzen:

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

Für interne Server, Testumgebungen oder private Infrastrukturen ist jedoch die direkte Analyse mit Nmap unter Debian eine effiziente und unabhängige Lösung.

Regelmäßige SSL/TLS-Scans helfen dabei, ein hohes Sicherheitsniveau aufrechtzuerhalten und veraltete Protokolle sowie schwache Cipher Suites konsequent zu entfernen.

Artykuł SSL – und TLS-Analyse mit Nmap unter Debian 11 pochodzi z serwisu soban.