# Firewalls Deep Dive: Stateful vs. Stateless Inspection

TL;DR / Management Summary Eine Firewall entscheidet über Leben und Tod von Datenpaketen. Während die veraltete Stateless Firewall jedes Paket isoliert prüft (und hunderte Regeln für Hin- und Rückweg braucht), “merkt” sich die Stateful Firewall (wie OPNsense oder Proxmox Firewall) aktive Verbindungen in einer State Table. Ein Senior Admin nutzt Stateful Inspection für maximale Sicherheit bei minimalem Konfigurationsaufwand, da Antworten auf erlaubte Anfragen automatisch passieren dürfen.

# 1. Stateless Firewalls (Packet Filter)

Die blinden Torwächter.

Arbeiten rein regelbasiert auf Layer 3 und 4.

• Logik: Paket kommt an -> Firewall prüft: Ist IP/Port in der Liste? -> Ja/Nein.
• Problem: Sie “weiß” nicht, ob ein Paket eine Antwort auf eine interne Anfrage ist. Sie müssen für jeden Dienst zwei Regeln schreiben (Inbound und Outbound).
• Vorteil: Extrem schnell, fast keine CPU-Last.
• Heutige Nutzung: ACLs auf physischen Core-Switchen (Artikel 731).

# 2. Stateful Firewalls (Modern Standard)

Das Gedächtnis des Netzwerks.

Arbeiten mit einer internen Zustandsdatenbank (State Table).

• Vorgang:
  1. User schickt SYN (Verbindungsaufbau) ins Internet.
  2. Firewall prüft Regel -> Pass.
  3. Firewall erstellt einen State (“User X spricht gerade mit Server Y auf Port 443”).
  4. Antwort kommt zurück: Firewall sieht den State und lässt das Paket durch, ohne die Regeln erneut zu prüfen.
• Vorteil: Deutlich sicherer gegen Angriffe mit gefälschten Antwort-Paketen.

# 3. Deep Dive: Deep Packet Inspection (DPI)

Der Röntgenblick.

Moderne Firewalls gehen über die Ports hinaus.

• Technik: Die Firewall schaut in den Payload (Layer 7).
• Nutzen: Erkennt, ob auf Port 80 wirklich HTTP-Webtraffic fließt oder ein getarnter VPN-Tunnel (Malware-C2).
• Hardware: Erfordert deutlich stärkere CPUs (z.B. in der OPNsense, Artikel 541).

# 4. Day-2 Operations: State-Tabelle bändigen

Ressourcen am Gateway.

Jede aktive Verbindung belegt RAM in der Firewall.

• Limit: Standardmäßig ca. 10.000 bis 1.000.000 States.
• Timeout: Wie lange darf ein inaktiver State im Speicher bleiben? (Standard bei TCP: 24h).
• Aktion: Senken Sie Timeouts für unvollständige Verbindungen, um sich gegen State Exhaustion Angriffe (DoS) zu schützen.

# 5. Troubleshooting & “War Stories”

Wenn der Zustand zum Problem wird.

# Top 3 Fehlerbilder

1. Symptom: “Connection Reset by Peer” bei asymmetrischem Routing.

   • Ursache: Das Hin-Paket geht über Firewall A (State erstellt), das Rück-Paket kommt über Firewall B an. Da B den State nicht kennt, droppt sie das Paket als “invalid”.
   • Lösung: Routing korrigieren oder “Sloppy State” (Stateless-Mode für diese Regel) nutzen.

2. Symptom: Firewall ist extrem langsam nach Regel-Änderung.

   • Ursache: Tausende veraltete States halten die alten Regeln im RAM “am Leben”.
   • Fix: Firewall -> Diagnostics -> States -> Reset State Table.

3. Symptom: Out-of-Memory am Gateway.

   • Lösung: Maximum States Limit unter System -> Settings -> Advanced prüfen.

# “War Story”: Der “Zombie” Tunnel

Ein Admin löschte die Firewall-Regel für einen internen Server, der massiv Traffic nach außen schickte. Das Ergebnis: Der Server schickte munter weiter Daten. Der Admin war ratlos. Die Ursache: Da der Server den Traffic bereits vor der Löschung der Regel gestartet hatte, hielt die Firewall den State offen. Solange der Server permanent sendete, wurde der Timeout nie erreicht. Lehre: Das Löschen einer Regel stoppt nur neue Verbindungen. Um laufende Sitzungen zu töten, müssen Sie zusätzlich den Eintrag in der State-Tabelle manuell löschen (Artikel 587).

# 6. Monitoring & Reporting

Status der Wächter.

# Dashboard Check

Überwachen Sie die Auslastung der State-Tabelle:

• KPI: Current States / Max States.
• KPI: States created per second. (Suche nach Brute-Force Mustern).

# 7. Fazit & Empfehlung

Stateful Inspection ist das Rückgrat moderner IT-Sicherheit.

• Empfehlung: Nutzen Sie Stateful Firewalls (OPNsense/PF) für alle Übergänge zwischen Zonen.
• Wichtig: Verwenden Sie Stateless ACLs nur dort, wo extreme Performance nötig ist (z.B. Core-Switche), und nur für grobe Filterung.

# Anhang: Vergleichstabelle

# Referenzen

• OpenBSD: Packet Filter (pf) Concepts
• Netfilter Project: Connection Tracking
• SANS: Stateful Inspection Firewall Whitepaper