Firewall-Konfiguration: UFW, iptables und Sicherheitsstrategie

Eine Server-Alarm-SMS reißt Sie mitten in der Nacht aus dem Schlaf – in einer Testumgebung wurde die Datenbank mit ungewöhnlichem Traffic gescannt. Auf dem Server angekommen: Die Firewall war aus. Schnell aktiviert – und in der Regelliste lagen chaotische Test-Konfigurationen, der SSH-Port ohne Ratenbegrenzung.

Das zeigt ein häufiges Problem: Viele konfigurieren Firewalls mit ein paar kopierten Befehlen oder wissen gar nicht, was UFW und iptables unterscheidet – geschweige denn, wie man eine Sicherheitsstrategie systematisch plant. Genau darüber geht es hier.

Was Linux-Firewalls eigentlich sind

Bevor es um Firewalls geht: Netfilter – ein oft verwechselter Begriff. Viele halten iptables für die Firewall. Stimmt so nicht.

Netfilter ist das Paketverarbeitungs-Framework im Linux-Kernel. An strategischen Stellen im Netzwerk-Stack sitzen Hooks – jedes Paket löst sie aus, und Sie können Logik zum Blockieren, Ändern oder Protokollieren anbinden.

iptables, UFW und nftables sind nur Benutzerland-Schnittstellen. Ihre Regeln werden in ein Format übersetzt, das Netfilter im Kernel versteht und ausführt.

Analogie: Netfilter ist das Ventilsystem unter der Straße, iptables der alte Handgriff, UFW ein Touch-Panel – alle steuern dieselben Ventile, nur die Bedienung unterscheidet sich.

Evolution der Benutzerland-Tools

Linux-Firewall-Tools haben sich stark weiterentwickelt:

• iptables: Klassiker seit etwa 2000. Direkter Zugriff auf Netfilter – komplexe Syntax, volle Kontrolle.
• nftables: Moderner Nachfolger seit 2014. Einheitlichere Syntax, bessere Performance; neuere Ubuntu-Versionen nutzen es standardmäßig als Backend.
• UFW (Uncomplicated Firewall): Seit 2008 in Ubuntu – vereinfachte Oberfläche, darunter iptables/nftables.
• firewalld: Dynamisches Firewall-Management in Red-Hat-Ökosystemen – Regeln zur Laufzeit ohne Verbindungsabbruch.

Dieser Artikel konzentriert sich auf UFW und iptables – in der Praxis am verbreitetsten. nftables ist moderner, aber konzeptionell nah an iptables; wer iptables kann, wechselt leicht.

UFW: Firewall-Konfiguration ohne Kopfschmerzen

Warum UFW so beliebt ist

Wer iptables kennt, kennt die Vorsicht beim Regelschreiben – ein falscher Parameter, und SSH ist weg, Sie sitzen draußen.

UFW setzt auf Einfachheit. Ein Befehl öffnet einen Port – ohne -A INPUT -p tcp --dport 22 -j ACCEPT.

Vergleich:

iptables:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

UFW:

ufw allow ssh

Der Unterschied ist offensichtlich. UFW übernimmt Protokoll, Status-Tracking und IPv6 – Sie sagen nur: „SSH freigeben“.

Grundkonfiguration: Von null an

Auf einem neuen Server sollten Sie so vorgehen:

Schritt 1: Standardrichtlinien

Die Standardrichtlinie bestimmt, was passiert, wenn keine Regel passt. Sicherheitsbasis: alles Eingehende ablehnen, alles Ausgehende erlauben.

sudo ufw default deny incoming   # Alle eingehenden Verbindungen ablehnen
sudo ufw default allow outgoing   # Alle ausgehenden Verbindungen erlauben

Ohne explizite Freigabe kommt von außen nichts rein. Wer aus Bequemlichkeit auf allow als Standard setzt, lässt den Server wie ein offenes Haus – jeder kann reinschauen.

Schritt 2: Notwendige Ports freigeben

