R\u00e9cemment, j'ai \u00e9t\u00e9 confront\u00e9 \u00e0 un probl\u00e8me : la station de commerce \u00e9lectronique d'un client a manifestement accroch\u00e9 un CDN \u00e0 haute d\u00e9fense, ou plus de 100 000 fausses commandes ont \u00e9t\u00e9 balay\u00e9es. Le journal a r\u00e9v\u00e9l\u00e9 que l'attaquant avait parfaitement falsifi\u00e9 l'adresse IP du n\u0153ud CDN et que la demande avait directement contourn\u00e9 le syst\u00e8me de protection. De nos jours, m\u00eame le CDN doit \u201cpr\u00e9venir les co\u00e9quipiers\u201d - vous pensez qu'un bouclier sur la s\u00e9curit\u00e9, mais vous ne savez pas que la v\u00e9rification de la station source n'est pas bonne, le CDN de haute s\u00e9curit\u00e9 deviendra le tremplin pour les attaquants.<\/p>\n
Les attaques par usurpation d'adresse IP ne sont pas nouvelles. Mais de nombreuses personnes pensent que le CDN sera tranquille, ce qui est en fait une grave erreur. Les attaquants commenceront par analyser le segment IP du n\u0153ud CDN, puis forgeront un en-t\u00eate X-Forwarded-For de ce type, afin de faire passer le trafic ind\u00e9sirable pour du \u201ctrafic CDN l\u00e9gitime\u201d et de le renvoyer directement \u00e0 la station source. J'ai test\u00e9 trois fournisseurs de services CDN l'ann\u00e9e derni\u00e8re, deux des configurations par d\u00e9faut permettent en fait \u00e0 n'importe quelle IP de d\u00e9clarer qu'ils sont des n\u0153uds CDN, cette faille de s\u00e9curit\u00e9 est tout simplement plus qu'une fuite de la passoire.<\/p>\n
La cause principale est que beaucoup d'op\u00e9rations et de maintenance font aveugl\u00e9ment confiance \u00e0 la liste d'adresses IP fournie par le fournisseur de services CDN. Mais les IP des n\u0153uds CDN sont mises \u00e0 jour ah brother ! La liste des segments IP qui vient d'\u00eatre mise \u00e0 jour la semaine derni\u00e8re peut \u00eatre invalide cette semaine. Sans parler des fournisseurs de CDN qui utilisent des services en nuage avec des IP \u00e9lastiques, les IP des n\u0153uds changent plus vite que les livres. Vous esp\u00e9rez maintenir manuellement une liste blanche d'adresses IP ? Autant envoyer une invitation aux attaquants.<\/p>\n
Tout d'abord, la v\u00e9rification de l'IP source. N'utilisez pas le \u201cCDN IP Segment Book\u201d t\u00e9l\u00e9charg\u00e9 sur internet, il expire plus vite que la dur\u00e9e de conservation d'un yaourt. J'ai maintenant chang\u00e9 tous les projets pour utiliser un m\u00e9canisme d'authentification dynamique : dans le panneau de contr\u00f4le du CDN pour g\u00e9n\u00e9rer un Token unique, et ensuite par le biais d'un en-t\u00eate personnalis\u00e9 pass\u00e9 \u00e0 la station source. La configuration Nginx du site source est directement morte en \u00e9criture :<\/p>\n
Cette astuce est impitoyable en quoi ? M\u00eame si l'attaquant a falsifi\u00e9 l'IP, il ne peut pas obtenir le jeton. Nous avons test\u00e9 CDN5 et CDN07, avec une v\u00e9rification personnalis\u00e9e de l'en-t\u00eate, le taux d'interception des requ\u00eates ill\u00e9gales atteint directement 100%. Toutefois, il convient de noter que le jeton doit faire l'objet d'une rotation r\u00e9guli\u00e8re, il est recommand\u00e9 d'utiliser le syst\u00e8me de gestion des cl\u00e9s pour mettre \u00e0 jour automatiquement le jeton.<\/p>\n
Le token seul ne suffit pas. L'ann\u00e9e derni\u00e8re, nous avons rencontr\u00e9 un cas o\u00f9 l'attaquant a eu recours \u00e0 l'ing\u00e9nierie sociale pour obtenir le token (un employ\u00e9 a jet\u00e9 le fichier de configuration sur GitHub), cette fois nous avons besoin d'une deuxi\u00e8me ligne de d\u00e9fense - le fingerprinting. Le principe de cette technologie est en fait tr\u00e8s simple : \u00e0 chaque n\u0153ud CDN l\u00e9gitime correspond un filigrane num\u00e9rique, tout comme les badges d'identification d\u00e9livr\u00e9s aux agents.<\/p>\n
J'ai essay\u00e9 cela sur le n\u0153ud de 08Host : injecter un bout de code JS sp\u00e9cifique dans la configuration du CDN, et le site source confirme l'identit\u00e9 en d\u00e9tectant cette empreinte. Par exemple, faire en sorte que le n\u0153ud CDN l'ajoute automatiquement lorsqu'il renvoie une r\u00e9ponse :<\/p>\n
Lorsque la station source re\u00e7oit la demande, elle utilise le m\u00eame algorithme pour v\u00e9rifier la signature et rejette la demande si l'\u00e9cart d'horodatage est sup\u00e9rieur \u00e0 5 secondes. L'aspect le plus ignoble de ce syst\u00e8me est que m\u00eame si l'attaquant obtient la cl\u00e9, elle est inutile parce que l'horodatage et l'ID du n\u0153ud changent dynamiquement. Une impl\u00e9mentation sp\u00e9cifique peut \u00eatre int\u00e9gr\u00e9e dans OpenResty en utilisant des scripts Lua :<\/p>\n
Parlons maintenant de la surcharge de performance. Beaucoup de gens entendent parler d\u201c\u201dauthentification cryptographique\" et pensent que cela affectera les performances. En fait, lors du test r\u00e9el, l'augmentation du d\u00e9lai de v\u00e9rification d'une seule demande est inf\u00e9rieure \u00e0 2 ms. Compar\u00e9 au co\u00fbt de la paralysie par un DDoS, ce surco\u00fbt est presque n\u00e9gligeable. Mais attention au choix des algorithmes de cl\u00e9s, ne soyez pas idiot d'utiliser RSA comme une arme lourde, ECDSA ou HMAC-SHA256 sont tout \u00e0 fait suffisants.<\/p>\n
R\u00e9cemment, pour aider une plateforme financi\u00e8re \u00e0 effectuer des tests de p\u00e9n\u00e9tration, j'ai d\u00e9couvert une attaque plus insidieuse : l'attaquant va d'abord acc\u00e9der l\u00e9gitimement au n\u0153ud CDN, capturer les caract\u00e9ristiques de l'empreinte digitale de l'en-t\u00eate de la r\u00e9ponse, et ensuite essayer de rejouer l'attaque. \u00c0 l'heure actuelle, il ne suffit pas de s'appuyer sur la v\u00e9rification statique des signatures, il faut ajouter un m\u00e9canisme de num\u00e9ro al\u00e9atoire \u00e0 usage unique (Nonce). J'ai vu dans le contexte de gestion de CDN07 que la derni\u00e8re version de leur g\u00e9n\u00e9rateur Nonce a \u00e9t\u00e9 prise en charge, rafra\u00eechissant automatiquement la valeur de la graine une fois toutes les 10 minutes.<\/p>\n
En fait, la solution la plus rentable consiste \u00e0 utiliser directement le SDK du fournisseur. Comme le module Edge Auth de CDN5 encapsule un ensemble complet de logique d'authentification, la station source n'a qu'\u00e0 ajuster une API pour v\u00e9rifier l'authenticit\u00e9. Mais ne vous fiez pas enti\u00e8rement aux solutions de bo\u00eete noire - j'ai vu une vuln\u00e9rabilit\u00e9 o\u00f9 le SDK d'un fournisseur \u00e9tait expos\u00e9 \u00e0 des cl\u00e9s cod\u00e9es en dur. Mon approche consiste d\u00e9sormais \u00e0 utiliser une authentification hybride : j'utilise le SDK du fournisseur pour effectuer le filtrage initial et je mets \u00e9galement en \u0153uvre un autre ensemble de logique de v\u00e9rification de la signature.<\/p>\n
En ce qui concerne les configurations sp\u00e9cifiques, donnons un exemple de Nginx en action. La configuration suivante met en \u0153uvre la triple protection de la liste blanche des adresses IP, de la v\u00e9rification par jeton et de la signature par empreinte digitale en m\u00eame temps :<\/p>\n
Enfin, certains petits fournisseurs de services CDN, afin de r\u00e9duire les co\u00fbts, sont trop paresseux pour effectuer les contr\u00f4les de s\u00e9curit\u00e9 de base. La derni\u00e8re fois que j'ai test\u00e9 un CDN appel\u00e9 \u201cintelligent high defence\u201d, j'ai d\u00e9couvert qu'il pla\u00e7ait en fait la logique de v\u00e9rification sur l'ex\u00e9cution JS du client - ce qui n'est pas \u00e9vident pour dire \u00e0 l'attaquant \u201cvite pour me contourner ? \u201dC'est un message clair pour les attaquants. Par cons\u00e9quent, lors de la s\u00e9lection du type d'\u00e9quipe technique, le programme de protection doit \u00eatre test\u00e9 sur le terrain, et il ne faut pas se contenter de regarder l'avant-projet promotionnel.<\/p>\n
Un syst\u00e8me de protection vraiment fiable doit \u00eatre multicouche et dynamique. La v\u00e9rification de l'IP source n'est que la base, l'empreinte digitale est l'armature, et elle doit \u00eatre associ\u00e9e \u00e0 une s\u00e9rie de mesures telles que l'analyse du comportement du trafic (pour d\u00e9tecter les mod\u00e8les de demande anormaux) et la limitation du d\u00e9bit (pour emp\u00eacher les attaques CC). Je d\u00e9ploie maintenant des solutions pour tous les clients, et j'exigerai au moins une fois par mois un test de simulation de contournement - en mati\u00e8re de s\u00e9curit\u00e9, il n'y a pas de programme unique.<\/p>\n
Pour \u00eatre honn\u00eate, au cours des trois derni\u00e8res ann\u00e9es, le volume des attaques par falsification d'adresses IP a plus que d\u00e9cupl\u00e9. Les outils d'attaque ont commenc\u00e9 \u00e0 int\u00e9grer l'empreinte digitale des CDN, et n'importe quel outil open source peut automatiquement identifier les fournisseurs de CDN et capturer les caract\u00e9ristiques des n\u0153uds. Si la d\u00e9fense est toujours bloqu\u00e9e \u00e0 la \u201cconfiguration d'une liste blanche au niveau de la r\u00e9flexion\u201d, la br\u00e8che n'est plus qu'une question de temps.<\/p>\n
Enfin, j'aimerais partager une le\u00e7on tir\u00e9e de mes larmes : ne jamais divulguer les d\u00e9tails de la validation dans le journal des erreurs ! J'ai vu un syst\u00e8me qui renvoie \u201cSignature expir\u00e9e\u201d et \u201cToken invalide\u201d lorsque la v\u00e9rification \u00e9choue, n'est-ce pas comme tendre un couteau \u00e0 un attaquant ? L'approche correcte consiste \u00e0 renvoyer \u201c404 Not Found\u201d, de sorte que l'attaquant ne puisse m\u00eame pas conna\u00eetre la raison de l'\u00e9chec.<\/p>\n
Se prot\u00e9ger contre les attaques de falsification de propri\u00e9t\u00e9 intellectuelle revient \u00e0 jouer au jeu du chat et de la souris ; il n'existe pas de solution miracle. L'essentiel est de mettre en place un syst\u00e8me de d\u00e9fense en constante \u00e9volution, car les m\u00e9thodes de l'attaquant sont elles aussi en constante \u00e9volution. D'apr\u00e8s mon exp\u00e9rience du combat, la combinaison d'un jeton dynamique et d'un syst\u00e8me de signature cryptographique peut encore bloquer l'attaque de falsification 90% \u00e0 la source.<\/p>","protected":false},"excerpt":{"rendered":"
R\u00e9cemment, j'ai \u00e9t\u00e9 confront\u00e9 \u00e0 un probl\u00e8me : la station de commerce \u00e9lectronique d'un client a manifestement accroch\u00e9 un CDN \u00e0 haute d\u00e9fense, ou plus de 100 000 fausses commandes ont \u00e9t\u00e9 balay\u00e9es. Le journal a r\u00e9v\u00e9l\u00e9 que l'attaquant avait parfaitement falsifi\u00e9 l'adresse IP du n\u0153ud CDN et que la demande avait directement contourn\u00e9 le syst\u00e8me de protection. De nos jours, m\u00eame le CDN doit \u201cpr\u00e9venir les co\u00e9quipiers\u201d - vous pensez qu'un bouclier sur la s\u00e9curit\u00e9, mais vous ne savez pas que la v\u00e9rification de la station source n'est pas bonne, le CDN de haute s\u00e9curit\u00e9 deviendra le tremplin pour les attaquants. Les attaques par falsification d'adresses IP n'ont rien de nouveau depuis longtemps. Mais de nombreuses personnes pensent que le CDN est un gage de tranquillit\u00e9 d'esprit, ce qui est en fait une grave erreur. Les attaquants commenceront par analyser le segment IP du n\u0153ud CDN, puis forgeront un en-t\u00eate X-Forwarded-For ce type d'en-t\u00eate, le trafic ind\u00e9sirable \u00e9tant pr\u00e9sent\u00e9 comme du \u201ctrafic CDN l\u00e9gitime\u201d directement vers la station source. L'ann\u00e9e derni\u00e8re, j'ai test\u00e9 trois grands fournisseurs de services CDN, \u00e0 savoir<\/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-980","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\/980","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=980"}],"version-history":[{"count":1,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/980\/revisions"}],"predecessor-version":[{"id":1145,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/980\/revisions\/1145"}],"wp:attachment":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/media?parent=980"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/categories?post=980"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/tags?post=980"},{"taxonomy":"collection","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/collection?post=980"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}