Recientemente, ayudé a un amigo a lidiar con un proyecto que fue golpeado por DDoS y no pude ocuparme de mí mismo, así que me acordé de preguntarle: “¿Estás usando una CDN que no tiene alta defensa?”. Como resultado, este amigo me preguntó con cara de confusión: “¿Puedes elegir un protocolo para una CDN de alta defensa? ¿No dar un nombre de dominio para colgar al final del asunto?”. Estuve a punto de romper el teclado en el acto: hoy en día todavía hay gente que piensa que las CDN sólo sirven para acelerar, y que la defensa y el soporte de protocolo son sólo para aparentar...
Honestamente, lo del soporte de protocolo realmente no es metafísico. He visto demasiadas personas compran un servicio de alta defensa, el resultado se debe a que el protocolo no está emparejado, fue perforado después de que los vendedores también regañó basura. De hecho, el problema es que usted no entiende los escenarios de negocio: usted empuja streaming en vivo con RTMP, hacer la comunicación en tiempo real con WebSocket, sitios web ordinarios con HTTPS, diferentes protocolos para ir puerto y cifrado son completamente diferentes. Si los proveedores de CDN sólo le ayudan a prevenir 80/443 puertos, otros protocolos simplemente no pasan por el nodo de limpieza, y ¿cuál es la diferencia entre correr desnudo?
Tome HTTPS primero, que es el más básico. Pero el soporte HTTPS de CDN de alta defensa y CDN ordinaria simplemente dos cosas diferentes. CDN ordinario puede simplemente ayudarle a hacer un punto final SSL, mientras que CDN de alta defensa tiene que estar involucrado en todo el proceso de protección TLS handshake. He probado los servicios de CDN5, incluso pueden identificar paquetes anormales en el tráfico encriptado - por ejemplo, una IP de repente envía peticiones TLS handshake con una frecuencia alta, lo que dispara directamente las reglas y las lanza a un agujero negro. No se crea esa propaganda de “soporte total de protocolo”, muchos vendedores de protección HTTPS simplemente no hacen detección SNI, se encuentran con ESNI (SNI cifrado) directamente mudo.
Al configurar HTTPS alta defensa, usted tiene que prestar atención a la forma en que se despliega el certificado. Se recomienda el uso de verificación de certificados de dos vías, aunque el problema, pero puede bloquear la mayoría de los ataques de certificados falsificados. Publicar un ejemplo de configuración de Nginx:
Además del protocolo RTMP, que es un viejo amigo de la industria de la retransmisión en directo. Soporte CDN de alta defensa para RTMP es clave para el aislamiento de los nodos push y pull. Algunos vendedores con el fin de ahorrar costes, flujo de empuje y tire de flujo con el mismo conjunto de servidores, los resultados del atacante un ataque de inundación RTMP, todo el colapso de la cadena en vivo. La práctica fiable como CDN07, nodos de flujo de empuje solo con clúster de alta defensa, los nodos de flujo de tracción y luego hacer la aceleración distribuida. Una vez medido su protección RTMP, nodos de flujo de empuje para llevar 200Gbps ataque de inundación al mismo tiempo, el retraso de flujo de tracción no superó los 200ms.
WebSocket es el escenario que realmente pone a prueba la tecnología de los proveedores. Este protocolo se caracteriza por conexiones largas, la estrategia tradicional de protección basada en la frecuencia de las peticiones es básicamente ineficaz. Los atacantes construyen cientos de miles de conexiones WebSocket colgando todavía pueden agotar los recursos del servidor. Buena CDN de alta defensa como 08Host para hacer el análisis del comportamiento de conexión - por ejemplo, una IP para construir una conexión después de la continua falta de envío de paquetes, o enviar un paquete de latido del corazón por segundo más que el umbral, directamente pellizcar conexión. También tienen que apoyar la suma de comprobación de actualización de protocolo, para evitar que los atacantes disfrazados de WebSocket apretón de manos en realidad se envía HTTP Flood.
Hay otro escollo que he encontrado recientemente: la protección WebSocket sobre TLS (WSS). Muchos vendedores piensan que la misma configuración que la protección HTTPS funcionará, pero el resultado es que se penetra en la fase de handshake TLS. Se recomienda configurar WSS para que imponga una versión mínima de TLS de 1.2 y deshabilite las suites de cifrado débiles. He probado la configuración por defecto de un proveedor, pero también soporta TLS 1.0, que directamente estaba en mi lista negra.
Además de estos protocolos principales, hay algunos escenarios especiales de los que merece la pena hablar. Por ejemplo, el protocolo UDP de uso común en la industria del juego, CDN de alta defensa tiene que soportar la protección de inundación UDP; la industria financiera puede necesitar el protocolo privado TCP, dependiendo de si la CDN soporta la protección de puerto personalizado. He visto un sistema de comercio de valores debido a la utilización de puertos no estándar, comprar un CDN de alta seguridad no detecta el tráfico de puerto, fue paralizado por SYN Flood antes de pensar en reglas personalizadas.
No te fijes sólo en el precio a la hora de elegir un CDN de alta defensa. Voy a enumerar unos datos de comparación de la vida real:
Por último, me gustaría dar una violenta teoría: los ataques a la red en estos días han ido mucho más allá del simple y burdo ICMP Flood. Los atacantes han comenzado a apuntar a las vulnerabilidades de protocolo para hacer ataques de capa de aplicación, tales como ataques de conexión lenta WebSocket, ataques de ofuscación de protocolo RTMP. Si usted elige el proveedor de CDN incluso la adaptación de protocolo no son perfectos, equivalente al hacker abrió la puerta trasera y también activamente pasar la llave.
Cuando configure una CDN de alta defensa, recuerde ponerse en segundo plano y mirar los informes de tráfico en tiempo real. Un buen sistema de protección mostrará claramente los tipos de ataques y las mitigaciones para los distintos protocolos. No espere a que su negocio se derrumbe para comprobar los registros: para entonces sus clientes se habrán quedado sin ellos. La seguridad es algo que siempre es mejor prevenir que remediar a posteriori.
Olvidé decir un punto clave: el soporte de protocolo también depende del camino de vuelta a la fuente. Algunos CDN anuncian soporte para WebSocket, pero de vuelta a la fuente se rebaja a HTTP polling, explosión directa de latencia. Asegúrese de utilizar los escenarios reales de negocio para probar antes de comprar, de lo contrario es gastar dinero para comprar un solitario.
En resumen (tsk, no he podido resistirme a decirlo en pocas palabras otra vez), la compatibilidad de protocolos para CDN de alta defensa no es un juego de casillas. Desde HTTPS hasta WebSocket, cada protocolo tiene una superficie de ataque y unos puntos de protección únicos. A la hora de elegir un proveedor, hay que comprobar la solidez de la relación, la compatibilidad de los protocolos, la granularidad de la protección y la pérdida de rendimiento. Después de todo, en estos días, incluso el CDN tiene que “evitar que los compañeros de equipo” - elegir el proveedor equivocado, compañeros de equipo en el enemigo es el más terrible.
