February 2026

CrowdSec – Intelligent Linux Server Protection Against Botnets, Brute-Force Attacks and Internet Scanning

Posted on February 27, 2026February 27, 2026 by soban

If you run a Linux server with Nginx, SSH, or WordPress, you probably already know Fail2Ban. It is a solid tool, but it works locally — it blocks only the IP addresses that attacked your server.

CrowdSec works in a completely different way. It is a protection system based on shared IP reputation. If thousands of servers worldwide detect a malicious IP address, your server can block it before an attack even happens.

How Does CrowdSec Work?

analyzes system logs (nginx, ssh, wordpress)
detects suspicious behavior
shares attacker IP intelligence with other servers
blocks traffic at the firewall level

The result? Most bots and internet scanners never even reach your Nginx server.

Installing CrowdSec on Debian / Ubuntu

CrowdSec installation is very simple and available directly from Debian repositories.

apt update
apt install crowdsec

1 2	apt update apt install crowdsec

During installation, CrowdSec automatically:

creates a local API (LAPI)
registers the server in CrowdSec Central API
downloads default security scenarios

Installing Firewall Bouncer

CrowdSec detects threats, but it requires an enforcement component — called a bouncer — which blocks traffic at the firewall level.

apt install crowdsec-firewall-bouncer

1	apt install crowdsec-firewall-bouncer

By default, the bouncer uses nftables and automatically adds blocking rules for malicious IP addresses.

Installing Security Collections

Collections include log parsers and attack detection scenarios.

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

Reload configuration after installation:

systemctl reload crowdsec

1	systemctl reload crowdsec

Configuring Nginx Logs

To allow CrowdSec to analyze HTTP traffic, you must specify Nginx log files.

Edit the file:

nano /etc/crowdsec/acquis.yaml

1	nano /etc/crowdsec/acquis.yaml

Add the following configuration:

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

Then restart the service:

systemctl restart crowdsec

1	systemctl restart crowdsec

Verifying CrowdSec Operation

Service status:

systemctl status crowdsec

1	systemctl status crowdsec

Active bans list:

cscli decisions list

1	cscli decisions list

Operational metrics:

cscli metrics

1	cscli metrics

Final Result

After proper CrowdSec installation:

the server automatically blocks known botnets
WordPress attacks and SSH brute-force attempts are stopped at the firewall
Nginx handles significantly less malicious traffic
server CPU and IO usage are noticeably reduced

CrowdSec can be considered an evolution of Fail2Ban — a system that not only reacts locally but also benefits from global threat intelligence.

Fail2Ban: How to Detect Repeat Offenders and Ban Them for a Week (Recidive)

Posted on February 26, 2026February 26, 2026 by soban

If you use Fail2Ban with Nginx and WordPress, sooner or later you’ll notice one thing: the same IP addresses keep coming back. They get banned for a few minutes or an hour, disappear… and shortly after try again /.env, /wp-login.php, /phpmyadmin, or other common attack paths.

The solution is not to aggressively tighten the filters. The solution is recidive — a second layer of protection in Fail2Ban that analyzes the ban history and blocks repeat offenders long-term.

Reference to the previous configuration

If you don’t yet have a basic Fail2Ban configuration for Nginx and WordPress, I described it here:

Fail2Ban + Nginx + WordPress – basic configuration

In that article, we configure jails such as nginx-exploit, nginx-secure, and sshd. Recidive does not replace that configuration — it strengthens it.

How to find repeat offenders in the logs

First, it’s worth checking whether the issue actually exists. We extract from the Fail2Ban logs the list of IP addresses that were banned most frequently:

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

Example output (addresses partially anonymized):

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

If you see numbers like 8, 9, or 13 — it means those IPs are coming back after the ban expires. A short bantime is just a technical pause for them.

Why recidive is better than increasing bantime

You don’t have to ban everyone for 24 hours because of a single typo in a URL.
You don’t increase the risk of blocking legitimate users.
The penalty is progressive and applies only to returning addresses.

Recidive analyzes /var/log/fail2ban.log and counts how many times a given IP has been banned by other jails. This way, you only “finish off” those that have already been blocked multiple times before.

Recidive configuration (5 bans in 24h = 7 days ban)

Add the following block to /etc/fail2ban/jail.local:

nano /etc/fail2ban/jail.local

1	nano /etc/fail2ban/jail.local

At the end of the file, paste:

