Unfairen Mitspielern im Netz zeigt IPtables die gelbe oder rote Karte. Dank FW-Builder, einem Profi-GUI, zaubert der Admin im Sturm ein ausgefeiltes Regelwerk. Version 2.1 gibt ihm noch mehr Mittel in die Hand und instruiert polyglott alle Schiri-Kollegen an den Außenlinien.

Regelsätze für Firewalls schreiben ist eine recht lästige Aufgabe. Wer mit der schier endlosen Liste von »iptables«-Parametern hadert, wünscht sich eine grafische Oberfläche. Kritisch wird es, wenn ein ganzes Team an Firewalls mit verschiedenen Architekturen auf dem Programm steht. Hier kommt der FW-Builder [1] von Vadim Kurland [2] ins Spiel. Das Programm verfügt über ein hervorragendes GUI und erzeugt aus der zusammengeklickten Policy passende Firewallskripte für die wichtigsten Firewallsprachen: IPtables, IPfilter, FWSM, IPfw, PF oder Pix. Dabei geht FW-Builder so umsichtig vor, dass das Tool auch professionellen Ansprüchen genügt.

Die aktuelle FW-Builder-Version 2.1.10 bindet sogar SNMP [3] ein und kann via Bind [4] DNS-Zonentransfers nutzen, um Konfigurationen auf die Firewalls zu verteilen. Wer das Tool schon länger einsetzt, sollte aufpassen: Ändert er ein altes Firewall-File (Endung ».fwb«) mit der 2.1-Release, dann konvertiert sie das Dateiformat. Das klappt zwar problemlos, nur können alte FW-Builder-Versionen damit später nichts mehr anfangen.

Neue Fähigkeiten

Beim ersten Kontakt mit der neuen Release fällt alten FW-Builder-Hasen die neue Auswahl »Tools« in der Menüleiste auf (Abbildung 1). Unter »Automat zur Netzerkennung« gibt es einen Wizard, der Objekte in einem Netzwerk aufspürt. Er liest zum Beispiel ein File im Format von »/etc/hosts« oder erkundet das Netz.

Abbildung 1: Vorkonfigurierte Beispiel-Firewall mit drei Netzwerkkarten und jeweils einem Server in der DMZ und einem im internen Netz. Bei den Tabs hat sich zur alten Version einiges geändert.

Als Startpunkt dient ein SNMP-fähiger Rechner. Der Druide liest per SNMP die ARP-Tabelle aus und versucht den gefundenen IP-Adressen DNS-Namen zuzuordnen. Bei den gefundenen Rechnern beginnt die SNMP-Anfrage erneut. Eine Begrenzung auf einen Adressenbereich (etwa 192.168.0.0/16) verhindert, dass der weise Mann das ganze Internet erkundet. Optional nutzt FW-Builder DNS-Zonentransfers, um die im DNS verzeichneten Maschinen aufzuspüren – falls diese Option einkompiliert ist.

Auch an anderen Stellen hat sich das GUI-Design verändert. Alles wirkt runder und frischer. Außerdem sind die Interface-Reiter aus der Policy verschwunden. Die Interfaces sind jetzt ein Bestandteil der Regel selbst. Die Schnittstellen innerhalb der Regeln zu verwalten beschränkt die Anzahl der Tabs auf ein Minimum und gibt jedem Tab eine klarer definierte Bedeutung. Bei riesigen Regelsätzen könnte das schwer überschaubar werden. In der Praxis passiert das aber nicht, weil die neue Version Regelsätze in Chains aufsplitten und dadurch für Übersicht sorgen kann.

Viele kleine Hilfen sorgen für zusätzliche Ergonomie. Ist ein Objekt im Baum ausgewählt, dann hebt FW-Builder alle Einträge optisch hervor, die dieses Objekt verwenden (Abbildung 2). Ein Klick im Kontextmenü auf »Wo benutzt« (je nach Version auch »Where used«) führt zu einer kompakten Aufstellung, wo das Objekt zum Einsatz kommt. Dabei ist es egal, ob das Objekt ein Host oder ein Gruppe ist oder ob es in der Policy, im NAT oder in einer Gruppe verwendet wird. Dieses Feature hilft sehr, eine gewachsene Policy durchzuflöhen und auf ein normales Maß zu beschränken.

