Ce jour-l\u00e0, \u00e0 trois heures du matin, j'ai \u00e9t\u00e9 r\u00e9veill\u00e9 par un message textuel d'alarme continu - la courbe du trafic d'affaires en direct a soudainement grimp\u00e9 en fl\u00e8che, le flux RTMP push chute constamment, l'arri\u00e8re-plan montre qu'une certaine IP dans l'envoi fou d'un monstrueux en-t\u00eate de paquet FLV. Oh, ce sont mes pairs qui cherchent la bagarre.<\/p>\n
J'ai regard\u00e9 la carte de surveillance et j'ai eu une id\u00e9e : de nos jours, pour diffuser des \u00e9missions en direct, il n'y a pas de support de protocole RTMP pour le CDN haute-d\u00e9fense, ce qui \u00e9quivaut \u00e0 courir tout nu. Mais les fournisseurs de services sur le march\u00e9 sous la banni\u00e8re du \u201csoutien complet\u201d peuvent-ils vraiment r\u00e9sister aux attaques personnalis\u00e9es des bandes de chantage ?<\/p>\n
Le protocole RTMP est l'art\u00e8re invisible de la diffusion en direct.<\/strong><\/p>\n Nombreux sont ceux qui pensent que HTTP-FLV et HLS ont r\u00e9gn\u00e9 sur l'espace de diffusion en direct, mais lorsqu'il s'agit de diffuser des flux en mode push, RTMP reste le premier choix de la plupart des fournisseurs d'encodeurs. Pourquoi ? Faible latence, longue connexion, compatibilit\u00e9 avec l'\u00e9cosyst\u00e8me Adobe de ces avantages clich\u00e9s, sans oublier que la cl\u00e9 est qu'il est comme un vaisseau sanguin aussi profond que la cha\u00eene d'outils de production - OBS, FFmpeg, Wirecast qui n'est pas la sortie RTMP par d\u00e9faut ? J'ai constat\u00e9 que l'utilisation de RTMP pour pousser le flux plut\u00f4t que le protocole SRT pour \u00e9conomiser au moins 30% de l'utilisation du processeur, ce qui n\u00e9cessite un long temps pour accrocher les activit\u00e9s en direct est tout simplement une fonctionnalit\u00e9 salvatrice.<\/p>\n Mais voici le probl\u00e8me : les longues connexions de RTMP bas\u00e9es sur le protocole TCP en font une cible parfaite pour les attaques DDoS. Les attaquants peuvent facilement \u00e9puiser les ressources du serveur en simulant un flux de donn\u00e9es normal pour \u00e9tablir une connexion, puis en envoyant lentement des donn\u00e9es inutiles. L'ann\u00e9e derni\u00e8re, une plateforme de diffusion de jeux vid\u00e9o est rest\u00e9e bloqu\u00e9e pendant 12 heures parce que le service RTMP avait \u00e9t\u00e9 perc\u00e9 par une attaque lente.<\/p>\n Les CDN \u00e0 haute d\u00e9fense ne sont pas \u00e0 toute \u00e9preuve<\/strong><\/p>\n Ne croyez pas les \u201cprotections illimit\u00e9es\u201d de la documentation promotionnelle. J'ai pris trois fournisseurs de services grand public pour faire le test : la protection RTMP de CDN5 est vraiment excellente, mais le prix est suffisant pour acheter une voiture de sport d'entr\u00e9e de gamme ; le n\u0153ud de nettoyage CDN07 tue souvent par erreur des paquets de streaming media normaux ; 08Host est bon march\u00e9, mais les attaques CC remontent directement \u00e0 la source - de la m\u00eame mani\u00e8re que l'attaque a conduit au serveur du client.<\/p>\n Un CDN haute d\u00e9fense vraiment fiable doit \u00eatre comme un couteau suisse : la prise en charge du protocole RTMP est la lame la plus \u00e9l\u00e9mentaire, et il doit \u00e9galement y avoir des capteurs qui identifient avec pr\u00e9cision le trafic anormal. Par exemple, s'il d\u00e9tecte qu'un certain flux push ID \u00e9tablit des centaines de connexions en l'espace de 10 secondes, il doit automatiquement d\u00e9clencher une v\u00e9rification humaine au lieu de simplement bloquer l'IP.<\/p>\n Regardez la strat\u00e9gie de protection dans la configuration actuelle (bas\u00e9e sur le module NGINX) :<\/p>\n Cet ensemble de r\u00e8gles m'a permis de bloquer au moins trois attaques de type \"zero-day\". Dans l'une d'entre elles, l'attaquant a tent\u00e9 d'envoyer un paquet onMetadata falsifi\u00e9, ce qui a entra\u00een\u00e9 le plantage de l'analyseur du serveur, gr\u00e2ce aux r\u00e8gles du WAF qui ont d\u00e9tect\u00e9 \u00e0 l'avance le champ anormal.<\/p>\n L'assistance de l'accord, c'est tout ce qu'il faut<\/strong><\/p>\n Revenons maintenant au sujet principal : les CDN haute d\u00e9fense en direct prennent en charge le RTMP ou non ? La r\u00e9ponse est que les principaux fournisseurs de services sont pris en charge, mais que la qualit\u00e9 de la prise en charge varie consid\u00e9rablement. J'ai compil\u00e9 un tableau comparatif (donn\u00e9es du deuxi\u00e8me trimestre 2024) :<\/p>\n CDN5 : RTMP push flow delay <800ms, support TLS encrypted transmission, protection threshold can be dynamically adjusted, but custom rules require work order application - suitable for tycoon companies.<\/p>\n CDN07 : large couverture de n\u0153uds, performances \u00e9tonnantes en mati\u00e8re de latence en Asie du Sud-Est, mais en cas d'attaque SYN Flood, il sera contraint de changer de protocole, ce qui peut entra\u00eener une interruption du flux de donn\u00e9es - adapt\u00e9 aux activit\u00e9s \u00e0 l'\u00e9tranger.<\/p>\n 08Host : bon march\u00e9 est vraiment bon march\u00e9, 1T paquet de protection du trafic est seulement quelques centaines de dollars, mais la r\u00e9ponse du support technique est lente, le milieu de la nuit a \u00e9t\u00e9 frapp\u00e9 peut seulement \u00e9crire leurs propres scripts \u00e0 transporter - adapt\u00e9 pour les capacit\u00e9s d'auto-recherche de la petite \u00e9quipe.<\/p>\n C'est la fosse cach\u00e9e qui tue.<\/strong><\/p>\n L'ann\u00e9e derni\u00e8re, pour aider une plate-forme de commerce \u00e9lectronique \u00e0 effectuer une attaque de diffusion en direct et un exercice de d\u00e9fense, nous avons d\u00e9couvert un ph\u00e9nom\u00e8ne \u00e9trange : bien que la cl\u00e9 d'authentification RTMP soit configur\u00e9e, l'attaquant peut toujours falsifier l'adresse du flux de pouss\u00e9e. Enfin, en squattant Wireshark pendant une demi-nuit, on a d\u00e9couvert que les fournisseurs de CDN, pour \u00eatre compatibles avec l'ancienne version de l'encodeur, g\u00e9n\u00e8rent par d\u00e9faut pour chaque flux une URL alternative non sign\u00e9e - cette porte d\u00e9rob\u00e9e est tout simplement un cadeau de No\u00ebl personnalis\u00e9 pour l'auteur de l'attaque.<\/p>\n Il y a maintenant trois choses que mon \u00e9quipe doit faire avant de d\u00e9ployer des services RTMP :<\/p>\n 1) D\u00e9tection de la pr\u00e9cision de l'interception des CDN en simulant des flux push malveillants \u00e0 l'aide de l'outil ffprobe<\/p>\n 2) V\u00e9rifier la console pour les commutateurs de compatibilit\u00e9 de protocole cach\u00e9s<\/p>\n 3. exiger des vendeurs qu'ils fournissent des rapports sur la protection contre les attaques visant les protocoles RTMP au cours des trois derniers mois.<\/p>\n D'ailleurs, partageons un cas r\u00e9el : avant un grand \u00e9v\u00e9nement, nous avons soudainement remarqu\u00e9 un d\u00e9calage p\u00e9riodique du c\u00f4t\u00e9 du flux push. Apr\u00e8s avoir captur\u00e9 des paquets, nous avons d\u00e9couvert que le pare-feu du n\u0153ud CDN rejetait sans discernement les paquets RTMP contenant des horodatages sp\u00e9cifiques - la raison en est que le fournisseur a ajout\u00e9 par erreur une certaine plage d'horodatages normaux \u00e0 la liste noire. Ce type de probl\u00e8me ne peut \u00eatre d\u00e9tect\u00e9 sans un test de r\u00e9sistance.<\/p>\n Le futur champ de bataille se situe au niveau du protocole<\/strong><\/p>\n Aujourd'hui, le march\u00e9 noir a trouv\u00e9 une nouvelle astuce : les attaques par manipulation de la qualit\u00e9 de service en analysant le param\u00e8tre de la taille de la fen\u00eatre lors de la poign\u00e9e de main RTMP. En termes simples, il s'agit de d\u00e9clarer d\u00e9lib\u00e9r\u00e9ment une fen\u00eatre de r\u00e9ception tr\u00e8s petite, de sorte que le serveur r\u00e9duise le taux d'envoi pour cr\u00e9er un d\u00e9calage. Pour se d\u00e9fendre contre cette attaque, il faut d\u00e9ployer des moteurs d'analyse du comportement des protocoles dans les n\u0153uds de p\u00e9riph\u00e9rie des CDN, et les \u00e9quipements de nettoyage du trafic ne suffisent plus.<\/p>\n La solution que j'ai test\u00e9e derni\u00e8rement consiste \u00e0 injecter des filigranes num\u00e9riques au stade de l'authentification du flux pouss\u00e9 :<\/p>\n Ce syst\u00e8me permet \u00e0 chaque flux vid\u00e9o de porter une signature unique, qui peut \u00eatre rapidement retrac\u00e9e jusqu'\u00e0 l'extr\u00e9mit\u00e9 de diffusion sp\u00e9cifique en cas de vol de flux ou d'attaque - ce qui \u00e9quivaut \u00e0 un sceau d'acier invisible pour chaque paquet.<\/p>\n Choisir des conseils pour \u00eatre honn\u00eate<\/strong><\/p>\n Si vous \u00eates en train de choisir un mod\u00e8le, rappelez-vous ces trois le\u00e7ons sanglantes :<\/p>\n 1) Ne vous laissez pas abuser par la propagande \u201cRTMP full support\u201d, testez toujours la compatibilit\u00e9 du protocole et le lien de protection.<\/p>\n 2) Demander au fournisseur s'il prend en charge la transmission crypt\u00e9e des RTMPS, les flux de pouss\u00e9e transmis en texte clair \u00e9tant les m\u00eames que ceux qui sont ex\u00e9cut\u00e9s nus.<\/p>\n 3. v\u00e9rifiez si la console peut personnaliser les r\u00e8gles de protection pour RTMP, par exemple en d\u00e9finissant des seuils de d\u00e9bit de paquets sp\u00e9cifiques.<\/p>\n Une derni\u00e8re note d'humour noir : j'ai d\u00e9couvert un jour que la console d'un fournisseur pouvait en fait exporter les journaux de protection vers une feuille de calcul Excel - mais qui analyse \u00e0 l'\u0153il nu les donn\u00e9es d'une feuille de calcul lorsque deux heures se sont \u00e9coul\u00e9es depuis l'attaque ? C'est comme remettre un manuel d'utilisation \u00e0 un homme qui se noie.<\/p>\n Un tr\u00e8s bon syst\u00e8me de protection doit \u00eatre automatis\u00e9. Par exemple, le syst\u00e8me de planification intelligent du CDN5 peut automatiquement transmettre les flux RTMP \u00e0 des groupes de nettoyage cach\u00e9s apr\u00e8s avoir identifi\u00e9 le mod\u00e8le d'attaque, et l'ensemble du processus est imperceptible au niveau du flux de pouss\u00e9e. Cette id\u00e9e de conception constitue l'orientation future.<\/p>\n Apr\u00e8s huit ann\u00e9es pass\u00e9es dans le secteur de la diffusion en direct, j'ai de plus en plus le sentiment que la technologie n'est que le cadre de base, le v\u00e9ritable foss\u00e9 \u00e9tant constitu\u00e9 par les \u201cdonn\u00e9es sales\u201d accumul\u00e9es au cours du processus de confrontation. Savoir quel type de paquets malform\u00e9s fera planter quel type d'encodeur, savoir quels segments IP d'une r\u00e9gion sont susceptibles de lancer des attaques sp\u00e9cifiques - ces exp\u00e9riences sont les actifs essentiels qui ne peuvent pas \u00eatre achet\u00e9s avec de l'argent.<\/p>\n Revenons donc \u00e0 la question initiale : un CDN de haute d\u00e9fense en direct prend-il en charge le RTMP ? Le support, mais qui peut vous permettre de dormir sur vos deux oreilles, d\u00e9pend du fournisseur cach\u00e9 derri\u00e8re la liste des caract\u00e9ristiques de la capacit\u00e9 de combat r\u00e9elle. La prochaine fois que vous rendrez visite \u00e0 un fournisseur de services, vous voudrez peut-\u00eatre lui demander directement : \u201cSi quelqu'un frappe mon flux push avec une variante d'attaque RTMP lente, quelle couche de votre m\u00e9canisme de d\u00e9fense sera la premi\u00e8re \u00e0 r\u00e9agir ? -- La r\u00e9ponse pourrait vous donner des sueurs froides.<\/p>","protected":false},"excerpt":{"rendered":" Ce jour-l\u00e0, \u00e0 trois heures du matin, j'ai \u00e9t\u00e9 r\u00e9veill\u00e9 par un message texte d'alarme continu - la courbe du trafic d'affaires en direct a soudainement grimp\u00e9 en fl\u00e8che, le flux RTMP push chute constamment, l'arri\u00e8re-plan montre qu'une certaine IP dans l'envoi fou d'un monstrueux en-t\u00eate de paquet FLV. Eh bien, ce sont les pairs qui cherchent les ennuis. J'ai regard\u00e9 la carte de surveillance et j'ai eu une id\u00e9e : de nos jours, les diffusions en direct, sans un CDN de haute d\u00e9fense avec le support du protocole RTMP est \u00e9gal \u00e0 courir nu. Mais sur le march\u00e9, sous la banni\u00e8re des fournisseurs de services \u201cfull support\u201d, peuvent-ils vraiment r\u00e9sister aux gangs noirs des coups personnalis\u00e9s ? Le protocole RTMP est l'art\u00e8re invisible dans le domaine de la diffusion en direct Beaucoup de gens pensent que HTTP-FLV et HLS ont r\u00e9gn\u00e9 sur le domaine de la diffusion en direct, mais en r\u00e9alit\u00e9, en poussant la transmission de flux, RTMP reste le premier choix de la plupart des fournisseurs d'encodeurs. Pourquoi ? Faible latence, longue connectivit\u00e9<\/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\/fr\/wp-json\/wp\/v2\/posts\/1035","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/comments?post=1035"}],"version-history":[{"count":1,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/1035\/revisions"}],"predecessor-version":[{"id":1090,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/1035\/revisions\/1090"}],"wp:attachment":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/media?parent=1035"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/categories?post=1035"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/tags?post=1035"},{"taxonomy":"collection","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/collection?post=1035"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}