Supresión, umbrales y afinado

En el archivo de umbrales (threshold.config, indicado en suricata.yaml con threshold-file) una línea suppress tiene esta forma: suppress gen_id 1, sig_id <sid>, track by_src, ip <dirección>. La supresión actúa en el momento de emitir la alerta: la regla se sigue evaluando, y lo que haga al coincidir, como activar un flowbit que usan otras reglas, se sigue haciendo. Lo único que desaparece es la alerta.

Deshabilitar la regla, en cambio, la saca del conjunto cargado: ni se evalúa ni deja efectos.

Afinar empieza por medir: qué reglas generan más alertas y cuántas de esas alertas fueron confirmadas por alguien. Una regla con miles de alertas y cero confirmadas es candidata a afinar; una con decenas de alertas y varias confirmadas es candidata a que alguien la mire hoy.

Consulta alertas_7d y compara el volumen con las confirmaciones.

Una supresión bien hecha dice a quién calla: un origen o un destino concretos, con un dueño y una fecha en la que se revisa. La línea suppress gen_id 1, sig_id <sid> sin track ni ip calla la regla para cualquier origen y destino, y lo hace sin que quede quién la pidió ni cuándo vence.

Consulta threshold_config.

Cuando una regla alerta mucho por un equipo autorizado —por ejemplo, el escáner de vulnerabilidades de TI en su ventana—, la medida es suprimir solo ese origen. Lo que queda es el volumen real de la regla para el resto de la red, y ese número es el que decide si la regla sigue siendo ruidosa o ya es útil.

Consulta alertas_por_origen y el inventario para identificar al escáner. Para el sid 5100061, resta las alertas del escáner del total de la semana.

Los umbrales ofrecen otra salida cuando el ruido viene de un origen que sí se quiere conocer: threshold ... type limit, track by_src, count 1, seconds 3600 deja pasar la primera alerta de cada origen y descarta las siguientes durante una hora. El analista sigue sabiendo que ese origen disparó la regla, pero no recibe diez mil líneas iguales.