Standortwechsel

Die Diskussion IPsec versus SSL bei Zugriffen mobiler User auf die Firmenzentrale war in Wahrheit überhaupt keine. Denn die Vorteile des browsergestützten Verfahrens waren von Beginn an so überzeugend, dass IPsec und seine Desktop-Clients immer stärker in eine Nebenrolle gedrängt wurden. Ohne Frage hat IPsec bei Site-to-Site-Kopplungen seine Stellung behauptet, trotz der Anstrengungen namhafter Carrier und Internet-Service-Provider, diesen Dienst durch eigene MPLS-VPN-Services zu ersetzen.

Beim Remote-Access mobiler User dagegen spielt SSL seinen starken Trumpf aus: Die Betriebskosten seien niedriger als bei IPsec-VPNs, so die Hersteller. Denn eine separate Client-Software sei konzeptionell nicht nötig, da der Browser SSL standardmäßig beherrscht und jede Datei mit dem 128 Bit starken Chiffrierverfahren AES verfälscht. Network-Address-Translation (NAT) wirkt sich auf die Funktionsweise ebenfalls nicht aus, da sich SSL lediglich auf die Payload zwischen Sender und Empfänger konzentriert. Anders als IPsec kann das SSL-Verfahren mit modifizieren IP-Adressen wunderbar leben, da es netzwerkrelevante Parameter bei seiner Authentifizierung schlicht ignoriert.

Wer das einfache VPN allerdings in einem heterogenen Netzwerk einsetzen will, muss sehr wohl einige Dinge beachten. Denn so einfach, wie es die Hersteller versprechen, sind Konfiguration und spätere Verwaltung keineswegs. Außerdem sollten sich Anwender auf Dauer davon verabschieden, gänzlich auf einen Client verzichten zu dürfen. Denn schon bei dem klassischen Remote-Access-Einsatzfall laden die Hersteller heute kleine Plugins auf den Desktop. Bei komplexeren Konzepten wie den Gesundheitschecks in Network-Access-Control-Konzepten ist es ohnehin zwangsläufig erforderlich, aktiven Code auf den Host zu laden. Aber gerade hier und auf dem Gebiet der VoIP-Verschlüsselung könnte die SSL-Technik größere Bedeutung erlangen.

Versprechen nicht gehalten
Die SSL-Lobby behauptet, der Endanwender könne gänzlich auf einen Client verzichten. Er brauche nur seinen Browser. Kompatibilitätsprobleme auf dem Host seien damit per se ausgeschlossen. Die Realität gerade in bunt gemischten Netzen mit zahlreichen Windows-Spielarten, Macintosh-Systemen und exotischen Browsern zeichnet ein anderes Bild.

Natürlich beherrscht jedes Produkt auf dem Markt Windows-XP/2000-Maschinen und den dazugehörigen Internet-Explorer souverän. Auch Mozilla-Firefox wird von den Anbietern unterstützt. Das Login kann aber ohne, dass der Browser erweitert wird, den User lediglich per Passwort und Weblogin identifizieren. Damit er weiterhin sein Zweifaktor-Authentifizierungssystem nutzen kann, haben die Hersteller so genannte Network-Extension-Clients entwickelt – und damit gegen ihr eigenes Prinzip verstoßen, gänzlich auf Host-Programme zu verzichten.

Diese Network-Extension-Clients sind in der Regel 1 MByte groß und downloadbare Applets, meist in Java- oder Active-X-Formaten geschrieben. Sie binden fremde Authentifizierungsmethoden wie Smartcards oder Token auf dem Host ein. Damit die existierenden Datenbanken, auf denen die Credentials des Users liegen, auch abgefragt werden, sprechen die SSL-Gateways Radius oder LDAP.

Die Extension-Clients leisten aber noch mehr. Sie bauen generell virtuelle VPN-Interfaces auf, für die der Administrator unterschiedliche Policies und variierende Zugriffsbedingungen definieren darf. Dies könnten durchaus auch Netzparameter sein, beispielsweise eine DHCP-Range, aus der sich die Lokation des Users ableiten ließe. Loggt der Mitarbeiter sich gerade remote vom Hotel aus ein oder über das Wireless-Segment im Konferenzraum?

Diese Regeln greifen ähnlich wie Firewallregeln und erlauben es den Verantwortlichen, den Zugriff an viel mehr Details und Bedingungen zu binden. Diese Flexibilität hat aber ihren Preis.

