¡No quiero a mi DNS!

Pues sí, parece ser que el DNS es un bicho raro que nadie quiere y seguro que algunos se preguntarán qué es eso del DNS. Pues el DNS es un servicio encargado de resolver los nombres de las direcciones de Internet, es decir, que si usted pone en su navegador web www.google.es, él se encarga de decirle a su navegador que donde quiere usted ir es a la IP 1.2.3.4.

Como ven bajo esas tres letritas tan raras se esconde uno de los servicios más críticos para la infraestructura de su empresa. ¿Por qué? Pues porque es el encargado de que si un cliente pone www.suempresa.es vaya a su empresa y no a la de la competencia, porque también es el encargado de que si su servidor requiere una actualización la obtenga del sitio correcto y no de “pedazo-rootkit-te-voy-a-meter” y, como no, de que cuando un usuario se conecte a Facebook el lunes para comprobar qué planes hay para el sábado vaya realmente a Facebook y no a un falsa web que robe las credenciales del usuario (tenga en cuenta que quien dice Facebook puede decir su entidad bancaria).

Una vez mostrado la importancia del DNS para su infraestructura, nos planteamos… ¿Por qué en ocasiones no se toman las medidas necesarias de arquitectura de red y de bastionado del servicio que realmente requiere este servicio? No hablo de restringir únicamente la petición de la versión empleada o las transferencias de zona, hablo de por qué permite que su DNS interno consulte directamente a un DNS externo, por qué el DNS de la red perimetral responde tanto a los servidores de la red perimetral como a las solicitudes de activos externos a su infraestructura, por qué permite que los activos de la red internan puedan solicitar cualquier dominio, por qué su servidor DNS público permite consultas recursiva a solicitudes externas… ¿Por qué? Mourinho, ahora te entiendo :)

Su infraestructura debe disponer de al menos tres DNS, los cuales se recomienda que estén replicados para alta disponibilidad (es decir, seis servidores DNS):

• El primer DNS es el encargado de responder a las peticiones externas que pregunten sobre un dominio de nuestra infraestructura y por tanto es el encargado de resolver las IP públicas de nuestra red. Éste debe estar en una zona dedicada y propia de la infraestructura, y dicho DNS no debe permitir peticiones recursivas y por supuesto peticiones desde nuestra infraestructura.
• El segundo DNS se encontrará en la red perimetral o DMZ. Contiene las IP privadas de los servidores de DMZ y a su vez será el encargado de consultar a los DNS externos de la infraestructura si recibe peticiones, si y solo si, de activos pertenecientes a la red perimetral o del DNS interno.
• El tercer DNS será el interno, que responderá única y exclusivamente a peticiones de los activos de la red interna y en caso de no disponer de la respuesta, siempre deberá preguntar al DNS de la red perimetral de la infraestructura y jamás, repito, JAMÁS, a un DNS externo de Internet.

Con este entorno dispondremos de una arquitectura de red para los DNS segura, dentro de lo seguro que pueda ser un servicio que se comunica mediante UDP (si la petición es inferior a 512 bytes). Pero lógicamente este diseño debe ser acompañado por dos herramientas: un IPS que sea capaz de entender a nivel de aplicación el protocolo DNS y añadir la capacidad de Sinkhole al DNS interno.

En lo referido al IPS es crucial que éste sea capaz de entender a nivel de aplicación el protocolo DNS puesto que éste emplea un formato muy especifico para contener los dominios. Si por ejemplo queremos detectar conexiones hacia el dominio de malware “counter.yadro.ru” no se le puede decir al IPS que intente buscar esa cadena porque no la va a encontrar. Si vemos a bajo nivel una consulta de dicho dominio vemos que lo que se manda es lo siguiente: “0763 6f75 6e74 6572 0579 6164 726f 0272 7500”, es decir, por cada registro se indica primero el número de caracteres del subdominio y posteriormente se envían los valores ASCII del subdominio. Para terminar el dominio se emplea el carácter “00”:

07	63	6f	75	6e	74	65	72	05	79	61	64	72	6f	02	72	75	00
	c	o	u	n	t	e	r		y	a	d	r	o		r	u

Estas construcciones pueden complicarse cuando se emplean punteros, que permiten legítimamente al protocolo DNS ahorrar espacio al poder saltar a cualquier posición del payload, dificultando la obtención del dominio solicitado, así como pudiendo generar bucles infinitos. Los punteros se identifican porque el valor del número de caracteres que le preceden es superior a 63. Recuerden que un dominio y subdominio no pueden superar los 63 caracteres, por tanto, si el valor es superior a 63 (0x40 o superior) esto indica que es un puntero y tras él, se indica la posición del payload donde se desea saltar.

La segunda herramienta básica a la que hacíamos referencia es Sinkhole, de Guy Bruneau, necesaria y prácticamente obligatoria en cualquier infraestructura. Lo que hace esta herramienta es detener la actualización y comunicación del malware con su controlador si emplean para ello Fast Flux (la gran mayoría del malware actual).

Sinkhole es un servidor DNS (BIND) al cual se le ha añadido un listado de dominios conocidos que distribuyen malware; en lugar de apuntar a la IP real del malware, se apunta a un servidor interno vacio y de esta forma cuando los usuarios reciban un correo con un enlace a un dominio que contenga malware, si pincha en el enlace correspondiente, Sinkhole impedirá que se infecten al redireccionarle al servidor vacio, de la misma forma que impedirá que el malware se actualice y que el atacante obtenga el control del equipo. Una política acertada es monitorizar las conexiones al servidor vacio para emplearlo como una herramienta de detección de malware. Es importante tener claro que para que esta estructura funcione todos los equipos de usuarios sólo pueden resolver dominios pasando por el DNS Sinkhole y que el DNS Sinkhole debe redireccionar, una vez pasado el filtro, al DNS interno.

Existen muchas otras configuraciones a tener en cuenta, como por qué aceptamos respuestas de DNS con un TTL inferior a un día o por qué algunos DNS no seleccionan de forma aleatoria su ID y su puerto origen para evitar envenenamiento de la cache de tipo Kaminsky, pero esto ya requeriría más de una entrada :)

Para finalizar les muestro un diagrama básico de una arquitectura más o menos segura de implantación de un DNS, que seguro que a todos nos sonará por tenerla implantada en nuestra empresa al ser un requisito indispensable de la norma ISO 27002… ¿verdad? :) Bromas aparte, ahí va: