Protección eficaz contra ataques DDoS del servicio de API con cloudflare

Problema

Hoy en día, las aplicaciones suelen dividirse en aplicaciones de front-end y API de back-end.

El front-end normalmente se almacena en Object Storage (como AWS S3 o Google Cloud Storage) y delante de él se configura una CDN (como CloudFront o el mismo CloudFlare). Este esquema ha demostrado su eficacia y, con los DDoS, este recurso es ineficaz. Incluso si el DDoS es realmente poderoso, CloudFlare hace un gran trabajo al filtrar el tráfico no deseado, lo que lleva a los usuarios a recaptcha como último recurso.

Pero cuando se trata de servicios de API, las cosas son peores. Incluso después de superar un desafío de js en un navegador, un usuario válido no siempre puede acceder fácilmente al servicio de API que hay detrás de CloudFlare en Bajo ataque modo.

Si hablamos de las API que utilizan otros servicios que no tienen un trabajo interactivo (varios bots, servicios personalizados, etc.), entonces habilitar la Bajo ataque el modo de una API puede equivaler a bloquear el acceso a ella.

¿Qué hacer en este caso?

La propia CloudFlare tiene un artículo en el recurso de soporte. Recomienda simplemente reducir el Nivel de seguridad a los puntos finales de la API, desactivando el Siempre en línea modo, desactivación Almacenamiento en caché, y apagando Verificación de integridad del navegador.

Por supuesto, esto ayudará a eliminar el problema del bloqueo no deseado de las API, pero reducirá tanto el nivel de protección que el backend de su API podría sobrecargarse e incluso denegarse el servicio.

En este artículo, veremos dos formas que le permitirán filtrar el 100% del tráfico no deseado y eliminar por completo los falsos positivos y el bloqueo de las solicitudes de usuario válidas.

Idea

Como sugiere el título, transferimos la validación principal de las solicitudes al lado de CloudFlare, pasando solo las claves de API registradas en tu aplicación.

Este método solo es adecuado para las API privadas (que son las más populares). Si utilizas una API pública en la que cualquier persona puede hacer una solicitud a tu servicio, debes estar preparado para una afluencia de tráfico no deseado. Esta práctica de los últimos años demuestra que incluso las API públicas están optando por el modelo de acceso mediante un token, que solo se puede obtener tras el registro. Esto le permite controlar mejor el proceso de prestación de servicios y, al mismo tiempo, configurar la protección contra los ataques.

Implementación

CloudFlare tiene soporte sin servidor - Trabajadores de Cloudflare. Se trata de una herramienta realmente potente y flexible que, además, tiene un precio muy bajo (de 0 a 5 dólares al mes, sin exceso de tráfico). Más recientemente, Cloudflare tiene un servicio adicional: almacenamiento de valores clave, lo que le permite acceder a él directamente desde los trabajadores de CloudFlare.

Estas dos tecnologías nos ayudarán a implementar nuestro filtro principal:

Como podemos ver en el diagrama anterior, utilizamos Cloudflare Workers para comprobar la presencia de una clave de API en la base de datos Key-Value. Si la clave no está presente en la solicitud (o no está en el KV-Store), el cliente recibirá un estado HTTP 403. Si la clave se especifica correctamente, la solicitud se redirigirá al servidor, como de costumbre.

Debe prestarse especial atención a la Secuencia de comandos de sincronización de claves API. Este es un script que debe mantener la lista de claves Cloudflare KV actualizada, lo que significa que, tan pronto como se añada una clave a la aplicación o se bloquee o elimine, su estado debería reflejarse en Cloudflare KV tan pronto como sea posible.

Lo ideal es que este proceso se lleve a cabo en tiempo real.

Instrucciones paso a paso

• Inicie sesión en Panel de control de Cloudflare
• Selecciona el dominio
• Ir a Trabajadores
• Haga clic Administre trabajadores
• Ir a la pestaña KILOVOLTIO y crear un nuevo espacio de nombres (con nombre) fichas, por ejemplo)
• Volver a la Trabajador tabulador y clic Crear un trabajador
• Ingresa el siguiente código y haz clic Guardar e implementar

Código:

async function handleRequest(request) {
    const {searchParams} = new URL(request.url)
    const key = searchParams.get(API_KEY_NAME)
    const isKeyPresent = await TOKENS_KV.get(key)

if (!key || !isKeyPresent) {
        const data = {
            "status": "REQUEST_DENIED",
            "error_message": "Access denied."
        }
        const json = JSON.stringify(data, null, 2)
        
        return new Response(json, {
            status: 403,
            headers: {
                "content-type": "application/json;charset=UTF-8"
            }
        })
    }
    return await fetch(request)
}

addEventListener("fetch", event => {
        event.respondWith(handleRequest(event.request))
})

