Anatomía de una regla de detección

Una regla empieza por su cabecera, siete campos en este orden: acción, protocolo, dirección de origen, puerto de origen, sentido, dirección de destino y puerto de destino. Después, entre paréntesis, van las opciones separadas por punto y coma.

El sentido -> significa que la regla mira el tráfico que va de lo que está a la izquierda hacia lo que está a la derecha; el sentido <> mira ambos. Las direcciones pueden ser literales o variables como $HOME_NET, que se definen en suricata.yaml.

El error de escritura más frecuente en una regla local no está en lo que busca sino en el sentido: se escribe el origen donde iba el destino. La regla compila, carga y nunca coincide, o coincide con el tráfico de respuesta, y nadie se entera porque «no hay alertas».

Consulta reglas_locales y las variables. Compara la intención escrita con el origen y el destino de la cabecera.

La opción classtype asigna a la alerta una clase —por ejemplo policy-violation— y, a través de ella, una prioridad por defecto. Sin clase, la alerta queda sin categoría y sin prioridad coherente, así que no se puede ordenar ni filtrar en el panel donde el analista la va a ver.

Revisa el texto completo de las cinco reglas.

Cada regla se identifica por su sid, que no cambia, y por su rev, que sube cada vez que alguien la modifica. Una rev alta en una regla local es una señal de que se ha retocado mucho —por falsos positivos, por cambios de direccionamiento o porque nadie definió bien su intención— y merece una lectura atenta.

La opción flow limita a qué paquetes se aplica la regla según el estado de la conexión y su sentido. established pide una conexión ya montada, y to_server pide el sentido del cliente hacia el servidor. Con ellas, la regla ignora los intentos que no llegaron a abrir conexión y el tráfico de respuesta, y evita coincidencias dobles.