iptables - Die Firewall des Kernels 2.4

Dies ist kein Artikel über die prinzipielle Funktion einer Firewall. Hierzu gibt es bereits zahlreiche Werke, die besser sind, als ich sie jemals schreiben könnte, z.B. das von Felix Mack, http://www.pro-linux.de/work/firewall/index.html. Der hier vorliegende Artikel befaßt sich vielmehr mit den Neuerungen, die die Architektur des Kernel 2.4 mit sich gebracht hat. Außerdem möchte ich versuchen, die zur Verfügung stehenden Parameter möglichst kompakt und verständlich zu vermitteln, sowie diverse Abhängigkeiten und Zusammenhänge darzustellen.

Nein, nicht nur die Namen haben sich in der Kernel-Evolution geändert. Auch die dahinter verborgenen Funktionen sind von Version zu Version stark erweitert worden. Leider sind damit auch jeweils andere Aufrufkonventionen verbunden. Beim ersten Hinsehen glaubt man an eine mutwillige Verwirrungstaktik der Entwickler, denn mal werden Schlüsselworte und Schalter klein, mal werden sie groß geschrieben. Logik dahinter scheint es keine zu geben. Doch! gerade in diesem Punkt ist iptables wesentlich logischer aufgebaut als seine Vorgänger. Unter der Haube, d.h. im Kernel, geht es mit iptables auch wieder wesentlich aufgeräumter zu. An wesentlich weniger Stellen als bisher wird in den Kernel-Code eingegriffen, um die Firewall-Funktionalität unterzubringen, als dies vorher der Fall war. Damit ist der zur Zeit vorliegende Code auch wesentlich besser wartbar als seine Vorgänger.

Vor dem Kernel 2.0 gab es bereits zahlreiche "Progrämmchen", die allerdings meist als Patch in den Kernel implantiert werden mußten, um diverse Effekte zu erreichen. Diese Programme waren zwar vom Code her bemerkenswert, doch bei weitem nicht so elegant wie die heute eingesetzte Architektur.

Mit dem Kernel 2.0 tauchte "ipfwadm" auf. Es war ein durchaus leistungsfähiges System, doch es gab nur die Möglichkeit, eingehende, geroutete oder ausgehende Pakete zu filtern.

Mit dem 2.2er Kernel erblickte "ipchains" die Linux-Welt. Hier gab es bereits mehrere "chains", die aus jeweils einzelnen Regeln bestanden, die der Reihe nach getestet wurden. Die erste erfolgreiche Regel verließ das Regelwerk und bestimmte den Werdegang des gerade getesteten Paketes. Darüber hinaus konnte man in "ipchains" erstmals eigene Ketten definieren, die den Charakter von Unterprogrammen hatten.

Der Kernel 2.4 brachte ebenfalls wieder zahlreiche Neuerungen. Die "Netfilter"-Architektur bringt ein neues Tool namens "iptables" mit. Verbesserungen gab es bei:

• konsistenterer Namensgebung
• drei Tabellen, die aus mehreren "Chains" bestehen
• stateful inspection jetzt möglich
• Port fowarding mit dem selben Tool
• snat, dnat, masquerading
• DoS Limiting
• Ethernet MAC Adress-Filtering
• variables Logging
• rejects mit einstellbarem Verhalten
• bessere Routing-Kontrolle
• flexiblere Architektur

Um die Funktion besser zu verstehen, gilt es, sich zunächst den Weg, den ein Datenpaket durch den Kernel macht, vorzustellen. Gerade hier haben sich die gravierendsten Änderungen zur bisherigen Architektur gezeigt.

Die "chains" haben also mit der Lage der Datenpakete bei ihrem Weg durch den Kernel zu tun. Um bestimmte Zwecke zu erreichen, bzw. bestimmte Schutzvorrichtungen aufzubauen, sind entsprechende Regeln in die jeweiligen "chains" einzutragen.

An dieser Stelle mag die Frage aufkommen: "Haben wir was vergessen?" Nein, haben wir nicht. Die "tables" haben den Zweck, die verschiedenen Arten der Paketbehandlung auf Module verteilen zu können und nur die Module zu laden (und damit auch nur die "tables" mitzuführen), die im Augenblick bzw. für die gestellte Anforderung benötigt werden. Deswegen tauchen die "tables" auch im obigen Diagramm nicht auf, da sie nur gruppierenden Charakter haben.

Die einzelnen Tabellen existieren nur, wenn Regeln in diesen Tabellen angelegt worden sind. Entsprechend hoch ist die Effizienz eines Paketfilters, wenn z.B. nur einfache Filterfunktionen benutzt werden, da die nicht vorhandenen Tabellen gar nicht erst durchlaufen werden müssen. Vorsicht ist jedoch beim Anlegen von Regeln geboten, da hier peinlichst auf den Zusammenhang zwischen den "tables" und den "chains" geachtet werden muß.