© Wattana Tasanart, 123RF.com

Seit knapp 13 Jahren macht IPtables den Türsteher für Linux und kontrolliert den Fluss der ein- und ausgehenden Netzwerkpakete mit Hilfe der Netfilter-Module. Mit dem anvisierten Einzug von NFtables in den Kernel bahnt sich jedoch eine Wachablösung an, die IPtables womöglich den Job kostet.

Firewalls sind keine Software, sondern ein umfassendes Konzept – das beteuern jedenfalls die Konstrukteure von Sicherheitslösungen immer wieder. Und ein gewichtiger Bestandteil dieses Konzepts sind die Paketfilter (Packet Filter): Das sind Werkzeuge, die es Administratoren ermöglichen, auf Kernelebene bestimmten Netzwerkpaketen den Zutritt zum System zu erlauben oder zu verbieten, was sie gewissermaßen zu Türstehern von Linux macht.

Startschuss: Kernel 3.13

Jene Tools haben eine wechselhafte Geschichte hinter sich – zwischen den Linux-Versionen 2.0 und 2.4 wechselte der Kernel gleich zweimal das Standardwerkzeug zum Filtern von Paketen: Kam in Linux 2.0 noch IPfwadm zum Einsatz, setzte Version 2.2 lieber auf IPchains. In Linux 2.4 hielt dann schließlich IPtables (Abbildungen 1 und 2) Einzug in den Kernel, das die Entwickler seither kontinuierlich verbessert und funktional ausgebaut haben. Bis heute bewährt sich IPtables als alleiniger Standardfilter für Pakete unter Linux.

Abbildung 1: IPtables heißt schon seit Jahren der Standardpaketfilter von Linux. Aus einer tabellarischen Anordnung wie dieser generiert IPtables …

Abbildung 2: … im Stile eines Stateful-Filters Regeln, aufgrund derer er dann Netzwerkpaketen eine Aufenthaltsgenehmigung erteilt oder eben nicht.

Mit der Linux-Version 3.13 könnte sich jedoch eine Wachablösung anbahnen: Die Maintainer des Paketfilters NFtables [1] haben offiziell beantragt [2], ihre Lösung in den Mainline-Kernel aufzunehmen. Zwar steht der Erfolg dieser Bestrebung bei Redaktionsschluss noch nicht fest, weil der Release-Zyklus für Linux 3.13 noch nicht begonnen hat. Doch dass Linux-Chef Torvalds dem Ansinnen Folge leisten könnte, gilt als ziemlich wahrscheinlich. Sollte NFtables den Einzug in den Kernel schaffen, dürfte IPtables keine glorreiche Zukunft mehr haben: Nicht nur kann NFtables die bisherige Lösung vollständig ersetzen, es hat sogar deutlich mehr drauf.

Frappierend ist, dass selbst viele eingefleischte Admins noch nichts von NFtables gehört haben. Dieser Artikel fragt darum, was die Software ausmacht und wieso sie besser als IPtables ist.

Revolution auf Raten

Ein Rückblick auf den Werdegang der diversen Paketfilter unter Linux führt schnell vor Augen, dass jeder neu eingeführte Filter stets das direkte Resultat einer Unzufriedenheit mit der bestehenden Lösung war. Der Paketfilter IPchains bietet sich dafür wunderbar als Beispiel an. Sein Vorgänger IPfwadm war im Grunde eine Portierung des IPfw-Werkzeugs aus dem BSD-Universum und verfügte nicht über besonders ausgefeilte Fähigkeiten. Welche Netzwerkpakete rein und wieder raus durften, ließ sich noch einstellen, aber nach diversen fortgeschrittenen Features suchten Administratoren damals vergeblich.

Der Einsatz von Konditionen blieb in der Ägide von IPfwadm beispielsweise Wunschdenken – Konstrukte wie “Falls ein Paket von der IP 192.168.0.1 kommt, springe zur Kette XYZ” waren daher nicht umsetzbar. Auch Quality of Service, also eine eingebaute Kontrolle der Bandbreite, hatte IPfwadm schlicht nicht implementiert. Und wer etwas anderes als TCP, UDP oder ICMP filtern wollte, der stand auf verlorenem Posten.

