Una mejora práctica en el Transporte DNS sobre UDP en IPv6

Por Hugo Salgado y Alejandro Acosta

Introducción y planteamiento del problema

En el presente documento queremos discutir sobre un draft (borrador de trabajo para convertirse en un estándar) existente en IETF que llamó nuestra atención, es un documento que involucra dos mundos muy interesantes: IPv6 y DNS. Este draft introduce algunas mejores prácticas para el transporte de DNS sobre IPv6.

El draft se titula “DNS over IPv6 Best Practices” y se puede encontrar aquí.

¿De qué trata el documento y qué busca solucionar?

El documento describe un enfoque sobre cómo el Protocolo de Nombres de Dominio (DNS) debería transmitirse sobre IPv6 [RFC8200].

Se han identificado algunos problemas operativos al enviar paquetes de DNS a través de IPv6, el draft busca solucionar estos problemas.

Contexto técnico

El protocolo IPv6 exige un tamaño mínimo de unidad de transmisión (MTU) de 1280 octetos. Según la Sección 5 “Problemas de tamaño de paquete” del RFC8200, se establece que cada enlace en Internet debe tener un MTU de 1280 octetos o más. Si un enlace no puede transmitir un paquete de 1280 octetos en una sola pieza, se debe proporcionar el servicio de fragmentación y reensamblaje específicos del enlace en una capa inferior a IPv6.

Funcionamiento exitoso de PMTUD en un ejemplo adaptado a MTU de 1280 bytes

Imagen tomada de: https://www.slideshare.net/slideshow/naveguemos-por-internet-con-ipv6/34651833#2

Utilizando el Descubrimiento de MTU de Ruta (PMTUD) y la fragmentación en IPv6 (solo en el origen), se pueden enviar paquetes más grandes. Sin embargo, la experiencia operativa indica que enviar grandes paquetes de DNS sobre UDP en IPv6 resulta en altas tasas de pérdida. Algunos estudios -ya de muchos años, pero sirven de contexto- han encontrado que aproximadamente 10% de los routers en IPv6 descartan todos los fragmentos IPv6, y 40% de ellos bloquean los mensajes “Packet Too Big”, que hacen imposible la negociación de los clientes. (“M. de Boer, J. Bosma, ”Discovering Path MTU black holes on the Internet using RIPE Atlas”)

La mayoría de los protocolos de transporte modernos, como TCP [TCP] y QUIC [QUIC], incluyen técnicas de segmentación que permiten enviar flujos de datos más grandes sobre IPv6.

Un poco de historia

El Sistema de Nombres de Dominio (DNS) fue definido originalmente en los documentos RFC 1034 y RFC 1035. Está diseñado para funcionar sobre diferentes protocolos de transporte, incluyendo UDP y TCP, y más recientemente se ha extendido para operar sobre QUIC. Estos protocolos de transporte pueden utilizarse tanto en IPv4 como en IPv6.

Al diseñar el DNS, se estableció un límite en el tamaño de los paquetes DNS transmitidos por UDP a 512 bytes. Si un mensaje era más largo, se truncaba y se activaba el bit de Truncamiento (TC) para indicar que la respuesta estaba incompleta, permitiendo que el cliente intentara nuevamente con TCP.

Con este comportamiento original, UDP sobre IPv6 no excedía el MTU (unidad máxima de transmisión) del enlace IPv6, evitando problemas operativos por fragmentación. Sin embargo, con la introducción de las extensiones EDNS0 (RFC6891) se amplió el máximo hasta un teórico de 64KB, con lo que algunas respuestas superaban el límite de 512 bytes para UDP, lo que resultó en tamaños que podrían exceder el Path MTU, ocasionando conexiones TCP y afectó la escalabilidad de los servidores DNS.

Encapsulamiento de un paquete DNS en un frame ethernet

Hablemos de DNS sobre IPv6

DNS sobre IPv6 está diseñado para funcionar sobre UDP, así como TCP o QUIC. UDP solo proporciona puertos de origen y destino, un campo de longitud y una suma de verificación simple, y es un protocolo sin conexión. En contraste, TCP y QUIC ofrecen características adicionales como segmentación de paquetes, confiabilidad, corrección de errores y estado de conexión.

