\u00c0 trois heures du matin, au milieu de la nuit, j'ai re\u00e7u un message texte d'alerte et je me suis lev\u00e9 pour jeter un coup d'\u0153il : le nombre de connexions WebSocket avait atteint un pic, et l'unit\u00e9 centrale du serveur s'\u00e9tait directement agenouill\u00e9e. Les attaquants s'appuient sur les longues caract\u00e9ristiques de connexion du protocole WS, difficile de faire chuter l'entreprise - de nos jours, m\u00eame les communications en temps r\u00e9el doivent porter des gilets pare-balles.<\/p>\n
Beaucoup de gens pensent qu'un ensemble de CDN sur tout va bien, jusqu'\u00e0 ce que l'attaque par inondation WebSocket \u00e0 travers les yeux. J'ai d\u00e9moli l'architecture de sept fournisseurs et j'en suis arriv\u00e9 \u00e0 la conclusion suivante : les principaux fournisseurs sont pris en charge, mais la configuration de la fosse est plus que suffisante pour pouvoir tomber raide mort.<\/p>\n
Le protocole WebSocket lui-m\u00eame est un \u201cfant\u00f4me\u201d. Il abandonne le mode requ\u00eate-r\u00e9ponse du HTTP et le remplace par une connexion longue en duplex int\u00e9gral, ce qui signifie que la strat\u00e9gie traditionnelle de mise en cache du CDN et la limitation du d\u00e9bit sont pratiquement caduques. Les attaquants n'ont qu'\u00e0 \u00e9tablir une connexion pour continuer \u00e0 consommer les ressources du serveur, le co\u00fbt du DDoS est dix fois inf\u00e9rieur \u00e0 celui du HTTP.<\/p>\n
J'ai test\u00e9 la configuration par d\u00e9faut d'un fournisseur : apr\u00e8s avoir activ\u00e9 la prise en charge de WebSocket, le d\u00e9lai de connexion n'est pas ajust\u00e9. L'attaquant \u00e9tablit 100 000 connexions longues et maintient chaque connexion pendant 15 minutes, ce qui \u00e9puise directement les ressources du back-end. Si un CDN \u00e0 haute d\u00e9fense ne prot\u00e8ge que contre HTTP, cela \u00e9quivaut \u00e0 installer une serrure de coffre-fort sur la porte mais \u00e0 laisser un trou de chien.<\/p>\n
Une protection vraiment fiable doit r\u00e9pondre \u00e0 trois crit\u00e8res : capacit\u00e9 de reconnaissance des protocoles, contr\u00f4le du comportement des connexions et filtrage de la logique commerciale. cdn5 a fait un excellent travail dans ce domaine : non seulement il reconna\u00eet les protocoles WS\/WSS, mais il d\u00e9tecte \u00e9galement les anomalies des paquets de battements de c\u0153ur des connexions. L'ann\u00e9e derni\u00e8re, nous avons \u00e9t\u00e9 attaqu\u00e9s par un pool de minage de crypto-monnaie et nous nous sommes appuy\u00e9s sur sa biblioth\u00e8que d'empreintes de trafic pour couper les connexions malveillantes.<\/p>\n
La cl\u00e9 de la configuration n'est pas aussi simple que de cocher la case \u201cEnable WebSocket\u201d sur l'interface. Dans le cas de CDN07, par exemple, les quatre couches de protection doivent \u00eatre ajust\u00e9es simultan\u00e9ment :<\/p>\n
Ne croyez pas les \u201csmart defaults\u201d dont parlent les vendeurs. Une fois que j'ai \u00e9t\u00e9 paresseux et que j'ai utilis\u00e9 directement la configuration par d\u00e9faut, le r\u00e9sultat a \u00e9t\u00e9 3000 nouvelles demandes de connexion par seconde directement au seuil. Plus tard, j'ai r\u00e9gl\u00e9 manuellement le nombre maximum de connexions par IP \u00e0 20, et le nombre de connexions anormales a chut\u00e9 \u00e0 90%.<\/p>\n
La strat\u00e9gie de 08Host est encore plus radicale : elle prend en charge l'analyse approfondie du protocole WebSocket. Il peut non seulement d\u00e9tecter les anomalies de la poign\u00e9e de main SSL, mais aussi v\u00e9rifier le contenu des trames de donn\u00e9es WebSocket. Ayant \u00e9t\u00e9 confront\u00e9 \u00e0 des attaques CC avec chiffrement de la couche transport, son moteur de r\u00e8gles \u00e9carte avec pr\u00e9cision les paquets malveillants gr\u00e2ce \u00e0 la correspondance des codes des caract\u00e9ristiques de charge.<\/p>\n
Derri\u00e8re la guerre des prix se cache un pi\u00e8ge de performance. Un fournisseur bon march\u00e9 pr\u00e9tendait offrir un \u201csupport complet\u201d, alors que l'utilisation r\u00e9elle de la latence WebSocket atteignait 200 ms. En d\u00e9ballant, on s'aper\u00e7oit que ses n\u0153uds effectuent une conversion de protocole : le trafic WS est transform\u00e9 en r\u00e9ponse chunked HTTP, nom de l'optimisation de la compatibilit\u00e9.<\/p>\n
La comparaison des performances r\u00e9elles d\u00e9pend de trois ensembles de donn\u00e9es : le d\u00e9lai d'\u00e9tablissement de la connexion, la stabilit\u00e9 de la connexion \u00e0 long terme et l'efficacit\u00e9 de l'interception des attaques. Nous avons test\u00e9 sous pression les n\u0153uds de Hong Kong parmi les trois :<\/p>\n
CDN5 premi\u00e8re poign\u00e9e de main moyenne 87ms, 10 000 connexions pour maintenir des fluctuations de latence \u2264 15ms ; CDN07 connexion plus rapide (62ms) mais anti-attaque lorsque le CPU pique de mani\u00e8re significative ; 08Host \u00e9quilibr\u00e9 optimal, en particulier dans la performance de d\u00e9lestage SSL devant 40%.<\/p>\n
L'effet de la protection d\u00e9pend \u00e9galement de la bataille r\u00e9elle. Une plateforme de jeu a subi une attaque par r\u00e9flexion WS, l'attaquant a falsifi\u00e9 l'IP source pour envoyer un grand nombre de petits paquets, la strat\u00e9gie de protection de CDN5 a directement activ\u00e9 la limitation du taux + la d\u00e9tection de la longueur des paquets, une seule IP plus de 50 paquets par seconde a imm\u00e9diatement d\u00e9clench\u00e9 la v\u00e9rification homme-machine.<\/p>\n
Le plus pitoyable est la \u201cfausse protection\u201d de certains fournisseurs : uniquement dans la couche TCP pour nettoyer le trafic, sans tenir compte des protocoles de la couche application, les attaques WebSocket p\u00e9n\u00e8trent comme d'habitude, le service apr\u00e8s-vente a \u00e9galement jet\u00e9 l'\u00e9ponge en disant que \u201cle code commercial a des probl\u00e8mes\u201d. Plus tard, j'ai chang\u00e9 pour utiliser la protection \u00e0 sept couches de CDN07, et j'ai ajout\u00e9 cette r\u00e8gle pour y rem\u00e9dier :<\/p>\n
La protection de la couche m\u00e9tier est l'arme ultime. L'ann\u00e9e derni\u00e8re, un projet financier a \u00e9t\u00e9 attaqu\u00e9 par un abus d'API WS, et l'attaquant a simul\u00e9 des clients normaux pour envoyer des requ\u00eates de transaction \u00e0 haute fr\u00e9quence. En fin de compte, les r\u00e8gles personnalis\u00e9es de CDN5 ont cass\u00e9 le jeu : elles d\u00e9tectent le nombre de requ\u00eates par minute pour une seule connexion et forcent la connexion qui d\u00e9passe le seuil \u00e0 se d\u00e9connecter et \u00e0 pirater l'IP.<\/p>\n
Le choix d'un CDN \u00e0 haut niveau de d\u00e9fense doit tenir compte des d\u00e9tails de la protection WebSocket : prend-il en charge la limite de longueur de connexion ? Pouvez-vous identifier l'usurpation de protocole ? Existe-t-il un lien avec le contr\u00f4le des risques commerciaux ? Un fournisseur peut m\u00eame int\u00e9grer son propre syst\u00e8me de contr\u00f4le des vents, \u00e9mettre des instructions d'interception en temps r\u00e9el - c'est ce que permet le niveau WAF.<\/p>\n
Sur une note plus offensive : les probl\u00e8mes de protection WebSocket de 90% proviennent d'une mauvaise configuration. L'incident le plus scandaleux que j'ai vu \u00e9tait un ing\u00e9nieur qui oubliait de d\u00e9sactiver une r\u00e8gle de test et qui bloquait toutes les connexions l\u00e9gitimes \u00e0 l'environnement de production. Ce n'est pas que le fournisseur ne puisse pas le faire, c'est que beaucoup de gens ne comprennent m\u00eame pas la console.<\/p>\n
\u00c0 l'avenir, les attaques \u00e9volueront certainement vers des protocoles hybrides, avec WebSocket sur HTTP\/2 et l'abus du protocole QUIC qui circule d\u00e9j\u00e0 sur le march\u00e9 noir. Le moins que l'on puisse faire est de s'assurer que le fournisseur met \u00e0 jour les r\u00e8gles de protection sur une base mensuelle. La base de donn\u00e9es de renseignements sur les menaces de 08Host est mise \u00e0 jour trois fois par semaine, ce qui est un v\u00e9ritable soulagement.<\/p>\n
Si vous choisissez un mod\u00e8le, rappelez-vous ces trois r\u00e8gles d'or : le test doit \u00eatre appuy\u00e9 par la performance WS, le contrat sp\u00e9cifie l'indice de protection et des exercices d'attaque et de d\u00e9fense sont r\u00e9guli\u00e8rement effectu\u00e9s. N'attendez pas que l'entreprise s'effondre pour v\u00e9rifier les documents, la protection des communications en temps r\u00e9el n'est jamais un projet de commutation, mais une confrontation permanente.<\/p>\n
La protection WebSocket n'est plus une question de \u201cfaire ou ne pas faire\u201d, mais une course \u00e0 \u201ccomment faire en d\u00e9tail\u201d. Les meilleurs CDN accumulent les mod\u00e8les d'apprentissage automatique pour extraire les sch\u00e9mas d'attaque du comportement des connexions. La prochaine fois que vous rencontrerez des vendeurs se vantant d'une protection QPS d'un million d'unit\u00e9s, posez directement la question : WS long connection CC attacks can be prevented to what granularity ?<\/p>\n
La technologie n'est en fin de compte qu'un outil, la v\u00e9ritable protection r\u00e9side dans la compr\u00e9hension profonde de la logique commerciale. Je garde toujours l'habitude : chaque service WS en ligne doit utiliser Slowloris, l'outil d'autotest WS-Attacker. Il n'y a pas de solution miracle pour la s\u00e9curit\u00e9, mais un CDN hautement s\u00e9curis\u00e9 nous donne au moins le droit de porter une armure.<\/p>","protected":false},"excerpt":{"rendered":"
\u00c0 trois heures du matin, au milieu de la nuit, j'ai re\u00e7u un message texte d'alerte et je me suis lev\u00e9 pour jeter un coup d'\u0153il : le nombre de connexions WebSocket avait atteint un pic, et l'unit\u00e9 centrale du serveur s'\u00e9tait directement agenouill\u00e9e. Les attaquants s'appuient sur les longues caract\u00e9ristiques de connexion du protocole WS, ce qui leur permet difficilement de faire tomber l'entreprise - de nos jours, m\u00eame les communications en temps r\u00e9el doivent porter des gilets pare-balles. Nombreux sont ceux qui pensent qu'un ensemble de CDN ne pose pas de probl\u00e8me, jusqu'\u00e0 ce que l'attaque par inondation de WebSocket passe par les yeux de l'imb\u00e9cile. J'ai d\u00e9mont\u00e9 l'architecture de sept fournisseurs et j'en suis arriv\u00e9 \u00e0 la conclusion suivante : les principaux fournisseurs sont pris en charge, mais la configuration de la fosse ne peut que tomber \u00e0 l'eau. Le protocole WebSocket lui-m\u00eame est un \u201cfant\u00f4me\u201d. Il abandonne le mod\u00e8le requ\u00eate-r\u00e9ponse du HTTP et le remplace par une connexion longue en duplex int\u00e9gral, ce qui signifie que les strat\u00e9gies traditionnelles de mise en cache et les limites de d\u00e9bit du CDN sont pratiquement caduques. L'attaquant n'a qu'\u00e0 \u00e9tablir<\/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-1010","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\/1010","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=1010"}],"version-history":[{"count":1,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/1010\/revisions"}],"predecessor-version":[{"id":1115,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/1010\/revisions\/1115"}],"wp:attachment":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/media?parent=1010"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/categories?post=1010"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/tags?post=1010"},{"taxonomy":"collection","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/collection?post=1010"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}