iptables Firewall: Leitfaden für Linux-Server

Wenn du einen Gameserver, eine Webanwendung oder einen Discord-Bot betreibst, wird deine Maschine ab dem Moment gescannt, in dem du sie ans Internet hängst. Eine iptables Firewall lässt dich genau bestimmen, welcher Verkehr hinein- und hinausgeht, indem sie die im Linux-Kernel eingebaute Paketfilter-Schicht (Netfilter) steuert: Du öffnest nur die Ports, die du brauchst, und weist alles andere stillschweigend ab. In dieser Anleitung bauen wir Schritt für Schritt ein sicheres Regelwerk von Grund auf, schreiben Portregeln und filtern die häufigsten Angriffe.

Wie iptables funktioniert: Chains und Tables

iptables ordnet Regeln in Tables (Tabellen) und Chains (Ketten). Für die tägliche Firewall-Arbeit reichen die filter-Tabelle und drei Chains:

• INPUT — Pakete, die am Server ankommen (hier sitzt unser Schutz).
• OUTPUT — Pakete, die den Server verlassen.
• FORWARD — Pakete, die über den Server an ein anderes Ziel geroutet werden (Router-/Docker-Szenarien).

Jedes Paket durchläuft die Chain von oben nach unten; das Target der ersten passenden Regel gewinnt: ACCEPT (erlauben), DROP (stillschweigend verwerfen) oder REJECT (ablehnen und Fehler zurückgeben). Passt nichts, greift die Standardrichtlinie der Chain. Das Grundprinzip einer soliden Firewall: Setze die Policy auf DROP und öffne dann nur das, was du ausdrücklich erlaubst.

Sperr dich nicht selbst aus: Die Reihenfolge zählt

Der häufigste Fehler ist, die Policy auf DROP zu setzen, bevor die SSH-Regel hinzugefügt wurde — das kappt deine Remote-Sitzung. Also schreibe zuerst die Erlauben-Regeln und verschärfe die Policy zuletzt. Gib außerdem Loopback und bestehende Verbindungen ganz oben frei:

# Bereits aufgebaute Verbindungen weiterlaufen lassen
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Loopback-Verkehr (127.0.0.1) niemals blockieren
iptables -A INPUT -i lo -j ACCEPT

# Fehlerhafte / ungültige Pakete verwerfen
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

Diese erste Regel ist entscheidend: Dank des conntrack-Moduls passieren Antwortpakete für Verbindungen, die der Server selbst gestartet hat oder die bereits bestehen, automatisch — so brauchst du keine getrennten Regeln auf der OUTPUT-Seite.

Portregeln: nur öffnen, was du brauchst

Jetzt fügen wir Portregeln pro Dienst hinzu. Ein typisches Setup: SSH (22), HTTP (80), HTTPS (443) und ein Gameserver-Port. -p legt das Protokoll fest, --dport den Zielport:

# SSH (zuerst hinzufügen, dann abriegeln!)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Web
iptables -A INPUT -p tcp --dport 80  -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Beispiel-Gameserver (z. B. Metin2 TCP 13000)
iptables -A INPUT -p tcp --dport 13000 -j ACCEPT

Um mehrere Ports in einer Zeile zu öffnen, nutzt du das multiport-Modul:

iptables -A INPUT -p tcp -m multiport --dport 80,443,13000 -j ACCEPT

Einen Port nur für eine bestimmte IP zu öffnen (etwa SSH nur von deiner festen IP) ist deutlich sicherer:

iptables -A INPUT -p tcp -s 203.0.113.10 --dport 22 -j ACCEPT

Sobald alle Erlauben-Regeln geschrieben sind, verschärfst du die Standardrichtlinien:

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

Einfache Angriffe filtern

Ein offener Server wird ständig mit Portscans, Brute-Force und gefälschten Paketen konfrontiert. Ein paar gezielte Regeln verwerfen oder bremsen die meisten davon.