Abbildung 2: Wo benutzt die Policy ein bestimmtes Objekt? Markiert der Anwender das Objekt in der Baumansicht (links), setzt FW-Builder rechts einen roten Rahmen um jedes Auftreten. Der Kontextmenü-Eintrag »Where used« liefert eine übersichtliche Liste aller Fundstellen (rechts unten).

Neue Objekte

Als neue Objektart taucht »Address Tables« auf, gemeint sind Ascii-Dateien mit Netzwerkadressen. Die bindet FW-Builder entweder beim Kompilieren der Policy ein oder erst zur Laufzeit, also wenn das Policy-Skript auf der Zielplattform läuft. Das eröffnet neue Möglichkeiten, rasch die Firewall umzukonfigurieren. Dshield listet zum Beispiel die 20 auffälligsten Störer im Internet [5]. Das in Listing 1 skizzierte Skript lädt die Liste (Zeile 2), bereitet sie für den FW-Builder auf (Zeilen 3 bis 6) und lädt die Firewall neu (Zeile 7).

01 cd /tmp
02 wget http://feeds.dshield.org/block.txt
03 grep "^[1-9]" /tmp/block.txt | while read L; do
04    set $L
05    echo $1"/"$3 >> /tmp/myblock.txt
06 done
07 /etc/init.d/firewall.fw

Achtung: Das Skript verwendet feste Namen unter »/tmp«. Es empfiehlt sich, ein eigenes, nicht öffentliches Verzeichnis anzulegen. Ein Cronjob könnte dieses Skript täglich ausführen – oder die deutlich bessere Version von Johannes Ullrich [6], des Gründers von Dshield. Ähnlich interessant ist es, Objekte mit ihren DNS-Namen anzulegen statt ihrer IP. FW-Builder löst sie wahlweise beim Kompilieren oder erst während der Laufzeit auf. Letzteres klappt nur, wenn die Firewall Zugang zu einem Nameserver hat, der den Namen des Objekts kennt.

Alles auf einen Schlag

Vor dem Kompilieren und Installieren erscheint jetzt ein Dialog (Abbildung 3), der abfragt, welche Firewallskripte FW-Builder neu kompilieren und installieren soll. Dieser Bulk-Betrieb ist sehr hilfreich, um größere Installation in den Griff zu bekommen.

Abbildung 3: FW-Builder kann die Skripte für mehrere Firewalls gleichzeitig übersetzen und installieren. Das erspart dem Administrator viel Arbeit.

Eine weitere wichtige Änderungen verbirgt sich im Detail der Eigenschaften eines Interface: Über seine Eigenschaften (per Doppelklick auf die Schnittstelle zu erreichen) ist es möglich, das Interface als Bridge-Port zu betreiben. Leider überprüft FW-Builder nicht selbstständig, ob das Zielsystem die notwendigen Patches installiert hat und die Schnittstellen richtig konfiguriert sind. Das Programm muss sich auf den Administrator verlassen, da es selbst erst bei der Installation mit den Firewalls kommuniziert.

Testlauf

Für kritische Fälle gibt es daher die Option, während der Installation einen Testlauf des neuen Skripts zu starten und es nicht permanent zu speichern. Zusätzlich kann man der Installationsroutine auftragen, dass sie die Firewall nach ein paar Minuten neu startet. Im Katastrophenfall stellt das automatisch die alte Konfiguration wieder her.

Ein besonderes Schmankerl ist das Routing-Patch von Maurizio Tidei, das es in den offiziellen Code geschafft hat. Der dritte Tab der Policy (Abbildung 1, oben Mitte) erlaubt es, Regeln für das Routing genauso einfach wie Filter- oder NAT-Regeln aufzustellen. Umfangreiche Routingtabellen lassen sich auf diese Art grafisch übersichtlich pflegen. Leider ist das notwendige IPtables-Patch in den Kerneln der meisten Distributionen noch nicht zu finden.

Wer seinen Kernel nicht mit dieser Option neu übersetzen will, kann sich mit einem Trick behelfen, um doch noch ein Firewall-basiertes Routing einzubauen und die Routingtabelle des Kernels zu nutzen. Als Aktion für eine Regel gibt es das »Mark«-Target, das einem Paket eine spezielle Markierung mitgibt. Sie gilt auch für alle weiteren Pakete dieser Verbindung, wenn die entsprechende Option ausgewählt wurde. FW-Builder fügt dann eine Regel mit »-j CONNMARK –save-mark« ein. Eigene Routingregeln (»ip rule …«) können die Markierung dann auswerten [7].