Wichtige Falle: Zuerst SSH freigeben, dann Firewall aktivieren! Sonst bricht die Remote-Verbindung sofort ab.

sudo ufw allow ssh        # SSH (Port 22)
sudo ufw allow 80/tcp     # HTTP
sudo ufw allow 443/tcp    # HTTPS

Bei SSH auf einem anderen Port (z. B. 2222):

sudo ufw allow 2222/tcp

Schritt 3: Firewall aktivieren

sudo ufw enable

Es erscheint eine Warnung: „This may disrupt existing ssh connections“ – kein Grund zur Panik, wenn Sie vorher allow ssh ausgeführt haben. Mit y bestätigen.

Schritt 4: Status prüfen

sudo ufw status verbose

Typische Ausgabe:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere

Status: active bedeutet: Die Firewall läuft.

Fortgeschritten: Konfiguration absichern

App Profiles

UFW bietet App Profiles – vordefinierte Profile für Nginx, Apache, OpenSSH und mehr.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Verfügbare Profile anzeigen:

sudo ufw app list

Beispielausgabe:

Available applications:
  Apache
  Apache Full
  Apache Secure
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH

Per App-Name freigeben:

sudo ufw allow 'Nginx Full'

Öffnet HTTP (80) und HTTPS (443) in einem Schritt.

Ratenbegrenzung: Schutz vor Brute-Force

SSH ist ein beliebtes Ziel für Brute-Force. UFW hat eingebaute Ratenbegrenzung:

sudo ufw limit ssh

Bedeutung: Versucht eine IP innerhalb von 30 Sekunden mehr als 6-mal zu verbinden, wird sie vorübergehend gesperrt – deutlich sicherer als allow ssh.

Zugriff auf bestimmte IPs beschränken

Manchmal soll nur eine IP einen Dienst erreichen – z. B. DB-Admin nur aus dem Firmennetz:

# Nur 192.168.1.100 darf MySQL erreichen
sudo ufw allow from 192.168.1.100 to any port 3306

# Bestimmte IP blockieren
sudo ufw deny from 203.0.113.100

Logging

Firewall-Logs sind zentral für die Fehlersuche:

sudo ufw logging on
sudo ufw logging medium   # Level: low/medium/high

Logs liegen in /var/log/ufw.log, z. B.:

Mar 15 10:23:45 server kernel: [UFW BLOCK] IN=eth0 OUT= MAC=... SRC=203.0.113.100 DST=... PROTO=TCP SPT=54321 DPT=22

[UFW BLOCK] bedeutet: Die Anfrage wurde blockiert.

Grenzen von UFW

UFW ist praktisch, hat aber Grenzen:

• NAT und Port-Weiterleitung: nur begrenzt – komplexe Setups brauchen iptables
• Komplexe Regelketten: keine benutzerdefinierten Chains oder verschachtelte Bedingungen
• Inhaltsfilterung: nicht möglich (z. B. bösartige HTTP-Payloads filtern)

Über diese Grenzen hinaus führt der Weg zu iptables.

iptables: Präzise Kontrolle

Architektur von iptables

iptables ist komplexer, aber logisch aufgebaut. Schlüssel: die Drei-Ebenen-Struktur Tabelle – Chain – Regel.

Tabellen (Tables)

Verschiedene Tabellen für verschiedene Aufgaben:

• filter (Standard): Paketfilter – annehmen oder verwerfen
• nat: Adressübersetzung (NAT) – Quell-/Zieladresse ändern
• mangle: TOS, TTL und andere Metadaten ändern
• raw: Ausnahmen, Connection Tracking umgehen

In den meisten Fällen reicht die filter-Tabelle.

Chains

Chains sind geordnete Regelsätze. Die filter-Tabelle hat fünf eingebaute Chains:

• INPUT: eingehende Pakete (Ziel ist der lokale Rechner)
• OUTPUT: ausgehende Pakete (Quelle ist der lokale Rechner)
• FORWARD: weitergeleitete Pakete (Rechner ist Relay)
• PREROUTING: vor dem Routing
• POSTROUTING: nach dem Routing

