Der Simple Security Policy Editor (SSPE) sorgt für Ordnung im Netz – mit ihm behalten Admins die Kontrolle über die Sicherheitsrichtlinien mehrerer Firewalls. Das Tool generiert aus der zentralen Policy eigene Regelsätze für die im Netz verteilten Paketfilter und VPN-Gateways.

Um größere Netze vor unbefugten Zugriffen zu schützen, sind meist mehrere Firewalls nötig. Sie bewachen jeden Übergang ins Internet, trennen Abteilungen einer Firma oder verbinden mehrere Standorte per VPN. Den Überblick über solche Netze behalten ist schon schwer genug, schwerer noch ist es, jede beteiligte Firewall korrekt zu konfigurieren. Vorbildlich hierbei ist die grafische Oberfläche der Checkpoint Firewall-1 [4]. Doch übertreibt es diese kommerzielle Software gelegentlich, umfangreiche und selten benötigte Features erhöhen ihre Komplexität.

Wesentlich schlanker fällt die freie Software SSPE [1] aus. Beim Simple Security Policy Editor handelt es sich um eine kleine Sammlung von Shell- und Perl-Skripten, mit der Admins bequem eine verteilte Firewallumgebung inklusive IPsec-VPNs verwalten. Das VPN authentifiziert seine Teilnehmer über X.509-Zertifikate. Jede dieser Aufgaben treibt für sich allein selbst gestandenen Admins den Schweiß auf die Stirn.

Beim ersten Start präsentiert sich SSPE mit einer schnörkellosen Dialog-Oberfläche ([7] und Abbildung 1). Hinter dem bewusst spartanisch gehaltenen Frontend verbirgt sich ein überraschend leistungsfähiges Werkzeug. Zu den Vorteilen der Textoberfläche gehört, dass sie sich problemlos aus der Ferne bedienen lässt – wer sich per Modem oder Handy einwählt, kämpft andernfalls mit dem lahmen X11-Forwarding. Die Maus muss dennoch nicht ruhen, je nach Terminalemulation lässt sich das Textinterface auch mit ihr bedienen.

Dass SSPE vom Admin eine Reihe von Konfigurationsdateien verlangt und nicht jede Feinheit in der Oberfläche einstellt, werden viele Anwender sogar als Vorteil empfinden. Ausgefeilte GUIs, etwa der Firewall Builder [3], greifen letztlich auch auf die Kommandozeilen-Tools des Betriebssystems zurück, sie verbergen das aber weitgehend vor dem Benutzer. Selbst die Oberfläche der Firewall-1 schreibt so genannte Inspect-Skripte, die den Paketfilter konfigurieren.

Der Verzicht auf ein umfassendes GUI erhöht die Sicherheit der Adminstrationsmaschine. Jedes weitere Programm, das sich auf der Festplatte befindet, und jedes zusätzliche Feature sind ein potenzielles Sicherheitsrisiko. Auch wenn die Firewalls nicht direkt betroffen sind, weil die Admin-Software auf einem anderen Computer läuft, ist die Gefahr real; ein Angreifer könnte jene Regeln manipulieren, die der Admin anschließend auf die Firewalls lädt.

Der Autor von SSPE gibt als Voraussetzung eine minimale Debian-Installation an. Die für SSPE benötigten Pakete Bash, Dialog und Perl sind darin bereits enthalten. Wegen der Mini-Anforderungen sollte aber jedes Linux als Basis taugen. Im Test bewährten sich Debian Woody, das demnächst erscheinende Sarge, der Debian-Abkömmling Ubuntu sowie Gentoo und Red Hat Linux.

Eine für alle

Gut beraten ist, wer seine zentrale Administrationsmaschine bestmöglich absichert. Nur über dieses Thema ließen sich Bücherregale füllen. Die SSPE-Dokumentation [2] gibt dazu sinnvolle Hinweise, unter anderem sollte der Rechner ausschließlich in einem vertrauenswürdigen Netz laufen und aus vertrauenswürdigen Quellen installiert sein. Die Doku verrät auch, welche Dienste der Admin deaktivieren darf.

Abbildung 1: Das Hauptmenü von SSPE ist sehr übersichtlich geraten. Durch das einfache Textinterface lässt sich die Konfigurationssoftware auch problemlos aus der Ferne bedienen – ein Segen für heimarbeitende Admins.

Vor der SSPE-Installation steht – je nach Bedarf – noch die IPsec-Installation. SSPE ist zwar auf das vor zwei Jahren eingestellte Freeswan-Projekt [5] ausgerichtet, mit Openswan [6] steht aber ein ebenbürtiger Ersatz bereit. Erst bei einem inkompatiblen Fork wären Änderungen an SSPE nötig, was dank seiner Quelloffenheit auch kein Problem wäre.

