UFW & Fail2ban (Netzwerkschutz und Angriffsblockierung)

1. Konzeptüberblick und Systemproblem

Ein öffentlich erreichbarer Linux-Server im Internet ist einem kontinuierlichen automatisierten Scanning durch Botnetze ausgesetzt. Scanner suchen nach offenen Ports, schwachen SSH-Passwörtern, ungeschützten Datenbankports (PostgreSQL, Redis, MySQL) sowie nicht gesicherten Admin-Panels. Ohne systemweite Firewall wird der Server anfällig für Denial-of-Service-Angriffe (DoS), die Erschöpfung von Socket-Deskriptoren-Limits und direkten unbefugten Zugriff.

UFW (Uncomplicated Firewall) und Fail2ban bilden ein zweistufiges aktives Schutzsystem:

• UFW (Statische Ebene): Eine vereinfachte Konfigurationsschnittstelle für das iptables / nftables-Subsystem des Linux-Kernels nach dem Default-Deny-Prinzip: Alle eingehenden Verbindungen werden blockiert, mit Ausnahme explizit erlaubter Ports (SSH, HTTP/HTTPS).
• Fail2ban (Dynamische Ebene): Ein Daemon zur Verhaltensanalyse, der Systemlogs überwacht und Firewall-Regeln dynamisch anpasst, um IP-Adressen von Bots zu isolieren, die Muster von Brute-Force-Angriffen oder Vulnerability-Probing zeigen.

+-------------------------------------------------------------------+
| Вхідний трафік (Інтернет)                                         |
+---------------------------------+---------------------------------+
                                  |
                                  v
                   +-----------------------------+
                   |       Fail2ban Демон        |
                   | (Аналіз логів journald/auth)|
                   +--------------+--------------+
                                  | Динамічний DROP (наприклад, 24 год)
                                  v
                   +-----------------------------+
                   |        UFW / Netfilter      |
                   |  (iptables / nftables ядра) |
                   +--------------+--------------+
                                  |
              +-------------------+-------------------+
              | Дозволено (22, 80, 443)              | Заблоковано (DROP)
              v                                       v
    +-------------------+                   +-------------------+
    | Системні сервіси  |                   | Пакет знищено     |
    | (Nginx, SSHd)     |                   | без відповіді     |
    +-------------------+                   +-------------------+

2. Architektonische Taxonomie und mentales Modell

Der Host-Schutz basiert auf einer klaren Aufgabenteilung der Komponenten:

1. Kernel-Netzwerkfilter (Netfilter / nftables):
   • Die Low-Level-Engine im Linux-Kernel, die Header jedes Netzwerk-Pakets an den Netzwerkschnittstellen prüft.
2. UFW (Uncomplicated Firewall):
   • Ein Utility zur einfachen Verwaltung der Filterketten INPUT, OUTPUT, FORWARD.
   • Bietet eine menschenlesbare Syntax als Alternative zu den komplexen Konstrukten von iptables.
   • Erzwingt eine statische Policy: Blockierung nicht autorisierter Port-Bereiche.
3. Fail2ban (Infiltration Prevention Framework):
   • Jail: Eine Konfigurationsentität, die einen Filter (filter.d), Log-Dateien und eine Blocking-Aktion (action.d) verknüpft.
   • Filter: Ein Satz regulärer Ausdrücke (failregex) zum Parsen von Authentifizierungsfehlern.
   • Action: Eine Anweisung (z. B. iptables-multiport), die temporär IPs in eine Kette zum Verwerfen von Paketen aufnimmt.

3. Technischer Pipeline und interne Mechanik

Basisinstallation und UFW-Konfiguration

[!IMPORTANT] Erlauben Sie immer den SSH-Port vor der Aktivierung der Firewall, um zu verhindern, dass Ihre eigene Sitzung gesperrt wird:

# 1. Скидання та дефолтні політики (заборонити все вхідне, дозволити вихідне)
sudo ufw default deny incoming
sudo ufw default allow outgoing

# 2. Дозвіл критичних портів
sudo ufw allow 22/tcp comment "OpenSSH"
sudo ufw allow 80/tcp comment "HTTP (Let's Encrypt)"
sudo ufw allow 443/tcp comment "HTTPS"

# 3. Активація фаєрволу
sudo ufw --force enable
sudo ufw status verbose

