Recientemente, me han preguntado, de alta seguridad CDN en el final no puede prevenir los ataques de API? Esta es una buena pregunta, lo que demuestra que la gente está finalmente empezando a preocuparse por la seguridad empresarial real - después de todo, en estos días, sólo un rastreador o llamadas maliciosas se pueden hacer a la interfaz de colapso, por no hablar de los específicos para la API de CC ataques y la penetración de inyección.
Yo digo directamente la conclusión: sí, pero definitivamente no abrir un CDN en todo. Tienes que entender, CDN de alta defensa es esencialmente un sistema de “limpieza de tráfico + programación inteligente”, y la protección de la API pertenece a una categoría más refinada WAF (Web Application Firewall). Muchos vendedores anuncian “una llave para proteger la API”, de hecho, detrás de un montón de configuraciones apiladas, si usted cree en los adwords, no está lejos de ser cepillado.
Voy a escupir un punto primero: muchas personas piensan que si compran un CDN de alta defensa, la API será automáticamente seguro. Como resultado del ataque, se encontró que la respuesta de la interfaz lenta como un caracol, un registro de verificación, todas las solicitudes maliciosas eludir las reglas de almacenamiento en caché, directamente a la estación de origen. Esto no es realmente CDN no puede, pero no le dijo a la CDN “que es la API” “cómo prevenir”.
¿En qué se diferencia un ataque a la API de un ataque web normal?
Las API suelen ser el núcleo del negocio, con frecuentes interacciones de datos, y muchas son peticiones dinámicas que no pueden confiar en el almacenamiento en caché para transportar el tráfico. A los atacantes les gusta centrarse en la API, porque una vez que se salta la protección, puede obtener directamente los datos e incluso levantar el derecho. He probado, un no hizo limitación de la tasa de la interfaz de inicio de sesión, una sola solicitud de IP cientos de veces por segundo, la CPU del servidor directamente se disparó completo - y esto es sólo un ataque primario.
Más despiadado es el tipo de ataque lento de baja frecuencia, simulando el comportamiento normal del usuario, cada pocos segundos para ajustar la clave API. esta solicitud parece inofensiva, pero un día de inactividad puede consumir cientos de miles de consultas a la base de datos, y el WAF tradicional es difícil de encontrar. Por lo tanto, la protección de la API debe ser “refinado”, sólo se basan en listas negras de IP y la protección básica de CC no es en absoluto suficiente.
¿Cómo proteger las API con CDN de alta defensa? El núcleo es sólo tres puntos: identificación, reglas, vinculación.
Por ejemplo, su interfaz de inicio de sesión de usuario es /api/v1/loginLa solicitud de pedido es /graphqlHay que decírselo explícitamente a la CDN: “Éstas son interfaces, no las trates como recursos estáticos”. Lo bueno es que los principales proveedores admiten la correspondencia de rutas, e incluso pueden anular el enrutamiento dinámico con expresiones regulares.
Por ejemplo, en la consola CDN5, puede configurar las reglas de ruta de la API del siguiente modo:
Lo que este conjunto de reglas significa es: todas las interfaces API coinciden en aceptar un máximo de 100 peticiones por minuto, con no más de 20 ráfagas cortas. Después de superar que no es un bloqueo de IP directa, pero un CAPTCHA emergente - después de todo, es peor perjudicar accidentalmente a un usuario real que dejar que un bot fuera del gancho.
Pero no basta con limitar el flujo, hay que protegerse contra los parámetros maliciosos y los ataques de inyección. Aquí es donde entran en juego las reglas WAF. Por ejemplo, para la inyección SQL, puede configurar reglas personalizadas en la consola de CDN07:
Cuidado, ¡no copies directamente mis reglas aquí! En el entorno real, usted tiene que ajustar de acuerdo con el negocio, de lo contrario puede matar por error la solicitud normal. He visto un proyecto de comercio electrónico, interfaz de búsqueda de productos con palabras clave “unión” (como “alianza de marcas”), los resultados fueron bloqueados directamente por el WAF, una gran broma.
Comparación de las capacidades de protección de API de distintos proveedores de CDN
He utilizado no menos de diez CDN y, para ser sincero, el nivel de cada una varía. Por ejemplo, la protección de la API de CDN5 es más detallada, admite la detección basada en JSON Body e incluso puede analizar la estructura de consulta GraphQL; mientras que la ventaja de CDN07 reside en la inteligencia global de amenazas, que puede relacionar los patrones de ataque de otros clientes y bloquear las IP maliciosas con antelación.
Sin embargo, hay algunos pequeños vendedores (no voy a nombrarlos) de “protección de la API” es un truco, en esencia, o la protección de CC en otro nombre, incluso POST Cuerpo no puede ser detectado. Si utiliza este tipo, es equivalente a cavar un agujero para la seguridad de la API.
Recientemente también probé los nodos de ultramar de 08Host y descubrí que su estrategia de protección para APIs es un poco interesante: no sólo soporta la limitación de flujo y WAF, sino que también puede ajustar dinámicamente su estrategia según el código de estado de retorno de la interfaz. Por ejemplo, si una interfaz devuelve de repente un gran número de errores 500, el sistema activará automáticamente un meltdown para evitar el efecto avalancha - esta característica es particularmente útil para la arquitectura de microservicios.
Configuración práctica: tres pasos para crear un sistema de protección API
El primer paso es, sin duda, ordenar los activos de la API. Es algo que parece básico, pero el 80% de los equipos simplemente no lo hacen todo. Tienes que listar todas las interfaces que están abiertas al público, incluyendo rutas, métodos (GET/POST), parámetros y líneas de base de tráfico normal. Recomiendo exportar directamente con Swagger o la especificación OpenAPI, de lo contrario la clasificación manual puede ser agotadora.
El segundo paso consiste en establecer estrategias de protección para las distintas interfaces. Las interfaces sensibles (como el inicio de sesión, el pago) para limitar estrictamente el flujo y la detección de parámetro completo, las interfaces públicas (como la lista de productos) puede ser relajado para limitar el flujo, pero anti-creeper. Un ejemplo:
El tercer paso es el monitoreo de registro y la iteración.registros de protección CDN deben ser acoplados sistema SIEM o plataforma de monitoreo de construcción propia, centrándose en falsos mata y eventos de derivación. Anteriormente he confiado en la pila ELK para hacer un Kanban en tiempo real, se encontró que un determinado rastreador específicamente en la mañana a las 4:00 API de rastreo de baja frecuencia, y luego añadió las reglas de dimensión temporal para detener por completo.
¡Nunca pises estos baches!
Algunas personas les gusta establecer el valor límite de flujo extremadamente bajo tan pronto como aparecen, y como resultado, los usuarios reales saltaron el CAPTCHA en masa durante la campaña, y la experiencia se derrumbó directamente. El enfoque correcto es poner primero la observación durante un período de tiempo, de acuerdo con la distribución real del tráfico para establecer el umbral - por ejemplo, tomar el volumen medio de solicitudes de 3 veces como la línea de disparo.
Además, no olvide que la CDN es sólo una capa de protección, y las API clave deben verificarse dos veces en la capa empresarial. Por ejemplo, la interfaz para modificar los datos del usuario, debe verificar el token de identidad y privilegios de operación. Una vez que la prueba de penetración encontró una laguna: nivel CDN poner la solicitud, pero el servidor no comprueba si el ID de usuario pertenece a la sesión actual, lo que resulta en sobrepasar el derecho de acceso.
También hay cuestiones de certificado y cifrado.API debe ser HTTPS de enlace completo, y tienen que actualizar el certificado con regularidad. He visto demasiadas tragedias donde el CDN no puede volver a la fuente debido a un certificado caducado, y la API es todo 503. Ahora Let's Encrypt puede renovar automáticamente el certificado, realmente no hay razón para cometer este error.
Resumiendo.
Una CDN de alta defensa protege frente a los ataques a la API, pero requiere una configuración proactiva y una optimización continua. La idea central es: identificar los activos de la API → establecer reglas refinadas → supervisar las iteraciones. Cuando seleccione proveedores, céntrese en la precisión de la detección WAF, las dimensiones de limitación de flujo y las capacidades de registro, como CDN5 y CDN07 están en el primer nivel, y 08Host es adecuado para escenarios específicos.
Por último, una afirmación sólida: la seguridad de las API no es una solución de una vez por todas, los métodos de ataque evolucionan cada día. Incluso en el mejor CDN, usted tiene que hacer pruebas de penetración regulares y auditorías de reglas. De lo contrario, cuando la fuga de datos y luego remediación, no es un cambio de configuración puede ser resuelto.
