¿Borrar el caché del servidor DNS?

2

¿Hay algún modo de que el atacante borre la memoria caché de un servidor DNS para envenenarlo?

Por ejemplo, si alguien atacó mi servidor DNS en un intento de falsificar Google.com, recibirá la respuesta "Google.com ya está en el caché", por lo que el atacante tiene la oportunidad de borrar los datos del caché. ?

    
pregunta Emadeddin 19.08.2013 - 21:08
fuente

1 respuesta

1

Administración de caché es un tema amplio. La mitad de las decisiones tomadas por un servidor DNS, en la forma en que maneja su caché, son puramente locales y, por lo tanto, no estándar.

En el sistema DNS , los servidores que son "autoritativos" para una zona (por ejemplo, un dominio) publican algunos cachés. Retrasos, que aplican restricciones a otros servidores. Por ejemplo, para google.com :

$ host -t soa google.com
google.com has SOA record ns1.google.com. dns-admin.google.com. 2013072400 7200 1800 1209600 300

Los números son, en ese orden: serial , refresh , reintentar , caducan y mínimo . El "serial" es un entero arbitrario aumentado en cada modificación, y tradicionalmente codifica la fecha de la última modificación (aquí, 24 de julio de 2013). Los otros cuatro enteros son retrasos , expresados en segundos. Indican que un "secundario" (por ejemplo, el servidor DNS de un ISP, no el servidor DNS de origen para el dominio de destino) debe usar la siguiente estrategia:

  • Cualquiera que sea la información que se almacenó en la caché, debería actualizarse después de dos horas (7200 segundos), en caso de que se obtenga información más reciente.
  • En caso de que no se pueda alcanzar el DNS de origen, un servidor debe esperar media hora (1800 segundos) antes de volver a intentarlo.
  • La información que se almacenó en caché no se puede considerar como utilizable más allá de catorce días (1209600 segundos). Un servidor DNS no debe usar ni conservar la información obtenida más de quince días antes.
  • A menos que no se pueda evitar, un servidor DNS no debe volver a comunicarse con el servidor DNS de origen dentro de los cinco minutos (300 segundos) de la respuesta anterior.

La Sección 2.2 de RFC 1912 ofrece más detalles. El valor más importante, para un atacante empeñado en el envenenamiento de DNS, es el "mínimo" retraso. En este caso, significa que al atacante le será difícil hacer que su víctima coma datos DNS falsos sobre google.com antes de que hayan transcurrido al menos 5 minutos. A la inversa, el atacante solo tiene que esperar cinco minutos, o mantener su flujo tóxico de respuestas falsas durante cinco minutos, para tener una buena oportunidad de envenenar el servidor.

Hay métodos para acelerar el olvido. El atacante tiene la posibilidad de envenenar el servidor si logra que olvide lo que sabe sobre un dominio determinado. Como se explicó anteriormente, un servidor DNS ya "olvidará" la información contenida en los retrasos anunciados por el propio servidor de origen. Sin embargo, un servidor DNS mantiene su caché en la memoria RAM, que no es un recurso infinito. Esto significa que lo siguiente puede ser aplicable:

  • El atacante puede enviar correo no deseado al DNS de destino con muchas solicitudes de muchos dominios elegidos al azar, de modo que el DNS tenga más información para almacenar en la memoria caché de la que realmente puede guardar en su RAM asignada, lo que obliga a desalojar la información almacenada previamente en la caché. antes de lo que hubiera implicado el "mínimo" retraso.

  • En algunos casos, el atacante puede hacer que el DNS de destino se bloquee y reiniciarse automáticamente (depende de qué tan bien el software de DNS y el sistema operativo subyacente se manejen contra DoS attack ). Un servidor DNS bloqueado y reiniciado comienza su vida con un caché limpio y vacío, listo para ser envenenado.

  • Los servidores DNS también pueden ponerse de acuerdo sobre las notificaciones proactivas de cambios: un DNS secundario puede pedir a un primario que le avise cada vez que algunos de sus datos hayan cambiado, de modo que pueda invalidar sus cachés de inmediato, en lugar de esperar a la normalidad. actualizaciones basadas en el retraso. Un atacante trabajador puede querer intentar falsificar este mecanismo para forzar una actualización temprana.

respondido por el Thomas Pornin 21.08.2013 - 15:50
fuente

Lea otras preguntas en las etiquetas