Mit der Secure Platform bietet Checkpoint ein gehärtetes Red Hat Linux zusammen mit der Firewall-1 NG aus dem eigenen Haus an. Damit ist es einfach, die Firewall in kurzer Zeit selbst zu installieren – ohne die sonst übliche Hilfe von Integratoren und Consultants.

Die Checkpoint Secure Platform[1] kombiniert auf einer CD die kürzlich erschienene Checkpoint Firewall-1 NG FP3 (Next Generation, Feature Pack 3) mit einer abgespeckten und gehärteten Linux-Distribution. Die CD ist auf Intel-Systemen bootfähig und installiert in wenigen Minuten eine stark angepasste Red-Hat-Distribution inklusive der Checkpoint-Software.

Die Installation hinterlässt ein hervorragend gesichertes System. Tiefere Linux-Kenntnisse, wie sie für die Systemhärtung und eine sinnvolle Partitionierung erforderlich sind, muss der Admin bei diesem Produkt nicht mitbringen. Um die wenigen Fragen im Verlauf der Installation richtig zu beantworten, benötigt er nur grundlegendes Wissen über die Struktur der Firewall-1 und ihre Lizenzierung. Mit der Secure Platform ist es für Endkunden somit leichter geworden, die Firewall-1 selbst aufsetzen und beim Integrator nur noch die Lizenz (siehe Kasten “Lizenzierung”) und den Datenträger einzukaufen.

Salopp ausgedrückt funktioniert der Checkpoint-Markt in Deutschland nach dem Coca-Cola-Prinzip: Der Getränke-Hersteller gibt sein Produkt an Franchising-Partner ab, die es abfüllen und an Distributoren weiterverkaufen. Von dort geht es an die Endverkäufer, dann erst kommt der Kunde ins Spiel. Mit der Firewall-1 ist es ganz ähnlich. Checkpoint gibt seine Produkte an Distributoren auf den europäischen Märkten, von dort geht es zu den Integratoren, die dem Endkunden dann sowohl das Produkt als auch die benötigten Consulting-Leistungen verkaufen.

Die Secure Platform durchbricht diesen Ablauf, sie ist bereits fertig integriert. Was den Kunden freut, birgt auf dem europäischen Markt einigen Sprengstoff. Integratoren wollen schließlich nicht nur Lizenzen durchreichen und im Notfall, wenn eine Eigeninstallation doch nicht skaliert, die Feuerwehr spielen.

Installation

Die Installation der Secure Platform läuft ab wie die einer Mini-Linux-Distribution. Das System bootet von der CD in einen textbasierten Installer, stellt einige Fragen (Tastatur, 2-Tier- oder 3-Tier-System …) und installiert in etwa vier Minuten eine funktionstüchtige Fire-wall-1. Fehler, die unter Umständen nicht mehr auszubügeln sind, können dabei lediglich an zwei Stellen passieren: Zum einen fragt der Installer, ob man ein Enterprise- oder ein Small-Office-System wünscht (Abbildung 1). Der zweite Stolperstein ist die Products Configuration: Diese detaillierte Konfigurationsmöglichkeit steht nur im Enterprise-System zur Verfügung.

Die Auswahl Small Office oder Enterprise wirkt sich auf die Produktauswahl im nachfolgenden Dialog (Abbildung 2) und auf das installierte System aus. Ein Small-Office-System lässt sich nur per HTTPS und Webserver (»admin_httpd«, »cp_httpd«) konfigurieren, ein Zugang per SSH ist hier nicht vorgesehen. Diese Option ist damit nur für kleine Netz mit weniger als 25 Clients geeignet. Bei größeren Netzen ergeben sich Probleme mit der Skalierbarkeit, der Admin hat dann doppelte Arbeit.

