Februar 2026

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