Reglas personalizadas

Las reglas personalizadas te dejan decidir sobre el tráfico con tu conocimiento de la aplicación, sin depender de las reglas genéricas del conjunto OWASP. No hay script, expresión ni expresión regular: cada regla es una condición elegida en una lista y una acción.

Reglas personalizadas

Una regla tiene tres partes:

Parte	Qué define
Condición	Qué debe tener la solicitud para coincidir
Acción	Qué hace el WAF cuando la condición coincide
Prioridad	El orden de evaluación entre tus reglas

Una misma regla puede combinar más de una condición. La regla solo coincide cuando todas las condiciones valen al mismo tiempo.

Condiciones

Condición	Cómo funciona	Ejemplo
IP	Compara la dirección del cliente con una dirección	203.0.113.10
CIDR	Compara la dirección del cliente con un rango, IPv4 o IPv6	203.0.113.0/24
COUNTRY	Compara el país del cliente; acepta varios países	BR, US
URL_PATH	Compara la ruta, exacta o por prefijo	/admin como prefijo
HTTP_METHOD	Compara el método de la solicitud	POST
HTTP_HEADER	Compara una cabecera, por igualdad, contenido o prefijo	X-Api-Version contiene 2.
USER_AGENT	Compara el agente del cliente, por igualdad, contenido o prefijo	curl como contenido

El país viene de la base DB-IP Lite, actualizada mensualmente. La atribución requerida es: IP geolocation by DB-IP, licencia CC BY 4.0. La geolocalización es una aproximación — no uses el país como único control de acceso para datos sensibles.

Algunas cabeceras no pueden usarse como condición, porque el WAF las necesita para enrutar y entregar la solicitud: Authorization, Cookie, Host y la familia X-Forwarded-*. Para tratar datos de autorización o sesión, usa el conjunto OWASP y una excepción puntual, no una regla personalizada.

Acciones

Acción	Código devuelto	Qué pasa
BLOCK	403	La solicitud se rechaza y se registra como evento
ALLOW	—	La evaluación de las reglas personalizadas siguientes se detiene para esa solicitud
MONITOR	—	La solicitud pasa y el caso se registra como evento
RATE_LIMIT	429	La solicitud entra en el límite de tasa definido en la regla

ALLOW es el punto que más confunde: detiene solo las reglas personalizadas siguientes. La inspección del conjunto OWASP y la limitación de tasa siguen valiendo para esa solicitud.

RATE_LIMIT en la regla sirve para limitar una ruta específica, además del límite general del dominio. El exceso recibe 429 y aparece en los eventos. Ver Limitación de tasa.

Orden de evaluación

controles de la plataforma → limitación de tasa → reglas personalizadas (por prioridad) → conjunto OWASP

1. Controles de la plataforma — la línea base de NNumbers, igual para todos.
2. Limitación de tasa — el límite del dominio y los límites por ruta.
3. Reglas personalizadas — en orden de prioridad: el número menor se evalúa antes.
4. Conjunto OWASP — la evaluación de anomalía que decide el bloqueo en prevención.

Si dos reglas tuyas coinciden con la misma solicitud, la de menor número decide. Por eso, deja las reglas de permiso con número bajo cuando necesitan vencer a las de bloqueo.

Ejemplos

Objetivo	Condición	Acción	Prioridad
Bloquear el acceso al panel administrativo fuera de Brasil	URL_PATH prefijo /admin y COUNTRY distinto de BR	BLOCK	10
Permitir un socio que usa una integración antigua en /api/legacy	IP igual a la dirección del socio y URL_PATH prefijo /api/legacy	ALLOW	20
Observar intentos de PUT en la API antes de bloquear	HTTP_METHOD PUT y URL_PATH prefijo /api	MONITOR	30
Limitar la descarga masiva	URL_PATH prefijo /export	RATE_LIMIT	40
Bloquear agentes de barrido conocidos	USER_AGENT contiene masscan	BLOCK	50

Una acción equivocada no se corrige en el conjunto OWASP

Si un ALLOW está dejando pasar algo que debería bloquearse, el ajuste es en la prioridad o en la condición de la regla — no en el nivel de paranoia.

Próximos pasos

• Limitación de tasa — límites por cliente y por ruta.
• Eventos y excepciones — confirmar el efecto de cada regla.
• Políticas — modo y nivel de paranoia que valen junto a las reglas.