Hoy un audio sobre seguridad en DNS que no es lo mismo que DNSSec, de hecho DNSSec lo veremos en otro capítulo posterior, hoy vamos a hablar de un montón de conceptos más y de los que estuvimos hablando con Joaquín Gómez que trabaja en Infoblox, una empresa que se dedica básicamente estas cosas que voy a contar hoy, aquel día también estaba el Javi Topo, . También decir que Joaquí tuve a bien darnos un libro llamado DNS Security for Dummies y que os dejo en enlace para conseguirlo en las notas del programa en eduardocollado.com. Ahora me es bastante complicado quedar y bajar a Madrid, pero vamos que Joaquín no se escapa de contaros esto también en el futuro, así que en cuanto podamos quedaremos.
Bueno, yo soy Eduardo, esto es eduardocollado.com y este es el capítulo 163 en el que vamos a hablar de seguridad en DNS, que no es lo mismo que DNSSec. DNS recordad que es uno de los protcolos mas críticos de Internet por la importancia que tiene ya que sin DNS Internet no podría ser como es a día de hoy. También voy a aprovechar para completar un poco el Podcast #10: Cómo funciona el DNS.
Si os interesa el tema y os queréis quedar conmigo un ratito pues vamos para allá y voy a resumiros lo mejor que pueda este libro porque la verdad es que lo que me apetecía contaros ahí viene muy bien explicado y voy a apoyarme en el libro, así que agradecer a los escritores del libro y a Infoblox por distribuirlo gratuitamente.
Conceptos previos
Si os parece voy a pasar a recordar conceptos más o menos conocidos de DNS para empezar y luego pasamos ya a temas de seguridad, prometo ser rápido
Todos somos conscientes que la cantidad de datos que hay en Internet y del crecimiento que tiene esos datos y resulta obvio pensar que todos esos datos no pueden estar en un único servidor, sino distribuidos por servidores u ordenadores alrededor de toda la Tierra.
DNS como seguro que la mayoría ya conocéis es una especie de agenda telefónica, un diccionario, donde buscas la URL y obtienes la dirección IP del servidor, bueno, y alguna cosa más que iremos desgranando a lo largo del audio.
La estructura del DNS podemos verla como un árbol, cono como los de que dan frutos sino como un grafo sin caminos redundantes, un árbol desde el punto de vista matemático, donde en el nodo raiz tenemos a root, muy obvio, y en cada uno de los niveles tendremos los gtlds (.com, .net, .es, .cat …) luego en un nivel inferior los dominios eduardocollado.com, tecnocratica.net o neodigit.es. Luego un nivel más abajo los llamados subdominios www.eduardocollado.com, panel.neodigit.net o mail.troloro.net porque sí, www es un subominio como pudiera ser cualquier otra cosa, lo que pasa es que motivos históricos es en ese subdominio donde dejamos la página web.
Y cada uno de esos niveles podemos delegarselo a alguien, por ejemplo, si yo quiera podría delegar a otra persona con su servidor de DNS todo lo que esté por debajo de www.eduardocollado.com, así esa persona podría crear hola.www.eduardocollado, adios.www.eduardocollado.com o lo que quisiera, a ese procedimiento se le llama delegaciones.
Pues bien, el proceso de ir de arriba abajo preguntando al servidor de DNS que corresponde cada vez es el proceso de resolución, así se llama.
Una zona DNS es un dominio gestionado por un mantenedor puede también mantener los subdominios o delegar se los a otro, como ya hemos dicho anteriormente.
Ya que una estructura de un único servidor de DNS por dominio no parece la solución más robusta se pueden añadir otros servidores que lo único que harán será replicar la información del primer servidor esos servidores se llaman secundarios o esclavos, aunque normalmente se van a llamar secundarios.
Ahora vamos a ver los tipos de registros que hay, lo más comunes, pero realmente todos siguiendo el mismo esquema, sus componentes o resource records son:
Nombre: el nombre del FQDN
TTL: El intervalo de tiempo que debe permanecer en caché antes de ser descartado, de esto hemos hablado bastante en este mismo podcast
Clase: Este campo lo solemos ignorar porque será siempre IN de Internet y especifica la clase de dato que vendrá en el RDATA
RDLENGTH: No se suele mostrar porque hacer referencia al tamañode la carga y al final es un número que va variando
RDATA: Nos da la información que hemos preguntado, es uno de los componentes más importantes pues nos da la respuesta a nuestra pregunta
En cuanto a tipos de registros pues hay un montón la verdad y ya hemos hablado de ellos largo y tendido en otros capítulos en este mismo podcast, pero por ejemplo en un registro de tipo A, el más fácil, tendremos en Nombre el dominio, por ejemplo eduardocollado.com, en TTL tendremos 2 horas, es decir 7200 segundos que es lo que he indicado, en tipo obviamente tendremos una A y en RDATA la IP de mi servidor. La clase será IN y el RDLEGHT el número generado con la carga.
Hay otros registros más complejos como el SOA que además de todo lo anterior, en RDATA tendremos una serie de campos como el mname (nombre delservidor dns primario), rname (email del adminsitrador, ojo, como no se ponen @ hay que poner puntos y mucha gente lo confinde con un DNS secundario, nada que ver, rname significa responsible party) y luego tendrmos campos que nos indica cuanto permanecer en caché, cual será el tiempo mínimo en caché, cuando se puede borrar, etc…. en definitiva, mucho más compleo que el A.
Y así tendremos los CNAME, PTR, NS, AAAA, MX, TXT … y un montón más.
Y en esta primera parte de introducción nos quedarían tres conceptos antes de poder empezar a tratar amenazas y demás.
El query path: Este es el recorrido que hay que hacer para obtener la información deseada, es decir, primero preguntaremos a nuestro DNS por www.eduardocollado.com, luego hay que preguntar al root, si sabe qué es eso de .com, nos dirá como preguntar a .com, en .com preguntaremos por eduardocollado.com y gracias la las entradas NS nos dirá aquien hay que preugntar, preguntaremos a ese servidor de DNS y si lo conoce nos driá quien es www, o en caso contrario nos dirá quien lo tiene delegado, todo esto lo podéis ver con la opción +trace de dig.
Y luego dos conceptitos, que básicamente es lo mismo, la diferencia es quien lo hace, si somos nosotros los que como usuarios preguntas sobre los registros hacemos recursión, pero si es el servidor de DNS se llama iteracción.
Vamos a ir pasando a las amenazas de la seguridad de los DNS, así que vamos a ir entrando en materia si os parece
Amenazas a los DNSs
Ataques de DDoS
La primera amenaza derivada de los DNSs pueden ser los ataques de DDoS a los servidores DNS. Este tipo de ataques lo que hacen es impedir que se puedan publicar cambios o servir peticiones y pueden ser de distintos tipos
Ataque de amplificación
Aquí nos basamos en una técnica donde la petición es muy pequeña, pero la respuesta que nos tiene que dar el servidor DNS es muy grande. En este caso a base de peticiones pequeñas podríamos hacer que el servidor DNS se saturara y dejara de dar peticiones.
Si hacemos una query de 44 bytes, un dig, y la respuesta es de 4077 bytes, el ejemplo que viene en el libro tendríamos una amplificación de 93 veces, así que con una línea de 1Mbps podríamos hacer 2909 peticiones por segundo y el servidor de DNS nos tendría que responder con un ancho de banda de 93 Mbps, así conseguiríamos saturar fácilmente mediante ataques de amplificación.
Ataque reflejo
Se hacen peticiones pero con la IP origen falseada, un spoofing, de forma que si esto lo juntamos con un ataque a amplificación podemos enviar una gran cantidad de tráfico a una IP concreta que nosotros queramos.
Ataques combinados
Aquí juntamos lo mejor de los dos mundos, por un lado hacemos un spoofing con la IP de la víctima y por otro lado creamos una petición con una respuesta que se convierta en un ataque de amplificación. La gracia la tenemos en que hacemos esta petición con una petición recursiva, de forma que al final hemos atacado al primer DNS y al peticionario final.
Ataque de envenenamiento de caché o DNS Spoofing
Esto se consigue básicamente aprovechando vulnerabilidades del servidor de DNS y antiguamente era posible aceptar RRset que no coincidieran, recordar si ya lo sabéis que un RRSet no es más que un conjunto de resource records que comparten clase, tipo y nombre y sí o sí tienen que ser los mimos datos, de hecho DNSSec, que lo veremos en otro audio opera firmando RRset..
Con este ataque lo que conseguimos es o bien modificar la IP de una entrada o bien modificar directamente el servidor DNS del dominio.
Malware y exfiltración
El Malware todos sabemos más o menos qué es y es capaz de extraer información importante para los usuarios, por ejemplo las contraseñas y ¿cómo se saca eso fuera? pues muy sencillo utilizando un dominio y una petición DNS, por ejemplo a un subdominio que no existe, pero le estamos haciendo una petición a un servidor de DNS que sí existe y que por tanto es capaz de recibir esa información y guardarla. En este caso hemos enviado una información utilizando una petición DNS, bien, pues a esto se le llama exfiltración de datos y puede ser complicado parar eso pues el servicio de DNS no lo vamos a bloquear.
De la misma manera podríamos incluir información entro, ¿cómo? pues haciendo preguntas a registros TXT, uno tras otro, de esa manera podríamos transferir ficheros completos a base de trozos de 64k que es el tamaño máximo del RDATA.
Soluciones a los ataques
Un DDoS abruma al servido DNS con un montón de peticiones que impiden que se pueda servir el tráfico legítimo. Una solución consiste es el concepto de token bucket, es decir, cuantas peticiones se pueden contestara cada origen durante un periódo de tiempo, si se superan esas peticiones se pueden truncar las respuestas para evitar ataques de amplificación. A esto lo llamaremos RPL, es decir Response Rate Limiting.
Otra cosa a hacer es DNSSec, pero esto a lo largo de la semana procuraré presentároslo, pero con el señor Almenar que es la persona que lo ha puesto en funcionamiento en Neodigit y que bien seguro que nos puede aportar muchísimo más de lo que yo os puedo decir más que nada porque se ha peleado bastante con el. Simplemente decir que DNSSec lo que hace es proporcionar validación de la respuesta, que no encripta el tráfico y que es compatible con aquellos servicios que funcionen sin DNSSec.
RPZ – Response Policy Zones
Hay un tema super interesante que son los RPZ, o Response Policy Zones, esto es algo parecido a un Access List pero para DNS, y podemos gesionar peticiones y respuestas y tomar acciones en función de las condiciones, como redirigir a otro sitio con una página de error.
Al hablar de RPZs tenemos que entender el concepto de reputación que viene a ser, como en el email, direcciones o zonas donde es más probable que se genere contenido malicioso, sea el que sea. Estas reputaciones se generan en listas, las de Infoblox u otras que hay. Hay que tener en cuenta que al hablar de RPZs estamos hablando de Bind versión 9.8.1 o superior, no es algo extendido al 100% todavía, ya que aunque la versión 9.8.1 sea del 2010, por ejemplo Microsoft Windows no lo implemento hasta el año 2016, así que poco a poco.
En RPZ hay disparadores como QNAME que actúa sobre el campo NAME; IP Trigger que actúa sobre el campo RDATA, sobre la IP; Client IP Trigger actúa sobre la IP del que inicia la query … hay muchísimos, que miran los glue records, o los servidores autoritativos
Premium
Plus
Comentarios