Umständliche Installation

Die Installation der SSPE-Software gestaltet sich gewöhnungsbedürftig, vor allem weil Informationen nur spärlich gestreut und schwammig formuliert sind. Immerhin gesteht das mitgelieferte »INSTALL«-Dokument, dass es nur Hinweise zur Installation enthält und von einem Security-Administrator erwartet, dass er sich auch mit der Systemadministration auskennt. Wer in den wenigen vorhandenen Hinweisen nichts Passendes findet, sitzt unweigerlich vor einem leeren Bildschirm, es gibt nicht mal aussagekräftige Fehlermeldungen, die ihm vielleicht weiterhelfen. Meist fehlen dem Programm einzelne Verzeichnisse oder sie stehen an falscher Stelle. Die Skripte prüfen solche Fehlerbedingungen nicht.

01 #Name         Netzwerkaddresse      # Kommentar
02 #####################################################################
03 any           0.0.0.0/0             # Alles, was nicht zuzuordnen ist
04 
05 # Interne Netzwerke
06 lan-dtm       192.168.0.0/24        # Work-LAN DTM
07 lan-muc       192.168.1.0/24        # Work-LAN MUC
08 dmz           192.168.2.0/24        # DMZ
09 
10 # Der Boss darf mehr als andere
11 boss          192.168.0.15/32       # PC des Chefs
12 
13 # Der Admin-Rechner benötigen SSH-Zugriff
14 admin         192.168.0.10/32       # Sysadmin-PC
15 
16 # Die SSPE-Workstation braucht spezielle Regeln
17 sspe          192.168.0.2/32        # SSPE-Administrationsrechner
18 
19 # Definition der internen und externen Gateways
20 def-gw        192.168.0.1/32        # Interne NIC der Firewall
21 gw-all        192.168.0.1/32        # Firewall Standort DTM
22 gw-all        1.2.3.4/32            # Firewall Standort DTM extern
23 gw-all        2.3.4.5/32            # Firewall Standort MUC extern

Sicherheitskritische Software sollte möglichst nicht als Root-User laufen. Ein gewöhnlicher Systembenutzer ist für SSPE ausreichend. In dessen Homeverzeichnis erhält SSPE ein eigenes Verzeichnis, die Dokumentation benennt es schlicht »adm«. Da einige Skripte das Verzeichnis unter »$HOME/adm« erwarten, sollte man den Vorschlag auch übernehmen. Der Admin muss darin eine Verzeichnishierarchie anlegen. Am einfachsten kopiert er die Unterverzeichnisse aus dem SSPE-Tarball. Unter »adm/bin« sucht SSPE seine Shell- und Perl-Skripte, um die allgemeinen Konfigurationsdateien in »adm/etc« zu verarbeiten.

Unter »adm/desc« liegt je ein Unterverzeichnis für jeden Rechner, den der Admin per SSPE konfigurieren will. Hier stehen Regeln, Routingtabellen und sonstige Informationen, die ausschließlich diese Maschine betreffen. In »adm/software« stecken alle Programme, die SSPE auf seine Gateways verteilt. Temporäre Dateien landen in »adm/tmp«. Darüber hinaus ist die Datei »adm/.config« nötig. Sie definiert Variablen, die SSPE zum Betrieb dringend braucht. Besonders interessant ist das »BASEDIR« – bei einer falschen Belegung würden viele Skripte ins Leere laufen. Es muss auf das »adm«-Verzeichnis zeigen.

Neben den in ».config« gesetzten Variablen brauchen einige Hilfsskripte eine Shell-Variable namens »ADMROOT«, die auf das im ersten Schritt angelegte Verzeichnis zeigt. Man setzt sie am besten in einer Profile-Datei. Die gesamte Prozedur könnte wie folgt ablaufen:

# adduser sspe
# su - sspe
$ mkdir adm
$ for DIR in bin etc desc software ;
do cp -r sspe-0.2.5/$DIR adm/ ; done
$ mkdir adm/tmp
$ cp sspe-0.2.5/config adm/.config
$ vi adm/.configâ # BASEDIR anpassen
$ echo "export ADMROOT=/home/sspe/adm";
  >> ~/.profile
$ source ~/.profile