Der Nachfolger IPchains räumte mit diesen Schwierigkeiten auf, doch waren die Entwickler und Admins auch mit diesem Produkt nicht wirklich zufrieden. Wie IPfwadm beherrschte auch IPchains diverse Funktionen nicht, die einen ordentlichen Packet Filter ausmachen: So arbeitete die Lösung durchgehend stateless (Details im Kasten “Stateful und stateless”), beherrschte nur eingeschränktes D-NAT (das so genannte Masquerading) und kämpfte mit einer ganzen Reihe weiterer Unzulänglichkeiten.

Defizite von IPtables

Auch die aktuelle Filter-Implementierung hat Nachteile. Aus den Diskussionen der Entwickler in den letzten Jahren kristallisierten sich gleich mehrere Probleme heraus. Derzeit besteht der auf IPtables aufbauende Stack aus vier Teilen:

• IPtables selbst fungiert als Stateful-Filter für Verbindungen nach dem IPv4-Standard.
• IP6tables tut das Gleiche wie IPtables, allerdings für IPv6-Verbindungen.
• ARPtables setzt im Stack weiter unten an und filtert bereits auf ARP-Ebene unerwünschte Pakete.
• EBtables kümmert sich als Sonderfall um Pakete, die Linux über Netzwerkbrücken (Bridges) empfängt und die so dem normalen IPtables entgehen.

Der Haken an der Sache: Es gibt kaum IPtables-Bestandteile, die sich von den vier Abteilungen gemeinsam nutzen lassen. Vielmehr existieren jeweils eigene Unterbereiche im Code, die weitgehend Duplikate sind. Einige Admins werfen IPtables zudem eine miserable Usability und ein mangelhaftes Error Reporting vor. Da es aber der Standard im Kernel ist, haben sich die meisten mit der Situation arrangiert.

Scheintot

Genau hier bringt sich NFtables ins Spiel: Die Lösung möchte die erwähnten Nachteile beseitigen und den Linux-Kernel mit einem Framework zum Filtern von Paketen ausstatten, das den Anforderungen der Zeit besser gewachsen ist als IPtables (siehe Kasten “Unter der Haube”).

nft add rule ip filter input tcp dport 22 accept

Ins Leben gerufen hat das NFtables-Projekt ursprünglich Patrick McHardy: Bereits im September 2008 stellte er es auf dem Netfilter-Workshop in Paris der Öffentlichkeit vor (Abbildung 3). Zwischenzeitlich gesellte sich zum Entwicklerteam auch Pablo Neira Ayuso, doch dann tat sich ein paar Jahre lang gar nichts: 2009 verschwand die Projektwebseite und die meisten Interessenten hielten die Lösung bereits für tot.

Abbildung 3: Im Jahre 2009 stellte Patrick McHardy erstmals seine Ideen für NFtables vor, eine neue Art von Paketfilter.

Zu Unrecht wie sich herausstellte, denn im Oktober 2012 zeigte sich, dass mit NFtables noch zu rechnen war. Der zweite Core-Entwickler Ayuso stellte auf der Netfilter-Mailingliste [3] einen Entwurf für einen NFtables-Layer vor, der vollständige Kompatibilität zu IPtables herstellt und dieses damit faktisch überflüssig macht. Nach dem üblichen Hickhack um eine Mainline-Integration ersuchten die Entwickler Linus Torvalds um die Aufnahme in den Kernel 3.13 – nun wird es also langsam ernst für den Nachfolger von IPtables.

Einheitliche Architektur

NFtables unterscheidet sich in vielerlei Hinsicht von seinem Vorgänger. Die wichtigste Differenz besteht zweifellos in der Architektur, die beiden Lösungen zugrunde liegt: Wirkt IPtables mittlerweile wie ein großes Flickwerk, greifen bei NFtables alle Komponenten ineinander: IPv4, IPv6, ARP und Bridging greifen im Kernel auf die gleichen, abstrahierten Features zurück, die ihrerseits die eigentlichen Funktionen anbieten.

Das ist gut, weil NFtables auf diese Weise jede Menge duplizierten Code vermeidet und die Pflege des ganzen Projekts deutlich erleichtert. Zugleich macht sich die Verzahnung mit dem Netzwerkstack des Linux-Kernels auch in Sachen Performance bemerkbar.

