🔒 GitHub-Repo-Update: Von iptables zu nftables – ein Deep Dive in den Paketfilter

🌐 Auch auf: English · Français · Español

Kurzes Repo-Update: Das GitHub-Repo www_k3s hat gerade eine ordentliche Firewall-Generalüberholung bekommen. Das alte Setup nutzte klassisches iptables – hat gut funktioniert, fühlte sich aber langsam an wie ein Oldtimer mit Choke und Zwischengas. Zeit für ein Upgrade. Die Firewall ist jetzt komplett in nftables neu geschrieben, dem modernen Nachfolger, der seit Kernel 3.13 als Linux-Standard ausgeliefert wird. Hier erkläre ich, warum das die richtige Entscheidung ist, und gehe das neue Regelwerk komplett durch. 🧵

⚡ nftables vs. iptables – warum das wichtig ist

iptables ist seit Ende der 90er der Standard-Paketfilter unter Linux. Es funktioniert, ist praxiserprobt, und ungefähr eine Milliarde Stack-Overflow-Antworten beziehen sich darauf. Aber man merkt ihm sein Alter an:

• Keine atomaren Regel-Updates – Änderungen werden Zeile für Zeile angewendet, es gibt also ein kurzes Zeitfenster, in dem dein Regelwerk nur halb aktiv ist
• Getrennte Tools für IPv4/IPv6 – iptables vs. ip6tables, zwei getrennte Regelspeicher, die man synchron halten muss
• Keine nativen Sets – IP-Blocklisten brauchen Zusatztools wie ipset
• Performance – Regeln werden linear abgearbeitet; je mehr Regeln, desto langsamer

nftables (eingeführt mit Linux 3.13, Standard auf den meisten Distributionen seit ca. 2019) löst all das:

• ✅ Ein einziges Regelwerk für IPv4 + IPv6 (table inet)
• ✅ Atomarer Austausch der Regeln – das komplette Regelwerk wird mit einem einzigen Syscall ersetzt
• ✅ Native Sets mit Timeout-Unterstützung (eingebaute IP-Blocklisten, kein ipset nötig)
• ✅ Bessere Performance dank einer JIT-kompilierten virtuellen Maschine im Kernel

Unter AlmaLinux 9 ist nftables der Systemstandard. Der Befehl iptables ist dort buchstäblich nur eine Kompatibilitätsschicht über nftables. Wer 2025 also noch echte iptables-Syntax schreibt, schreibt iptables-Regeln, die sowieso in nftables-Regeln übersetzt werden – und verzichtet dabei nur auf die ganze schöne Syntax. 😅

📄 Das Regelwerk – Abschnitt für Abschnitt

Die Firewall ist ein Ansible-Jinja2-Template (roles/common_firewall/templates/fw.nft.j2), das pro Host gerendert und über nftables angewendet wird. Gehen wir es durch.

🗂️ Die Blocklisten-Sets

set banned4 {
  type ipv4_addr
  flags timeout
  timeout 1d
}
set banned6 {
  type ipv6_addr
  flags timeout
  timeout 1d
}

Zwei Sets – eins für IPv4, eins für IPv6 –, die als dynamische Blockliste dienen. flags timeout + timeout 1d bedeutet, dass jeder Eintrag nach 24 Stunden automatisch verfällt. fail2ban schreibt in diese Sets, sobald es Brute-Force- oder Portscan-Aktivität erkennt. Kein Cronjob nötig, um alte Sperren aufzuräumen. 🧹

🔗 Chain: INPUT – das Hauptprogramm

Die Standard-Policy ist DROP – alles, was nicht ausdrücklich erlaubt ist, wird stillschweigend verworfen.

iif lo accept

Loopback-Traffic (127.0.0.1, ::1) wird immer akzeptiert. Die gesamte hostinterne Kommunikation – kubectl, kubelet, Prometheus-Scraping, Datenbank-Sockets – läuft hierüber.

ct state established,related accept
ct state invalid drop

Das Connection Tracking erledigt die Schwerstarbeit. Bereits bestehende Verbindungen werden akzeptiert, ohne weitere Regeln zu prüfen. Pakete mit ungültigem Zustand (z. B. TCP-Pakete, die zu keiner bekannten Verbindung gehören) werden sofort verworfen.

tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg drop  # XMAS
tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 drop                       # NULL

Der Klassiker: kaputte Pakete wegwerfen. Bei XMAS-Paketen sind alle TCP-Flags gleichzeitig gesetzt – in echtem Traffic unmöglich, genutzt von Portscannern (nmap -sX). NULL-Pakete haben überhaupt keine Flags – gleiche Geschichte. Beides sind Tricks zum Fingerprinting bzw. zum Umgehen von Filtern. Weg damit. 🎄🚫

ct state new tcp flags & (syn|ack) == syn|ack reject with tcp reset

Anti-Spoofing: Ein SYN,ACK, das als neue Verbindung ankommt, heißt, dass jemand aus dem Nichts eine Antwort auf einen TCP-Handshake fälscht. Wird mit einem TCP-RST abgewiesen.

tcp flags & (syn|ack|fin|rst) == rst limit rate 1/second accept
tcp flags & (syn|ack|fin|rst) == rst drop

Schutz vor RST-Floods. RST-Pakete sind legitim (damit werden Verbindungen abgebaut), aber eine Flut davon ist eine DoS-Technik. Höchstens eins pro Sekunde erlauben, den Rest verwerfen.

ip  saddr @banned4 drop
ip6 saddr @banned6 drop