Neue Action

Welche Aktionen eine Regel auslösen, bestimmt primär das Zielsystem. Viele der hier beschriebene Features stellt FW-Builder nur zur Verfügung, wenn als Zielfirewall Linux (also Netfilter/IPtables) zum Einsatz kommt. Einiges hängt aber auch von der Distribution ab. Viele Hersteller haben zum Beispiel die als experimentell markierten Module noch nicht eingebaut. Ein Blick in »/lib/modules/Version/kernel/net/ipv4/netfilter« schafft Klarheit, welche Module es auf einem System gibt.

Um den Wildwuchs der Regeln in einer langen Policy zu bremsen, ist es möglich, über das Kontextmenü der Aktion einer Regel eine neue Kette (Chain) anzulegen. FW-Builder erzeugt daraufhin einen neuen Tab für die Regeln der neuen Chain. Sinnvoll ist das zum Beispiel, um innerhalb eines VPN-Tunnels zu filtern [8]. Dazu ist ein eigener Dienst nötig, der das Policy-Modul von Netfilter auswertet: Im linken Baum auf »Services | Custom« gehen, im Kontextmenü »Neuer benutzerdefiniertzer Dienst« wählen, den Namen »VPN_IN« vergeben und den Code »-m policy –dir in –pol ipsec« für die IPtables-Plattform eintragen.

In der Policy muss eine weitere Regel (erste Zeile in der oberen Hälfte von Abbildung 4) dafür sorgen, dass alle eingehenden verschlüsselten Pakete in die Chain »VPN_IN« wandern. Dort darf der Admin nach Herzenslust filtern, wie die unterste Zeile in Abbildung 4 zeigt.

Abbildung 4: Filtern innerhalb eines VPN-Tunnels ist mit einer Verzweigung im Regelsatz (oben) kein Problem. Alle Pakete, die die Firewall verschlüsselt erreichen, leitet IPtables an eine eigene Chain (unten).

Qualität und Limits

Die Wunschliste vieler Anwender beginnt mit der Integration einer QoS-Lösung in FW-Builder. Daraus ist zwar noch nichts geworden, aber man kann bereits als Aktion für eine Regel »Klassifizieren« (Classify) angeben. Parameter dafür ist der Wert »Major:Minor«. Er bestimmt, welche Klasse die Pakete dieser Verbindung erhalten ([7], [9]).

Regeln mit diesem Target behandelt IPtables in der Mangle-Tabelle beim Postrouting. Normalerweise ist eine weitere Regel notwendig, die diesen Verkehr auch zulässt. Über die erweiterten Einstellungen der Firewall (in FW-Builder) lässt sich auch bestimmen, dass sie entsprechend klassifizierte Pakete automatisch akzeptiert (Option »Make Tag and Classify actions terminating«).

FW-Builder erlaubt es, über die Optionen einzelner Regeln deren Gültigkeit zu begrenzen. Das bietet sich zum Beispiel für SSH-Anfragen an. Bei Rumpelstilzchen-Attacken sammeln die Logfiles hunderte Benutzernamen und Passwörter, die ein Angreifer erfolglos durchprobiert. Als Gegenmaßnahme eignet sich das Limit-Modul von IPtables.

In den Optionen einer Regel der Policy von FW-Builder befindet sich der Tab namens »Limit«. Der Autor verwendet hier eine Rate von einer Anfrage pro Minute und einem Burst von fünf. Achtung: Die Grenzen nicht zu eng setzen! Zum Beispiel startet der FW-Builder selbst etliche SSH-Verbindungen, um ein neues Skript zu installieren. Auch muss der Admin aufpassen, wie die Firewall eine Verbindung bewertet, die außerhalb des Limits liegt. Die ursprüngliche Regel gilt dann nicht mehr, es ist explizit eine DROP-Regel einzufügen.

Gelungen

Die aktuelle Version des FW-Builder ist ein gelungener Wurf, der viele lange gehegte Wünsche wahr werden lässt. Über seine Vielfalt an Targets nutzt das Tool IPtables und IProute 2 hervorragend. Die neuen Installationsmechanismen sind ein Segen für Admins, die mehrere Firewalls betreuen. Glückwunsch an Vadim Kurland! (fjl)