3 Minuten Lesezeit (593 Worte)

Der Tisch wird neu gedeckt – NFtables löst iptables ab

Donnerstag, 19. Dezember 2019

Seit nun schon fast 20 Jahren (Kernel 2.3) wacht das Team aus netfilter-Kernelmodulen und iptables-Userspace-Programmen über den Netzwerkverkehr auf Linux-Systemen. Alle Netzwerkpakete durchlaufen den Kernel und können mit Hilfe von Regeln inspiziert, modifiziert oder verworfen werden. Die mehr oder weniger komplexen Regeln werden vom Administrator mit iptables definiert, allerdings nur für IPv4. Regeln für IPv6, Pakete auf ARP-Ebene oder Pakete, die durch eine Bridge laufen, benötigen eigene Tools mit teils unterschiedlicher Syntax: ip6tables, arptables und ebtables.

Der Nachfolger NFtables wurde ebenfalls von den Netfilter-Entwicklern als Ablösung für iptables entwickelt, mit dem Ziel, die „Firewall"-Konfiguration zu vereinheitlichen und zu vereinfachen. NFtables wird seit 2009 entwickelt und ist seit 2014 (Kernelversion 3.13) Bestandteil des Linux-Kernels. Anstatt vier Tools für die Verwaltung der Regeln gibt es nur noch eines (nft) mit einer einheitlichen Syntax für IPv4-/IPv6-/ARP-/EB-Regeln. Die Syntax der Regeln wurde vereinfacht bzw. „lesbarer" gemacht und ist vom Anwender deutlich intuitiver zu verwenden. Die Entwickler orientierten sich dabei an der Syntax des Berkeley Packet Filter (BPF), die z.B. auch vom bekannten tcpdump verwendet wird.

Als Beispiel hier eine Filterregel, die eingehende Verbindungen auf Port 443 (HTTPS) erlaubt, zuerst in iptables-Schreibweise, dann in NFtables-Syntax:

# iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT 

# iptables -A OUTPUT -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT 

 

# nft add rule inet filter input tcp dport 443 ct state new,established accept

Damit jahrelang gepflegte und komplexe iptables-Filterregeln beim Umstieg auf NFtables nicht sofort auf die neue Syntax umgeschrieben werden müssen, bringt NFtables eine eingebaute Kompatibilitätsschicht mit, die die alte iptables-Syntax verarbeiten kann. Das alte iptables wird dazu in iptables-legacy umbenannt und ein Link von iptables nach iptables-nft sorgt dafür, dass beim Einlesen der Regeln die NFtables-Kompatiblitätsschicht angesprochen wird. Das Gleiche gilt auch für ip6tables, arptables und ebtables. Außerdem existieren noch Tools zum direkten Umwandeln von Regeln, so lassen sich mit iptables-translate einzelne Regeln übersetzen bzw. mit iptables-restore-translate ein komplettes Regelwerk, das vorher mit iptables-save in eine Datei gesichert wurde. Übrigens unterstützt natürlich auch NFtables das Sichern von Regeln: nftlistruleset > nftables.config speichert und nft -f nftables.config liest den Regelsatz wieder ein.

Die interne Arbeitsweise von NFtables unterscheidet sich deutlich von iptables. Letzteres baut auf dem Netzwerkstack des Kernels auf und muss sich von dort immer erst die notwendigen Informationen zum Filter von Paketen besorgen. NFtables hingegen ist direkt im Netzwerk-Stack integriert und kann sofort auf die zu filternden Pakete zugreifen, ohne sie erst vom Netzwerk-Stack anfordern zu müssen. Der ganze Vorgang läuft dabei in einer Art virtuellen Maschine innerhalb des Kernels ab und ist insgesamt deutlich performanter und ressourcenschonender als die Arbeitsweise von iptables.

Seit der Einführung von NFtables hat es das Konstrukt allerdings noch nicht geschafft, das deutlich unterlegene iptables überall zu ersetzten. Zu groß sind die Vorbehalte vieler Admins („Never touch a running system…") und viele scheuen den Aufwand, komplexe Regelwerke in die neue Syntax zu überführen, trotz Kompatiblitätsschicht oder Converter-Tools. Das dürfte sich aber bald ändern, da immer mehr große Distributionen schon auf NFtables als Standard setzen, z.B. Debian 10 (Buster) oder Red Hat seit RHEL 8. Im Laufe der Zeit werden dann auch die angesprochenen Links für die Kompatiblitätsschicht entfernt, so dass z.B. ab Debian 11 (voraussichtlich 2021) der Aufruf von iptables nicht mehr funktionieren wird.