[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

Save the file and restart Fail2Ban:

systemctl restart fail2ban

1	systemctl restart fail2ban

Check the jail status:

fail2ban-client status recidive

1	fail2ban-client status recidive

How to check who is close to the recidive threshold

If you want to see IPs that already have several bans and are approaching the recidive threshold:

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

Summary

Recidive is one of the simplest and most effective ways to limit recurring scanners and bots. Instead of aggressively banning everyone — you block only those who repeatedly come back.

In an environment with multiple domains, Nginx reverse proxy, and WordPress, it’s practically a must-have configuration element: less noise in logs, fewer repeated attacks, and less manual analysis.

Debian 13 (Trixie) → Proxmox VE 9 – Simplified Installation on Pure Debian

Posted on February 23, 2026February 24, 2026 by soban

Proxmox VE 9 is based on Debian 13 (Trixie) and introduces a newer kernel, updated LXC, QEMU and improved virtualization stack. This guide presents a simplified and automated method to install Proxmox VE 9 on a clean Debian 13 system using two installation scripts.

The method follows the same approach as my previous Proxmox 8 on Debian 12 guide, but adapted for Debian 13 and Proxmox VE 9.

Prerequisites

Fresh Debian 13 (Trixie) installation
Root access
Internet connectivity

All commands must be executed as root.

Part 1 – System Preparation & Proxmox Kernel Installation

Download the first script:

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

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

chmod +x install-proxmox9-part1.sh

./install-proxmox9-part1.sh

This script:

Sets hostname and updates /etc/hosts
Installs Proxmox archive keyring (verified via SHA512)
Adds Proxmox VE 9 repository for Debian 13
Performs full system upgrade
Installs proxmox-default-kernel
Reboots the system

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

Part 2 – Proxmox VE 9 Installation

After reboot, download and execute:

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

Content of install-proxmox9-part2.sh

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

#!/usr/bin/env bash

set -euo pipefail

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

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

# - installs proxmox-ve + required packages

# - removes Debian kernel packages (keeps pve)

# - updates grub

# - removes os-prober

# - prints URL to GUI

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

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

FORCE="${FORCE:-0}"

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

die "Run as root."

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

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

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

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

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

Reboot and select the Proxmox kernel first.

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

else

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

else

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

log "Update package lists"

apt update

log "Install Proxmox VE packages"

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

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

log "Upgrade remaining packages"

apt full-upgrade -y

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

# Remove Debian meta kernel (keeps proxmox kernel)

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

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

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

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

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

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

log "Update grub"

update-grub || true

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

apt remove -y os-prober || true

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

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

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

log "Login: root + your root password"

Accessing the Web Interface

After completing the second script, open:

https://YOUR_SERVER_IP:8006

1	https://YOUR_SERVER_IP:8006

Login with the root user and your root password. You may see a certificate warning — this is normal for fresh installations.

Troubleshooting – 401 Unauthorized (pve-enterprise repository)

If after installation or during apt update you encounter the following error:

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.

This means the enterprise repository is enabled but your system does not have a valid Proxmox subscription. If you are using the no-subscription repository (as shown in this guide), you should disable the enterprise repository.

Fix it by running:

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

After this, the update should complete successfully:

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

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

If everything is correct, you should see:

All packages are up to date.

1	All packages are up to date.

Conclusion

This method provides a clean and controlled way to deploy Proxmox VE 9 directly on Debian 13 without using the ISO installer. It is especially useful for automated environments, labs, and custom infrastructure setups.

Fail2Ban + Nginx (WordPress-friendly): 5 suspicious requests → 5-minute ban (iptables-nft fix, testing and IP unban)

Posted on February 16, 2026 by soban

This guide shows a complete Fail2Ban installation and configuration for Nginx and WordPress, designed to:

block scanners and bots (e.g. attempts to access /.env, /.git, phpmyadmin, etc.),
avoid blocking the WordPress administrator,
ban IP addresses after 5 suspicious or invalid requests,
apply only a 5-minute ban (no risk of locking yourself out for long).

Step 1: Install Fail2Ban

Install Fail2Ban:

apt update
apt install -y fail2ban

1 2	apt update apt install -y fail2ban

Enable and start the service:

systemctl enable fail2ban
systemctl start fail2ban

1 2	systemctl enable fail2ban systemctl start fail2ban

Verify that it is running:

fail2ban-client ping
systemctl status fail2ban

1 2	fail2ban-client ping systemctl status fail2ban

Step 2: Create the nginx-secure filter

Create the filter file:

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

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

Paste the following configuration:

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

Step 3: Create the nginx-secure jail

Create the jail configuration file:

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

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

Paste the following configuration:

[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

Step 4: Restart Fail2Ban

fail2ban-server -t
systemctl restart fail2ban

1 2	fail2ban-server -t systemctl restart fail2ban

Step 5: Verify firewall integration

Check that the Fail2Ban chain exists:

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

External test

Run from another machine:

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

for i in 1 2 3 4 5; do

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

done

After 5 attempts, the IP address will be banned for 5 minutes.

Check banned IPs

fail2ban-client status nginx-secure

1	fail2ban-client status nginx-secure

Unban IP address

Unban your IP manually:

fail2ban-client set nginx-secure unbanip YOUR_IP

1	fail2ban-client set nginx-secure unbanip YOUR_IP

Summary

protects against scanners and exploit attempts,
does not block the WordPress admin panel,
uses a short 5-minute ban duration,
fully compatible with iptables-nft,
easy to test and easy to unban IP addresses.

Automatic upgrade Debian 12 → Debian 13 with optional PHP and nginx update

Posted on February 16, 2026February 16, 2026 by soban

Upgrading Debian from version 12 (bookworm) to 13 (trixie) is an operation that should be performed in a repeatable and predictable way, especially on servers and containers (for example Proxmox LXC or virtual machines). Below you will find a simple guide and ready-to-use commands to download and run the upgrade script.

Before running the upgrade: create a backup or snapshot. In Proxmox, the best option is vzdump or a snapshot. On bare metal, at minimum back up /etc, applications, and databases.

Proxmox LXC / VM: backup using vzdump or create a snapshot.
Server: backup /etc, /var/www, databases (MySQL/PostgreSQL), and SSL certificates.

Script download:

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

1) Backup before upgrade (examples)

Example backup in Proxmox (run on Proxmox host, replace CTID/VMID):

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

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

Example simple filesystem backup on a server (this does not replace a full snapshot, but it’s better than nothing):

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) Download the script (wget / curl)

