El ataque que no puedes detener en tu aplicación

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

En su aplicación se pueden (y se deben) prevenir una gran variedad de ataques basados en HTTP. El Top 10 de OWASP es un claro ejemplo de técnicas de ataque que pueden detectarse y prevenirse desde cualquier aplicación. Una gran variedad de herramientas, como los análisis estáticos y dinámicos y las pruebas de penetración, puede garantizar que estas vulnerabilidades no lleguen a producción. Siempre y cuando, por supuesto, estas pruebas de seguridad se desplacen a una fase más temprana del proceso de CI/CD en lugar de dejarlas como último paso antes de accionar el interruptor (o cambiar los bits, por así decirlo) que permite a los usuarios acceder a la aplicación.

Aunque hayas eliminado todas las posibles vulnerabilidades detectadas durante el desarrollo, las aplicaciones siguen estando en riesgo. Esto se debe a que algunos ataques no pueden —y cuando digo que no pueden, quiero decir que realmente no pueden— ser detectados por la aplicación. De hecho, cuando el ataque llega a la aplicación, ya es demasiado tarde.

Por supuesto, me refiero a los ataques DDoS en la capa de aplicación (HTTP). Ya sabes, esos ataques vampíricos que aprovechan el propio protocolo HTTP para absorber hasta la última gota de capacidad de procesamiento y memoria disponible de una aplicación, dejándola inutilizable para los usuarios legítimos.

Básicamente, hay dos tipos de ataques DDoS HTTP: los rápidos y los lentos; los que inundan y los que agotan los recursos.

El ataque por inundación

Un ataque DDoS HTTP basado en inundación aprovecha el hecho de que se espera que las aplicaciones acepten solicitudes HTTP y respondan a ellas. Al fin y al cabo, esa es su función, ¿no? Así que lo hacen, independientemente de la velocidad a la que lleguen las solicitudes. Aunque lleguen a un ritmo que agote en cuestión de minutos —o segundos— los recursos disponibles del servidor, este intenta responder. Toda aplicación (de hecho, todo dispositivo, servicio, sistema, etc.) tiene un límite máximo de conexiones TCP que puede mantener abiertas simultáneamente antes de no poder abrir ninguna más. Cuando alcanza ese límite, las solicitudes posteriores simplemente se ignoran. Los usuarios lo perciben mediante el inocuo estado «Intentando conectar…», mientras su navegador o aplicación espera a que transcurra el tiempo establecido por el sistema y, después, se disculpa por no haber podido establecer la conexión.

Este tipo de ataque puede producirse con tanta rapidez (de ahí la analogía con una «riada repentina») que supera la capacidad de los sistemas para escalar y satisfacer la demanda. Ni siquiera el escalado automático puede ayudar en este caso, ya que el tiempo necesario para aprovisionar y poner en marcha una nueva instancia de la aplicación es mayor que el que tarda el ataque en agotar todos los recursos de las instancias existentes.

El ataque de agotamiento

El ataque opuesto —un ataque de agotamiento— logra el mismo objetivo, pero lo hace obligando a la aplicación a mantener una conexión abierta durante más tiempo del necesario. Para ello, simula que utiliza una conexión telefónica y extrae de la aplicación apenas unas gotas de datos por segundo, en lugar de hacerlo a la velocidad a la que realmente es capaz de recibirlos. De este modo, las conexiones duran más y, si se hace con suficientes conexiones, se acaba básicamente en la misma situación que con el ataque de inundación: el agotamiento de los recursos.

Ninguno de estos ataques puede detectarse desde dentro de una aplicación. ¿Cómo iba a ser posible? Para la aplicación, todas estas solicitudes son legítimas: son solicitudes de datos bien formadas y basadas en HTTP, a las que probablemente responde miles de veces al día. No hay ningún indicador en las cabeceras HTTP ni en la carga útil que revele la naturaleza maliciosa de las solicitudes. La aplicación es total y absolutamente ajena a las intenciones maliciosas que se esconden tras ellas, ya que no tiene visibilidad de la red ni del entorno más amplio; en concreto, de la tabla de sesiones del servidor, que contiene la lista maestra de todas las conexiones abiertas. Le ahorraré los detalles técnicos y la explicación sobre hilos, procesos y volatilidad de los datos en entornos multihilo, y me limitaré a decir que «no tiene visibilidad del procesamiento de otras solicitudes».

Baste decir que la propia aplicación no tiene forma de determinar si una solicitud concreta forma parte de un ataque de mayor envergadura (inundación) o si su comportamiento no se corresponde con sus capacidades conocidas (agotamiento).

El proxy al rescate

Lo que sí tiene visibilidad sobre ambos aspectos es el proxy situado aguas arriba (delante) de la aplicación. Esto se debe a que probablemente el proxy esté realizando el balanceo de carga y, por tanto, tenga que prestar atención tanto al número de solicitudes que se están procesando en ese momento como al de las que están llegando, ya que debe enviarlas a una de las aplicaciones del clúster (o grupo, si lo prefiere).

Además, tiene que saber adónde enviar la respuesta, por lo que conoce al cliente y su conexión de red (normalmente, solo se envía a la aplicación la dirección IP del cliente, nada más). A diferencia de la aplicación, dispone de la visibilidad necesaria para detectar tanto los ataques de inundación como los de agotamiento, y detenerlos antes de que puedan hincar sus colmillos vampíricos en los recursos de la aplicación.

Por eso, los servicios basados en proxy, como un WAF (cortafuegos de aplicaciones web) o incluso un balanceador de carga avanzado, desempeñan un papel fundamental en las estrategias actuales de seguridad de las aplicaciones. Disponen de la visibilidad y los medios necesarios para detectar comportamientos anómalos que revelan un ataque y repelerlo como el ajo repele a los vampiros.

Y dado que estos servicios tradicionalmente «de red» deberían pasar necesariamente a formar parte de la arquitectura de la aplicación, parece lógico que un enfoque DevOps tienda a ampliar sus horizontes y sea más inclusivo con aquellos servicios que, por su propia naturaleza, tienden a integrarse en la aplicación desde el principio, como la seguridad de las aplicaciones y la escalabilidad (balanceo de carga).

Las aplicaciones no pueden detener todos los ataques, especialmente aquellos que requieren un nivel de visibilidad del que sencillamente no disponen. Sin embargo, al trabajar conjuntamente con servicios afines a las aplicaciones, como la seguridad de aplicaciones web y el balanceo de carga, se pueden proporcionar los medios necesarios para detectar y repeler un conjunto más amplio de ataques, reduciendo así las interrupciones y las brechas de seguridad.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie