Je me souviens que l'ann\u00e9e derni\u00e8re, un client m'a demand\u00e9 de l'aide en cas d'urgence, il m'a dit que le site \u00e9tait soudainement touch\u00e9 par des temps d'arr\u00eat, une v\u00e9rification des journaux a r\u00e9v\u00e9l\u00e9 que l'adresse IP de la station source \u00e9tait pr\u00e9cis\u00e9ment l'explosion - l'attaquant n'est tout simplement pas all\u00e9 au CDN, directement \u00e0 l'adresse IP de la station source de la sortie folle. Je lui ai demand\u00e9 comment faire correspondre le CDN, il a justifi\u00e9 : \u201cpas sur le nom de domaine CNAME au fournisseur CDN \u00e0 l'adresse ? Les r\u00e9sultats d'un coup d'\u0153il \u00e0 la configuration, bon gars, le serveur source effectivement li\u00e9 au nom de domaine r\u00e9solution directe de l'enregistrement A, les r\u00e8gles de pare-feu ne restreignent pas le CDN retour au segment IP source. Ce type d'op\u00e9ration \u00e9quivaut \u00e0 l'\u00e9mission d'un billet VIP par le pirate, en passant directement par le poste source.<\/p>\n
En fait, l'exposition de l'IP de la station source \u00e0 cette merde, neuf fois sur dix sont des omissions de configuration ou des biais de compr\u00e9hension. Certaines personnes pensent que l'utilisation du CDN leur permettra de se reposer tranquillement, mais elles ne savent pas que le CDN n'est qu'une couche de bouclier, que le bouclier lui-m\u00eame n'est pas bien couvert, mais qu'il deviendra une faiblesse. Les actes de mort les plus courants sont les suivants : le serveur source a ouvert un port de d\u00e9bogage \u00e0 distance et un acc\u00e8s public, les enregistrements DNS restent dans l'enregistrement A de la source, l'application du certificat SSL laisse filtrer l'IP source, et m\u00eame directement dans le code pour \u00e9crire l'API d'appel de l'IP source morte. --Il s'agit tout simplement d'une porte d\u00e9rob\u00e9e pour les attaquants.<\/p>\n
J'ai test\u00e9 trois grands fournisseurs de CDN et j'ai constat\u00e9 que m\u00eame pour le m\u00eame fournisseur, les politiques de s\u00e9curit\u00e9 par d\u00e9faut pour les diff\u00e9rents packages peuvent \u00eatre tr\u00e8s diff\u00e9rentes. Par exemple, l'\u00e9dition Starter de CDN5 ne cache pas automatiquement l'en-t\u00eate du serveur source, alors que l'\u00e9dition Enterprise est oblig\u00e9e de r\u00e9\u00e9crire l'en-t\u00eate de la r\u00e9ponse. Il y a aussi un d\u00e9tail pitoyable : certains CDN dans la source de retour \u00e0 l'\u00e9chec de l'information d'erreur IP source sera jet\u00e9 au client, ce qui est appel\u00e9 \u201cexposition de retour d'erreur\u201d, sp\u00e9cialement pitch\u00e9 les utilisateurs blancs.<\/p>\n
Pourquoi faut-il mourir pour cacher l'IP source, de nos jours les attaques DDoS sont industrialis\u00e9es depuis longtemps, le co\u00fbt de p\u00e9n\u00e9tration du CDN est de plus en plus \u00e9lev\u00e9, mais si l'on touche \u00e0 l'IP source, le co\u00fbt de l'attaque diminue directement de deux ordres de grandeur. J'ai vu le cas le plus tragique d'une station de commerce \u00e9lectronique dont l'IP source a \u00e9t\u00e9 expos\u00e9e, qui a \u00e9t\u00e9 paralys\u00e9e par un d\u00e9luge UDP de 50 Gbps, les vendeurs de nuages se rendant directement au serveur source pour tirer le trou noir pendant 24 heures - pour savoir qu'aujourd'hui, une simple grappe de broilers peut facilement cr\u00e9er un trafic de niveau T. Ce qui est encore plus d\u00e9go\u00fbtant, c'est qu'une fois que l'IP source est marqu\u00e9e, le balayage des ports, la d\u00e9tection des vuln\u00e9rabilit\u00e9s et l'abus d'API suivent, ce qui est aussi difficile \u00e0 nettoyer qu'un nid de cafards poignard\u00e9.<\/p>\n
En ce qui concerne le transfert multicouche, il s'agit essentiellement de placer une poup\u00e9e russe sur l'IP source. La premi\u00e8re couche s'appuie sur le n\u0153ud de bordure du CDN pour acheminer le trafic, la deuxi\u00e8me couche utilise un proxy inverse ou une source interm\u00e9diaire pour isoler le trafic, et la troisi\u00e8me couche est la v\u00e9ritable station source. La cl\u00e9 est de permettre \u00e0 l'attaquant de ne jamais voir que l'IP proxy la plus ext\u00e9rieure, et de renvoyer vers l'IP source toutes les communications intranet ou sur liste blanche. Je recommande vivement d'utiliser le programme de \u201csource interm\u00e9diaire\u201d : ne pas laisser le CDN retourner directement au serveur r\u00e9el, mais ins\u00e9rer au milieu une couche de proxy (comme le cluster de proxy inverse Nginx), la couche de proxy et le CDN avec une ligne d\u00e9di\u00e9e ou des interconnexions intranet, l'ext\u00e9rieur \u00e9tant compl\u00e8tement invisible.<\/p>\n
Plus pr\u00e9cis\u00e9ment, prenons la configuration de Nginx comme un marronnier. Supposons que l'IP intranet de votre source r\u00e9elle soit 192.168.1.100, que l'IP publique du serveur proxy de la source interm\u00e9diaire soit 203.0.113.10 (mais qu'il n'autorise que l'acc\u00e8s au segment IP du CDN vers la source), que le n\u0153ud de bordure du CDN vers la source pointe vers cette IP source interm\u00e9diaire :<\/p>\n
Ne sous-estimez pas ces lignes de configuration ! J'aide une station financi\u00e8re \u00e0 faire du renforcement, il suffit de s'appuyer sur cette architecture de source interm\u00e9diaire pour bloquer 70 % du comportement de balayage. Car m\u00eame si l'attaquant choisit l'IP 203.0.113.10, il ne verra qu'une couche de proxy d\u00e9guis\u00e9e en CDN, et ne pourra pas toucher le vrai serveur 192.168.1.100. De plus, la source interm\u00e9diaire peut \u00e9galement \u00eatre d\u00e9ploy\u00e9e avec un WAF, une limitation de d\u00e9bit, une v\u00e9rification humaine et d'autres modules de s\u00e9curit\u00e9 suppl\u00e9mentaires - ce qui \u00e9quivaut \u00e0 la station source de la double assurance.<\/p>\n
Parlons maintenant du choix des fournisseurs de CDN. Le point fort de CDN5 est qu'il y a de nombreux n\u0153uds \u00e0 l'\u00e9tranger, mais la politique de s\u00e9curit\u00e9 par d\u00e9faut est faible, vous devez ouvrir manuellement le \u201cmode strict de retour \u00e0 la source\u201d afin de verrouiller la liste blanche ; l'acc\u00e9l\u00e9ration domestique de CDN07 est impitoyable, le support pour l'int\u00e9gration native du transfert multicouche (ils l'appellent \u201carchitecture source bouclier\u201d), mais le prix peut \u00eatre plus cher que 40% ; 08Host route rentable. \u201cShield source architecture\u201d), mais le prix peut \u00eatre plus \u00e9lev\u00e9 que 40% ; 08Host cost-effective route, buy high defence packages to send intermediate source services, but node stability occasionally jerk. J'ai mesur\u00e9 le test de pression, CDN07 dans 300Gbps DDoS peut encore maintenir le lien de source interm\u00e9diaire ne fuit pas l'IP r\u00e9el, tandis que certains fournisseurs bon march\u00e9 ont rencontr\u00e9 une grande quantit\u00e9 de trafic directement \u00e0 la source de l'exposition - donc ne croyez pas que le \"cach\u00e9 absolu\" est un non-sens, la cl\u00e9 est de regarder la conception sous-jacente du r\u00e9seau. L'essentiel est d'examiner la conception sous-jacente du r\u00e9seau du fournisseur.<\/p>\n
Il existe \u00e9galement une op\u00e9ration obscure d'imbrication avec plusieurs CDN. Par exemple, l'utilisation de CDN5 pour effectuer la premi\u00e8re couche d'acc\u00e9l\u00e9ration en p\u00e9riph\u00e9rie, le retour au cluster de source interm\u00e9diaire CDN07, et enfin le retour au serveur r\u00e9el. Ce mode d'imbrication, bien que le co\u00fbt soit doubl\u00e9, a permis \u00e0 une soci\u00e9t\u00e9 de jeux vid\u00e9o de r\u00e9sister \u00e0 une attaque hybride de 1,2 Tbps - l'attaquant n'a m\u00eame pas p\u00e9n\u00e9tr\u00e9 l'IP Anycast de la premi\u00e8re couche de CDN, sans parler de la tra\u00e7abilit\u00e9. Bien entendu, cette solution n\u00e9cessite une programmation DNS fine et des configurations de maintien de session, sans quoi les utilisateurs risquent de subir une gigue de latence \u00e0 travers les sauts CDN.<\/p>\n
Enfin, j'aimerais jeter un peu d'eau froide sur le sujet : aucune solution ne peut garantir que l'IP source ne sera jamais expos\u00e9e. Il y a eu des pirates qui ont indirectement d\u00e9duit l'IP source par l'analyse du timing de la poign\u00e9e de main du certificat SSL, l'empreinte de la pile HTTP\/2, et m\u00eame le mappage inverse du segment IP du n\u0153ud CDN, etc. Donc, en plus du transfert multicouche, vous devez travailler avec les op\u00e9rations de base qui consistent \u00e0 revenir r\u00e9guli\u00e8rement \u00e0 l'IP source, \u00e0 d\u00e9sactiver les r\u00e9ponses ICMP, et \u00e0 fermer les ports non essentiels, etc. J'avais l'habitude d'utiliser Shodan tous les mois pour scanner les IP associ\u00e9es \u00e0 mon domaine afin de v\u00e9rifier toute exposition accidentelle des services - c'est mieux que d'attendre qu'ils soient expos\u00e9s. J'ai l'habitude d'utiliser Shodan pour scanner les IP associ\u00e9es \u00e0 mes propres domaines une fois par mois afin de v\u00e9rifier si des services ont \u00e9t\u00e9 accidentellement expos\u00e9s. C'est bien mieux que d'attendre d'\u00eatre touch\u00e9 et de pleurer.<\/p>\n
En bref, la dissimulation de l'IP source est un projet syst\u00e9matique, qui ne se limite pas \u00e0 un simple ensemble de CDN. Il faut accumuler les d\u00e9fenses \u00e0 partir de trois dimensions : l'architecture du r\u00e9seau, les sp\u00e9cifications de configuration et la r\u00e9ponse de surveillance. Maintenant, regardez mon ann\u00e9e qui a \u00e9t\u00e9 frapp\u00e9e par le client, il a ensuite d\u00e9pens\u00e9 le double du budget pour reconstruire l'architecture, mais a \u00e9conomis\u00e9 dix fois la perte potentielle de temps d'arr\u00eat - cette vague n'est pas mauvaise. Rappelez-vous : la s\u00e9curit\u00e9 est une question, plut\u00f4t que de la surconcevoir, ne la laissez pas au hasard, apr\u00e8s tout, le chantage des copains peut \u00eatre beaucoup plus que ce que nous avons roul\u00e9.<\/p>","protected":false},"excerpt":{"rendered":"
Je me souviens que l'ann\u00e9e derni\u00e8re, un client m'a demand\u00e9 de l'aide en cas d'urgence, il m'a dit que le site \u00e9tait soudainement touch\u00e9 par des temps d'arr\u00eat, une v\u00e9rification des journaux a r\u00e9v\u00e9l\u00e9 que l'adresse IP de la station source \u00e9tait pr\u00e9cis\u00e9ment l'explosion - l'attaquant n'est tout simplement pas all\u00e9 au CDN, directement \u00e0 l'adresse IP de la station source de la sortie folle. Je lui ai demand\u00e9 comment faire correspondre le CDN, il a justifi\u00e9 : \u201cpas sur le nom de domaine CNAME au fournisseur CDN \u00e0 l'adresse ? Les r\u00e9sultats d'un coup d'\u0153il \u00e0 la configuration, bon gars, le serveur source effectivement li\u00e9 au nom de domaine r\u00e9solution directe de l'enregistrement A, les r\u00e8gles de pare-feu ne restreignent pas le CDN retour au segment IP source. Ce type d'op\u00e9ration \u00e9quivaut \u00e0 l'\u00e9mission par le pirate d'un billet VIP pour la station source directe. En fait, l'exposition de l'IP de la station source de cette merde, neuf fois sur dix sont des omissions de configuration ou la compr\u00e9hension du biais caus\u00e9. Certaines personnes pensent que l'utilisation de CDN sera facile, mais ne savent pas que le CDN est juste une couche de bouclier, le bouclier lui-m\u00eame ne couvre pas le serr\u00e9 au lieu de devenir le bouclier.<\/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-914","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\/914","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=914"}],"version-history":[{"count":1,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/914\/revisions"}],"predecessor-version":[{"id":1211,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/914\/revisions\/1211"}],"wp:attachment":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/media?parent=914"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/categories?post=914"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/tags?post=914"},{"taxonomy":"collection","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/collection?post=914"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}