© designer111, Photocase.com

Per FW-Builder pflegen Admins die Regelsätze aller ihrer Firewalls, egal welches System sie dort verwenden. Chefprogrammierer Vadim Kurland hat die Software in der dritten Auflage weiter verbessert .

Mehr Funktionen und mehr Übersicht – das verspricht die neue Version 3 des gut etablierten Firewall Builder, kurz FW-Builder. Das Tool konfiguriert in einem Rutsch die Policies beliebig vieler Firewalls unterschiedlicher Hersteller (Apple, BSD, Cisco, Linux) und installiert auf Wunsch die Regelsätze. Die erste Neuerung ist für Kenner der Version 2 sofort zu sehen, wenn sie die erste Firewall anlegen: FW-Builder 3 ordnet die Regelsätze als Objekte direkt einer Firewall zu, diese finden sich nun im Objektbaum im linken Fensterbereich (Abbildung 1a). Version 2 hatte verschiedene Policies hingegen als Reiter im Feld oberhalb des Regelsatzes angezeigt (Abbildung 1b).

Neuerdings ist es möglich, mehrere NAT-Regelsätze zu nutzen. FW-Builder 2 beschränkte den Admin noch auf eine NAT-Tabelle pro Firewall. Je einen Policy- und einen NAT-Regelsatz konfiguriert der Anwender per »top ruleset«-Optionen als oberste Regel. IPtables nutzt diese für die Input-, Forward- und Output-Chains. Andere Regelsätze (ohne Top-Option) legt FW-Builder unter ihrem jeweiligen Namen an und erzeugt Verweise auf diese Regelsätze per Chain-Aktion.

Abbildung 1a: Version 3 des Firewall Builder sortiert alle Policies (hier »Policy«, »NAT« und »Routing«) als Objekte direkt unter den Firewalls. Damit sind sie übersichtlich im grün hinterlegten Objektbaum zu finden.

Abbildung 1b: Die alte Firewall-Builder-Version 2 stellt jede Policy als eigenen Reiter über den Regelsätzen dar. Das hat sich als unübersichtlich erwiesen, da der Admin an zwei Stellen navigieren muss.

Praktische Kette

Sinnvoll ist das zum Beispiel, um Traffic in VPN-Verbindungen anders zu behandeln als den Rest. Im Hauptregelsatz lädt eine Regel als Dienst das Policy-Modul und prüft auf IPsec: »-m policy –policy ipsec«. Die Aktion bei einem Treffer ist dann der Verweis auf den speziellen Regelsatz. Diese Technik ist unter [2] beschrieben. Andere Firewalls (PF, Cisco ACLs) verwenden ähnliche Prinzipien, um zwischen verschiedenen Regelsätzen zu verzweigen.

Komischerweise erlaubt es FW-Builder derzeit noch, mehreren Regelsätzen das Top-Attribut zu verpassen, was recht unsinnige Skripte produziert. Sinnvoller, als sich auf die Umsicht des Admins zu verlassen, wäre, dass FW-Builder den Fehler erkennt und verhindert oder wenigstens davor warnt.

Mehrfachverwertung

Die Sprungtechnik ermöglicht es auch, generische Policies in vielen Firewalls einzusetzen. Bei jeder Firewall verweist dann die Top-Policy auf den generischen Regelsatz. Das funktioniert, da FW-Builder Verweise auch zwischen Regelsätzen erlaubt, die zu unterschiedlichen Firewalls gehören. Das Programm kopiert alle erforderlichen Bestandteile auf jede Firewall. Das hilft enorm, große Installationen im Griff zu behalten.

Noch ein Schmankerl: Regelsätze bleiben zwischen Minor Releases der Version 3 kompatibel. Das heißt, die Struktur eines Regelsatzes ändert sich nicht jedes Mal, wenn jemand sie mit einer neueren FW-Builder-Version öffnet.

Eine sehr praktische Neuerung ist das Multi Document Interface (MDI). Eine FW-Builder-Instanz kann damit mehrere Datensätze mit unterschiedlichen Objekten und Regelsätzen gleichzeitig darstellen. Es ist sogar möglich, Objekte per Drag & Drop zwischen den Datensätzen zu übertragen. Wenn ein komplexes Objekt, etwa eine ganze Firewall, auf diese Weise seinen Stammplatz wechselt, löst das Programm alle Abhängigkeiten auf und nimmt sie mit.

