No a los WAFs

Tu equipo de seguridad acaba de pintarte un panorama sombrío de posibles ciberamenazas y sabes que tu aplicación web es un campo minado de vulnerabilidades. Resolver estos problemas de seguridad parece una tarea que podría tomarte entre una eternidad y nunca.

WAF: no es lo que esperabas

¡Pero espera! Existe una solución: un Web Application Firewall, que detecta vulnerabilidades comunes como ataques de inyección y de Denegación de Servicio Distribuida (DDoS). Sin necesidad de programar. Basta con dirigir todo el tráfico web al WAF; este inspecciona todas las solicitudes HTTPS y bloquea las peligrosas.

Los WAFs funcionan inspeccionando todas las solicitudes HTTPS dirigidas a tu aplicación web y bloqueando las que parezcan peligrosas. Desencriptan las solicitudes HTTPS y revisan los headers y el body en busca de amenazas potenciales, para bloquearlas según el contenido, la dirección IP o los patrones de la solicitud.

Además, los WAFs ofrecen protección frente a ataques DDoS bloqueando picos repentinos de tráfico. Esto se logra con reglas simples, como la tasa de solicitudes y las direcciones IP de origen. Como alternativa, los WAFs pueden recurrir a la inteligencia artificial para detectar los patrones de acceso típicos de los ataques DDoS y bloquearlos.

No lo hagas.

El WAF es un error. Estas son algunas razones:

Bloquear tu propia aplicación

Los WAFs pueden impedir el acceso a usuarios legítimos al confundir la actividad normal con un ataque. De hecho, es muy probable que tu web-app reciba entradas con cadenas "sospechosas" que las expresiones regulares atraparán por error: por ejemplo, si tu app atiende a clientes técnicos, podrías tener fragmentos de JavaScript que parecen un ataque. Peor aún, tu app puede requerir entradas intrínsecamente peligrosas: por ejemplo, si acepta HTML de un componente de editor de texto enriquecido y lo renderiza directamente, entonces te puedo decir lo que ya sabes: que podrías y deberías escapar las cadenas, en lugar de andar pasando lo que equivale a un ataque. Pero erradicar esas debilidades, una vez creadas, es difícil, y hasta que puedas dedicar a tu equipo a esa tarea, el WAF dejará tu web-app inutilizable.

En cuanto a la protección DDoS, el WAF bloquea aumentos repentinos de tráfico, pero eso da pie al peor tipo de falso positivo: el que ocurre cuando tu app se vuelve viral y tus visitantes no pueden usarla. Por eso el filtrado avanzado del WAF, basado en machine learning (ML), puede ayudar. No es perfecto, pero sí mejor que los enfoques basados en patrones que usa la mayoría del filtrado WAF.

Bloquear direcciones IP individuales es, claramente, demasiado granular, así que el siguiente paso es bloquear países enteros, dejando fuera a todos los clientes de un país. Quizá hoy no atiendes clientes en ese país, pero con el WAF también te cierras la puerta a descubrir nuevos mercados potenciales.

El enfoque recomendado para lidiar con los falsos positivos es configurar el WAF en modo dry run, de manera que, en vez de bloquear, registre en un log las entradas sospechosas. Después analizas los logs para ver si hay falsos positivos y, si los hay, o aflojas las reglas (lo que podría dejar pasar algunos ataques reales) o corriges tu código (algo que llevas años postergando). He visto a organizaciones correr el WAF en dry run durante dos años por un miedo bastante justificado a romper la funcionalidad de su propia app. Así, ralentizaron su app, no obtuvieron ningún beneficio de seguridad y gastaron decenas de miles de dólares en licencias, sin conseguir jamás ningún beneficio en seguridad.

Dejar pasar ataques

La variedad de posibles ataques nuevos escapa a la imaginación de los diseñadores de WAFs y a la tuya; pero no a la de los hackers. Eso te deja con la cara opuesta del falso positivo: el falso negativo, ataques reales que pasan sin ser detectados.

Las expresiones regulares, la forma más común de filtrar texto, son limitadas en lo que pueden detectar. Deben definirse de antemano para ataques específicos y mantenerse simples para procesarse rápido. Por velocidad, solo se escanean los primeros kilobytes del header y el body HTTP; e incluso si elevas ese límite, siempre habrá un punto a partir del cual los ataques pasan sin filtrarse.

Bloquear direcciones IP también genera falsos negativos, ya que los atacantes pueden cambiar fácilmente a nuevas direcciones IP usando proxies.

