Erweiterte Möglichkeit für den Zugang ins HU-Netz

Die HU bietet für Mitarbeiter und Studierende seit langem die Möglichkeit, sich per VPN mit dem HU-Netz zu verbinden. Das geht von außerhalb der Uni und auch aus dem WLAN-Netz. Für den Zugang über das WLAN-Netz gibt es seit kurzem das neue Funknetz „HU-VPN“, welches offen und nur mit einem VPN-Client benutzbar ist. VPN steht für Virtual Private Network. Dahinter verbirgt sich eine Technologie, die es ermöglicht, von einem externen Internet-Zugang einen verschlüsselten und damit sicheren Zugriff auf ein internes Netz zu bekommen. Zwischen einem Client-Rechner und einem VPN- Konzentrator, dem Eintrittspunkt in das interne Netz, wird ein Tunnel aufgebaut. Der Client authentifiziert sich und wird nach erfolgreicher Authentifizierung logisch zum Bestandteil des Netzes, in dem sich der Tunnelendpunkt befindet. Die Technologie umfasst neben einer Authentifizierung auch moderne Verschlüsselungsverfahren, wie beispielsweise AES. Damit ist es möglich, einen sicheren Zugang über unsichere Netze zu realisieren, im speziellen Fall also ein Zugang zum Netz der HU, von jedem beliebigen Rechner mit Internet-Zugang weltweit. Mitarbeiter oder Studierende, die einen beliebigen Internet- Provider zur Einwahl oder DSL benutzen, können beispielsweise somit auf universitätsinterne Ressourcen zugreifen. Zum Herstellen der Verbindung zum HU-Netz werden lediglich ein Software- Client und ein Account benötigt.

Bis jetzt sorgten zwei VPN- Concentrators 3060 von der Firma Cisco als Tunnelendpunkte für den Netzzugang mittels VPN. Als Clientsoftware wurde vom CMS dafür der VPN-Client von Cisco in verschiedenen Versionen für die Betriebssystemplattformen Windows, Mac OS und Linux bereitgestellt.

Mit der steigenden Verwendung von Notebooks für die tägliche Arbeit und der Abschaffung des alten Funknetzes „Wireless Campus Network HUB“ wird der Netzzugang über die Cisco-Geräte stärker ausgelastet. Dazu kommt noch die wachsende Verbreitung von netzfähigen PDAs und ähnlicher mobiler Kleingeräte, die uns zum Handeln bewogen haben. Für diese gibt es keinen VPN-Client von Cisco. Um diesen Geräten einen Netzzugang zu ermöglichen, haben wir beschlossen, als weitere Möglichkeit ein SSL-VPN-Gateway als Zugang anzubieten.

Warum SSL-Gateway?

Die Verwendung von SSL löst einige Probleme, die mit IPsec-VPNs verbunden sind. Traditionelle VPNs basieren auf IPSec (Internet Protokoll Security), um einen Tunnel zwischen zwei Endpunkten aufzubauen. Diese können zwei entfernte Netze sein oder ein Netz und ein einzelner Rechner. IPSec arbeitet auf der Netzebene des OSI-Modells und sichert dabei alle Daten, die zwischen diesen zwei Endpunkten, ohne eine Zuordnung zu einer bestimmten Anwendung, übertragen werden. Wenn ein Client-Computer mit einem IPSec-VPN verbunden ist, befindet er sich dann logisch im Netz des Tunnelendpunktes. Der Client-Rechner kann das gesamte Netzwerk sehen und auf den Inhalt direkt zugreifen. Weitere Beschränkungen in den Zugriffsrechten sind mit IPsec nicht realisierbar (siehe Abb. 1).

Abb. 1: Zwei Einsatzfälle für IPsec: zwischen zwei Netzen und zwischen Benutzer und Netz [1]

Dagegen bietet ein SSL-VPN folgende Vorteile:

Die Nachteile müssen aber auch erwähnt werden. Um Zugriff auf nicht webbasierte Anwendungen zu bekommen, müssen auf Client- und/oder Serverseite Umsetzer mitlaufen, etwa Java-Plug-ins oder ActiveX-Komponenten, die deren Daten über die Browserverbindung umleiten. Nicht alle Anwendungen lassen sich durch diese Umsetzer benutzen (siehe Abb. 2). Einsatzfall für SSL-VPN: fein einstellbare Zugriffsberechtigung auf eine Ressource im HU-Netz über einen verschlüsselten Tunnel zwischen SSL-Gateway und Client.

Abb. 2: Einsatzfall für SSL-VPN: fein einstellbare Zugriffsberechtigung auf eine Ressource im HU-Netz über einen verschlüsselten Tunnel zwischen SSL-Gateway und Client [2]

Was kann unser SSL-VPN-Gerät