El funcionamiento de DNS sobre UDP en IPv6 es adecuado para tamaños de paquete pequeños, pero se vuelve menos confiable con tamaños más grandes, especialmente cuando se requiere fragmentación de datagramas IPv6.

Por otro lado, DNS sobre TCP o QUIC en IPv6 funciona bien con todos los tamaños de paquete. Sin embargo, el uso de un protocolo con estado como TCP o QUIC exige más recursos del servidor DNS (y otros equipos como Firewall, DPIs, IDS, etc), lo que puede afectar la escalabilidad. Esta puede ser una compensación razonable para servidores que necesitan enviar paquetes de respuesta DNS más grandes.

La sugerencia del draft en cuanto a DNS sobre UDP recomienda limitar el tamaño de los paquetes de DNS sobre UDP en IPv6 a 1280 octetos. Esto evita la necesidad de fragmentación IPv6 o el descubrimiento del MTU del camino (Path MTU Discovery), lo que asegura una mayor confiabilidad.

La mayoría de las consultas y respuestas DNS encajarán dentro de este límite de tamaño de paquete y, por lo tanto, se pueden enviar a través de UDP. Los paquetes DNS más grandes no deben enviarse por UDP; en su lugar, deben ser enviados a través de TCP o QUIC, como se menciona en la siguiente sección.

DNS sobre TCP y QUIC

Cuando se necesitan transportar paquetes DNS más grandes, se recomienda utilizar DNS sobre TCP o QUIC. Estos protocolos manejan la segmentación y ajustan de manera confiable su tamaño de segmento para diferentes valores de MTU del enlace y del camino, lo que los hace mucho más fiables que el uso de UDP con fragmentación IPv6.

La sección 4.2.2 del [RFC1035] describe el uso de TCP para transportar mensajes DNS, mientras que el [RFC9250] explica cómo implementar DNS sobre QUIC para proporcionar confidencialidad en el transporte. Además, los requisitos operativos para DNS sobre TCP están descritos en el [RFC9210].

Seguridad

El cambio de UDP a TCP/QUIC para respuestas grandes implica que el servidor DNS debe mantener un estado adicional para cada consulta recibida a través de TCP/QUIC. Esto consumirá recursos adicionales en los servidores y afectará la escalabilidad del sistema DNS. Además, esta situación puede dejar a los servidores vulnerables a ataques de Denegación de Servicio (DoS).

¿Esta es la manera correcta?

A pesar de que sí creemos que esta solución aportará muchos beneficios al ecosistema de IPv6 y DNS, se trata de un parche operativo temporal, pero que no resuelve la solución de raíz.

Creemos que la solución correcta es que la fragmentación en el origen funcione, que PMTUD no se encuentre roto en el camino, y que las cabeceras de fragmentación sean permitidas por los dispositivos de seguridad. Esto requiere de cambios en distintos actores de Internet que puede tomar bastante tiempo, pero no por eso debemos abandonar la educación y los esfuerzos por lograr hacer lo correcto.

Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64

Parece loco, pero no lo es: Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64 

 

Despliegue de DNSSEC en la región - Estadística y mediciones

 dnssec mediciones

Por: Hugo Salgado (@huguei) / Dario Gomez (@daro_ua) / Alejandro Acosta (@ITandNetworking)

Introducción

En el presente post queremos conversar sobre unas recientes investigaciones que hemos realizados 

sobre un tema que nos apasiona mucho: DNSSEC. Por favor notar que hablamos en plural: 

“investigaciones”, debido a que son dos estudios sobre DNSSEC que comenzamos a la vez… 

¡favor continua leyendo para que entiendas de que se tratan ambas dos!

Sobre DNSSEC

DNSSEC añade un plus de seguridad al protocolo DNS que permite comprobar la integridad

 y autenticidad de los datos, previniendo ataques de suplantación y falsificación, mediante

 el uso de criptografía asimétrica o mejor conocida como clave pública / privada. 

Mediante el uso de estas claves y las firmas generadas a partir de ellas, se puede saber 

si una consulta fue modificada, permitiendo garantizar la integridad y autenticidad del 

mensaje. Si al comprobar estas firmas no coinciden entre ellas, quiere decir que la cadena 

