Die Firewall-1 von Checkpoint zusammen mit der Cluster-Software Rainwall auf einem Rack-PC unter Red Hat: Mit 4 Your Safety hat die Siemens-Tochter SBS eine Firewall-Appliance für gehobene Ansprüche im Programm. Sie spielt zwar in der oberen Preisliga, bietet aber auch viel Leistung fürs Geld.

Eine Appliance kann viel Arbeit sparen: Das Betriebssystem selbst härten, Firewall-tauglich konfigurieren und darauf die Firewall-1 installieren – das ist eine schwierige Aufgabe. Bei der Appliance 4 Your Safety[1] hat Siemens das bereits erledigt und das Produkt zusätzlich OPSEC-zertifiziert. Der Firewall-1-Hersteller Checkpoint hat die Appliance also in seinen Labors getestet und als empfehlenswerte Konfiguration anerkannt. Sollte irgendwann eine Support-Anfrage bei Checkpoint nötig sein, reduziert das die Menge der Fragen der Support-Mitarbeiter, ebenso eventuelle Zweifel an den eigenen Fähigkeiten.

Als neues Produkt am Markt muss sich die Siemens-Appliance gegen eine Reihe etablierter Lösungen durchsetzen. Beispielsweise liefert Nokia ebenfalls Firewall-1-Appliances mit Intel-x86-Prozessoren. Die Hardware steckt bei den Finnen in einem speziell für diesen Zweck entworfenen Chassis. Als Betriebssystem dient ein stark modifiziertes OpenBSD. Die geänderten Quellen stehen nicht zur Verfügung – die BSD-Lizenz erlaubt dies.

Siemens benutzt einen normalen Rack-PC des Typs Fujitsu-Siemens Primergy N200 und setzt auf Red Hat Linux. Der Kasten “4 Your Safety” fasst zusammen, wie die beiden Knoten des getesteten Clusters ausgestattet waren. Vorinstalliert waren die Checkpoint Firewall-1[2] zusammen mit Version 1.6 der Rainfinity Rainwall[3] auf einem Red Hat Linux 6.2 mit Kernel-Version 2.2.19.

Modernes Clustering mit Rainwall

Die Rainwall des Herstellers Rainfinity ist eine innovative und leistungsfähige Clustering- und Load-Balancing-Lösung, unter anderem für die Checkpoint Firewall-1. Erfreulich ist, dass Rainwall für Linux verfügbar ist und eine Appliance diese Kombination auch nutzt.

Mit Rainwall können mehrere Firewalls parallel arbeiten, um den gesamten Durchsatz zu erhöhen (Abbildung 1). Sie benutzt dazu einen Pool von virtuellen IP-Adressen (VIP), der auf die Interfaces der beteiligten Firewalls verteilt ist. Im Eingangsrouter sind alle VIPs als Gateway für das Netz hinter den Firewalls eingetragen. Ein Cisco-Router wird bei asymmetrischem Routing so eingestellt, dass er jedes Paket über eine andere VIP schickt, also ein Round-Robin-Verfahren benutzt. Bei symmetrischem Routing verteilt er die Sessions (Verbindungen) auf die VIPs.

Abbildung 1: Mehrere Firewalls können gemeinsam mehr Daten bewältigen als eine einzelne. Der Router bestimmt mit der virtuellen IP (VIP), über welchen Weg die einzelnen Pakete in das Firmen-LAN gelangen.

Verschobene VIP

Die Rainwall kann VIPs zwischen den einzelnen Interfaces und Firewalls austauschen und damit den Weg der Daten beeinflussen. Das Prinzip verdeutlicht Abbildung 2: Die Waage steht für das Firewall-Cluster, die Waagschalen für je ein Firewall-Interface. Zunächst sind die VIPs gleichmäßig verteilt, die CPU der rechten Firewall ist aber stärker ausgelastet als die der linken. Rainwall behebt das, indem sie dem linken Interface mehr VIPs zuteilt. Die linke Firewall erhält so einen höheren Anteil des gesamten Datenstroms. Nun ist die Systemlast auf beiden Systemen ausgeglichen.