Einen ganz anderen Eindruck macht das System, das mit der Enterprise-Option entsteht. Installiert werden 94 RPM-Archive mit 210 MByte Software, ohne Webserver, aber inklusive OpenSSH. Es gibt keine Möglichkeit, während der Installation die Paketauswahl, die Partitionierung oder den Hostnamen zu ändern. Tabelle 1 zeigt die Partitionierung des fertigen Systems, die Checkpoint-Software befindet sich unterhalb des »/opt«-Verzeichnisses.

Viele Pakete unterliegen der GPL oder der BSD-Lizenz, die Checkpoint-Software untersteht aber einer proprietären Lizenz. Alle Paketnamen enden auf »cp«, zum Beispiel »bash-2.05-8cp«. Bei GPL-Paketen muss Checkpoint die eventuell veränderten Quellen offen legen. Weil uns die Bash besonders interessierte, haben wir die Quellen angefordert und binnen 24 Stunden auch erhalten. Zumindest die Bash unterscheidet sich im Inhalt nicht vom GNU-Original, trotz des »cp«-Kürzels. Der einzige Unterschied ist die Größe der Archive, das lässt sich aber auf die Komprimierung (Gzip, Bzip2) zurückführen.

Härtung und Betrieb

Das installierte System hinterlässt einen überzeugenden Eindruck. So befinden sich unmittelbar nach der Installation keine Set-UID-Dateien auf der Festplatte, kein Dienst wird über den Inetd gestartet, das System akzeptiert (wegen der installierte Cracklib, siehe Abbildung 3) nur sichere Passwörter. Der Remote-Zugang ist nur per SSH möglich, direkte Root-Logins sind nicht erlaubt.

Weder für GNU-Pakete noch für die proprietäre Software stehen Manpages zur Verfügung. In der Vergangenheit waren Manpages zahlreicher Unix-Derivate (etwa Solaris, FreeBSD und Red Hat) ein beliebter Angriffspunkt für Rootkits. Zumeist haben diese Sicherheitsprobleme mit dem Catman-System zu tun, das für das Cacheing und Anzeigen von formatierten Texten zuständig ist. Catman funktioniert Set-GID (Gruppe »man«) oder gar Set-UID (User »man« benötigt sogar eine gültige Login-Shell). Es gibt Vorschläge, den regelmäßig wiederkehrenden Sicherheitslöchern ein Ende zu bereiten: Statt vorformatierte Texte anzuzeigen, müsste der Man-Viewer die Seite jedes Mal neu aufbereiten.

Das eigentlich Interessante dieser Distribution liegt tiefer. Von den Einträgen in »/etc/passwd« sind nur die beiden Benutzerkennungen Root und Admin (welche beide die UID »0″ haben) aktive User. Ein Remote-Login per SSH ist nur dem Benutzer Admin möglich. Er erhält als Login-Shell die proprietäre CP-Shell (deren Quellen nicht zur Verfügung stehen). Die Shell ähnelt mehr dem Cisco IOS als einer klassischen Unix-Shell. Nach der Eingabe eines Fragezeichens präsentiert sie eine Liste mit allen Befehlen, die sie anbietet.

Die CP-Shell enthält (so jedenfalls in der Enterprise- Installation) eine ganze Reihe eingebauter Kommandos, von denen sich der größte Teil auf die Checkpoint-Software bezieht. Diese Kommandos genügen, um eine Firewall-1 zu administrieren. Kommandos zum Konfigurieren der Secure-XL-API (Checkpoint Performance Pack zum Erhöhen des Durchsatzes) und Befehle für Cluster-XL sind ebenfalls vorhanden.

Abbildung 1: Bei der Installation bietet die Secure Platform eine Enterprise- und eine Small-Office-Version zur Wahl. Letztere ist recht unflexibel, da sie sich nur per Web-Oberfläche administrieren lässt.

Abbildung 2: Der Admin kann neben der Firewall-1 noch weitere Produkte von Checkpoint mitinstallieren. Diese Auswahl unterscheidet sich, je nachdem, ob er ein Enterprise- oder Small-Office-System gewählt hat.

