Captive Portal

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Ein englisch Captive Portal, dt. etwa Gefangen im Portal, ist eine Einrichtung die üblicherweise in öffentlichen, drahtlosen Netzwerken eingesetzt wird um den Zugriff verschiedener Endgeräte wie Laptops oder Smartphone auf das dahinter liegende Netzwerk oder das Internet an die Zustimmung des Nutzer an bestimmte Nutzungsregeln zu knüpfen oder den Zugang mit einem bestimmten Benutzerkonto zu verbinden, beispielsweise zum Zwecke der Abrechnung der Verbindungskosten.

Eingesetzt werden Captive Portals vor allem in den Bereichen in denen mit öfter wechselnden Teilnehmern und verschiedenen Endgeräten zu rechnen ist, wie beispielsweise von Gästen nutzbare WLAN-Netze in Hotels, öffentlichen WLAN-Hot-Spots in Städten und Gemeinden, oder WLAN-Netze in Transportmitteln wie Zug, Bus oder Flugzeug.

Beispielseite eines Captive Portal

Funktion[Bearbeiten | Quelltext bearbeiten]

Bei einem Captive Portal kann ein Endgerät sich zunächst mit dem meist unverschlüsselten und ohne Zugangsdaten erreichbaren WLAN-Netz verbinden. In diesem Zustand wird vom Captive Portal allerdings jeder weiterer Zugriff auf das dahinter liegende Netzwerk oder Internet noch blockiert, das Gerät ist quasi im diesem Bereich gefangen wovon sich die Bezeichnung ableitet.

Üblicherweise werden in diesem Zustand Anfragen von Webbrowser über HTTP zu einer Web-Seite am Captive Portal umgeleitet, wo der Benutzer seine Zustimmung zu bestimmten Regeln geben muss und weitere Angaben wie beispielsweise Benutzerkennung und Passwort für die Abrechnung eingibt. Erst nach erfolgter Zustimmung und ggf. positiver Authentifizierung erfolgt über das Captive Portal die Freigabe für den Netzwerk- oder Internetzugriff für dieses Endgerät. Je nach Konfiguration des Netzwerkes ist der Zugriff dann nicht nur auf HTTP beschränkt, sondern umfasst beispielsweise auch verschiedene andere Protokolle wie IMAP für die Abfrage von Email oder auch VPN-Verbindungen.

Da die Freischaltung auf IP-Ebene basiert, oft verschiedene Protokolle zugelassen werden, werden freigeschaltete Endgeräte an der jeweiligen MAC-Adresse zugeordnet. Je nach Konfiguration des Netzwerk können dabei die Freigaben zeitlich befristet erfolgen oder bestimmte MAC-Adressen können auch fest eingestellten freien Zugang bekommen.

Implementierung[Bearbeiten | Quelltext bearbeiten]

Obwohl Captive Portals in der Funktion seit ca. Anfang der 2000 Jahre bestehen gab es bis Mitte 2015 keinen einheitlichen Standard wie ein Captive Portal zu realisieren ist und welche Funktionen ein Endgerät erfüllen muss um die Anwendung für den Benutzer so einfach wie möglich zu gestalten.

Die Lösungen sind daher meist proprietäre Verfahren die oft das Niveau von einem Workaround und verschiedene praktische Probleme aufweisen. Für die Umsetzung setzten die verschiedenen Realisierung sowohl auf entsprechende Software, beispielsweise m0n0wall, als auch auf Hardwareebene wie entsprechende Router auf.

Seit Ende 2015 steht mit RFC 7710 ein RFC-Standard zur Verfügung, welcher herstellerübergreifend die Realisierung und Grundlage von Captive Portalen beschreibt. Dabei wird das zur Konfiguration der Endgeräte eingesetzte Protokoll DHCP um einen speziellen Eintrag erweitert, welches dem Endgerät erstens anzeigt, dass es sich in einem Captive Portal befindet und noch keinen externen Internetzugriff hat, und zweitens wird per DHCP im Rahmen der Netzwerkkonfiguration dem Endgerät eine URL mitgeteilt, wo sich das Captive Portal befindet und durch einen Webbrowser aufgerufen werden kann. Es wird IPv4 und IPv6 unterstützt und es entfällt damit die problematische Umleitung von Netzwerkzugriffen.

Vor der Verabschiedung von RFC 7710 haben sich im laufe der Jahre verschiedene Verfahren zur Realisierung von Captive Portalen etabliert, welche im Prinzip auf einer Umleitung des Netzwerkverkehrs auf das Captive Portal beruhen und in folgenden Abschnitten dargestellt werden.

Umleitung via HTTP[Bearbeiten | Quelltext bearbeiten]

Wenn ein nicht autorisiertes Endgerät eine beliebige Webseite anfordert, wird das DNS abgefragt und die IP wie üblich aufgelöst. Der Browser schickt dann einen HTTP-Anfrage an diese IP-Adresse. Diese Anfrage wird durch eine Firewall abgefangen und an einen eigenen Umleitungs-Server geschickt. Dieser beantwortet die Anfrage mit einer HTTP-Antwort, welche den Statuscode 302: Found enthält, um so auf die Captive-Portalseite umzuleiten. Für das Endgerät ist dieser Vorgang transparent, es muss davon ausgehen, dass die ursprünglich angefragte Webseite diese Umleitung gesendet hat. Eine abgewandelte Methode besteht darin, den Statuscode 511: Network Authentication Required zu verwenden, welcher aber nicht von allen Webbrowsern verstanden wird.

Diese Art der Umleitung funktioniert nur bei dem nicht verschlüsselten HTTP. Dazu kommt der Umstand, dass die Verwendung von HTTP zugunsten von HTTPS stetig abnimmt.

Probleme mit HTTPS[Bearbeiten | Quelltext bearbeiten]

Bei dem mittels Transport Layer Security (TLS) verschlüsselten HTTPS kommt es bei dieser Umleitung zu einer Fehlermeldung, da das vom Captive-Portal verwendete Zertifikat nicht für die vom Endgerät ursprünglich aufgerufene HTTPS-Adresse gültig ist. Im Prinzip entspricht die bei Captive Portalen eingesetzte Methode der Umleitung einem Man-in-the-Middle-Angriff. Durch die Signierung der eingesetzten TLS-Zertifikate durch eine vertrauenswürdige Stelle kann das Endgerät diese Manipulation der Umleitung erkennen und dem Anwender eine entsprechende Warnung anzeigen oder den Zugriff auf die Portalseite gänzlich unterbinden.

Aber auch wenn der Anwender eine HTTP-URL manuell eingibt kann es bei zusätzlichen Schutzverfahren wie HTTP Strict Transport Security (HSTS) zu Problemen kommen: Bei HSTS erklärt ein Web-Server auf eine bestimmte Zeit von beispielsweise einem Jahr, keinen Zugriff mit unverschlüsselten HTTP auf diese Domain zu erlauben. Wurde die entsprechende Domain welche HSTS verwendet von dem Endgerät zuvor schon einmal aufgerufen, wird die Verwendung von HTTP für diese Adresse am Endgerät verhindert und das Captive Portal kann nicht angezeigt werden.[1] Eine weitere Hürde für Captive Portale mit Umleitung ergibt sich bei Einsatz von HTTP Public Key Pinning (HPKP).

Umleitung via DNS[Bearbeiten | Quelltext bearbeiten]

Wenn ein nicht-autorisiertes Endgerät eine Webseite anfordert, wird das DNS abgefragt. Die Firewall stellt sicher, dass nur ein DNS-Server erreichbar ist, der via DHCP vom Hot-Spot-Betreiber vorgegeben wird oder alternativ alle DNS Anfragen auf einen solchen DNS-Server umleitet. Der DNS-Server wird auf jede Anfrage die IP-Adresse der Portalseite als Ergebnis zurückmelden. Diese Methode wird allerdings durch die Domain Name System Security Extensions (DNSSEC) unterbunden, da das Zertifikat nicht gültig ist und diese Umleitung als ein Man-in-the-Middle-Angriff erkannt wird.[1]