Da SSPE die Zielrechner mit ihrem Hostnamen anspricht, empfiehlt es sich, die Maschinen in »/etc/hosts« einzutragen. Sind sie im DNS bekannt, ist dieser Schritt nicht erforderlich. Aus Sicherheitsgründen ist er dennoch zu empfehlen, vermeidet dieser Eintrag doch Probleme durch DNS-Poisoning-Angriffe.

Sichere Kommunikation zu den Firewalls

Da die Kommunikation mit den Firewall-Gateways ausschließlich über SSH mit Public-Key-Authentifizierung zustande kommt, braucht der neu angelegte User noch ein SSH-Schlüsselpaar. Wer nicht ständig die Passphrase eintippen will, gibt dem Key eine leere Passphrase oder benutzt den SSH-Agenten. Der Admin muss – wie üblich – den öffentlichen Teil des Schlüssels auf die Zielrechner bringen [8], auf denen sich SSPE als Root einloggen wird.

01 #Name            Netzwerkadresse    # Kommentar
02 ###################################################
03 lan-dtm          192.168.0.0/24      # Work-LAN DTM
04 lan-muc          192.168.1.0/24      # Work-LAN MUC
05 dmz              192.168.2.0/24      # DMZ

01 #Lokales Netz     NAT-Adresse        # Kommentar
02 ################################################
03 192.168.0.0/24    1.2.3.4            # DTM
04 192.168.1.0/24    2.3.4.5            # MUC

01 #Quelle Ziel Richtung Protokoll Port Policy Options
02 ###################################################
03 admin   sspe Oneway   TCP       ssh  accept LOG

Für die Konfiguration sind mehrere Dateien zuständig, sie erfüllen je einen eigenen Zweck und enthalten Beispiele. An dieser Stelle wird die Dokumentation erheblich ausführlicher und erläutert sogar die Zusammenhänge zwischen den einzelnen Komponenten.

Die zentrale Datei heißt »hostnet«. Sie befindet sich in »adm/etc« und gruppiert Maschinen, die eine ähnliche Richtlinie befolgen sollen. Anhand dieser Gruppen lässt sich das Sicherheitskonzept recht feingranular umsetzen. Meist existiert eine gemeinsame Policy für das interne Netz, die nur wenigen Clients besondere Zugriffe erlaubt. Auch die Zugriffsregeln auf die Firewall selbst sind bei den meisten Maschinen identisch, nur die Admin-Rechner brauchen Sonderrechte. Ein Beispiel ist in Listing 1 abgedruckt.

Mit NAT und IPsec

Verwendet ein Netzwerk NAT (Network Address Translation), dann ist es für die korrekte Umsetzung des Regelwerks wichtig, die intern genutzen privaten Netze (meist nach RFC 1918, [9]) im Vorfeld zu definieren. Hierzu dient die Konfigurationsdatei »privates« (Listing 2). Die Zuordnung zwischen Netzwerk- und IP-Adressen mit der gewünschten NAT findet in »nathosts« statt (Listing 3). Soll SSPE auch für die IPsec-Konfiguration zuständig sein, muss der Admin die Datei »ipsecs« anpassen. Die Angaben darin füllen »/etc/ipsec.conf« im weiteren Verlauf mit Leben.

Es gibt noch drei weitere Konfigurationsdateien, über die später das gesamte Firewall-Regelwerk entsteht. Die Aufteilung ist logisch gut durchdacht. Die Regeln für administrative Zugriffe »rules.admin« und IPsec »rules.ipsec« sind weitgehend statisch, sie unterscheiden sich zwischen den beteiligten Rechnern kaum. Das eigentliche Regelwerk steht in »rules.user«. Die Syntax für alle Dateien ist recht simpel (Listing 4).

Abbildung 2: Im »machines«-Menü trägt der Admin Firewalls ein, die eine eigene Konfiguration erhalten sollen. SSPE ergänzt die Einzelkonfiguration um Basiseinstellungen, die für das gesamte Netz gelten.

Abbildung 3: Das »rules«-Menü verwirrt durch die fehlerhafte Bezeichnung »machines configuration«. Hier ist es derzeit nur möglich, die Konfiguration anzusehen oder sie von Hand mit dem Editor »vi« anzupassen.

Globale und lokale Regeln

Die aus diesem Beispiel resultierende Regel würde es dem Rechner »admin« gestatten, eine SSH-Verbindung mit dem Zielrechner »sspe« herzustellen. Welche IP-Adressen sich hinter diesen Maschinennamen verbergen, steht in der Datei »hostnet«. Das Schlüsselwort »Oneway« beschränkt diese SSPE-Regel auf eine Richtung – der Rechner »sspe« erhält also keinen Zugriff auf »admin«. Da SSPE die globalen Regeln auf alle betroffenen Gateways lädt, sollte dieser Abschnitt des Regelwerks auch möglichst universell bleiben.