Experte eingebaut

Eines der Built-in-Kommandos ist der »expert«-Befehl. Es ist in beiden Installations-Versionen vorhanden. Das Kommando funktioniert analog zum »su«-Befehl und startet als Subshell eine Bash für den Root-User (Abbildung 4). Zur Systemwartung stehen Root so zusätzliche GNU-Kommandos zur Verfügung, zum Beispiel kann er zusätzliche Verzeichnisse anlegen, Filesysteme (etwa CD-ROM) mounten oder Shellskripte schreiben.

Erst im Expert-Modus kann der Admin weitere Pakete installieren. Die Secure Platform lässt sich auch mit der im Linux-Magazin 08/02[3] beschriebenen Rainwall clustern – wenn die mit der Rainwall gelieferte GNU-C++-Bibliothek installiert ist. Das erfordert zwar etwas Handarbeit, ergibt aber ein Cluster ohne unnötigen Ballast.

Die Plattform sieht lediglich die beiden erwähnten Benutzer mit der UID »0« vor (Root/Expert und Admin). Ein Login als Root-User ist weder remote noch lokal möglich. Obwohl die GNU-Befehle »useradd« und »passwd« vorhanden sind, war es unmöglich, neue User anzulegen. Auch manuelles Editieren der Dateien »/etc/passwd« und »/etc/shadow« führte nicht zum Erfolg.

Das Problem ist, dass der »passwd«-Befehl offenbar immer das Login-Passwort des Admin-Users ändert, egal welcher Benutzer es aufruft oder für welchen User man es ausführt. Die Sourcen des Befehls sind aber unverändert. Das Verhalten könnte von PAM-Modulen ausgelöst werden, aber auch dort war nichts Ungewöhnliches zu entdecken. Nachfragen beim Hersteller Checkpoint führten ebenfalls zu keiner Klärung.

Abbildung 3: Nach dem ersten Login zwingt die CP-Shell den Admin, sein Passwort zu setzen. Die Cracklib verhindert dabei, dass er ein zu kurzes oder zu leicht zu erratendes Passwort wählt.

Abbildung 4: Per SSH gelangt der Admin zunächst in die CP-Shell der Secure Platform. Das »expert«-Kommando führt ihn dann zur Bash. Erst hier hat er Zugriff auf die üblichen Linux-Funktionen.

Auf direktem Weg ins Netz

Die Netzwerkkarten des Systems oder das VLAN-Tagging (Virtual LAN) lassen sich bequem in der CP-Shell konfigurieren, diese Aufgabe übernimmt der Befehl »sysconfig«. Eigenartigerweise ist dort kein Untermenü zu finden, das die Geschwindigkeit der Netzwerkkarten oder den Betriebsmodus (Fullduplex FDX, Halfduplex HDX) festlegt. Hier muss sich der Admin offenbar auf die Autosensing-Funktion der Netzwerkkarten verlassen, was in der Praxis zu Problemen führen kann. Eine Firewall sollte so wenig Parameter dynamisch aushandeln wie möglich.

Interessant ist der Sysconfig-Menüpunkt »Products Configuration«. Er legt fest, ob man eine einfache oder eine verteilte Installation anstrebt (auf gut Neudeutsch: 2-Tier oder 3-Tier). Bei einer 2-Tier-Installation (Abbildung 5) sind zwei Rechner involviert: der Rechner des Administrators mit dem GUI zur Konfiguration der Regelbasis und der Rechner mit der eigentlichen Firewall. An einer 3-Tier-Installation (Abbildung 6) sind drei Rechner beteiligt. Die Firewall teilt sich dann auf in einen Rechner, der die Regelbasis verwaltet und die Logfiles empfängt, sowie einen Rechner mit der eigentlichen Filter- und Routing-Funktion (das Firewall-Modul).

