Récemment, j'ai aidé un ami à gérer un projet qui a été touché par un DDoS et je n'ai pas pu m'occuper de moi-même. Je me suis donc souvenu de lui demander : “Utilisez-vous un CDN qui n'a pas une défense élevée ?”. Du coup, ce pote m'a répondu avec un visage confus : “Peux-tu choisir un protocole pour un CDN à haute défense ? Ne pas donner un nom de domaine à raccrocher à la fin de l'affaire ?” J'ai failli écraser le clavier sur place - de nos jours, il y a encore des gens qui pensent que les CDN ne servent qu'à l'accélération, et que la défense et la prise en charge du protocole ne sont que de la poudre aux yeux ?
Honnêtement, la question du support du protocole n'est pas métaphysique. J'ai vu trop de gens acheter un service de haute défense, le résultat est que le protocole n'est pas apparié, a été percé après que les vendeurs ont également grondé des déchets. En fait, le problème est que vous ne comprenez pas les scénarios d'entreprise : vous poussez le streaming en direct avec RTMP, vous faites de la communication en temps réel avec WebSocket, les sites web ordinaires avec HTTPS, différents protocoles pour aller au port et au cryptage sont complètement différents. Si les fournisseurs de CDN vous aident uniquement à empêcher les ports 80/443, les autres protocoles ne passent tout simplement pas par le nœud de nettoyage, et quelle est la différence entre l'exécution nue ?
Prenons d'abord HTTPS, qui est le plus élémentaire. Mais la prise en charge du HTTPS par un CDN haute défense et un CDN ordinaire sont deux choses différentes. Un CDN ordinaire peut simplement vous aider à mettre en place un point de terminaison SSL, alors qu'un CDN à haute défense doit être impliqué dans l'ensemble du processus de protection de la poignée de main TLS. J'ai testé les services de CDN5, ils peuvent même identifier des paquets anormaux dans le trafic crypté - par exemple, une IP envoie soudainement des requêtes TLS handshake à une fréquence élevée, ce qui déclenche directement les règles et les jette dans un trou noir. Ne croyez pas la propagande du “support complet du protocole”, de nombreux fournisseurs de protection HTTPS ne font tout simplement pas de détection SNI, rencontrant ESNI (encrypted SNI) directement en sourdine.
Lors de la configuration de la haute défense HTTPS, vous devez prêter attention à la manière dont le certificat est déployé. Il est recommandé d'utiliser la vérification bidirectionnelle des certificats, bien que cela pose des problèmes, mais cela permet de bloquer la plupart des attaques par faux certificats. Postez un exemple de configuration de Nginx :
De plus, le protocole RTMP est un vieil ami de l'industrie de la diffusion en direct. La prise en charge du protocole RTMP par le CDN haute défense est essentielle pour isoler les nœuds "push" et "pull". Certains fournisseurs, afin de réduire les coûts, utilisent le même ensemble de serveurs pour le flux d'envoi et le flux de réception, ce qui entraîne une attaque par inondation RTMP et l'effondrement de l'ensemble de la chaîne de diffusion en direct. La pratique fiable, comme CDN07, consiste à utiliser des nœuds de flux poussés seuls avec un cluster de haute défense, des nœuds de flux tirés, puis à procéder à une accélération distribuée. Une fois mesurée leur protection RTMP, les nœuds de flux poussés peuvent porter une attaque par inondation de 200 Gbps en même temps, le délai du flux tiré ne dépasse pas 200 ms.
WebSocket est le scénario qui met réellement à l'épreuve la technologie des fournisseurs. Ce protocole se caractérisant par de longues connexions, la stratégie de protection traditionnelle basée sur la fréquence des requêtes est fondamentalement inefficace. Les attaquants établissent des centaines de milliers de connexions WebSocket qui peuvent encore épuiser les ressources du serveur. Un bon CDN de haute défense comme 08Host peut analyser le comportement des connexions - par exemple, une IP pour établir une connexion après l'échec continu de l'envoi de paquets, ou envoyer un paquet de battement de cœur par seconde plus que le seuil, directement pincer la connexion. Il faut également prendre en charge la somme de contrôle de la mise à niveau du protocole, afin d'éviter que des attaquants déguisés en poignée de main WebSocket n'envoient en réalité une inondation HTTP.
J'ai récemment rencontré un autre écueil : la protection WebSocket over TLS (WSS). De nombreux fournisseurs pensent que la même configuration que la protection HTTPS fonctionnera, mais le résultat est que la phase de poignée de main TLS est pénétrée. Il est recommandé de configurer WSS de manière à imposer une version TLS minimale de 1.2 et à désactiver les suites de chiffrement faibles. J'ai testé la configuration par défaut d'un fournisseur, qui prend également en charge TLS 1.0, que j'ai directement mis sur liste noire.
Outre ces protocoles courants, certains scénarios particuliers méritent d'être évoqués. Par exemple, le protocole UDP couramment utilisé dans l'industrie du jeu, le CDN de haute sécurité doit prendre en charge la protection UDP Flood ; l'industrie financière peut avoir besoin du protocole privé TCP, selon que le CDN prend ou non en charge la protection des ports personnalisés. J'ai vu un système de négociation de titres à cause de l'utilisation de ports non standard, acheter un CDN de haute sécurité qui ne détecte pas le trafic du port, a été paralysé par SYN Flood avant de penser à des règles personnalisées.
Ne vous contentez pas de regarder le prix lorsque vous choisissez un CDN de haute défense. Je vais vous présenter des données comparatives réelles :
Enfin, j'aimerais exposer une théorie violente : de nos jours, les attaques de réseau ont depuis longtemps dépassé le simple et grossier ICMP Flood. Les attaquants ont commencé à cibler les vulnérabilités des protocoles pour mener des attaques au niveau de la couche application, telles que les attaques par connexion lente WebSocket, les attaques par obscurcissement du protocole RTMP. Si vous choisissez le fournisseur de CDN, même l'adaptation du protocole n'est pas parfaite, ce qui équivaut à ce que le pirate ouvre la porte arrière et passe activement la clé.
Lors de la configuration d'un CDN à haute défense, n'oubliez pas de vous accroupir en arrière-plan et de regarder les rapports de trafic en temps réel. Un bon système de protection indiquera clairement les types d'attaques et les mesures d'atténuation pour les différents protocoles. N'attendez pas que votre entreprise s'effondre pour vérifier les journaux - vos clients auront alors épuisé leurs stocks. Il est toujours préférable de prévenir la sécurité plutôt que d'y remédier après coup.
J'ai oublié de préciser un point essentiel : la prise en charge du protocole dépend également du chemin de retour vers la source. Certains CDN annoncent la prise en charge de WebSocket, mais le retour à la source est rétrogradé à l'interrogation HTTP, ce qui entraîne une explosion directe de la latence. Assurez-vous de tester avec des scénarios d'affaires réels avant d'acheter, sinon vous dépensez de l'argent pour acheter un solitaire.
En bref (tsk, je n'ai pas pu résister à l'envie de dire encore une fois en bref), la prise en charge des protocoles pour les CDN à haute défense n'est certainement pas un jeu de cases à cocher. De HTTPS à WebSocket, chaque protocole présente une surface d'attaque et des points de protection uniques. Lorsque vous choisissez un fournisseur, vous devez vérifier la solidité de la relation, la compatibilité du protocole, la granularité de la protection, la perte de performance ne peut pas être épargnée. Après tout, de nos jours, même les CDN doivent “empêcher les coéquipiers” - choisir le mauvais fournisseur, les coéquipiers deviennent l'ennemi, ce qui est le plus terrible.
