Archiwa Uncategorized

CrowdSec – Intelligenter Linux-Server-Schutz vor Botnetzen, Brute-Force-Angriffen und Internet-Scans

Posted on Februar 27, 2026Februar 27, 2026 by soban

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

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

1	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

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

1	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

1	nano /etc/crowdsec/acquis.yaml

Folgende Konfiguration hinzufügen:

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

Anschließend den Dienst neu starten:

systemctl restart crowdsec

1	systemctl restart crowdsec

Überprüfung der CrowdSec-Funktion

Dienststatus:

systemctl status crowdsec

1	systemctl status crowdsec

Liste aktiver Sperren:

cscli decisions list

1	cscli decisions list

Systemmetriken:

cscli metrics

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

Fail2Ban: Wie man Wiederholungstäter erkennt und für eine Woche sperrt (Recidive)

Posted on Februar 26, 2026Februar 26, 2026 by 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

1	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

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

1	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

[recidive]

enabled = true

logpath = /var/log/fail2ban.log

bantime = 7d

findtime = 1d

maxretry = 5

Datei speichern und Fail2Ban neu starten:

systemctl restart fail2ban

1	systemctl restart fail2ban

Status des Jails prüfen:

fail2ban-client status recidive

1	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

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

Debian 13 (Trixie) → Proxmox VE 9 – Vereinfachte Installation auf einem reinen Debian-System

Posted on Februar 23, 2026Februar 24, 2026 by 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

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

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

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"

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

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

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

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

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

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

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

Wenn alles korrekt konfiguriert ist, erscheint die Meldung:

All packages are up to date.

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

Fail2Ban + Nginx (WordPress-freundlich): 5 verdächtige Anfragen → 5-Minuten-Sperre (iptables-nft Fix, Tests und IP entsperren)

Posted on Februar 16, 2026 by 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

1 2	apt update apt install -y fail2ban

Aktivieren und starten Sie den Dienst:

systemctl enable fail2ban
systemctl start fail2ban

1 2	systemctl enable fail2ban systemctl start fail2ban

Überprüfen Sie den Status:

fail2ban-client ping
systemctl status fail2ban

1 2	fail2ban-client ping systemctl status fail2ban

Schritt 2: nginx-secure Filter erstellen

Erstellen Sie die Filterdatei:

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

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

[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

1	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

[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

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

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

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

1	fail2ban-client status nginx-secure

IP entsperren

Entsperren Sie Ihre IP manuell:

fail2ban-client set nginx-secure unbanip IHRE_IP

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

Automatisches Upgrade von Debian 12 → Debian 13 mit optionalem PHP – und nginx-Update

Posted on Februar 16, 2026Februar 16, 2026 by 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

1	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

1	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

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

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) Skripthilfe (Parameter)

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

cd /root
./upgrade_to_debian13.sh --help

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

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

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

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

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

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

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

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

Posted on Januar 23, 2026Januar 23, 2026 by 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

1	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

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

1	/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 "-----------------------------------"

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 (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

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

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.

Dell WD19/WD19S: Firmware-Update auf Proxmox/Debian ohne USB-Timeouts (fwupd + Autosuspend-Fix)

Posted on Januar 18, 2026Januar 18, 2026 by 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]

1	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

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

Danach startest du das Update:

fwupdmgr refresh --force
fwupdmgr update

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

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.

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

1	fwupdmgr activate

Am Ende überprüfst du den Status:

fwupdmgr get-updates
fwupdmgr get-devices | less

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

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

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

Falls less nicht installiert ist:

apt update
apt install -y less

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

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

Script ausführen

Am einfachsten so:

chmod +x dell_updage.sh
./dell_updage.sh

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

iftop als gutes Tool zur Überwachung des Netzwerkverkehrs

Posted on November 4, 2021Februar 26, 2026 by soban

iftop ist ein Kommandozeilen-Tool zur Echtzeit-Überwachung der Netzwerkbandbreite. Es zeigt eine kontinuierlich aktualisierte Liste von Netzwerkverbindungen sowie die zwischen ihnen übertragenen Datenmengen an. Die Verbindungen werden tabellarisch dargestellt und können nach Bandbreitennutzung sortiert werden.

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

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

1	# apt install iftop

Installation von iftop unter Debian Linux

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

# iftop -PpNn

1	# iftop -PpNn

iftop während der Überwachung des Netzwerkverkehrs

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

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

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

Dateiübertragung mit Geschwindigkeitsbegrenzung über scp

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.

SSL – und TLS-Analyse mit Nmap unter Debian 11

Posted on September 30, 2021Februar 26, 2026 by soban

SSL- und TLS-Analyse mit Nmap unter Debian 11

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

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

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

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

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