WAF

El WAF de ExyonQ es un motor nativo en Rust, integrado en el proceso exyonq serve. Inspecciona ruta, query, cabeceras y cuerpo con detectores de firma y añade una puerta de abuso por IP. No es un complemento externo ni depende de Pingora.

Modos

waf.mode decide qué se hace con una firma que coincide:

La puerta de abuso es independiente del modo de firma: con mode = "monitor" y [waf.abuse] mode = "rate_limit" se siguen devolviendo 429. Un reto superado nunca anula un bloqueo de firma.

[waf]

Reglas incluidas

Los bots legítimos conocidos se perdonan: googlebot, bingbot, slurp, duckduckbot, facebookexternalhit, twitterbot. Antes de comparar se normaliza la URL (incluida la doble codificación) y el cuerpo se lee como UTF-8 con pérdida, de modo que un cuerpo binario no se salta en silencio.

Activación por detector

[waf.ruleset.builtins] ajusta familia por familia. Si ningún ruleset suministra builtins, se usa el paquete por defecto: SQL, XSS, path y comandos en block; cabeceras y bot en log.

[waf]
enabled = true
mode = "block"
engine = "native"
max_inspection_body_bytes = 1048576
on_inspection_limit = "log_and_allow"
fail_policy = "closed_for_invalid_rules"

[[waf.ruleset]]
id = "exyonq-core"
enabled = true

[waf.ruleset.builtins]
sql_injection = "block"
xss = "block"
path_traversal = "block"
command_injection = "block"
header_anomaly = "log"
bot_ua = "block"

Exclusiones

Una exclusión calla reglas concretas, no apaga el WAF. Es la herramienta para casos como el editor de bloques de WordPress, que envía HTML y Markdown en el cuerpo de un POST y dispararía XSS o CMD sobre contenido legítimo.

[[waf.exclusion]]
host = "blog.exyonq.org"
path_prefix = "/wp-admin"
method = "POST"
rule_ids = ["EXY-SQL-1001", "EXY-XSS-1001", "EXY-CMD-1001"]

rule_ids vacío no significa «todas las reglas». En configuración se rechaza; en tiempo de ejecución una lista vacía no coincide con nada. Una exclusión nunca es un bypass genérico.

Límite de inspección

El cuerpo se inspecciona hasta max_inspection_body_bytes (1 MiB por defecto). Al agotarse el presupuesto, on_inspection_limit decide:

La truncación se registra: nunca se reporta como «inspeccionado completo».

fail_policy

Solo existe closed_for_invalid_rules. Si el WAF está habilitado y la compilación del snapshot falla (regla inválida, regex roto, configuración incoherente), el arranque o la recarga fallan cerrados y no se publica una generación sin protección.

Abuso y rate limit

[waf.abuse] es una tabla única (singleton), no una lista: una sola política por proceso, indexada por IP.

[waf.abuse]
mode = "rate_limit"
requests_per_second = 20
burst = 40

Con rate_limit, una petición denegada devuelve 429 con Retry-After en segundos (mínimo 1). Con challenge, el host devuelve 403 con una prueba de trabajo HMAC-SHA256 y cookie de concesión (exyonq_waf_grant, TTL 300 s); la verificación es un POST /.exyonq/waf-challenge, que sigue pasando por las firmas.

Snapshot fijo por generación

Las reglas se compilan a un snapshot inmutable. Al arrancar se compila el snapshot de la generación 1; cada recarga compila un candidato en la fase de preparación y solo lo intercambia si la publicación sale bien. Un fallo de compilación deja vivo el snapshot anterior, y las peticiones en vuelo conservan el suyo.

Las variables de entorno mandan sobre el IR cuando están definidas: EXYONQ_WAF_MODE, EXYONQ_WAF_ENFORCE (solo con mode = "block"), EXYONQ_WAF_ABUSE, EXYONQ_WAF_ABUSE_RPS, EXYONQ_WAF_ABUSE_BURST y EXYONQ_WAF_CHALLENGE_KEY_FILE (32 bytes exactos). Un valor desconocido en EXYONQ_WAF_ABUSE falla cerrado.

Verificar con curl

Con mode = "block", estas peticiones se rechazan con 403 (comprobado en un despliegue real con la configuración de ejemplo):

curl -s -o /dev/null -w '%{http_code}\n' 'https://exyonq.dev/?q=1%20UNION%20SELECT%20password%20FROM%20users'
curl -s -o /dev/null -w '%{http_code}\n' 'https://exyonq.dev/?q=%3Cscript%3Ealert(1)%3C/script%3E'
curl -s -o /dev/null -w '%{http_code}\n' 'https://exyonq.dev/../../etc/passwd'
curl -s -o /dev/null -w '%{http_code}\n' -A 'sqlmap/1.7' 'https://exyonq.dev/'

Las cuatro devuelven 403 y el cuerpo blocked by waf. Una petición limpia devuelve 200. Si obtienes un 200 en una carga que debería bloquear, revisa el mode, el host de la petición y si hay una exclusión que cubra esa ruta y ese método.

Verificar en el journal

Cada coincidencia deja una línea warn con el objetivo exyonq_waf:

WARN exyonq_waf: waf violation phase=RequestHeaders rule_id=EXY-SQL-1001 action=Block truncated=false field=Some("query") enforce=true sql injection pattern

Campos útiles: phase (RequestHeaders, RequestBodyComplete…), rule_id, action, truncated, field (path, query, header:user-agent), enforce. La línea de acceso asociada lleva status=403 y outcome="forbidden".

journalctl -u exyonq-sites | grep 'waf violation' | tail -20
journalctl -u exyonq-sites | grep -c 'rule_id=EXY-BOT-1001'

Con [modules.metrics] habilitado, el WAF publica exyonq_waf_inspections_total, exyonq_waf_decisions_total y exyonq_waf_violations_total (por rule_id).

Límites conocidos

• No hay importación de ModSecurity CRS, ni motor de puntuación por anomalías, ni detectores de fase de respuesta.
• No hay proveedor externo de CAPTCHA.
• El abuso es una sola política global por proceso.
• Existen reglas personalizadas por ruleset ([[waf.ruleset.rule]] con pattern, target, action y phases), pero las acciones válidas son allow, log y block: challenge y rate_limit están reservadas a la puerta de abuso.