Im Jahr 1999 habe ich im Rahmen meiner Diplomarbeit ein Framework entwickelt, das flexibel und leistungsfähig die
Erstellung von - damals noch - ipfwadm-basierten Firewalls erlaubte. Irgendwann wurde es dann auf iptables aktualisiert
und war insgesamt zwölf Jahre lang in zahlreichen Installationen im produktiven Betrieb.
Eben habe ich die letzten zwei Instanzen abgeschaltet. Und ich bin froh darüber.
Als ich netfilter-init schrieb, war es Stand der Technik, in einem Script zunächst das komplette Regelwerk zu löschen
und dann durch explizit geschrieben Aufrufe von ipfwadm neu aufzubauen. Abhängig davon, wieviel Mühe man sich dabei
gab, war die Firewall während dieses Aufbauprozesses für einige Zeit komplett offen oder komplett zu, was auf der
einen Seite ein Sicherheitsrisiko ist und auf der andren Seite im Falle eines fatalen Tippfehlers den ssh-Zugriff auf
die Firewall unterbindet, wenn der Aufbau des Regelwerks abbricht, bevor die Regeln etabliert sind, die den ssh-Zugriff
erlauben.
Mit netfilter-init war ein Konglomerat verschiedener Shellscripts. Das Haupt-Regelwerk war dabei in eigenen Rules
versteckt, die nach dem Bau des Regelwerks mit einer atomaren iptables --replace Regel aktiviert wurden. Auf diese Weise
war das alte Regelwerk bis zum erfolgreichen Bau des neuen Regelwerks aktiv. Außerdem hatte ich ein Verfahren
implementiert, mit dem man Kreuzprodukte schreiben konnte: --src { 192.168.0.0/24 , 192.168.10.0/24 } --dst {
172.16.0.0/24 , 172.17.0.0/24 } erzeugte vier Regeln.
Mit dem Einbau von netfilter-init in das Firewall-Produkt meines damaligen Arbeitgebers bekam netfilter-init
kommerzielle exposure und zeigte recht schnell seine Grenzen: Besonders die Expansion der Kreuzprodukte und die
Einbindung der aktuellen Netzwerkkonfiguration des Gerätes waren viel zu langsam, so dass die stringintensiven
Operationen relativ schnell in einige kurze C++-Programme ausgelagert wurden. perl wollte ich damals vermeiden, weil
meine Vision war, ein minimales Firewall-System ohne perl installieren zu können. Leider entwickelte sich Debian in die
andere Richtung, und es ist heute richtig schwer, ein Debian ohne perl und ohne python zu betreiben.
Parallel dazu gab es den Versuch, einen in C geschriebenen Konverter zu etablieren, der mir erlauben sollte, dieselben
Scripts zum Regelwerkbau zu verwenden wie vorhanden, nur nicht für jede Regel einen eigenen iptables-Aufruf absetzt,
sondern die Regeln im Speicher zusammenbaut, um sie dann zum Schluß atomar via iptables-restore in den Kernel zu
schieben. So weit kam es dann nicht mehr, weil ich den Arbeitgeber wechselte.
netfilter-init wurde von mir nie wirklich ernsthaft veröffentlicht, weil zu dem Zeitpunkt, zu dem die nötige Reife
erreicht war, andere Lösungen wie shorewall etc da waren, die den Job besser gemacht haben. Ich habe nur lange
gebraucht, bis ich eine Lösung fand, die auch meine Wünsche erfüllt.
Währenddessen schrumpfte die Installationsbasis von netfilter-init immer weiter, während die großen Installationen so
langsam auf unzumutbare Arbeitsgeschwindigkeiten kamen. Dies lag zum Schluß nichtmal mehr an den Shellscripts, sondern
an iptables, bei dem es signifikant Zeit dauert, 16000 Regeln aus dem Kernel auszulesen und dann 16001 Regeln wieder in
den Kernel zurückzuschreiben. Meine größte Installation hat schließlich 15 Minuten gebraucht, um das Regelwerk neu
zu bauen, was besonders beim Booten, wo kein “altes” Regelwerk zur Verfügung stand, unangenehm war.
Schließlich entdeckte ich ferm und arbeitete lange daran, “meine” Spezialitäten auch in einem mit ferm
gebauten Paketfilter unterzubringen. Dies gipfelte in einigen kleinen Patches gegen den ferm-Code selbst und einem
inzwischen ganz gut ausgefeilten “Drumrum”. Das eigentliche Regelwerk wird auf einem Managementsystem gebaut
und das daraus entstehende iptables-restore-taugliche File per scp auf die eigentliche Firewall geschoben. Bevor das
neue Regelwerk dort etabliert wird, gibt es einen at-job, der das alte Regelwerk wieder aktiviert, wenn nicht innerhalb
von 30 Sekunden ein neuer erfolgreicher Login vom Management-System erfolgt und somit nachgewiesen ist, dass auch das
neue Regelwerk den Management-Zugang erlaubt. Versionskontrolle in git rundet die ganze Aktion ab.
Heute habe ich jetzt die beiden letzten, kleinen netfilter-init-Installationen von lenny auf squeeze gehoben und den Bau
des Regelwerks auf mein ferm-Framework umgestellt. Damit endet für mich eine Ära. Wenn man mir 1999 gesagt hätte,
dass diese Software zwölf Jahre lang leben wird - ich hätte es nicht geglaubt.
In diesem Sinne: netfilter-init ist tot, es lebe ferm.