Linux bringt eine leistungsfähige Firewall mit. Sie manuell zu konfigurieren, bringt jedoch selbst Profis ins Schwitzen. Mit dem grafischen Firewall Builder dagegen behalten Sie sogar komplexe Regelwerke bequem im Griff.

Im Zug, im Büro oder im Wohnzimmer: Das Internet ist überall – und damit sein Nutzen, aber auch seine Gefahren. In der Firma schotten Fachkräfte mit Hilfe von Firewalls die Arbeitscomputer vor Attacken aus dem globalen Netz ab. Am Rechner daheim mutiert jeder User zum Admin, der für die Sicherheit des Systems verantwortlich zeichnet. Linux bringt die dafür nötige Firewall-Technologie bereits auf Kernel-Ebene mit: den Paketfilter IPtables.

Der direkte Umgang mit dem Paketfilter und seinen Kommandozeilenwerkzeugen bleibt jedoch eher Profis vorbehalten, die hauptamtlich Firewalls administrieren (Kasten 1). Der Rest der Linux-Welt greift lieber auf eingängigere Konfigurationshilfen zurück. Eine hervorragende Wahl stellt hier der Firewall Builder von Vadim Kurland dar.

iptables -A INPUT -s 192.168.1.1 ?
-p icmp -j DROP

Das Gespann aus IPtables und Firewall Builder benötigt als Grundlage mindestens Kernel 2.3.15, übersetzt mit der Option CONFIG_NETFILTER. Alle gängigen Distributionen weisen diese Voraussetzungen seit längerem bereits auf. Suse-Benutzer müssen aber aufpassen: Die Nürnberger konfigurieren standardmäßig eine eigene Personal Firewall vor, die ebenfalls IPtables verwendet. Um Konfigurationskonflikte zu vermeiden, empfiehlt es sich, vor jeglichen Gehversuchen mit FWBuilder die Suse-Firewall abzuschalten. Dazu starten Sie YaST, öffnen Sicherheit | Firewall und wählen Firewall stoppen und aus dem Bootprozess entfernen aus. Aber auch auf anderen Distributionen gilt analog: Erst eine vorhandene Firewall deaktivieren, bevor FWBuilder neue Regeln scharf schaltet.

Die Basis

Ob der Kernel IPtables tatsächlich unterstützt, lässt sich recht leicht nachprüfen. Dazu sind aber Root-Rechte nötig – tippen Sie also su und danach das Root-Passwort ein. Das folgende Kommando iptables -L listet die vorhandene Regelketten.

Bei einer inaktiven Firewall ohne Regelsatz sollten lediglich die drei Standardketten sowie die Überschriften der zukünftigen Regeln (target, prot, opt, source, destination) zum Vorschein kommen. Erscheinen diese nicht, scheitert die Ausgabe entweder an der Kernel-Version, oder das Userspace-Werkzeug iptables fehlt bzw. liegt nicht im Pfad.

Mit dem Studium entsprechender Dokumentation – etwa Webseiten, Man-Pages und Howtos – sowie einer gehörigen Portion Ausdauer schaffen es auch Firewall-Novizen, ihren Schutzwall Regel für Regel selbst aufzusetzen. Einen einzelnen Heim-PC ausreichend abzuschotten, erfordert allerdings bereits ein paar Dutzend kryptischer iptables-Kommandos. Ein kleines Heimnetz mit wenigen Clients macht bereits Regelskripte mit über hundert Einträgen notwendig, bei komplexeren Setups steigt der Aufwand weiter. Außerdem fallen lange Regelskripte unübersichtlich und damit fehleranfällig und potenziell unsicher aus.

Gebt mir ein GUI

Für mehr Übersicht im Regelwald sorgt der Firewall Builder. Das GPL-lizenzierte Programm arbeitet als Managementapplikation, die Filterregeln für eine Firewall erstellt. Beim FWBuilder arbeitet der Benutzer mit grafischen Objektbeziehungen. Als Ziel-Firewall kommen neben Linux auch BSD-Paketfilter oder kommerzielle Firewalls in Frage.

Managementkonsole und Firewall werden in professionellen Umgebungen üblicherweise getrennt installiert, auch FWBuilder macht das problemlos möglich. Das Programm läuft auf Linux, auf BSD-Systemen, Mac OS X sowie Windows 2000 und XP. Im Fall von Linux und BSD ist es auch möglich, Firewall und Firewall Builder für kleine Heimnetze oder Notebooks auf derselben Maschine zu betreiben.

Die Linux-Installation des Firewall Builder 2.0.6 verläuft dank fertiger RPMs für Suse, Fedora und Mandrake recht einfach. Auf Sourceforge liegen die Pakete zum Download [2], zusätzlich befinden sie sich auf der Heft-CD. Die FWBuilder-Pakete für Suse 9.1 funktionieren auch unter Suse Linux 9.2. Achtung: Vadim Kurland hat seine Software in mehrere Einzelkomponenten zerlegt, die er auch als Einzel-RPM anbietet. Mindestens drei davon müssen installiert sein, damit FWBuilder funktioniert: Zuerst die Bibliothek libfwbuilder-2.0.6-1.Distribution.rpm., danach FWBuilder selbst (fwbuilder-2.0.6-1.Distribution.rpm) sowie der so genannte Policy-Compiler für die IPtables-Regeln (fwbuilder-ipt-2.0.6-1.Distribution.rpm).

Verschiedene Ziele

Weitere Policy-Compiler erzeugen die Regelsätze für andere Plattformen, beispielsweise fwbuilder-pf-2.0.6-1.Distribution.rpm für die pf-Firewall von OpenBSD. Diese Option schätzen besonders Security-Administratoren, die ihre Firewall-Plattform wechseln und dabei ihre Regelbestände behalten können. Zusätzliche, zum Teil auch kommerzielle Compiler finden sich auf [1].

Nach der Installation starten Sie mit dem Befehl fwbuilder die Oberfläche. Das Programm präsentiert zunächst ein aufgeräumtes Dialogfenster, mit dem Sie ein bestehendes Projekt öffnen oder ein neues erstellen. Nach der Wahl von Create new project file fragt der Firewall Builder zuerst nach Namen und Pfad für die zukünftige fwb-Projektdatei. Nach einem Klick auf Next müssen Sie noch entscheiden, ob er die Versionskontrolle aktivieren und das neue Projekt automatisch bei jedem Programmstart laden soll. Beides können Sie nachträglich noch ändern. Erst der Klick auf Finish startet das noch weitgehend leere Hauptfenster von FWBuilder.

Das Objekt der Begierde

Firewall Builder verfolgt einen konsequent objektorientierten Ansatz und stellt deshalb reale Beziehungen von Objekten und deren Diensten dar. Mögliche Objekte sind einzelne Hosts, IP-Adressen, Netzwerkkarten, aber auch ganze Netzwerke sowie die Firewall selbst.

Die Dienste (Services) umfassen die Verbindungsarten der Objekte und damit die Protokolle und Ports, welche die jeweiligen Verbindungen nutzen. Soll zum Beispiel ein Notebook eine lokale Firewall erhalten und lediglich SSH-Verkehr von und zur Maschine X gestatten, dann sind zwei Objekte involviert: die Firewall und Maschine X. Als Service kommt das TCP-basierte SSH auf Port 22 zum Zug. Dieser Ansatz macht FWBuilder so charmant: Statt endlos abstrakte iptables-Regeln aneinander zu hängen, arbeitet man hier mit Begriffen und Assoziationen der realen Welt, die das Programm zudem grafisch darstellt.

Um das Notebook-Beispiel in leicht modifizierter Form umzusetzen (eine Maschine, lokale Firewall, SSH-Zugriff von und zu beliebigen Rechnern) gilt es zunächst, das Firewall-Objekt zu erstellen. Dazu offeriert FWBuilder das Menü Objects | New Object mit allen bekannten Objekttypen. Für die Firewall ist der Eintrag New Firewall zuständig. Dieser Menüpunkt startet einen Wizard, der mehrere Fragen zur Konfiguration der neuen Firewall stellt, vor allem nach deren Betriebssystem und Paketfilter sowie dem gewünschten Objektnamen. Der Wizard bringt auch fertige Vorlagen als Basis für die neue Firewall-Konfiguration mit. Ein gesetztes Häkchen (zum Beispiel bei host fw template 1) bindet die Vorlage ein. Das spart Zeit und demonstriert zugleich, wie abstrakte Objekte und Services funktionieren.

Nach dem Bestätigen des Dialogs erscheint eine weitere Box, die zusätzliche Einstellungen der Firewall erwartet – vorerst sind hier aber keine Angaben nötig. Abbildung 1 zeigt FWBuilder nach Auswahl des Templates host fw template 1, das sich für eine direkte Internetanbindung und eine dynamische IP-Adresse bestens eignet.

Abbildung 1: FWBuilder 2 wirkt aufgeräumt mit grafischen Objekten statt kryptischer IPtables-Kommandos. Diese Konfiguration erlaubt SSH-Zugriffe auf das Notebook, gestattet dem Notebook beliebige Verbindungen nach außen und sperrt alle anderen Zugriffe.

