Tu firewall perimetral funciona. Tu certificado SSL está vigente. Tu sitio carga rápido. Y aún así, los logs muestran cientos de peticiones diarias intentando inyectar SQL en el formulario de búsqueda, miles de intentos de login con credenciales de breaches anteriores, scrapers descargando tu catálogo y crawlers buscando paneles administrativos olvidados. Nada de eso lo bloquea un firewall tradicional, porque ocurre dentro de HTTP — el protocolo que tú mismo abriste a Internet.
El Web Application Firewall (WAF) existe exactamente para esa capa: la lógica de tu aplicación web. En esta guía explicamos qué hace un WAF moderno, qué amenazas debe cubrir, las fases por las que pasa una implementación bien hecha y cómo opera Cerberus WAF — el WAF propio de UpTech, desarrollado y operado en Chile.
Contenido
¿Qué es un WAF y en qué se diferencia de un firewall normal?
Un firewall de red tradicional —y también un NGFW— filtra tráfico a nivel de IP, puerto y, en el caso de NGFW, aplicación reconocida (Facebook, Zoom, BitTorrent). Pero para él, una petición HTTP es opaca: solo ve "tráfico TCP/443 hacia tu servidor" y decide pasar o no. No entiende qué hace esa petición.
Un WAF opera en la capa 7 (HTTP/HTTPS) y mira el contenido completo de cada request: el método, la URL, los parámetros, las cookies, los headers, el body. Con eso puede decidir, por ejemplo, que SELECT * FROM users WHERE id=1 OR 1=1 escondido en el parámetro id es una inyección SQL y bloquearla antes de que llegue a tu aplicación.
| Capa | Firewall tradicional | NGFW | WAF |
|---|---|---|---|
| Decisiones por IP/puerto | ✅ | ✅ | Parcial |
| Identificación de aplicación | — | ✅ | — |
| Inspección de payload HTTP | — | Limitada | ✅ Profunda |
| OWASP Top 10 | — | Firmas básicas | ✅ Cobertura completa |
| Bot mitigation | — | — | ✅ |
| Rate-limit por endpoint | — | — | ✅ |
| Validación de schema API | — | — | ✅ |
Las amenazas que un WAF debe bloquear
El catálogo no es teórico — son los ataques que cualquier sitio público recibe a diario, con o sin tráfico real. Estos son los seis vectores que cubre Cerberus WAF y que cualquier WAF moderno debe atender:
1. OWASP Top 10
El estándar de facto de las vulnerabilidades web. Incluye SQL injection, Cross-Site Scripting (XSS), Server-Side Request Forgery (SSRF), deserialización insegura, XML External Entity (XXE), broken access control, identificación y autenticación rotas, fallas criptográficas, registro insuficiente y vulnerabilidades de componentes. Un WAF managed actualiza estas reglas continuamente — tú no tienes que escribir ni mantener firmas.
2. Bots maliciosos y scrapers
El tráfico bot representa entre el 30 % y el 50 % del tráfico de Internet, y no todo es malo (Googlebot, Bingbot, monitoring legítimo). El WAF distingue: allowlist a los buenos, fingerprinting a los malos (scrapers de catálogo, vulnerability scanners tipo Nuclei o Burp, crawlers no declarados). Sin esto, tu base de datos de productos termina replicada en sitios competidores.
3. Credential stuffing y abuso de login
Los atacantes prueban listas de credenciales filtradas en breaches públicos contra tu endpoint de login. Un WAF aplica rate-limit por IP, ASN y huella de cliente, detecta patrones de automatización y obliga MFA o CAPTCHA cuando el tráfico se vuelve sospechoso. Combinado con MFA, el ataque deja de ser viable.
4. Abuso de APIs
Las APIs son el blanco preferido de 2026: BOLA/IDOR (acceso a recursos ajenos por enumeración), validación de schema rota, y rate-limit ausente. Un WAF moderno valida cada request contra el schema declarado (OpenAPI/GraphQL), aplica cuotas por endpoint y detecta enumeración en serie de IDs.
5. DDoS de capa 7
Los ataques volumétricos L3/L4 (SYN flood, UDP amplification) los mitiga el datacenter upstream. Pero el HTTP flood, slowloris o cache-busting parecen tráfico legítimo y solo el WAF los puede contener: detecta patrones de comportamiento, exige challenges JavaScript a clientes sospechosos y absorbe la ola en el borde sin saturar tu origen.
6. Geo-blocking y reputación
Bloqueo por país o ASN cuando tu negocio no opera fuera de Chile, listas negras de IP en tiempo real (TOR exit nodes, redes residenciales abusadas, IPs reportadas en feeds de threat intel) y reglas custom específicas de tu vertical.
Las 5 fases de una implementación WAF bien hecha
Activar un WAF en producción y poner todas las reglas en modo block el primer día es el camino directo a romper tu propio sitio. Una implementación profesional pasa por fases:
Fase 1 — Descubrimiento y baseline
Antes de bloquear nada, el WAF observa. Aprende los endpoints reales de tu aplicación, los métodos válidos por cada ruta, los parámetros esperados, los user-agents legítimos, los rangos de IP de tus integraciones B2B. Esta foto es la línea base contra la que se medirán las anomalías.
En Cerberus esta fase dura típicamente entre 5 y 14 días, según el volumen de tráfico. Para sitios con tráfico bajo, complementamos con tráfico sintético desde nuestros nodos de monitoreo.
Fase 2 — Modo monitor (detection only)
Las reglas se activan, pero solo registran lo que habrían bloqueado. Es la fase de calibración: revisamos los falsos positivos, ajustamos exclusiones para tus rutas legítimas (carga de archivos grandes, endpoints con HTML rico, integraciones que envían payloads atípicos) y validamos que no haya tráfico legítimo cayendo en el set managed.
Fase 3 — Bloqueo gradual
Las reglas se mueven a modo block por categoría, no todas a la vez. Primero las firmas de explotación con cero falsos positivos (SQL injection clásica, XSS reflejada, lectura de archivos sensibles tipo /etc/passwd). Luego bot mitigation con challenge JavaScript. Después rate-limit en login y endpoints sensibles. Por último, las reglas con mayor riesgo de FP (anomaly scoring, validación estricta de schema) — y solo después de revisar logs.
Fase 4 — Reglas custom
El set managed protege contra amenazas genéricas. Pero cada aplicación tiene rutas críticas: el endpoint de transferencia bancaria, el formulario de registro, el upload de documentos, la API de pedidos. Aquí se escriben reglas específicas para tu app: cuotas por usuario en endpoints sensibles, validación de parámetros con regex, detección de patrones de fraude propios de tu negocio.
En Cerberus, este trabajo lo hace nuestro equipo de seguridad junto con el cliente. No es algo que escriben ustedes en YAML a las 3 AM.
Fase 5 — Operación continua
Un WAF no es "fire and forget". Cada semana aparecen nuevos CVE, nuevas técnicas de evasión, nuevas botnets. La operación continua incluye: actualización de reglas managed, revisión de tráfico bloqueado para detectar nuevos patrones, ajuste de umbrales de anomaly scoring, respuesta a incidentes cuando aparece un ataque dirigido.
Para los clientes de Cerberus, esto está incluido en el servicio — no es módulo aparte ni licencia premium. El monitoreo proactivo de UpTech alimenta directamente al WAF con señales adicionales.
Modos de despliegue: proxy, inline o agente
Hay tres formas razonables de poner un WAF delante de una aplicación. Cerberus soporta las dos primeras nativamente; la tercera depende del stack:
Proxy gestionado (DNS-based)
El más rápido de activar. Apuntas tu DNS al WAF y el WAF hace reverse proxy hacia tu origen actual, donde sea que esté. SSL puede terminarse en el WAF (recomendado, permite inspección) o pasarse en passthrough. Activación en horas: cambias un registro A o CNAME y propagas.
Ventaja: funciona con cualquier hosting o cloud. Desventaja: tu origen sigue siendo alcanzable directo por IP si alguien la descubre — por eso se restringe el firewall del origen para aceptar solo desde los rangos del WAF.
Inline en hosting/cloud UpTech
Si tu sitio ya está alojado en la plataforma de UpTech, Cerberus corre integrado: no hay salto de red adicional, el origen no es alcanzable desde fuera y la latencia es la mínima posible. Es el modo recomendado para clientes que migran su web a UpTech.
Agente en el servidor (alternativa)
Algunos WAFs ofrecen agentes que corren como módulo del web server (mod_security, plugins de Nginx). Útil cuando no se puede tocar el DNS, pero pierdes la protección de borde: el atacante ya consumió ancho de banda y CPU del servidor antes del bloqueo. No es el modo de Cerberus por diseño.
Cerberus WAF: el enfoque de UpTech
Cerberus es nuestro WAF propio, desarrollado y operado por UpTech en Chile. No es reventa de un producto extranjero ni un contrato con un proveedor que opera tu tráfico desde otro país. Estas son las características concretas que hoy ofrece — todas documentadas en la página del producto:
- Reglas managed: OWASP Top 10, bot mitigation, credential stuffing, abuso de APIs, DDoS L7, geo-blocking. Mantenidas y actualizadas por el equipo de seguridad de UpTech, no por ti.
- Reglas custom por cliente: definimos protecciones específicas para tu aplicación (rutas sensibles, parámetros vulnerables, lógica de negocio).
- Despliegue en horas: modo proxy gestionado vía DNS o inline en la plataforma de UpTech. Activación en el día, no en semanas.
- Dashboard en tiempo real: tráfico permitido/bloqueado, top IPs, top reglas disparadas, geografía, latencia — accesible desde tu Portal Cliente.
- Soporte 24/7 en Chile: cuando algo se bloquea por error o ves un patrón raro, hablas con un ingeniero local — no con un chatbot de un proveedor extranjero.
- Logs y auditoría: retención configurable, exportación a tu SIEM si la necesitas para compliance (ISO 27001, PCI-DSS).
- Soberanía de datos: tu tráfico se procesa en Chile, no se envía a regiones de proveedores cloud extranjeros.
¿Cerberus es para tu sitio?
Lo desplegamos por defecto en cada cliente con presencia web crítica. Si tienes formularios públicos, login, APIs expuestas o un e-commerce, conversemos qué necesita tu aplicación.
Ver Cerberus WAF →Errores comunes al implementar un WAF
1. Activar todo en modo block el primer día
Es la receta para bloquear tráfico legítimo y aprender malo: ahora tu equipo desactiva reglas en pánico y queda peor que antes. Siempre hay fase de monitor y bloqueo gradual.
2. No proteger el origen
Si pones un WAF en proxy pero tu IP de origen sigue siendo alcanzable directo, el atacante simplemente la encuentra (Censys, Shodan, headers filtrados) y bypasea todo el WAF. Hay que restringir el firewall del origen para aceptar solo desde los rangos del WAF.
3. Olvidar la inspección de uploads
Subir un PHP disfrazado de imagen es uno de los vectores más viejos del libro. El WAF debe inspeccionar el contenido real del archivo (magic bytes), no solo el header Content-Type.
4. No revisar logs
Un WAF que bloquea pero nadie lee es un WAF parcial. Los patrones que se repiten te dicen quién te está atacando, qué busca y cómo prepararte. Integrar logs con tu SIEM o, mínimo, revisar el dashboard semanal es parte del trabajo.
5. Confiar solo en el WAF
El WAF es defensa en profundidad, no la única capa. Necesitas también código sin vulnerabilidades, parches al día, MFA, segmentación, backup, monitoreo. El WAF compra tiempo y bloquea lo automatizado, pero un atacante dirigido necesita varias capas para detenerse.
Preguntas frecuentes
¿Qué es un WAF y en qué se diferencia de un firewall normal?
Un Web Application Firewall opera en capa 7 (HTTP/HTTPS) e inspecciona el contenido de las peticiones web — payloads, cabeceras, cookies, parámetros — para bloquear ataques como SQL injection, XSS o credential stuffing. Un firewall de red tradicional o NGFW filtra a nivel de IP, puerto y aplicación, pero no entiende la lógica de tu aplicación web.
¿Necesito un WAF si ya tengo HTTPS y un buen NGFW?
Sí. HTTPS cifra el canal pero no valida el contenido: una inyección SQL viaja perfectamente por TLS. Un NGFW puede tener algunas firmas web, pero no cubre OWASP Top 10 con la profundidad de un WAF dedicado, ni mitiga bots, ni hace rate-limit de APIs ni reglas custom por endpoint.
¿Un WAF añade latencia perceptible?
Bien dimensionado, agrega entre 5 y 30 ms al tiempo de respuesta del origen. La mayoría de los visitantes no lo nota, y cuando el WAF está cerca del usuario (anycast o región Chile en el caso de Cerberus) la latencia neta puede incluso bajar gracias a TLS terminado en el borde.
¿Cómo se activa Cerberus WAF en mi sitio?
Hay dos modos: proxy gestionado (apuntas tu DNS al WAF y nosotros hacemos reverse proxy hacia tu origen) o inline si tu sitio ya está en hosting/cloud de UpTech. La activación toma horas, no semanas.
¿Puedo definir reglas personalizadas para mi aplicación?
Sí. Además del set managed por nuestro equipo de seguridad, definimos reglas custom para tu app: rutas sensibles, parámetros vulnerables, cuotas por endpoint, lógica de negocio específica.
¿El WAF reemplaza a un buen pentest o auditoría de código?
No. El WAF mitiga la explotación pero no corrige la causa raíz. La práctica correcta es pentest + corrección + WAF como capa adicional. Si encuentras un SQL injection en producción, no basta con bloquearla en el WAF — hay que parchar el código.