Der Firewall-I verfügt über ausgiebige Logging-Möglichkeiten. Folgende Ereignisse werden vom FW-I mitgeloggt:
Hierbei handelt es sich z. B. um die Veränderung oder Neuinstallation von Regeln auf einem der packet filter modules.
Auf sämtliche eintreffenden Pakete werden die vom Administrator angegebenen Regeln angewandt. Zu jeder Regel kann mitangegeben werden, ob ein Paket, das aufgrund dieser Regel transportiert oder verworfen wurde, einen Eintrag im Log-File verursachen soll oder nicht. Die Log-Einträge verfügen über alle wichtigen Informationen mit folgenden Ausnahmen:
Es wäre wünschenswert zu wissen, aufgrund welcher Regel das jeweilige Paket transportiert oder verworfen wurde. Dies ist leider in der derzeitigen Version nicht möglich.
Die Anzahl der übertragenen Bytes wäre wichtig, um die Log-Einträge gleichzeitig im Rahmen des Accounting einsetzen zu können.
Leider werden sämtliche Pakete unabhängig voneinander geloggt, anstatt einen Eintrag bei Beginn der Verbindung und einen Eintrag bei Verbindungsende zu erzeugen. Dies würde einerseits die Anzahl der Einträge deutlich verringern, andererseits die Übersichtlichkeit der Log-Files erhöhen.
Zur Betrachtung der Log-Files steht der sogenannte Log Viewer zur Verfügung, mit dessen Hilfe die Log-Einträge sehr übersichtlich angezeigt werden können. Verwendung des Log Viewers bietet folgende Vorteile:
Der Log Viewer stellt verworfene Pakete in rot, weitertransportierte Pakete in grün und Kontroll-Operationen in grau dar. Somit wird es für einen menschlichen Betrachter einfacher, die jeweils relevanten Informationen zu erkennen.
Es besteht die Möglichkeit, nur die Informationen anzeigen zu lassen, die für die jeweilige Betrachtung relevant erscheinen. Bei der großen Menge an Informationen ist dies natürlich für den Betrachter ein angenehmer Vorteil, da er nicht durch nicht-relevante Informationen gestört wird.
Der Log Viewer verfügt über die Möglichkeit, daß Log-File nach bestimmten Kriterien zu durchsuchen. Gibt man einen Zeitraum an, in dem gesucht werden soll, sowie Kriterien, die auf die zu suchenden Pakete zutreffen sollen, so bekommt man sämtliche zutreffenden Einträge geliefert.
Da aufeinanderfolgende Log-Einträge, die sich nur in Datum und Uhrzeit unterscheiden, dem Betrachter keinerlei neue Informationen liefern, da sie offensichtlich zu ein und derselben Verbindung gehören, können diese verborgen werden, um die Übersichtlichkeit des betrachteten Log-Files zu erhöhen.
Auch im Bereich des Alerting stehen umfangreiche Möglichkeiten zur Verfügung. Wiederum kann bei jeder Regel angegeben werden, ob eine Benachrichtigung bei Ausführung dieser Regel durchgeführt werden soll oder nicht. Ist dies der Fall, so existieren folgende Möglichkeiten:
In der hier untersuchten Version 1.0 bietet der Firewall keine Authentifikationsmöglichkeiten, die eine Nutzung interner server für externe Benutzer zulassen würden. Für die Version 1.2 ist allerdings die Integration folgender Produkte angekündigt:
Man kann dann beim Aufstellen der Regeln für einen bestimmten Dienst angeben, nach welcher Methode der Benutzer authentifiziert werden soll. Trifft dann ein Paket ein, das zur Eröffnung einer entsprechenden Verbindung geeignet ist, so wird zuerst eine Authentifikation des Benutzers durchgeführt, bevor das Paket weitergeleitet wird. Die Authentifikation durch den eigentlichen server bleibt hiervon unberührt. Zusätzlich zur Sicherung über die genannten one-time password-Mechanismen kann auch eine Authentifizierung über Standard-UNIX-Paßworte erfolgen.
Über die Anfälligkeit der Software für Fehler lassen sich keine genauen Aussagen machen. Man kann aber sagen, daß es sich um neuentwickelte Software handelt, wobei natürlich Wert auf Fehlerfreiheit gelegt wurde, was bei Verwendung von Standard-Software nicht unbedingt gesagt ist. Insbesondere ist der Firewall nicht von sendmail abhängig, was ihn anderen Firewalls gegenüber deutlich sicherer erscheinen läßt.
Das control module des Firewalls befindet sich üblicherweise auf der Workstation des Firewall-Verantwortlichen. Normale Benutzer haben hierfür normalerweise keine Accounts. Die packet filter modules befinden sich hingegen zum Teil auf Rechnern, auf denen auch normale Benutzer über Accounts verfügen. Da Änderungen an der Konfiguration aber nur vom control module aus vorgenommen werden können, besteht hier keine Gefahr.
Es besteht die Möglichkeit, mehrere packet-filter modules einzusetzen und somit einzelne Subnetze oder Rechner gesondert zu schützen. Selbst wenn dann ein Einbruch in einen anderen Rechner geglückt sein sollte, ist der zusätzlich geschützte Rechner weiterhin sicher.
Eine Bildung von Prüfsummen über die Konfigurationsfiles ist nicht vorgesehen.
Die Workstation, auf der das control module läuft, läßt sich ganz normal über das Netz erreichen. Die Verbindung zwischen control module und packet filter modules wird alledings über ein one-time password-Schema abgesichert, sodaß kein Angreifer die Möglichkeit hat, die Konfiguration eines packet filter modules zu verändern, indem er sich für das control module ausgibt.
Der Sun Firewall besitzt in der derzeitigen Version 1.0 keine Möglichkeit, die Adressen des internen Netzes nach außen hin zu verbergen. Stattdessen werden Anfragen zu oder von einem name server explizit gestattet. Die Version 1.2 ermöglicht das Verbergen der internen Adressen bei von innen initiierten Verbindungen, indem die Adresse des Firewalls als Absenderadresse eingetragen wird. Die Zuordnung der Antwortpakete zu der entsprechenden Verbindung erfolgt mit Hilfe unterschiedlicher Portnummern. Darüberhinaus kann der Firewall auch eine Adreßumsetzung durchführen, wenn intern keine offiziellen IP-Adressen verwendet werden, der Aufwand einer Umkonfiguration aber zu groß wäre. Mit Hilfe einer Tabelle wird hier jedem internen Rechner eine offizielle Adresse zugeordnet, sodaß bei Verbindungen mit dem externen Netz diese Adresse als Absender bzw. Ziel eingetragen werden kann.
Die Installation des Firewall-I bereitet keine Probleme und kann innerhalb weniger Minuten erfolgen.
Die Konfiguration ist ebenfalls relativ einfach, kann aber speziell bei größeren Netzen einige Zeit in Anspruch nehmen. Es existiert eine graphische Benutzeroberfläche, die die Konfiguration wesentlich erleichtert. Für die Konfiguration sind die folgenden drei Fenster relevant:
Mit Hilfe des Network Object Managers definiert man die Objekte, die bei der Aufstellung der Regeln verwendet werden sollen. Dies können Hosts, Gateways, Router oder ganze Subnetze sein. Man kann hierarchische Gruppen von Objekten bilden, um leichter verständliche Regeln zu ermöglichen. Für jedes Objekt müssen Daten wie z. B. Name, Adresse und angeschlossene Interfaces angegeben werden. Verfügt das Objekt über einen SNMP-Agenten, so können einige Informationen über diesen beschafft werden, um die Konfiguration zu vereinfachen.
Als nächstes müssen mit dem Services Manager sämtliche verwendeten Dienste beschrieben werden. Die Standard-Dienste sind bereits enthalten, sodaß nur einige wenige Dienste konfiguriert werden müssen. Hier muß man z. B. den Namen und den Port des Dienstes angeben. Der FW-I versucht aufgrund des Namens, weitere Informationen wie die Portnummer aus Systemfiles wie /etc/services oder über NIS zu ermitteln, um die Konfiguration zu vereinfachen.
Mit dem Rule Base Editor werden die Filterregeln festgelegt, die auf den verschiedenen packet filter modules installiert werden sollen. Hierzu gibt man jeweils eines der mit dem Network Object Manager definierten Objekte als Quell- bzw. Zieladresse an, sowie einen mit dem Services Manager definierten Dienst. Weiterhin muß nur noch eine Aktion festgelegt werden, die mit einem entsprechendem Paket ausgeführt werden soll, also ob es transportiert oder verworfen werden soll. Die verbleibenden Einstellungen dienen dazu, festzulegen ob ein Log-Eintrag angefertigt werden soll, wenn die Regel auf ein Paket zutrifft, sowie um zu bestimmen, in welchem der packet filter modules die Regel aktiviert werden soll.
Nachdem die Filterregeln definiert wurden, können sie in den entsprechenden packet filter modules bzw. Routern installiert werden. Bevor dies geschieht wird die Konsistenz der Regeln durch den Firewall überprüft, um so bereits einen ersten Schutz vor Fehlkonfigurationen zu erhalten.
Im Kaufpreis sind drei Updates sowie der technische Support für die ersten drei Monate enthalten [Farrow92]. Danach sind für den Support pro Jahr 20% des Kaufpreises des Firewalls zu entrichten.
Die Dokumentation ist leicht verständlich und beschreibt die Installation und Konfiguration des Firewalls sehr gut. Das Testen der installierten Filterregeln bzw. die Erstellung sinnvoller Filterregeln wird aber überhaupt nicht behandelt, sodaß der Verantwortliche bereits über ausgiebige Erfahrung in der Erstellung von Filteregeln verfügen sollte.
Der FW-I verfügt über zwei Arten von SNMP-Unterstützung. Zum einen kann er, wie bereits erwähnt, bei der Definition der im Netz enthaltenen Objekte gewisse Informationen über den SNMP-Agenten des jeweiligen Objektes einholen, zum anderen besitzt er selber einen SNMP-Agenten, der es ermöglicht, Status-Informationen über eine Managementanwendung abzufragen.
Die Integration von proprietären bzw. neuen Diensten stellt keinerlei Problem dar, da mit Hilfe des Services Managers die Eigenschaften dieser Dienste beschrieben werden können, woraufhin sie beliebig in Filteregeln verwendet werden können. Die Integration eines weiteren Dienstes ist innerhalb kürzester Zeit zu realisieren.
Der Firewall-I ist sowohl für die Benutzer als auch für die Anwendungen völlig transparent. Die Pakete werden weiterhin an die tatsächliche Zieladresse adressiert und werden nur auf dem Weg dorthin einer eingehenden Untersuchung unterzogen. Somit ist weder eine Änderung der verwendeten client-Software erforderlich, noch müssen sich die Benutzer auf neue Arbeitsgewohnheiten einstellen. Selbsverständlich kann bei zusätzlicher Authentifizierung eines Benutzers in der Version 1.2 die Transparenz nicht völlig aufrechterhalten werden.
Ein Performance-Test einer Computerzeitschrift konnte keine Einbußen der Performance bei Verwendung des Sun FW-I feststellen [Farrow92].
Je nachdem, ob nur die Version für kleine Netze oder das Network Security Center benötigt wird, bewegen sich die Preise zwischen $9900 und $39900.
Der Sun Firewall läuft auf Sun SPARC oder x86-basierenden Systemen mit dem Betriebssystem SunOS 4.1.3 oder Solaris 2.3. Der für das control module eingesetzte Rechner muß über mindestens 16MB Hauptspeicher verfügen, während die Rechner für die packet filter modules keine bestimmten Voraussetzungen erfüllen müssen. Da die Module auf bereits vorhandene Rechner bzw. Router installiert werden können, entstehen keine weiteren Kosten für Hardware-Anschaffungen.