R\u00e9cemment, j'ai aid\u00e9 mon ami \u00e0 enqu\u00eater sur un site web qui avait \u00e9t\u00e9 touch\u00e9 par un accrochage, je me suis connect\u00e9 \u00e0 l'arri\u00e8re-plan du CDN pour jeter un coup d'\u0153il, bon gars, le trafic d'attaque est presque en train de franchir le niveau T, mais la strat\u00e9gie de d\u00e9fense du CDN de haute d\u00e9fense est en fait comme une cuill\u00e8re qui fuit et qui n'a pas arr\u00eat\u00e9 quelques requ\u00eates. L'activit\u00e9 r\u00e9elle est paralys\u00e9e depuis longtemps, mais la console montre \u00e9galement que \u201ctout est normal\u201d, ce qui est une image ironique qui peut \u00eatre utilis\u00e9e comme film de propagande sur la s\u00e9curit\u00e9 des r\u00e9seaux.<\/p>\n
De nos jours, m\u00eame les CDN doivent \u201cpr\u00e9venir les co\u00e9quipiers\u201d. La protection de niveau T annonc\u00e9e par les fournisseurs semble bluffante, mais la configuration n'est pas correcte ou la compr\u00e9hension est biais\u00e9e, ce qui vous expose \u00e0 courir nu dans la fusillade de l'internet. J'ai test\u00e9 le march\u00e9 de cinq ou six services grand public de haute d\u00e9fense, et j'ai r\u00e9sum\u00e9 cinq des raisons les plus courantes de l'\u00e9chec des CDN de haute d\u00e9fense - certaines de ces raisons peuvent m\u00eame laisser les fabricants de l'assistance technique se gratter la t\u00eate.<\/p>\n
Tout d'abord, la station source IP leakage : vous pensez qu'elle est cach\u00e9e, en fait, dans la station nue.<\/strong><\/p>\n L'erreur la plus courante et la plus fatale. Beaucoup de webmasters pensent que l'ensemble du CDN sera tranquille, mais ne savent pas que les minutes de l'attaquant peuvent identifier l'IP r\u00e9elle de votre serveur. Une fois que l'IP de la station source est expos\u00e9e, le trafic d'attaque contourne directement le CDN \u00e0 haute d\u00e9fense vers le serveur, ce qui est une protection est devenu un pi\u00e8ge.<\/p>\n L'ann\u00e9e derni\u00e8re, j'ai aid\u00e9 un site de commerce \u00e9lectronique \u00e0 effectuer des tests de p\u00e9n\u00e9tration, et j'ai utilis\u00e9 un outil d'empreinte digitale open source pour scanner directement l'IP source - simplement parce qu'ils avaient oubli\u00e9 de supprimer la source pointant dans l'enregistrement A d'un sous-domaine. Il est plus courant de passer par le serveur de messagerie, les anciens sous-domaines et m\u00eame les informations du certificat SSL pour v\u00e9rifier l'IP \u00e0 rebours.<\/p>\n Solution :<\/strong><\/p>\n 1. isoler strictement le chemin d'acc\u00e8s \u00e0 la station source et n'autoriser que le segment IP de retour du CDN \u00e0 acc\u00e9der au port du serveur. Un r\u00e9seau backhaul priv\u00e9 comme celui fourni par CDN5 fonctionne tr\u00e8s bien, et vous pouvez \u00e9galement personnaliser les tunnels crypt\u00e9s ;<\/p>\n 2. utiliser r\u00e9guli\u00e8rement l'outil pour auto-v\u00e9rifier les risques d'exposition \u00e0 la propri\u00e9t\u00e9 intellectuelle :<\/p>\n 3. une solution tierce distincte (par exemple, SendGrid) pour les services de courrier, jamais sur la m\u00eame IP que l'entreprise ;<\/p>\n 4. le pare-feu du serveur refuse tout trafic par d\u00e9faut et n'ouvre que les ports n\u00e9cessaires aux segments IP fournis par le fournisseur de CDN. une liste des IP des n\u0153uds globaux est fournie directement dans la documentation de CDN07. n'oubliez pas de la mettre \u00e0 jour une fois par semaine.<\/p>\n II. mauvaise configuration des r\u00e8gles de protection : couvercle ouvert ne signifie pas pr\u00eat \u00e0 l'emploi<\/strong><\/p>\n Le cas le plus scandaleux que j'ai vu est celui d'une entreprise qui avait achet\u00e9 un pack de haute d\u00e9fense de qualit\u00e9 sup\u00e9rieure, mais dont le WAF n'avait m\u00eame pas activ\u00e9 la protection CC de base - parce qu'elle pensait qu'elle \u00e9tait \u201cactiv\u00e9e par d\u00e9faut\u201d. En fait, la plupart des CDN d'aujourd'hui, afin de r\u00e9duire le nombre de faux positifs, n'ouvrent que la base de r\u00e8gles de base par d\u00e9faut, comme les attaques lentes, les abus d'API, qui doivent \u00eatre configur\u00e9s manuellement.<\/p>\n D'autres ont fix\u00e9 des seuils de protection extr\u00eamement agressifs : une seule adresse IP est autoris\u00e9e \u00e0 recevoir 1 000 requ\u00eates par seconde, ce qui rend la protection CC pratiquement inexistante. Il est important de savoir que le pic du comportement r\u00e9el des utilisateurs ne d\u00e9passe g\u00e9n\u00e9ralement pas 20 requ\u00eates par seconde, sans compter que le \u201cmode intelligent\u201d de certains fournisseurs n'est en fait qu'un commutateur de seuil.<\/p>\n Solution :<\/strong><\/p>\n 1. la base de r\u00e8gles WAF est au moins ouverte au niveau \u201cstrict\u201d, n'ayez pas peur d'\u00eatre bloqu\u00e9 par erreur, c'est mieux que d'\u00eatre frapp\u00e9 par la pendaison ;<\/p>\n 2) R\u00e8gles de fr\u00e9quence personnalis\u00e9es : j'ai d\u00e9fini des seuils par type d'activit\u00e9. La passerelle API est limit\u00e9e \u00e0 50 fois par seconde pour une seule IP, les ressources statiques sont limit\u00e9es \u00e0 200 fois, et l'interface de connexion doit \u00eatre activ\u00e9e moins de 10 fois ;<\/p>\n 3. activer le mode de d\u00e9fi d'authentification humaine pour afficher directement le CAPTCHA en cas de trafic suspect. 08Host a fait un bon travail dans ce domaine et prend en charge plusieurs modes d'authentification non sensorielle et de d\u00e9fi JS ;<\/p>\n 4. consulter r\u00e9guli\u00e8rement les rapports d'attaque : se concentrer sur les sch\u00e9mas d'attaque qui visent \u00e0 contourner les r\u00e8gles, tels que des champs d'en-t\u00eate UserAgent ou XFF al\u00e9atoires.<\/p>\n Troisi\u00e8mement, les probl\u00e8mes de certificat et de compatibilit\u00e9 des protocoles : TLS peut \u00e9galement devenir une vuln\u00e9rabilit\u00e9.<\/strong><\/p>\n Nous avons rencontr\u00e9 une situation particuli\u00e8rement pitoyable : le client a achet\u00e9 une petite usine de CDN haute-d\u00e9fense, les r\u00e9sultats de l'autre partie ne supportent pas le protocole TLS1.3. Le site a \u00e9t\u00e9 contraint de r\u00e9trograder vers TLS1.2, et il s'est trouv\u00e9 qu'il a \u00e9t\u00e9 victime d'une attaque CC utilisant des failles du protocole, et le CPU a directement grimp\u00e9 en fl\u00e8che jusqu'\u00e0 atteindre sa pleine capacit\u00e9. Le plus souvent, la mauvaise configuration du certificat SSL conduit \u00e0 ce que le CDN ne puisse pas avoir une poign\u00e9e de main normale, le trafic retournant \u00e0 la source du nu non chiffr\u00e9.<\/p>\n Solution :<\/strong><\/p>\n 1) Testez la liaison enti\u00e8rement crypt\u00e9e avec Qualys SSL Labs :<\/p>\n 2. s'assurer que la cha\u00eene de certificats est compl\u00e8te et que les certificats interm\u00e9diaires doivent \u00eatre d\u00e9ploy\u00e9s. Il est recommand\u00e9 d'utiliser des services de gestion automatique des certificats, CDN5 et CDN07 fournissent tous deux un d\u00e9ploiement SSL en une seule \u00e9tape ;<\/p>\n 3. d\u00e9sactiver les anciens protocoles (SSLv3, TLS1.0) et forcer l'activation de l'extension SNI ;<\/p>\n 4) Le lien vers la source doit \u00e9galement \u00eatre crypt\u00e9, n'utilisez pas le protocole HTTP pour renvoyer \u00e0 la source - trop de gens ont \u00e9t\u00e9 victimes de cette pratique.<\/p>\n Quatri\u00e8mement, la mauvaise configuration de la r\u00e9solution DNS : l'angle mort du routage du trafic<\/strong><\/p>\n Le CDN haute d\u00e9fense consiste essentiellement \u00e0 planifier le trafic par le biais du DNS. Cependant, de nombreuses personnes ont mal configur\u00e9 les enregistrements CNAME, ou la valeur TTL est trop \u00e9lev\u00e9e, ce qui entra\u00eene une r\u00e9solution tardive lorsque l'attaque est d\u00e9clench\u00e9e. Dans le cas le plus extr\u00eame, le cache DNS peut durer plusieurs heures dans certaines r\u00e9gions, et l'entreprise s'est effondr\u00e9e bien avant que la strat\u00e9gie de d\u00e9fense ne prenne effet.<\/p>\n D'autres oublient d'appuyer sur la ligne de r\u00e9solution du trafic en premier lorsqu'ils passent d'un CDN \u00e0 haut niveau de d\u00e9fense \u00e0 un CDN normal. Le r\u00e9sultat de la commutation directe des enregistrements DNS est que certains utilisateurs vont vers l'ancien n\u0153ud, d'autres vers le nouveau, et qu'il y a un \u00e9cart dans la strat\u00e9gie de d\u00e9fense.<\/p>\n Solution :<\/strong><\/p>\n 1. toujours CNAME le nom de domaine vers le nom de domaine prot\u00e9g\u00e9 fourni par le CDN de haute d\u00e9fense d'abord, et ensuite le CDN vers la source ;<\/p>\n 2) R\u00e9gler le temps TTL plus court, 300 secondes pour une utilisation normale et 60 secondes pour une commutation d'urgence ;<\/p>\n 3. utiliser la fonction d'analyse multilin\u00e9aire de DNSPod ou de Cloudflare pour envoyer les n\u0153uds de haute d\u00e9fense individuellement dans la zone d'attaque ;<\/p>\n 4. effectuer r\u00e9guli\u00e8rement des tests de p\u00e9n\u00e9tration DNS :<\/p>\n V. Conflits entre les caract\u00e9ristiques des entreprises et les strat\u00e9gies de protection<\/strong><\/p>\n C'est le point le plus facilement n\u00e9glig\u00e9. Certaines entreprises ont elles-m\u00eames des caract\u00e9ristiques de demande \u00e0 haute fr\u00e9quence (telles que la connexion longue WebSocket, le streaming vid\u00e9o), l'ouverture aveugle d'une protection stricte conduira \u00e0 un grand nombre de faux positifs. Dans le cas d'une plateforme d'enseignement en ligne, le paquet vid\u00e9o Heartbeat est intercept\u00e9 par les r\u00e8gles CC, ce qui entra\u00eene une chute vertigineuse du nombre d'utilisateurs qui regardent la classe.<\/p>\n En outre, la protection de l'interface API doit \u00eatre trait\u00e9e s\u00e9par\u00e9ment. Les caract\u00e9ristiques de la requ\u00eate POST au format JSON sont diff\u00e9rentes de celles d'une requ\u00eate de forme normale et n\u00e9cessitent l'ajustement des r\u00e8gles de d\u00e9tection du WAF. La base de r\u00e8gles par d\u00e9faut de certains fournisseurs a un taux de d\u00e9tection inf\u00e9rieur \u00e0 30% pour les attaques API.<\/p>\n Solution :<\/strong><\/p>\n 1) Avant la mise en service du service, vous devez effectuer le test de la liste blanche : enregistrez le trafic r\u00e9el du service pour le lire et observez les r\u00e8gles de protection afin de neutraliser la situation ;<\/p>\n 2. les services WebSocket et de connexion longue pour prendre un canal de transfert d\u00e9di\u00e9, la politique de protection WebSocket de 08Host est optimis\u00e9e s\u00e9par\u00e9ment ;<\/p>\n 3. les services API permettent des modes de protection sp\u00e9ciaux pour se concentrer sur les nouveaux vecteurs d'attaque tels que l'analyse approfondie JSON et l'injection GraphQL ;<\/p>\n 4) L'analyse des journaux en temps r\u00e9el doit \u00eatre effectu\u00e9e, avec la pile ELK ou directement avec les services de journalisation du fournisseur de CDN pour d\u00e9tecter les mod\u00e8les anormaux de mani\u00e8re plus fiable qu'en s'appuyant simplement sur le WAF.<\/p>\n En conclusion<\/strong><\/p>\n Un CDN \u00e0 haute d\u00e9fense n'est pas un coffre-fort pr\u00eat \u00e0 l'emploi, mais un syst\u00e8me sophistiqu\u00e9 qui n\u00e9cessite une mise au point permanente. Une d\u00e9fense vraiment efficace = 70% de configuration correcte + 20% de surveillance et d'alerte + 10% de r\u00e9ponse d'urgence. Ne vous fiez pas enti\u00e8rement \u00e0 la \u201cprotection automatique\u201d du fournisseur, examinez la cartographie du trafic en temps r\u00e9el et effectuez r\u00e9guli\u00e8rement des exercices d'attaque et de d\u00e9fense.<\/p>\n Si vous voulez vraiment recommander - CDN07 est rentable pour les petites entreprises, CDN5 est pr\u00e9f\u00e9rable pour les sc\u00e9narios de trafic \u00e9lev\u00e9 avec Anycast Network, et vous pouvez regarder la solution de protection hybride de 08Host pour la recherche d'une personnalisation extr\u00eame. Mais n'oubliez pas qu'il n'existe pas de solution unique, mais seulement une strat\u00e9gie de s\u00e9curit\u00e9 it\u00e9rative et continue.<\/p>\n (Pas de probl\u00e8me apr\u00e8s avoir v\u00e9rifi\u00e9 ces \u00e9l\u00e9ments de configuration ? Envoyez-moi un message priv\u00e9 pour envoyer un rapport de diagnostic afin de d\u00e9terminer si vous \u00eates victime d'une attaque malveillante)<\/p>","protected":false},"excerpt":{"rendered":" R\u00e9cemment, j'ai aid\u00e9 mon ami \u00e0 enqu\u00eater sur un site web qui avait \u00e9t\u00e9 touch\u00e9 par un accrochage, je me suis connect\u00e9 \u00e0 l'arri\u00e8re-plan du CDN pour jeter un coup d'\u0153il, bon gars, le trafic d'attaque est presque en train de franchir le niveau T, mais la strat\u00e9gie de d\u00e9fense du CDN de haute d\u00e9fense est en fait comme une cuill\u00e8re qui fuit et qui n'a pas arr\u00eat\u00e9 quelques requ\u00eates. L'activit\u00e9 r\u00e9elle est paralys\u00e9e depuis longtemps, mais la console affiche \u00e9galement \u201ctout est normal\u201d, l'ironie de cette image peut \u00eatre utilis\u00e9e comme un film de propagande sur la s\u00e9curit\u00e9 des r\u00e9seaux. De nos jours, m\u00eame les CDN doivent \u201cpr\u00e9venir les co\u00e9quipiers\u201d. La protection de niveau T annonc\u00e9e par les fournisseurs semble bluffante, mais la configuration n'est pas correcte ou la compr\u00e9hension est biais\u00e9e, ce qui vous expose \u00e0 courir nu dans la fusillade de l'internet. J'ai test\u00e9 le march\u00e9 de cinq ou six services grand public de haute d\u00e9finition, et j'ai r\u00e9sum\u00e9 cinq des raisons les plus courantes de l'\u00e9chec des CDN de haute d\u00e9finition - certaines de ces raisons peuvent m\u00eame amener le support technique du fabricant \u00e0 se gratter la t\u00eate. Premi\u00e8rement, la fuite d'IP de la station source : vous pensez qu'elle est cach\u00e9e, mais en fait, elle se produit \u00e0 l'\u00e9tat nu L'erreur la plus fr\u00e9quente et la plus fatale<\/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-1052","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\/1052","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=1052"}],"version-history":[{"count":1,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/1052\/revisions"}],"predecessor-version":[{"id":1073,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/1052\/revisions\/1073"}],"wp:attachment":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/media?parent=1052"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/categories?post=1052"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/tags?post=1052"},{"taxonomy":"collection","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/collection?post=1052"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}