Alltag: vor allem INPUT und OUTPUT; FORWARD bei Router oder Gateway.

Regel-Reihenfolge

Regeln werden von oben nach unten geprüft – erstes Match gewinnt, der Rest wird übersprungen.

Beispiel:

iptables -A INPUT -s 192.168.1.100 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -j DROP

192.168.1.100 trifft die erste ACCEPT-Regel und wird durchgelassen. Kehren Sie die Reihenfolge um, trifft 192.168.1.100 zuerst DROP – die ACCEPT-Regel kommt nie zum Zug.

Kernprinzip: spezifische Regeln nach oben, allgemeine nach unten.

Syntax im Detail

Grundformat:

iptables -t tabellenname -A chainname matchbedingungen -j aktion

Häufige Parameter:

• -t: Tabelle (Standard filter, kann entfallen)
• -A: Regel ans Chain-Ende anhängen (Append)
• -I: Regel an Position einfügen (Insert)
• -D: Regel löschen (Delete)
• -L: Regeln auflisten (List)
• -F: alle Regeln leeren (Flush)
• -P: Standardrichtlinie setzen (Policy)

Match-Bedingungen

• -s: Quell-IP (z. B. -s 192.168.1.100)
• -d: Ziel-IP
• -p: Protokoll (tcp, udp, icmp)
• --sport: Quellport
• --dport: Zielport
• -i: eingehende Schnittstelle (z. B. -i eth0)
• -o: ausgehende Schnittstelle
• -m state --state: Connection-State-Tracking

Aktionen (Target)

• ACCEPT: Paket annehmen
• DROP: still verwerfen (keine Antwort)
• REJECT: ablehnen mit Fehlermeldung
• LOG: protokollieren (blockiert nicht, nächste Regel folgt)
• RETURN: aktuelle Chain verlassen, zur übergeordneten Chain zurück

Praxis: Sichere Server-Firewall

Vollständiger Ablauf für Produktion:

Schritt 1: Bestehende Regeln leeren

Neue Server haben oft Default-Regeln – zuerst aufräumen:

sudo iptables -F        # Alle Regeln leeren
sudo iptables -X        # Benutzerdefinierte Chains löschen
sudo iptables -t nat -F
sudo iptables -t mangle -F

Schritt 2: Standardrichtlinien

Wie bei UFW – eingehend standardmäßig ablehnen:

sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

Schritt 3: Etablierte Verbindungen erlauben

Besonders wichtig: Antwort-Traffic und bestehende Sessions durchlassen.

sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Wenn Sie eine Website aufrufen, geht die Anfrage über OUTPUT (Standard ACCEPT); die Antwort kommt über INPUT. Ohne diese Regel wird die Antwort gedroppt – Sie erhalten keine Daten.

ESTABLISHED: Verbindung steht; RELATED: verwandte Verbindung (z. B. FTP-Datenkanal).

Schritt 4: Notwendige Ports

# SSH
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# HTTP
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# HTTPS
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Schritt 5: ICMP einschränken (optional)

ICMP wird für ping genutzt. Manche Policies verbieten ping:

# Ping erlauben
sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Oder Ping verbieten
sudo iptables -A INPUT -p icmp -j DROP

Schritt 6: Logging

Vor DROP eine LOG-Regel erleichtert die Analyse:

sudo iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 4

--limit 5/min verhindert Log-Flut – maximal 5 Einträge pro Minute.

Schritt 7: Explizites DROP

Standard ist schon DROP – eine explizite Regel macht die Absicht klar:

sudo iptables -A INPUT -j DROP

Schritt 8: Regeln speichern

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

iptables-Regeln sind standardmäßig nicht persistent. Unter Ubuntu/Debian:

sudo apt install iptables-persistent
sudo netfilter-persistent save

Oder manuell:

