¿Cómo clasificar los paquetes DNS que llegan a los clientes como falsificados o no?

Probablemente sea imposible mirar un solo paquete DNS y saber si está falsificado o no. Pero, si se trata de un paquete de respuesta de DNS a un sistema sin una solicitud de DNS coincidente un poco antes, es probable que se trate de una suplantación de identidad. Y si hay una solicitud de DNS que se origina en la máquina pero la respuesta de DNS entrante sí responde a la consulta de DNS pero no coincide en la solicitud de DNS en el puerto y la identificación, es probable que este sea también un intento de suplantación de identidad, especialmente si hay muchos de estos desajustes. los paquetes

Si está supervisando las solicitudes de DNS en sus clientes, habría pensado que cualquier solicitud en la que la IP de origen es la del equipo cliente no se falsificaría, y cualquier otra cosa se falsificaría.

Desde la perspectiva del servidor, es un poco más complicado, pero hasta cierto punto:

• en términos de monitoreo de tráfico, es posible que pueda obtener algo al retirar los TTL de los paquetes entrantes; si el TTL sugiere que una solicitud ha cruzado más saltos de los que sabe que tiene en su red, existe la posibilidad de que podría estar falsificado (o simplemente identificó algo para ver en términos de enrutamiento)
• el puerto de origen podría ayudar a un punto, en particular, cualquier cosa que se pareciera al tráfico de servidor a servidor y que no fuera de un servidor que usted conocía podría apuntar a que algo no esté sucediendo. Si tiene un rango conocido de puertos que los clientes configuran para usar (por ejemplo, 10000 a 30000), entonces vale la pena investigar cualquier cosa fuera de ese rango.
• dependiendo de los detalles de su configuración, puede obtener una idea de dónde proviene el tráfico (por ejemplo, un firewall externo está grabando paquetes entrantes con una IP de origen falsificada, o la interfaz entrante para una solicitud no es t correcto
• su proceso puede ser un proceso de eliminación que puede aplicar: ¿la IP y / o el rango de origen están en uso dentro de su red? ¿Se sabe que la IP de origen específica está activa en un cliente legítimo (es decir, DHCP / ActiveDirectory / algo más se correlaciona con este cliente real)?

Algunos detalles más sobre tu configuración y motivaciones podrían ayudarte a pensar en otras áreas, pero esperamos que las anteriores sean de alguna utilidad.

Editar :

Leyendo los comentarios, me di cuenta de que entendía mal la pregunta como si se tratara de solicitudes falsificadas, en lugar de respuestas falsas.

Como lo señaló otro, para las respuestas de DNS, las cosas son más complicadas. De las sugerencias anteriores, solo mirando TTL parece que incluso valdría la pena considerarlo.

Es posible que pueda poner algo en su lugar para sus registros DNS internos (tal vez comparando las respuestas DNS internas con los valores esperados). Pero eso parece ser una pequeña parte del problema general, para el cual es más difícil encontrar una solución.

Supongo que otra cosa que podría considerar es perfilar los DNS TTL (así como los IP TTL): sitios significativos como google, facebook, etc. tienen TTL bastante bajos (300 segundos) para los registros A, por ejemplo, y usted podría esperar que alguien que intenta envenenar cachés tenga interés en usar TTL mucho más altos para estos registros.

Para los registros A, también puede obtener algo al analizar realmente las respuestas; por ejemplo, intentar verificar las que usan GeoIP podría ayudar.

¿qué tan efectivo sería todo eso (en comparación con la cantidad de trabajo que sería mantener)?

La detección de respuestas de DNS UDP falsificadas es compleja. Puede considerar realizar solicitudes de DNS solo a través de TCP y rechazar las respuestas de DNS a través de UDP con una regla de firewall. Dado que TCP requiere un protocolo de enlace de tres vías, es muy difícil de falsificar.