Wir verwenden 2 Geräte (SA4000) der Firma Juniper als SSL-VPN-Gateway. Des Weiteren haben wir ein kleineres Testgerät (SA2000) für Testkonfigurationen. Da unser Cluster seit dem letzten Herbst schon produktiv im Einsatz ist, werden alle Änderungen vorher auf dem Testgerät ausprobiert.

Beide SA-4000-Geräte sind zu einem Aktiv/Passiv–Cluster zusammengeschaltet. Dabei wird im Cluster eine virtuelle IP-Adresse im CASG-Netz simuliert. Diese virtuelle IP-Adresse ist mit dem DNS-Namen ssl.cms.hu-berlin.de verbunden und zeigt auf das aktive Gerät, während das passive nicht angesprochen wird und nur die Sessions mitverfolgt. Die Benutzer, ob von außen oder von innen, benutzen nur den DNS-Namen und landen dann auf dem aktiven Gerät. Bei einem Ausfall des aktiven Gerätes werden alle Anfragen an das andere Gerät geleitet. Somit ist eine hohe Ausfallsicherheit gegeben. Wir haben zurzeit eine Lizenz für maximal 1000 gleichzeitige Benutzer. Der Cluster steht in Adlershof im Erwin Schrödinger-Zentrum.

Abb. 3: Aktiv/Passiv-Cluster

Das Gerät, die SA-4000, bietet 3 verschiedene Stufen des Zugriffs auf Ressourcen im HU-Netz wie Web, Mail, SSH etc.

1. Stufe:

Basisdienste wie Mail, Telnet, Terminalsitzungen werden über ActiveX-Scripte oder Java-Applets über https-Port 443 getunnelt, erfordern also keine ClientInstallation.

2. Stufe:

Für eigene Anwendungen können ActiveXScripte oder Java-Applets generiert werden, diese werden dann clientseitig über https-Port 443 getunnelt, die Bereitstellung der Anwendung erfolgt unter einer Loopback-Netzwerkadresse des Clients. Zur Umlenkung von Client-Applikationen wird der DNS-Name durch eine temporäre Anpassung der Hosts-Tabelle des ClientSystems auf diese Adresse umgelenkt.

3. Stufe:

Mit Network Connect steht ein vollwertiger IPsec-Client als Java-Applet bereit, Vorteil dieses Clients: er geht leichter zu installieren (gilt nicht für mobile Kleingeräte!!!), läuft auch über UDP-Port 500 und 4500. Bei dieser Stufe werden komplette IP-Pakete eingekapselt, wodurch sich die Verbindung mit dem SSL-VPNGateway aus Benutzersicht genauso verhält, wie dies bei dem Cisco-VPN-Gateway der Fall ist. Der Benutzer kann also lokale Anwendungen auf seinem PC verwenden und durch den IPsec-Tunnel auf entfernte Server zugreifen.

Zurzeit stellt der CMS folgende Dienste bereit:

Im Moment ist wegen des immensen Konfigurationsaufwandes an keine weitergehende, feiner unterteilte Freigabe von Netzwerkressourcen gedacht.

Ausblick

Die Möglichkeiten der Nutzung SA4000 sind mit dem jetzigen Stand noch nicht ausgereizt. Es gibt noch eine Reihe von Funktionen, die man im weiteren Ausbau noch aktivieren könnte. Als erstes möchte ich die zertifikatsbasierende Anmeldung des Clients (Benutzers) an der SA4000 erwähnen. Der CMS unterstützt die Verbreitung und Anwendung von Zertifikaten. Jeder Angehöriger der HU-Berlin (Studierender oder Mitarbeiter) mit einem eingerichteten CMS-Account kann ein persönliches Zertifikat auf einer HU-CA Smartcard beantragen. Damit authenti-fizieren sich beide Seiten (SSL-VPN-Gateway und Benutzer) gegenseitig und können sich sicher sein, mit dem wahren Gegenüber verbunden zu sein. Diese Funktion gibt es schon bei der Verwendung des Cisco-Clients.

Des Weiteren gibt es SecureMeeting. Damit kann man sichere, verschlüsselte Online-Konferenzen mit Personen weltweit durchführen. Voraussetzung ist natürlich ein PC mit den vorgenannten Eigenschaften. Auch könnte man die erweiterten Sicherheitsfunktionen (Hostchecker, Cachecleaner) aktivieren, die mithilfe von ActiveX-Scripten oder Java-Applets auf den Clients dann Sicherheitschecks wie Updateaktualität vom System, Viren-scanner etc. durchführen. Dies ist aber schon ein tiefer Eingriff auf fremde Rechner und ist in diesem Umfang von uns nicht gewünscht.

Der aktuelle Stand der WLAN-Arbeiten und Neuerungen sind auf unserer CMS-Webseite zu finden.