TA13-088A: DNS Amplification Attacks

Hace un par de días recibí un correo de US-CERT con el título "TA13-088A: DNS Amplification Attacks" y me llamó poderosamente la atención que esto siga siendo un problema en la red.

Según el último análisis hecho por la gente de Open Resolver Project (http://openresolverproject.org/ 2013-06-30):


35086838 servers responded to udp/53 probe
30085246 gave the correct answer to the A? for the DNS name queried
30556493 responses had recursion-available bit set


Es decir que existen alrededor de 35 millones de servidores DNS, de los cuales 30 millones responderían consultas recursivas, esto es aproximadamente el 87% del total (bastante, no?). 

A ver..., a priori tener un servidor DNS que responde consultas recursivas no es un pecado capital, de hecho es una gran funcionalidad en casos como el de la siguiente figura:

Un DNS recursivo brinda una serie de ventajas:

• Permite que las aplicaciones no tengan que cargar con el proceso de resolución de nombres.
• Definir políticas en cuanto al acceso a determinados dominios.
• En el caso de tener un firewall principal que controle el tráfico entrante y saliente de la organización, solo sería necesario abrir el puerto 53 (UDP/TCP) para el servidor de DNS y no para todas las IPs.
• Por lo general los servidores recursivos además son servidores cache, es decir que guardan las respuestas obtenidas por un plazo de tiempo, esto implica reducciones de tiempo y de consumo de ancho de banda.

Entonces cuál es el problema con tener un DNS recursivo?

El problema radica principalmente en la capacidad de un atacante de falsificar la dirección IP de origen (conocido como IP spoofing) en una consulta de dns. Sumado a esto, las consultas DNS tienen una particularidad muy interesante y util en este contexto:

Las respuestas suelen ser mucho mas grandes que las preguntas.

Por ejemplo, una consulta sencilla donde solo queremos los registros NS que corresponden a la raíz del servicio de nombres:


juan@moon:~$ dig -t ns .

; <<>> DiG 9.7.3 <<>> -t ns .
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- 43559="" font="" id:="" noerror="" opcode:="" query="" status:="">
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 15

;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       194627  IN      NS      i.root-servers.net.
.                       194627  IN      NS      j.root-servers.net.
.                       194627  IN      NS      m.root-servers.net.
.                       194627  IN      NS      g.root-servers.net.
.                       194627  IN      NS      k.root-servers.net.
.                       194627  IN      NS      b.root-servers.net.
.                       194627  IN      NS      e.root-servers.net.
.                       194627  IN      NS      l.root-servers.net.
.                       194627  IN      NS      c.root-servers.net.
.                       194627  IN      NS      h.root-servers.net.
.                       194627  IN      NS      f.root-servers.net.
.                       194627  IN      NS      a.root-servers.net.
.                       194627  IN      NS      d.root-servers.net.

;; ADDITIONAL SECTION:
j.root-servers.net.     603710  IN      A       192.58.128.30
m.root-servers.net.     198503  IN      A       202.12.27.33
m.root-servers.net.     254964  IN      AAAA    2001:dc3::35
g.root-servers.net.     603710  IN      A       192.112.36.4
k.root-servers.net.     603710  IN      A       193.0.14.129
b.root-servers.net.     603710  IN      A       192.228.79.201
e.root-servers.net.     603497  IN      A       192.203.230.10
l.root-servers.net.     601827  IN      A       199.7.83.42
l.root-servers.net.     601827  IN      AAAA    2001:500:3::42
c.root-servers.net.     603710  IN      A       192.33.4.12
h.root-servers.net.     603710  IN      A       128.63.2.53
f.root-servers.net.     603710  IN      A       192.5.5.241
a.root-servers.net.     442939  IN      A       198.41.0.4
a.root-servers.net.     599900  IN      AAAA    2001:503:ba3e::2:30
d.root-servers.net.     603710  IN      A       199.7.91.13

;; Query time: 24 msec
;; SERVER: 200.49.130.47#53(200.49.130.47)
;; WHEN: Sun Jul  7 00:25:00 2013
;; MSG SIZE  rcvd: 504

juan@moon:~$ 

Capturando con wireshark la consulta anterior vemos:

La respuesta es casi 10 veces mas grande que la pregunta (podrían existir casos aún peores, pruebe con dig -t ANY . @8.8.8.8 ... 1600 bytes!). Esta particularidad hace al protocolo DNS una potencial herramienta de denegación de servicio muuuuy interesante. 

Si extrapolamos un poco los números:

• Digamos que podemos hacer 10 consultas por segundo, eso serían 590 bytes, recibiríamos 5460 bytes en respuestas.
• Digamos que podemos hacer 100 consultas por segundo, eso serían 5900 bytes en consultas y unos 54600 bytes en respuestas.

Dificilmente logremos realizar una DoS realizando 100 consultas por segundo... la amenaza está realmente en el trabajo en equipo, es decir en las Botnets. 

Si un atacante contara con una botnet pequeña de unos 2000 equipos infectados generando unas 10 consultas por segundo, podría generar un bruto de 10920000 (5000*10*546) bytes, aproximadamente 10 Gbytes de tráfico en respuestas!!! Pero todavía queda algo por arreglar, claramente no podríamos exigirle este tráfico a un solo servidor DNS... necesitamos poder distribuir las consultas en mas de un servidor; pero eso no debería ser un impedimento según la gente de OpenResolvers.org, ya que hay millones de servidores DNS recursivos abiertos.

Ahora supongamos que además, el atacante es capaz de cambiar la IP de origen con que salen las consultas DNS de cada uno de los miembros de la botnet, por la IP de la víctima... eso significaría que estos 10 Gbytes estarían volviendo no a los nodos de la botnet sino a la IP víctima, colapsando así su ancho de banda y produciendo una denegación de servicio.

Cómo evitarlo?
Evitar denegaciones de servicio no es un tema sencillo y en la mayoría de los casos lo mejor que podamos hacer solamente reducirá el riesgo de sufrir una o disminuirá un poco su impacto.

Las siguiente medidas son de ayuda:

• Deshabilitar las consultas recursivas en los servidores que no las precisen, por ejemplo aquellos servidores que solo son autoritativos.
• Si las consultas recursivas son necesarias, se pueden tomar dos medidas: limitar la funcionalidad a un número acotado de IPs o limitar la cantidad de consultas por segundo permitidas.
• Verificación de direcciones IP, los ISP deberían combatir el IP spoofing, aca va un RFC que presenta una solución a este problema http://tools.ietf.org/html/bcp38 .

Cómo saber si mi servidor de DNS es vulnerable?

Una buena herramienta para ver si nuestros servidores son vulnerables es la siguiente http://www.dnsinspect.com/ . Con solo introducir nuestro nombre de dominio la aplicación hace una serie de pruebas a los servidores DNS declarados de la zona y prepara un breve informe. Este contiene los resultados de las pruebas junto con una serie de advertencias, sugerencias/recomendaciones para aplicar sobre las configuraciones de los mismos.