Parece loco, pero no lo es: Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64
Blog en espanol destinado a diferentes temas tecnicos principalmente en IT y Networking. Se desea cubrir Linux, DNS, DNSSEC, RPKI, BGP, Cisco, Programacion (Bash, Python, etc), Protocolos de Enrutamiento, Seguridad en Redes, VoIP.
lunes, 6 de noviembre de 2023
lunes, 25 de julio de 2022
Despliegue de DNSSEC en la región - Estadística y mediciones
Despliegue de DNSSEC en la región - Estadística y 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/
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.
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:
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
martes, 1 de septiembre de 2020
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)
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)
lunes, 23 de marzo de 2020
Draytek y DDNS con HE.NET
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,
jueves, 4 de julio de 2019
Por fin, RRL en BIND por defecto - con ejemplo
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.
apt-get –only-upgrade install bind9
root@my:~/SCRIPTS# apt-cache policy bind9
bind9:
Installed: 1:9.9.5.dfsg-3ubuntu0.19
rate-limit {
responses-per-second 1;
};
(favor notar que puse "1".., solo para probar que el feature realmente sirva)
#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
martes, 30 de abril de 2019
Como verificar si un sitio Web se encuentra bloqueado
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
.- Utilizando nslookup
¿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
La idea es en lineas generales ver si podemos alcanzar el destino desde nuestra computadora:
Utilizando traceroute:
¿Qué hay que revisar de la salida?
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):
!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
!
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)
Ejemplo 1: (conectándose al puerto https)
Cuando el destino se encuentra bloqueado a nivel de 4 veríamos algo así:
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)
¿Qué hay que revisar de la salida?
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.
miércoles, 6 de febrero de 2019
DNS: Bloquear o no bloquear las direcciones IPv6 6to4
Introducción
vivo v15 pro
beautiful Rohini escorts for you
BGP Stream: un año de análisis sobre incidentes BGP
BGP Stream: un año de análisis sobre incidentes BGP 04/03/2024 Por Alejandro Acosta , Coordinador de I+D en LACNIC LACNIC presenta la prim...
-
Debido al crecimiento moderado que ha tenido el presente blog se me ocurrió añadir/integrar las estadisticas de google analytics a mi blog. ...
-
Introduccion: En algunas ocasiones es necesario "bajar" o deshabilitar iptables en nuestro Linux, el procedimiento depende de...
-
Saludos, Lo primero que debemos de hacer para quitar el stacking entre los switches es desconectar los cables Stack que los unen.... Es buen...