Seite 2: Neue Firewall-Technik Bpfilter

Inhaltsverzeichnis

Der neue Linux-Kernel bringt erste Teile einer neuen Paket-Filter-Technik für Firewalls: Bpfilter. Admins brauchen sich allerdings nicht um ihr Iptables- oder Nftables/nft-Know-how zu sorgen, denn Bpfilter soll lediglich den Unterbau ersetzen, den das altbekannte Iptables und sein designierter Nachfolger nutzen. Das soll beide deutlich schneller machen. Noch liegt dieses Ziel aber in weiter Ferne, denn bei 4.18 wurden nur Teile des dazu nötigen Fundaments gelegt.

Genau passender Code

Der Clou von Bpfilter: Die Entscheidung über die Handhabung von Netzwerkpaketen erfolgt durch lokal erzeugten Programmcode, den der Kernel mit dem BPF ausführt. Dabei handelt es sich um eine prozessbasierte Virtual Machine, die allerdings simpler gestrickt ist als jene von .NET oder Java. Die VM ist auch als eBPF bekannt, da sie in den letzten Jahren aus dem Berkeley Packet Filter (BPF) hervorgegangen ist; mit ihm hat der aktuelle und an zahlreichen Stellen des Kernels genutzte BPF aber kaum noch etwas gemein.

Der BPF-Programmcode zum Filtern der Netzwerkpakete wird bei Bpfilter für die jeweiligen Anforderungen maßgeschneidert. Das reduziert Verzweigungen im Code und verspricht, Overhead zu vermeiden. Damit der Prozessor den BPF-Code möglichst schnell ausführt, übersetzt der Kernel ihn auf gängigen Prozessor-Architekturen noch per Just-in-Time (JIT) in Maschinenbefehle. Darüber hinaus kann Bpfilter den Netzwerkverkehr schon beim eXpress Data Path (XDP) abgreifen; der BPF-Code verarbeitet die Pakete dann schon kurz nach Empfang durch die Netzwerk-Hardware, bevor der mächtigere und daher trägere Netzwerkstack von Linux übernimmt.

Durch diese und andere Vorteile verspricht der neue Ansatz, effizienter zu arbeiten als der Iptables- und Nftables-Code im Netfilter-Subsystem. Der ist zwar in C geschrieben, aber als universeller und flexibler Paket-Filter ausgelegt. Beim Abarbeiten des Regelsatzes muss der Code daher auch auf Eventualitäten gefasst sein, die lokal verwendete Regeln gar nicht nutzen. Das macht den Codepfad komplex, schließlich bietet Netfilter immens viele Möglichkeiten, von denen Firewalls meist nur einen Bruchteil nutzen.

Userspace-Helferlein

Der Umstieg auf Bpfilter ist aber noch Zukunftsmusik, denn in 4.18 flossen lediglich Vorarbeiten ein. Sie schaffen eine Infrastruktur, mit der der Kernel den Filtercode lokal erzeugen soll. Das erfordert einen komplexen Übersetzungsvorgang, daher wollen die Entwickler die dazu nötigen Funktionen nicht im Code sehen, der mit Kernel-Rechten ausgeführt wird. Da es um eine sehr sicherheitskritische Kernel-Funktion geht, wollen sie die Aufgabe aber auch nicht an Werkzeuge delegieren, die unabhängig vom Kernel entwickelt werden und als normale Anwendungen laufen.

Dieses Dilemma gehen die Programmierer mit einer in 4.18 eingeflossenen Erweiterung am User Mode Helper (UMH) und Module-Code an. Sie schaffen einen Zwischenweg, mit dem sich im Rahmen der Kernel-Quellen entwickelte Userspace-Software in autark arbeitende Kernel-Module packen lassen. Bei Bpfilter soll das Modul ein Programm enthalten, das den Bpfilter-Code erzeugt, kompiliert und dabei über Pipes mit dem Kernel interagiert. Das Programm läuft dabei unabhängig vom Userland der verwendeten Linux-Distribution, zugleich aber auch ohne Kernel-Privilegien – es kann daher abstürzen oder abgeschossen werden, ohne dass es den Kernel sonderlich juckt.