de confianza se ha roto y la consulta no puede ser validada como legítima.

Contar con DNSSEC depende del ISP o del proveedor de servicios de internet que tenga 

contratado, que es quien debe configurarlo. Para saber si cuenta con DNSSEC existen varias 

herramientas en Internet que lo permiten como:

https://dnssec-analyzer.verisignlabs.com/

https://dnsviz.net/

Como muchos saben DNSSEC es un protocolo que ha venido creciendo mucho en los 

últimos años. Dos aspectos han marcado su aumento del despliegue:

1) DNSSEC viene habilitado por defectos en algunos servidores recursivos (BIND) y

2) Grandes avances en facilitar habilitar DNSSEC en los diferentes dominios por los 

registradores más importantes.

3) Todos los grandes recursivos públicos hacen validación DNSSEC (google public dns, 

cloudflare, quad9, etc)

4) Apple acaba de mencionar que iOS16 y macOS Ventura permitirán hacer validación 

DNSSEC en el stub final.

DNSSEC ha sido un tema muy importante para LACNIC, hemos realizado gran cantidad 

de eventos y actividades en torno a este tema, sin embargo hasta la fecha no teníamos 

ningún estudio propio al respecto.

¿De qué trata el estudio?

Desde el área I+D de LACNIC quisimos realizar un estudio con el fin de conocer el estado 

y el avance respecto al despliegue de DNSSEC en la región.

Origen de la Data

Tenemos dos fuentes de datos muy confiables

• Utilizamos los probes ATLAS de RIPE https://atlas.ripe.net/

• Realizamos capturas (tcpdump) que posteriormente fueron anonimizadas en 

• servidores autoritativos

Fechas:

La obtención de la data comenzó en Noviembre de 2021, actualmente se lleva a cabo de 

una manera automatizada con reportes semanales y mensuales [1]

¿Cómo se identifica que un servidor realice DNSSEC?

Hay que verlo desde dos aspectos:

Sondas Atlas:

Se envían solicitudes de resolución DNS a todas las sondas disponibles en latinoamérica y el caribe, por un nombre de dominio que intencionalmente tiene sus firmas incorrectas y por lo tanto no valida según DNSSEC. Si la respuesta es error (SERVFAIL), quiere decir que el resolver que utiliza esa sonda sí utiliza correctamente DNSSEC. Si por el contrario se obtiene respuesta (NOERROR), quiere decir que dicho resolver no realiza ninguna validación. Nótese que interesantemente la idea es que la respuesta del servidor DNS sea negativa, *esto es la clave* para saber si el recursivo valida DNSSEC o no. 
Te dejamos este ejemplo: si visitas dnssec-failed.org y puedes abrir la página significa que tu DNS recursivo no hace DNSSEC, si no la puedes abrir es bueno! :-). 

Captura (tcpdump):

Antes de indicar que hacemos con la captura vamos a expandir un poco el concepto de DNSSEC. Así como existen los registros tradicionales en DNS (A, AAAA, MX, etc) para la utilización de DNSSEC se agregaron nuevos registros, estos mismos son DS, RRSIG, NSEC, NSEC3 y DNSKEY. Es decir, un servidor DNS recursivo puede consultar el registro AAAA para conocer la dirección IPv6 de un registro y puede consultar el registro DS (Delegation Signer) para verificar la autenticidad de las zonas hijas. La parte clave de este estudio es que los servidores que no hacen validaciones DNSSEC no consultan registros DNSSEC!. 

En base a lo anterior, al momento de realizar la captura se le pide a tcpdump que tome todo el paquete (flag -s 0),  de esa manera tenemos todo el contenido del mismo, desde capa 3 hasta capa 7, durante el procesamiento del paquete buscamos por los registros específicos de DNSSEC (nuevamente: DS, RRSIG, NSEC, NSEC3 y DNSKEY), si conseguimos alguno de ellos entonces el recursivo si hace DNSSEC, en caso contrario no hace. 

¿Donde se realiza la captura mencionada?

La captura se hace especificamente en una de las instancias del servidor DNS 

Reverso D (D.IP6-SERVERS.ARPA). El comando utilizado es: /usr/sbin/tcpdump 

