\u00c0 trois heures du matin, au milieu de la nuit, mon t\u00e9l\u00e9phone portable a vibr\u00e9 comme un fou. Le groupe d'alerte de surveillance a bross\u00e9 trois \u00e9crans d'\"anomalie HTTP 500 de la source\" et de \"bande passante en cours d'ex\u00e9cution 95%\". Le c\u0153ur battant, j'ai saisi l'ordinateur portable connect\u00e9 au VPN - l'arri\u00e8re-plan de l'entreprise a \u00e9t\u00e9 bloqu\u00e9 \u00e0 l'ouverture, la charge du serveur source a grimp\u00e9 \u00e0 trois chiffres, les graphiques de trafic en temps r\u00e9el montrent que le grill offshore est des milliers de demandes par seconde l'\u00e9chelle de l'impact fou de nos services. Qu'y a-t-il de plus ironique ? Nous avons manifestement fait flamber l'argent d'un CDN de haute d\u00e9fense bien connu, et maintenant la console de protection est aussi silencieuse que si rien ne s'\u00e9tait pass\u00e9.<\/p>\n
Il s'agit d'une sc\u00e8ne typique de p\u00e9n\u00e9tration d'un CDN \u00e0 haute d\u00e9fense. Les attaquants ont contourn\u00e9 les r\u00e8gles de protection du CDN, ont touch\u00e9 directement votre IP source, et cette fois le soi-disant nettoyage de trillion, le WAF intelligent deviennent tous une pose. J'ai vu trop d'\u00e9quipes dont la premi\u00e8re r\u00e9action est de contacter le service client du CDN, de red\u00e9marrer le serveur ou m\u00eame d'arr\u00eater temporairement l'activit\u00e9 - ces op\u00e9rations sont soit trop lentes, soit \u00e9quivalentes \u00e0 un suicide.<\/p>\n
La discussion d'aujourd'hui ne porte pas sur des solutions th\u00e9oriques, mais sur un manuel d'urgence pratique r\u00e9sum\u00e9 apr\u00e8s que j'ai personnellement mis les pieds dans le plat. La prochaine fois que vous constaterez qu'un CDN est une imposture, suivez les \u00e9tapes ci-dessous et vous pourrez ramener votre entreprise dans la zone de s\u00e9curit\u00e9 en une demi-heure.<\/p>\n
\u00c9tape 1 : Bloquer imm\u00e9diatement le trafic provenant des stations sources directement connect\u00e9es<\/strong><\/p>\n La premi\u00e8re fois que vous d\u00e9couvrez que vous avez \u00e9t\u00e9 p\u00e9n\u00e9tr\u00e9, ne v\u00e9rifiez pas les journaux et ne cherchez pas la cause, sauvez d'abord votre vie. Le moyen le plus rapide est de bloquer l'acc\u00e8s \u00e0 toutes les IP de retour non-CDN sur le pare-feu ou le groupe de s\u00e9curit\u00e9 du serveur. Prenons l'exemple de Cloudflare : le segment officiel des IP de retour est public, et d'autres fournisseurs tels que CDN5 et CDN07 fournissent \u00e9galement des listes exclusives d'IP de retour en arri\u00e8re-plan. Blocage temporaire avec iptables :<\/p>\n Si vous utilisez un groupe de s\u00e9curit\u00e9 de plateforme cloud (comme AliCloud\/AWS), il est plus rapide de modifier les r\u00e8gles directement. Remarque : veillez \u00e0 confirmer \u00e0 l'avance la plage d'adresses IP de retour du fournisseur de CDN, sinon le trafic normal risque d'\u00eatre bloqu\u00e9 par erreur.<\/p>\n \u00c9tape 2 : Changement rapide des n\u0153uds de haute d\u00e9fense et rafra\u00eechissement de la r\u00e9solution<\/strong><\/p>\n Les CDN haute d\u00e9fense de nombreux fournisseurs proposent des n\u0153uds de sauvegarde multi-lignes. Par exemple, le \"Emergency Protection Mode\" de CDN07 ou le \"Resilient Shield Node\" de 08Host, ces n\u0153uds ont g\u00e9n\u00e9ralement des politiques de contr\u00f4le de fr\u00e9quence et d'authentification plus strictes. Imm\u00e9diatement apr\u00e8s que la console ait chang\u00e9 de n\u0153ud, le TTL du DNS est ajust\u00e9 \u00e0 la baisse \u00e0 60 secondes (s'il \u00e9tait auparavant \u00e9lev\u00e9) et la r\u00e9solution est forc\u00e9e d'\u00eatre rafra\u00eechie. Ne vous attendez pas \u00e0 ce que le cache expire - les attaquants ne peuvent pas attendre que vous attendiez une demi-heure.<\/p>\n C'est l\u00e0 que l'on voit l'importance de la s\u00e9lection. Je l'ai test\u00e9, et le r\u00e9seau Anycast comme CDN5 permet de changer de n\u0153ud en quelques secondes, alors que certaines solutions moins ch\u00e8res n\u00e9cessitent de lever manuellement des ordres de travail - attendre un ordre de travail au milieu de la nuit ? Attendez que la salle des serveurs fume.<\/p>\n \u00c9tape 3 : Remonter jusqu'\u00e0 la personne qui a manqu\u00e9 l'IP de la station source<\/strong><\/p>\n Apr\u00e8s avoir combl\u00e9 la faille, il est temps de r\u00e9gler les comptes. Quatre-vingt pour cent de l'exposition de l'IP source est due \u00e0 des oublis de configuration. Les fuites les plus courantes sont les suivantes :<\/p>\n Recommandez une astuce : utilisez diff\u00e9rents noms de domaine pour effectuer plusieurs r\u00e9solutions DNS pour le m\u00eame service, et observez quels domaines r\u00e9solvent l'IP source. par exemple :<\/p>\n Si un nom de domaine se r\u00e9sout directement \u00e0 l'IP source, cela signifie que la configuration de la r\u00e9solution ne passe pas du tout par le CDN. J'ai vu une \u00e9quipe sur DNSPOD avec CNAME, mais qui a oubli\u00e9 de supprimer l'enregistrement A pr\u00e9c\u00e9dent, ce qui \u00e9quivaut \u00e0 une porte d\u00e9rob\u00e9e pour l'attaquant.<\/p>\n \u00c9tape 4 : Renforcer la strat\u00e9gie de furtivit\u00e9 du site source<\/strong><\/p>\n Le CDN haute d\u00e9fense n'est pas une amulette universelle, le poste source lui-m\u00eame doit \u00eatre \"furtif\". Nous vous conseillons quelques astuces sournoises :<\/p>\n Partage d'une configuration Nginx que j'utilise moi-m\u00eame pour intercepter automatiquement les requ\u00eates non-CDN :<\/p>\n \u00c9tape 5 : V\u00e9rifier l'efficacit\u00e9 de la protection et la contr\u00f4ler en permanence<\/strong><\/p>\n Une fois l'op\u00e9ration d'urgence termin\u00e9e, utilisez l'outil pour simuler l'attaque et v\u00e9rifier que la protection est efficace. Nous recommandons deux widgets d\u00e9velopp\u00e9s par nos soins :<\/p>\n Surveillez \u00e9galement le d\u00e9lai d'ex\u00e9cution et le taux d'erreur. Les CDN \u00e0 haute d\u00e9fense peuvent tuer les utilisateurs normaux (par exemple, le CAPTCHA appara\u00eet trop souvent) apr\u00e8s avoir activ\u00e9 une protection stricte, vous devez donc ajuster la sensibilit\u00e9 en fonction de votre activit\u00e9. Ne croyez pas \u00e0 la \"protection intelligente enti\u00e8rement automatique\" - je l'ai test\u00e9e et au moins trois des modes intelligents sur le march\u00e9 ne peuvent m\u00eame pas emp\u00eacher les simples attaques CC.<\/p>\n Des tweets percutants sur la s\u00e9lection des fournisseurs<\/strong><\/p>\n De nos jours, le march\u00e9 du CDN de haute d\u00e9fense est trop profond. Certains fournisseurs se vantent d'une \"protection de 2Tbps\", alors qu'en r\u00e9alit\u00e9 ils utilisent les anciens n\u0153uds de la pile mat\u00e9rielle ; il existe \u00e9galement des \"pools de nettoyage partag\u00e9s\", une grosse attaque impliquant tous les clients. J'ai mesur\u00e9 le trafic d'une attaque d'un petit fournisseur \u00e0 200 Gbps et toute la r\u00e9gion s'est effondr\u00e9e ; le service client\u00e8le a m\u00eame d\u00e9clar\u00e9 qu'il \u00e9tait \"recommand\u00e9 de passer \u00e0 la version entreprise\".<\/p>\n Comparez plusieurs fournisseurs de services courants :<\/p>\n Conseil sinc\u00e8re : ne vous contentez pas de regarder l'offre et les param\u00e8tres, construisez r\u00e9ellement un environnement de test pour jouer une vague de trafic \u00e0 essayer. Un jour, un fournisseur m'a fait une d\u00e9monstration de \"protection r\u00e9ussie contre des attaques de 500 Gbps\", et j'ai d\u00e9couvert par la suite qu'il s'agissait d'une donn\u00e9e de brossage interne - de nos jours, m\u00eame les CDN doivent \"pr\u00e9venir les co\u00e9quipiers\".<\/p>\n Quelques derniers coups de gueule.<\/strong><\/p>\n La p\u00e9n\u00e9tration du CDN haute d\u00e9fense n'est pas un probl\u00e8me technique, c'est le syst\u00e8me d'exploitation et de maintenance et les capacit\u00e9s de r\u00e9action en cas d'urgence du miroir d\u00e9moniaque. J'ai vu des \u00e9quipes d\u00e9penser des millions pour acheter une protection, mais \u00e0 cause d'une erreur de configuration DNS, toute la plaque s'est effondr\u00e9e. J'ai \u00e9galement vu des cas o\u00f9 le CDN minimum + les r\u00e8gles auto-d\u00e9velopp\u00e9es sont aussi stables que le Mont Taishan.<\/p>\n La solution vraiment fiable est toujours la suivante : supposer que le CDN doit \u00eatre p\u00e9n\u00e9tr\u00e9 et que le site source doit \u00eatre cach\u00e9 l\u00e0 o\u00f9 l'ennemi ne peut pas le trouver. Le principe de la confiance z\u00e9ro est toujours vrai en mati\u00e8re de cybers\u00e9curit\u00e9.<\/p>\n La prochaine fois que vous serez r\u00e9veill\u00e9 \u00e0 minuit, j'esp\u00e8re que vous sourirez, que vous ouvrirez votre terminal et que vous ferez une s\u00e9rie de combos, puis que vous vous rendormirez.<\/p>","protected":false},"excerpt":{"rendered":" \u00c0 trois heures du matin, au milieu de la nuit, mon t\u00e9l\u00e9phone portable a vibr\u00e9 comme un fou. Le groupe d'alerte de surveillance a bross\u00e9 trois \u00e9crans d'\"anomalie HTTP 500 de la source\" et de \"bande passante en cours d'ex\u00e9cution 95%\". Le c\u0153ur battant, j'ai saisi l'ordinateur portable connect\u00e9 au VPN - l'arri\u00e8re-plan de l'entreprise a \u00e9t\u00e9 bloqu\u00e9 \u00e0 l'ouverture, la charge du serveur source a grimp\u00e9 \u00e0 trois chiffres, les graphiques de trafic en temps r\u00e9el montrent que le grill offshore est des milliers de demandes par seconde l'\u00e9chelle de l'impact fou de nos services. Qu'y a-t-il de plus ironique ? Nous avons manifestement d\u00e9pens\u00e9 beaucoup d'argent pour un CDN r\u00e9put\u00e9 \u00e0 haute d\u00e9fense, mais maintenant la console de protection est aussi silencieuse que s'il ne s'\u00e9tait rien pass\u00e9. Il s'agit d'un sc\u00e9nario typique de \"p\u00e9n\u00e9tration d'un CDN \u00e0 haute d\u00e9fense\". Les attaquants ont contourn\u00e9 les r\u00e8gles de protection du CDN, ont touch\u00e9 directement l'IP de votre station source, et cette fois le soi-disant nettoyage de trillion, le WAF intelligent deviennent tous des poses. J'ai vu<\/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-1030","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\/1030","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=1030"}],"version-history":[{"count":1,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/1030\/revisions"}],"predecessor-version":[{"id":1095,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/1030\/revisions\/1095"}],"wp:attachment":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/media?parent=1030"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/categories?post=1030"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/tags?post=1030"},{"taxonomy":"collection","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/collection?post=1030"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}