A las tres de la ma\u00f1ana de ese d\u00eda, me despert\u00f3 un mensaje de texto de alarma continua - curva de tr\u00e1fico de negocios en vivo de repente se dispar\u00f3 en un poste, RTMP flujo de empuje constantemente ca\u00eddo, el fondo muestra que una determinada IP en el env\u00edo loco monstruoso encabezado del paquete FLV. Oh, son mis compa\u00f1eros que est\u00e1n buscando pelea.<\/p>\n
Lanzado al amanecer finalmente suprimi\u00f3 el ataque, me qued\u00e9 mirando el mapa de seguimiento se acerc\u00f3 con un pensamiento: en estos d\u00edas para participar en las transmisiones en vivo, no hay soporte de protocolo RTMP para CDN de alta defensa es igual a correr desnudo. Pero los proveedores de servicios en el mercado bajo la bandera de \u201capoyo total\u201d realmente puede soportar los ataques personalizados de las bandas de chantaje?<\/p>\n
El protocolo RTMP es la arteria invisible del streaming en directo<\/strong><\/p>\n Mucha gente piensa que HTTP-FLV y HLS han dominado el espacio de la retransmisi\u00f3n en directo, pero cuando se trata de hacer realmente la entrega de flujo push, RTMP sigue siendo la primera opci\u00f3n para la mayor\u00eda de los proveedores de codificadores. \u00bfPor qu\u00e9? Baja latencia, larga conexi\u00f3n, compatibilidad con el ecosistema de Adobe de estas ventajas clich\u00e9 por no hablar, la clave es que es como un vaso sangu\u00edneo tan profundo como la cadena de herramientas de producci\u00f3n - OBS, FFmpeg, Wirecast que no es el valor por defecto ir RTMP salida? He encontrado que el uso de RTMP para empujar el flujo que el protocolo SRT para ahorrar al menos 30% de uso de la CPU, que requiere mucho tiempo para colgar las actividades en vivo es simplemente una caracter\u00edstica que salva vidas.<\/p>\n Pero aqu\u00ed est\u00e1 el problema: las largas conexiones basadas en TCP de RTMP lo convierten en un objetivo perfecto para los ataques DDoS. Los atacantes pueden agotar f\u00e1cilmente los recursos del servidor simulando un flujo push normal para establecer una conexi\u00f3n y luego enviar lentamente datos basura. El a\u00f1o pasado, una plataforma de difusi\u00f3n de juegos se colaps\u00f3 durante 12 horas porque el servicio RTMP fue perforado por un ataque lento.<\/p>\n Las CDN de alta defensa no son blindadas<\/strong><\/p>\n No se crea esas \u201cprotecciones ilimitadas\u201d de la literatura promocional. Tom\u00e9 tres principales proveedores de servicios para hacer la prueba: CDN5 protecci\u00f3n RTMP es realmente grande, pero el precio es suficiente para comprar un coche deportivo de nivel de entrada; CDN07 nodo de limpieza a menudo por error matar a los paquetes normales de streaming de medios de comunicaci\u00f3n; 08Host es barato, pero los ataques CC directamente de vuelta a la fuente - el mismo que el ataque llev\u00f3 al servidor del cliente.<\/p>\n Una CDN de alta defensa verdaderamente fiable deber\u00eda ser como una navaja suiza: la compatibilidad con el protocolo RTMP es la cuchilla m\u00e1s b\u00e1sica, y tambi\u00e9n deber\u00eda haber sensores que identifiquen con precisi\u00f3n el tr\u00e1fico an\u00f3malo. Por ejemplo, si detecta que un determinado ID de flujo push establece cientos de conexiones en 10 segundos, deber\u00eda activar autom\u00e1ticamente la verificaci\u00f3n humana en lugar de limitarse a bloquear la IP.<\/p>\n Mire la estrategia de protecci\u00f3n en la configuraci\u00f3n real (basada en el m\u00f3dulo NGINX):<\/p>\n Este conjunto de reglas me ha ayudado a bloquear al menos tres ataques de d\u00eda cero. En uno de ellos, el atacante intent\u00f3 enviar un paquete onMetadata manipulado que provoc\u00f3 el bloqueo del analizador del servidor, gracias a que las reglas WAF detectaron el campo an\u00f3malo de antemano.<\/p>\n El apoyo a los acuerdos es la soluci\u00f3n<\/strong><\/p>\n Ahora volvamos al tema principal: \u00bflas CDN de alta defensa en directo soportan RTMP o no? La respuesta es que los principales proveedores de servicios s\u00ed lo soportan, pero la calidad del soporte var\u00eda mucho. He compilado una tabla comparativa (datos de Q2 2024):<\/p>\n CDN5: RTMP push flow delay <800ms, soporta transmisi\u00f3n encriptada TLS, el umbral de protecci\u00f3n se puede ajustar din\u00e1micamente, pero las reglas personalizadas requieren solicitud de orden de trabajo - adecuado para empresas magnates.<\/p>\n CDN07: Amplia cobertura de nodos, rendimiento de latencia asombroso en el sudeste asi\u00e1tico, pero cuando se encuentre con un ataque SYN Flood, se ver\u00e1 obligado a cambiar de protocolo, lo que puede causar la interrupci\u00f3n del flujo push - adecuado para negocios en el extranjero.<\/p>\n 08Host: barato es realmente barato, 1T paquete de protecci\u00f3n del tr\u00e1fico es s\u00f3lo unos pocos cientos de d\u00f3lares, pero la respuesta de soporte t\u00e9cnico es lento, la mitad de la noche fue golpeado s\u00f3lo puede escribir sus propios scripts para llevar - adecuado para la auto-investigaci\u00f3n de las capacidades del peque\u00f1o equipo.<\/p>\n Es el pozo oculto lo que mata.<\/strong><\/p>\n El a\u00f1o pasado para ayudar a una plataforma de comercio electr\u00f3nico para hacer ataque de transmisi\u00f3n en vivo y defensa de perforaci\u00f3n encontr\u00f3 un fen\u00f3meno extra\u00f1o: obviamente configurado clave de autenticaci\u00f3n RTMP, el atacante todav\u00eda puede falsificar la direcci\u00f3n de flujo de empuje. Por \u00faltimo, en Wireshark en cuclillas durante media noche s\u00f3lo para encontrar que los proveedores de CDN con el fin de ser compatible con la versi\u00f3n antigua del codificador, el valor predeterminado para cada flujo de generar una URL alternativa sin firmar - esta puerta trasera es simplemente un regalo de Navidad personalizado para el atacante.<\/p>\n Ahora hay tres cosas que mi equipo debe hacer antes de desplegar servicios RTMP:<\/p>\n 1. Detecci\u00f3n de la precisi\u00f3n de la interceptaci\u00f3n de CDN mediante la simulaci\u00f3n de flujos push maliciosos con la herramienta ffprobe<\/p>\n 2. Compruebe en la consola si hay interruptores ocultos de compatibilidad de protocolos<\/p>\n 3. Exigir a los proveedores que faciliten informes de protecci\u00f3n contra ataques a protocolos RTMP de los \u00faltimos tres meses.<\/p>\n Por cierto, compartamos un caso real: antes de un gran evento, de repente notamos un retraso peri\u00f3dico en el lado del flujo push. Despu\u00e9s de capturar los paquetes, descubrimos que el cortafuegos del nodo CDN rechazaba indiscriminadamente paquetes RTMP que conten\u00edan marcas de tiempo espec\u00edficas; la raz\u00f3n era que el proveedor hab\u00eda a\u00f1adido por error un cierto rango de marcas de tiempo normales a la lista negra. Este tipo de problema no puede detectarse sin una prueba de estr\u00e9s.<\/p>\n El futuro campo de batalla est\u00e1 en la capa de protocolo<\/strong><\/p>\n Ahora el mercado negro ha ideado un nuevo truco: los ataques de manipulaci\u00f3n de la calidad de servicio mediante el an\u00e1lisis del par\u00e1metro del tama\u00f1o de la ventana durante el handshake RTMP. En pocas palabras, se trata de declarar deliberadamente una ventana de recepci\u00f3n muy peque\u00f1a, de forma que el servidor reduzca la velocidad de env\u00edo para crear retardo. Defenderse de este ataque requiere el despliegue de motores de an\u00e1lisis del comportamiento del protocolo en los nodos de borde de las CDN, y los equipos de limpieza del tr\u00e1fico por s\u00ed solos ya no son suficientes.<\/p>\n La soluci\u00f3n que he estado probando \u00faltimamente consiste en inyectar marcas de agua digitales en la fase de autenticaci\u00f3n del flujo push:<\/p>\n Este sistema permite que cada flujo de v\u00eddeo lleve una firma \u00fanica, que puede rastrearse r\u00e1pidamente hasta el extremo de transmisi\u00f3n espec\u00edfico en caso de robo o ataque del flujo, lo que equivale a un sello de acero invisible para cada paquete.<\/p>\n Elegir un consejo para ser honesto<\/strong><\/p>\n Si est\u00e1s en proceso de seleccionar un modelo, recuerda estas tres lecciones sangrantes:<\/p>\n 1. No se deje enga\u00f1ar por la propaganda de \u201ccompatibilidad total con RTMP\u201d, compruebe siempre la compatibilidad del protocolo y la vinculaci\u00f3n de la protecci\u00f3n.<\/p>\n 2. Pregunte al proveedor si admite la transmisi\u00f3n cifrada RTMPS, los flujos push transmitidos en texto claro son lo mismo que ejecutar desnudos.<\/p>\n 3. Compruebe si la consola puede personalizar las reglas de protecci\u00f3n para RTMP, como establecer umbrales espec\u00edficos de velocidad de paquetes.<\/p>\n Una \u00faltima nota de humor negro: una vez descubr\u00ed que la consola de un proveedor pod\u00eda exportar los registros de protecci\u00f3n a una hoja de c\u00e1lculo Excel, pero \u00bfqui\u00e9n analiza a simple vista los datos de una hoja de c\u00e1lculo cuando han pasado dos horas desde el ataque? Es como entregar un manual de usuario a un hombre que se est\u00e1 ahogando.<\/p>\n Un sistema de protecci\u00f3n realmente bueno debe estar automatizado. Por ejemplo, el sistema de programaci\u00f3n inteligente de CDN5 puede reenviar autom\u00e1ticamente flujos RTMP a clusters de limpieza ocultos tras identificar el patr\u00f3n de ataque, y todo el proceso es imperceptible en el extremo del flujo push. Esta idea de dise\u00f1o es la direcci\u00f3n futura.<\/p>\n Despu\u00e9s de ocho a\u00f1os en el negocio de la retransmisi\u00f3n en directo, cada vez tengo m\u00e1s la sensaci\u00f3n de que la tecnolog\u00eda es s\u00f3lo el marco b\u00e1sico, el verdadero foso son los \u201cdatos sucios\u201d acumulados en el proceso de confrontaci\u00f3n. Saber qu\u00e9 tipo de paquetes malformados har\u00e1 que se bloquee qu\u00e9 tipo de codificador, conocer qu\u00e9 segmentos IP de una regi\u00f3n son propensos a lanzar ataques espec\u00edficos... estas experiencias son los activos fundamentales que no se pueden comprar con dinero.<\/p>\n As\u00ed que volvamos a la pregunta inicial: \u00bfsoporta RTMP una CDN de alta defensa en directo? Soporta, pero puede dejarte dormir tranquilo, dependiendo del proveedor oculto tras la lista de caracter\u00edsticas de la capacidad de combate real. La pr\u00f3xima vez que visite a un proveedor de servicios, puede preguntarle directamente: \u201cSi alguien ataca ahora mi flujo push con una variante de ataque RTMP lento, \u00bfqu\u00e9 capa de su mecanismo de defensa ser\u00e1 la primera en responder?\u201d. -- La respuesta puede hacerte sudar fr\u00edo.<\/p>","protected":false},"excerpt":{"rendered":" A las tres de la ma\u00f1ana de ese d\u00eda, me despert\u00f3 un mensaje de texto de alarma continua - curva de tr\u00e1fico de negocios en vivo de repente se dispar\u00f3 en un poste, RTMP flujo de empuje constantemente ca\u00eddo, el fondo muestra que una determinada IP en el env\u00edo loco monstruoso encabezado del paquete FLV. Bueno, son los compa\u00f1eros que est\u00e1n buscando problemas. Lanzado al amanecer finalmente suprimi\u00f3 el ataque, me qued\u00e9 mirando el mapa de monitoreo se le ocurri\u00f3 una idea: en estos d\u00edas se dedican a las transmisiones en vivo, sin una alta defensa CDN con soporte de protocolo RTMP es igual a correr desnudo. Pero en el mercado, bajo la bandera de proveedores de servicios de \u201csoporte completo\u201d, \u00bfpueden realmente resistir las bandas negras del golpe personalizado? El protocolo RTMP es la arteria invisible en el campo de la retransmisi\u00f3n en directo Mucha gente piensa que HTTP-FLV y HLS han dominado el campo de la retransmisi\u00f3n en directo, pero realmente empujan la transmisi\u00f3n de flujo, RTMP sigue siendo la primera opci\u00f3n de la mayor\u00eda de los vendedores de codificadores. \u00bfPor qu\u00e9? Baja latencia, larga conectividad<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"gallery","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","footnotes":""},"categories":[150],"tags":[],"collection":[],"class_list":["post-1035","post","type-post","status-publish","format-gallery","hentry","category-updates","post_format-post-format-gallery"],"_links":{"self":[{"href":"https:\/\/www.ddosgj.com\/es\/wp-json\/wp\/v2\/posts\/1035","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ddosgj.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ddosgj.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ddosgj.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ddosgj.com\/es\/wp-json\/wp\/v2\/comments?post=1035"}],"version-history":[{"count":1,"href":"https:\/\/www.ddosgj.com\/es\/wp-json\/wp\/v2\/posts\/1035\/revisions"}],"predecessor-version":[{"id":1090,"href":"https:\/\/www.ddosgj.com\/es\/wp-json\/wp\/v2\/posts\/1035\/revisions\/1090"}],"wp:attachment":[{"href":"https:\/\/www.ddosgj.com\/es\/wp-json\/wp\/v2\/media?parent=1035"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ddosgj.com\/es\/wp-json\/wp\/v2\/categories?post=1035"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ddosgj.com\/es\/wp-json\/wp\/v2\/tags?post=1035"},{"taxonomy":"collection","embeddable":true,"href":"https:\/\/www.ddosgj.com\/es\/wp-json\/wp\/v2\/collection?post=1035"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}