Prüfung der dynamischen Blocklisten-Sets von fail2ban. Sie stehen vor den K3s-Ausnahmeregeln, damit sich eine gesperrte IP niemals über die Pod-CIDR-Ausnahmen weiter unten durchschleichen kann.

{% if 'nextcloud' in group_names %}
ip saddr {{ k3s_pod_cidr }} tcp dport 3306 accept
ip saddr {{ k3s_pod_cidr }} tcp dport 6379 accept
{% endif %}

Eine Jinja2-Bedingung – dieser Block taucht nur auf Nextcloud-Hosts auf. Auf den Nextcloud-Servern laufen MariaDB und Redis als Host-Dienste (nicht in K3s), also müssen Pods sie über die Host-IP erreichen. Auf WordPress-Hosts läuft MariaDB als Pod im Cluster, daher sind diese Regeln überflüssig und fallen weg. 🧠

ip saddr {{ server_ipv4 }} tcp dport { 3000, 10254 } accept

ingress-nginx läuft mit hostNetwork: true, lebt also im Netzwerk-Namespace des Hosts. Wenn es eine Anfrage über einen Kubernetes-ExternalService an Grafana (Port 3000) weiterleitet, ist die Quell-IP die eigene öffentliche IP des Hosts – keine Pod-IP. Dasselbe gilt für die Health-Probes des kubelet auf Port 10254. Also erlauben wir die eigene IP des Hosts, aber nur für genau diese zwei Ports – kein pauschales Accept. 🎯

ip saddr {
  0.0.0.0/8, 10.0.0.x/8, 127.0.0.0/8, 169.254.0.0/16,
  172.16.0.x/12, 192.168.0.x/16, 224.0.0.0/4, 240.0.0.0/5
} drop

Alle Quelladressen aus RFC-1918- und reservierten Bereichen, die auf dem externen Interface ankommen, werden verworfen. Wenn ein Paket aus dem öffentlichen Internet behauptet, von 10.x.x.x oder 192.168.x.x zu kommen, ist es gefälscht. Die K3s-Pod-CIDR-Ausnahmen oben stehen genau deshalb vor diesem Block, damit legitimer Pod-Traffic hier nicht hängen bleibt.

icmp type { destination-unreachable, echo-request, time-exceeded, parameter-problem } accept

Nur die ICMP-Typen erlauben, die wir wirklich brauchen: Ping, Traceroute und Meldungen zu nicht erreichbaren Netzen. Alles andere (Redirect, Router-Advertisement usw.) wird verworfen.

icmpv6 type { destination-unreachable, packet-too-big, time-exceeded, parameter-problem,
  router-advertisement, router-solicitation,
  nd-neighbor-solicitation, nd-neighbor-advertisement,
  echo-request, echo-reply } accept

ICMPv6 braucht eine längere Allowlist, weil IPv6 grundlegend darauf angewiesen ist. Das Neighbor Discovery Protocol (NDP) – das IPv6-Gegenstück zu ARP – läuft über ICMPv6. Ohne diese Typen funktioniert IPv6 schlicht nicht.

ip  daddr {{ server_ipv4 }} tcp dport { 80, 443 } ct state new accept
ip  daddr {{ server_ipv4 }} udp dport 443          ct state new accept
ip6 daddr {{ server_ipv6 }} tcp dport { 80, 443 } accept
ip6 daddr {{ server_ipv6 }} udp dport 443          accept

HTTP, HTTPS und UDP/443 (QUIC/HTTP3) für den Webserver öffnen. Für IPv4 und IPv6. Die UDP-Regel ist es, die HTTP/3 ermöglicht – Browser bekommen es per Alt-Svc angekündigt und wechseln dann bei folgenden Verbindungen darauf. 🚀

ip  daddr {{ server_ipv4 }} tcp dport 10022 ct state new accept

SSH auf einem Nicht-Standard-Port. Port 22 ist inzwischen nur noch Rauschen.

limit rate 2/minute log prefix "nftables DROP IN:  " level warn flags all

Rate-limitiertes Logging von allem Übrigen vor dem Drop durch die Policy. So siehst du, was geblockt wird, ohne das Kernel-Log zu fluten. Mit dem Präfix lässt es sich im journald leicht greppen.

🔀 Chain: FORWARD

K3s verwaltet seine eigenen KUBE-*-Chains für das Service-Routing – diese Chain muss nur Pod-zu-Pod- und Pod-zu-Service-Traffic innerhalb der Pod-CIDR durchlassen und alles andere blocken. Die Blocklisten-Sets werden auch hier geprüft, damit gesperrte IPs weitergeleiteten Traffic nicht ausnutzen können.

📤 Chain: OUTPUT

Auch ausgehender Traffic ist per Standard-DROP eingeschränkt. Erlaubt sind: DNS, NTP, HTTP/HTTPS für Paket-Downloads und die ACME-Zertifikatserneuerung, SMTP für den Mailversand, der K3s-API-Server auf 6443 und ausgehendes QUIC. Alles andere – auch zufällige ausgehende Verbindungen, die Malware versuchen könnte – wird verworfen und geloggt.

🏁 Fazit

Das nftables-Regelwerk leistet eine Menge in relativ wenigen Zeilen. Eine einzige Datei, Dual-Stack IPv4/IPv6, native dynamische Blocklisten, Connection Tracking und Kubernetes-taugliche Ausnahmen – alles in einer atomaren Einheit, die bei jedem Ansible-Lauf sauber angewendet wird. Genau bei so etwas lernt man Infrastructure as Code zu schätzen. 🤓

Das Repo findest du unter github.com/aptupgrademe/www_k3s, falls du tiefer einsteigen willst.