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.
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.
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.
|
Listing 1: Hosts und |
|---|
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.
Alle Rezensionen aus dem Linux-Magazin
Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...