-i $INTERFAZ -c $CANTIDAD -w findingdnssecresolvers-$TODAY.pcap -s 0 dst port 

$PORT and ( dst host $IP1 or dst host $IP2 )

Procesamiento de la información

Primero, el procesamiento de los datos consta de varias partes, todas realizadas 

completamente con software Open Source, específicamente con Bash, Perl y Python3 

sobre Linux.

Segundo, recordemos que existen dos fuentes de información: Captura de tráfico (PCAPs) 

y Probe Atlas. Aquí la metodología seguida en cada caso:
  a) Procesamiento de los PCAPs: Luego de obtener los PCAPs se realizan una serie de 

paso, entre ellos:

    1) El procesamiento de los .pcap se realiza en Python3 utilizando la librería pyshark.
    2) Limpieza de los datos improcesables (paquetes malformados, dañados, no-procesables, etc)
    3) Remoción de direcciones duplicadas
    4) Anonimización de datos
    5) Generación de resultados
    6) Generación de las gráficas y open data

  b) Procesamiento de la información obtenida en RIPE Atlas:
La captura de datos se realiza con mediciones mensuales en la plataforma RIPE Atlas, 

utilizando su API por línea de comandos. Luego se recogen y procesan en una serie de 

scripts utilizando lenguaje Perl, para finalmente graficar utilizando la API de Google Charts 

y adicionalmente dejamos los datos disponibles siempre en Open Data.
Favor recordemos que para detectar si una sonda está utilizando un resolver con validación, 

se utiliza un nombre de dominio que intencionalmente tiene sus firmas incorrectas. De 

esta forma, al intentar resolver ese nombre, una sonda que valide debe responder con error, 

porque el nombre no es válido según DNSSEC. Por el contrario, si se obtiene una respuesta 

positiva frente al nombre, quiere decir que el resolver no está validando, ya que ignoró la 

firma incorrecta.

Resultados obtenidos

Esta gráfica muestra la cantidad de servidores estudiados que utilizan DNSSEC y cuáles no 

lo usan. Las líneas azules determinan los servidores con DNSSEC activo, las rojas los que 

no lo tienen.

Grafico 1

Se puede apreciar que para el 2 de Junio 2022 existen más servidores recursivos sin realizar 

DNSSEC que los que lo hacen. Se analizaron entre 33.000 a 55.000 direcciones IP cada semana. 

En líneas generales, se mantiene un promedio aproximado de un 55% de servidores que no utilizan 

el protocolo y un 45% de muestras positivas.

Grafico #2

En el gráfico #2 podemos apreciar el histórico de consultas DNSSEC en IPv6. Un dato no menor 

que llama mucho la atención es que en varios periodos de muestreo, existen más cantidad de 

consultas DNSSEC sobre v6 que en v4. Indiscutiblemente la intención es que la línea roja 

disminuya y la azul aumente de forma gradual.

Ranking de países con mayor validación DNSSEC

Utilizando la plataforma de mediciones de RIPE Atlas, es posible medir en cada una de ellas su 

capacidad de validar DNSSEC o no. Cada medición se puede agrupar por país, creando un ranking:

Grafico #3

Ranking ordenado con el porcentaje de validación DNSSEC promedio desde redes de países 

en Latinoamérica y el Caribe correspondiente a mayo de 2022.

Los números dentro de las barras indican la cantidad de ASs participantes por cada país. Se 

descartan países donde medimos un solo ASs.

Resumen

Desde el estudio basado en captura de tráfico, con los datos obtenidos en un lapso de 8 

meses la gráfica sugiere una disminución lenta de número de servidores NO-DNSSEC; 

adicionalmente parece existir un mayor despliegue de DNSSEC en servidores IPv6 que en IPv4.

En el caso del análisis de sondas Atlas, es esperable un mayor despliegue de validación que 

con otras fuentes de datos más genéricas, considerando que las sondas generalmente son 

hospedadas en redes más avanzadas o por usuarios que podrían activar deliberadamente 

DNSSEC. Pero representa de alguna manera el “límite superior” de penetración, y también 

es un indicador importante de la evolución a través del tiempo.

OpenData

Como es habitual en LACNIC siempre deseamos dejar nuestra información disponible para su 

trabajo por quien así lo desee:

https://stats.labs.lacnic.net/DNSSEC/opendata/

https://mvuy27.labs.lacnic.net/datos/

Estos datos que estamos dejando disponibles también poseen el espíritu de “Time Series 

Data”. Es decir, estamos dejando los datos recolectados durante el tiempo lo que hará muy 

sencillo tener fluctuaciones de nuestras estadísitcas en el tiempo y saber si el despliegue de 

DNSSEC aumenta y/o disminuye por país, región, etc.

Como siempre cuando realizamos este tipo de proyectos, son bienvenidas sugerencias de 

mejora tanto en la implementación como en la visualización de la información obtenida.

Referencias:

[1] https://stats.labs.lacnic.net/DNSSEC/dnssecstats.html

https://mvuy27.labs.lacnic.net/datos/dnssec-ranking-latest.html

Pequeño script en Python3 para obtener los registros DNS RRSIG

(seguramente hay más maneras más de hacer esto, incluso más elegantes pero así lo hice yo) 

import dns.resolver
domain='lacnic.net'
domain = dns.name.from_text(domain)
request = dns.message.make_query(domain, dns.rdatatype.ANY)
response = dns.query.tcp(request,'8.8.8.8')
for item in str(response).splitlines( ):
  if 'RRSIG' in item: 
      print (item)

Draytek y DDNS con HE.NET

Hola,

  Para hacer funcionar un router Draytek con Hurricane Electric (he.net / tunnelbroker.net) en mi caso tuve que hacer:

1) Del lado de HE.NET / tunnelbroker.net hay que obtener el "Update Key"

Será un texto como: xQCw4ngV2xJaOSVz



y buscar el tunnel id:








2) Luego del lado del router Draytek buscas "Applications" -- "Dynamic DNS":





3) Chequear el checkbox "Enable Dynamic DNS Setup"





4) Hacer click sobre el número 1.



5) Configurar el DDNS de la siguiente manera:
Service Provider debe quedar en "Customized" lo que te permitirá ingresar la información necesaria

El provider host es: ipv4.tunnelbroker.net
Auth es: Basic
Connection Type es: Https (PROBAR HTTP en caso que https no funcione)
Login: usuario en el he.net/tunnel broker

Password es el "Update Key" conseguido en el paso anterior

TUNNEL ID debe ser sustituido por el número de tunel obtenido en el paso anterior





Suerte!, espero haya sido de tu utilidad


Alejandro,

Por fin, RRL en BIND por defecto - con ejemplo

Historia

Al parecer este es un post que tuve que haber hecho hace mucho, sin embargo hoy recién es que lo veo funcionando correctamente


Introducción

Si el lector se parece un poco a mí, quizás sea de esas personas que tiene MUCHOS años esperando el soporte de Response Rate Limiting en Bind9. Buenas noticias!, ya existe !.


¿Qué es RRL en DNS?

RRL se refiere a Response Rate Limit. De una manera resumida es una técnica para minimizar ataques de amplificación que son muy comunes en el mundo de DNS. Hoy en día es muy recomendado en servidores autoritativos pero puede servir en recursivos.


Situación


Deseo instalar Bind9 vía apt (apt-get) y tener soporte de RRL (Response Rate Limiting). Algo que me extraña es que en teoría debería tener soporte por defecto luego del 9.10, sin embargo verán que este ejemplo está en 9.9.5)


Pasos:


El día de hoy, con Ubuntu 14.04 (si, bastante viejo) hice un upgrade de Bind9, probé RRL y todo anduvo perfecto. 

1) Actualizar bind9
   apt-get –only-upgrade install bind9

2) Chequeo la versión:
   root@my:~/SCRIPTS# apt-cache policy bind9
      bind9:
      Installed: 1:9.9.5.dfsg-3ubuntu0.19

3) Configurar RRL en bind9. Un sencillo ejemplo:


   rate-limit {
      responses-per-second 1;
   };


(favor notar que puse "1".., solo para probar que el feature realmente sirva)

4) Reiniciar bind vía rndc o el servicio (service bin9 restart)


   #service bind9 restart