SSH-Brute-Force ausbremsen: Mit dem recent-Modul blockierst du vorübergehend jede IP, die mehr als 4 neue SSH-Verbindungen in 60 Sekunden versucht:

iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
  -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW \
  -m recent --update --seconds 60 --hitcount 5 --name SSH -j DROP

Portscans / ungültige Flags: TCP-Pakete ohne Flags (NULL) oder mit unsinnigen Flag-Kombinationen stammen meist von einem Scan-Tool:

# NULL-Pakete
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
# XMAS-Scan
iptables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP
# Neue Verbindungen, die kein SYN sind
iptables -A INPUT -p tcp ! --syn -m conntrack --ctstate NEW -j DROP

ICMP (Ping) drosseln: Statt Ping ganz abzuschalten, hält das Begrenzen der Anfragen pro Sekunde die Diagnose nutzbar und stoppt zugleich Floods:

iptables -A INPUT -p icmp --icmp-type echo-request \
  -m limit --limit 1/second -j ACCEPT

Denk daran: iptables allein stoppt kein echtes DDoS (eine gesättigte Leitung liegt jenseits des Kernels), aber es reduziert Scanning auf Anwendungsebene und Rauschen erheblich.

Regeln dauerhaft machen

iptables-Regeln liegen im Speicher und gehen beim Neustart verloren. Unter Debian/Ubuntu speichert das Paket iptables-persistent sie und stellt sie beim Booten wieder her:

sudo apt install iptables-persistent
sudo netfilter-persistent save        # /etc/iptables/rules.v4

Du kannst auch manuell speichern und wiederherstellen:

iptables-save  > /etc/iptables/rules.v4
iptables-restore < /etc/iptables/rules.v4

Um Regeln mit Zeilennummern anzuzeigen und zu löschen:

iptables -L INPUT -n -v --line-numbers
iptables -D INPUT 3        # Regel Nummer 3 löschen

Ein Hinweis zu nftables und UFW

Auf modernen Distributionen wird der iptables-Befehl im Hintergrund meist an nftables weitergeleitet (iptables-nft). Die Befehlssyntax bleibt gleich, daher funktioniert alles in dieser Anleitung. Für neue Projekte ist es sinnvoll, direkt nft zu lernen, doch unzählige bestehende Docs und Skripte basieren weiterhin auf iptables. Willst du eine einfachere Oberfläche, kapselt UFW (Uncomplicated Firewall) iptables: Einzeiler wie ufw allow 443/tcp erledigen dieselbe Arbeit. Um aber wirklich zu verstehen, was passiert, ist iptables-Grundwissen unbezahlbar.

Häufige Fragen

Sollte ich DROP oder REJECT verwenden?

DROP verwirft das Paket stillschweigend; der Absender kann nicht erkennen, ob der Port offen, geschlossen oder per Firewall geschützt ist, was Scanner verlangsamt. REJECT sendet eine "connection refused"-Meldung zurück und gibt schnelleres Feedback. Auf einer internetzugewandten INPUT-Chain wird meist DROP bevorzugt; in einem internen Netz ist REJECT für schnelle Fehler praktischer.

Warum ist die Reihenfolge der Regeln so wichtig?

Weil iptables bei der ersten passenden Regel stoppt. Setzt du oben ein breites DROP, werden die ACCEPT-Regeln darunter nie ausgeführt. Setze enge/spezifische Erlaubnisse stets nach oben und allgemeine Verbote/die Policy nach unten.

Brauche ich separate Regeln für IPv6?

Ja. iptables verwaltet nur IPv4; IPv6-Verkehr wird separat mit ip6tables konfiguriert. Hat dein Server IPv6, ist es eine große Lücke, ihn ungefiltert zu lassen — schreibe daher mit derselben Logik passende ip6tables-Regeln.

Willst du deinen Server sicher und robust konfiguriert haben? Wenn du Hilfe bei Firewall, Hardening und Deployment für einen Gameserver, VPS oder eine Web-Infrastruktur brauchst, melde dich bei mir.