¿Cuál es el mejor antídoto para el envenenamiento de caché de DNS?

  

Pero, ¿cuál es la más efectiva?

Abordan temas ligeramente diferentes:

• La aleatorización de puertos hace que la falsificación de DNS sea más difícil porque hay un secreto desconocido adicional para el atacante (el puerto) que debe coincidir con la respuesta falsificada.
• Con DNSSec, uno puede detectar de manera confiable si la respuesta fue falsificada.

  

¿Qué soluciones se implementan realmente en los servidores de nombres hoy?

DNSSec en todas partes probablemente haga que la asignación aleatoria de puertos sea obsoleta, pero actualmente estamos lejos de una adopción suficiente. Por el momento, necesitamos aleatorización de puertos. Pero esto no es una solución del lado del servidor, sino que debe hacerlo el cliente (un caché de DNS funciona como un cliente cuando se le pregunta a otro servidor de DNS).

El envenenamiento de caché se produce más fácilmente cuando toda la infraestructura usa el mismo conjunto de resolutores recursivos. Para mitigar este riesgo, prefiero tener diferentes resolutores recursivos para estos roles:

1. Consultas de usuarios finales, navegación web: para todas las estaciones de trabajo, o idealmente WCCP, use una infraestructura de DNS dedicada. Para mayor seguridad, use DNSSecurity como OpenDNS

2. Consultas de usuario final, todas excepto navegación web: el host DNS configurado en la estación de trabajo debe estar aislado del resto de la infraestructura que se describe a continuación

3. Procesamiento de correo electrónico y AntiSPAM: los correos electrónicos que llegan a la consulta de registros SPF, y otras comprobaciones de DNS que pueden resultar en una consulta de DNS que posiciona el caché. Por este motivo, trato de separar el procesamiento del correo electrónico de cualquier cosa que un usuario final intente utilizar en Internet en general.

4. DMZ, y utilidades de análisis de encabezados en la DMZ: si la DMZ actúa sobre los datos del DNS obtenidos de terceros que no son de confianza, se debe asumir que esos servidores del DNS posiblemente intenten envenenar su DNS.

5. IDS, macetas de miel

¿Por qué es esto importante? Imagine que un atacante puede forzar una consulta de DNS que se produce en su servidor DNS central simplemente enviando un correo electrónico, conectándose a un servidor DNS determinado o ingresando datos en un formulario HTML. Dado que un resolutor recursivo consultará a todos los servidores DNS según sea necesario para satisfacer la solicitud, es posible contaminar una entrada de caché para los usuarios de estaciones de trabajo con la consulta de infraestructura mencionada anteriormente.