Dos filtros, dos momentos

El filtro de captura se escribe antes de grabar. Usa la sintaxis de libpcap, la misma que entienden tcpdump y el propio analizador: palabras como host, port, net, unidas con and, or y not. Se aplica en el punto de escucha, mientras llegan las tramas, y sirve para guardar menos: menos disco, menos ruido, menos datos de personas que no hacen falta.

El filtro de visualización se escribe después, sobre un archivo que ya existe. Habla de campos que el analizador entiende de cada protocolo, con nombres con puntos, y solo oculta lo que no cumple. Quitarlo devuelve todo.

La asimetría es la clave: el de visualización se puede cambiar mil veces sin consecuencias; el de captura es una decisión que se toma una vez y no se deshace.

Una captura responde preguntas solo dentro de lo que cubre: el intervalo de tiempo y el filtro con el que se grabó. Antes de analizar, se leen esos dos datos de cada archivo, igual que se mira la fecha y el alcance de un registro antes de fiarse de él.

En el laboratorio tienes la tabla capturas con las cinco que dejó el sensor. Para cada una, la pregunta es doble: ¿cubre la franja? y ¿su filtro dejó pasar el protocolo que buscas? El DNS viaja por el puerto 53 y, además de las consultas, el archivo tiene que contener las respuestas del resolutor.

Escribir la misma expresión en el campo equivocado da error, y el error enseña. host 10.162.20.44 se entiende en el campo de captura porque es libpcap. ip.addr == 10.162.20.44 se entiende en la barra de visualización porque es un campo del analizador. Cada lenguaje tiene sus propios operadores: libpcap usa palabras, la visualización usa comparaciones y && o and.

La tabla expresiones guarda lo que respondió el analizador cuando alguien probó las mismas expresiones en cada campo. Léela antes de contestar.

Un filtro de visualización también sirve para medir. Con el archivo de la captura elegida abierto, la barra de estado dice cuántos paquetes cumplen la expresión frente al total. Eso es lo que se anota en un informe: no «hay muchos errores de DNS» sino una cifra con su filtro al lado, que otra persona pueda reproducir.

Una respuesta de DNS con código de respuesta distinto de cero indica que el resolutor no pudo darla: nombre que no existe, fallo del servidor, consulta rechazada. Es el primer filtro útil para ver qué intentó resolver un equipo y no encontró.

Mañana el sensor grabará dos horas del enlace de salida. El responsable de TI quiere ahorrar disco y propone un filtro de captura que deje solo el tráfico de un puesto que le preocupa. Tu trabajo no es decir que no, sino explicar qué se gana y qué se pierde, y proponer una alternativa que cuide la evidencia.

Grabar ancho y filtrar al mirar cuesta disco; grabar estrecho cuesta la posibilidad de contestar preguntas que todavía no se han hecho. Si el disco alcanza, la regla de prudencia es no descartar en el origen lo que podría explicar el caso.