La baliza, medida con una consulta

Ninguna conexión de una baliza, sola, llama la atención: es corta, va cifrada, usa el puerto de siempre. Lo que la delata es el conjunto: muchas conexiones al mismo destino, separadas por intervalos parecidos, con envíos del mismo tamaño —la misma pregunta una y otra vez— y desde un equipo que es el único de la empresa que habla con ese destino.

Cada una de esas cuatro señales tiene su falso positivo. La telemetría del antivirus es regular, pero la mandan todos los puestos. Un sensor de temperatura llama cada minuto exacto, pero alguien lo aprobó y está anotado. Una persona que vuelve a la misma web no llama a intervalos parecidos. Es la combinación lo que describe una baliza.

Mirar filas sueltas no sirve: en un día hay decenas de miles de conexiones. Hay que agrupar por par —este equipo con este destino— y medir. La tabla intervalos ya trae, para cada conexión, los segundos desde la anterior del mismo par (en el SIEM se calcula con una función de ventana que mira la fila previa). Con eso, la medición es una consulta:

SELECT id_orig_h, id_resp_h, COUNT(*) AS conexiones,
       AVG(intervalo_s) AS media_s, STDDEV(intervalo_s) AS desviacion_s,
       AVG(orig_bytes) AS bytes_medios
FROM intervalos
GROUP BY id_orig_h, id_resp_h
HAVING COUNT(*) > 30

La media dice cada cuánto llama; la desviación, cuánto se aparta de esa media. Una persona da desviaciones más grandes que la propia media, porque navega a saltos. Un programa da una desviación pequeña frente a la media. Después, una segunda consulta cuenta cuántos equipos distintos hablan con cada destino, y la lista de excepciones quita lo que ya está explicado.

El intervalo de una baliza puede bailar, pero lo que envía suele ser idéntico en cada llamada: el programa manda siempre el mismo saludo —quién es, si sigue vivo— y espera. Por eso la columna de bytes enviados es una de las mejores pistas: en la navegación de una persona no hay dos peticiones iguales; en una baliza, todas pesan lo mismo al byte.

Mira también la columna de lo que recibe. Casi siempre es la misma respuesta corta, «nada nuevo». Si un día la respuesta crece de golpe, es que el servidor tenía algo para ese equipo, y esa hora va directa a la línea de tiempo del caso.

Muchas reglas de canal de mando se escriben pensando en el reloj perfecto: «el mismo intervalo, una y otra vez». Las balizas de verdad añaden un margen al azar —el jitter— precisamente para escapar de esa regla. Un programa configurado para llamar cada 300 segundos con un 15 % de jitter llamará a los 268, a los 334, a los 297… y su desviación ya no es cero.

La forma de medirlo sin que se escape es la desviación relativa: la desviación dividida entre la media. Por debajo de un umbral —un 20 o un 25 %, según lo que se ajuste con los datos de la casa— el par se comporta como un programa, aunque no sea un reloj exacto. Y como el sensor y el antivirus también caerán ahí, la regla se escribe con la rareza del destino y la lista de excepciones desde el primer día.

Una baliza medida es un hallazgo sólido: un equipo, un destino, un intervalo, un tamaño y una hora en la que el servidor contestó con algo. Falta lo de siempre para escalarlo: qué equipo es y de quién. Lo siguiente ya no es trabajo de red, es del agente del puesto: qué proceso abre esas conexiones.