Der Firewall bietet ausgiebige Logging-Möglichkeiten. Auf jedem der drei beteiligten Rechner werden sämtliche interessanten Ereignisse geloggt. Dies umfaßt jede Verbindung zum Firewall, wiederholte Fehlversuche beim login, sämtliche übertragene mail sowie die Benutzung der Proxies und des TCP-Relays. Hierzu wird eine veränderte Version des syslog-Programms verwendet, daß zusätzlich noch alle Log-Einträge von gate und gatekeeper an mailgate weiterleitet. Da mailgate innerhalb des sicheren Netzes liegt, ist es sehr schwierig für einen Angreifer, nach einem geglückten Angriff auf einen der beiden anderen Rechner, die Log-Einträge zu verändern und somit seine Spuren zu verwischen.
Auf mailgate werden die Einträge nach ihrem Typ sortiert, also es werden getrennte Files z. B. für alle mail-Transaktionen oder für alle FTP-Verbindungen angelegt. Außerdem besteht die Möglichkeit, in regelmäßigen Abständen eine Zusammenfassung der Logs zu erzeugen, die dann längerfristige Aussagen über die Nutzung des Firewalls erlaubt.
Der Administrator kann reguläre Ausdrücke definieren, bei deren Auftreten in einem Log-Eintrag, er den gesamten Eintrag in einer mail zugestellt bekommen möchte. Somit kann genau festgelegt werden, welche Ereignisse zu einem Alert führen sollen und welche nicht.
Darüberhinaus enthält natürlich SOCKS die Möglichkeit, wie bereits mehrfach erwähnt, zu jeder Filterregel ein Kommando zu definieren, das bei deren Anwendung ausgeführt werden soll.
Die Proxies für telnet und FTP stellen die folgenden Authentifikationsmöglichkeiten zur Verfügung:
Mit Hilfe dieser Authentifikation ist es möglich, auch Verbindungswünsche von außen zu gestatten, ohne daß ein Angreifer die Möglichkeit hat, mitgehörte Paßwörter zu Angriffen einzusetzen.
Aussagen über die Fehlerfreiheit der Firewall-Software gestalten sich relativ schwierig, da die Untersuchung des Firewalls sich, wie bereits erwähnt, nur auf Informationen stützen kann, die von der Firma DEC zur Verfügung gestellt werden. Ein Test des Firewalls konnte leider nicht durchgeführt werden.
Der Firewall verwendet zu großen Teilen Standard-Software, die gewisse funktionelle Erweiterungen erfahren hat, sodaß sie den Ansprüchen eines Firewalls gerecht werden kann. Dies deutet aber normalerweise auf eine erhöhte Anfälligkeit für Fehler hin, da Standard-Software sehr stark von Angreifern auf mögliche Fehler untersucht wird und häufig auch nicht mit besonderem Augenmerk auf die Sicherheit entwickelt wurde. Die Proxies hingegen sind neuentwickelte Programme, die demnach relativ sicher vor Fehlern sein sollten, die von Angreifern ausgenutzt werden können.
Der DEC SEAL erfordert es nicht, daß für Benutzer, die Firewall-Dienste nutzen wollen, Accounts auf dem Firewall eingerichtet werden. Einzig administrative Accounts sind notwendig, wobei natürlich davon auszugehen ist, daß für diese Accounts hinreichend sichere Paßworte gewählt werden.
Da der Paket-Filter dazu dient, jeden Verkehr zwischen dem internen und dem externen Netz zu verbieten und nur Verkehr vom sicheren Netz zu gatekeeper und umgekehrt zu ermöglichen, ist es relativ leicht, diesen so zu konfigurieren, daß gewisse Rechner oder Subnetze des internen Netzes überhaupt keine Kommunikation mit dem unsicheren Netz führen können. Diese Rechner sind allerdings trotzdem von internen Rechnern aus ungehindert angreifbar. Wenn also ein Einbruch auf einen internen Rechner geglückt ist, so genießt auch ein derartig gesicherter Rechner keinen besonderen Schutz mehr.
Der DEC Firewall verfügt über keinerlei Möglichkeiten, die Konfiguratonsfiles auf nichtautorisierte Veränderungen zu überprüfen.
Um den Zugang über das Netz zu ermöglichen, ohne gleichzeitig Angreifern die Möglichkeit zu Einbrüchen zu geben, existiert das Programm netaccess. Es handelt sich um eine Erweiterung des inetd-Daemons und kann, bevor es den entsprechenden server startet, überprüfen, ob der Rechner, von dem der Verbindungswunsch stammt, autorisiert ist, Verbindungen zum Firewall aufzubauen. Es können sogar unterschiedliche server gestartet werden, je nachdem, von welchem Rechner aus die Verbindung initiiert wurde. Das ermöglicht es, nur bestimmten Rechnern den telnet-Zugang zu gestatten und allen anderen eine Nachricht zu präsentieren, daß eine Verbindung zum Firewall untersagt ist.
Weiterhin erlaubt das netaccess-Programm, daß jeder Verbindungswunsch, gleichgültig ob er gestattet oder zurückgewiesen wurde, einen Eintrag im Log-File verursacht. Somit kann niemand unbemerkt Zugang zum Firewall erlangen.
Es besteht die Möglichkeit der Zweiteilung des name service. Gatekeeper agiert als name server für das externe Netz, während mailgate diese Aufgabe für das interne Netz erfüllt. Mailgate wird so konfiguriert, daß es Anfragen, die es nicht selber beantworten kann, an gatekeeper weiterleitet, der wiederum die Möglichkeit hat, sämtliche name server des externen Netzes zu kontaktieren. Umgekehrt darf gatekeeper natürlich keine Anfragen an mailgate weiterleiten, um die Adressen des internen Netzes geheim zu halten. Gatekeeper selber ist natürlich in der Lage, Adressen des internen Netzes von mailgate zu erfahren, da er ja ungehindert durch den Paket-Filter mit allen internen Rechnern kommunizieren kann.
Die Installation des Firewalls gestaltet sich relativ umständlich. Es ist erforderlich jede Firewall Komponente einzeln zu installieren, wobei natürlich bereits Fehler passieren können.
Die Konfiguration gestaltet sich ähnlich umstänlich. Da keinerlei Hilfsmittel wie z. B. eine graphische Benutzeroberfläche zur Verfügung stehen, muß die Konfiguration über das manuelle Editieren von Konfigurationsfiles erfolgen. Auch hier verbergen sich natürlich Gefahren, da die Unübersichtlichkeit eines derartigen Files relativ schnell zu kleinen Fehlern führen kann, die aber große Wirkungen auslösen können.
Um den technischen Support der Firma DEC zu erhalten, ist es erforderlich, einen speziellen Vertrag abzuschließen. Die Kosten hierfür belaufen sich auf 328 DM/Monat.
Der DEC SEAL verfügt über sehr umfangreiche Dokumentation, die die Installation und Konfiguration jeder Komponente detailliert beschreibt. Somit dürfte es für einen erfahrenen UNIX-Administrator kein Problem sein, den Firewall trotz der umständlichen und fehleranfälligen Konfiguration einzurichten.
Es ist keinerlei SNMP-Unterstützung enthalten.
Die Behandlung proprietärer bzw. neuer Dienste stellt ein großes Problem dar, da weder das TCP-Relay noch die Proxies hierfür problemlos eingesetzt werden können. Es wäre notwendig, entweder einen client so umzuschreiben, daß er in der Lage ist, mit der hier verwendeten Version von SOCKS zu kommunizieren oder einen Proxy zu programmieren, der die gewünschte Funktion erfüllt. Mit Hilfe eines Proxies würden sich dann auch UDP-basierende Dienste sichern lassen. Aus bereits genannten Gründen kommt ein Einsatz des Paket-Filters höchstens für peer-to-peer-Dienste in Frage.
Es handelt sich um eine nicht-transparente Lösung [DEC94b]. Zur Verwendung von SOCKS müssen die mitgelieferten clients auf sämtliche Rechner des internen Netzes verteilt werden, während die Proxy-Lösung einen Verbindungsaufbau in zwei Schritten erfordert. Erst wird der Kontakt zum Firewall hergestellt, dem man daraufhin den gewünschten Zielrechner mitteilt. Dann erst kann die Verbindung zum eigentlichen Ziel aufgebaut werden.
Da der Firewall leider nicht zu Tests zur Verfügung stand, können über die Performance kaum Aussagen gemacht werden. Zu Erwarten sind Performace-Einbußen bei starker Nutzung der Proxies, da diese jeweils den gesamten Protokollstack abarbeiten müssen.
Der DEC SEAL kostet ohne Hardware ca. 105.000 DM.
In der Maximalkonfiguration erfordert der DEC SEAL drei dedizierte Workstations, die also ausschließlich für den Firewall eingesetzt werden. Dies stellt natürlich einen erheblichen Kostenfaktor dar, weswegen auch Möglichkeiten existieren, den Firewall mit zwei oder einem Rechner zu installieren.
Die verwendeten Rechner müssen als Betriebssystem über eines der folgenden Systeme verfügen:
Aussagen über den erforderlichen Speicherausbau oder erforderliche Festplattenkapazität können leider nicht getroffen werden.