Nicht jeder Hersteller deckt mit seinen Erweiterungen alle Microsoft-Plattformen ab. Vor allem mit älteren Windows-98- oder -95-Hosts haben sie ihre Schwierigkeiten. Weniger verbreitete Betriebssysteme wie Mac-OS werden noch seltener unterstützt, ganz zu schweigen von Exoten auf Basis von Linux. Hier sollte sich ein Verantwortlicher für heterogene Netze besonders erkundigen, um später vor bösen Überraschungen gefeit zu sein. Außerdem sollte er wissen, dass die meisten Hersteller lokale Administrationsrechte auf den Zielhosts verlangen. Ohne diese Privilegien misslingt die erste Installation. Ein Punkt, den jeder beim Enrollment unbedingt beachten muss.

Allerdings helfen die Extension-Clients bei einem generellen Problem. Sobald das Unternehmen seinen Benutzern erlaubt, remote per SSL auf interne Anwendungen zuzugreifen, würden ihre Zugangscredentials prinzipiell genügen. Der Administrator könnte nicht mehr verifizieren, mit welchem Gerät sich der User gerade einzuwählen versucht: mit seinem Notebook, das von sich aus ein höheres Sicherheitsniveau erreicht, weil beispielsweise Virenscanner und PC-Firewall installiert und aktiv sind? Oder mit seinem vergleichsweise nackten PDA, der standardmäßig mit einem SSL-fähigen Browser ausgestattet ist und genauso auf E-Mails zugreifen kann? Eine einfache Policy kann dieses Problem beheben. Nur wer beispielsweise einen Network-Extension-Client installiert hat, darf auf wichtige Anwendungen und Daten zugreifen. Der PDA dürfte dann nur statische Webinformationen wie Preise abrufen.

Den Client durchleuchten
Die SSL-VPN-Hersteller haben so relativ schnell eine grundlegende Frage beim Remote-Access zu beantworten versucht. Wenn ein Gateway den User erst nach Passwort und Benutzername fragt, bis es ihn akzeptiert, warum bringt es dann seinem System prinzipiell so viel Vertrauen entgegen? Ein Punkt, der in jüngster Zeit immer mehr an Gewicht gewann, weil Malware aggressiver, schneller und unter dem Strich erfolgreicher wurde. Der User mag nicht wissen, dass sein Rechner infiziert ist. Er wird im schlimmsten Fall unbewusst eine netzweite Epidemie auslösen, sobald er sich remote einwählt. Die Anbieter haben für sich entschieden, den Client genauso zu untersuchen wie den Anwender, bevor sie beiden Zugriffsrechte gewähren.

Dazu haben sie zahlreiche Abfragemechanismen implementiert, die vom downloadbaren Applet auf dem Zielhost durchgeführt werden. Die Idee hinter diesen Checks ist es, einen Eindruck vom Sicherheitsniveau des Hosts zu erhalten. Wie detailliert diese Abfragen erfolgen und welche Kriterien tatsächlich geprüft werden, variiert von Produkt zu Produkt.

Zum Standard gehört heute, dass die Applets prüfen, ob der Virenscanner installiert und tatsächlich aktiviert ist. Auch das Alter seiner Signatur wird überprüft. Wessen Virendatenbank nicht aktuell ist, sollte überhaupt nicht oder nur auf statische, weniger sensible Daten zugreifen dürfen. Der Administrator sollte aber prüfen, ob sein künftiger SSL-VPN-Anbieter seine Virenscanner auch unterstützt. Oder zumindest einen generischen Abfragemechanismus beherrscht, der beispielsweise jede beliebige DLL finden kann.

Genauso ist es heute Standard, die PC-Firewall und ihren Status abzufragen und die Version des Betriebssystems zu ermitteln. Hieraus lässt sich der Patch-Stand des Hosts genau protokollieren. Einige Hersteller beziehen noch weitere Drittherstellersoftware mit ein, seien es lokale Verschlüsselungsprogramme, Host-Intrusion-Prevention-Scanner oder Malware-Blocker.

Außerdem bieten nahezu alle Hersteller heute einen »Sandbox«-Modus an. Dahinter verbirgt sich ein Secure-Container-Konzept, das vor allem bei Rechnern eingesetzt werden soll, die dem User nicht gehören. Den Herstellern schwebt vor, dass der Mitarbeiter sich über ein Internet-Cafe oder andere öffentliche Clients einwählt und seinen Secure-Container herunterlädt. Dieses weitere Applet, in der Regel erheblich größer als der Extension-Client, baut einen vom übrigen System vollkommen isolierten Arbeitsbereich auf dem Rechner auf.