sudo iptables-save > /etc/iptables/rules.v4
sudo ip6tables-save > /etc/iptables/rules.v6  # IPv6-Regeln

Regelstatus anzeigen

sudo iptables -L -n -v --line-numbers

• -n: numerische Ausgabe (schneller, ohne DNS)
• -v: verbose (Paketzähler)
• --line-numbers: Regelnummern

Beispielausgabe:

Chain INPUT (policy DROP 0 packets, 0 bytes)
num  pkts bytes target     prot opt in     out     source               destination
1      42  2848 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state ESTABLISHED,RELATED
2       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
3       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
4       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
5       0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 5/min burst 5 LOG flags 0 level 4 prefix "iptables denied: "
6       0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

UFW oder iptables: Was wählen?

Kernunterschied: Bedienbarkeit vs. Flexibilität

Performance: die Wahrheit

Viele glauben, iptables sei schneller – falsch. Beide nutzen Netfilter im Kernel. Der einzige Faktor ist die Regelmenge; für kleine und mittlere Server irrelevant.

Empfehlungen

UFW empfohlen bei:

• VPS, Cloud, Dedicated Server
• Web- und API-Deployments
• Kein komplexes Netz (kein NAT, keine Port-Weiterleitung)
• Kein iptables-Syntax-Interesse
• Schnelle Absicherung (z. B. nach Angriff)

iptables empfohlen bei:

• Gateway, Router, VPN-Server
• NAT, Port-Weiterleitung, Load Balancing
• Komplexen Regelketten und Bedingungen
• Großflächigem Rollout (Dutzende Server per Skript)
• Erweitertem Filtern (Inhalt, Rate, Zeit)
• Dediziertem Netzwerk-Team

Mischbetrieb?

Nicht empfohlen. Beide schreiben in dieselben Netfilter-Regeln – Konflikte sind vorprogrammiert.

Beispiel: SSH per iptables frei, später per UFW blockiert – letzte Regel gewinnt, Sie sind draußen.

Falls nötig: UFW-Regeln liegen zwischen before.rules und after.rules; direkt per iptables hinzugefügte Regeln können von UFW-Defaults überschrieben werden.

Kernprinzipien der Firewall-Sicherheitsstrategie

Tool-Know-how ist Schritt eins – wichtiger ist eine durchdachte Strategie. Viele werfen Regeln dazu und hinterlassen Lücken.

Prinzip 1: Default Deny

Grundstein jeder sicheren Konfiguration.

Kernidee: Alles ablehnen, außer explizit erlaubt.

Gegenbeispiel „Default Allow“ – alles offen, dann Risiken schließen. Probleme:

1. Sie kennen nicht alle Risikoports (Angreifer scannen alle 65.535)
2. Ein vergessener Port = Angriffsfläche

Richtig:

# UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing

# iptables
sudo iptables -P INPUT DROP
sudo iptables -P OUTPUT ACCEPT

Dann nur geschäftlich nötige Ports. Pro Port fragen: Wofür? Kann die Quell-IP eingeschränkt werden?

Prinzip 2: Least Privilege

Jede Regel soll eine Sache tun, so eng wie möglich.

Port-Freigabe:

• ❌ ufw allow 3306 (MySQL weltweit)
• ✅ ufw allow from 192.168.1.100 to any port 3306 (nur eine IP)

Dienstzugriff:

• ❌ Alle internen Ports nach außen
• ✅ Nur öffentliche Dienste (Web, API); Internes über LAN oder VPN

SSH:

• ❌ ufw allow ssh (jeder darf versuchen)
• ✅ ufw allow from Firmen-IP to any port 22 + ufw limit ssh

Prinzip 3: Defense in Depth

Die Firewall ist nicht alles – nur die erste Schicht. Vollständige Sicherheit ist mehrschichtig:

1. Netzwerk-Firewall (UFW/iptables): bösartigen Traffic blockieren
2. Application Firewall (WAF): SQL-Injection, XSS auf HTTP-Ebene
3. Host-Härtung (SELinux/AppArmor): Prozessrechte begrenzen
4. Intrusion Detection (IDS/IPS): Anomalien live erkennen
5. Regelmäßige Audits: Log-Analyse, Schwachstellen-Scans