Mit diesem Fundament ist auch schon Rumpfcode für Bpfilter in 4.18 eingeflossen, mit dem sich bereits ein Bpfilter.ko genanntes Kernel-Modul erzeugen lässt. Allerdings ist der bislang zu nichts nutze, denn die Entwickler haben die Schnittstellen und den rudimentären Code zurückgestellt, der BPF-Code zum Paketfiltern lokal erzeugt. Diese Funktionen soll bei einer der nächsten Kernel-Versionen folgen, sobald die grundlegende Infrastruktur die gröbsten Fehler abgeschüttelt hat.

Performance-Gewinn

Nutzer sollen von Bpfilter nicht viel mitbekommen, denn Letzterer lässt sich über die Programmierschnittstellen ansprechen, die klassische Filterwerkzeuge wie iptables oder das Nftables-Tool nft bereits nutzen, wenn sie mit dem Iptables- oder Nftables-Code im Netfilter-Subsystem des Kernels interagieren. Die derzeit im Umlauf befindlichen Programme sollten daher auch mit Bpfilter funktionieren.

Frühen Messungen zufolge soll Bpfilter im Betrieb deutlich bessere Performance erzielen. Noch mehr Geschwindigkeit versprechen derzeit eher exotische Netzwerk-Chips, die einen BPF-Beschleuniger mitbringen, um BPF-Code direkt auszuführen.

Solche Verbesserungen sind wichtig, damit Firewalls auch den Verkehr von 40G-Netzwerkkarten stemmen, schließlich rauschen dort in der Spitze rund 60 Millionen 64-Byte-Pakete pro Sekunde durch. Das überfordert den älteren Netfilter-Code bei Weitem. Einige weitere Gründe für die Arbeit an Bpfilter nennt der langjährige Linux-Netzwerkcode-Entwickler Thomas Graf im Blog-Beitrag "Why is the kernel community replacing iptables with BPF?"

Zukunftschancen

Es bleibt abzuwarten, ob das mit Bpfilter so klappt, wie die beteiligten Entwickler sich das denken; bis der neue Ansatz den alten vollständig ersetzen kann, müssen die Programmierer noch allerlei Funktionen implementieren, was einige Zeit dauern wird.

Die Erfolgsaussichten des Bpfilter stehen aber ziemlich gut, denn er stammt von zwei langjährigen und angesehenen Netzwerk- und BPF-Entwicklern: Alexei Starovoitov und Daniel Borkmann. Sie hatten die Unterstützung des langjährigen Kernel-Entwicklers David Miller, der den Netzwerk-Code von Linux betreut. Er witzelte bei der Annahme des Bpfilter-Fundaments für 4.18, dass der Wahnsinn jetzt beginnen könne („let the madness begin“). Greg Kroah-Hartman, einer der wichtigsten Linux-Entwickler, legte noch „Ja, das wird lustig“ nach („Yeah, this is going to be fun“).

Der Chef der Linux-News-Webseite LWN.net geht in einem Artikel zum Stand von Bpfilter bei 4.18 noch weiter: Er erwartet, der erweiterte User Mode Helper werde auch bei anderen Entwicklern auf Interesse stoßen, um Aufgaben auszulagern. Das ist wahrscheinlich, denn ähnlich wie bei Microkerneln kann das den Kernel entlasten, die Sicherheit verbessern und die Programmierung vereinfachen; ein zentraler Entwickler liebäugelte schon mit der Idee, Treiber für USB-Geräte mit Userspace-Modulen zu implementieren.

Der LWN.net-Autor führt zugleich aber an, man solle das Ganze bloß nicht Microkernel nennen, sonst würde es Leute womöglich aus der Fassung bringen. Damit spielt er auf eine 1992 in der Frühzeit von Linux geführte Debatte an, in der Minix-Erfinder Andrew S. Tanenbaum und Linux-Vater Linus Torvalds einige teilweise harsche Mails ausgetauscht haben. Auslöser war ein Statement von Tanenbaum, in dem er den monolithischen Linux-Kernel für obsolet erklärte, schließlich hätten Microkernel letztlich schon gewonnen.