Logstash: Creando un panel de control personalizado (II)

Hoy os voy a presentar el resultado del trabajo que hicimos en el post del otro día. Una vez cargados todos los datos, accedemos con nuestro navegador al puerto 9292 del equipo donde hemos desplegado Logstash (en nuestro caso nuestro propio equipo), y empezamos a jugar con todas las visualizaciones que proporciona . El resultado inicial es el siguiente:

Aquí podemos ver como hemos introducido varios parámetros de búsqueda, que coinciden con las categorías que proporciona Emerging Threats, el conjunto de reglas que usamos en la sonda que hemos utilizado para las pruebas.

A continuación aparece por defecto un histograma que nos permite ver, de un vistazo, qué tipos de ataques han sido los que más hemos sufrido. Como se puede apreciar, hay varios picos de alertas “ET SCAN” que corresponden con escaneos hacia nuestra infraestructura, así como varios picos de alertas del tipo “ET P2P”, que nos hacen pensar que alguno de nuestros usuarios ha utilizado herramientas P2P.

A partir de este punto es donde empezamos la personalización, generando nosotros mismos las visualizaciones que queramos.

La primera visualización interesante es la de terms, que para un campo concreto que le indiquemos, obtiene los valores más (o menos) comunes. Se puede configurar para que nos muestre los resultados en un gráfico de barras, de tarta, o en una lista simple (como veremos más adelante).

Además, nos permite mostrar el número de registros con otros valores fuera de los que muestra (‘Other values’), e incluso a los que les falta el campo que estamos visualizando (‘Missing’).

Utilizando esta visualización para las IP y los puertos origen y destino obtenemos una vista como la siguiente:

Seguidamente, vemos otra de las visualizaciones que hemos generado:

Aquí aparece, a la izquierda, una visualización de tipo terms sobre las firmas más comunes que han generado alertas. Este caso es ligeramente diferente, ya que para que funcione bien la visualización debemos seleccionar el campo sig_name.raw. Esto se debe a que elasticsearch por defecto procesa todos los campos que le llegan, separándolos en palabras, de forma que la visualización de tipo terms actuaría para cada palabra que forma la firma, dejando por ejemplo en primer lugar el término “ET” con un valor igual al número de alertas que se han generado. Para evitar esta separación y poder obtener el valor deseado, logstash añade por defecto a cada campo otro homónimo con el sufijo “.raw”, que marca para que no sea procesado por elasticsearch, dejando el resultado como se aprecia en la imagen anterior.

Otra visualización interesante es la de tendencias (trends), que compara, para cada una de las búsquedas que hemos realizado, su evolución temporal, en base a un intervalo prefijado. Si por ejemplo, fijamos el intervalo en 1 día, comparará el número de ocurrencias de cada búsqueda en las últimas 24h, y el valor para las 24h anteriores, mostrando la diferencia en porcentaje.

Para finalizar, tenemos un gráfico de tarta que muestra la distribución de los protocolos IP utilizados por las alertas generadas.

En la parte inferior de la página vemos otra visualización por defecto, se trata de un listado detallado con un número determinado de alertas, de entre todas las que cumplen los requisitos indicados en las búsquedas. Como ya indiqué en el anterior post, se pueden seleccionar campos para que se ordene la información por ellos, y abrir cada alerta para ver todos sus campos.

Para finalizar el post, os voy a mostrar otra visualización muy interesante, que se puede obtener modificando el fichero de configuración que generamos para cargar los datos, añadiendo las siguientes líneas en el apartado filter:

  geoip {
	database => "/usr/share/GeoIP/GeoLiteCity.dat"
	source => ip_src
	target => geoip_src
  }
  geoip {
	database => "/usr/share/GeoIP/GeoLiteCity.dat"
	source => ip_dst
	target => geoip_dst
  }

Con ello obtendremos dos nuevos campos, con los que podremos generar mapas localizando hasta la ciudad a la que pertenecen las IP origen y destino de las alertas, siempre que sea posible.

Para obtener estos mapas el panel se creará con la visualización bettermap, y el único campo que necesitaremos introducir es el Coordinate, donde debemos indicar, por ejemplo, el campo geoip_src.location si queremos generar un mapa con los orígenes de los ataques.

El resultado es el siguiente:

Por supuesto, el mapa es navegable y al pulsar en cualquiera de los puntos el mapa se acerca, mostrando un desglose específico de las alertas por área geográfica.

