SSL-VPN: Erweitern der SonicWALL-Firewall

Der geschützte Zugriff auf Server und Dienste eines Unternehmensnetzwerks erfolgt traditionell über eine IPSec-Konfiguration. Dabei wird auf dem Client (Notebook oder PC) eine Software installiert, die den Tunnel zur Firmen-Firewall aufbaut. Das zusätzliche Setup eines SSL-Zugangs bringt erweiterte Möglichkeiten und ist technisch recht einfach.

Zweimal VPN: IPSec und SSL

Eine verschlüsselte Anbindung an das Unternehmensnetzwerk mithilfe des IPSec-Protokolls ist eine schöne Sache. Der Anwender baut auf seinem Computer eine Verbindung auf (mit Username und Kennwort oder Zertifikat) und kann anschließend die auf Firewall-Seite konfigurierten Ressourcen der Firma nutzen. Arbeiten wie im Netzwerk, nur langsamer.

Der große Nachteil: auf dem PC des Anwenders muss zuerst die passende Software installiert werden. Kein Zugriff von einem anderen Computer.

Mobile Geräte und VPN

Eine weitere Einschränkung stellt diese Technik für die zunehmende Nutzung von Tablets und Smartphones dar. Diese Geräte sind meist von einer Installation eines IPSec-Clients ausgenommen, da deren Betriebssysteme dies nicht unterstützen. Auch hier ist der Zugriff mithilfe des SSL-Protokolls einfacher und schneller einzurichten.

Die Firewall als SSL-Gateway

Die Lösung für Firmen liegt in der Installation einer SSL-Appliance. Für kleinere Umgebungen ist aber manchmal bereits die Konfiguration eines SSL-Zugangs auf Firewall-Seite eine einfache und schnelle Lösung. Am Beispiel einer Firewall von SonicWALL das Setup in der Praxis.

Konfiguration des WAN-Interface

Da in diesem Fall – wie gesagt nur für kleine Umgebungen zu empfehlen – kein eigenständiges SSL-Gateway existiert, dient die Firewall selbst als solches. Aus diesem Grund ist die offizielle IP-Adresse der Firewall auch der Eingangspunkt für SSL-Verbindungen.

Im ersten Schritt heißt es nun, auf dem WAN-Interface (X1) die Annahme von SSL-Verbindungen zu ermöglichen. Dazu wird in der Firewall-Konfiguration auf dieser Netzwerkschnittstelle das User-Login über https aktiviert (siehe Abbildung).

Der Http-Redirect bleibt deaktiviert. Ansonsten würde die Firewall nach außen (Internet) auch den Standard-Webport (Port 80) als ansprechbar melden – unnötig.

SSL-Server konfigurieren

Im nächsten Schritt ist im Reiter „SSL VPN“ die eigentliche Konfiguration des SSL-Zugangs vorzunehmen. Dabei gilt es zuerst die gewünschten „Zonen“ für den Zugriff freizugeben. Als Standard dürfte hier die Zone »WAN« zur Aktivierung anstehen. Nur dann kann ein Verbindungsaufbau aus dem Internet erfolgen. Gegebenenfalls kann aber auch eine WLAN-Schnittstelle (zusätzlich) aktiviert werden, um mobilen Geräten den Zugang im eigenen Unternehmensnetzwerk über das eigene WLAN zu ermöglichen.

Port für Anwender und Admins

Ein wichtiger Punkt: Als Standard wird für den Zugangsport für SSL-Verbindungen der Anwender die Portnummer 4433 vorgegeben. Funktioniert soweit. Das Problem dabei ist, dass in vielen (fremden) Umgebungen – z.B. bei Verwendung von öffentlichen Hotspots, wie in Hotels – Verbindungen nach außen über diesen Port geblockt werden. Als Standard für verschlüsselte SSL-Verbindungen ist ja eigentlich Port 443 vorgesehen (wie auch bei Homebanking und anderen geschützten Browser-Verbindungen).

Das Problem: Port 443 ist für das Management der Firewall durch den Administrator reserviert. Entweder, oder – sollte eine Verbindung der User über den „normalen“ Https-Port 443 ermöglicht werden, so muss zuvor der Admin-Port auf einen anderen (z.B. 4433) geändert werden.

Verschlüsselung

Das Herzstück der Sicherheit ist die Konfiguration der gewünschten Verschlüsselung. Hier ist (aktuell) eine AES-256-Kodierung Pflicht. In Kombination mit SHA1 die beste Wahl.

Das Portal

Die Konfiguration des „Portals“ ist der für den Endanwender entscheidende Punkt. Hier ist aber auch die Limitierung eines Setups ohne dedizierte SSL-Appliance ersichtlich. Machen Sie das Beste für Ihre User daraus und passen Sie das Erscheinungsbild der Eingangsseite bestmöglich an die Unternehmens-CI an. Ein Auto-Start des Netextenders sollte nicht aktiviert werden.

Die Client-Settings

In den Einstellungen der „Client Settings“ gilt es vor allem die DHCP-Konfiguration eines bestehenden DHCP-Servers zu berücksichtigen. Hier darf es keine Überschneidungen geben. Ein speziell für SSL-Clients ausgesetzter DHCP-Bereich ist zu konfigurieren.

Die restlichen Settings sind einfach festzulegen: Als „Interface“ ist bei Standard-Setups X0 zu wählen – mehr Absicherung bietet hier die Konfiguration einer speziellen DMZ-Konfiguration. Die DNS-Domain sollte dem internen DNS-Setup entsprechen (yourdomain.local).

Etwas mehr Aufmerksamkeit verdient die sogenannte „User Domain“. Wenn Sie die einzelnen SSL-User lokal verwalten wollen, kann die Vorgabe – „LocalDomain“ – bestätigt werden. Gibt es im Netzwerk erweiterte Authentifizierungsmöglichkeiten (Stichwort: RSA), so ist hier etwas mehr Konfigurationsvorbereitung angesagt.

Kleinigkeiten

Zuletzt werden in der Konfiguration noch einige Kleinigkeiten angepasst. Dazu zählt vor allem, das Verbindungs-Timeout zu erhöhen. Schließlich wollen wir die Arbeit den Anwendern nicht unnötig schwer machen.

NetBios sollte für Broadcasts aktiviert werden. Funktioniert zwar nicht immer, verhindert aber oft Probleme beim Netzwerkzugriff.

Zuletzt noch die Einstellung „Exit Client after Disconnect“ anhaken und die Speicherung des „Client Connection Profile“ ermöglichen.

Netzwerkstrecken – Routes

Die „Client-Routes“ werden im Schnellgang festgelegt. Das „Primary Subnet“ sollte als Minimum konfiguriert sein. Detaillierte Zugriffsberechtigungen werden ohnehin über die Firewall-Access-Policy festgelegt. Hier geht es nur um mögliche und notwendige Netzwerkverbindungen.

Einen speziellen Punkt stellt die Konfigurationsmöglichkeit „Tunnel All“ dar. Diese Variante ist auch als „Split Tunnel“ bekannt. Letztlich geht es hierbei um die Entscheidung, ob sämtlicher Datenverkehr des Anwenders über die Unternehmensverbindung laufen soll, oder nur die Zugriffe auf Systeme im Firmennetzwerk. Eine wichtige Entscheidung. Der »Split Mode« ermöglicht dem SSL-Client, den „normalen“ Internet-Zugang über „seine“ aktuelle Anbindung zu routen. Das Surfen im Internet läuft demnach nicht über die SSL-Verbindung – wahrscheinlich schneller, aber ohne Abschirmung durch das Sicherheitsnetzwerk des Unternehmens.

John Doe und seine Kollegen

Jetzt ist nur noch der Userzugriff anzulegen. Ohne Ldap- oder Radius-Authentifizierung ist an dieser Stelle nur noch der lokale Anwender-Account anzulegen. Diesem wird die Gruppe „SSLVPN-Service“ und der VPN-Access auf das „LAN-Subnet“ zugewiesen – Bookmarks für RDP und SSH optional.

Test, Test, Test

Für ein Standard-Setup sollte dies ausreichen. Wie eingangs bemerkt, ist für mittlere und größere Umgebungen eine explizite SSL-Appliance unausweichlich. Das Setup gleicht dem hier angeführten. Weitere Informationen gibt es hier im Blog.