IP-Umleitung[Bearbeiten | Quelltext bearbeiten]

Der Datenstrom kann auch durch IP-Umleitung auf der OSI-Schicht 3, mittest einer Redirect Message nach RFC 792, realisiert werden. Da der dargestellte Inhalt dann nicht mehr der URL entspricht wird diese Methode durch TLS und DNSSEC als Man-in-the-Middle-Angriff erkannt.

Erkennung[Bearbeiten | Quelltext bearbeiten]

Im Rahmen des RFC 7710 wird dem Endgerät die Anwesenheit in einem Captive Portal mitgeteilt, womit ein meist vom Datenschutz her problematisches Erkennungsverfahren, indem eine bestimmte externe Serveradresse über HTTP abgefragt wird, entfällt. Die Problematik ergibt sich aus dem Umstand, dass der externe Zielserver welcher zur Erkennung eines Internetzuganges vom Endgerät verwendet wird, im Prinzip Daten wann welches Endgerät von wo aus aktiv wird zentral mitgeteilt bekommt und diese Daten sammeln und zur weiteren Verarbeitung zur Verfügung stellen kann.

Im Folgenden sind einige dieser zur Portalerkennung eingesetzten externen Serveradressen angeführt:

Windows[Bearbeiten | Quelltext bearbeiten]

In Microsoft Windows gibt es den Network Connectivity Status Indicator (NCSI), welcher die Internetverbindung prüft und Captive Portals erkennt. Die entsprechenden Einstellungen sind in der Windows Registry unter HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet hinterlegt.

In Windows 10 wird die DNS-Domäne dns.msftncsi.com abgefragt und die IPv4-Adresse 131.107.255.255 und die IPv6-Adresse fd3e:4f5a:5b81::1 erwartet. Anschließend wird eine DNS-Abfrage auf www.msftncsi.com durchgeführt und die Ressource http://www.microsoftconnecttest.com:80/connecttest.txt (zum Test der IPv4-Verbindung) und http://ipv6.microsoftconnecttest.com:80/connecttest.txt (zum Test der IPv6-Verbindung) abgefragt. Diese Ressourcen müssen aus der Zeichenfolge Microsoft NCSI bestehen.

In älteren Windows-Versionen wird die Ressource http://www.msftncsi.com:80/ncsi.txt abgefragt.

Android[Bearbeiten | Quelltext bearbeiten]

Im Fall von Android gibt es den Captive Portal Check.

Webbrowser und Mailclients[Bearbeiten | Quelltext bearbeiten]

Webbrowser wie Mozilla Firefox, Thunderbird und SeaMonkey verwenden die URL http://detectportal.firefox.com:80/success.txt. Die Erkennung von Captive Portals kann in der about:config durch das Setzen des Schlüssels network.captive-portal-service.enabled auf false abgeschaltet werden.

Einschränkungen[Bearbeiten | Quelltext bearbeiten]

Auf der Filterung nach IP- oder MAC-Adresse basierende Implementierungen können auf WLAN-Seite relativ leicht umgangen werden, indem das Netzwerk mit einem Packet Sniffer belauscht und die dadurch ermittelten bereits freigeschalteten IP- und/oder MAC-Adressen anderer Teilnehmer nachfolgend mit dem Rechner des Angreifers imitiert werden.

Da der Zugang bei Captive Portalen im Regelfall über unverschlüsseltes WLAN erfolgt können diese WLAN-Verbindungen in der Umgebung leicht abgehört werden. Verbindungen in einem unverschlüsselten WLAN sollten daher nur über sichere, verschlüsselte Verbindungen wie HTTPS oder unter Verwendung wie VPN zu einem externen VPN-Server erfolgen.

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. a b Hanno Böck: Captive Portals: Ein Workaround, der bald nicht mehr funktionieren wird. In: Golem.de. 8. Februar 2016, abgerufen am 26. Mai 2017.