¿Cómo este "portal cautivo" intercepta y manipula mis solicitudes HTTP?

28

A veces utilizo un servicio Wifi gratuito para acceder a Internet.
Como la mayoría / todos los proveedores de servicios como este, este servicio emplea un portal cautivo . Entonces, si intenta realizar una solicitud HTTP (solicitar una página web) en su navegador y no está autorizado en la red, solo verá la página que dice "Bienvenido a la red de Free -wifi. Aquí están nuestros términos etc ... "
No estoy interesado en abusar del servicio para wifi gratuito. Quiero saber qué información (transacciones HTTP) está expuesta / insegura cuando uso este servicio y qué cambios persistentes están realizando en mi sistema, es decir, ocultar cookies en mi navegador ( usando hosts anónimos).
Así que me conecté a su punto de acceso wifi, momento en el que asignaron a mi computadora una dirección IP y un servicio DNS, etc.

$ 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

Luego intento realizar una solicitud HTTP: intente "navegar a una página web" mientras aún no esté autorizado. (Al ser HTTP, esta solicitud / respuesta no estará encriptada, no habrá verificación de identidad en el servidor que maneja la solicitud [a través de la confirmación de la autoridad de certificación SSL a través de firmas de claves públicas / privadas, etc.])

$ 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>

He truncado y rediseñado la salida, pero básicamente parece que, cuando mi navegador (curl) hace una solicitud, la red está proporcionando acceso a un servidor DNS real, lo probé aún más al ejecutarlo mientras estaba conectado al servicio .

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

Parece que el servicio está proporcionando información real y veraz sobre DNS,

Pero a pesar de que la dirección IP a la que se dirige mi navegador parece válida, la respuesta HTTP está regresando, no proviene del servidor deseado (es un servidor que ha sido insertado por el servicio WiFi). La respuesta es

  • 302 le dice a mi navegador que realice una nueva solicitud al 1.1.2.1/reg.php server y URL
  • la respuesta de ese servidor / URL es la página del "portal cautivo".

Cuando realice una solicitud HTTPS

$ 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

La solicitud falla totalmente. ¿Supongo que mi computadora no aceptará una conexión de un host remoto que no pueda autenticar?
Entonces, mi pregunta es: ¿es esto una intercepción de tipo "hombre en el medio" en el nivel TCP / IP? en otras palabras, cuando la pila de la red en mi computadora intenta establecer una conexión TCP con el servidor placeimg.com , iniciando un protocolo de enlace de 3 vías, es la puerta de enlace de los servicios Wifi o el nodo de red que responde a mi SYN con un ACK / SYN y dice sí, soy el servidor con el que quería hablar: completemos nuestra conexión TCP , luego, una vez establecido, está preprogramado para enviar automáticamente la redirección HTTP y luego, porque mi navegador está generando la siguiente solicitud a 1.1.2.1 : todos los "negocios divertidos" pueden detenerse y su comportamiento HTTP / HTML es normal desde ese momento en adelante. (es decir, llenado de formularios estándar y envíos como lo haría en cualquier sitio web normal)
De no ser así, ¿cómo está esta puerta de enlace interceptando y reencaminando mis solicitudes mientras soy un usuario "no autenticado"?

    
pregunta the_velour_fog 08.08.2016 - 05:51
fuente

2 respuestas

32
  

Entonces, mi pregunta es, ¿es esto una intercepción de tipo "hombre en el medio" en el nivel TCP / IP?

Sí, este es un hombre en la intercepción de tipo medio que es fácil para el punto de acceso porque en realidad está en el medio de su conexión a Internet. Tales redirecciones al portal de captura se realizan fácilmente con un filtro de paquetes.

La forma habitual es que una vez que haya autorizado (iniciado sesión, términos aceptados, lo que sea ...) se agregará una regla temporal al filtro de paquetes del punto de acceso, que tiene preferencia sobre la regla de redirección y permite el acceso directo a la Internet.

    
respondido por el Steffen Ullrich 08.08.2016 - 06:20
fuente
8
  

Al realizar una solicitud HTTPS La solicitud falla totalmente. ¿Supongo que mi computadora no aceptará una conexión desde un host remoto que no pueda autenticar?

Parece que ni siquiera están intentando interceptar tu conexión HTTP y, en cambio, simplemente la están bloqueando.

Algunos portales cautivos intentarán interceptar la conexión HTTP que da como resultado un error de certificado en su cliente.

También he visto algunos portales cautivos que permiten HTTPs, incluso para usuarios no autenticados.

  

Entonces, mi pregunta es, ¿es esto una intercepción de tipo "hombre en el medio" en el nivel TCP / IP? en otras palabras, cuando la pila de la red en mi computadora intenta establecer una conexión TCP con el servidor de placeimg.com, iniciando un protocolo de enlace de 3 vías, es la puerta de enlace de los servicios Wifi o el nodo de la red que responde a mi SYN con un ACK / SYN y dice Sí, soy el servidor con el que quería hablar: completemos nuestra conexión TCP, luego, una vez establecido, está preprogramado para enviar automáticamente el redireccionamiento HTTP y luego, porque mi navegador está generando la próxima solicitud al 1.1.2.1 en sí. el "negocio divertido" puede detenerse y todo su comportamiento normal de HTTP / HTML a partir de ese momento. (es decir, llenado de formularios estándar y envíos como lo haría en cualquier sitio web normal)

Sí, esa es la forma normal de hacerlo. Si el servidor de portal cautivo está basado en Linux, los objetivos "REDIRECCIONAR" o "DNAT" se pueden usar para desviar su tráfico al servidor web de portales cautivos, que luego puede emitir la redirección. Es probable que otros sistemas de firewall con estado tengan opciones similares.

Estos sistemas generalmente son bastante flexibles, por lo que si el operador del portal quiere ofrecer acceso a partes específicas de Internet (por ejemplo, una pasarela de pago para que pueda pagarlos) sin autenticación, pueden hacerlo fácilmente.

Cuando se autentica con éxito, el portal cautivo puede establecer una regla que invalida la regla de redirección que le permite el acceso normal a Internet.

Tenga en cuenta que todas las cookies (no seguras) establecidas para el sitio web que intentó visitar se enviarán al servidor web del portal cautivo. Depende del implementador del portal cautivo si realmente hacen algo con ellos.

    
respondido por el Peter Green 08.08.2016 - 18:50
fuente

Lea otras preguntas en las etiquetas