Die Proxies erstellen einen Log-Eintrag bei jedem Versuch, eine Verbindung zum Proxy aufzubauen, egal ob sie gestattet oder zurückgewiesen wurde. Dieser Eintrag enthält z. B. folgende Informationen:
Sowohl der Name als auch die Prozeß-ID des kontaktierten Proxies wird geloggt.
Je nachdem, ob die Verbindung akzeptiert oder zurückgewiesen wird, wird hier permit oder deny eingetragen.
Hier steht sowohl der Name als auch die IP-Adresse des Rechners, der die Verbindung wünschte.
Versucht ein Benutzer nun die Verbindung zum eigentlichen Zielrechner aufzubauen, so erfolgen weitere Einträge. Der erste Eintrag gibt an, ob der Benutzer die Berechtigung zu dieser Verbindung besitzt, der zweite Eintrag gibt an, ob der Verbindungsaufbau geglückt ist oder nicht und ein dritter Eintrag wird bei Verbindungsabbau vorgenommen. Dieser enthält dann folgende Informationen:
Im Falle des Verbindungsabbaus steht als Aktion exit eingetragen.
Name und IP-Adresse des Quellrechners
Name und IP-Adresse des Zielrechners
Anzahl der übertragenen Bytes in der entsprechenden Richtung.
Wurde der Benutzer authentifiziert, so steht hier der Name des Benutzers, andernfalls noauth.
Dauer der Verbindung.
Bestimmte Proxies, wie z. B. der FTP-Proxy verfügen darüberhinaus noch über Konfigurationsmöglichkeiten, die es erlauben, bei Auftreten bestimmter Kommandos, einen Log-Eintrag zu erzeugen.
Beim TCP-Relay gestaltet sich das Logging analog zu dem der Proxies. Zusätzlich wird noch jeweils der Port angegeben, auf dem die Verbindung eintraf und zu dem die Verbindung weitergeleitet wurde. Es ist ebenfalls möglich, die Dauer und das Übertragungsvolumen der Verbindung zu erkennen.
Über das Logging des Paket-Filters lassen sich keine konkreten Aussagen machen, da es sich nicht um einen Teil des Toolkits handelt, sondern um einen beliebigen Router. Im allgemeinen verfügen Router aber nicht über ausreichende Logging-Mechanismen.
Zusätzlich werden noch besondere Ereignisse, wie z. B. jeder Authentifikationsvorgang, gleichgültig ob gelungen oder fehlgeschlagen, mitgeloggt.
Das Logging des TIS FWTK ist also gut. Insbesondere ist es möglich, ein Accounting durchzuführen, das auf den Logging-Informationen des Firewalls basiert, sofern der gesamte Verkehr durch den Firewall-Rechner läuft und nicht der Router so konfiguriert ist, daß er bestimmte Dienste gestattet, ohne einen Proxy oder das TCP-Relay zu verwenden.
Der verwendete syslogd-Daemon verfügt über Möglichkeiten, reguläre Ausdrücke zu definieren, bei deren Auftreten in einer Zeile des Log-Files ein Kommando ausgeführt werden kann. Somit kann das Log-File in Echtzeit überwacht werden und der Administrator ist in der Lage, selber zu bestimmen, bei welchen Ereignissen er benachrichtigt werden möchte und auf welche Weise dies geschehen soll.
Der TIS FWTK besitzt einen Authentifikationsserver, der von den Proxies verwendet wird, um Benutzer zu authentifizieren. Dieser server stellt derzeit folgende Möglichkeiten zur Verfügung, die Identität eines Benutzers festzustellen:
Der Authentikikationsserver verfügt über eine Schnittstelle, mit der sehr einfach Benutzer hinzugefügt oder mit einem Paßwort versehen werden können. Es existiert ebenfalls ein client, der verwendet werden kann, um die Konfiguration von einem entfernten Rechner aus durchzuführen. Hierbei wird eine Verschlüsselung des Verkehrs vorgenommen, um einem Angreifer keine Möglichkeit zu geben, Paßworte mitzuhören.
Alle Komponenten des TIS Toolkit wurden mit Blick auf die Sicherheit erstellt. Es handelt sich um sehr einfache Programme, deren Fehlerfreiheit zum Teil innerhalb kürzester Zeit zu überprüfen ist. Außerdem laufen alle Komponenten, die in direktem Kontakt zu eventuellen Angreifern stehen, in einer Umgebung, die mit chroot ein leeres Verzeichnis als root-Verzeichnis besitzt und es sind keinerlei root-Privilegien erforderlich. Man kann also davon ausgehen, daß die Software kaum Fehler enthält und wenn doch ein Fehler auftritt, daß er nur sehr schwer auszunutzen sein wird.
Es ist nicht erforderlich, User-Accounts auf dem Firewall-Rechner einzurichten.
Es sind keine Maßnahmen vorgesehen, bestimmten Rechnern oder Subnetzen einen besonderen Schutz zukommen zu lassen. Einzig die Möglichkeit, die Konfiguration so zu wählen, daß bestimmte Rechner gar keine Verbindungen aufbauen können, besteht natürlich.
Der Firewall selber enthält keine Möglichkeit, die Konfiguration mittels einer Prüfsumme zu überwachen. Bestimmte Betriebssysteme besitzen aber tools, die hierfür verwendet werden können.
Es besteht die Möglichkeit, telnet und FTP zu administrativen Zwecken zu gestatten. Hierzu steht ein Programm namens netacl zur Verfügung, das über den inetd-Daemon gestartet wird und eine Zugriffskontrolle auf Basis der IP-Adresse des Absenders durchführen kann. Somit wird es also möglich, den Zugang zu den Standard-servern nur von einigen wenigen Rechnern aus zu gestatten. Die Standard-server müssen aber auf anderen Ports laufen als normal, da die well-known ports bereits durch die Proxies belegt sind. Als Alternative bietet es sich an, netacl zu verwenden, um je nach Ursprung eines Verbindungswunsches, den Proxy oder den jeweiligen Standard-server zu starten. Der Administrator muß dann zuerst eine Verbindung zum Proxy aufbauen, von wo aus er eine Verbindung zu localhost initiiert. Trifft eine derartige Verbindung ein, so entscheidet netacl, daß der Standard-server verwendet werden soll.
Da es sich um eine reine Proxy-Lösung handelt, sollte es problemlos möglich sein, nach außen hin nichts weiter bekanntzugeben als die Adresse des Firewalls sowie Informationen zum Empfang von mail. Der domain name service wird aber in der gesamten Dokumentation nicht erwähnt.
Die Installation gestaltet sich relativ schwierig. Da der Toolkit für viele verschiedene Plattformen entwickelt wurde, sollte man über Kenntnisse in der Installation von Software mittels make verfügen. Auch sind umfangreiche Kenntnisse in der Administration eines UNIX-Systems von Vorteil, um nicht Fehler zu begehen, die wiederum Angriffsmöglichkeiten darstellen können.
Die Konfiguration erfolgt mittels eines einzigen Konfigurationsfiles, das Einträge für sämtliche Komponenten enthält. Jede Zeile des Files beginnt mit dem Namen einer Komponente, für die die jeweilige Zeile dann gültig ist. Da keine Abhängigkeiten zwischen den einzelnen Komponenten bestehen und die Syntax des Konfigurationsfiles leicht verständlich ist, ist die Gefahr, Fehler zu begehen, relativ gering.
Es handelt sich um ein kostenlos erhältliches Produkt, für das natürlich keinerlei Support besteht.
Der Firewall verfügt über eine umfangreiche Dokumentation. Hier wird die Installation und Konfiguration der wichtigsten Komponenten ausführlich beschrieben. Zusätzlich existiert zu jeder Komponente eine manpage, sodaß die wichtigsten Informationen auch online zur Verfügung stehen.
Einige Programme, wie z. B. das x-gw sind aber zu knapp beschrieben, sodaß eine Installation und Konfiguration sehr erschwert wird. Auch fehlen Informationen über die Konfiguration des domain name service völlig. Wünschenswert wäre es auch noch gewesen, wenn das Testen der Konfiguration auf richtige Funktion in der Dokumentation besser behandelt worden wäre.
Da es aber ohnehin unumgänglich ist, daß ein Betreiber des TIS Toolkit über ausgiebige UNIX-Erfahrung verfügt, ist die Dokumentation durchaus angemessen.
Es besteht keinerlei SNMP-Unterstützung.
Dienste, die über das TCP-Relay zu sichern sind, stellen keinerlei Problem dar, während die anderen Dienste gewisse Schwierigkeiten bereiten können. Mit Hilfe des Paket-Filters ist es natürlich möglich, fast alle Dienste zu sichern, man verzichtet aber auf Logging-Möglichkeiten und die Möglichkeit des Zugangs von außen.
Die beste Möglichkeit wäre natürlich die Entwicklung weiterer Proxies. Für neue Standard-Dienste ist davon auszugehen, daß innerhalb relativ kurzer Zeit Proxies entwickelt werden, die diesen Dienst absichern können, während bei proprietären Diensten die Entwicklung des Proxies selber übernommen werden muß. Hierzu steht eine Bibliothek von C-Funktionen zur Verfügung, mit denen der Authentifikationsserver problemlos angesprochen werden kann. Es dürfte also keine größeren Probleme bereiten, einfache Dienste mit einem Proxy zu versehen.
Der TIS FWTK wurde so entwickelt, daß keine Änderungen an den client-Programmen erforderlich sind. Dies bedeutet aber, daß die Benutzer in Kauf nehmen müssen, ihre Gewohnheiten zu ändern, da meist ein zweistufiger Verbindungsaufbau erforderlich ist [TIS94a]. Der HTTP-Proxy erfordert trotzdem noch leichte Änderungen an der Konfiguration der clients.
Über die Performance des TIS Toolkit sind keine Informationen vorhanden.
Der TIS Toolkit ist kostenlos über anonymous ftp von ftp.tis.com im Verzeichnis pub/firewalls/toolkit erhältlich.
Es ist keine spezielle Hardware erforderlich. Der Firewall kann auf vielen unterschiedlichen Plattformen installiert werden. Natürlich ist ein dedizierter Rechner notwendig, der ausschließlich den Firewall enthält. Sinnvoll ist auch noch die Verwendung eines Routers, um Pakete, die z. B. die source-routing Option verwenden abzublocken.