Beispiel: Port 80 ist offen – WAF prüft HTTP-Payloads, SELinux begrenzt Dateizugriff des Webservers. Erst nach drei Schichten erreicht der Angreifer die Anwendung – dort gelten Input-Validierung und Berechtigungen.

Prinzip 4: Network Segmentation

Große Netze nicht als Einheit – Zonen bilden.

Typisches Modell:

• DMZ: öffentliche Dienste (Web, Mail)
• Internes Netz: Datenbank, interne Services, Büro
• Management: Ops, Monitoring, Logs

Vorteile:

1. Fehlerisolierung: DMZ kompromittiert – noch eine Hürde bis ins Interne
2. Ausbreitung begrenzen: Würmer in einer Zone, Firewall stoppt Quertraffic
3. Feinere Rechte: unterschiedliche Zonen, unterschiedliche Policies

Bei iptables ist die FORWARD-Chain zentral:

# DMZ → Intern: nur DB-Zugriff
iptables -A FORWARD -s dmz_network -d internal_network -p tcp --dport 3306 -j ACCEPT
iptables -A FORWARD -s dmz_network -d internal_network -j DROP

Prinzip 5: Regelmäßige Audits und Updates

Firewall-Konfiguration ist kein Einmal-Projekt.

Regel-Review:

• Monatlich: veraltete Regeln? (Test-Ports vergessen?)
• Quartalsweise: passt die Port-Freigabe zur aktuellen Architektur?
• Jährlich: Redundanz entfernen, Performance optimieren

Log-Analyse:

• Wöchentlich: welche IPs blockiert, warum?
• Schwellwert-Alarme bei Anomalien
• Angriffsherkunft aus Logs – gezielt härten

Reaktion auf Änderungen:

• Neuer Dienst: Risiko bewerten, dann Port öffnen
• Vorfall: Regeln anpassen, IPs sperren, Rate-Limits verschärfen
• Architektur-Wechsel: unnötige Regeln löschen, Angriffsfläche verkleinern

Produktion: Konfiguration ohne Fallstricke

Sicherer Konfigurationsablauf

Schritt 1: In der Testumgebung validieren

Neue Regeln nie blind in Produktion. Erst Test-VM oder Dev – dann Rollout.

Schritt 2: SSH-Rückweg sichern

Vor Änderungen prüfen, ob SSH erreichbar ist. Bei Custom-Port:

# UFW
ufw allow 2222/tcp  # Benutzerdefinierter SSH-Port

# iptables
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT

Schritt 3: Ports schrittweise öffnen

Nicht alles auf einmal. Erst SSH, Login testen, dann Web, dann Rest.

Schritt 4: Änderungen dokumentieren

Jede Regeländerung festhalten:

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

• Zeitpunkt
• Inhalt
• Grund
• Verifikationsergebnis

Regel-Dateien in Git oder in einem Runbook.

Häufige Fehler und Lösungen

Fehler 1: SSH-Aussperrung

Symptom: Nach Firewall-Aktivierung bricht SSH ab, kein Re-Login.

Ursache: SSH nicht freigegeben oder falsche Reihenfolge (DROP vor ACCEPT).

Prävention:

1. Aktuellen SSH-Port vorher prüfen
2. Erst ufw allow ssh, dann ufw enable
3. Bei iptables: SSH-Regel vor DROP

Notfall:

• VPS: Provider-Konsole (ohne SSH)
• Cloud: Recovery Mode / Rescue System
• Physisch: lokale Konsole

Fehler 2: Falsche Regelreihenfolge

Symptom: Port hat ACCEPT-Regel, Verbindung scheitert trotzdem.

Ursache: Frühere DROP-Regel matcht zuerst.

Diagnose:

iptables -L -n -v --line-numbers