En las últimas semanas se ha cambiado el proveedor de mapas para esta visualización, por lo que es posible que no se cargue ningún mapa al generar esta visualización. Para solucionar este problema, tan sólo es necesario realizar el cambio que se muestra en este commit de GitHub en el fichero vendor/kibana/app/panels/bettermap/module.js dentro de la carpeta donde se encuentra logstash.

Espero que os haya gustado esta entrada, y os animéis a jugar con este gran conjunto de herramientas.

Logstash: Creando un panel de control personalizado (I)

Logstash es una herramienta muy potente, que permite visualizar y analizar gran cantidad de información de una forma ágil y cómoda, y que está teniendo una gran aceptación en muchos ámbitos diferentes. En mi anterior entrada, que he actualizado con detalles de funcionamiento de la última versión de LogStash publicada, os contaba cómo iniciarse en el uso de esta aplicación, y empezar a probar su gran potencial.

Hoy vamos a ver otro posible uso para esta magnífica aplicación. Se trata de realizar un pequeño análisis sobre las alertas que se han generado en una sonda Snort durante un periodo determinado de tiempo.

Para ello, lo primero es disponer de las alertas en un fichero, para que la aplicación las pueda procesar. Una consulta como la siguiente nos servirá para extraer la información al fichero /tmp/saw_dump.csv:

SELECT
	sig_name AS sig_name,
	dec2ip(ip_src) AS ip_src,
	layer4_sport AS port_src,
	dec2ip(ip_dst) AS ip_dst,
	layer4_dport AS port_dst,
	ip_proto AS ip_proto,
	timestamp AS timestamp
FROM
	acid_event
WHERE
	timestamp >= 20140301
	and timestamp < 20140401
INTO OUTFILE'/tmp/saw_dump_march.csv'
	FIELDS TERMINATED BY ';'
	LINES TERMINATED BY '\n'
;

El fichero creado tendrá un contenido similar al siguiente:

ET P2P BitTorrent Announce ;AA.AA.AA.AA;18301;XX.XX.XX.XX;6969;6;2014-03-01 
      00:00:00
ET MALWARE User-Agent (Mozilla/4.0 (compatible ICS)) ;AA.AA.BB.BB;3289;
      XX.XX.XX.XX;80;6;2014-03-01 00:00:00
ET MALWARE Suspicious Mozilla User-Agent - Likely Fake (Mozilla/4.0) ;
      AA.AA.CC.CC;62460;XX.XX.XX.XX;80;6;2014-03-01 00:00:00
ET P2P BitTorrent Announce ;AA.AA.DD.DD;18301;XX.XX.XX.XX;6969;6;2014-03-01
      00:00:00
ET WEB_SERVER Outbound PHP User-Agent;AA.AA.EE.EE;53376;XX.XX.XX.XX;80;6;
      2014-03-01 00:00:00

Si echamos un vistazo a los patrones que incluye por defecto vemos que, como era de esperar, no hay ninguno que coincida con la salida de nuestra consulta, por lo que tendremos que generar un patrón nuevo para poder procesar toda la información necesaria. Para ello, nos ayudaremos de la aplicación web Grok Debugger, que nos permite, a partir de un ejemplo de nuestro log, generar un patrón de forma sencilla.

La estructura de los patrones de Grok es la siguiente: %{SINTAXIS:SEMÁNTICA}. En SINTAXIS se define el nombre del patrón que se buscará (puede ser una cadena, una IP, un entero, una fecha, etcétera. En definitiva, cualquier patrón definido anteriormente), y en SEMÁNTICA qué nombre le vamos a dar en la salida a dicho parámetro. Con esto en mente, creamos los siguientes patrones para poder procesar correctamente el fichero de log que hemos generado:

SNORT_SIMPLE %{DATA:signature};%{IP:ip_src};%{POSINT:port_src};
      %{IP:ip_dst};%{POSINT:port_dst};%{DATA:proto};%{TIMESTAMP:timestamp}

DATE_ENG %{YEAR}[./-]%{MONTHNUM}[./-]%{MONTHDAY}

TIMESTAMP %{DATE_ENG} %{TIME}

Estos patrones personalizados los guardamos en un fichero de texto, que luego indicaremos a Logstash para que los pueda interpretar.