• Ir a la Ajustes pestaña de la nueva página de trabajador
• En la sección Variables de entorno, agrega la variable env API_KEY_NAME, con el nombre de tu clave de API como Value
• En la sección Encuadernación de espacios de nombres KV, cree la variable de entorno TOKENS_KV y, en Valor, seleccione crear Espacio de nombres KV. Por último, haga clic Guardar para guardar los cambios.
• Ahora es el momento de sincronizar las claves de API de tu aplicación con Cloudflare KV. Esto se puede hacer usando el API de Cloudflare. Proporcionaré un ejemplo de código Python que utiliza el cliente oficial de Cloudflare.
• CF_ACCOUNT_ID que puedes obtener usando documentación
• CF_API_TOKEN también se describe en doc.
• CF_KV_NAMESPACE_ID: este es el ID del espacio de nombres KV fichas, disponible en la página de configuración de KV

Código:

import logging
import CloudFlare‍

class CF:
    CF_ACCOUNT_ID = ''
    CF_API_TOKEN = ''
    CF_KV_NAMESPACE_ID = ''‍
    
    def __init__(self):
        self.cf = CloudFlare.CloudFlare(token=self.CF_API_TOKEN)‍
    
    def get_active_tokens_list():
        """
        Need define
        """
        return []
    
    def get_tokens(self):
        return [i['name'] for i in
                self.cf.accounts.storage.kv.namespaces.keys.get(self.CF_ACCOUNT_ID, self.CF_KV_NAMESPACE_ID)]
    def create_tokens(self, tokens):
        data = [{"key": token, "value": "enabled"} for token in tokens]
        self.cf.accounts.storage.kv.namespaces.bulk.put(self.CF_ACCOUNT_ID, self.CF_KV_NAMESPACE_ID, data=data)‍
    
    def delete_tokens(self, tokens):
        self.cf.accounts.storage.kv.namespaces.bulk.delete(self.CF_ACCOUNT_ID, self.CF_KV_NAMESPACE_ID,
                                                            data=list(tokens))‍
    def update_tokens(self):
        old_tokens = set(self.get_tokens())
        new_tokens = set(self.get_active_tokens_list())
        to_delete_tokens = old_tokens - new_tokens‍
        
        self.delete_tokens(to_delete_tokens)
        self.create_tokens(new_tokens)‍
        
        logging.info('CF KV tokens update status: {old} old / {new} new / {deleted} deleted'.format(old=len(old_tokens),
                                                                                                    new=len(new_tokens),
                                                                                                    deleted=len(to_delete_tokens)))

if __name__ == '__main__':
    c = CF()
    c.update_tokens()

• El último paso es volver al menú principal del dominio de Cloudflare en la sección Trabajadores y hacer clic en Añadir ruta botón. Especifique el punto final de la API que va a filtrar nuestro nuevo trabajador y seleccione el trabajador creado de la lista haciendo clic Guardar para guardar las reglas de enrutamiento.
• Si tienes mucho tráfico, probablemente tenga sentido cambiarte inmediatamente al plan pagado de Cloudflare Workers para no tener problemas con el límite agotado. Más información sobre los precios: https://developers.cloudflare.com/workers/platform/pricing
• Por supuesto, después de la aplicación de esta decisión, el nivel de protección debería reducirse y todas las demás recomendaciones deberían especificarse en https://support.cloudflare.com/hc/en-us/articles/200504045-Using-Cloudflare-with-your-API para puntos finales de API. La ventaja será que ahora el recurso no solo pasará el tráfico válido, sino que también filtrará el tráfico no válido.

Preguntas y respuestas

P: Pero, ¿cómo puedo dar acceso a Cloudflare a todas las claves de API de mi servicio? ¡No es seguro!

R: Ya le das acceso a Cloudflare a todo tu tráfico configurándolo en modo proxy. Y no solo tú. Según la investigación, Cloudflare es utilizado por el 80.9% de todos los sitios web cuyo servicio de proxy inverso conocemos. Esto representa el 14,7% de todos los sitios web.

Conclusión

El método descrito lo aplicamos en la práctica a un servicio de API que sucumbió a un ataque DDoS con una cantidad de varios miles de millones de solicitudes por día (con una carga normal de decenas de miles de solicitudes por día).

Esta solución rechazó el ataque al 100% y no bloqueó las solicitudes de los usuarios reales. Al mismo tiempo, los costes eran ridículos: hasta 50 dólares al mes (por el uso excesivo de las solicitudes dirigidas a los trabajadores de Cloudflare, lo que está incluido en la cuota de 5 dólares al mes en el momento en que se produjo el ataque). A partir de esto, podemos concluir que una solución de este tipo no solo es muy eficaz, sino que también es la opción más económica para proteger la API). A modo de comparación, los servicios especializados para proteger la API contra ataques de denegación de servicio en este tráfico costarían entre 800 y 1500 dólares para los mismos volúmenes. Al mismo tiempo, somos conscientes del potencial de CloudFlare y podemos estar seguros de que esta solución protegerá contra ataques más masivos.