Alle Dateien, die der User herunterlädt, werden nur in diesem Bereich ausgeführt. Die Sandbox verhindert, dass der Mitarbeiter diese Daten lokal speichert. Und sie löscht sich und alle Spuren, die der User hinterlassen hat, automatisch, sobald Letzerer sich ausloggt. Alle Cookies, Passwörter, Daten und der Secure-Container sind danach beseitigt. Der Administrator sollte sich aber informieren, wie der tatsächliche Löschprozess funktioniert. Ideal wäre, überschriebe die Lösung die entsprechenden Einträge und Dateien mit zufälligen Bitmustern. So lassen sich wichtige Dateien zumindest nicht mit einfachen Betriebssystemmitteln restaurieren.

Schließlich prüfen einige Gateways, bevor sie diese Sandbox herausschicken, ob die Zielmaschine eventuell mit Keyloggern und ähnlicher Malware infiziert ist. Das geschieht, ohne dass zusätzlich Drittherstellersoftware konsultiert wird. Ob der Administrator diesem selbsständigen Scan trauen sollte? Besser nicht, denn den rein auf Malware konzentrierten Antiviren-Herstellern fällt es zunehmend schwerer, aktuell genug auf frische Schädlingsvarianten zu reagieren. Wie soll es einem SSL-Anbieter dann gelingen, mindestens genauso schnell zu sein, zumal er diese frischen Signaturen und Abfrageroutinen erst in sein Applet einspielen müsste?

Applikationen einbinden
Im Gegensatz zu IPsec hat SSL den Makel, dass es nicht alle Anwendungen per se unterstützt. Das ist immer noch richtig, da IPsec-VPNs den gesamten Protokoll-Stack stellen und so eine große Zahl von Programmen ohne jegliche Anpassung tunneln können. Beim Browser-Verfahren muss der Administrator genau untersuchen, welche seiner installierten Applikationen tatsächlich unterstützt werden.

Bei einigen Kandidaten ist es offensichtlich. Moderne Groupware- und Kommunikationstools wie Notes oder Exchange besitzen ihr eigenes SSL-Interface, das sich wunderbar an ein solches VPN koppeln lässt. Auch Zugriffe auf Web-Applikationen und -Server sind sofort umsetzbar. Interessant wird es dann schon bei Windows-File-Shares, SSH oder Anwendungen, die selbst entwickelt wurden oder eben noch nicht webfähig sind.

Einige Hersteller versuchen, diese Programme mit intelligentem Portforwarding und Proxy-Technik einzubinden. Hin zum Web spricht der Proxy klassisch HTTP/S, während er im Firmennetz das Standardprotokoll der Applikation verwendet. Der Administrator sollte hierbei analysieren, ob er alle seine wichtigen Anwendungen im Remote-Access einbinden kann. Außerdem sollte er untersuchen, wie viele Usersessions der Proxy-Ansatz verkraftet und ob die Antwortfristen in der Praxis genügen.

Die Frage der Kontrolle
Wer ein VPN auf Basis von SSL etablieren möchte, wird einige Zeit damit verbringen, sich in den jeweiligen Management-Konsolen zurechtzufinden. Der Grund: Die Zugriffe können an verschiedenen Kriterien scheitern, wobei die Parameter in Verantwortungsbereichen der Kollegen liegen könnten. Allein die vielen Parameter bei den Endpoint-Checks und die zahlreichen Bedingungen und Abhängigkeiten, die sich daraus ableiten können, geben einen Eindruck von der möglichen Komplexität.

Daher ist es wichtig, die Einstellungsmenüs mit ihren Funktionen und Reglern auch verschiedenen Zuständigen im Unternehmen zugänglich zu machen. Denn ein SSL-VPN greift funktional in viele Abteilungen ein. So ist es bei mittelgroßen Firmen schon üblich, die Desktops, die Server, das Netz, die Anwendungen und Enduserbedürfnisse auf verschiedene Zustänigkeitsbereiche aufzuteilen. Sie alle werden ein Wörtchen mitzureden haben. Ein Beispiel: Jemand muss die Standardparameter in LDAP- und Radius-Servern eintragen; ein anderer entscheiden, wie die User auf Windows-Fileserver zugreifen sollen; ein Dritter, wie die Desktops und ihre Integritätsparameter konfiguriert werden sollen; schließlich muss ein Vierter die Firewalls, Router und so weiter entsprechend einstellen. Gerade beim Troubleshooting ist es essenziell, dass diese IT-Zuständigen in gewisser Weise auch auf die SSL-Gateways zugreifen können.