Durch das Round-Robin-Verfahren im Zugangsrouter werden selbst Pakete, die zu einer einzelnen Verbindung gehören, zwischen den Firewalls aufgeteilt und getrennt gefiltert. Weil das in der Praxis nicht immer problemlos möglich ist, kann Rainwall auch einzelne Sessions (Verbindungen) getrennt behandeln oder bestimmte IPs fest einem Interface zuordnen.

Abbildung 2: Load Balancing mit Rainwall: Zunächst haben beide Firewalls dieselbe Anzahl virtueller IP-Adressen, die rechte aber eine höhere Systemlast. Das Verschieben einiger VIPs gleicht die Last aus.

Die Appliance

Im Test musste die Appliance zeigen, wie gut sie sich zu einem Cluster konfigurieren lässt, wie sich der Support für Hard- und Software darstellt und ob das Cluster überhaupt stabil läuft.

Siemens hat auf dem Gerät nur 121 Pakete installiert, nach dem Booten zeigt sich eine schlanke Prozesstabelle (siehe Listing 1). Die offenen Ports sind in Listing 2 wiedergegeben. Der Hersteller hat die Härtung also ernst gemeint. Das zeigen auch die kurzen Idle-Zeiten, nach denen beim Zugriff über das Netzwerk und über das GUI ein automatischer Logout erfolgt. Für sicheren Remote Login ist OpenSSH vorinstalliert, der Daemon wird gestartet.

Per Default verarbeitet »sshd« die SSH-Protokollversion 2. Wer mit älteren Clients zugreifen muss, kann dies mit dem Eintrag

Protocol 2,1

in »/etc/ssh/sshd_config« erlauben. Ob das angesichts der bekannten Schwächen der Protokollversion 1 sinnvoll ist, muss jeder selbst entscheiden[4].

Die Web-basierte Administrations-Oberfläche von Siemens präsentiert sich sehr übersichtlich, der Funktionsumfang geht aus der linken Leiste (Abbildung 3) hervor. Im Vergleich zu Nokia bietet das Siemens-Produkt einige Goodies, etwa die Webshell oder den Web-basierten Texteditor. Beide benutzen Https. Die Webshell ist leider keine Terminal-Emulation, daher lassen sich keine interaktiven Programme (more, less, vi …) benutzen. Mit einer Java-Lösung wie Mindterm[5] wäre auch dies möglich.

Abbildung 3: Die Auswahlliste am linken Rand ist fast vollständig aufgeklappt. Rechts läuft die Webshell, sie kann Shell-Kommandos an die Firewall abschicken.

Listing 1: Prozesse auf der Appliance

USER     PID %CPU %MEM   VSZ  RSS TTY    STAT START  TIME COMMAND
root       1  0.0  0.1  1120  476 ?      S    May17  0:04 init [3]
root       2  0.0  0.0     0    0 ?      SW   May17  0:00 [kflushd]
root       3  0.0  0.0     0    0 ?      SW   May17  0:00 [kupdate]
root       4  0.0  0.0     0    0 ?      SW   May17  0:00 [kswapd]
root       5  0.0  0.0     0    0 ?      SW   May17  0:00 [keventd]
root       6  0.0  0.0     0    0 ?      SW<  May17  0:00 [mdrecoveryd]
root    1306  0.0  0.2  1172  552 ?      S    May17  0:00 syslogd -m 0
root    1315  0.0  0.3  1604  948 ?      S    May17  0:00 klogd -c 4
daemon  1329  0.0  0.1  1144  496 ?      S    May17  0:00 /usr/sbin/atd
root    1343  0.0  0.2  1328  620 ?      S    May17  0:00 crond
root    1352  0.0  0.3  2032  904 ?      S    May17  0:00 sshd
root    1361  0.0  0.9  4412 2436 ?      S    May17  0:00 /opt/apache/bin/httpd
root    1364  0.0  1.4  5256 3696 ?      S    May17  0:00 /opt/apache/bin/httpd
root    1365  0.0  1.5  5516 3940 ?      S    May17  0:00 /opt/apache/bin/httpd
root    1398  0.0  0.1  1092  428 tty1   S    May17  0:00 /sbin/mingetty tty1
root    1399  0.0  0.1  1092  428 tty2   S    May17  0:00 /sbin/mingetty tty2
root    1400  0.0  0.1  1104  464 ttyS0  S    May17  0:00 /sbin/agetty -L 9600 ttyS0 vt100
root    5664  0.0  0.9  4496 2516 ?      S    10:12  0:00 /opt/apache/bin/httpd
root    5666  0.0  0.9  4496 2516 ?      S    10:12  0:00 /opt/apache/bin/httpd
root    5782  0.0  0.6  3220 1744 ?      S    13:17  0:00 sshd

