Ce jour-là, à trois heures du matin, j'ai été réveillé par un message textuel d'alarme continu - la courbe du trafic d'affaires en direct a soudainement grimpé en flèche, le flux RTMP push chute constamment, l'arrière-plan montre qu'une certaine IP dans l'envoi fou d'un monstrueux en-tête de paquet FLV. Oh, ce sont mes pairs qui cherchent la bagarre.
J'ai regardé la carte de surveillance et j'ai eu une idée : de nos jours, pour diffuser des émissions en direct, il n'y a pas de support de protocole RTMP pour le CDN haute-défense, ce qui équivaut à courir tout nu. Mais les fournisseurs de services sur le marché sous la bannière du “soutien complet” peuvent-ils vraiment résister aux attaques personnalisées des bandes de chantage ?
Le protocole RTMP est l'artère invisible de la diffusion en direct.
Nombreux sont ceux qui pensent que HTTP-FLV et HLS ont régné 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é avec l'écosystème Adobe de ces avantages clichés, sans oublier que la clé est qu'il est comme un vaisseau sanguin aussi profond que la chaîne d'outils de production - OBS, FFmpeg, Wirecast qui n'est pas la sortie RTMP par défaut ? J'ai constaté que l'utilisation de RTMP pour pousser le flux plutôt que le protocole SRT pour économiser au moins 30% de l'utilisation du processeur, ce qui nécessite un long temps pour accrocher les activités en direct est tout simplement une fonctionnalité salvatrice.
Mais voici le problème : les longues connexions de RTMP basées sur le protocole TCP en font une cible parfaite pour les attaques DDoS. Les attaquants peuvent facilement épuiser les ressources du serveur en simulant un flux de données normal pour établir une connexion, puis en envoyant lentement des données inutiles. L'année dernière, une plateforme de diffusion de jeux vidéo est restée bloquée pendant 12 heures parce que le service RTMP avait été percé par une attaque lente.
Les CDN à haute défense ne sont pas à toute épreuve
Ne croyez pas les “protections illimitées” 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ée de gamme ; le nœud de nettoyage CDN07 tue souvent par erreur des paquets de streaming media normaux ; 08Host est bon marché, mais les attaques CC remontent directement à la source - de la même manière que l'attaque a conduit au serveur du client.
Un CDN haute défense vraiment fiable doit être comme un couteau suisse : la prise en charge du protocole RTMP est la lame la plus élémentaire, et il doit également y avoir des capteurs qui identifient avec précision le trafic anormal. Par exemple, s'il détecte qu'un certain flux push ID établit des centaines de connexions en l'espace de 10 secondes, il doit automatiquement déclencher une vérification humaine au lieu de simplement bloquer l'IP.
Regardez la stratégie de protection dans la configuration actuelle (basée sur le module NGINX) :
Cet ensemble de règles m'a permis de bloquer au moins trois attaques de type "zero-day". Dans l'une d'entre elles, l'attaquant a tenté d'envoyer un paquet onMetadata falsifié, ce qui a entraîné le plantage de l'analyseur du serveur, grâce aux règles du WAF qui ont détecté à l'avance le champ anormal.
L'assistance de l'accord, c'est tout ce qu'il faut
Revenons maintenant au sujet principal : les CDN haute défense en direct prennent en charge le RTMP ou non ? La réponse est que les principaux fournisseurs de services sont pris en charge, mais que la qualité de la prise en charge varie considérablement. J'ai compilé un tableau comparatif (données du deuxième trimestre 2024) :
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.
CDN07 : large couverture de nœuds, performances étonnantes en matière 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îner une interruption du flux de données - adapté aux activités à l'étranger.
08Host : bon marché est vraiment bon marché, 1T paquet de protection du trafic est seulement quelques centaines de dollars, mais la réponse du support technique est lente, le milieu de la nuit a été frappé peut seulement écrire leurs propres scripts à transporter - adapté pour les capacités d'auto-recherche de la petite équipe.
C'est la fosse cachée qui tue.
L'année dernière, pour aider une plate-forme de commerce électronique à effectuer une attaque de diffusion en direct et un exercice de défense, nous avons découvert un phénomène étrange : bien que la clé d'authentification RTMP soit configurée, l'attaquant peut toujours falsifier l'adresse du flux de poussée. Enfin, en squattant Wireshark pendant une demi-nuit, on a découvert que les fournisseurs de CDN, pour être compatibles avec l'ancienne version de l'encodeur, génèrent par défaut pour chaque flux une URL alternative non signée - cette porte dérobée est tout simplement un cadeau de Noël personnalisé pour l'auteur de l'attaque.
Il y a maintenant trois choses que mon équipe doit faire avant de déployer des services RTMP :
1) Détection de la précision de l'interception des CDN en simulant des flux push malveillants à l'aide de l'outil ffprobe
2) Vérifier la console pour les commutateurs de compatibilité de protocole cachés
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.
D'ailleurs, partageons un cas réel : avant un grand événement, nous avons soudainement remarqué un décalage périodique du côté du flux push. Après avoir capturé des paquets, nous avons découvert que le pare-feu du nœud CDN rejetait sans discernement les paquets RTMP contenant des horodatages spécifiques - la raison en est que le fournisseur a ajouté par erreur une certaine plage d'horodatages normaux à la liste noire. Ce type de problème ne peut être détecté sans un test de résistance.
Le futur champ de bataille se situe au niveau du protocole
Aujourd'hui, le marché noir a trouvé une nouvelle astuce : les attaques par manipulation de la qualité de service en analysant le paramètre de la taille de la fenêtre lors de la poignée de main RTMP. En termes simples, il s'agit de déclarer délibérément une fenêtre de réception très petite, de sorte que le serveur réduise le taux d'envoi pour créer un décalage. Pour se défendre contre cette attaque, il faut déployer des moteurs d'analyse du comportement des protocoles dans les nœuds de périphérie des CDN, et les équipements de nettoyage du trafic ne suffisent plus.
La solution que j'ai testée dernièrement consiste à injecter des filigranes numériques au stade de l'authentification du flux poussé :
Ce système permet à chaque flux vidéo de porter une signature unique, qui peut être rapidement retracée jusqu'à l'extrémité de diffusion spécifique en cas de vol de flux ou d'attaque - ce qui équivaut à un sceau d'acier invisible pour chaque paquet.
Choisir des conseils pour être honnête
Si vous êtes en train de choisir un modèle, rappelez-vous ces trois leçons sanglantes :
1) Ne vous laissez pas abuser par la propagande “RTMP full support”, testez toujours la compatibilité du protocole et le lien de protection.
2) Demander au fournisseur s'il prend en charge la transmission cryptée des RTMPS, les flux de poussée transmis en texte clair étant les mêmes que ceux qui sont exécutés nus.
3. vérifiez si la console peut personnaliser les règles de protection pour RTMP, par exemple en définissant des seuils de débit de paquets spécifiques.
Une dernière note d'humour noir : j'ai découvert 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 à l'œil nu les données d'une feuille de calcul lorsque deux heures se sont écoulées depuis l'attaque ? C'est comme remettre un manuel d'utilisation à un homme qui se noie.
Un très bon système de protection doit être automatisé. Par exemple, le système de planification intelligent du CDN5 peut automatiquement transmettre les flux RTMP à des groupes de nettoyage cachés après avoir identifié le modèle d'attaque, et l'ensemble du processus est imperceptible au niveau du flux de poussée. Cette idée de conception constitue l'orientation future.
Après huit années passées 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éritable fossé étant constitué par les “données sales” accumulées au cours du processus de confrontation. Savoir quel type de paquets malformés fera planter quel type d'encodeur, savoir quels segments IP d'une région sont susceptibles de lancer des attaques spécifiques - ces expériences sont les actifs essentiels qui ne peuvent pas être achetés avec de l'argent.
Revenons donc à la question initiale : un CDN de haute défense en direct prend-il en charge le RTMP ? Le support, mais qui peut vous permettre de dormir sur vos deux oreilles, dépend du fournisseur caché derrière la liste des caractéristiques de la capacité de combat réelle. La prochaine fois que vous rendrez visite à un fournisseur de services, vous voudrez peut-être lui demander directement : “Si quelqu'un frappe mon flux push avec une variante d'attaque RTMP lente, quelle couche de votre mécanisme de défense sera la première à réagir ? -- La réponse pourrait vous donner des sueurs froides.
