it-swarm.com.de

Wie fängt dieses "Captive-Portal" meine HTTP-Anfragen ab und bearbeitet sie?

Ich benutze manchmal einen kostenlosen Wifi-Service, um Zugang zum Internet zu erhalten.
Wie die meisten/alle Anbieter solcher Dienste verwendet dieser Dienst ein Captive-Portal . Wenn Sie also versuchen, eine HTTP-Anfrage (eine Webseite anzufordern) in Ihrem Browser zu stellen und nicht im Netzwerk autorisiert sind, wird immer nur die Seite mit der Aufschrift "Willkommen bei Free" angezeigt -wifi Netzwerk. Hier sind unsere Begriffe etc ... "
Ich bin nicht daran interessiert, den Dienst für kostenloses WLAN zu missbrauchen. Ich möchte wissen, welche Informationen (HTTP-Transaktionen) bei der Verwendung dieses Dienstes verfügbar/unsicher sind und welche dauerhaften Änderungen sie an meinem System vornehmen, dh verbergen Cookies in meinem Browser (unter Verwendung anonymer Hosts).
Also habe ich eine Verbindung zu ihrem WLAN-Zugangspunkt hergestellt. An diesem Punkt weisen sie meinem Computer eine IP-Adresse und einen DNS-Dienst usw. zu.

$ nmcli device show wlp2s0
IP4.ADDRESS[1]:                         192.168.12.199/22
IP4.GATEWAY:                            192.168.12.1
IP4.ROUTE[1]:                           dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000
IP4.DNS[1]:                             123.123.xxx.xxx
IP4.DNS[2]:                             123.123.xxx.xxx

Ich versuche dann eine HTTP-Anfrage - versuche "zu einer Webseite zu navigieren", solange ich noch nicht autorisiert bin. (Da HTTP diese Anforderung/Antwort unverschlüsselt ist, erfolgt keine Identitätsprüfung auf dem Server, der die Anforderung verarbeitet [über Bestätigung der SSL-Zertifizierungsstelle über Signaturen mit öffentlichen/privaten Schlüsseln usw.])