Während IPtables stets auf dem Netzwerkstack aufbaut und sich aus diesem zum Filtern von Paketen erst die notwendigen Informationen besorgen muss, steckt NFtables direkt im Netzwerkstack. Es ist damit deutlich näher am Geschehen und kann sich direkt mit den Paketen beschäftigen, die durch den Stack wandern, statt sie erst separat anzufordern.

Auch sonst geht NFtables durchaus clever zu Werke und orientiert sich an den Berkeley Packet Filters (BPF). Wichtiges Herzstück der gesamten Lösung ist eine virtuelle Maschine innerhalb des Kernels, die das eigentliche Packet Filtering übernimmt. Das ist genau der Teil, der im Netzwerkstack eingebettet ist.

Freilich ist NFtables kein Quasi-Nachbau von KVM & Co., der neue Paketfilter benötigt deren Funktionen größtenteils gar nicht. Aber das Grundprinzip ist dem der gängigen Virtualisierer sehr ähnlich: Ein Paket landet im Netzwerkstack, wo es der Bytecode-Interpreter analysiert, um dann zu entscheiden, was mit dem Paket passieren soll.

Letztlich versprechen sich die Entwickler von NFtables dank der beschriebenen Architektur massive Performancegewinne, eine deutlich höhere Flexibilität des Codes und eine bessere Wartbarkeit im Kernel. Die größte Herausforderung besteht aber weniger in der Technik, sondern eher darin, den Anwendern einen fließenden Übergang von IPtables hin zu NFtables zu ermöglichen.

Mühsame Migration

Denn genau dort liegt eigentlich der Hase im Pfeffer. Nach den Wirren um den Paketfilter in früheren Linux-Versionen haben sich die meisten Anwender und Distributoren mittlerweile mit IPtables arrangiert. Praktisch alle Firewall-Werkzeuge, die den gängigen Systemen beiliegen, sind tief in IPtables verwurzelt und darauf ausgelegt, aus ihm das Beste herauszuholen. Admins haben nicht selten eigene Skripte verfasst, die spezifische IPtables-Konfigurationen nach ihren Wünschen umsetzen. Auch Drittanbieter-Software wie die des Firehol-Projekts [5] sind stark mit IPtables verbandelt (Abbildung 4).

Abbildung 4: Hilfswerkzeuge wie Firehol sorgen dafür, dass Benutzer die komplizierte Syntax von IPtables etwas einfacher nutzen können.

Die NFtables-Entwickler müssen die starken Verbindungen mit bereits existierender Software beachten, wenn sie ihr neues Filtersystem in den Kernel integrieren wollen. Ein inkompatibles System ließe die Akzeptanz der neuen Lösung vermutlich auf null sinken, das Projekt wäre zum Scheitern verurteilt.

Nicht zufällig erhielt NFtables in dem Augenblick Aufwind, als seine Entwickler auf der Netfilter-Mailingliste eine Kompatibilitätsschicht zu IPtables vorstellten. Der Layer soll ein zu IPtables kompatibles Kernelinterface anbieten, das die IPtables-Aufrufe im Hintergrund auf NFtables umbiegt. So bliebe die Kompatibilität erhalten, im Kernel wäre dennoch der neue Paketfilter tätig.

Freilich hängt die Akzeptanz einer solchen Lösung immer von der technischen Qualität ihrer Implementation ab, und relativ sicher ist, dass die Entwickler nur eine Chance haben, um einen guten ersten Eindruck zu erzeugen. Dass sie ihren Code nun in den Kernel bringen wollen, zeigt jedoch, dass sie zumindest selbst davon überzeugt sind, eine stabile Codequalität erreicht zu haben.

Fazit

Mit NFtables könnte erstmals seit Kernel 2.4 eine neue Generation von Paketfilter in Linux einziehen. Technisch ist die Software IPtables überlegen, denn sie ist stateful, modularer, lässt sich einfacher an Protokolle und Techniken anpassen, weil sie dafür vorhandenen Code nutzt, und dürfte aus diesem Grund auch vergleichsweise wartungsarm sein.

Zwar werden wohl nicht sämtliche Distributoren sofort auf den neuen Zug aufspringen, aber sollte es NFtables in absehbarer Zeit in den Kernel schaffen und erreicht die IPtables-Kompatibilität einen stabilen Zustand, wird es für das altgediente IPtables eng. Bis es jedoch angepasste Tools gibt, die sich auch die spezifischen Vorteile von NFtables zunutze machen, dürfte noch etwas Zeit vergehen.