Listing 2: Offene Ports

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address   State
tcp        0      0 *:262           *:*               LISTEN
tcp        0      0 *:18184         *:*               LISTEN
tcp        0      0 *:18183         *:*               LISTEN
tcp        0      0 *:900           *:*               LISTEN
tcp        0      0 *:1052          *:*               LISTEN
tcp        0      0 *:259           *:*               LISTEN
tcp        0      0 *:1051          *:*               LISTEN
tcp        0      0 *:1050          *:*               LISTEN
tcp        0      0 *:1049          *:*               LISTEN
tcp        0      0 *:1048          *:*               LISTEN
tcp        0      0 *:1047          *:*               LISTEN
tcp        0      0 *:264           *:*               LISTEN
tcp        0      0 *:265           *:*               LISTEN
tcp        0      0 *:256           *:*               LISTEN
tcp        0      0 *:6374          *:*               LISTEN
tcp        0      0 *:https         *:*               LISTEN
tcp        0      0 *:ssh           *:*               LISTEN
udp        0      0 *:259           *:*
udp        0      0 *:6374          *:*
udp        0      0 *:6372          *:*
udp        0      0 *:https         *:*

Zu streng geprüft

Negativ fällt die Plausibilitätsprüfung beim Setzen des Hostnamens auf. Sie ist zu streng und erlaubt nicht alle Namen, die laut DNS-RFC zulässig sind. Bei dem Versuch, »linux-magazin« als Hostnamen zu verwenden, erscheint die Fehlermeldung aus Abbildung 4: Die Oberfläche erlaubt nur Buchstaben, Zahlen und Punkte.

Das Rainwall-Modul ist in der Standard-Installationen ebenfalls über ein komfortables Web-Interface konfigurierbar (Abbildung 5). Dazu muss auf der Appliance der Tomcat-Server (siehe Kasten “Tomcat: Servlets im Web”) gestartet sein. Er setzt eine lauffähige Java-Installation voraus, allerdings ist Java der Härtung durch Siemens zum Opfer gefallen. Tomcat selbst ist zwar installiert, kann ohne Java aber nicht laufen. Nach Auskunft von Siemens ist Tomcat ein fester Bestandteil des Rainwall-Pakets, der bei der Vorkonfiguration nicht wieder entfernt wird.

Abbildung 4: Bei den zulässigen Hostnamen ist die Siemens-Appliance zu streng, sie verbietet sogar den Bindestrich.

Abbildung 5: Das Rainwall-Modul lässt sich über eine eigene Web-Oberfläche konfigurieren. Vorausgesetzt allerdings, dass auf der Appliance das Java-RPM installiert ist.

Java: Mit oder ohne?

Java lässt sich aber als eigenes RPM von der Rainwall-CD nachinstallieren. Danach kann man Tomcat kurzzeitig aktivieren, um das Cluster einzurichten. Eigentlich wäre das eine Aufgabe für das GUI der Appliance: Es könnte Tomcat bei Bedarf starten und dann wieder beenden. Andererseits kann man die Rainwall ähnlich übersichtlich mit dem »vi« konfigurieren. Es ist auch bedenklich, dass der Tomcat-Server etwa 60 bis 70 Threads startet. Wenn er permanent läuft, wird die Prozesstabelle sehr unübersichtlich.

