entrar registro

Cómo saltarse la SENSURA de los ISPs

603 visitas
|
votos: 11 · 1
|
karma: 117
|

Como ya sabeis, hay días y días, y tengo días para todo. La cosa es que, desde que volví de mi último periplo, uno de mis colegas me dio una idea interesante que he testeado y puesto en ejecución.

Contexto: ¿qué saben de nosotros los ISPs y los grandes proveedores? Pues mucho, y si tienen acceso a nuestras visitas, pueden saber mucho acerca de nuestro comportamiento en la red. Por ejemplo

- Apps que usamos
- Webs que visitamos
- Frecuencia del uso

Eso ya da bastante idea de qué pasa, porque que el gran hermano nos vigila, ni cotiza. Normalmente, si uno quiere asegurarse el tiro y entrar en el internete con un mínimo de privacidad, puede usar TOR y conectarse con bastante tranquilidad si uno no lo usa para ciertas cosas (como comprar drogainas o un lanzamisiles traspapelado de los americanos en Ucrania). Y esto es porque todas las peticiones de DNS van en claro por el puerto 53, DNSSEC aún está lejos de ser estándar (y por mucho que los navegadores digan que sí, en realidad no se usa).

Por tanto, y asumiendo que los ISP y los grandes proveedores como Cloudfare, Google, y Meta viven de nuestros metadatos, hice el ejercicio de saber hasta qué punto son unos chapuceros para implementar el bloqueo a sitios web como www.rt.com y similares, que están vetados en Europa.
Por defecto, los ISP te mandan a un "black hole" o en su defecto a una página cautiva que dice que el acceso está restringido.

Y esto, amigüitos, recordad, es porque el DNS es Domain Name Service. La piedra angular de todo Internet: el resolutor de nombres que identifica un sitio con una dirección IP.

En estos tiempos, tener un DNS recursivo local es casi una rareza: entre que todos los proveedores proporcionan el servicio por defecto y que requiere un mínimo de conocimiento, es una tarea si no tediosa, poco gratificante. En resumen, se puede resumir en:

1) Descargar los root.hints www.iana.org/domains/root/files
2) Configurar al gusto el demonio (bind9, unbound)
3) Asegurar que el sistema local no está ejecutando ningún servicio en el puerto 53
4) Arrancar el servicio y testear

Con esto, he podido comprobar que mi proveedor no bloquea por CIDR el acceso a según que webs, y que puedo leer www.rt.com sin problema alguno.

Nota al pie, super importante.
Si quieres hacer algo super ilegal, o dudoso (como conectar a rojadirecta.com), necesitas al menos una VPN contra otro sitio donde empezar a hacer canalladas, el gran hermano podría hacer reverse DNS a cualquiera de las IPs que hemos resuelto.

Segunda nota al pie:
Muchos sitios bloquean o distribuyen contenido según el bloque CIDR asignado a cada país, por lo que no espereis ver cosas diferentes en el catálogo de Netflix. Como decía arriba, eso necesita una VPN.

P.D.
Hay cientos de tutoriales para ello. Yo lo he montado en un Mac Mini con Linux, un core i5 de cuarta generación, que tengo ocioso por aquí. Lo dejaré en marcha a ver cuanto me sube la luz :troll:

