Web Application Firewall (WAF)

El Web Application Firewall (WAF) filtra las solicitudes HTTP antes de que lleguen a tu servidor de origen. En Tero Services se compone de dos capas complementarias: una base de protección nativa siempre activa y un motor de reglas que vos definís.

Dos capas

Base nativa (siempre activa)

Una capa escrita de forma nativa valida cada solicitud contra abusos estructurales del protocolo, independientemente de si activás el motor de reglas o no. No requiere configuración: viene de fábrica y cubre, entre otros:

• Traversal de paths (../, codificaciones, normalización).
• Conformidad con los RFC de URI y HTTP (RFC 3986, 9110, 9112).
• Request smuggling (contrabando de solicitudes por Content-Length/Transfer-Encoding inconsistentes).
• Inyección de encabezados (caracteres de control, CRLF).
• Validación del Host (coherencia entre el Host y la ruta solicitada).

Motor de reglas (opcional)

Las expresiones que vos definís, evaluadas por solicitud. Es la capa que se activa o desactiva por ruta.

Qué hace el motor de reglas

Filtra solicitudes según expresiones legibles que evalúan path, encabezados, método, dirección IP, país, agente de usuario y sus combinaciones. La sintaxis es del estilo de Wireshark/Cloudflare, pensada para ser leída por personas, no para mantener expresiones regulares sueltas.

Cuándo usarlo

• Cerrar paneles administrativos a direcciones IP o países conocidos.
• Bloquear paths sensibles ante agentes de usuario sospechosos.
• Permitir bots legítimos (buscadores) y bloquear el resto.
• Mitigar un ataque específico mientras no haya un parche disponible (virtual patching).

Sintaxis (ejemplos)

# Bloquear acceso a /wp-admin desde fuera de Uruguay
http.path matches "^/wp-admin" and ip.geoip.country != "UY"

# Bloquear bots conocidos
http.user_agent contains "AhrefsBot"
  or http.user_agent contains "SemrushBot"

# Permitir solo POST a /api/webhook desde una IP conocida
http.path eq "/api/webhook" and (http.method != "POST" or ip.src != 203.0.113.10)

# Bloquear extensiones peligrosas
http.path matches "\\.(env|git|sql|bak)$"

Variables disponibles

Variable	Descripción
http.path	Path solicitado (/foo/bar)
http.method	GET, POST, etc.
http.user_agent	Valor del encabezado del agente de usuario
http.host	Nombre de dominio pedido
http.headers["X-Algo"]	Acceso por nombre de encabezado
ip.src	Dirección IP del visitante
ip.geoip.country	Código ISO-2 del país
http.query	Cadena de consulta completa

Operadores: eq, ne, matches (expresión regular), contains, in, and, or, not, y paréntesis para agrupar.

Cómo se configura

Se entregan las reglas al equipo de Host Admin. Cada regla queda asociada a un dominio. La aplicación de reglas no requiere reinicio.

Activación por ruta

El motor de reglas se activa o desactiva con esta precedencia (gana el primero definido):

1. Override de la ruta — la ruta fuerza el WAF encendido o apagado.
2. Valor por defecto del servicio — si la ruta no define nada, se usa el valor por defecto configurado por Host Admin.

La base nativa descrita arriba permanece activa en todos los casos, sin importar este toggle.

Modo “solo registro”

Antes de pasar una regla a bloqueo real, puede correrse en modo solo registro: cuenta como si hubiera bloqueado, pero deja pasar la solicitud. Sirve para validar el impacto de una regla nueva sin riesgo.

Limitaciones

• El motor de reglas se evalúa antes de llegar al servidor de origen y opera sobre path, encabezados y método. No inspecciona el cuerpo de la solicitud en esta etapa.
• No reemplaza la validación de entrada de tu aplicación; es una capa de defensa adicional.

Preguntas frecuentes

• ¿Hay un conjunto “OWASP” precargado? No por defecto. El motor de reglas está pensado para reglas explícitas, mantenibles y revisadas. Para defensas amplias contra bots, combinalo con CrowdSec.
• ¿Pueden traducir mis reglas de mod_security / nginx? Sí, al dar de alta el servicio. La mayoría se mapea directamente.
• ¿Los bloqueos se ven en métricas? Sí, hay un contador por regla y dominio.