Bloque 6 — Infoblox Inspect y seguridad DNS a escala

6.1 Del análisis manual al problema de escala

Durante los bloques anteriores analizamos DNS de forma controlada. Generamos consultas con dig, capturamos tráfico con Wireshark y aprendimos a identificar respuestas, errores, patrones y comportamientos dinámicos.

Cuando tenemos unas cuantas transacciones, el análisis manual funciona muy bien. Podemos seleccionar una consulta y aplicar nuestro modelo:

WHO → WHAT → WHERE → RESPONSE → RESULT → TIME

El problema aparece cuando una red genera miles, cientos de miles o millones de consultas. El conocimiento sigue funcionando, pero el análisis paquete por paquete deja de ser una estrategia operacional sostenible.

Entender una transacción DNS es posible manualmente. Proteger una red analizando todas sus transacciones de esa forma no lo es.

6.2 Generar tráfico con Infoblox Inspect

En este bloque utilizaremos Infoblox Inspect para generar tráfico DNS de prueba y observar qué ocurre cuando aumenta la cantidad y variedad de actividad que debemos analizar.

Inspect no será sólo una demostración del instructor. La intención es que los asistentes lo utilicen repetidamente para generar evidencia, observarla y comparar resultados.

Trabajaremos con dos escenarios utilizando, en lo posible, la misma prueba:

SCENARIO A
Inspect → DNS traffic → Wireshark

SCENARIO B
Inspect → Endpoint → Infoblox Security → Security Events

La diferencia entre ambos escenarios no será el tráfico de prueba, sino la arquitectura que lo procesa.

6.2.1 Escenario A — Analizar el tráfico únicamente con Wireshark

Objetivo práctico

Ejecutar pruebas con Inspect, capturar el tráfico DNS generado y aplicar las técnicas aprendidas durante B1–B5 para identificar manualmente los eventos relevantes.

¿Podemos identificar y explicar manualmente todo lo que Inspect está generando?

Preparación

• Infoblox Inspect disponible.
• Wireshark abierto.
• Perfil DNS-under-the-microscope activo.
• Acceso a Internet.
• Endpoint fuera de este escenario.

Paso 1 — Establecer el baseline

Capturamos tráfico durante unos segundos antes de ejecutar Inspect y aplicamos:

dns

Observamos qué consultas, tipos de registros y respuestas aparecen normalmente.

Paso 2 — Ejecutar Inspect

Sin detener Wireshark, iniciamos una prueba de generación de tráfico desde Inspect. Durante los primeros segundos no intentamos interpretar cada paquete: sólo observamos cómo cambia la captura.

NORMAL TRAFFIC
      ↓
RUN INSPECT
      ↓
DNS ACTIVITY INCREASES
      ↓
COLORS + PATTERNS + RESPONSES

Éste es nuestro “árbol de Navidad”.

Paso 3 — Seguir una transacción

Seleccionamos una consulta y aplicamos nuevamente:

WHO → WHAT → WHERE → RESPONSE → RESULT → TIME

El participante debe poder explicar quién consultó, qué nombre solicitó, a qué DNS fue enviada la consulta, qué respuesta recibió y cuánto tardó.

Paso 4 — Buscar patrones conocidos

Reutilizamos algunos filtros vistos anteriormente:

dns.flags.rcode == 3

dns.flags.rcode == 2

dns.flags.rcode == 0 && dns.count.answers == 0

dns && (dns.flags.response == 0) && !dns.response_in

También observamos las columnas QNAME, RNAME y RSP TTL.

Paso 5 — Pasar de transacciones a patrones

Ahora dejamos de seguir un único paquete y preguntamos:

• ¿Cuántos NXDOMAIN aparecen?
• ¿Cuántos nombres diferentes?
• ¿Qué clientes los generan?
• ¿Hay nombres con alta variabilidad?
• ¿Hay TTL bajos o respuestas grandes?

OBSERVE → COUNT → COMPARE → CORRELATE → INTERPRET

Paso 6 — Encontrar el límite humano

Dejamos Inspect funcionando durante más tiempo y tratamos de distinguir qué consultas representan actividad relevante y cuáles forman parte del comportamiento normal del sistema.

Puedo entender lo que veo, pero no puedo analizar manualmente cada transacción con la velocidad con la que aparece.

6.2.2 Escenario B — El mismo tráfico con Endpoint y una política predefinida

Objetivo práctico

Repetir la prueba de Inspect utilizando Endpoint y una política de Threat Defense previamente preparada, para observar qué cambia cuando la actividad DNS puede ser clasificada, priorizada y sometida a una política automáticamente.

En este curso el participante no configura la política. El diseño, ajuste y validación de políticas será parte del Curso 2.

Estado inicial

• Endpoint instalado y activo.
• Política predefinida asignada.
• Equipo visible para la plataforma.
• Wireshark ejecutándose.
• Inspect disponible.

Paso 1 — Iniciar una captura limpia

Creamos una nueva captura para poder comparar claramente los dos escenarios. Antes de ejecutar Inspect podemos aplicar nuevamente:

dns

Aquí puede aparecer la primera diferencia: el Endpoint puede transportar las consultas mediante un canal cifrado, por lo que ya no necesariamente veremos los QNAME como antes.

Paso 2 — Ejecutar la misma prueba

Repetimos, en lo posible, exactamente el mismo test de Inspect.

Paso 3 — Observar Wireshark

