Captive Portal

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Ein Captive Portal leitet einen HTTP-Client in einem Netzwerk auf eine spezielle Webseite um, bevor dieser sich normal in das Internet verbinden kann. So wird üblicherweise eine Authentifizierung oder die Annahme der Nutzungsbedingungen erzwungen bzw. die Abrechnung der Nutzung ermöglicht.

Hintergrund[Bearbeiten | Quelltext bearbeiten]

Umgesetzt wird die Technik durch das Abfangen aller übermittelten Pakete unabhängig von IP-Adresse oder Port, bis der Benutzer einen Webbrowser öffnet und eine beliebige Webseite aufruft. Dann wird die Portalseite angezeigt, bei der eine Authentifizierung, Angabe von Zahlungsmethoden oder die Nutzungsbedingungen angezeigt werden. Captive-Portale werden meist bei Wi-Fi-Hot-Spots genutzt, um den Zugriff zu kontrollieren und abzurechnen.

Die Portalseite selbst muss entweder beim Gateway gespeichert sein, oder der Zugang zum Webserver, von dem die Seite bezogen wird, muss freigeschaltet sein (Walled Garden), um die Umlenkungen zu umgehen. Es ist auch möglich, die Umlenkungen des Portals für definierte MAC-Adressen zu deaktivieren, um so bestimmten Rechnern freien Zugang zu gewähren.

Implementierung[Bearbeiten | Quelltext bearbeiten]

Um ein Captive-Portal zu realisieren, gibt es mehrere Möglichkeiten. Diese können sowohl auf Software- als auch auf Hardwareebene umgesetzt werden.

Umleitung via HTTP[Bearbeiten | Quelltext bearbeiten]

Beispielkonfiguration anhand der frei verfügbaren Software mOnOwall

Wenn ein nicht autorisierter Client eine Webseite anfordert, wird das DNS abgefragt und die IP wie üblich aufgelöst. Der Browser schickt dann einen HTTP-Request an diese IP-Adresse. Dieser Request wird durch eine Firewall abgefangen und an den Umleitungs-Server geschickt. Dieser beantwortet den Request mit einer normalen HTTP-Response, welche den Statuscode 302: Found enthält, um so den Client auf die Captive-Portalseite umzuleiten. Für den Client ist dieser Vorgang transparent, er muss davon ausgehen, dass die ursprünglich angefragte Webseite diesen Redirect gesendet hat. Eine etwas bessere Variante besteht darin, den Statuscode 511: Network Authentication Required zu verwenden.

Die Umleitung funktioniert nicht, wenn Transport Layer Security (TLS), wie insbesondere bei HTTP Strict Transport Security (HSTS), eingesetzt wird, da hier das Zertifikat als ungültig erkannt wird.[1]

Da bei der HTTP-Umleitung meist der Zugriff auf DNS-Server möglich ist, kann zudem ein DNS-Tunnel verwendet werden, um die Firewall zu umgehen.[1]

Umleitung via DNS[Bearbeiten | Quelltext bearbeiten]

Wenn ein nicht-autorisierter Client 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 umleiten). 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.[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. Das ist aber nicht zu empfehlen, da der dargestellte Inhalt dann nicht mehr der URL entspricht. Auch dies wird durch TLS und DNSSEC unterbunden.

DHCP-Umleitung[Bearbeiten | Quelltext bearbeiten]

Ein Draft der IETF beschäftigt sich derzeit mit der Erkennung von Captive Portals mittels DHCP.[1][2]

Erkennung[Bearbeiten | Quelltext bearbeiten]

Um ein Captive Portal zu erkennen, wird vom Betriebssystem im Hintergrund eine spezifische DNS-Domäne abgefragt und versucht eine Ressource mit einer bestimmten URL über HTTP abzurufen. Diese URLs werden in regelmäßigen Abständen, sowie bei der Verbindungsherstellung mit einem LAN oder WLAN angerufen.

Windows

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

Im Fall von Android gibt es den Captive Portal Check.

Mozilla Firefox, Thunderbird und SeaMonkey

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 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. Die dazu nötigen technischen Kenntnisse sind nicht allzu hoch. Dennoch können Captive-Portale dieser Machart eine Berechtigung besitzen, um einem technisch nicht versierten Publikum die Zahlung eines geringen Benutzungsentgelts nahezulegen. Dass das Portal von einem sehr kleinen Anteil potentieller Benutzer überwunden werden kann, wird in Kauf genommen.

Ist die Login-Seite per TLS verschlüsselt, kann das Kennwort nicht abgehört werden. Gelegentlich verursacht SSL Probleme mit älteren Plattformen, die dies nicht unterstützen, z. B. einige Spielekonsolen. Der Einsatz von Einmalkennworten kann die Authentifizierung ebenfalls absichern, da das Kennwort nach einmaliger Nutzung verbraucht ist. Allerdings wird kein ernsthafter Angreifer versuchen das Kennwortsystem zu kompromittieren, wenn er doch einfach IP- und MAC-Adressen mitlesen kann und diese ihm als eigentliche Eintrittskarte ausreichen.

Sichere Captive-Portale müssen hingegen den gesamten Netzwerkverkehr digital signieren oder verschlüsseln, um sicherstellen zu können, dass der Rechner oder Browser, von dem aus das Kennwort eingegeben wurde, auch der Rechner oder Browser ist, mit dem der gesamte weitere Netzwerkverkehr abgewickelt wird. Lösungen auf Basis eines per SSL angesprochenen Proxy-Servers schränken die nutzbaren Dienste auf die ein, die sowohl Proxyserver und die vom Nutzer eingesetzten Programme verstehen. Konkret bedeutet dies meist die Einschränkung auf HTTP und HTTPS. Die dahingehend problemlose Alternative, ein verschlüsseltes Funknetzwerk einzusetzen und jedem Nutzer einen eigenen Schlüssel zur Verfügung zu stellen erfordert eine aufwändigere Konfiguration mittels RADIUS sowie Access Points, die dies auch unterstützen. Viel schwerer wiegt dabei aber, dass die Einrichtung eines verschlüsselten Funknetzwerkes auf ihrem Rechner viele Gelegenheitsnutzer überfordert.

Siehe auch[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. a b c d Hanno Böck: Captive Portals: Ein Workaround, der bald nicht mehr funktionieren wird. In: Golem.de. 8. Februar 2016; abgerufen am 26. Mai 2017.
  2. Captive-Portal Identification in DHCP / RA. In: GitHub. IETF, 15. September 2015; abgerufen am 26. Mai 2017 (englisch).