# Netfilter Architecture: Packet Processing Deep Dive

TL;DR / Management Summary Netfilter ist das Herzstück der Netzwerkverarbeitung im Linux-Kernel. Es bietet die Hooks, an denen Tools wie iptables, nftables und conntrack ansetzen. Wer High-Performance-Networking oder komplexe Firewalls betreibt, muss den Weg eines Pakets durch die Chains (PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING) verstehen. Die moderne Ablösung nftables optimiert diesen Prozess durch eine virtuelle Maschine im Kernel-Space, was den Overhead massiv reduziert.

# 1. Einführung & Architektur

Wie Pakete im Kernel ‘atmen’.

Netfilter ist kein einzelnes Tool, sondern ein Framework aus Kernel-Hooks. Jedes Mal, wenn ein Netzwerkpaket die Netzwerkkarte (NIC) erreicht oder verlässt, durchläuft es eine vordefinierte Reise.

# Warum Deep Dive?

Admins, die nur iptables -A INPUT -j ACCEPT kopieren, scheitern, wenn:

# Das Hook-System

Es gibt 5 fundamentale Hooks im Kernel:

  1. NF_IP_PRE_ROUTING: Bevor die Routing-Entscheidung getroffen wird.
  2. NF_IP_LOCAL_IN: Wenn das Paket für den lokalen Host bestimmt ist.
  3. NF_IP_FORWARD: Wenn das Paket an ein anderes Interface weitergeleitet wird.
  4. NF_IP_LOCAL_OUT: Für lokal generierte Pakete.
  5. NF_IP_POST_ROUTING: Nach der Routing-Entscheidung, kurz vor dem Verlassen des Systems.

# Architektur-Diagramm (Mermaid)

graph TD
    NIC_IN[Network Interface IN] --> PRE[PREROUTING Hook]
    PRE --> ROUTE{Routing Decision}
    ROUTE -->|Local Destination| IN[INPUT Hook]
    ROUTE -->|Foreign Destination| FWD[FORWARD Hook]
    IN --> APP[Local Process / App]
    APP --> OUT[OUTPUT Hook]
    FWD --> POST[POSTROUTING Hook]
    OUT --> ROUTE_OUT{Routing Decision}
    ROUTE_OUT --> POST
    POST --> NIC_OUT[Network Interface OUT]

    subgraph "Netfilter Kernel Hooks"
    PRE
    IN
    FWD
    OUT
    POST
    end

# 2. Der Weg des Pakets: Schritt für Schritt

Vom Bit zum Byte zur Applikation.

# Ingres & Prerouting

Sobald ein Paket den Treiber verlässt, erreicht es den PREROUTING Hook. Hier findet primär DNAT (Destination NAT) statt. Wenn Sie einen Load Balancer bauen, ist dies der Ort, an dem die Ziel-IP geändert wird, noch bevor der Kernel weiß, wohin das Paket eigentlich soll.

# Die Routing-Entscheidung

Hier prüft der Stack die Routing-Tabelle.

# Forwarding vs. Local Input

In der FORWARD Chain setzen wir Firewall-Regeln für Transit-Traffic (z.B. Proxmox Host fungiert als Router für VMs). In der INPUT Chain schützen wir den Host selbst (SSH, API-Ports).

# 3. Deep Dive: nftables vs. iptables

Die Evolution der Paketverarbeitung.

# Das Problem mit iptables

Iptables ist linear. Wenn Sie 1000 Regeln haben, muss ein Paket im schlimmsten Fall 1000 Vergleiche durchlaufen. Zudem gibt es Code-Duplizierung zwischen IPv4 (iptables) und IPv6 (ip6tables).

# Die Lösung: nftables

Nftables nutzt eine Netlink-Schnittstelle und eine kleine Virtual Machine (VM) im Kernel.

# Beispiel: Effizientes Blocken

# nftables Syntax: Nutzt ein Set für High Performance
nft add set inet filter blackhole { type ipv4_addr \; flags interval \; }
nft add element inet filter blackhole { 192.168.1.0/24, 10.0.0.5 }
nft add rule inet filter input ip saddr @blackhole drop

# 4. Day-2 Operations: State Management

Conntrack – Das Gedächtnis des Kernels.

Ohne conntrack wäre Linux eine “Stateless Firewall”. Wir müssten jedes Antwort-Paket explizit erlauben.

# Conntrack Tabelle einsehen

# Zeigt alle aktuell verfolgten Verbindungen
conntrack -L

# Überwachung von State-Änderungen in Echtzeit
conntrack -E

# Problem: Table Full

Auf High-Traffic Systemen (DDoS oder viele Microservices) läuft die conntrack-Tabelle oft voll. Symptom: nf_conntrack: table full, dropping packet. Lösung:

# Limit erhöhen (Laufzeit)
sysctl -w net.netfilter.nf_conntrack_max=262144
# Hashsize anpassen (erfordert oft Modul-Reload oder speziellen Parameter)
echo 65536 > /sys/module/nf_conntrack/parameters/hashsize

# 5. Troubleshooting & “War Stories”

Wenn die Firewall zum Kerker wird.

# Top 3 Fehlerbilder

  1. Symptom: Ping geht, aber TCP-Verbindungen hängen nach dem Handshake.

    • Ursache: MTU-Probleme oder falsche MSS-Clamping Regeln im POSTROUTING.
    • Lösung: nft add rule inet filter forward tcp flags syn tcp option maxseg size set rt mtu.

  2. Symptom: Lokale Dienste sind von außen nicht erreichbar, obwohl INPUT offen ist.

    • Analyse: Prüfen, ob das Paket im PREROUTING durch ein fehlerhaftes NAT umgeleitet wird.
    • Tool: nft monitor oder das alte iptables -t raw -A PREROUTING -p tcp --dport 80 -j TRACE.

  3. Symptom: Massive CPU-Last durch ksoftirqd.

    • Ursache: Zu viele Firewall-Regeln ohne Sets/Maps.
    • Lösung: Migration auf nftables Verzeichnisse (dictionaries).

# “War Story”: Der Geister-Drop

Wir hatten ein System, bei dem Pakete sporadisch verloren gingen. tcpdump am Interface zeigte die Pakete an, aber die Applikation sah sie nie. Die Firewall-Logs waren leer. Die Entdeckung: Ein RP-Filter (Reverse Path Filtering) im Kernel verwarf die Pakete, weil die Antwort über ein anderes Interface hätte gehen müssen (Asymmetrisches Routing). Netfilter Hooks sind oft unschuldig, aber die Basis für die Diagnose.

# 6. Monitoring & Alerting

Die Firewall im Blick behalten.

# Wichtige Metriken (KPIs)

# Alerting Regel (Prometheus)

- alert: FirewallTableFillingUp
  expr: (node_nf_conntrack_entries / node_nf_conntrack_entries_limit) > 0.85
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Conntrack Tabelle zu 85% voll auf {{ $labels.instance }}"

# 7. Fazit & Empfehlung

Netfilter ist mächtig, aber komplex.

# Anhang: Cheatsheet

Tool Befehl Zweck
nft nft list ruleset Zeigt alle nftables Regeln
iptables iptables -nvL Zeigt iptables (mit Counter)
conntrack conntrack -S Kurzstatistik der Tabelle
sysctl sysctl net.netfilter.nf_conntrack_count Aktuelle Anzahl Einträge
tcpdump tcpdump -i any nflog Pakete loggen, die per jump NFLOG markiert wurden

# Referenzen