Fail2ban-Konfiguration (/etc/fail2ban/jail.local)

Editieren Sie niemals direkt jail.conf (diese Datei wird bei Paketupdates überschrieben); erstellen Sie stattdessen eine Override-Datei:

[DEFAULT]
# Список довірених IP (білий список, який ніколи не блокується)
ignoreip = 127.0.0.1/8 ::1 198.51.100.12

# Час блокування (1 день) та вікно спостереження (10 хвилин)
bantime  = 24h
findtime = 10m
maxretry = 5

# Використання systemd backend для сучасних дистрибутивів (Ubuntu 22.04/24.04, Debian 12)
backend = systemd
banaction = ufw

[sshd]
enabled = true
port    = 22
mode    = aggressive

[nginx-http-auth]
enabled = true
port    = http,https
logpath = /var/log/nginx/error.log

Daemon-Verwaltung:

sudo systemctl enable --now fail2ban
# Перевірка статусу ізолятора SSH
sudo fail2ban-client status sshd

4. Praktische Engineering-Szenarien im Production-Umfeld

01. Schutz gegen gezieltes Vulnerability-Scanning von Nginx / Webservern

Angreifer starten Scanner (nikto, sqlmap), die hunderte Anfragen an /wp-login.php, /.env, /phpmyadmin generieren. Erstellen Sie einen benutzerdefinierten Filter /etc/fail2ban/filter.d/nginx-botsearch.conf, der Statuscodes 404 und 403 für diese Pfade in den Logs überwacht. Nach 3 Versuchen wird die IP auf Firewallebene für 7 Tage blockiert, was die CPU-Ressourcen der Instanz schont.

02. Einschränkung des Zugriffs auf interne Prometheus-Metriken und DB-Services

Ein Monitoring-Server oder eine PostgreSQL-Datenbank muss möglicherweise auf externen Interfaces lauschen, um Replikation oder Metric-Scraping zu ermöglichen. Anstatt Ports öffentlich zu öffnen, konfigurieren Sie Einschränkungen basierend auf spezifischen IP-Adressen von Partnerknoten:

sudo ufw allow from 10.0.0.15 to any port 9090 proto tcp comment "Prometheus scraper"
sudo ufw allow from 10.0.0.20 to any port 5432 proto tcp comment "Postgres Replica"

Alle anderen Anfragen an diese Ports werden verworfen, ohne TCP RST zu senden (Stealth-Modus).

03. Notfall-Unblockierung über fail2ban-client

Ein Entwickler hat sich beim Verbinden mit einem falschen Key vertippt, und seine private IP wurde gebannt. Der Administrator verbindet sich über einen Jump-Host und hebt die Sperre auf, ohne den gesamten Dienst neu zu starten:

sudo fail2ban-client set sshd unbanip 203.0.113.45

5. Fallstricke, typische Fehler und Sicherheit

1. Docker umgeht UFW via iptables: Wenn Docker einen Container mit dem Parameter -p 8080:8080 startet, erstellt es Regeln in der PREROUTING-Kette, die Vorrang vor UFW-Regeln haben. Der Port ist für die gesamte Welt offen, selbst wenn ufw status eine Sperrung anzeigt. Beheben Sie dies, indem Sie Ports ausschließlich an Loopback binden (-p 127.0.0.1:8080:8080) oder die iptables-Verwaltung in /etc/docker/daemon.json deaktivieren ({"iptables": false}).
2. Log-Overflow bei fehlendem logrotate: Wenn Fail2ban gigabytegroße Webserver-Logs ohne Rotation parst, beginnt der Daemon, 100 % der CPU-Kerne zu verbrauchen, während er versucht, die Datei von Anfang an zu lesen. Stellen Sie sicher, dass logrotate die Logdateien korrekt komprimiert.
3. Blockierung eigener Proxies (Cloudflare / Reverse Proxy): Wenn der Webserver hinter Cloudflare oder AWS ALB läuft, blockiert Fail2ban in der Standardkonfiguration die IP-Adressen von Cloudflare selbst, anstatt der echten Clients. Konfigurieren Sie das Modul mod_remoteip in Nginx/Apache, um X-Forwarded-For wiederherzustellen, bevor Sie HTTP-Jails aktivieren.