Dónde va el sensor y lo que no ve

Un sensor puesto delante del cortafuegos ve todo lo que llega de internet, incluido lo que el cortafuegos va a bloquear de todas formas: es una fuente enorme de ruido y de volumen, útil para saber qué intentan, poco útil para decidir qué hacer esta mañana. Uno puesto detrás ve solo lo que el cortafuegos dejó pasar: menos tráfico, menos ruido, y cada alerta se parece más a algo que sí llegó a un servidor.

Ninguno es el correcto; son preguntas distintas. Delante responde «¿qué nos intenta alcanzar?»; detrás responde «¿qué consiguió pasar?». Y un sensor en el interior, entre segmentos, ve lo único que ninguno de esos dos puede ver: lo que se dicen los equipos de dentro entre sí.

La pregunta más útil al heredar un SOC es qué segmentos de la red no tienen sensor, porque ahí no hay alertas y es fácil confundirlo con calma. Se responde con un mapa: segmento, rango de direcciones y el sensor que lo ve, o ninguno. La tabla topologia es ese mapa en Molinos del Sinú.

Ejecuta SELECT * FROM topologia y busca el segmento cuyo sensor es «(ninguno)». Es un segmento donde cualquier cosa puede pasar sin que una sola regla la vea.

El sensor guarda sus propias estadísticas. Dos números cuentan aquí: kernel_packets, los paquetes que el sistema entregó al motor, y kernel_drops, los que tuvo que tirar porque el motor no daba abasto. Un paquete tirado es un paquete que ninguna regla vio: si dentro iba lo que una regla buscaba, no habrá alerta, y nadie sabrá que debía haberla.

El porcentaje de descarte es kernel_drops entre kernel_packets, por cien. Lo ideal es que se acerque a cero, y una cifra de dos dígitos significa que el sensor tiene huecos grandes en su vista.

Un sensor que descarta uno de cada cuatro paquetes sigue escribiendo alertas, y en la consola todo se ve normal: la cola llega, las reglas disparan. Lo que cambia es lo que no llega. Un día sin alertas de un sensor así no es un día sin ataques: es un día en que el sensor vio solo una parte del tráfico, y esa parte puede no incluir lo que importaba.

Por eso las estadísticas del sensor se miran con el mismo cuidado que sus alertas, y por eso se escalan a quien mantiene el sensor, no al SOC: la causa suele ser capacidad —un enlace que creció, un puerto espejo que ya no cabe— y la corrección es de ingeniería de red.

Una regla que busca una cadena dentro de una petición necesita leer la petición. Si la conexión va cifrada, el sensor ve el saludo inicial —con datos como el nombre del servidor al que se conecta— y el resto son bytes ilegibles: la regla no coincide, no porque no haya nada, sino porque no puede leer. Y no se queja ni escribe un aviso. Por eso, cuanto más tráfico va cifrado, menos pueden ver las reglas de contenido, y más pesan el nombre del servidor, el volumen y las reglas de comportamiento.

La tabla cifrado mide qué parte de cada segmento va cifrada. La DMZ es donde están los portales, y es el segmento donde las reglas de petición web tienen que hacer su trabajo.