Recientemente, ayudé a mi amigo para investigar un sitio web que fue golpeado por un ahorcamiento, iniciado sesión en el fondo CDN para echar un vistazo, buen tipo, el tráfico de ataque es casi romper el nivel T, pero la estrategia de defensa de la CDN de alta defensa es en realidad como una cuchara con fugas que no se detuvo a unas pocas peticiones. El negocio real está paralizado desde hace mucho tiempo, pero la consola también muestra que “todo es normal”, lo cual es una imagen irónica que se puede utilizar como una película de propaganda de seguridad de la red.
En estos días, incluso los CDN tienen que “evitar que los compañeros de equipo”. Los vendedores anuncian T-nivel de protección suena farol, pero la configuración no es correcta o la comprensión de sesgo, minutos para que usted pueda correr desnudo en el tiroteo de Internet. He probado el mercado cinco o seis principales servicios de alta defensa, pisando el hoyo resumió cinco de las razones más comunes para el fracaso de la CDN de alta defensa - algunos de los hoyo puede incluso dejar que el soporte técnico del fabricante están rascando la cabeza.
En primer lugar, la fuga de IP de la estación de origen: usted piensa que está oculto, de hecho, en el desnudo
El error más común y fatal. Una gran cantidad de webmasters piensan que el conjunto de CDN descansará fácil, pero no saben que los minutos atacante puede elegir su IP del servidor real. una vez que la exposición IP de la estación de origen, el tráfico de ataque directamente eludir la CDN de alta defensa para el servidor, lo que la protección se ha convertido en una configuración.
El año pasado, ayudé a un sitio de comercio electrónico para hacer pruebas de penetración, y se utiliza una herramienta de huellas dactilares de código abierto para escanear directamente la IP de origen - sólo porque se olvidaron de eliminar la fuente que apunta en el registro A de un subdominio. Más común es a través del servidor de correo, subdominios de edad, e incluso la información del certificado SSL para revertir comprobar la IP. no creo que “establecer el CDN es absolutamente seguro” tonterías.
Solución:
1. Aísle estrictamente la ruta de acceso a la estación de origen y permita que sólo el segmento IP de retorno de la CDN acceda al puerto del servidor. Una red backhaul privada como la que proporciona CDN5 funciona bastante bien, y además puedes personalizar los túneles cifrados;
2. Utilice regularmente la herramienta para autocomprobar los riesgos de exposición a la PI:
3. Solución independiente de terceros (por ejemplo, SendGrid) para servicios de correo, nunca en la misma IP que la empresa;
4. El cortafuegos del servidor deniega todo el tráfico por defecto y sólo abre los puertos necesarios a los segmentos IP proporcionados por el proveedor de CDN. en la documentación de CDN07 se proporciona directamente una lista de IP de nodos globales. recuerde actualizarla una vez a la semana.
II. Mala configuración de las normas de protección: tapa abierta no significa listo para usar
El caso más escandaloso que he visto es que una empresa compró un paquete de alta defensa de primer nivel, pero el WAF ni siquiera activa la protección CC básica, porque pensaban que estaba “todo activado por defecto”. De hecho, la mayoría de los CDN hoy en día, con el fin de reducir el número de falsos positivos, sólo abren la base de reglas básicas por defecto, como ataques lentos, abuso de API, estos necesitan ser configurados manualmente.
Otros han fijado sus umbrales de protección para que sean extremadamente agresivos: a una sola IP se le permiten 1.000 peticiones por segundo, lo que hace que la protección CC sea prácticamente inexistente. Es importante saber que el pico de comportamiento real de los usuarios no suele superar las 20 peticiones por segundo, por no mencionar que el “modo inteligente” de algunos proveedores no es en realidad más que un interruptor de umbral.
Solución:
1. Base de reglas WAF al menos abierta al nivel “estricto”, no tengas miedo de bloquear por error, es mejor que ser golpeado por ahorcamiento;
2. Reglas de frecuencia personalizadas: solía establecer umbrales por tipo de negocio. la pasarela API se limita a 50 veces por segundo para una sola IP, los recursos estáticos se relajan a 200 veces y la interfaz de inicio de sesión debe pulsarse menos de 10 veces;
3. Habilitar el modo de desafío de autenticación humana para que aparezca el CAPTCHA directamente para el tráfico sospechoso. 08Host ha hecho un buen trabajo en esta área y soporta múltiples modos de autenticación sin sentido y desafío JS;
4. Examine periódicamente los informes de ataques: céntrese en los patrones de ataque que intentan saltarse las normas, como los campos de cabecera UserAgent o XFF aleatorios.
En tercer lugar, los problemas de compatibilidad de certificados y protocolos: TLS también puede convertirse en una vulnerabilidad
Se encontró con una situación particularmente lamentable: el cliente compró una pequeña fábrica de CDN de alta defensa, los resultados de la otra parte no es compatible con el protocolo TLS1.3. El sitio se vio obligado a degradar a TLS1.2, y sucedió que se encontró con un ataque de CC utilizando las lagunas del protocolo, y la CPU directamente se disparó a plena capacidad. Más común es la mala configuración del certificado SSL conduce a CDN no puede ser normal apretón de manos, el tráfico de vuelta a la fuente de la desnuda sin cifrar.
Solución:
1. Pruebe el enlace cifrado completo con Qualys SSL Labs:
2. Asegúrese de que la cadena de certificados está completa y deben desplegarse certificados intermedios. Se recomienda utilizar servicios automáticos de gestión de certificados, tanto CDN5 como CDN07 proporcionan despliegue SSL de ventanilla única;
3. Desactive los protocolos más antiguos (SSLv3, TLS1.0) y fuerce la activación de la extensión SNI;
4. El enlace de vuelta a la fuente también debe estar cifrado, no utilices HTTP de vuelta a la fuente.
Cuarto, la desconfiguración de la resolución DNS: el punto ciego fatal del enrutamiento del tráfico
La CDN de alta defensa consiste esencialmente en programar el tráfico a través de DNS. Sin embargo, muchas personas han configurado incorrectamente los registros CNAME, o el valor TTL está configurado demasiado grande, lo que provoca un retraso en la resolución cuando se activa el ataque. El caso más extremo es que la caché DNS en algunas zonas llega a durar varias horas, y el negocio se ha colapsado mucho antes de que la estrategia de defensa surta efecto.
Otros olvidan pulsar primero la línea para resolver el tráfico al cambiar entre CDN de alta defensa y normal. El resultado de cambiar los registros DNS directamente es que algunos usuarios van al nodo antiguo, otros al nuevo, y se produce un vacío en la estrategia de defensa.
Solución:
1. Siempre CNAME el nombre de dominio al nombre de dominio protegido proporcionado por el CDN de alta defensa en primer lugar, y luego el CDN de nuevo a la fuente;
2. Ajuste el tiempo TTL más corto, 300 segundos para uso normal y 60 segundos para conmutación de emergencia;
3. Utilice la función de análisis sintáctico multilineal de DNSPod o Cloudflare para enviar a los nodos de alta defensa individualmente para el área de ataque;
4. Realice pruebas de penetración DNS de forma regular:
V. Conflictos entre las características de las empresas y las estrategias de protección
Este es el punto más fácil de pasar por alto. Cierto negocio en sí tiene características de solicitud de alta frecuencia (como WebSocket larga conexión, streaming de vídeo), la protección estricta ciegamente abierta dará lugar a un gran número de falsos positivos. Visto una plataforma de educación en línea, debido a que el paquete de latido del corazón de vídeo es interceptado por las reglas de CC, lo que resulta en los usuarios viendo la clase caída loco.
Además, la protección de la interfaz API debe tratarse por separado. las características de la solicitud POST en formato JSON son diferentes de las de una solicitud de formulario normal y requieren el ajuste de las reglas de detección del WAF. La base de reglas por defecto de algunos proveedores tiene una tasa de detección inferior a 30% para los ataques API.
Solución:
1. Antes de que el servicio entre en funcionamiento, debe realizar la prueba de la lista blanca: grabe el tráfico real del servicio para reproducirlo y observe las reglas de protección para acabar con la situación;
2. WebSocket y servicios de conexión larga para tomar un canal de reenvío dedicado, la política de protección WebSocket de 08Host se optimiza por separado;
3. Los servicios API permiten modos de protección especiales para centrarse en nuevos vectores de ataque como el análisis profundo de JSON y la inyección GraphQL;
4. Debe realizarse un análisis de registros en tiempo real, pila ELK o directamente con los servicios de registro del proveedor de CDN para detectar patrones anómalos de forma más fiable que simplemente confiando en WAF.
Para terminar
Un CDN de alta defensa no es una caja fuerte “plug-and-play”, sino un sistema sofisticado que requiere una puesta a punto continua. Una defensa realmente eficaz = 70% de configuración correcta + 20% de supervisión y alerta + 10% de respuesta de emergencia. No confíe totalmente en la "protección automática" del proveedor, eche un vistazo a la cartografía del tráfico en tiempo real y realice periódicamente simulacros de ataque y defensa.
Si realmente quiere recomendar - CDN07 es rentable para pequeñas empresas, CDN5 es preferible para escenarios de alto tráfico con Anycast Network, y puede mirar la solución de protección híbrida de 08Host para la búsqueda de una personalización extrema. Pero recuerde que no existe una solución única, sino una estrategia de seguridad iterativa y continua.
(¿No hay problema después de comprobar estos elementos de configuración? Envíeme un mensaje privado para enviar un informe de diagnóstico que le ayude a ver si está experimentando un ataque maligno)