La principal fuente de ataques contra los que el WAF no puede hacer nada está en la lógica de tu propia aplicación. Si una página debía estar protegida con contraseña y no lo está, o si la autorización permite a un usuario escribir datos cuando solo debería poder leer, la responsabilidad es tuya. Aunque nadie espera que los WAFs encuentren ese tipo de vulnerabilidades, esto refuerza que el lugar principal donde se debe implementar la seguridad web es en tu propio código.

¿Flexibilidad?

A medida que vas sorteando falsos positivos y negativos, resulta tentador ajustar las reglas y personalizarlas a la medida de tus necesidades, o incluso escribir las tuyas. No lo hagas.

Los expertos en seguridad ya investigaron los tipos de ataques que usan los hackers. Los hackers no van a inventar ataques especiales para ti, y si lo hacen, tampoco lo sabrás de antemano. Las vulnerabilidades de tu app son casi con seguridad las mismas que ya están cubiertas en los rulesets estándar. Si tu app realmente tiene debilidades tan particulares que necesitas diagnosticarlas y escribir nuevas reglas de protección, ese tiempo de desarrollo deberías invertirlo en mejorar la app misma, no en ponerle un parche.

Equilibrar precisión y recall —falsos negativos vs. falsos positivos— es difícil, casi imposible, incluso para los expertos. Por eso definen niveles de protección que te permiten elegir el trade-off entre falsos positivos y falsos negativos. Afinar ese equilibrio frente a millones de posibles solicitudes web futuras no vale la pena.

Riesgo añadido

Estos inconvenientes suelen hacer que los WAFs sean, en neto, negativos. Pero hay más: los propios WAFs pueden representar un riesgo de seguridad. Tienen que desencriptar HTTPS para inspeccionar los datos, lo que crea otro punto potencial de fuga; el propio código del WAF podría tener vulnerabilidades. Además, pueden ralentizar la comunicación, ya que cada solicitud pasa por ellos.

Con demasiada frecuencia, incluso conociendo todos estos hechos sobre el WAF, los managers deciden agregarlo de todas formas, como medida temporal, con la idea de corregir las vulnerabilidades de seguridad más adelante. Pero una vez que el WAF está en su lugar, el equipo se confía y nunca se adoptan las prácticas de seguridad adecuadas; el código de la aplicación se vuelve cada vez menos seguro. Mientras tanto, el WAF no está entregando la seguridad que se imagina.

A pesar de estos inconvenientes, hay situaciones en las que usar un WAF puede ser aconsejable, aunque tampoco obtendrás mucha seguridad con él:

Si tienes un requisito externo que lo exija; si la Request for Proposals de un cliente o las regulaciones de la industria te obligan a cumplir con un estándar de seguridad formal, entonces, por supuesto, agrégalo: el WAF es necesario, pero no por motivos de seguridad.

Si vas a desplegar una web-app de terceros, una que no desarrollaste tú y no puedes arreglar, un WAF puede ser tu única vía para sumar un poco de seguridad. Aun así, corres el riesgo de confiarte respecto a tu nivel real de seguridad, pero al menos en este caso no te estás alejando aún más del camino hacia las buenas prácticas de desarrollo.

Dicho esto, sí hay una buena razón de seguridad para usar un WAF: la protección frente a DDoS. Cuando un ataque de Denegación de Servicio envía tráfico masivo, tu WAF puede detectarlo y bloquearlo. La detección de patrones de ataque con ML ofrece buena precisión.

Para una protección DDoS más completa, contar con un equipo de expertos humanos listos para responder, como en Google Cloud Armor Managed Protection y AWS Shield Advanced, vale la pena para las web-apps más grandes.

Muchos clientes nos contactan e intentan contratar urgentemente servicios de protección DDoS —ya sea un WAF o un equipo de expertos— después de que el ataque ya empezó, cuando ya no hay tiempo; conviene tenerlo listo de antemano.

Si vas a usar un WAF, usa el que ofrece tu proveedor de nube: Google Cloud Armor o AWS Shield. Con los servicios en la nube pagas según consumo, en lugar de comprometerte a una cuota mensual costosa por un producto que quizá no uses. Además, como los datos ya fluyen por la nube y, en muchas arquitecturas, los servicios en la nube desencriptan tus datos de todas formas, usar un servicio WAF de tu proveedor de nube minimiza el impacto en rendimiento, seguridad y privacidad.

Consulta este artículo de Mac Chaffee y este hilo de StackExchange para encontrar detalles técnicos valiosos sobre estos puntos.