Trügerische Sicherheit

25.10.2002
Internetverbindungen, die das HTTPS-Protokoll (Hypertext Transfer Protcocol Secure Socket) verwenden, gelten als sicher. Das ist ein Trugschluss. Denn auch verschlüsselte Inhalte können Viren oder "Malicious Code" enthalten. Nur mithilfe spezieller Content-Scanner lassen sich solche Angriffe abwehren.

Von: Andreas Baumhoff, Bernd Reder

Angriff auf Unternehmensnetze werden immer häufiger mithilfe "verseuchter" Inhalte durchgeführt. Das können E-Mails mit Dateianhängen sein, die Viren enthalten, aber auch Programme, in die ein Hacker ein Trojanisches Pferd eingeschleust hat. Um solchen Angriffen vorzubeugen, setzten Netzwerkverwalter in der Regel Software ein, die den HTTP- oder FTP-Verkehr untersucht. Bekannte Hersteller von Programmen, die "Content" scannen, sind beispielsweise Symantec, Finjan oder Trend Micro. Doch zwei Trends erschweren es solchen Produkten, Angriffen auf die Spur zu kommen: das "Tunneling" von Verbindungen und der verstärkte Einsatz von Verschlüsselung mittels Se-cure Socker Layer (SSL) und Transport Layer Security (TLS).

Häufig ist es gängige Praxis, den Port 443, der für Datentransfers mithilfe von "Hypertext Transfer Protocol Secure Socket" (HTTPS) vorgesehen ist, einfach zu "tunneln", um eine verschlüsselte Kommunikation zu erlauben. "Tunneling" bedeutet, dass Protokolle und Datenverbindungen in einen HTTP-Request verpackt werden. Auf diese Weise können sie den HTTP-Standardport 80 nutzen. Ein Beispiel ist Microsofts RPC (Remote Proce-dure Call). Normalerweise fängt eine Firewall RPC-Requests ab. Bei der .NET-Architektur werden jedoch RPC-Calls über HTTP transportiert, wenn sie mit Servern außerhalb des Firmennetzes kommunizieren. Der zweite Faktor, der die Content Inspection erschwert, ist die Kommunikation via SSL und TLS. Sie beginnt mit einem "Handshake" zwischen Client und Server. Anschließend wird der Datenstrom mit dem privaten Schlüssel (Private Key) eines der beiden Systeme verschlüsselt. Daher ist es für ein Content-Scanning-System nicht möglich, die Daten auf Viren hin zu untersuchen. Um dieses Problem zu lösen, gibt es drei Alternativen:

- alle Inhalte zu blockieren, die mithilfe von SSL oder TLS verschlüsselt wurden. Das hätte zur Folge, dass alle Passwörter oder Kreditkartennummern unverschlüsselt über das Internet transportiert werden müssten. Das ist natürlich aus Sicherheitsgründen nicht machbar;

- die Firewall so zu konfigurieren, dass sie den Content passieren lässt: Dann könnte Malicious Code ins lokale Netz oder Intranet gelangen;

- die Inhalte von Antiviren- oder Sandbox-Software analysieren zu lassen, die auf den Arbeitsplatzsystemen installiert ist. Die Folge sind höhere Kosten durch die Lizenzgebühren und das Systemmanagement.

Es fehlt somit ein Verfahren, das verschlüsselten Internet-Verkehr überprüft, wobei die vorhandenen Gateway-Scanner weiterhin Verwendung finden können. Als erster Anbieter, so zumindest das Unternehmen, hat Microdasys mit dem "Secured Content Inspection Proxy" (Scip) eine solche Lösung entwickelt. Scip dekodiert die verschlüsselten Daten und stellt sie den Scannern zur Verfügung. Sind die Datenpakete "sauber", werden sie erneut verschlüsselt und anschließend weitertransportiert.

Überprüfung in Echtzeit

Der Prüfvorgang läuft in Echtzeit ab, sodass keine spürbaren Verzögerungen im Netz auftreten. Außerdem bleibt die Vertraulichkeit der Daten gewahrt, weil Scip zwar den Content-Scanner in die Lage versetzt, die Inhalte zu prüfen, diese aber nicht öffentlich zugänglich macht. So lässt sich eine weitere Sicherheitslücke schließen. Sie entsteht dann, wenn Firewall-Systemen eine verschlüsselte Kommunikation vorgegaukelt wird, auch wenn diese gar nicht stattfindet. Das soll den Zugriff auf Rechner und Ports ermöglichen, die normalerweise gesperrt sind. Diese SSL-Connect-Methode verwendet unter anderem der AOL-Instant-Messenger.

Das schwächste Glied in der Sicherheitskette ist die unzureichende Überprüfung der digitalen Zertifikate, die als Beleg für die "wahre" Identität eines Webservers dienen. Die meisten Web-Browser verfügen über eine vorgegebene Liste mit vertrauenswürdigen "Certificate Authorities" (CA). Der Internet Explorer beispielsweise vertraut sage und schreibe 109 solcher CA. Alle Zertifikate einer solchen Zertifizierungsstelle werden ohne explizite Meldung akzeptiert. Ein Benutzer kann selbst dann eine verschlüsselte Verbindung zum betreffenden Webserver aufbauen, wenn ein Zertifikat abgelaufen ist oder manipuliert wurde. Nur wenige Zertifizierungsstellen bauen in ihre Certificates einen Link ein, der auf die "Certificate Revocation List" (CRL) verweist. Sie enthält die Seriennummern von Certificates, außerdem das Datum, an dem sie für ungültig erklärt wurden. Anhand dieser Listen können Clients, etwa Web-Browser, automatisch den Status eines Zertifikats überprüfen.

Der einzige Ausweg besteht darin, eine zentrale Instanz einzurichten - eine so genannte "Enterprise Validation Authority" (EVA). Sie überwacht den Aufbau einer verschlüsselten Verbindung und lässt nur solche zu, die den firmeneigenen Sicherheitsrichtlinien entsprechen (zu EVA siehe den Kasten auf Seite 16). Der Scip-Proxy ist in der Lage, die Rolle einer solchen Enterprise Validation Authority zu übernehmen und Zertifikate daraufhin zu überprüfen, ob sie noch gültig sind. Das System greift dazu auf die Certificate Revocation List (CRL) zurück. Zusätzlich unterstützt Scip das "Online Certificate Status Protocol" (OCSP), über das ein Client online bei einer Zertifizierungsstelle anfragen kann, ob ein Zertifikat in Ordnung ist. OSCP ist allerdings noch relativ neu, deshalb wird es derzeit von wenigen CA unterstützt. Die Informationen, die es bei den Abfragen über den Status von Zertifikaten erhält, legt Scip in einer eigenen lokalen Datenbank ab.

Desktop-Lösungen sind teurer

Zum Abschluss noch ein Blick auf die "Total Cost of Owner-ship" (TCO), die bei Scip anfallen. In einem White Paper, dem die amerikanischen Listenpreise vom Februar zu Grunde liegen, beziffert Microdasys die Kosten von Scip für ein Netz mit 1000 Usern auf 41 000 Dollar über einen Zeitraum von drei Jahren. Sandbox-Systeme, die an jedem Arbeitsplatz installiert werden, sind etwa fünf Mal so teuer, und für Desktop-Antivirenprogramme muss der Anwender rund 150 000 Dollar veranschlagen. Sowohl die Installation der Programme als auch Wartung, Support und das Management seien deutlich aufwändiger als beim Proxy von Microdasys.

Zur Person

Andreas Baumhoff

ist Corporate Communications Manager bei Microdasys.