Nummern prüfen – ACCEPT vor DROP?

Lösung:

# Falsche Regel entfernen
iptables -D INPUT 3

# An richtiger Position einfügen
iptables -I INPUT 2 -p tcp --dport 80 -j ACCEPT

Fehler 3: Keine Persistenz

Symptom: Nach Neustart alle Regeln weg.

Ursache: iptables-Regeln nur im RAM.

Lösung:

# Ubuntu/Debian
sudo apt install iptables-persistent
sudo netfilter-persistent save

# CentOS/RHEL
sudo service iptables save

UFW ist standardmäßig persistent.

Fehler 4: IPv6 vergessen

Symptom: IPv4 ok, IPv6 nicht erreichbar.

Ursache: iptables nur für IPv4; IPv6 braucht ip6tables.

Lösung:

# IPv6-Regeln (analog IPv4)
sudo ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT

# Speichern
sudo ip6tables-save > /etc/iptables/rules.v6

UFW behandelt IPv6 automatisch.

Troubleshooting

Bei Firewall-Problemen in dieser Reihenfolge:

1. Firewall-Status

# UFW
sudo ufw status verbose

# iptables
sudo iptables -L -n -v

Aktiv? Regeln plausibel?

2. Port-Erreichbarkeit

# Von außen
telnet server_ip 22
nc -zv server_ip 80

# Lokal
sudo netstat -tulnp | grep :22

3. Firewall-Logs

# UFW
tail -f /var/log/ufw.log

# iptables
tail -f /var/log/kern.log | grep "iptables"

Blockierte Requests sichtbar?

4. Temporär deaktivieren

# UFW
sudo ufw disable

# iptables
sudo iptables -F

Connectivity testen – Firewall oder Dienst?

Achtung: Deaktiviert ist der Server voll exponiert – nach der Diagnose sofort wieder aktivieren!

Fazit: Ihr Firewall-Sicherheitssystem

Tool-Wahl

• Einfache Szenarien: UFW reicht – in Minuten einsatzbereit
• Komplexe Szenarien: iptables flexibler für Gateway, NAT, erweitertes Filtern
• Nicht mischen: ein Tool, eine Regelquelle

Konfigurationsprinzipien

• Default Deny: eingehend ablehnen, nur Nötiges öffnen
• Least Privilege: enge Regeln, Quell-IP einschränken
• Defense in Depth: Firewall plus WAF, SELinux und mehr
• Segmentierung: DMZ, Internes, Management trennen
• Regelmäßige Audits: monatlich, quartalsweise, jährlich

Praxis-Checkliste

• SSH zuerst: vor Aktivierung sicherstellen
• Reihenfolge: bei iptables spezifisch vor allgemein
• Persistenz: iptables-Regeln speichern
• IPv6: ip6tables separat oder UFW nutzen
• Test zuerst: nie ungetestet in Produktion
• Logging: aktivieren und auswerten

Weiterführend

Vertiefung Firewall und Server-Sicherheit:

• nftables: moderner iptables-Nachfolger, einheitlichere Syntax
• firewalld: dynamisches Management, Laufzeit-Änderungen
• WAF: Nginx ModSecurity, Cloudflare WAF
• Intrusion Detection: Fail2ban, OSSEC
• SELinux/AppArmor: Host-Rechte

Firewall-Konfiguration ist Server-Sicherheit von Grund auf. UFW und iptables beherrschen, Strategie verstehen – dann ist Ihr Server kein offenes Haus mehr. Alarm-SMS um drei Uhr morgens werden seltener.

Referenzen

• UFW Essentials: Common Firewall Rules and Commands - DigitalOcean
• UFW vs iptables: Simple Firewall Rules That Actually Work - WeHaveServers
• Difference Between ufw vs. nftables vs. iptables - Baeldung on Linux
• Firewall Design Principles In Network Security - Fortinet
• Linux Firewall: Configuration, Tools, Best Practices - TuxCare
• Ubuntu Community Help Wiki - UFW