3-Tier-Installationen sind zwar etwas performanter, unterliegen jedoch einer komplizierteren Lizenzierung. Diese Installationsvariante eignet sich vor allem für Cluster und für große Umgebungen mit vielen Firewall-Modulen an verschiedenen Standorten.

Wenn alle Punkte des Sysconfig-Menüs abgearbeitet sind, sollte sich das GUI mit der neuen Firewall verbinden können, um Zertifikate auszutauschen und ein erstes Regelwerk zu konfigurieren (siehe Abbildung 7). Schlägt dies fehl, etwa weil das Regelwerk ausgerechnet den GUI-Arbeitsplatz aussperrt, ist Arbeit an der Konsole angesagt: Das Kommando »fw unload all.all« schaltet die Firewall auf Durchzug.

Die mittlerweile zahlreichen Features und APIs der Firewall-1 haben zur Folge, dass nach der Installation auf knapp 30 TCP-Ports bereits ein Service lauscht. Bis auf SSH und die RPC-Ports 32770 bis 32774 gehören alle offenen Ports zu Firewall-1-Diensten, etwa für die Remote-Administration per GUI, zur User-Authentifizierung oder für das Logging. Genau genommen sind nicht alle diese Ports offen, da die Regelbasis jene Dienste per Default sperrt. Eine implizite Cleanup-Rule sorgt dafür: »any any any deny«.

Im Test kam eine 2-Tier-Installation zum Einsatz. Nach der Konfiguration des Systems in der CP-Shell ist dazu nur noch das Checkpoint-GUI erforderlich. Es dient zum Erstellen und Administrieren der Regelbasis und läuft auf einem eigenen Rechner mit Microsoft Windows. Dieser Punkt war der zeitaufwändigste und verwirrendste der ganzen Installation. Ein erfahrener Firewall-1-NG-Anwender wird im Windows-Installer ein Paket namens »Management Clients« suchen, das es aber seit FP 3 nicht mehr gibt. Die Management-GUIs bestanden früher aus drei Applikationen: Policy-Editor, Log-Viewer und Status-Viewer. Mit FP 3 heißen alle drei jetzt SMART-Client (SMART-Dashboard, SMART-Status und SMART-View-Tracker).

Abbildung 5: In einer 2-Tier-Installation legt das GUI die Regelbasis direkt auf dem Firewall-Rechner ab. Ein Compiler übersetzt die Regeln, die das Firewall-Modul steuern, in ein Binärformat.

Abbildung 6: Eine 3-Tier-Installation trennt den Firewall-Rechner und den Konfigurations-Server. So kann eine zentrale Konfiguration auch mehrere Firewall-Module bedienen, gerade bei verteilten Installationen ist diese Architektur praktisch.

Abbildung 7 : Die Secure Platform lässt sich mit den üblichen Checkpoint-GUIs von einem Windows-Rechner aus administrieren.

Fazit

Wegen der CP-Shell ähneln Konfiguration und Administration der Secure Platform mehr einer Appliance als einem normalen Linux-Rechner mit installierter Checkpoint-Software. Gegenüber einer typischen Appliance hat die Secure Platform aber zwei Vorteile: Zum einen werden die meisten Appliances Browser-basiert administriert, auf ihnen läuft also zusätzlich ein Webserver. Stellt man ihn ab, ist die Administration nicht mehr besonders komfortabel. Die Secure Platform lässt sich textbasiert per SSH und CP-Shell ohne zusätzlichen Webserver administrieren. Zudem hat sie einen Preisvorteil, da günstige, handelsübliche Hardware ausreicht, wenn sie die Systemanforderungen erfüllt.

Ein möglicher Nachteil ist, dass im Gegensatz zur echten Appliance Hard- und Software aus verschiedenen Quellen stammen. Schuldzuweisungen im Fehlerfall zwischen beiden Lieferanten sind daher nicht ausgeschlossen, in der Praxis aber kaum zu erwarten. (fjl)