Intentamos localizar el tráfico generado por Inspect. Esta vez podemos observar principalmente la comunicación cifrada asociada al Endpoint, en lugar del contenido DNS en claro.

La pregunta para el grupo es simple:

¿Qué cambió?

Paso 4 — Ir al Cloud Services Portal

Revisamos la actividad generada durante el mismo periodo. Según los campos disponibles en el evento, buscamos información como:

CLIENT
DOMAIN
DETECTION / CATEGORY
POLICY
ACTION
TIME

Ahora la pregunta deja de ser “¿puedes encontrar el paquete?” y pasa a ser “¿qué hizo la plataforma con esta consulta y por qué merece nuestra atención?”.

Paso 5 — Seleccionar un evento

Elegimos un solo evento generado por Inspect y tratamos de explicarlo utilizando el conocimiento adquirido durante el curso.

No queremos concluir:

Es malicioso porque la plataforma lo dice.

Queremos construir una explicación basada en comportamiento, contexto y evidencia.

Paso 6 — Comparar con el Escenario A

Paso 7 — Pregunta al grupo

¿Qué conocimiento adquirido durante B1–B5 dejó de ser necesario cuando activamos Threat Defense?

Ninguno.

6.3 Comparar visibilidad manual vs. eventos de seguridad

Después de ejecutar los dos escenarios podemos comparar qué aporta cada enfoque.

Con Wireshark tenemos visibilidad profunda del protocolo y podemos reconstruir una transacción. Cuando el volumen crece, el problema es decidir cuáles de todas esas transacciones merecen atención.

TOO MANY TRANSACTIONS
        ↓
MANUAL CORRELATION
        ↓
HUMAN BOTTLENECK

Con Threat Defense cambia la unidad de análisis:

MANY DNS TRANSACTIONS
        ↓
SECURITY PROCESSING
        ↓
PRIORITIZED EVENT

La plataforma ayuda a clasificar, correlacionar y priorizar, mientras que Wireshark sigue siendo útil para comprender el comportamiento de red.

Wireshark nos ayuda a comprender una transacción. Los eventos de seguridad nos ayudan a decidir cuáles merecen atención cuando el volumen ya no permite revisarlas todas manualmente.

6.4 DNS cifrado: privacidad, movilidad y visibilidad

En el Escenario A pudimos observar directamente las consultas DNS con Wireshark. Cuando DNS viaja cifrado mediante mecanismos como DoT, DoH o HTTP/3 sobre QUIC, Wireshark continúa viendo la comunicación de red, pero ya no necesariamente puede leer el contenido DNS.

PLAIN DNS
   ↓
DNS CONTENT VISIBLE

ENCRYPTED DNS
   ↓
TRAFFIC VISIBLE
DNS CONTENT ENCRYPTED

Esto protege las consultas frente a observadores intermedios y es especialmente importante cuando un dispositivo utiliza redes que la organización no controla: casa, hotel, aeropuerto, Wi-Fi público o el ISP.

Con DNS tradicional podemos observar:

QNAME
QTYPE
RCODE
ANSWER
TTL

Con DNS cifrado podemos seguir observando elementos como:

Source
Destination
TLS / QUIC
Timing
Traffic volume

pero no necesariamente el contenido de la consulta.

En nuestro Escenario B, aunque Wireshark ya no muestre el DNS en claro, el servicio que procesa la consulta puede seguir teniendo visibilidad y generar eventos de seguridad.

DEVICE
   ↓
ENCRYPTED DNS
   ↓
INFOBLOX
   ↓
SECURITY EVENT

Esto permite combinar:

El caso de las aplicaciones

Algunas aplicaciones pueden utilizar sus propios mecanismos de DNS cifrado. Firefox, por ejemplo, puede utilizar DoH y mecanismos como canary domains para decidir cómo resolver DNS.

No necesitamos profundizar aquí en su implementación. La lección es que una aplicación puede cambiar el camino que sigue una consulta DNS y eso también cambia dónde podemos observarla.

Ideas clave

ENCRYPTED ≠ INVISIBLE

VISIBILITY DEPENDS ON
THE OBSERVATION POINT

PRIVACY AND SECURITY VISIBILITY
CAN COEXIST

Cifrar DNS no elimina la visibilidad; cambia el lugar desde donde podemos obtenerla.

6.5 Comprender primero, automatizar después

Durante este curso comenzamos con dig. Después aprendimos a observar tráfico con Wireshark, reconstruir transacciones, interpretar respuestas, identificar patrones y entender comportamientos dinámicos.

Al llegar al Bloque 6 el conocimiento adquirido sigue siendo válido. Lo que deja de ser suficiente es hacer todo manualmente.

NXDOMAIN ≠ ATTACK

LOW TTL ≠ FAST FLUX

DIFFERENT RESPONSE ≠ FAILURE

SECURITY EVENT ≠ ROOT CAUSE

Por eso el orden importa:

La automatización puede reducir el espacio de búsqueda y priorizar eventos, pero el SE todavía necesita comprender qué significa lo que está viendo.

MASSIVE DNS TRAFFIC
        ↓
AUTOMATION
        ↓
RELEVANT EVENTS
        ↓
HUMAN ANALYST

El mensaje final

La seguridad DNS no empieza con una herramienta. Empieza entendiendo el protocolo. Pero entender el protocolo tampoco significa que podamos proteger una red analizando paquetes uno por uno.

Comprender primero. Automatizar después. Y cuando algo no tenga sentido, volver a la evidencia.