$ curl 'http://placeimg.com/' -H 'Host: placeimg.com'  
-H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0' 
-H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8'  -v -L
*   Trying 216.243.142.217...
* Connected to placeimg.com (216.243.142.217) port 80 (#0)
> GET / HTTP/1.1
> Host: placeimg.com
>
< HTTP/1.1 302 Found
< Location: http://1.1.2.1:80/reg.php?ah_goal=auth-tc.html&ah_login=true&url=E2B8F357812412D8
<
* Ignoring the response-body
* Connection #0 to Host placeimg.com left intact
* Issue another request to this URL:  
       'http://1.1.2.1:80/reg.php?ah_goal=auth-tc.html&ah_login=true&url=E2B8F35792412D8'
* Connection 0 seems to be dead!
* Closing connection 0
*   Trying 1.1.2.1...
* Connected to 1.1.2.1 (1.1.2.1) port 80 (#1)
> GET /reg.php?ah_goal=auth-tc.html&ah_login=true&url=E2B8F8 HTTP/1.1
> Host: 1.1.2.1
> User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> Accept-Language: en-US,en;q=0.5
>
< HTTP/1.1 200 OK
< Date: Mon, 08 Aug 2016 02:50:16 GMT
< Connection: keep-alive
< Transfer-Encoding: chunked
< Content-type: text/html; charset=utf-8
<
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">

<head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
        <meta name="viewport" content="width=device-width"/>
        <title>Login</title>
        <h1>WiFi - Free Internet Access</h1>
This service is provided primarily for the purposes of accessing Email and light web browsing ..
....
</div>
</body>
</html>

Ich habe die Ausgabe abgeschnitten und redigiert, aber im Wesentlichen scheint es so, als ob mein Browser (Curl) eine Anfrage stellt, dass das Netzwerk Zugriff auf einen echten DNS-Server gewährt. Ich habe dies weiter getestet, indem ich dies ausgeführt habe, während ich mit dem Dienst verbunden war.

$Dig +short google.com
203.118.141.95
203.118.141.123
... (basically real ip addresses for google.com)

Es scheint also, dass der Dienst echte, wahrheitsgemäße Informationen über DNS liefert.

Obwohl die IP-Adresse, die mein Browser adressiert, gültig zu sein scheint, stammt die zurückkommende HTTP-Antwort nicht vom vorgesehenen Server (es handelt sich um einen Server, der vom WiFi-Dienst eingefügt wurde). Die Antwort ist

  • 302 meinem Browser mitteilen, dass er eine neue Anfrage an das 1.1.2.1/reg.php Server und URL
  • die Antwort von diesem Server/dieser URL ist die Seite "Captive Portal".

Wenn Sie eine HTTPS-Anfrage stellen

$ curl 'https://google.com/' -H 'Host: google.com' -H 'User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0' -H 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8' -H 'Accept-Language: en-US,en;q=0.5' -v -L
*   Trying 216.58.220.142...
* connect to 216.58.220.142 port 443 failed: Connection refused
*   Trying 2404:6800:4006:800::200e...
* Immediate connect fail for 2404:6800:4006:800::200e: Network is unreachable
*   Trying 2404:6800:4006:800::200e...
* Immediate connect fail for 2404:6800:4006:800::200e: Network is unreachable
* Failed to connect to google.com port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to google.com port 443: Connection refused

Die Anforderung schlägt sofort fehl. Ich gehe davon aus, dass mein Computer keine Verbindung von einem Remote-Host akzeptiert, den er nicht authentifizieren kann.
Meine Frage ist also, ist dies ein Abfangen vom Typ "Mann in der Mitte" auf TCP/IP-Ebene? Mit anderen Worten, wenn der Netzwerkstapel auf meinem Computer versucht, eine TCP -Verbindung mit dem placeimg.com Server ist durch Starten eines 3-Wege-Handshakes das Wifi-Dienst-Gateway oder der Netzwerkknoten, der auf mein SYN mit einem ACK/SYN antwortet und sagt : Ja, ich bin der Server, mit dem Sie sprechen möchten - Lassen Sie uns unsere TCP -Verbindung ) abschließen, sobald sie vorprogrammiert ist, um die HTTP-Umleitung automatisch zu senden, und dann, weil mein Browser tatsächlich die nächste Anforderung generiert zu 1.1.2.1 selbst - all das "lustige Geschäft" kann aufhören und sein normales HTTP/HTML-Verhalten von diesem Punkt an. (dh Standardformular ausfüllen und einreichen wie auf jeder normalen Website)
Wenn nicht, wie fängt dieses Gateway meine Anforderungen ab und leitet sie weiter, während ich ein "nicht authentifizierter" Benutzer bin?

29
the_velour_fog

Meine Frage ist also, ist dies ein Abfangen vom Typ "Mann in der Mitte" auf TCP/IP-Ebene?

Ja, dies ist ein Mann in der mittleren Art des Abfangens, was für den Zugangspunkt einfach ist, da er sich tatsächlich in der Mitte Ihrer Verbindung zum Internet befindet. Solche Weiterleitungen zum Erfassungsportal können einfach mit einem Paketfilter durchgeführt werden.

Der übliche Weg ist, dass nach der Autorisierung (angemeldet, akzeptierte Bedingungen, was auch immer ...) dem Paketfilter des Zugangspunkts eine temporäre Regel hinzugefügt wird, die die Umleitungsregel bevorzugt und den direkten Zugriff auf das Internet ermöglicht .

33
Steffen Ullrich

Wenn eine HTTPS-Anfrage gestellt wird Die Anfrage schlägt sofort fehl. Ich gehe davon aus, dass mein Computer keine Verbindung von einem Remote-Host akzeptiert, den er nicht authentifizieren kann.

Es scheint, dass sie nicht einmal versuchen, Ihre HTTP-Verbindung abzufangen, sondern sie nur blockieren.

Einige Captive-Portale versuchen, die HTTP-Verbindung abzufangen, was zu einem Zertifikatfehler in Ihrem Client führt.

Ich habe auch einige Captive-Portale gesehen, die HTTPs auch für nicht authentifizierte Benutzer zulassen.

Meine Frage ist also, ist dies ein Abfangen vom Typ "Mann in der Mitte" auf TCP/IP-Ebene? Mit anderen Worten, wenn der Netzwerkstapel auf meinem Computer versucht, eine TCP -Verbindung mit dem placeimg.com-Server herzustellen, indem ein 3-Wege-Handshake gestartet wird, reagiert das Wifi-Dienst-Gateway oder der Netzwerkknoten darauf Mein SYN mit einem ACK/SYN und Ja, ich bin der Server, mit dem Sie sprechen wollten. Vervollständigen Sie unsere TCP -Verbindung) und stellen Sie die vorprogrammierte Verbindung her, um die HTTP-Umleitung und automatisch zu senden dann, weil mein Browser tatsächlich die nächste Anfrage an 1.1.2.1 selbst generiert - das ganze "lustige Geschäft" kann aufhören und sein normales HTTP/HTML-Verhalten von diesem Punkt an (dh das Ausfüllen und Senden von Standardformularen, wie Sie es tun würden) jede normale Website)

Ja, das ist der normale Weg. Wenn der Captive-Portal-Server auf Linux basiert, können die Ziele "REDIRECT" oder "DNAT" verwendet werden, um Ihren Datenverkehr zum Webserver für Captive-Portale umzuleiten, der dann die Umleitung ausgeben kann. Andere Stateful-Firewall-Systeme haben wahrscheinlich ähnliche Optionen.

Diese Systeme sind im Allgemeinen recht flexibel. Wenn der Portalbetreiber also den Zugriff auf bestimmte Teile des Internets (z. B. ein Zahlungsgateway, damit Sie sie bezahlen können) ohne Authentifizierung anbieten möchte, können sie dies problemlos tun.

Wenn Sie sich erfolgreich authentifizieren, kann das Captive-Portal eine Regel einrichten, die die Umleitungsregel überschreibt und Ihnen den normalen Zugriff auf das Internet ermöglicht.

Beachten Sie, dass alle (nicht sicheren) Cookies, die für die Website gesetzt wurden, die Sie besuchen wollten, an den Webserver des Captive-Portals gesendet werden. Es liegt beim Implementierer des Captive-Portals, ob er tatsächlich etwas mit ihnen macht.

9
Peter Green