Crear una estrategia de seguridad de defensa exhaustiva para aplicaciones web
Los ciberataques están en alza y los gobiernos instan a ciudadanos y a organizaciones a revisar y mejorar su seguridad. Evidentemente, esto hace que muchos clientes determinen qué medidas pueden poner en práctica hoy mismo para garantizarse la mejor protección de aplicaciones web. Aunque no hay una respuesta mágica que pueda detener todos los ataques, hay gran cantidad de prácticas recomendadas que se utilizan en una estrategia de defensa exhaustiva que pueden limitar sus repercusiones.
En esta entrada del Blog, pondré de manifiesto los pasos que puedes llevar a cabo para proteger tus aplicaciones a diferentes niveles, pero lo primero es entender cómo limitar lo que realmente puede ser objetivo de ataques en primera instancia.
Inventario de tus superficies de ataque y qué pueden ofrecer los proveedores
Resulta muy útil empezar a pensar en los pasos que tienen lugar durante una petición habitual en la que un cliente envía y recibe información con una aplicación web. Por ejemplo, la mayoría de la gente piensa en superficie de ataque de su hogar como la puerta principal, pero también deberían pensar en las ventanas, la entrada, los conductos de agua y el poste de electricidad de la calle. Del mismo modo, cualquier componente que pueda evitar que una aplicación sirva a los usuarios previstos puede ser objetivo de un ataque.
Si echamos un vistazo a estos componentes de una petición web de forma secuencial, la fase del DNS debe tener lugar para que el nombre de dominio se resuelva en una dirección IP. Luego, se conecta la IP y se envía una petición HTTP. Lo normal es que esta IP esté vinculada a un proxy inverso, como una red de distribución de contenidos (CDN) o un equilibrador de carga. Finalmente, el proxy inverso debe realizar una petición a una red de origen que albergue la versión original del contenido. Esto es todo lo que debemos proteger.
A través de estas tres fases, todo el modelo de conexión OSI (Open Systems Interconnection) o TCP/IP debe producirse para establecer un vínculo de datos, una conexión, una sesión, y luego devolver una petición completamente formada. En resumen, puedes verlo de la siguiente forma:
Desde la perspectiva de la seguridad, todos estos elementos constituyen funciones esenciales que pueden ser objetivo de ataques. Tener protecciones en cada lugar y ser consciente de qué protecciones dispone tu proveedor en tu nombre es esencial para la disponibilidad.
Por ejemplo, si usas un DNS distribuido, una CDN distribuida globalmente para almacenar contenido en caché, una limitación de frecuencia/volumen para aplicar límites de velocidad con identificadores variables para que sortearlo sea más difícil y un WAF en modo de bloqueo, las aplicaciones podrán estar protegidas ante un ataque. Nos gusta pensar que estas protecciones son como un embudo, con capas de protección que se alinean para lograr una estrategia de infraestructura de seguridad de defensa exhaustiva, como verás a continuación. En el resto de esta entrada, te explicaré cada segmento y protección con todo detalle.
Protege en cada nivel
Protecciones a nivel de la infraestructura
Hoy en día, para la gran mayoría de aplicaciones modernas de Internet, las empresas han decidido encargar las tres fases de petición web de las que hemos hablado a proveedores en la nube, en lugar de operar una red de forma directa. No obstante, como el DNS es un lugar habitual de ataque y la primera fase en la que ocurre una petición web, es buena idea pensar en el uso de múltiples proveedores de DNS, si es posible, para garantizar la máxima disponibilidad. También animamos a nuestros clientes a establecer un proxy inverso, como una CDN, al frente del máximo tráfico posible y así bloquear el origen para que solo reciba tráfico de IP seleccionadas (como el de esos proxies) para evitar ataques directos a la red de origen. Por último, el propio origen podría estar ubicado en un proveedor en la nube o en varios proveedores, con un equilibrio de carga por parte de la CDN al frente. Esto hace que la responsabilidad principal sea proteger la red de origen del proveedor, en lugar de a tu propio equipo.
Cuando estén aplicadas estas medidas, un sitio web individual o un operador de una aplicación podrán tachar los tipos de ataques de nivel inferior, como la amplificación UDP o los desbordamientos de SYN TCP, de la lista de cosas necesarias para la mitigación directa, gracias a la cobertura del proveedor. Por ejemplo, disponemos de una amplia red global con grandes cantidades de ancho de banda, prestaciones de mitigación y un grupo de red que supervisa constantemente nuestra infraestructura para poder reaccionar de inmediato a ataques como estos que ocurren en nombre de nuestros clientes.
Los clientes que operan en sus propias redes a menudo tienen prestaciones de limpieza de sus proveedores de servicios de Internet o de otros, que pueden desviar una IP de un BGP, limpiar el tráfico malicioso y volver a distribuir a la red de origen. Este servicio puede utilizarse para aplicar las listas de control de acceso anteriores ante un tráfico desbordante.
Protecciones a nivel de la aplicación
Con la infraestructura básica ahora protegida, los operadores pueden comenzar a centrarse en “el protocolo” o en los tipos de ataques basados en la capa 7 del modelo OSI, lo que conlleva que un ataque simula una petición de usuario real en la aplicación.
Los ataques a aplicaciones pueden tomar dos formas diferentes. La primera es un tipo de continuación de ataque a la infraestructura, en el que hay un desbordamiento de tráfico con peticiones que son bastante similares a las peticiones habituales de los clientes; el volumen es el problema. El objetivo de este ataque podría ser desbordar la aplicación hasta el punto de que deje de procesar peticiones legítimas (es decir, un ataque por denegación de servicio), o podría ser el de sustraer datos, dinero o inventario.
La segunda forma de ataque es una petición dirigida específica que es propiamente maliciosa porque su objetivo final es el de tomar el control de los sistemas de una aplicación. Las inyecciones SQL (SQLi), la ejecución de comandos (CMDEXE), una secuencia de comandos en sitios cruzados (XSS), los intentos a acceder a páginas de administrador y las peticiones que buscan aprovecharse de la vulnerabilidad Log4j son excelentes ejemplos de este tipo de ataques.
Cuidado con los vacíos
Debido a la proliferación de dispositivos basados en Internet y a los botnets a gran escala, cada vez es más fácil llevar a cabo ataques desbordando un sistema con ataques al protocolo. También podemos ver una evolución en la madurez en la apariencia de estos ataques. Aquí puedes ver mi perspectiva ante esta evolución y las formas que tienes de proteger tus aplicaciones:
Servir desde la caché
Como algo muy elemental, cualquiera puede realizar una petición para el mismo recurso miles de millones de veces en un intento de agotar los sistemas que lo sirven. Simplemente garantizando que se sirven tantos recursos como sea posible desde la caché puede reducirse la repercusión de este tipo de ataque. Las ventajas pasivas, como la reducción de peticiones a una sola y la protección, que permiten una elevada proporción de aciertos de caché y disminuyen el tráfico que se envía al origen, pueden ofrecer una particular ventaja si las peticiones se originan desde bots en lugar de desde usuarios reales. Además, buscar activamente el aumento de la cobertura de caché, como con el ordenamiento y el saneamiento de los parámetros de consulta de la petición, puede hacer que permanezca tanto como sea posible en la caché. Servir el tráfico desde la caché a menudo es la forma menos complicada en el aspecto computacional (además de la más rentable) de resolver un ataque a una aplicación en el protocolo.
Elevadas tasas conllevan un riesgo elevado
La siguiente evolución de los ataques es simplemente variar la URL para que sea un hash aleatorio, o cambiar otros valores de la petición para que no pueda ser almacenada en caché. Esto conlleva que se enviará de vuelta al origen un elevado volumen de tráfico a una tasa elevada. En conjunto, lo denominamos “caché que atrapa desbordamientos HTTP”.
La limitación de frecuencia/volumen del edge se ve a la tasa global de tráfico de acuerdo con un identificador de cliente. Aunque un atacante puede variar IP, agente de usuario red, etc., se pueden utilizar varias directivas juntas para fijar los límites de velocidad del tráfico global de acuerdo con cómo debería ser el perfil de tráfico típico para un sitio. Estos límites de protección de directivas podrían incluir hasta 100 RPS por IP, 100 RPS por userID, 500 RPS por red (es decir, ASN), etc. El objetivo no es eliminar el ataque al completo, sino mantener el flujo de tráfico lo suficientemente bajo como para que los sistemas posteriores puedan procesar el volumen.
Un daño lento y silencioso
No todos los ataques son a la fuerza bruta. A veces, parecen ocultar su tráfico en menores volúmenes para destacar menos, buscando atacar algo menor y más lento, y dependiendo del daño causado en los sistemas de backend. Si un atacante buscara una API capaz de cambiar en masa registros o una petición de autenticación con múltiples sistemas que consultar, podrían depender de la aplicación para amplificar su uso de la fuerza para ellos. De igual forma, los atacantes en busca de sistemas vulnerables quieren que su volumen sea lo suficientemente bajo como para evadir su detección por completo.
Para disponer de un control más preciso, la limitación de frecuencia/volumen de una aplicación ofrece una precisión quirúrgica frente a ataques de bajo volumen. Por ejemplo, puede crearse una regla fácilmente para limitar las IP a cinco peticiones por minuto en una lista de URL de API. También puede estar implicada la lógica, como únicamente limitar la frecuencia/el volumen de ciertos recursos, como países extranjeros o nodos TOR; o incluso excluir listas de orígenes de petición conocidas. No suele ser práctica recomendada bloquear todas las peticiones de un país en particular, a menos que la ley lo requiera expresamente. En lugar de eso, es mejor ser más estricto en cuanto al volumen y a la aceptación de tipos de peticiones procedentes de esos lugares de mayor riesgo, como en los que tu organización no opera actualmente.
Preocúpate por lo pequeño
Con tantos tipos diferentes de tráfico de desbordamiento eliminados, las peticiones maliciosas restantes son aquellas en las que existe incluso un volumen extremadamente pequeño de contenido malicioso. Muchos de estos tipos de ataques se definen en la lista de la fundación OWASP de principales ataques y puede utilizarse como guía para peticiones web maliciosas. Además, existen ataques individuales que se aprovechan de vulnerabilidades CVE para servirse de los defectos en las aplicaciones. Además de aplicar parches y gestionar vulnerabilidades importantes, detener el tráfico entrante de la propia vulnerabilidad participante ha sido históricamente el trabajo de un firewall de aplicaciones web (WAF).
Con un WAF antiguo, se recomienda asegurarse de que las reglas WAF están en un modo de bloqueo y de que tratan tantos activos como sea posible para maximizar la protección. No obstante, las soluciones de próxima generación pueden ofrecer la ventaja de un procesamiento de lenguaje mejorado para identificar mejor las peticiones maliciosas y evitar los falsos positivos. Además, nuestro WAF de próxima generación aprovecha los umbrales para garantizar que tanto la clasificación del ataque como la velocidad de este se tengan en cuenta antes de denegar una petición. Esto disminuye la posibilidad de bloquear una petición “subjetivamente benigna” como la de un empleado que envía código a un CMS y se marca como una señal de ataque. En conjunto, esto permite que el WAF se aplique a más activos, mientras ofrece un bloqueo preciso en producción. Como he mencionado anteriormente, las prestaciones de limitación de frecuencia/volumen aplican barreras al tráfico más allá del típico rol de un WAF tradicional.
Tu estrategia de seguridad global
Vale la pena reconocer que todos los temas de los que he hablado en esta entrada del Blog, como el aprovechamiento de los WAF y CDN, deberían existir en una estrategia de seguridad de defensa exhaustiva integral. Garantizar un control de acceso basado en roles (RBAC) y la autenticación multifactor (MFA) a través de un sistema de autenticación central puede garantizar la adecuada seguridad de los usuarios y mitigar el acceso no autorizado a los sistemas de seguridad. Un WAF no sustituye al seguimiento de las prácticas recomendadas en cuanto a gestión de vulnerabilidades ni al escaneo activo de los cambios realizados en la aplicación.
Sin embargo, la gran mayoría del tráfico que recorre la Internet pública se basa en HTTP y los métodos descritos en esta entrada del Blog reflejan algunos de los desafíos de ciberseguridad más habituales para las aplicaciones web de hoy en día. Colabora con tus socios de confianza para garantizar que los sistemas están listos para proteger tu aplicación ante ataques. Nuestros equipos tecnológicos y de asistencia técnica están ahí para ayudarte a implementar esas tecnologías y ayudarte a protegerte en la medida de lo posible. Ponte en contacto con nosotros para comenzar o realizar cualquier pregunta.