Regelwerk

Drei grundlegende Objektbeziehungen definiert FWBuilder bereits vor, die das Programm am linken Rand von oben nach unten durchnummeriert. Eine solche Objektbeziehung heißt im FWBuilder-Jargon “Rule”. Es handelt sich dabei aber nicht um eine IPtables-Regel, sondern um eine abstrakte Objektregel. Erst später generiert der Policy-Compiler daraus die konkreten IPtables-Regeln.

Die Reihenfolge der Objektregeln ist wichtig. Pakete durchlaufen, logisch gesehen, alle Rules der Reihe nach von oben nach unten. Lehnt eine Regel weiter oben ein Paket ab, eine spätere Rule würde dieses Paket aber gestatten, dann blockiert die Firewall das Paket dennoch. Dieser Effekt heißt Rule Shadowing: Unten stehende Regeln liegen im Schatten der oberen Einträge und kommen daher nicht zum Tragen. Nach dem Erstellen aller Einträge prüft Firewall Builder, ob dieser Effekt auftritt.

Das Policy-Fenster ist sehr schlüssig aufgeteilt. Jede Regel enthält Felder für die Einträge zu Quelle, Ziel, Service und Aktion sowie für die optionalen Zeitabhängigkeiten und für etwaige Kommentare. Zum Beispiel erlaubt Regel 0 in Abbildung 1 zu allen Zeiten den Zugriff auf die Firewall von allen Quellen (Schlüsselwort Any in den Spalten Source und Time), aber nur via SSH (Spalte Service). Sie akzeptiert auch ping requests.

Das gelbe Symbol neben Useful_ICMP bedeutet, dass es sich um eine Objektgruppe handelt. Ein Doppelklick auf das Symbol öffnet die Gruppe und zeigt, dass sie vier ICMP-Typen zusammenfasst, die nach Ansicht des Template-Autors sinnvollerweise erlaubt sein sollten.

Wege ins Netz

Die zweite Regel (Nummer 1 in der ersten Spalte) beschreibt die Beziehung der Firewall zu allen anderen Zielen, namentlich dem Internet. Die Regel erlaubt jeglichen Service (Any) und gestattet damit dem Notebook-Besitzer uneingeschränkten Zugriff auf alle Dienste im weltweiten Netz. Rule 2 agiert als Auffangbecken für jene Pakete, auf die weder Rule 0 noch Rule 1 zutrifft. Wird die Firewall mit einer HTTP-Anfrage auf Port 80 belästigt, dann fühlen sich (ordnungsgemäß) weder Regel 0 noch 1 zuständig: Sie reichen die unbehandelten Pakete ignorant an Rule 3 weiter, die sie kurzerhand verwirft. Wer weitere Regeln, Objekte und Dienste braucht, kann diese problemlos ergänzen.

Für jedes Netzwerk-Interface der Firewall erscheint im FWBuilder ein eigener Reiter neben dem Policy-Reiter. Dorthin kommen schnittstellenspezifische Regeln. Das oben gewählte Template host fw template 1 sieht zwei Schnittstellen vor: outside für das externe Netz und loopback für das Rechner-interne Loopback-Device.

In und Out

Der Reiter outside der Beispielkonfiguration enthält eine Spoofing-Schutzregel. Sie verwirft alle hereinkommenden Pakete, deren Absender die Adresse der Firewall trägt: Solche offensichtlich gefälschten Pakete stellen ein Sicherheitsrisiko dar. Im loopback-Bereich ist jeder Verkehr gestattet, den die Firewall selbst generiert hat.

Ein einzelner Rechner braucht keine NAT-Regeln (im letzten Reiter vorgesehen). Die wären nur für Firewalls nötig, die als Gateway für andere, über eine private IP-Adresse konfigurierte Rechner fungieren und den Zugang ins Internet herstellen. In einem Heimnetz allerdings ist letzteres meist der Fall – die englische Dokumentation auf [1] leistet bei der entsprechenden Konfiguration wertvolle Hilfe.

Ein Management-Interface auf der Firewall darf auf keinen Fall fehlen. FWBuilder benötigt diesen Zugang später, um seine Regeln einzuspielen. Zur Einrichtung wählen Sie im linken Objektbaum die gewünschte Schnittstelle der Firewall – in diesem Fall das Loopback-Interface – und klicken mit der rechten Maustaste darauf. Über den Eintrag Edit des Kontextmenüs gelangen Sie zum Interface-Fenster und markieren dort das Kästchen Management Interface.

Stricken oder stricken lassen