Comprobar

Debido a que dejamos una sola consulta por segundo, es tan sencillo como ir a otro equipo, tener varios terminales abiertos y hacer muchos dig simultáneamente de algún dominio/zona autorizada. Si todo sale bien, en el log verás algo como:


Jul 4 11:47:55 my named[8317]: limit responses to 10.112.225.0/24 for exp.example.com IN A (fff7f64c)


Jul 4 11:47:55 my named[8317]: client 10.112.225.51#11257 (exp.example.com): rate limit slip response to 10.112.225.0/24 for exp.example.com IN A (fff7f64c)


Jul 4 11:47:56 my named[8317]: client 10.112.225.51#7921 (exp.example.com): rate limit drop response to 10.112.225.0/24 for exp.example.com IN A (fff7f64c)

Mas info:
https://kb.isc.org/docs/aa-00994
https://whatis.techtarget.com/definition/DNS-amplification-attack

Como verificar si un sitio Web se encuentra bloqueado

Hola,
  Si en google por ejemplo buscamos "como revisar si un sitio web esta bloqueado" será difícil  conseguir información de como revisar nosotros mismos, los resultados serán principalmente sitios Web que pueden abrir la página Web por tí, mostrarte desde otros sitio si puede conectarse, algún plugin que puedas instalar. En estás páginas se puede revisar si un sitio está arriba o no: https://www.blocked.org.uk/check y https://downforeveryoneorjustme.com/

   NOTA: Este post es básicamente como podemos revisar nosotros mismos un bloqueo. Estamos hablando de bloqueos por parte de un ISP/país, no de bloqueos en el firewall en una empresa o compañía. Se aceptan sugerencias y quejas.., comentarios están abiertos al final del documento

Introducción:
  Como algunos de ustedes saben, existen muchas manera de bloquear sitios Web, principalmente los bloqueos ocurren de 4 maneras:
1) DNS
2) Routing
3) Capa 4 (bloqueo de puertos TCP/UDP a ciertos destinos)
4) Capa 7 (bloqueo de por ejemplo la URL/dominio)

  Ahora bien, antes de continuar quiero dejar claro mi posición en cuanto a los bloqueos en Internet: ME PARECEN MUY MALA IDEA y no trae nada bueno al país/ISP..., y en el supuesto que traíga una cosa buena, trae 10 cosas malas. Tengo algunas cosas plasmadas en este post: https://blog.acostasite.com/2014/10/la-mala-idea-de-bloquear-internet.html

Pasos para revisar un bloqueo de un sitio Web:
  Ahora bien, en el supuesto que queramos saber si algún sitio se encuentra bloqueado, podemos seguir estos pasos (preferiblemente Linux y/o MAC):

1) Revisar si el bloqueo es por DNS. ¿Cómo lo hacemos?
   Podemos usar dos herramientas de resolución DNS. Para este ejemplo utilizaremos dig y/o nslookup.


.- Utilizando dig

MacBook-Pro-2:tmp$ dig +short www.example.com

172.XX.YY.39

.- Utilizando nslookup

MacBook-Pro-2:tmp$ nslookup www.example.com

Server: 8.8.8.8

Address: 8.8.8.8#53

Non-authoritative answer:

Name: www.example.com

Address: 172.XX.YY.39

¿Qué hay que revisar de la salida?
Básicamente con el comando, le pedimos a dig que muestre de manera resumida, que direcciones IP resuelve www.example.com. En este sentido 172.XX.YY.39 será el IP al cual nuestra computadora se va a conectar. Lo importante aquí es identificar si 172.XX.YY.39 corresponde al IP destino que nos queremos conectar (si, ciertamente pueden resolver direcciones diferentes y eso, pero si sabes eso no necesitas leer este documento :) !! )  Muchas veces algunos ISPs cambian la resolución de un dominio y no verías el IP correcto sino otra al cual es imposible conectarse (por ejemplo, 127.0.0.1)


2) Routing

  Para revisar routing principalmente utilizaremos traceroute (tracert en Windows)

  La idea es en lineas generales ver si podemos alcanzar el destino desde nuestra computadora:


Utilizando traceroute:

