Recientemente se encontró con una cosa mala, la estación de comercio electrónico de un cliente, obviamente, colgó un CDN de alta defensa, o se cepilló más de 100.000 pedidos falsos. Compruebe el registro encontró que el atacante perfectamente falsificado la IP del nodo CDN, la solicitud directamente eludido el sistema de protección. En estos días, incluso el CDN tiene que “evitar que los compañeros de equipo” - usted piensa que un escudo en la seguridad, pero no saben la verificación de la estación de origen no es bueno, de alta seguridad CDN se convertirá en el trampolín para los atacantes.
Los ataques de suplantación de IP no son nada nuevo. Pero mucha gente piensa que en el CDN descansará fácil, de hecho, un gran error. Los atacantes ahora primer paso escanear nodo CDN segmento IP, y luego forjado X-Forwarded-Para este tipo de cabecera, el tráfico de basura empaquetado como “tráfico legítimo CDN” directamente a la estación de origen. He probado tres principales proveedores de servicios CDN el año pasado, dos de la configuración por defecto en realidad permite que cualquier declaración de IP que son nodos CDN, este agujero de seguridad es simplemente más que una fuga de tamiz.
La causa raíz es que muchas operaciones y mantenimiento confían ciegamente en la lista de IPs proporcionada por el proveedor de servicios CDN. Pero las IP de los nodos CDN se actualizan ¡ah hermano! La lista de segmentos IP que se acaba de actualizar la semana pasada puede no ser válida esta semana. Por no hablar de los proveedores de CDN que utilizan servicios en la nube con IP elástica, la IP de nodo cambia más rápido que el libro. ¿Esperas mantener manualmente una lista blanca de IP? Es como enviar una invitación a los atacantes.
En primer lugar, la verificación de la IP de origen. No utilice el “CDN IP Segment Book” descargado de Internet, que expira más rápido que la vida útil de yogur. Yo ahora todos los proyectos han cambiado a utilizar mecanismo de autenticación dinámica: en el panel de control CDN para generar un Token único, y luego a través de un encabezado personalizado pasado a la estación de origen. La configuración de Nginx sitio de origen directamente escribir muertos:
Este truco es despiadado en qué? Incluso si el atacante falsificó la IP no puede obtener el Token. probado CDN5 y CDN07 dos, con la verificación de encabezado personalizado, la tasa de interceptación de solicitud ilegal directamente a 100%. Sin embargo, debemos prestar atención a la Token debe ser rotado con regularidad, se recomienda utilizar el sistema de gestión de claves para actualizar automáticamente.
El token por sí solo no es suficiente. El año pasado, nos encontramos con un caso, el atacante a través de la ingeniería social para obtener el Token (un empleado lanzó el archivo de configuración en GitHub), esta vez necesitamos una segunda línea de defensa - fingerprinting. El principio de esta tecnología es en realidad muy simple: a cada nodo CDN legítimo con una marca de agua digital, al igual que los agentes emitidos insignias de identificación.
He probado esto en el nodo de 08Host: inyectar un fragmento de código JS específico en la configuración de la CDN, y el sitio de origen confirma la identidad mediante la detección de esta huella digital. Por ejemplo, que el nodo CDN lo añada automáticamente cuando devuelva una respuesta:
Cuando la estación de origen recibe la solicitud, utiliza el mismo algoritmo para comprobar la firma, y rechaza la solicitud si la desviación de la marca de tiempo es superior a 5 segundos. Lo más chabacano de este esquema es que aunque el atacante consiga la clave, es inútil porque la marca de tiempo y el ID de nodo cambian dinámicamente. La implementación específica se puede incrustar en OpenResty usando scripts Lua:
Ahora, hablemos de la sobrecarga de rendimiento. Muchas personas escuchan “autenticación criptográfica” en la cabeza, piensan que afectará el rendimiento. De hecho, la prueba real, el aumento de retardo de verificación de una sola solicitud de menos de 2 ms. En comparación con el costo de ser paralizado por DDoS, esta sobrecarga es casi insignificante. Pero preste atención a la elección de los algoritmos de clave, no sea tonto al utilizar RSA como arma pesada, ECDSA o HMAC-SHA256 es completamente suficiente.
Recientemente para ayudar a una plataforma financiera para hacer pruebas de penetración, encontró un ataque más insidioso: el atacante primero legítimo acceso al nodo CDN, capturar las características de la huella digital de la cabecera de respuesta, y luego tratar de reproducir el ataque. En este momento, sólo confiar en la comprobación de firma estática no es suficiente, hay que añadir un mecanismo de número aleatorio de un solo uso (Nonce). He visto en los antecedentes de gestión de CDN07 que la última versión de su generador Nonce ha sido apoyada, refrescando automáticamente el valor de la semilla una vez cada 10 minutos.
De hecho, la solución más rentable es utilizar directamente el SDK del proveedor. como el módulo Edge Auth de CDN5 encapsula un conjunto completo de lógica de autenticación, la estación de origen sólo necesita ajustar una API para verificar la autenticidad. Pero no confíes totalmente en soluciones de caja negra: he visto una vulnerabilidad en la que el SDK de un proveedor estaba expuesto a claves de código duro. Ahora mi enfoque es utilizar la autenticación híbrida: utilizo el SDK del proveedor para hacer el filtrado inicial, y también implemento un conjunto alternativo de lógica de verificación de firmas.
Hablando de configuraciones específicas, pongamos un ejemplo de Nginx en acción. La siguiente configuración implementa la triple protección de listas blancas de IP, verificación de token y firma de huella digital al mismo tiempo:
Por último, algunos pequeños proveedores de servicios CDN con el fin de ahorrar costes, incluso los controles básicos de seguridad son demasiado perezosos para hacer. La última vez que probé un CDN llamado “inteligente de alta defensa”, encontró que en realidad ponen la lógica de verificación en el cliente JS ejecución - esto no es obvio para decirle al atacante “rápidamente para eludirme? ” Este es un mensaje claro a los atacantes. Por lo tanto, al seleccionar el tipo de equipo técnico debe ser programa de protección de prueba de campo, no se limite a mirar el proyecto de promoción voló por los aires.
Un sistema de protección verdaderamente fiable debe ser multicapa y dinámico. La verificación de la IP de origen es sólo la base, la huella digital es la barra de refuerzo, y tiene que ir unida a una serie de medidas como el análisis del comportamiento del tráfico (para detectar patrones de petición anormales) y la limitación de la velocidad (para evitar ataques CC). Ahora despliego soluciones a todos los clientes, les exigiré al menos una vez al mes que realicen una prueba de simulación de bypass - seguridad esta cosa, no hay un programa de una vez por todas.
A decir verdad, en los últimos tres años, el volumen de ataques de falsificación de IP se ha multiplicado por más de diez. Las herramientas de ataque han empezado a integrar el fingerprinting de CDN, y cualquier herramienta de código abierto puede identificar automáticamente a los proveedores de CDN y capturar las características de los nodos. Si la defensa sigue estancada en la “configuración de una lista blanca a nivel de pensamiento”, la brecha es realmente sólo cuestión de tiempo.
Por último, me gustaría compartir una lección aprendida de mis lágrimas: ¡nunca filtres detalles de validación en el registro de errores! He visto un sistema que devuelve “Firma caducada” y “Token no válido” cuando falla la verificación, ¿no es eso como entregar un cuchillo a un atacante? Lo correcto es devolver “404 Not Found”, para que el atacante ni siquiera pueda tocar el motivo del fallo.
Protegerse contra los ataques de falsificación de IP es como jugar al gato y al ratón; no existe una solución milagrosa. La clave está en establecer un sistema de defensa en continua evolución, después de todo, los medios del atacante también se actualizan constantemente. Al menos desde mi experiencia práctica, la combinación de Token dinámico y esquema de firma criptográfica, también puede ser 90% ataques de falsificación en la fuente de la muerte.