Antes de continuar, apuntar un pequeño detalle; hemos generado el patrón a partir de un ejemplo, así que es posible que el patrón generado no cubra todos los posibles valores de entrada con los que nos podemos encontrar, por lo que será necesario, al menos al principio, revisar la salida por consola de LogStash o Kibana en busca de elementos con el tag “_grokparsefailure”.

Es el caso del siguiente mensaje:

Aquí vemos que, al tratarse de una alerta ICMP, los valores de los puertos son nulos por lo que aparece la cadena “\N”, que no coincide con el valor de entero positivo que habíamos asignado en nuestra definición de patrón, dando lugar al fallo. En este caso, debemos modificar dicho patrón para que tenga en cuenta que es posible que los valores de los puertos sean nulos, quedando el listado como sigue:

SNORT_SIMPLE %{DATA:signature};%{IP:ip_src};(?:%{POSINT:port_src}|\N);
      %{IP:ip_dst};(?:%{POSINT:port_dst}|\N);
      %{DATA:proto};%{TIMESTAMP:timestamp}

DATE_ENG %{YEAR}[./-]%{MONTHNUM}[./-]%{MONTHDAY}

TIMESTAMP %{DATE_ENG} %{TIME}

Ahora sólo nos falta configurar Logstash con el fichero a procesar, e indicarle dónde están los patrones que vamos a aplicar en este caso. Para ello, generamos un nuevo fichero de configuración (que hemos llamado logstash-snort.conf) con el siguiente contenido:

input {
  file {
	start_position => "beginning"
	path => [ "/home/jvila/saw_dump_march.csv" ]
  }
}

filter {
  grok {
  	patterns_dir => "./patterns"
  	match => { "message" => "%{SNORT_SIMPLE}" }
  }

  date {
  	match => [ "timestamp", "yyyy-MM-dd HH:mm:ss" ]
  	locale => "en"
  }
}

output {
  elasticsearch { embedded => true }
}

Los cambios principales respecto al fichero mostrado en el artículo anterior los encontramos en la cadena que se busca en el filtro, y el formato de la fecha proporcionado por la base de datos.

Para finalizar, tan sólo debemos lanzar Logstash y esperar a que cargue toda la información necesaria, ejecutando por una parte el proceso que recopilará toda la información:

jvila@jvila:~/logstash-1.4.0$ bin/logstash -f logstash-snort.conf

Y por otra el que nos cargará la web:

jvila@jvila:~/logstash-1.4.0$ bin/logstash web

Mañana, si el editor me deja, os enseño el resultado y os explico algunas vistas que nos han parecido interesantes.

Estad atentos.

Alternativas a Splunk: Logstash

Hoy vamos a hablar de una herramienta gratuita que puede servirnos de alternativa al conocido Splunk para realizar análisis de logs de forma rápida y sencilla.

Logstash es una aplicación de Java que podemos lanzar en cualquier equipo con una versión actual de Java, y que gracias al servidor de búsqueda ElasticSearch que incorpora, puede ampliarse y desplegarse en infraestructuras complejas con múltiples nodos trabajando en paralelo.

Para mostrar su funcionamiento no necesitamos hacer un despliegue tan complejo, y vamos a aprovechar la funcionalidad autocontenida en el paquete descargable, para analizar un conjunto de ficheros de Apache en busca de patrones sospechosos.

[Read more…]

Apache: guardar peticiones POST en los logs

De un tiempo a esta parte muchos de los ataques que sufren los portales web se materializan en peticiones POST. Inyecciones SQL, inclusión de ficheros remotos o envenenamiento de parámetros son sólo algunos de los ataques en los que intervienen peticiones POST.

El problema es que por regla general la información de las peticiones POST no se guarda en los logs, por lo que al hacer un análisis forense a un equipo atacado, generalmente nos falta información para poder esclarecer el origen del compromiso o la información que se ha podido ver comprometida.

Por ello vamos a ver, centrados en el servidor web Apache, las posibilidades que existen para guardar el contenido de las peticiones POST que se hacen a nuestro servidor web.

[Read more…]

Liberada Guía Nmap 6 de CSIRT-cv y CCN

Hoy os traemos una guía muy interesante, realizada por @BufferOverCat y un servidor (@jovimon), que se ha liberado en los últimos días. La guía, fruto de la colaboración del Centro Criptológico Nacional (CCN) y el Centro de Seguridad TIC de la Comunidad Valenciana (CSIRT-cv), muestra de forma útil y práctica el funcionamiento de Nmap, detallando las técnicas que se pueden utilizar con este analizador de redes.

La guía se finalizó el verano del año pasado, poco tiempo después de la publicación de la versión 6.01 de Nmap, y ha estado hasta ahora únicamente disponible a través del portal del CCN para usuarios de administraciones públicas. Con la liberación de esta guía, única de este tipo que existe en Español, para el público general, se cubre un hueco que hasta ahora únicamente se podía cubrir con textos en otros idiomas.

Por si a estas alturas alguien aún no conoce Nmap, destacar que es sin lugar a dudas la herramienta más utilizada para realizar análisis de redes. Con ella se pueden realizar todo tipo de tareas, desde el descubrimiento de equipos y servicios disponibles en una red, a análisis avanzados que incluyan auditorías tanto a los equipos y servicios descubiertos como a cortafuegos o elementos intermedios de red que puedan interponerse en la comunicación. Es por ello que tanto por administradores de red como auditores de seguridad la utilizan de forma habitual.

La guía se compone de una completa documentación sobre las funcionalidades disponibles, que cubre las técnicas, tanto básicas como avanzadas, de: descubrimiento de equipos, análisis de puertos, optimización, rendimiento, etcétera, y se muestran procedimientos recomendados de actuación dependiendo de la tarea que se quiera realizar.

Además, se cubren dos de las principales mejoras que incluye esta versión: el soporte completo para IPv6 y el motor de scripting de Nmap (NSE: Nmap Scripting Engine), al que se dedica un tema entero. En este tema, se detalla el funcionamiento del motor y se dan directrices detalladas, tanto para entender los scripts ya creados como para crear nuevos scripts.

Aunque la versión actual de Nmap disponible para descarga es la 6.40, las diferencias con la versión de la guía son mínimas, ya que en los últimos tiempos los esfuerzos se centran en aumentar la cantidad de sistemas y servicios diferentes detectados, así como aumentar también las capacidades del motor NSE y el número de scripts que se ofrecen por defecto (actualmente más de 450).

La Guía Avanzada de Nmap está disponible en la sección de descargas del portal de CSIRT-cv y en la web del CCN.

Script para tratamiento de reglas de Snort

En el artículo de hoy os vamos a mostrar un pequeño script que hemos realizado JoseMi Holguín (@J0SM1) y un servidor, y cuya finalidad es poder tratar el conjunto de reglas activas en una instalación de Snort y, llegado el caso, realizar modificaciones a las mismas.

El script está realizado en python, y cuenta con dos clases, una llamada ruleDissector(), que se encarga de trocear cada regla y guardar sus parámetros por separado, y otra llamada ruleseParser(), que lee los ficheros de configuración de Snort y selecciona los ficheros de reglas que están activos.

Para utilizar el script únicamente es necesario importarlo, y llamar a la siguiente función (todos los parámetros son opcionales, y se muestran los valores por defecto):

ruleset = rulesetParser(basedir = '/usr/local/snort/etc', snortfile = 'snort.conf', 
    classiffile = 'classification.config', rulesdir = 'rules')

[Read more…]

Conferencias Navaja Negra – Día 1

Hace unos días, mi compañero Joel (@jsevilleja) y yo asistimos a las charlas Navaja Negra, que tuvieron lugar en Albacete del 3 al 5 de octubre. Navaja Negra son unas charlas jóvenes (van por la tercera edición), pero a pesar de ello congregan a un montón de gente interesante, manteniendo un espíritu colaborativo y cercano. Podéis seguir lo que se ha escrito sobre ellas en los hashtag #nn3ed y #nn3d, o seguir su cuenta oficial de Twitter en @navajanegra_ab.

Las conferencias tuvieron lugar, después de un cambio de ubicación a última hora, en las instalaciones de la Universidad Popular de Albacete. Tras el acto de bienvenida, empezaron las charlas.

La primera de ellas corrió a cargo de Juan Carlos Montes (@jcmontes_tec), de Inteco, que nos habló de una herramienta que ha desarrollado, llamada Telepathy. Esta herramienta proporciona una gran versatilidad a la hora de analizar muestras de malware ya que permite al analista actuar en dos frentes: por una parte, permite cargar nuevas DLL en un proceso en ejecución y hacer que este proceso las utilice; por otra, permite lanzar la ejecución bajo demanda de cualquier función o fragmento de código incluida en un proceso en ejecución. Este segundo supuesto es muy útil por ejemplo en funciones de cifrado y descifrado de las comunicaciones del malware, ya que da la posibilidad al analista de obtener las órdenes que envía y recibe una muestra de código malicioso sin tener que hacer ingeniería inversa sobre dicha muestra.

[Read more…]

Múltiples interfaces en la misma subred

Hoy vamos a hablar de un problema que tuvimos hace unos días con un equipo nuevo que estamos configurando.

Al principio teníamos únicamente una IP para acceder a configurar y gestionar el equipo, la 172.16.1.10 (interfaz eth0). Más adelante, solicitamos que se añadiera otra interfaz de red, para poder dedicar una a configuración y gestión interna y otra a ofrecer el servicio al exterior. Por problemas en el direccionamiento, nos asignaron en la nueva interfaz otra IP de la misma subred local que la que ya teníamos, la 172.16.1.20 (interfaz eth1).

Probando la nueva IP nos dimos cuenta de que, independientemente de la IP que yo solicitara, todo el tráfico llegaba al sistema por la misma interfaz: eth0. Es más, desde otro equipo de la misma subred, podía ver como ARP me indica que ambas IP se sirven por la misma interfaz física:

$ arp -n
Dirección      TipoHW  DirecciónHW         Indic Máscara     	Interfaz
172.16.1.10    ether   aa:bb:cc:dd:ee:ff       C                    eth0
172.16.1.1     ether   00:00:00:00:00:01       C                    eth0
172.16.1.20    ether   aa:bb:cc:dd:ee:ff       C                    eth0

La investigación en Internet fue bastante desalentadora hasta que averiguamos que este comportamiento se debe a que la pila IP implementada en Linux asigna por defecto las direcciones IP a todo el equipo, ya que se implementó pensando en maximizar la disponibilidad del equipo. De este modo, si cae una interfaz, el tráfico de todas las IP asociadas al equipo se redirigirá por la otra y el equipo, con todos sus servicios, seguirá estando disponible.

Por suerte, este comportamiento por defecto se puede modificar para conseguir el funcionamiento que nosotros queremos, que es tener una IP diferente asignada única y exclusivamente a una interfaz de red. Para esta tarea utilizaremos la suite iproute, incluida por defecto en las distribuciones Debian y Ubuntu más actuales, así como el siguiente manual de enrutado avanzado y control de tráfico en Linux.

Como queremos que el cambio sea persistente, modificaremos el fichero /etc/network/interfaces para añadir los siguientes valores al final de la definición de cada una de las interfaces implicadas:

up ip route add 172.16.1.0/25 dev eth0 proto kernel scope link src 172.16.1.10 table 1
up ip route add default via 172.16.1.1 dev eth0 table 1
up ip rule add from 172.16.1.10 lookup 1

Estas tres líneas crean una tabla de enrutado (table 1) en la que se indica que todo aquel tráfico que tenga como fuente la IP asignada a eth0 vaya únicamente por eth0. Para la otra interfaz añadiremos las mismas líneas, cambiando el nombre de la interfaz, la tabla, y la dirección IP. Además, para poder descargar actualizaciones del sistema u otros materiales que vengan de redes externas, debemos añadir una ruta de salida por defecto (esta vez sin asignar ningún valor de tabla):

up ip route add default via 172.16.1.1 dev eth0 

Con todo lo anterior, la configuración completa quedaría como sigue:

# cat /etc/network/interfaces
iface lo inet loopback
auto lo

auto eth0
iface eth0 inet static
address 172.16.1.10
network 172.16.1.0
netmask 255.255.255.128
broadcast 172.16.1.127
up ip route add 172.16.1.0/25 dev eth0 proto kernel scope link src 172.16.1.10 table 1
up ip route add default via 172.16.1.1 dev eth0 table 1
up ip rule add from 172.16.1.10 lookup 1
up ip route add default via 172.16.1.1 dev eth0

auto eth1
iface eth1 inet static
address 172.16.1.20
network 172.16.1.0
netmask 255.255.255.128
broadcast 172.16.1.127
up ip route add 172.16.1.0/25 dev eth1 proto kernel scope link src 172.16.1.20 table 2
up ip route add default via 172.16.1.1 dev eth1 table 2
up ip rule add from 172.16.1.20 lookup 2

