DNS Tunneling - Mitigación

Question

DNS Tunneling - Mitigación

#1 de Avineshwar (1 votos)

5

Creo que la causa raíz de los túneles de DNS se debe a que los hosts internos tienen permiso para realizar consultas recursivas de dominios externos. Para que el túnel DNS funcione, un host interno debería poder enviar consultas al dominio controlado por el atacante dnstunnel.xyz.com.

Me preguntaba si limitaríamos las consultas de DNS a los servidores de DNS conocidos / autorizados únicamente, ¿evitará este ataque? Para dejarlo claro, cuando ejecutamos nslookup para un dominio externo desde dentro de la organización utilizando un servidor DNS de terceros, no se resolvería.

C:\Users\bAdb0y>nslookup cisco.com 8.8.8.8
DNS request timed out.
timeout was 2 seconds.
Server:  UnKnown
Address:  8.8.8.8

DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to UnKnown timed-out

Intenté configurar un túnel DNS usando yodo con y sin la configuración anterior. No se pudo establecer el túnel cuando las consultas recursivas se limitaron a los servidores DNS internos. El túnel funcionaba como encanto de lo contrario. Entonces, ¿esta solución es efectiva? ¿O necesito deshabilitar completamente la consulta recursiva de las máquinas internas?

dns attack-vector dns-domain tunneling

pregunta bAd bOy 01.02.2017 - 06:58

fuente

1 respuesta

Lea otras preguntas en las etiquetas dns attack-vector dns-domain tunneling

Corrí netstat y una cosa que surgió fue MSN bingbot, ¿significa que mi computadora está siendo utilizada como parte de una botnet de Microsoft? Restaurando la base de datos desde un sistema pirateado

score 1 · Answer 1

En primer lugar, la tunelización de DNS generalmente aprovecha el hecho de que el tráfico de DNS no suele ser monitoreado.

Por lo tanto, para (dar o recibir) manejar eficazmente los túneles de DNS se requieren:

Análisis de la carga útil (vista de alto nivel en una consulta de DNS en sí)
Análisis de tráfico (análisis de estado, es decir, seguimiento de solicitudes / respuestas múltiples de consultas de DNS)

También hay un montón de otras cosas para agregar (medición de entropía en una consulta de DNS, etcétera) también. Puede consultar la SANS .

La idea es evitar que una máquina se vea comprometida en primer lugar. Una máquina no contabilizada / desconocida comprometida en una red es un gran problema.

Dado que no será un tema importante, omitiré lo que las organizaciones suelen hacer para evitar meterse en esta situación en primer lugar.

Por lo que vale, debido a la misma razón, una protección definida contra un shell inverso es muy difícil. El análisis de patrones / tráfico (con o sin eliminación de SSL) es el camino a seguir para esto, de nuevo .