Eventos y excepciones

Cada bloqueo y cada detección se convierten en un evento. Es por él que entiendes qué decidió el WAF y por qué — y de él sale la excepción, el ajuste puntual para un falso positivo.

Eventos

Un evento registra una solicitud que el WAF bloqueó o detectó. Una solicitud puede listar más de una regla en el mismo evento.

Campo	Qué muestra
Fecha y hora	Cuándo llegó la solicitud
Dominio	Qué hostname la recibió
IP del cliente	Dirección de origen
Método	GET, POST y los demás métodos
Ruta	La ruta, sin la query string
Categoría	La familia de ataque evaluada
Regla	El identificador de la regla que coincidió
Acción	Bloqueada, detectada o limitada
Modo	Detección o prevención en ese momento
Puntuación de anomalía	La suma que alcanzó la solicitud
Identificador de la solicitud	El mismo que el usuario final puede informar
Revisión de la política	Qué configuración decidió
Versión del conjunto	Qué versión del conjunto OWASP estaba aplicada

El evento no guarda contenido sensible: Authorization, cookies, cuerpos, query strings y tokens quedan fuera. Lo que ves es suficiente para decidir, sin convertirse en un archivo de credenciales.

La retención de eventos es de 30 días. Las métricas agregadas se guardan 12 meses.

Interpretar eventos

Para leer un bloqueo, sigue este orden:

1. Qué regla coincidió. El identificador de la regla OWASP dice qué se reconoció. Las reglas del rango 942 son inyección de SQL, 941 es XSS, 930 es LFI, 932 es inyección de comando.
2. Qué ruta. El mismo parámetro puede ser legítimo en /api/search y no en /login.
3. Modo y puntuación. En prevención, la puntuación muestra cuánto superó el límite la solicitud. En detección, muestra qué habría pasado.
4. Si había una regla personalizada. Si una regla tuya bloqueó, el evento apunta a tu regla y no al conjunto OWASP.

Un ejemplo de lectura: un POST en /api/search bloqueado por la regla 942100 (inyección de SQL) en prevención, con puntuación 5 y ninguna regla personalizada en la ruta. La conclusión es que el conjunto OWASP vio un payload parecido a SQL en el cuerpo o en los parámetros. Si el formulario es de búsqueda libre, el siguiente paso es repetir la misma consulta y mirar el evento generado.

Métricas

Las métricas muestran solicitudes permitidas, bloqueadas y limitadas, y el volumen de tráfico, por dominio. Son agregadas: pueden llegar con algunos minutos de retraso respecto al evento.

Métrica	Uso
Solicitudes permitidas	Confirmar que el tráfico normal pasa
Solicitudes bloqueadas	Medir ataque y medir el efecto de un cambio de política
Solicitudes limitadas	Calibrar la limitación de tasa
Tráfico	Capacidad y tendencia por dominio

Una métrica retrasada no es una métrica equivocada. Para decidir sobre un bloqueo específico, usa el evento, que es puntual.

Falsos positivos

Un falso positivo es tráfico legítimo detenido por una regla que reconoció un ataque. Las señales son reconocibles:

• el cliente relata un error intermitente en un formulario específico;
• el evento apunta a la misma regla y la misma ruta, con el mismo parámetro;
• el contenido es texto libre, documentación o un campo que acepta marcado;
• el bloqueo empezó después de un cambio de paranoia o de versión del conjunto.

Antes de crear una excepción, confirma que la solicitud es realmente legítima. Una excepción es una puerta abierta estrecha, pero es una puerta: esa regla deja de evaluarse en esa ruta.

Excepciones

La excepción se crea desde el evento bloqueado, con el botón Crear excepción. Tiene alcance estrecho por diseño:

Campo	Opciones
Regla ignorada	Una única regla OWASP, por identificador
Ruta	Exacta o por prefijo
Métodos	Opcional, para restringir a algunos métodos
Dominio	Un dominio
Parámetro	Opcional, un ARGS, cookie o cabecera por nombre
Justificación	Obligatoria
Validez	Opcional, con caducidad

Ejemplo: ignorar la regla 942100 solo en /api/search, con la justificación "campo de búsqueda libre con comillas" y validez de 90 días.

Reglas de uso:

• Nunca desactives una categoría completa. Si la familia 942 molesta en una ruta, la excepción es para la regla y la ruta, no para la familia.
• Prefiere el alcance más pequeño que resuelve. Regla y ruta antes que regla y dominio; ruta exacta antes que prefijo.
• Pon caducidad cuando la causa sea temporal. Una excepción con validez vuelve a evaluar por sí sola.
• Toda excepción es auditada. Quién la creó, cuándo, con qué justificación — y lo mismo vale para la eliminación.

Una exención de cuerpo no es una excepción de regla. Cuando el problema es el tamaño del cuerpo en un endpoint de carga, el ajuste es la exención de inspección de cuerpo en la política del dominio, y no una excepción de regla: la excepción ignora una regla OWASP en una ruta, mientras que la exención retira de la inspección solo el cuerpo de la solicitud.

Próximos pasos

• Políticas — nivel de paranoia que genera los falsos positivos.
• Solución de problemas — los códigos que ve el usuario final.
• Seguridad — auditoría y roles.