Künftige Marktentwicklungen
Ein Hersteller hat inzwischen darauf reagiert, dass vor allem bei großen Firmen die Zahl der Anwender, die angebunden werden müssen, sich stark und kurzfristig ändert. Sei es durch interne Projekte oder externe Vorhaben mit Partnerfirmen – permanent variieren die Zusammensetzung und Zahl der Remote-User. Der Anbieter Aventail hat mit »Spike License Pack« daher ein neues Lizenzierungsverfahren eingeführt.

Hierbei kaufen die Kunden eine zeitlich begrenzte Lizenz, die sie bei Bedarf aktivieren. Der Hersteller spricht von 30 bis 90 Tagen. Diese Speak-Zugänge sollen so Spitzenzeiten elegant abfedern, ohne dass ein Unternehmen die entsprechenden Lizenzen gleich für ein Jahr oder länger bezahlen muss.

Aber auch auf anderen Gebieten deuten sich Veränderungen an. Die generellen Vorteile von SSL haben dazu geführt, dass bis heute nahezu jeder Firewall-VPN-Hersteller das Verfahren in seine Lösungen eingebaut hat. Die Unified-Threat-Management-Appliances (UTM) von Produzenten wie Sonicwall, Nokia oder Watchguard arbeiten dabei als Hybridwesen. Sie koppeln andere LANs und Außenstellen weiterhin klassisch per IPsec an die Firmenzentrale. Während sie mobile User dagegen per SSL-Terminierung und -Proxies versorgen.

Der UTM-Markt ist mit mehr als 600 Herstellern heiß umkämpft. Diese Situation hat sich dadurch noch verschärft, dass Microsoft mit ihrer Firewall »ISA Server« neben IPsec auch SSL beherrscht. Gerade für kleinere und mittelgroße Unternehmen ist dies ein interessantes Angebot, fügt sich ein Redmond-Produkt doch wunderbar in die Office-Welt und Active-Directory ein.

Rein auf SSL konzentrierte Anbieter sind inzwischen selten geworden. Als wenige haben Aventail und Array Networks ihre Unabhängigkeit bewahren können. Andere Hersteller wurden meist von großen Firewall-Anbietern akquiriert. So hat unter anderem Juniper Neoteris erworben, der Load-Balancing-Hersteller F5 Networks schluckte Uroam. Es ist zu erwarten, dass sich die Konsolidierung auf dem Markt weiter fortsetzt.

Kein Wunder also, dass die Hersteller neue Aufgabengebiete suchen, um sich in eine gute Position zu bringen und der Konkurrenzdichte aus dem Weg zu gehen. Der Analyst Infonetic Research hat in einer Umfrage im vergangenen Jahr herausgefunden, dass vor allem bei VoIP Potenzial liegt.

Die meisten Konvergenzprojekte wurden jeweils im Netz des Unternehmens umgesetzt, ohne viele Schnittstellen zu fremden Firmen. Der Analyst befürchtet, dass gerade interne Mitarbeiter die SIP-Sessions bedrohen könnten. Denn nach Studien des CSI/FBIs werden rund 80 Prozent aller Attacken von innen heraus geführt. Ein unzufriedener Mitarbeiter wäre in der Lage, einen Man-in-the-Middle-Angriff gegen VoIP zu führen und Gespräche abzuhören. SSL als interne Verschlüsselung Ende-zu-Ende würde dies verhindern.

Außerdem können SSL-VPN-Gateways dank ihrer Client-Checks eine große Rolle bei NAC spielen. Hier wird auch der Zustand interner Clients analysiert, bevor der User auf das Unternehmensnetz zugreifen darf. Juniper hat ihre Lösung bereits hierfür positioniert, andere werden folgen. Daher ist es wahrscheinlich, dass die Aufgaben für die SSL-Gateways wachsen – auch wenn die Hersteller andere Namen für sie finden werden.

pm@networkcomputing.de