Cloudflare ha ampliado las capacidades de su firewall de aplicaciones web (WAF) con dos funciones nuevas: detecciones de transacción completa y reglas de respuesta. Estas funciones permiten evaluar una petición HTTP junto con la respuesta del origen para detectar pruebas de explotación, fugas de datos o configuraciones riesgosas que la inspección solo de peticiones podría pasar por alto.
Qué cambia con la detección por transacción completa
Hasta ahora, el WAF se centraba principalmente en analizar las peticiones entrantes para bloquear ataques conocidos antes de que llegaran al servidor. La detección por transacción completa añade el contexto de la respuesta devuelta por el origen: combina señales del input sospechoso con características de la respuesta (por ejemplo, fragmentos que indiquen ficheros de configuración, texto sensible o respuestas que confirmen ejecución de código) para inferir si un intento fue exitoso.
Esto reduce la ambigüedad de ciertas firmas que, por sí solas, generan muchos falsos positivos. Un mismo payload puede ser benigno en un caso y explotador en otro; la correlación con la respuesta permite distinguir entre una exploración que no tuvo efecto y una que sí expuso datos o ejecutó comandos.
A quién afecta y qué deben hacer los administradores
- Administradores de servidores, responsables de seguridad y propietarios de sitios verán más contexto en los eventos del WAF: detecciones que indican no solo un intento, sino evidencia del resultado.
- Las detecciones aparecen en Security Analytics para facilitar la investigación; los equipos pueden revisar primero sin bloquear y luego diseñar reglas de respuesta específicas.
- Si usan las reglas gestionadas de Cloudflare, recibirán protecciones que ya combinan petición y respuesta, incluidas reglas que abordan vulnerabilidades de alto perfil citadas por Cloudflare.
Prácticamente, los administradores deben revisar las nuevas detecciones en su panel de seguridad, ajustar el alcance (por ejemplo, restringir inspección a rutas concretas) y, si procede, crear reglas personalizadas que actúen en función de los campos de detección correlacionados.
Reglas de respuesta: bloquear la respuesta antes de que llegue al atacante
Las reglas de respuesta permiten reemplazar la respuesta del origen por una página de bloqueo del WAF (o una respuesta personalizada) antes de que el requester la reciba. Esto no deshace acciones ya ejecutadas en el servidor, pero impide que un atacante obtenga información sensible que confirme o facilite la explotación.
En la práctica, un flujo típico sería: una detección correlaciona una petición de path traversal con una respuesta que contiene indicios de un fichero de configuración; una regla de respuesta entra en acción y devuelve un bloque 403 en lugar de la respuesta real.
Disponibilidad y gestión
Cloudflare ha declarado que las nuevas capacidades están disponibles para todos los clientes, incluidos los planes gratuitos. Las controles de fase de respuesta aparecen en el panel bajo Security > Security Rules. Las protecciones gestionadas vienen en un conjunto predeterminado (Managed Response Firewall Default) pensado para desplegarse con un solo clic; los clientes de pago pueden además usar los campos de detección en reglas más específicas.
Impacto y límites
La detección por transacción completa amplía la visibilidad frente a técnicas modernas de descubrimiento de vulnerabilidades (incluidos agentes automatizados que adaptan payloads con retroalimentación). Es particularmente útil contra vulnerabilidades que requieren confirmar un efecto en la respuesta para demostrar explotación o exfiltración.
Sin embargo, la función no puede revertir cambios ya realizados en el origen ni impedir operaciones que ya ejecutaron side effects; su valor está en prevenir que información sensible llegue al atacante y en facilitar la identificación de fallos reales para su corrección.
En resumen, los administradores deben revisar las nuevas detecciones en Security Analytics, ajustar el alcance de la inspección a sus aplicaciones y considerar el uso de reglas de respuesta para bloquear respuestas que confirmen explotación o exposición de datos.
Lee también:
- Exploit público precede a parche crítico de PHP; proveedores y WordPress responden ajustando configuraciones
- ISPConfig publica un parche temporal para mitigar PHP2Shell en servidores web
Fuente: Cloudflare Blog