Replicación pasiva de DNS (III)

Vamos a seguir con nuestra serie sobre la Replicación Pasiva de DNS, abordando por fin la instalación de la sonda en nuestra red. En anteriores entradas dimos una introducción al tema y hablamos de las posibles alternativas de diseño de la infraestructura.

El agente

Para hacer la labor de recolección de información hemos decidido utilizar el agente passivedns desarrollado por Edward Bjarte Fjellskål (usuario de github y también conocido como gamelinux), que nos proporciona tanto la capacidad de captura de tráfico y extracción de información, como el paso de esa información a una base de datos.
[Read more…]

Replicación pasiva de DNS (II)

Después de un paréntesis (mis disculpas para nuestro lector Javi, que nos pedía continuar con esta serie en los comentarios del primer post), continuamos hablando de la replicación parcial del árbol DNS de forma pasiva.

En la anterior entrada hemos dejado claro lo que queremos obtener y por qué, y hoy cubrimos el diseño de la infraestructura necesaria para poner en marcha una sonda de este tipo en nuestra organización.

Recursos hardware

Para poner en marcha esta sonda necesitamos, en primer lugar, infraestructura de red que nos permita realizar una captura de tráfico y enviarla a nuestra sonda. Estamos hablando de dispositivos con capacidad de reenviar tráfico hacia otro equipo (bien electrónica de red o bien dispositivos de monitorización de red como sondas IDS/IPS, gestores de tráfico, etcétera), o de TAP físicos (dispositivos que copian el tráfico que pasa por un cable de red a otro).

Los recursos que necesita la propia sonda son más bien reducidos, ya que únicamente necesitamos un equipo con una buena interfaz de red que sea capaz de procesar todo el tráfico capturado (aunque el tráfico no DNS se descarta en la entrada de la aplicación y no es procesado), y suficiente espacio en disco duro como para albergar los registros necesarios.

Si queremos hacer una visualización y procesado posterior de la información, necesitaremos también disponer de una base de datos en la que insertar la información generada con la aplicación, y un servidor web para obtener los resultados a nuestras consultas. Estos elementos pueden estar en la misma sonda, o en otro equipo al que tengamos acceso.

Ubicación del sensor

La decisión más importante es dónde situar nuestra sonda.

Vamos a suponer que disponemos de servidores DNS internos a la organización, por lo que la estructura más adecuada sería la se muestra en el siguiente diagrama:

En él podemos ver cómo desde la red interna se realizan peticiones al servidor DNS corporativo (1), y este a su vez reenvía las peticiones para las que no tiene respuesta a un servidor DNS externo (2). Cuando recibe la respuesta adecuada (3), la reenvía al cliente que realizó la petición original (4).

El lugar más adecuado para colocar nuestra sonda es, por tanto, el punto de la red más cercano a nuestros servidores DNS, ya que allí obtendremos únicamente el tráfico DNS que queremos analizar. El diagrama siguiente muestra esta localización.

Sin embargo, a pesar de que en el anterior post comentaba que no se guarda información sobre los clientes que realizan las peticiones DNS, hemos encontrado aplicaciones en las que sí que se guarda la información sobre el cliente que ha realizado una petición determinada. A pesar de que se puede considerar un punto negativo en la privacidad del usuario, en ámbitos empresariales puede justificarse la recolección de esta información, siempre desde el punto de vista de maximizar la seguridad para el usuario.

Si ponemos la sonda en esta posición, tenemos que las consultas recursivas que realicen los servidores DNS corporativos también se guardan en memoria y, si la herramienta utilizada tiene caché, es posible que perdamos información sobre las peticiones realizadas por un cliente determinado.

Por ello, puede ser interesante mover la posición de la sonda a una ubicación donde únicamente tengamos las peticiones que realizan los clientes a los DNS corporativos, eliminando las consultas recursivas de los últimos hacia Internet. Así, la infraestructura quedaría como sigue:

Finalmente, si no disponemos de servidores DNS corporativos, la instalación es más sencilla, ya que podemos ubicar la sonda en cualquier punto en el que se capture todo el tráfico DNS de nuestros clientes internos:

Dejamos para entradas siguientes la instalación, configuración y optimización de la instalación.