Firewall

1 🛡️ FIREWALL (Der Schutzschild für das Linux-System)

1.1 🔬 DIE FUNKTIONSWEISE: WIE ARBEITET EINE LINUX-FIREWALL?

Unter Linux ist eine Firewall keine eigenständige, schwere Software, die im Hintergrund läuft, sondern ein tief im Linux-Kernel verankertes Subsystem namens Netfilter. Dieses System fängt jedes Datenpaket ab, das die Netzwerkkarte erreicht oder verlässt, und entscheidet in Lichtgeschwindigkeit anhand von Tabellen und Regeln über das Schicksal des Pakets: Erlauben (ACCEPT), Verwerfen (DROP) oder Ablehnen mit Rückmeldung (REJECT).

Da die direkte Konfiguration von Netfilter extrem komplex ist, nutzen wir unter Linux sogenannte Frontends (Bedienoberflächen), um die Regeln zu schreiben. Hier gab es über die Jahre einen Generationenwechsel:

1. Die Oldschool-Generation (iptables):
   Jahrzehntelang der Standard. Regeln waren starr, oft unübersichtlich und bei tausenden Einträgen ging die Performance in die Knie.
2. Die moderne Generation (nftables):
   Der offizielle Nachfolger im Kernel. Es nutzt eine viel schnellere, VM-basierte Struktur und eine sauberere Syntax.
3. Die Komfort-Frontends (UFW / Firewalld):
   Da niemand im Alltag komplexe Kernel-Regeln tippen möchte, gibt es leicht verständliche Wächter-Dienste, die die Befehle für uns übersetzen.

1.2 🛠️ WORKFLOW IM TERMINAL: DIE ZWEI WICHTIGSTEN FIREWALL-DIENSTE

Je nachdem, welche Distribution du nutzt, kommt ein anderes Komfort-Werkzeug zum Einsatz. Ein Systemneustart ist nach Regeländerungen nie nötig – die Firewall lädt die Regeln im laufenden Betrieb live neu.

1.2.1 Variante A: UFW (Uncomplicated Firewall) – Standard bei Ubuntu / Debian / Mint

UFW ist extrem minimalistisch und perfekt für Einzelplatzrechner oder kleine Server.

Den Status und alle aktiven Regeln anzeigen:

sudo ufw status verbose

Die Firewall aktivieren (Achtung: Blockiert standardmäßig alle eingehenden Verbindungen!):

sudo ufw enable

Einen bestimmten Port (z. B. Port 22 für SSH) für das lokale Netz freigeben:

sudo ufw allow 22/tcp
sudo ufw allow http
sudo ufw allow https

oder:

sudo ufw allow "WWW Full"

1.2.2 Variante B: Firewalld – Standard bei Fedora / RHEL / openSUSE

Firewalld arbeitet mit dynamischen "Zonen" (z. B. public, home, work), je nachdem, wie vertrauenswürdig das Netzwerk gerade ist.

Den aktuellen Status und die aktive Zone abfragen:

sudo firewall-cmd --state

Einen Dienst (z. B. den Webserver auf Port 80/443) dauerhaft in der Standardzone erlauben:

sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https

Die Konfiguration live neu laden, damit Änderungen aktiv werden:

sudo firewall-cmd --reload

1.3 ⚠️ DIE KLASSISCHEN STOLPERSTEINE: DIE SSH-AUSSPERR-FALLE UND REBOOT-VERLUSTE

In den Foren sind Threads zur Firewall meistens von Panik geprägt, weil sich Nutzer komplett von ihren eigenen Systemen isoliert haben.

Die SSH-Aussperr-Falle bei Servern:
Ein Nutzer mietet einen Linux-Server im Rechenzentrum oder setzt einen kopflosen (headless) Raspberry Pi auf. Er tippt voller Elan sudo ufw enable. Im selben Moment bricht die Verbindung ab und der Server ist nie wieder erreichbar.

Der Grund:
UFW blockiert nach dem Einschalten jeden eingehenden Verkehr. Wenn man SSH nicht vorher explizit erlaubt, sperrt man sich selbst unwiderruflich aus.

Die Lösung:
Die goldene Regel lautet:
Erst die Erlaubnis, dann die Aktivierung!
Bevor eine Firewall scharf geschaltet wird, muss vorher immer der Zugangskanal geöffnet werden:

sudo ufw allow ssh && sudo ufw enable

Sitzt man bereits in der Falle, hilft meist nur der Weg über die serielle Web-Konsole des Server-Anbieters, um die Firewall dort mit sudo ufw disable wieder abzuschalten.

Die Vergesslichkeits-Falle bei manuellen iptables/nftables-Regeln:
Ein Nutzer schreibt mühsam Regeln über das Terminal in die Tabellen. Nach dem nächsten System-Neustart (Reboot) ist die Firewall jedoch wieder komplett leer und ungeschützt.

Der Grund: Direkte Kernel-Befehle sind flüchtig und werden nur im RAM gehalten.

Die Lösung:
Wer Komfort-Tools wie UFW oder Firewalld nutzt, hat das Problem nicht, da diese die Regeln automatisch dauerhaft im System speichern. Wer jedoch direkt mit den nackten Befehlen von iptables oder nftables arbeitet, muss dem System explizit sagen, dass es die Regeln beim Booten laden soll. Im Forum hilft je nach Distribution der exakte Pfad:

• Unter Debian / Ubuntu / Linux Mint:
  Hier hilft das Nachinstallieren von persistenten Speicher-Skripten, die die Regeln automatisch beim Herunterfahren sichern und beim Starten laden:

  Code

  sudo apt install iptables-persistent

• Unter Arch Linux / Manjaro:
  Hier müssen die aktuell aktiven Regeln manuell in den Standard-Pfad des Kernels exportiert und danach der Systemd-Dienst aktiviert werden:

  Code

  sudo iptables-save -f /etc/iptables/iptables.rules
  sudo systemctl enable --now iptables

• Unter Fedora:
  Fedora setzt voll auf nftables. Wer hier dennoch manuell mit alten iptables-Regeln arbeitet, muss zuerst das persistente Paket nachinstallieren und den Dienst scharfschalten:

  Code

  sudo dnf install iptables-services
  sudo systemctl enable --now iptables

• Unter openSUSE (Tumbleweed / Leap):
  openSUSE nutzt standardmäßig Firewalld als Backend. Wer hier manuelle Regeln über das Terminal einschleust, ohne das firewall-cmd Frontend zu nutzen, muss die Konfiguration über das mächtige openSUSE-Kontrollzentrum YaST (Modul yast2 firewall) permanent abspeichern oder die Regeln direkt in die Konfigurationsdatei unter /etc/sysconfig/SuSEfirewall2 (bei älteren Versionen) bzw. direkt in die Struktur von Firewalld eintragen, da openSUSE rohe iptables-Befehle beim nächsten Systemstart über den Sicherheitsdienst sofort wieder überschreibt.