Das Logging des IBM NetSP erfolgt über das syslog-Programm. Man gibt eine Datei an, in die bis zu 512 Einträge geschrieben werden können. Wird die Zahl von 512 Einträgen überschritten, so wird als letzter Eintrag eine Zeile eingefügt, die angibt, wieviele Einträge nicht mehr geloggt werden konnten. Je nachdem, ob man Paket-Filter, TCP-Relay oder Proxy verwendet, unterscheiden sich die erzeugten Log-Files zum Teil erheblich:
Der Paket-Filter erzeugt Log-Einträge bei jeder Änderung seines Zustandes, d. h. bei Änderungen der Filterregeln oder bei Aktivierung bzw. Deaktivierung des Filters. Weiterhin ist er in der Lage, für jedes zurückgewiesene Paket einen Log-Eintrag anzulegen. Diese Einträge setzen sich z. B. aus folgenden Informationen zusammen:
Gibt an, ob das Paket bereits beim Eintreffen am Firewall oder erst bei dessen Verlassen zurückgewiesen wurde.
Gibt das Interface an, auf dem das Paket angekommen ist bzw. auf das das Paket geschrieben werden sollte.
Die Absender-Adresse und Port, wie sie im Header des zurückgewiesenen Paketes angegeben waren.
Die Zieladresse und Port, an die das Paket adressiert war.
Gibt die Nummer der Regel an, die die Zurückweisung des Paketes veranlaßt hat.
SOCKS stellt hervorragende Logging-Möglichkeiten zur Verfügung, die sogar ausreichen könnten, um die Kosten für den Internet-Anschluß auf die einzelnen Benutzer umlegen zu können. Im einzelnen werden folgende Daten zur Verfügung gestellt:
Beim Verbindungsaufbau wird ein Eintrag im Log-File vorgenommen, der den Zeitpunkt des Eintrages, die Adressen von Quell- und Zielrechner, den Benutzer sowie den verwendeten Dienst enthält.
Beim Verbindungsabbau werden zwei Zeilen im Log-File angelegt. Die erste enthält Informationen, die mit denen beim Verbindungsaufbau vergleichbar sind, während die zweite Zeile die tatsächlich in beide Richtung übertragene Anzahl von Bytes angibt.
Selbstverständlich werden auch Verbindungswünsche angezeigt, bei denen keine Verbindung zustande kam, da der entsprechende Benutzer nicht zum Aufbau einer derartigen Verbindung autorisiert war.
Das Logging der Proxies ist in der derzeitigen Version des Firewalls noch unzureichend ausgeprägt. Es wird ein Eintrag in ein Log-File vorgenommen, wenn ein Benutzer eine Verbindung aufbaut bzw. wenn ein Verbindungswunsch zurückgewiesen wird. Das Ende einer Verbindung ist allerdings nicht über das Logging erkennbar. Ebenso fehlt jegliche Angabe über das innerhalb dieser Verbindung übertragene Volumen.
Einzig der SOCKS-server enthält eine Möglichkeit, jeder Filterregel ein Kommando hinzuzufügen, das bei Eintreffen eines Paketes, das diese Regel erfüllt, ausgeführt wird. Somit lassen sich eigene Alerting-Mechanismen entwickeln, die dann vom SOCKS-server gestartet werden können. Weder der Paket-Filter noch die Proxies verfügen über derartige Möglichkeiten.
Der IBM NetSP verfügt über folgende Möglichkeiten, einen Benutzer zu authentifizieren:
Gibt man als Absender einer Mail ausführbare Kommandos an und schickt diese Mail an einen nicht existierenden Benutzer, so werden diese bei älteren Versionen ausgeführt, wenn sendmail versucht, eine Nachricht über die Unzustellbarkeit der Mail an den Absender zu übermitteln. Da sendmail unter root-Berechtigung läuft, werden auch diese Kommandos mit root-Privilegien ausgeführt.
Neuere Versionen von sendmail enthalten die Möglichkeit, die Identität des Absenders über das identd-Programm zu überprüfen. Hierzu wird eine Verbindung zum identd-Daemon des entsprechenden Rechners aufgebaut, der die Identität des Absenders bestätigen soll. Handelt es sich aber um eine gefälschte Version des identd-Programms, so kann man hier statt der Bestätigung der Identität Kommandos übergeben, die aufgrund eines Fehlers von sendmail ausgeführt werden.
Möchte man die Proxies einsetzen, so ist dies nur möglich, wenn für jeden Benutzer ein Account auf dem Firewall eingerichtet wird. Da Benutzer häufig Paßworte wählen, die keinen ausreichenden Schutz bieten, besteht hier die große Gefahr, daß ein Angreifer Zugang zum Firewall erlangt. Da die Möglichkeit besteht, den Benutzern nur Shells zu geben, die einige wenige Kommandos ausführen können, kann man hier noch relativ sicher sein, daß ein Angreifer keine Möglichkeit hat, mit einer derartigen Shell Angriffe durchzuführen. Gelingt es ihm aber, einen Account einzurichten (z. B. über einen der oben beschriebenen Fehler des sendmail-Programms), der ihm zu einer normalen Shell verhilft, so stehen ihm alle Möglichkeiten offen. Bei der großen Anzahl von Accounts, die auf dem Firewall existieren müssen, ist es denkbar, daß ein solches Eindringen über lange Zeit unbemerkt bleibt.
Der IBM Firewall verfügt über keine Möglichkeit, bestimmte server oder Subnetze speziell zu schützen. Bei Verwendung des TCP-Relays oder des Paket-Filters ist es natürlich möglich, mit Hilfe der entsprechenden Filterregeln, den Zugang von und zu bestimmten Adressen völlig zu verbieten.
Der IBM Firewall stellt keine Möglichkeiten zur Verfügung, die Konfigurationsfiles auf Veränderungen hin zu überwachen. Allerdings verfügt das AIX-Betriebssystem über tools, die eine Überwachung dieser Dateien ermöglichen.
Der Firewall gestattet ein Einloggen als root über das Netz mit selbst konfigurierbaren Authentifikationsmöglichkeiten. Hier sollte unbedingt ein sicheres Authentifikationsschema verwendet werden, um einem Angreifer nicht die Möglichkeit zu geben, über das Netz die Konfiguration des Firewalls zu ändern.
Der IBM NetSP bietet eine Zweiteilung des Domain Name Service an, wobei der externe Name Server vom Firewall selber erstellt wird, während der interne Server natürlich vom Betreiber konfiguriert werden muß. Externe Hosts haben somit nicht die Möglichkeit, Adressen interner Rechner zu erfahren, interne hingegen haben Kenntnis über alle externen Rechner.
Zur Installation und Konfiguration des Firewalls bieten sich zwei unterschiedliche Möglichkeiten an: Einerseits kann er mit Hilfe des System Maintenance and Installation Tool (SMIT) des IBM-Betriebssystems AIX/6000 konfiguriert werden. Es handelt sich hierbei um eine Benutzeroberfläche, die menügesteuert die Installation und Konfiguration vornimmt. Andererseits steht eine Kommandosprache zur Verfügung, die eine schnellere Konfiguration erlaubt, allerdings schwierig zu lernen und weniger komfortabel in der Benutzung ist.
Die Installation gestaltet sich schnell und einfach. Nach einigen wenigen Eingaben wie z. B. dem Laufwerk, von dem aus installiert werden soll, findet die gesamte Installationsprozedur automatisch statt. Dies findet in weniger als fünf Minuten statt. Nach der Installation ist ein Reboot der Firewall-Machine notwendig.
Ähnlich verhält es sich mit der Konfiguration. Probleme ergeben sich nur bei der Konfiguration der Proxies, da bei deren Verwendung für jeden berechtigten Benutzer ein Account eingerichtet werden muß. Der hieraus resultierende Aufwand ist bei Größenordnungen von mehreren tausend Benutzern nicht tragbar, sodaß eine Verwendung der Proxies nur für einige wenige Benutzer, die Zugang von außen benötigen, in Frage kommt.
Im Kaufpreis des Firewalls ist der Support für das erste Jahr enthalten. Danach muß ein entsprechender Wartungsvertrag geschlossen werden, über dessen Konditionen aber keine Informationen vorliegen.
Die Dokumentation ist ausreichend, um die Installation und Konfiguration des Firewalls selbstständig vornehmen zu können. Auch ist ein eigenes Kapitel dem Testen der erstellten Konfiguration gewidmet.
Ein SNMP-Agent ist im IBM Firewall weder vorhanden noch für zukünftige Versionen geplant.
Durch die Verwendung von SOCKS und des Paket-Filters, stehen zwei allgemeine Hilfsmittel zur Verfügung, mit denen weitere Dienste in den Firewall integriert werden können. Außerdem besteht die Möglichkeit, clients auf dem Firewall zu installieren, die dann über den telnet-Proxy benutzt werden können. Hierzu muß sich ein Benutzer über telnet in den Firewall einloggen und dort den entsprechenden client starten. Da Benutzer nur über eine eingeschränkte shell verfügen, muß die shell natürlich noch dahingehend geändert werden, daß der Start des clients ermöglicht wird.
Mit Ausnahme des Paket-Filters handelt es sich um eine nicht-transparente Lösung. Bei der Verwendung von SOCKS müssen Änderungen an sämtlichen client-Programmen vorgenommen werden, was bei einem Netz mit einer fünfstelligen Anzahl von Endgeräten große Probleme bereiten kann. Die Proxies sind natürlich ebensowenig transparent, da sie einen echten zweistufigen Verbindungsaufbau erfordern.
Im Testbetrieb bei der BMW AG traten keine Beinträchtigungen der Performance durch den Firewall auf.
Die NetSP-Software ist zu einem Preis von ca. 30.000 DM erhältlich.
Für den IBM NetSP benötigt man eine Workstation vom Typ IBM RS/6000 mit dem IBM-Betriebssystem AIX 3.2.5. Die Workstation sollte über mindestens 32 MB Hauptspeicher verfügen und benötigt mindestens zwei Netz-Interfaces, um Anschlüsse zum sicheren und zum unsicheren Netz realisieren zu können.