Nach der global gültigen Basiskonfiguration folgen die einzelnen Firewalls und Gateways. Hier greift erstmals die SSPE-Oberfläche, aufgerufen per »adm/bin/adm« im Home-Directory des SSPE-Accounts. Der Admin könnte zwar die Verzeichnisse unter »adm/desc« und die jeweiligen Konfigurationsdateien auch händisch anlegen, einfacher geht es aber mit dem Menüpunkt »machine administration | add« (siehe Abbildungen 1 und 2). Die Maschinen sollten hier den gleichen Namen tragen wie in der »hostnet«-Datei. Leider leitet das Tool die IP-Adresse nicht automatisch aus dem Namen ab, sondern erfragt stur jedes Detail beim Admin.

SSPE generiert das benötigte Verzeichnis mit drei Dateien: »desc« enthält die Beschreibung, »ip« die Adresse der Maschine und »hw« unterscheidet zwischen einem Unix-artigen und einem Cisco-Betriebssystem. Der Unterschied wirkt sich etwa darauf aus, wie SSPE die Routen des Gateway ermittelt.

Neben diesen drei eigenständigen Dateien liegen drei Symlinks auf den globalen »rules.*«-Dateien. Sie sorgen dafür, dass jede Firewall zusätzlich das universelle Regelwerk befolgt. Bei einem simplen Szenario mit einer einzelnen Firewall wären die globalen Regeln schon ausreichend, komplexere Fälle brauchen mindestens eine eigene »rules.user« je Firewall. Deren Regeln besitzen Vorrang gegenüber den globalen.

Fünf-Gänge-Menü

Das SSPE-Hauptprogramm ist primär darauf ausgelegt, die jeweiligen Konfigurationen sichtbar zu machen. Der Punkt »rules administration« (Abbildung 3) listet den Inhalt von »hostnet« und erlaubt es, das globale Regelwerk per »vi« anzupassen. (Welchen Texteditor SSPE aufruft, lässt sich nur im Skript »adm/bin/nethostrules« ändern.) Für die spezifischen Regeln einzelner Standorte ist jedoch eine eigene Policy nötig, die wieder Handarbeit verlangt.

Ein Aufruf des Menüpunkts »apply« (Abbildung 1) verteilt das Sicherheitskonzept auf alle beteiligten Maschinen oder auf eine Auswahl. An dieser Stelle zeigt sich, ob alle Einstellungen korrekt waren. Unschön ist die Positionierung dieses Menüpunkts an dritter Stelle, das Menü wirkt daher etwas unaufgeräumt. Besonders stört, dass »prepare distribution« erst an fünfter Stelle folgt, obwohl dieser Schritt vor dem Verteilen kommt. An diesen Zustand gewöhnt man sich aber recht schnell.

Der SSPE-Menüpunkt »ipsecs administration« fördert zunächst nur den Inhalt der »ipsecs«-Konfigurationsdatei zutage, gekürzt um die in ihr enthaltenen Kommentare. Fehlt die lokale »/etc/ipsecs« auf dem Admin-Rechner, bricht SSPE mit einer Fehlermeldung ab. Im Erfolgsfall wartet das Tool, bis der Admin [Enter] drückt. Danach generiert und verteilt es die IPsec-Konfigurationen zusammen mit den Pre-Shared Secrets. Diese berechnet SSPE anhand des Datums, der Uhrzeit und einer Zufallszahl, über die es eine MD5-Summe bildet.

Die »machine administration« (Abbildung 2) dient nicht nur dazu, neue Gateways hinzuzufügen und aufzulisten, hier deaktiviert man auch einzelne Rechner, die vorübergehend nicht erreichbar sind. Andernfalls würden es manche Skripte erfolglos versuchen, auf diese Hosts zuzugreifen.

Gute Basis für verteilte Firewalls

SSPE erreicht das selbst gesteckt Ziel, die Verwaltung und Konfiguration eines verteilten Firewallsystems einfach und effektiv umzusetzen. Das Konzept mag anfangs gewöhnungsbedürftig sein, ist aber logisch durchdacht und taugt sogar für komplexere Szenarien. Bei einer großen Anzahl zu verwaltender Maschinen wird die Darstellung allerdings etwas unübersichtlich.

SSPE ist bisher zu Unrecht nur wenig bekannt. Aber mit zunehmender Beliebtheit dürften sich auch weitere Entwickler für dieses Projekt begeistern, um für Innovationen und Detailverbesserungen zu sorgen. (fjl)