MacBook-Pro-2:tmp$ traceroute -n 8.8.8.8  (sustituye 8.8.8.8 por el dominio o el IP obtenido en el paso previo)

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets

 1  192.168.1.1  1.724 ms  1.030 ms  1.376 ms

 2  190.XX.XX.1  28.969 ms *  35.939 ms

 3  172.YY.13.33  27.988 ms  27.379 ms  29.267 ms

 4  * * *

 5  10.XX.1.105  29.229 ms 28.628 ms 28.303 ms

 6  10.XX.1.1  38.332 ms  26.855 ms 28.605 ms

 7  200.XX.XX.177  61.560 ms  62.466 ms  68.661 ms

 8  72.NN.NN.84  62.411 ms  62.523 ms 62.188 ms

 9  108.170.253.17  62.537 ms  63.011 ms 63.182 ms

10  108.170.226.13  63.588 ms 65.335 ms 62.301 ms

11  8.8.8.8  62.329 ms  63.023 ms  62.176 ms

¿Qué hay que revisar de la salida?

  Como se puede ver en el traceroute de arriba, se llegó satisfactoriamente al destino.
  En el caso de ver algún "!" seguido por una letra, es mala noticia. Por ejemplo ver esto en el traceroute significa que hay algo mal, quizás el ISP bloqueó las direcciones IP destino de alguna manera.

  Errores comunes (tomados de la página del manual de traceroute):

 !H, !N, or !P (host, network or protocol unreachable)

  !S (source route failed)
  !U or !W (destination network/host unknown) 
 !I (source host is isolated)
 !A (communication with destination network administratively prohibited)
 !Z (communication with destination host administratively prohibited)
 !Q (for this ToS the destination network is unreachable), 
 !T (for this ToS the destination host is unreachable), 
 !X (communication administratively prohibited), 
 !V (host precedence violation), 
 !C (precedence cutoff in effect), or 
 ! (ICMP unreachable code ). 

Extra:
  Otra herramienta que recomiendo para revisar este punto es MTR  (My traceroute) ; https://es.wikipedia.org/wiki/MTR_(software).., es una combinación de ping y trace. MUY buena.


3) Capa 4 (bloqueo de puertos a ciertos destinos)
  Para revisar bloqueos de capa 4, principalmente la idea es revisar conectividad a nivel de puertos (TCP) desde tu computadora al destino.
  La herramienta más sencilla para revisar esto es telnet, la intención al ejecutarlo es chequear que efectivamente "se conectó" nuestra computadora al destino.

Utilizando telnet:
Ejemplo 1: (conecta¡ándose al puerto http)

MacBook-Pro-2:tmp$ telnet www.example.com 80  -- 80 quiere decir el puerto destino

Trying 199.NN.NN.100...

Connected to www.example.com. --- esto es lo que hay que revisar

Escape character is '^]'.

Ejemplo 1: (conectándose al puerto https)

MacBook-Pro-2:tmp$ telnet www.example.com 443  -- 443 quiere decir el puerto destino

Trying 199.NN.NN.100...

Connected to www.example.com.   --- esto es lo que hay que revisar

Escape character is '^]'.

Cuando el destino se encuentra bloqueado a nivel de 4 veríamos algo así:

MacBook-Pro-2:tmp$ telnet www.example.com 80

Trying 199.XX.XX.100...

telnet: connect to address 199.XX.NN.100: Operation timed out

telnet: Unable to connect to remote host

Depende el tipo de bloqueo, el telnet puede ser rechazado muy rápido (reject *), quizás el telnet solo dure mucho hasta que haga timeout.

* tu computadora recibe un icmp error desde el dispositivo que se encuentra bloqueando

4) Capa 7 (bloqueo de por ejemplo la URL/dominio)

  Revisar capa 7 viene a ser cuando el ISP es capaz de identificar el contenido de paquetes HTTP y chequear por el texto del dominio bloqueado dentro de él, es decir: el ISP quiere bloquear www.example.com, algunos dispositivos dentro del ISP son capaces de revisar a nivel de capa de aplicación (capa 7) el fqdn www.example.com, y allí tomar la decisión: bloquear o no.

  Para lo anterior, recomiendo utilizar curl o wget. Dejaré solo el ejemplo con curl:

Utilizando curl (en hacia un destino bloqueado)

MacBook-Pro-2:tmp$ curl -v https://www.example.com

* Rebuilt URL to: https://www. example.com/

*   Trying 172.NN.NN.39...

* TCP_NODELAY set

* Connected to www.example.com (172.NN.NN.39) port 443 (#0)

* ALPN, offering h2

* ALPN, offering http/1.1

* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH

* successfully set certificate verify locations:

*   CAfile: /etc/ssl/cert.pem

  CApath: none

* TLSv1.2 (OUT), TLS handshake, Client hello (1):

* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.example.com:443 

* stopped the pause stream!

* Closing connection 0

curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.example.com:443 

¿Qué hay que revisar de la salida?

   No hay que asustarse con la salida, aquí hay revisar que la negociación SSL/TLS no pudo completarse, esto lo podemos apreciar al conseguir que el texto *ERROR* se ve en la salida.

   Nota: Cuando la salida es satisfactoria, veremos código html

Conclusión:
  Existen MUCHAS manera de bloquear acceso a sitios en Internet, incluso en algunas oportunidades puede usarse una combinación de varias maneras para lograr un bloqueo.

  Se que el post puede ser mucho más amplio y faltaron cosas por cubrir, sin embargo a su vez espero que él mismo sea visto como una introducción.

  El bloqueo de sitios Web en Internet no trae beneficios.

DNS: Bloquear o no bloquear las direcciones IPv6 6to4

Introducción

  El servicio de DNS es sin duda alguna uno de los pilares de Internet, sin DNS el Internet no sería ni remotamente como lo conocemos hoy en día.

  DNS es el servicio que permite -entre otras funciones- convertir nombres de dominios a direcciones IP y viceversa.

Sobre el proyecto IPv6 Open Resolvers:

  Dentro de Lacnic, desde comienzos del año 2018 [1] estamos en la búsqueda de servidores DNS sobre IPv6 que son consideraciones “Open Resolvers” [2]

¿Que tiene que ver 6to4 con Open Resolvers y seguridad?

  Durante el tiempo que tiene este proyecto en funcionamiento hemos tenido la oportunidad de exponer el estudio y sus resultados [3] en sitios como DNS-OARC 28 , LACNIC 29 y NANOG 74. En esta última, recibimos muy buenos comentarios y quizás el más significativo fue el de George Wes donde él indicaba la existencia de muchos servidores DNS con direcciones IP 6to4 [4] las cuales utilizan direcciones IP de túneles automáticos dentro del prefijo 2002::/16.

  En base a lo anterior, decidimos profundizar en este concepto y estudiar con más detalle los resolvers con direcciones IPv6 6to4 y obtuvimos información muy interesante.

  Por ejemplo, el día 2 de Diciembre del 2018 estudiamos: 6248 servidores, de los cuales 61 estaban contenidos en el prefijo 2002::/16, y de aquí tuvimos 20 servidores abiertos, es decir, casi un 33%. Todos ellos potenciales para realizar diferentes ataques de DNS como de amplificación, cache poisoning, DDoS, DNS hijacking, entre otros.

  Aquí tenemos dos gráficos de lo arriba expuesto:

   Conclusión

   Primero, el problema per sé no es el 6to4, son los Open Resolvers. Segundo, como administrador de servidores DNS ustedes deben querer responder a la mayor cantidad de queries posibles de clientes válidos, nuestra recomendación no se ajusta solo a redes 6to4, sino básicamente la implementación de RLL (Response Rate Limit) a los queries según el origen, claro prestarle mayor atención a las provenientes del prefijo 2002::/16 no es mala idea.

Referencias

[1]https://labs.lacnic.net/aportando_un_grano_de_arena_en_la_seguridad_de_la_red/

[2] https://www.bsi.bund.de/EN/Topics/IT-Crisis-Management/CERT-Bund/CERT-Reports/HOWTOs/DNS-Open-Resolver/DNS-Open-Resolver_node.html

[3] https://stats.labs.lacnic.net/IPv6/DNSOpenResolver/

[4] https://en.wikipedia.org/wiki/6to4

vivo v15 pro
beautiful Rohini escorts for you