Die Lesbarkeit der Policy verbessern die lang erwarteten Gruppen (Abbildung 2). Beliebig viele Regeln darf der Admin nun zusammenfassen. Falls er eine Regelgruppe gerade nicht benötigt, klappt er sie kurzerhand zu, ganz wie beim Code Folding in guten Texteditoren. Endlich ist es auch möglich, die Größe von Fonts und Icons im Objektbaum und im Regelsatz zu ändern. Damit sorgt FW-Builder auch auf kleinen Laptop-Bildschirmen für eine gute Übersicht.

Mit Version 3 von FW-Builder findet auch IPv6 Einzug in das Tool: Es gibt IPv6-Objekte vom Typ Adresse, Netzwerk oder ICMP-Dienst. Allerdings erlaubt es das Programm nicht, Objekttypen für IPv4 und IPv6 zusammen einzusetzen. Die Eigenschaften einer Policy (Doppelklick auf das Objekt) bestimmen, welcher Adressentyp (IPv4 oder IPv6) hier gilt. Das ist auch verständlich, da Linux strikt zwischen »iptables« und »ip6tables« unterscheidet.

Abbildung 2: Gerade bei großen Regelsätzen sorgen die neuen Gruppen für mehr Übersicht. Der Admin kann den Gruppen Namen geben und sie bei Bedarf einklappen.

Rechte für Benutzer

Spannend ist die neue Fähigkeit, einen Benutzerbezug in die Policy einzubauen. Dazu existiert ein neuer Objekttyp »User Service«. Allerdings funktioniert der nur mit IPtables und PF, da nur diese Firewalls die benötigten Benutzerinformationen auswerten. Während PF dies sowohl für eingehende als auch für weitergeleitete Pakete beherrscht, beschränkt sich IPtables auf Pakete, die von der Firewall selbst stammen (Output-Chain). Zudem muss das Netfilter-Modul »owner« auf der Zielplattform vorhanden sein.

Trotz ihrer Grenzen ist diese Fähigkeit interessant, um etwa Pakete auf Port 25 (SMTP) nur von »postfix«, »sendmail« oder »exim« schicken zu lassen. Hinterlistig installierte Trojaner, die Spam verbreiten oder nach Hause telefonieren wollen, haben so keine Chance.

Mail-Bremse

Ein Beispiel: Der Postfix-Prozess läuft als Benutzer 51. Der Admin erzeugt im FW-Builder einen neuen Benutzer namens »Postfix« mit der User-ID 51. Diesen User kann er nun im einem Regelsatz verwenden, den er direkt auf dem Mailserver installiert. Leider kann er in FW-Builder noch nicht eingeben, dass die Regel sowohl auf das Protokoll SMTP als auch auf den User Postfix prüft. Mehrere Dienste einer Regel verknüpft das Programm automatisch per “oder”. So müsste der Admin in einer ersten Regel das Protokoll prüfen (SMTP) und für den Erfolgsfall auf eine zweite Regel verweisen, die dann den Benutzer prüft und letztlich die Verbindung akzeptiert. Da ist es einfacher, einen neuen Dienst zu definieren und die kombinierte Prüfung von Hand einzutippen (Abbildung 3).

Abbildung 3: Definition eines neuen Dienstes. Beim Anlegen im GUI sind dem Administrator keine Grenzen gesetzt und er kann all Features nutzen, die er von der Kommandozeile kennt.

Die wichtigste Neuerung in Version 3 ist für viele Anwender sicher die überarbeitete Möglichkeit, die XML-Konfigurationsdateien per Skript zu steuern. So braucht der Admin Routinearbeiten, die viele Objekte betreffen, nicht mehr mühsam im GUI zu erledigen, sondern er kann sie per Kommandozeile automatisieren. Auf den Befehl »fwbedit« folgt die gewünschte Operation:

• »new«: Neues Objekte anlegen
• »delete«: Vorhandenes Objekt löschen
• »modify«: Objekt ändern
• »list«: Alle Objekte listen
• »add«: Objekte in eine Gruppe aufnehmen
• »remove«: Entfernt ein Objekt aus einer Gruppe
• »update«: Konvertiert das Datenfile in die aktuelle
  Version
• »checktree«: Datenfile auf Fehler prüfen und
  notfalls gleich reparieren

Alle Operationen erwarten per Option »-f« den Namen des Datenfile. Mit »-F« ist es möglich, die Ausgabe der »list«-Operation zu formatieren. Die Option erkennt Makros, die mit »%« beginnen und enden, in der Eingabe und ersetzt sie durch die entsprechenden Werte der Objekte. So gibt »%address%« die Adresse des Objekts aus. Eine Liste mit allen möglichen Attributen enthält »man fwbedit«.

Das wohl wichtigste Attribut ist »%name%«, aber Achtung: Das Tool identifiziert alle Objekte über ihre eindeutige »%id%«, nicht über ihren Namen. Das Kommando »fwbedit list -r -f firewall.fwb -F “%name%”« listet alle Objekte der Datei »firewall.fwb«. Die Option »-r« veranlasst »fwbedit«, das angegebene Objekt und alle darunter liegenden rekursiv auszugeben. Die Option »-o« begrenzt die Objektsuche auf bestimmte Objekte des Baums. So gibt der folgende Befehl nur die Daten des internen Netzes preis:

fwbedit list -f firewall.fwb -o /User/Objects/Networks/internal -F "%name% %address% %netmask%"

Die Ausgabe lautet »internal 192.168.1.0 255.255.255.0«. Mit »-r« und der Frage nach »/User/Objects/Hosts« erfährt der Admin alles über die definierten Hosts. Zudem kann »-c« die Ausgabe des abgefragten Objekts verhindern und sich auf die darunter definierten beschränken.

Verwirrung

Leider sind die Optionen nicht konsistent. Wenn man ein neues Objekt mit dem Kommando »new« anlegt, setzt »-c« einen Kommentar statt wie bei »list« das Startobjekt auszusparen. Um etwa der Firewall auf Interface »eth1« eine neue Adresse 192.168.200.1/24 hinzuzufügen, lautet der Aufruf:

fwbedit new -f firewall.fwb -p /User/Firewalls/firewall/eth1 -t IPv4 -n firewall:eth1:IP2 -c "secondary address" -a 192.168.200.1,24

Dank der »fwbedit«-Kommandos ist es mit Nmap und einem simplen Skript möglich, neue Objekte automatisch anzulegen. Zeile 2 von Listing 1 gibt den Adressenbereich der DMZ vor, in Zeile 3 fahndet Nmap nach allen Hosts darin. Die Schleife in den Zeilen 13 bis 22 trägt den Host, sein Interface und dessen IP-Adresse in die FW-Builder-Datei »test.fwb« ein. Eine ähnliche Funktion erfüllt die SNMP-Discovery-Funktion [2] bereits seit FW-Builder 2.

Das Beispiel in Listing 2 zeigt, wie leicht es ist, Regelsätze per Skript zu manipulieren, etwa um alle Hosts aus dem Subnetz 192.168.5.* als Gruppe »DMZ-Group« zu vereinen. Die erste Zeile sucht alle Hosts im Subnetz, und Zeile 4 fügt sie zur Gruppe zusammen. Die Gruppe muss dazu vorher schon existieren.

01 #/bin/bash
02 DMZ_LAN=192.168.5.*
03 nmap -sP -T5 $DMZ_LAN | awk '
04   /appears to be up/ {
05     NAME = $2
06     IP = $3
07     gsub(/[()]/, "", IP)
08     if (IP == "appears") {
09       IP = NAME
10     }
11     print NAME " " IP
12   }' | 
13 while read HOSTNAME IP ; do
14   fwbedit new -f test.fwb -t Host -n $HOSTNAME 
15     -p /User/Objects/Hosts
16   fwbedit new -f test.fwb -t Interface 
17     -a external,regular,no -n eth0 
18     -p /User/Objects/Hosts/$HOSTNAME
19   fwbedit new -f test.fwb -t IPv4 
20     -a $IP4,24 -n $HOSTNAME:eth0:ip 
21     -p /User/Objects/Hosts/$HOSTNAME/eth0
22 done

01 fwbedit list -f test.fwb -o /User/Objects/Hosts -c -r -F "%address% %id%" | grep -B3 "192.168.5" | grep "^ id" | 
02 while read id
03 do
04     fwbedit add -f test.fwb -g /User/Objects/Groups/DMZ-Group -o $id
05 done

Überzeugend

Zwar leidet FW-Builder 3 noch unter ein paar Kinderkrankheiten, wie ein Blick in Bugzilla [3] belegt, das meiste sind aber nur kleine Unannehmlichkeiten. Die neue Version wird sicher viele Anhänger finden, da die Fortschritte an der Oberfläche und vor allem das neue Kommandozeilentool »fwbedit« überzeugen. (fjl)