El ataque que no puedes detener en tu aplicação
Se pueden (y se deben) prevenir una amplia variedad de ataques basados en HTTP en su aplicação. El OWASP Top 10 es un excelente ejemplo de técnicas de ataque que son detectables y prevenibles desde cualquier aplicação. Una gran cantidad de herramientas que incluyen análisis estáticos y dinámicos, así como pruebas de penetración, pueden garantizar que estas vulnerabilidades no pasen a producción. Siempre y cuando, por supuesto, dichas pruebas de seguridad se trasladen al proceso CI/CD en lugar de dejarlas como el paso final antes de activar el interruptor (o los bits, por así decirlo) que las hace accesibles a los usuarios.
Incluso si ha eliminado todas las vulnerabilidades potenciales encontradas en el desarrollo, las aplicações aún están en riesgo. Esto se debe a que algunos ataques no pueden (y cuando digo "no pueden" en realidad quiero decir "no pueden") ser detectados por la aplicação. De hecho, cuando el ataque llega a la aplicação, ya es demasiado tarde.
Por supuesto, estoy hablando de ataques DDoS de capa de aplicação (HTTP). Ya sabes, esos vampiros que explotan el propio protocolo HTTP para básicamente absorber hasta la última gota disponible de procesamiento y memoria de una aplicação para volverla inútil para usuarios legítimos.
Básicamente, existen dos tipos de ataques DDOS HTTP: el rápido y el lento, el de inundación y el de drenaje.
El ataque de la inundación
Un ataque DDoS HTTP basado en inundaciones aprovecha el hecho de que se espera que las aplicaciones acepten solicitudes HTTP y respondan a ellas. Ese es su estilo, ¿no? Y así lo hacen. Y lo hacen independientemente de la rapidez con la que lleguen esas solicitudes. Incluso si las solicitudes llegan a un ritmo que agotará los recursos disponibles para ese servidor en minutos (o segundos), este intenta responder. Mira, cada aplicación (de hecho, cada dispositivo, servicio, sistema, etc.) tiene un límite superior en la cantidad de conexiones TCP que puede mantener abiertas en cualquier momento antes de que simplemente no pueda abrir más. Cuando se alcanza ese límite superior, cualquier solicitud posterior simplemente se ignora. Los usuarios experimentan esto con el estado inocuo "Intentando conectar..." mientras su navegador o aplicación espera hasta que transcurra el tiempo especificado por el sistema y luego se disculpa por no poder conectarse.
Este tipo de ataque puede llegar tan rápido (de ahí la analogía de una “inundación repentina”) que supera la capacidad de los sistemas de escalar para satisfacer la demanda. Ni siquiera el escalamiento automático puede ayudar en este escenario, ya que el tiempo que lleva aprovisionar y lanzar una nueva instancia de la aplicación es mayor que el tiempo que tarda el ataque en despojar a las instancias existentes de todos sus recursos.
El ataque del drenaje
El método opuesto (un ataque de drenaje) realiza la misma tarea pero lo hace forzando a la aplicación a mantener una conexión abierta más tiempo del necesario. Logra esto simulando que está conectado a una red telefónica, y enviando unas cuantas gotas de datos de la aplicación por segundo en lugar de hacerlo a la velocidad a la que realmente es capaz de recibirlos. Al hacerlo, las conexiones duran más tiempo y, si lo haces con suficientes conexiones, básicamente terminarás en la misma situación que el ataque de inundación: agotamiento de recursos.
Ninguno de estos ataques es detectable desde dentro de una aplicação. ¿Por qué lo serían? Para la aplicação , todas estas solicitudes son legítimas: son solicitudes de datos bien formadas y basadas en HTTP que probablemente responde miles de veces al día. No hay ninguna bandera en los encabezados HTTP ni en la carga útil que indique la naturaleza nefasta de las solicitudes. La aplicação es completamente ciega a las intenciones maliciosas detrás de estas solicitudes porque no tiene visibilidad de la red ni del entorno más amplio, específicamente la tabla de sesiones del servidor que mantiene la lista maestra de todas las conexiones abiertas. Te ahorraré los detalles técnicos y la charla sobre subprocesos, procesos y volatilidad de datos en entornos multiproceso y me limitaré a la "falta de visibilidad en el procesamiento de otras solicitudes".
Basta decir que la aplicação por sí misma no tiene forma de determinar si una solicitud dada es parte de un ataque más grande (inundación) o si su comportamiento es inconsistente con sus capacidades conocidas (drenaje).
El proxy al rescate
Lo que tiene visibilidad en ambos es el proxy que se encuentra aguas arriba (delante de) la aplicação. Esto se debe a que el proxy probablemente está realizando el equilibrio de carga y, por lo tanto, tiene que prestar atención a cuántas solicitudes están actualmente en proceso, así como a cuántas ingresan, porque tiene que enviarlas a una de las aplicaciones en el clúster (o grupo, si lo prefiere).
Además, debe saber dónde enviar la respuesta, para poder conocer 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 aplicação, tiene la visibilidad necesaria para detectar ataques tanto de inundación como de drenaje, y detenerlos antes de que puedan hundir sus dientes vampíricos en los recursos de la aplicación.
Es por eso que los servicios basados en proxy como un WAF (firewall de aplicação web) o incluso un balanceador de carga avanzado son un actor fundamental en las estrategias de seguridad de aplicação actuales. Porque tienen la visibilidad y los medios para detectar el comportamiento anómalo indicativo de un ataque y repelerlo como al ajo y a un vampiro.
Y debido a que estos servicios tradicionalmente "de red" necesariamente deben convertirse en parte de la arquitectura de la aplicação , parece lógico que un enfoque DevOps tienda a extender sus alas y ser más inclusivo de aquellos servicios que naturalmente gravitan hacia la aplicação en primer lugar , como la seguridad de la aplicación y la escalabilidad (equilibrio de carga).
Las aplicações no pueden detener todos los ataques, en particular aquellos que requieren un nivel de visibilidad que simplemente no está disponible para ellas. Sin embargo, trabajar en conjunto con servicios afines a la aplicación, como la seguridad de aplicaciones web y el equilibrio de carga, puede proporcionar los medios por los cuales se puede detectar y repeler un conjunto más completo de ataques para garantizar menos interrupciones y violaciones.