Cómo Azure Front Door ayuda a proteger contra ataques DDoS
Cada vez hay más ataques DDoS a páginas webs, concretamente ataques a aplicaciones de capa 7, que desconectan un sitio web abrumándolo con peticiones HTTP. Este tipo de ataques son relativamente fáciles de automatizar y ejecutar por los atacantes a través de redes de bots, y son particularmente eficaces contra los servicios web que utilizan frameworks y sistemas de gestión de contenidos más antiguos. Un ataque DDoS puede inutilizar por completo un sitio web que no esté adecuadamente preparado.
La buena noticia es que las plataformas de computación en nube como Microsoft Azure proporcionan servicios globales como Azure Front Door que ayudan a protegerse de los ataques DDoS, proporcionando varias capas de defensa para reducir el impacto de un ataque y disuadir a los atacantes.
Ataques a aplicaciones de capa 7
Los tres tipos principales de ataques DDoS son volumétricos, de protocolo y de aplicación o recursos. El almacenamiento en caché puede mejorar la resistencia de una aplicación a los ataques de aplicación de capa 7.
Un ataque a los recursos se efectúa enviando tantas peticiones (legítimas) a un servicio como sea posible en un intento de saturarlo, lo que se conoce como ataque de «denegación de servicio» (DoS). Cuando un ataque se distribuye utilizando una sofisticada red de bots, el ataque se conoce como «ataque distribuido de denegación de servicio» (DDoS). El objetivo de un ataque DDoS suele ser dejar fuera de servicio (o amenazar con hacerlo) un activo web valioso y luego pedir un rescate.
A diferencia de los ataques tradicionales de capa 3/4 (volumétricos y de protocolo), los ataques de recursos contienen peticiones bien formadas que se ajustan a los protocolos y parecen legítimas. De este modo, el tráfico de ataque puede eludir el bloqueo de protocolos y los controles de cortafuegos de aplicaciones web. Los propietarios de sitios web y aplicaciones pueden hacer que sus aplicaciones sean más resistentes a los ataques combinando varias capas de defensa, incluidas las funciones de protección DDoS que ofrece Azure Front Door: absorción de capacidad, bloqueo de protocolos, almacenamiento en caché y un cortafuegos de aplicaciones web (WAF) con protección contra bots.
Almacenamiento en caché
El almacenamiento en caché es una de las formas más sencillas de reducir el tráfico de ataque, así como de mejorar el rendimiento y la resistencia, y reducir costes. Azure Front Door Cache permite escalar una aplicación para manejar más carga y absorber el tráfico de ataque si es necesario. ¿Cómo funciona?
Almacenamiento en caché de activos estáticos
El almacenamiento en caché de activos web estáticos (imágenes, scripts, hojas de estilo, vídeos) en una red de distribución de contenidos (CDN) es un buen ejemplo de estrategia de almacenamiento en caché para mejorar el rendimiento y la escalabilidad. Los activos estáticos suelen almacenarse en caché durante días. Estos activos pueden ser inmutables o purgarse en el momento del lanzamiento.
Almacenamiento en caché de respuestas dinámicas
También es una buena práctica almacenar en caché recursos dinámicos pero de «cambio poco frecuente». Por ejemplo, la página de inicio de un sitio web puede ser generada dinámicamente por un sistema de gestión de contenidos, pero el contenido devuelto a un usuario no necesita cambiar a menudo – ciertamente no cada solicitud. En este caso, las respuestas a las solicitudes de recursos de la página de inicio pueden almacenarse en caché durante un breve periodo de tiempo; normalmente segundos o minutos.
Imaginemos que un atacante está enviando 30 millones de peticiones por minuto a la página de inicio de su sitio web a través de una red de bots. Sin ningún tipo de mitigación, el servidor de origen tendrá que ser capaz de servir quinientas mil peticiones por segundo (500K RPS), lo cual es mucho. Sin embargo, si la respuesta de la página de inicio se almacena en caché durante un minuto en Front Door, sólo unos cientos de esos 30 millones de peticiones llegarán al servidor de origen. Para escenarios donde un tiempo de expiración de un minuto es demasiado largo, vale la pena considerar un TTL de incluso 1-2 segundos ya que esto puede reducir dramáticamente el tráfico.
TTL (time to live)
El tiempo durante el que un recurso debe almacenarse en caché se conoce como TTL (time to live) o tiempo de expiración. Algunos equipos definirán la caducidad de los recursos como un requisito no funcional durante la planificación del sprint, o como una definición de hecho. Una buena pregunta para determinar el tiempo de caducidad de un recurso es «¿cuándo esperaría un usuario que se actualizara este contenido?».
La mayoría de las páginas anónimas (aquellas que no requieren que el usuario inicie sesión) son buenas candidatas para almacenar en caché con un TTL corto. Por ejemplo:
- Página de inicio
- Quiénes somos
- Contacto
- Catálogos de productos
- Datos de referencia de cambios no frecuentes (códigos de país, por ejemplo)
No todas las páginas, API y recursos son adecuados para el almacenamiento en caché. Por ejemplo cualquier dato que requiera coherencia en tiempo real. Para aprovechar al máximo las ventajas de la caché, los desarrolladores deben seguir unas buenas prácticas de diseño web, diseñando los sitios de forma que se puedan almacenar en caché para sacarles el máximo partido.
Control de caché
Lo mejor de la caché Front Door es que no requiere ninguna configuración aparte de activarla. Una vez activada, Front Door Cache simplemente respetará cualquier cabecera cache-control que sea devuelta por el servicio de origen. Si no hay ninguna cabecera, Front Door guardará la respuesta en caché entre uno y tres días. Sin embargo, si la cabecera cache-control contiene no-cache, private, o no-store, Front Door nunca almacenará la respuesta, incluso si el almacenamiento en caché está habilitado en la ruta. Cualquiera de estos escenarios (ninguna directiva o una directiva para no almacenar en caché) puede tener consecuencias no deseadas, por lo que es importante que los orígenes envíen las directivas correctas.
Comprobación de cabeceras de caché
Se puede comprobar si las cabeceras de las directivas de caché están presentes usando curl. En el ejemplo hay un origen que está detrás de una Azure Front Door.
Las solicitudes a Front Door se enrutan a un grupo de origen mediante una regla de enrutamiento, con el almacenamiento en caché activado. El grupo de origen es un Azure App Service con restricciones de acceso para aceptar únicamente tráfico de Azure Front Door o la del ordenador del desarrollador.
Monitorización de la caché
El rendimiento de la caché puede ser monitorizado en el Azure Portal usando los informes Azure Front Door, o escribiendo tus propias consultas Kusto en Front Door Logs (Azure Monitor).
¿Te ha parecido interesante? ¿Quieres más información o que lo implantemos en tu página web? Ponte en contacto con nosotros y te aconsejaremos.
Post basado en la publicación en inglés de DanielLarsenNZ en techcommunity.microsoft.com: How Azure Front Door cache can help protect against DDoS attacks