Bevor die Regelsätze auf die Linux-Firewall kommen, muss sie FWBuilder in rudimentäre iptables-Aufrufe übersetzen. Der Firewall Builder geht noch einen Schritt weiter und erstellt ein Shell-Skript, das zusätzlich die Einstellungen aus dem Kontextmenü Firewall Settings ... umsetzt.

Das Erstellen des Skripts heißt in FWBuilder-Terminologie trefflich “Kompilieren” und lehnt sich bewusst an das Übersetzen von Quell- in Binärcode an. FWBuilder legt sich erst beim Kompilieren auf eine Zielplattform fest. Das bedeutet aber auch, dass jede Änderung der Policy einen neuen Policy-Compiler-Lauf erfordert. Das Menü Rules | Compile startet diesen Vorgang; die Dialogbox aus Abbildung 2 begleitet ihn. Das Ergebnis landet zunächst im selben Verzeichnis wie die Projektdatei.

Der Compiler bemerkt das erwähnte Rule Shadowing und meldet unsinnige Regeln, etwa doppelte oder widersprüchliche Einträge. Dieser Mechanismus schützt nicht vor schweren Fehlern im Regeldesign, findet aber viele Flüchtigkeitsfehler. Abbildung 3 zeigt die generierten iptables-Regeln. Der Compiler erzeugt ein recht übersichtliches Skript und fügt sogar Kommentare ein. Abbildung 3 zeigt Regel 0 aus dem Policy-Bereich von Abbildung 1. Für ein weiteres Verständnis von IPtables lohnt es sich, das Skript genauer zu untersuchen.

Abbildung 2: Die Policy-Compiler generieren plattformspezifisch die eigentlichen Firewall-Regeln. Hier ist der Compiler für IPtables “fwb_ipt” am Werk.

Abbildung 3: Das generierte Firewall-Skript enthält alle nötigen IPtables-Anweisungen. Obwohl es per GUI entstand und automatisch kompiliert wurde, enthält das Skript Kommentare und nützliche Hinweise.

Regeln installieren

Laufen FWBuilder und Firewall auf zwei getrennten Maschinen, dann muss das Regelskript nun noch auf die Firewall kommen. Der Firewall Builder bedient sich dabei der Hilfe von SSH. Daher muss ein entsprechender Daemon auf dem Management-Interface der Firewall lauschen. Im vorliegenden Beispiel handelt es sich bei der Schnittstelle um das Loopback-Device, wie das verwendete Template es vorgibt. SSH muss Root-Logins akzeptieren, weil nur root die iptables-Befehle absetzen darf (mit sudo lässt sich diese Einschränkung umgehen).

Nach Eintragen des Benutzernamens root mit Kennwort öffnet FWBuilder eine SSH-Verbindung zur Firewall (hier dem lokalen Rechner), überträgt das Skript und führt es aus (Abbildung 4). Ein Eintrag in /var/log/messages auf der Firewall bestätigt, dass das Skript erfolgreich lief:

Mar 2 17:02:11 mynotebook root: ?
Activating firewall script gener?
ated Wed Mar 2 17:00:06 2005 CET?
 by stephan

In der Logdatei landen auch Hinweise über Pakete, die die Firewall mit reject oder deny verworfen hat. Wünschen Sie ein weniger ausführliches Logging, so stellen Sie dies im Policy-Fenster des FWBuilder unter Options bei der jeweiligen Regel ein.

Abbildung 4: Der Policy Installer überträgt das Firewall-Skript auf die Firewall und führt es aus. Damit aktiviert er die neuen Regel. Über den kompletten Ablauf informiert der Installer übersichtlich und dennoch detailliert.

Fazit

FWBuilder hat seit Version 1 in Puncto Stabilität und Benutzerfreundlichkeit enorm zugelegt. Es bietet weitaus mächtigere Funktionen, als man auf den ersten Blick vermuten würde. Lediglich in Details weist das Tool noch kleinere Schwächen auf. So wirkt etwa das GUI manchmal etwas hakelig, eine Integration von Bandbreiten-Policies (Quality of Service, QoS) fehlt bislang.

Die kompromisslose Umsetzung der Idee einer objektorientierten, zentralen Verwaltung von Firewalls macht das Werkzeug gleichermaßen für Heimanwender wie für Security-Profis interessant. Selbst komplexe Setups mit mehreren hundert Regeln behält man im Griff, ohne die Übersicht zu verlieren. Feineinstellungen lassen sich mit wenigen zielsicheren Mausklicks erledigen. Das Installieren der Regeln erfolgt schlicht und effizient. (fjl/jlu)