Cuando se producen brechas relacionadas con aplicaciones y exposición de datos, casi siempre se señala a los desarrolladores. En muchos casos, se hace con razón. Los ataques de inyección y los exploits basados en la pila casi siempre son consecuencia de código no seguro. Normalmente, porque se ha infringido la Regla Cero de Seguridad.
Pero no podemos culpar a los desarrolladores de todas las brechas de seguridad. Lo cierto es que, aunque los desarrolladores pudieran crear código totalmente seguro, seguirían siendo necesarios servicios de aplicaciones para protegerse frente a muchos otros ataques.
Esto se debe a que la seguridad de las aplicaciones se basa en varias capas. Hay ataques que aprovechan los protocolos y los principios de las redes y que no pueden evitarse simplemente mediante una «programación segura». Para complicar aún más la seguridad, las aplicaciones a menudo no pueden detectar estos ataques porque carecen de la visibilidad necesaria para distinguir las solicitudes maliciosas de las legítimas.
En concreto, hay tres ataques de los que los desarrolladores sencillamente no deberían tener que ocuparse. En su lugar, estos ataques se detectan y mitigan mejor mediante servicios de aplicaciones desplegados en una fase anterior, donde se dispone de la visibilidad y el contexto necesarios para ayudar a detenerlos.
DDoS volumétrico
Utilizamos el término «volumétrico» para describir un ataque distribuido de denegación de servicio tradicional y distinguir los ataques basados en la sobrecarga de la red de aquellos que han ascendido en la pila para atacar la capa de aplicación. Se trata de clases de ataques diferentes, por lo que debemos ser capaces de defendernos de ambos, aunque para ello se requieren soluciones muy distintas.
Un ataque volumétrico es, sencillamente, una ofensiva relámpago. Se dirige una avalancha de tráfico contra un servicio concreto con la intención de saturar el dispositivo, la infraestructura o el software que gestiona las solicitudes. El principio subyacente es que todos los dispositivos —ya sean de hardware o software, locales o en la nube— disponen de recursos limitados. Por tanto, si se envían suficientes solicitudes, el dispositivo puede quedar saturado y bloquear el acceso a todo lo que se encuentra detrás de él.
El motivo por el que los desarrolladores no pueden prevenir eficazmente este ataque es que las aplicaciones dependen de las plataformas y de los sistemas operativos anfitriones para gestionar las conexiones de red. Un ataque DDoS volumétrico tiene como objetivo esa pila de red y puede consumir tantos recursos compartidos que la aplicación apenas logra procesar las solicitudes necesarias para determinar que está siendo atacada.
La programación segura no puede evitarlo: no se trata de un ataque que aproveche una vulnerabilidad. Y, en realidad, tampoco es culpa del código de ninguna parte del sistema. Sencillamente, por mucho que intentemos fingir que el hardware no existe, es de ahí de donde proceden los recursos, y estos son limitados.
Los ataques DDoS volumétricos se detectan y mitigan mejor mediante servicios de aplicaciones de gran capacidad y alto rendimiento situados en un punto anterior a la aplicación. Cuanto más cerca estén del origen del ataque, mejor.
Sin vulnerabilidad explotable, no hay solución mediante codificación segura.
DDoS de capa 7
Al ascender por la pila hasta la capa de aplicación, encontramos una forma insidiosa de denegación de servicio denominada DDoS de capa 7 (o HTTP). Estos ataques resultan exasperantes porque aprovechan el funcionamiento del sistema, pero no se deben a una vulnerabilidad ni a prácticas de programación poco seguras. Funcionan debido a la propia naturaleza de HTTP y de los sistemas que lo implementan.
Por lo general, existen dos tipos de ataques DDoS de capa 7: lentos y rápidos. Los ataques DDoS lentos de capa 7 consumen recursos simulando una conexión de red pésima y extrayendo m u y l e n t a m e n t e las respuestas a solicitudes legítimas. Esto consume recursos porque las aplicaciones web se basan en conexiones y, una vez más, los recursos para mantenerlas son limitados. Al conectar suficientes clientes y realizar solicitudes legítimas, pero recibir las respuestas lentamente, los atacantes consiguen acaparar los recursos de la aplicación. Esto hace que a los clientes legítimos les resulte prácticamente imposible conectarse, lo que en la práctica constituye un ataque de denegación de servicio.
Este ataque es especialmente pernicioso y difícil de detectar, a menos que se compare la velocidad de la red con la velocidad de recepción. Es decir, los servicios de aplicaciones situados en niveles superiores tienen visibilidad sobre las características de red de los clientes y pueden determinar con mayor precisión si estos reciben los datos lentamente de forma intencionada o si realmente tienen un problema de red. Determinar su legitimidad es fundamental para detener este tipo de ataques.
Básicamente, estos ataques aprovechan vulnerabilidades en la capa de protocolo (HTTP), y la programación segura no puede hacer nada para impedirlos.
Sin vulnerabilidad, no hay solución mediante programación segura.
Relleno de credenciales
Por último, pero no por ello menos importante, está el relleno de credenciales. La increíble cantidad de credenciales expuestas a raíz de filtraciones en los últimos años hace que sea especialmente importante protegerse contra este ataque.
Los ataques de relleno de credenciales suelen recurrir a bots o herramientas, ya que se basan en principios de fuerza bruta que aprovechan las enormes cantidades de volcados de nombres de usuario y contraseñas existentes. Es muy poco habitual encontrar ataques de relleno de credenciales realizados manualmente. Un ataque de relleno de credenciales exitoso no es consecuencia de una programación poco segura*. Los atacantes no intentan aprovechar nada más que unas malas prácticas en el uso de contraseñas y la incapacidad para reconocer un ataque en curso.
Para detectar estos ataques, debe poder determinar que el cliente no es un ser humano real. Por tanto, en una especie de prueba de Turing inversa, tendrá que plantear desafíos y utilizar CAPTCHA de forma que estos sistemas automatizados no puedan responder.
Ninguna práctica de programación segura puede impedir que este ataque tenga éxito. Mejorar las prácticas relativas a las contraseñas y detectar los intentos de ataque son las mejores formas de evitar sucumbir a esta creciente lacra de Internet.
Sin código explotable, no hay solución de codificación segura.
*Los ataques de relleno de credenciales pueden verse facilitados por prácticas de programación inseguras. Al fin y al cabo, un número considerable de brechas de seguridad se produce debido a vulnerabilidades en el código que dan lugar a enormes listas de credenciales disponibles para este tipo de ataque.
Diferenciar para detectar y defenderse
Es importante saber cuándo se puede utilizar la programación segura para prevenir un ataque y cuándo no. Esto es importante porque no podemos seguir culpando a los desarrolladores de cada ataque que tiene éxito. La seguridad requiere pensar a nivel de sistema; necesitamos múltiples soluciones porque debemos defendernos de distintos tipos de ataques.
Es importante distinguir entre los distintos tipos de ataques para poder defenderse de forma eficaz y satisfactoria frente a la variedad de ataques a los que se verá sometida la mayoría de las organizaciones en un futuro próximo. No pierda el tiempo intentando obligar a los desarrolladores a defenderse de ataques cuando (1) no se trate de una vulnerabilidad explotada debido a prácticas de programación inseguras o (2) no sea posible por falta de visibilidad.
Debemos abordar la seguridad de forma estratégica mediante un sistema de servicios que proporcione la protección adecuada en los lugares apropiados, independientemente de cuál sea el origen o la superficie de ataque.
Mantente a salvo.
Sobre el autor
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 VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.