¿Cómo están logrando esto (ISP), están realmente robando y MITM el tráfico de 8.8.8.8?

Probablemente, simplemente redirigen todos los paquetes con el puerto de destino 53 (es decir, DNS) a sus propios servidores y responden a la consulta ellos mismos. Esto no es tan difícil de hacer.

  

¿Cómo puedo solucionar esto sin VPN?

Una VPN correctamente configurada (es decir, sin fugas de DNS) puede solucionar esto (a menos que también bloqueen la VPN). También el uso de un proxy HTTP o SOCKS puede ayudar (asegúrese de configurar la resolución de nombres externa para el último) para el tráfico HTTP y HTTPS. Y técnicas de privacidad de DNS como dnscurve, dnscrypt, DNS sobre TLS y DNS sobre HTTPS ( soportado ya por Firefox ) también ayudará.

  

lamentablemente no lo están haciendo!

Ellos están haciendo eso, y su escritura tipográfica muestra que está sucediendo, con nslookup consultando esa dirección IP y obteniendo respuestas de ella.

Su confusión se debe en parte a una idea errónea de lo que es 8.8.8.8. Es una dirección IP anycast . El tráfico que se envía a él se enruta a las interfaces de red de varias máquinas en todo el mundo, que ejecuta Google en varios centros de datos. El enrutamiento lo realiza cada nodo al que se envía, incluido el propio ISP inmediatamente después de que abandona la (s) propia (s) red (es).

En primer lugar, el propio Google puede hacer que esas máquinas se comporten de manera diferente en diferentes países. Puede hacer que las máquinas en un país respondan de manera diferente a las máquinas en otros países, si así lo decide, o si es requerido por las autoridades de ese país.

En segundo lugar, los servidores de contenido DNS que Google Public DNS consulta desde su back-end pueden responder de manera diferente a diferentes máquinas de Google. Las direcciones IP de back-end y los países a los que corresponden se publican como parte del documento DNS público de Google. Los servidores DNS de contenido que ofrecen diferentes respuestas a los diferentes clientes (los clientes aquí son el back-end de la resolución de servidores DNS proxy) en función de sus direcciones IP de origen es una característica de varios softwares de servidor DNS.

En tercer lugar, se puede decir a los ISP sujetos a la jurisdicción de un país en particular que simplemente enruten el anycast a otras máquinas bajo el control de alguien que no sea Google. Como sucedió en Turquía en 2014. Se ha afirmado que Taiwan tiene planes similares.

Irán ya estaba haciendo esto un año antes que Turquía. Los ISP iraníes interceptan todo el tráfico DNS / UDP enrutado a través de ellos y responden a él desde máquinas bajo control iraní. Curiosamente, parece que esto no se hace de manera muy competente, ya que los paquetes TCP (¡sic!) Ficticios aún pasan a las máquinas originales.

(Lo mismo sucede con el servicio 1.1.1.1 de Cloudflare, pero menos por razones políticas y de censura y más por la pereza y la insensatez humanas. Durante mucho tiempo se ha utilizado como una dirección IP de prueba o como un rango de direcciones IP extra privadas no oficiales, Por enrutadores de programación de personas y otros.

Por supuesto, si uno organiza el tráfico de DNS deja su propia máquina a través de la VPN en lugar de hacerlo directamente a su ISP, entonces los tres cambian. El tráfico va a través de la VPN a una máquina de Google diferente en un país diferente, que envía sus consultas de back-end desde una dirección IP de origen diferente, y que no es enrutado a 8.8.8.8 por el ISP de uno.

La desventaja de aparecer como si uno estuviera en un país diferente para el servicio DNS es aparecer como si estuviera en un país diferente , como descubrieron los australianos que usaron el DNS público de Google en 2010. Los CDN dirigen uno a los servidores HTTP de contenido que están mucho más lejos y no son locales. Los servicios que son gratuitos o de bajo costo, pero solo dentro del propio país, vienen repentinamente de servidores HTTP de contenido caros.

Lectura adicional

• Steven Carstensen (2014-03-29). DNS público de Google interceptado en Turquía . Seguridad de Google.
• Kieren McCarthy (2017-05-11). " El gobierno de Taiwán bloqueará el DNS público de Google a favor de HiNet's ". El Registro .
• Dan Warne (2010-05-19). " Por qué usar Google DNS / OpenDNS es una mala idea ". APC Magazine .
• Aryan et al. (2013-08). Censura de Internet en Irán: Una primera mirada .
• enlace
• enlace
• enlace
• enlace

En resumen, estás siendo MITMed. El censor al que te enfrentas está haciendo algo a tus solicitudes de DNS dirigidas al 8.8.8.8 para que obtengas respuestas no genuinas. Hay muchas maneras de lograr esto, y diferentes entidades ejecutan esta censura por diferentes medios. Para ver más de cerca, use su herramienta favorita de captura de paquetes (Wireshark o tcpdump ).

Como demostración, he tomado una captura de mí al consultar el servidor DNS de Google en 8.8.8.8 para las direcciones de "www.google.com".

ComosepuedeverenlacapturadepantalladeWireshark,micomputadoraenvíadosconsultasDNSalservidorDNS,unaparaelregistroA(direccionesIPv4)yotraparaelregistroAAAA(direccionesIPv6).Paracadasolicitud,serecibieron3respuestas.Lasprimerasdosrespuestascontienendireccionesfalsasy,curiosamente,lasdosprimerasrespuestasparalaconsultaAAAAcontienenunregistroAenlarespuesta,claramenteunarespuestamalformada.LatercerayúltimarespuestaparacadasolicitudcontieneladirecciónIPrealdewww.google.com.Laherramientanslookup,sinsabernadamejor,aceptólaprimerarespuestaparacadasolicitudymostróesasdirecciones.

Estosugiereloqueestáhaciendomicensuranacional.Evidentemente,noestánbloqueandoeltráficodereda8.8.8.8deformaabsoluta.Ensulugar,monitoreandichotráficoy,cuandoseencuentraunasolicituddeDNSparaundominiobloqueado,elcensorinyectarespuestasfalsas.ElcensornopuedemolestarseencrearunarespuestaadecuadadeAAAA,deahílasrespuestasmalformadas.LasrespuestasauténticasdelservidorDNSrealtampocoseeliminan.Sinembargo,lasprimerasrespuestasfalsassonsuficientesparaengañaralclientequerealizólasolicituddeDNSparaqueaceptedireccionesfalsas.

Sucensorpodríaestarhaciendoalgosimilar,opodríaestarhaciendoalgocompletamentediferente.Tomaalgunascapturasdepaquetes,ypodríamosdartemásinformación.

Encuantoacómosolucionaresto,larespuestaprácticaesprobablementeunproxyDNSencriptadolocal,como DNSCrypt Proxy o Stubby . Estas herramientas ejecutan un servidor DNS en su computadora, y las solicitudes de DNS dirigidas a ellas se cifrarán y se enviarán a un servidor DNS que entienda el protocolo de cifrado. De esta manera, el censor no puede saber para qué dominio está la solicitud y no puede falsificar respuestas. Sin embargo, el censor todavía puede bloquear estos servidores directamente.

(Si está tratando de eludir un censor nacional, la eliminación del envenenamiento de DNS por sí sola puede no ser suficiente. Es posible que necesite usar diferentes herramientas para diferentes ocasiones).

Ya que está ejecutando Linux, una forma sencilla de evitar esto sin una VPN completa es el tunelling SSH. Si puede configurar u obtener una cuenta en un servidor en una ubicación neutral, sin filtro, puede canalizar su tráfico a través de esa ubicación utilizando SSH con solo un par de comandos. Puede canalizar su tráfico de dns en el puerto 53 y su tráfico web a través de la máquina remota.

Puede usar una instancia de Amazon Web services o Google Compute Engine, o simplemente un vps remoto regular.

enlace

enlace

Lo que acabo de aprender es que no importa qué servidor de nombres elijas. El tráfico DNS está siendo interceptado en su totalidad!

kasra@ubuntu:~$ nslookup youtube.com 80.80.81.81
Server:     80.80.81.81
Address:    80.80.81.81#53

Non-authoritative answer:
Name:   youtube.com
Address: 10.10.34.35
Name:   youtube.com
Address: 10.10.34.35

kasra@ubuntu:~$ nslookup youtube.com 80.80.80.80
Server:     80.80.80.80
Address:    80.80.80.80#53

Non-authoritative answer:
Name:   youtube.com
Address: 10.10.34.35
Name:   youtube.com
Address: 10.10.34.35

kasra@ubuntu:~$ nslookup youtube.com 1.1.1.1
Server:     1.1.1.1
Address:    1.1.1.1#53

Non-authoritative answer:
Name:   youtube.com
Address: 10.10.34.35
Name:   youtube.com
Address: 10.10.34.35

kasra@ubuntu:~$ nslookup youtube.com 4.4.4.4
Server:     4.4.4.4
Address:    4.4.4.4#53

Non-authoritative answer:
Name:   youtube.com
Address: 10.10.34.35
Name:   youtube.com
Address: 10.10.34.35

kasra@ubuntu:~$ nslookup youtube.com 2.2.2.2
Server:     2.2.2.2
Address:    2.2.2.2#53

Non-authoritative answer:
Name:   youtube.com
Address: 10.10.34.35
Name:   youtube.com
Address: 10.10.34.35

kasra@ubuntu:~$ nslookup youtube.com 8.8.8.8
Server:     8.8.8.8
Address:    8.8.8.8#53

Non-authoritative answer:
Name:   youtube.com
Address: 10.10.34.35
Name:   youtube.com
Address: 10.10.34.35

kasra@ubuntu:~$ nslookup youtube.com 7.7.7.7
Server:     7.7.7.7
Address:    7.7.7.7#53

Non-authoritative answer:
Name:   youtube.com
Address: 10.10.34.35
Name:   youtube.com
Address: 10.10.34.35

kasra@ubuntu:~$ nslookup youtube.com 9.9.9.9
Server:     9.9.9.9
Address:    9.9.9.9#53

Non-authoritative answer:
Name:   youtube.com
Address: 10.10.34.35
Name:   youtube.com
Address: 10.10.34.35

kasra@ubuntu:~$ nslookup youtube.com 10.10.10.10
Server:     10.10.10.10
Address:    10.10.10.10#53

Non-authoritative answer:
Name:   youtube.com
Address: 10.10.34.35
Name:   youtube.com
Address: 10.10.34.35

kasra@ubuntu:~$ nslookup youtube.com 10.10.10.22
Server:     10.10.10.22
Address:    10.10.10.22#53

Non-authoritative answer:
Name:   youtube.com
Address: 10.10.34.35
Name:   youtube.com
Address: 10.10.34.35

kasra@ubuntu:~$ nslookup youtube.com 23.23.23.33
Server:     23.23.23.33
Address:    23.23.23.33#53

Non-authoritative answer:
Name:   youtube.com
Address: 10.10.34.35
Name:   youtube.com
Address: 10.10.34.35

kasra@ubuntu:~$ nslookup youtube.com 200.100.23.432
nslookup: couldn't get address for '200.100.23.432': not found
kasra@ubuntu:~$ nslookup youtube.com 200.100.23.44
Server:     200.100.23.44
Address:    200.100.23.44#53

Non-authoritative answer:
Name:   youtube.com
Address: 10.10.34.35
Name:   youtube.com
Address: 10.10.34.35

kasra@ubuntu:~$