The easiest way is to use wget. If the wget command does not work even though the package is installed, use the full path /usr/bin/wget.

Variant 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

Variant B (wget with full path – useful if PATH is broken):

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

Variant 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) Script help (parameters)

Before running the upgrade, display available parameters and usage examples:

cd /root
./upgrade_to_debian13.sh --help

1 2	cd /root ./upgrade_to_debian13.sh --help

4) Upgrade Debian 12 → Debian 13 (system only)

If you are currently running Debian 12 (bookworm) and want to perform a system upgrade:

cd /root
./upgrade_to_debian13.sh

1 2	cd /root ./upgrade_to_debian13.sh

The script will create a backup of /etc/apt/sources.list, switch repositories to trixie, run apt update and apt full-upgrade, and finally execute autoremove and autoclean.

5) Auto-detect PHP/nginx and update if needed

If the container or VM is running a web stack and you want the script to automatically detect PHP usage (nginx + fastcgi_pass) and upgrade PHP and nginx if necessary:

cd /root
./upgrade_to_debian13.sh --auto

1 2	cd /root ./upgrade_to_debian13.sh --auto

6) Force PHP and nginx upgrade (PHP-FPM socket fix)

If you want to force installation or upgrade of PHP and automatically fix nginx configuration to use the correct PHP-FPM socket:

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

This command installs PHP 8.2 (php-fpm and common modules) and replaces old PHP-FPM socket paths in nginx configuration with /run/php/php8.2-fpm.sock. Then it runs nginx -t and reloads or restarts services.

7) Already running Debian 13? PHP/nginx only mode

If the system is already running Debian 13 (trixie) and you only want to upgrade PHP and nginx without modifying system repositories:

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) Dry-run mode (test mode)

If you want to see what the script will do without making any changes:

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

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

9) Troubleshooting: wget installed but not working

If apt reports wget is installed but the shell shows command not found, it is usually a PATH issue. The easiest workaround is to use the full path: /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

Summary

This solution provides a convenient way to upgrade Debian 12 → Debian 13 and optionally fix common PHP/nginx issues after upgrade (PHP-FPM socket paths, nginx config testing, and service restart). Always create a backup before upgrading and start by running --help to review available options.

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