Als Pluspunkt des Rainwall-GUI ist das Versionsmanagement zu nennen: Vor jedem Überarbeiten sichert es die vollständigen Konfig-Dateien zusammen mit Datum und Uhrzeit. Zusätzlich garantiert die Oberfläche noch, dass die Konfiguration auf allen Rechnern im Cluster konsistent ist.

Härtetest: Support

Im Test traten einige Schwierigkeiten auf: Die statischen Routen ließen sich nicht setzen, die Rainwall-Lizenz verweigerte den Dienst und nach fünf Tagen war ein CPU-Lüfter defekt. Es boten sich also einige Gelegenheiten, um den Support zu testen. Im Kaufpreis ist ein 24-Monate-Rundum-Service für die Hardware inbegriffen. Es steht aber nirgends, inwieweit sich dieser Service von einer üblichen Garantieleistung unterscheidet. Das Siemens-Callcenter wusste darauf auch keine Antwort.

Insgesamt dauerte der Lüfter-Austausch drei Arbeitstage (plus Wochenende). Laut Siemens sollte das im Regelfall am nächsten Arbeitstag passieren – bei einem neu entwickelten Produkt ist diese Verzögerung noch entschuldbar. In Zukunft will der Hersteller keine einzelnen Komponenten mehr reparieren, sondern die Appliance als Ganze tauschen. Ein Grund mehr, regen Gebrauch von der Backup-Funktion des GUI zu machen (siehe Abbildung 6).

Beim Setzen der statischen Routen konnte der Support binnen 30 Minuten helfen. Wir hatten als Ziel-Interface die Option »any« eingetragen und uns zusätzlich beim Ändern der »/etc/sysconfig/static-routes« verschrieben.

Mit dem unbürokratischen Support der Firma Rainfinity gab’s durchweg gute Erfahrungen. Wer Checkpoint kennt, würde vielleicht auch bei Rainfinity mit Floskeln wie “Kaufen Sie Consulting bei unseren Partnern” rechnen. Weit gefehlt. Auch als ein Fehler beim Installieren einer Policy eindeutig auf unserer Seite lag, wurden wir noch wie Menschen behandelt.

Abbildung 6: Ein Backup wichtiger Konfigurationsdateien ist mit dem GUI der Appliance bequem erstellt.

Was bringt das Cluster?

Ohne eine Firewall kann ein aktuelles Linux-System an einem 100 MBit/s schnellen Full-Duplex-Ethernet die vollen 100 MBit/s weiterleiten. Mit der aktiven Firewall-1 bleiben davon erfahrungsgemäß 50 bis 70 Prozent übrig. Die Zahl der Regeln spielt bis zu etwa 250 Einträgen keine Rolle.

Durch Clustering kann sich dieser Wert verbessern, zwei parallel arbeitende Firewalls schaffen mehr Durchsatz als eine einzelne. Bei symmetrischem Routing wirkt sich das auf eine einzelne Verbindung nicht aus, da alle Pakete denselben Weg gehen. Damit konnten wir etwa 70 MBit/s für eine Sitzung messen. Bei zwei gleichzeitigen Sessions stieg der Gesamtdurchsatz auf 140 MBit/s, das Cluster zeigte Wirkung. Die Netzlast erzeugten wir mit Veritas Netbackup.

Bei asymmetrischem Routing wirkt sich das Cluster auch auf eine einzelne Verbindung aus, da alle Pakete auf beide Firewalls verteilt werden. Eine einzelne Session erreichte bereits 140 MBit/s.

Fazit

Während des gesamten Tests lief das Firewall-Cluster absolut stabil. Für 7300 Euro erhält man bei Siemens mit 4 Your Safety eine professionelle, Cluster-fähige Firewall-Lösung. Bei der gebotenen Leistung ist die Appliance verhältnismäßig günstig. (fjl)