comentarios (21)
  1. juanda
    Muy bueno, yo si que tengo acceso a RT.com sin haber implementado nada, igual mi ISP no me lo ha bloqueado, aún, pero me lo guardo para cuando quiera hacer alguna malesetes
    3    k 69
  2. Injustice_Marvin
    #0 El artículo en si es un delito de odio, odio a la censura y te encontrarán.
    2    k 60
  3. macarty
    #2 odiar es muy cansado, simplemente lo que lw digo a la sensura es que no me interesa.
    2    k 60
  4. macarty
    #1 depende de los DNS que uses, básicamente.
    1    k 40
  5. juanda
    #4 Recuerdo hace tiempo intentar cambiarlos en el router de la compañía, creo que están como "valores fijos" a menos que lo rutee, pero tampoco me quería complicar la vida así que los dejé como están... .eso, o sí los cambié pero al acceder al router me sigue mostrando los originales, aunque lo dudo.
    2    k 60
  6. AshMostaza
    Ya todo depende #4. AHora mismo con las DNS de google no puedes entrar por ejemplo en epublibre ni en RT.
    1    k 40
  7. macarty
    #5 puedes cambiarlo simplemente modificando el servicio DHCP
    2    k 60
  8. Juan_Nervion
    #1 Ya.... nos hemos dado cuenta.
    0    k 18
  9. juanda
    #7 Lo miraré!!! Gracias
    1    k 40
  10. jimyx17
    Esto en realidad tiene las patas muy cortas.
    Un ISP puede hacer literalmente lo que quiera con los datos que envías o recibes e tu casa. Si te montas un DNS en tu casa o utilizas otro servicio DNS te puede valer si el operador no quiere controlarte. En caso contrario, el ISP tiene muy fácil redirigir todas las peticiones DNS que salen de casa de sus clientes y contestar a esas consultas como mejor les parezca.
    Tecnicamente, DNS no se pensó para un contexto como el actual donde y con la seguridad en la cabeza... Se diseñó para resolver un problema y lo hizó con mucho éxito.

    PD: ojito con las VPN, cuando te conectas a una, el que aloja esa VPN controla todo tu tráfico (exactamente igual que tu ISP actual). Piensa cuanto confias en ese proveedor de VPN en comparación con tu proveedor de internet.
    0    k 8
  11. Josdete
    #1 Yo tambien la tengo sin problemas y mi ISPs es Rovafone.
    0    k 20
  12. Josdete
    #4 Yo uso las de Cloudflare 1.1.1.1 y 1.0.0.1
    0    k 20
  13. pcaro
    #10 El DNS se puede cifrar usando HTTPS por ejemplo.
    1    k 27
  14. macarty
    #14 macarty
     *
    #12 te puedo dar unas estadísticas de mi triste cacharro: tiene mejor tiempo de respuesta que cloudfare xD

    (nota: es cierto que hago algo de trampa y aparte de dns recursivo, hace caché)
    0    k 20
  15. Josdete
    #15 Josdete
     *
    #14 Cloudfare sus dns no me va mal, las que me fueron como el culo fue las de google .
    1    k 40
  16. macarty
    #16 macarty
     *
    #15 No, si no te lo discuto, pero el hecho de reducir el tiempo de transaccion al entorno del milisegundo, ha mejorado horrores el tiempo de respuesta de todo en casa (¡y no transfiero metadatos a nadie!)


    me@flowerpower:~$ time dig @192.168.1.2 www.google.com

    ; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> @192.168.1.2 www.google.com
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 11984
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 1232
    ;; QUESTION SECTION:
    ;www.google.com. IN A

    ;; ANSWER SECTION:
    www.google.com. 282 IN A 142.250.200.100

    ;; Query time: 0 msec
    ;; SERVER: 192.168.1.2#53(192.168.1.2) (UDP)
    ;; WHEN: Thu Sep 19 09:59:19 CEST 2024
    ;; MSG SIZE rcvd: 59


    real 0m0,028s
    user 0m0,010s
    sys 0m0,005s
    me@flowerpower:~$ time dig @1.1.1.1 www.google.com

    ; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> @1.1.1.1 www.google.com
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; >>HEADER<< opcode: QUERY, status: NOERROR, id: 24886
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 1232
    ;; QUESTION SECTION:
    ;www.google.com. IN A

    ;; ANSWER SECTION:
    www.google.com. 300 IN A 142.250.184.164

    ;; Query time: 16 msec
    ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
    ;; WHEN: Thu Sep 19 09:59:30 CEST 2024
    ;; MSG SIZE rcvd: 59


    real 0m0,042s
    user 0m0,011s
    sys 0m0,005s
    0    k 20
  17. macarty
    #17 macarty
     *
    #10 con un DNS recursivo, usando DNSSEC está muy complicado que te controlen incluso si quieren. No es imposible, de todas formas, especialmente porque el DNS normal va en claro. Y siempre pueden recurrir a analizar el tráfico de origen a destino, bloquear por rango CIDR, entre muchas otras cosas. Por lo demás, con un DNS recursivo sólo se ha de evitar el DNS poisoning, que de eso no te libra nadie.
    0    k 20
  18. jimyx17
    #17 Para poder usar DNSSEC lo tiene que soportar el dominio al que te conectas y el autoritativo de ese dominio, no vas a encontrar muchos dominios bien configurados. Para colmo, la implementación de windows depende en que el dns caché soporte DNSSec. Es increiblemente sencillo para cualquier operador entre otras cosas suplantar redirigir todo tu tráfico DNS saliente y hacere pasar por cualquier DNS caché como los de google o los open DNS.
    Montarte tu DNS recursivo (el DNS caché vamos....) tampoco te libra, con interceptar el tráfico saliente a los root DNS el ISP volvería a tomar el cotrol.
    0    k 8
  19. jimyx17
    #13 No, no puedes cifrar las peticiones DNS con HTTPS.
    Con HTTPS puedes cifrar la url a la que te conectas, no las peticiones DNS. Y desde hace años cifrar el dominio se dejó de hacer. Desde que incorporaron la extensión SNI a HTTPS para permitir a los servidores tomar decisiones en función del dominio que el cliente solicita.
    0    k 8
  20. jimyx17
    #20 Ya... Entiendes como funciona ¿no? Porque es exactamente lo mismo que haría un OpenSSL o cualquier túnel ssl que ya he comentado en los post de antes.
    Por supuesto que ocultaría tus peticiones DNS, bueno, más bien parte de ellas, porque todo aquello que no sea navegador seguirá con DNS.
    Por tanto, tiene los mismos problemas que un proxy o una VPN, que cambias al operador del servidor https del otro lado por el operador del servicio.
    Por último... Incluso si de verdad el operador no pudiese ver la query y el nombre en claro, te recuerdo que el operador (por narices) es tu punto de entrada en la red y va a saber las direcciones a las que envías trafico. ¿Cuanto crees que cuesta hacer una resolución inversa o revisar los registros de ripe, una y cia?
    Si quieres privacidad, lo más cercano es la red tor... Y ni por esas.
    0    k 8
suscripciones por RSS
ayuda
+mediatize
estadísticas
mediatize
mediatize