R\u00e9cemment, j'ai aid\u00e9 un ami \u00e0 v\u00e9rifier une station qui avait \u00e9t\u00e9 touch\u00e9e par un accrochage, et j'ai d\u00e9couvert que bien qu'ils aient mis en place un CDN \u00e0 haute d\u00e9fense, ils n'avaient pas v\u00e9rifi\u00e9 si la d\u00e9fense \u00e9tait efficace ou non. Une fois l'attaque lanc\u00e9e, l'adresse IP de la station source a \u00e9t\u00e9 directement expos\u00e9e, et le CDN est devenu un pi\u00e8ge. De nos jours, m\u00eame les CDN doivent \u201cpr\u00e9venir les co\u00e9quipiers\u201d - certains fournisseurs n'ont pas r\u00e9dig\u00e9 leurs propres documents de configuration pour les rendre compr\u00e9hensibles.<\/p>\n
Est-il vrai qu'un CDN de haute d\u00e9fense peut r\u00e9sister \u00e0 une attaque ? N'\u00e9coutez pas les vantardises des vendeurs, vous devez le mesurer vous-m\u00eame. J'ai vu trop de gens penser qu'ils avaient achet\u00e9 le service pour \u00eatre tranquilles, le r\u00e9sultat de la premi\u00e8re vague de trafic sur le nu direct. Aujourd'hui, le chat des deux m\u00e9thodes de test, j'ai march\u00e9 sur la fosse au fil des ans a sorti de l'exp\u00e9rience, et peut m\u00eame \u00e0 son tour forcer le vendeur \u00e0 vous donner la configuration.<\/p>\n
Commen\u00e7ons par une douche froide : ce que vous pensez \u00eatre \u201cen vigueur\u201d peut \u00eatre une illusion.<\/strong>De nombreux fournisseurs n'activent la protection que pour certains n\u0153uds par d\u00e9faut, ou la politique de mise en cache est si mal d\u00e9finie que le trafic n'arrive m\u00eame pas au centre de nettoyage. Le c\u0153ur du test tient en une phrase :Veiller \u00e0 ce que tout le trafic d'attaque passe par le n\u0153ud de nettoyage du CDN, tandis que le site d'origine est totalement invisible.<\/strong><\/p>\n Les deux m\u00e9thodes ci-dessous, la premi\u00e8re pour une v\u00e9rification rapide et la seconde pour une simulation de haute tension, sont utilis\u00e9es en combinaison pour une v\u00e9ritable tranquillit\u00e9 d'esprit.<\/p>\n M\u00e9thode 1 : Test de r\u00e9solution DNS - basique mais mortel<\/strong><\/p>\n Si vous ne faites pas cette \u00e9tape correctement, tout sera inutile. J'ai constat\u00e9 que plus de 30% des probl\u00e8mes de configuration se situent au niveau de la r\u00e9solution DNS. Beaucoup de gens changent le CNAME en pensant que c'\u00e9tait fini, mais ne connaissent pas le cache DNS local, la diff\u00e9rence de temps TTL peut vous laisser courir nu pendant des heures.<\/p>\n N'oubliez jamais :Tout d'abord, utilisez dig ou nslookup pour v\u00e9rifier les r\u00e9sultats de la r\u00e9solution de votre nom de domaine.<\/strong>Id\u00e9alement, l'IP r\u00e9solue doit \u00eatre l'IP du n\u0153ud du fournisseur de CDN. Id\u00e9alement, l'IP r\u00e9solue doit \u00eatre l'IP du n\u0153ud du fournisseur de CDN et non l'IP de votre site source, comme avec cette commande :<\/p>\n Si le pop-up est votre IP source, d\u00e9p\u00eachez-vous de v\u00e9rifier la configuration DNS. Ne riez pas, j'ai \u00e9galement rencontr\u00e9 un client le mois dernier, la valeur de l'enregistrement CNAME a \u00e9t\u00e9 remplie avec la mauvaise lettre, la r\u00e9solution retourne directement \u00e0 la source, une \u201cfausse protection\u201d dure pendant trois mois.<\/p>\n Une mesure encore plus difficile \u00e0 prendre seraitModifier le fichier Hosts local pour forcer la r\u00e9solution vers le n\u0153ud CDN<\/strong>. Par exemple, vous pointez le nom de domaine vers l'IP de test fournie par le fournisseur de CDN, puis vous visitez le site web pour voir s'il est normal. S'il est normal, cela signifie que le lien de retour du n\u0153ud vers le site source passe ; s'il signale une erreur, il peut y avoir un probl\u00e8me avec la configuration du retour (comme l'en-t\u00eate de l'h\u00f4te ou le certificat).<\/p>\n Certains fournisseurs, comme CDN07, proposent un domaine de test d\u00e9di\u00e9, de sorte que vous n'ayez pas \u00e0 attendre que le DNS prenne effet pour v\u00e9rifier l'\u00e9tat du n\u0153ud. Cette fonction est en fait tr\u00e8s pratique, mais 80 % des vendeurs ne prendront pas l'initiative de vous le dire - apr\u00e8s tout, mieux vaut plus que moins.<\/p>\n M\u00e9thode 2 : Test d'attaque simul\u00e9e - Jouer pour de vrai est fiable<\/strong><\/p>\n Il ne suffit pas d'analyser correctement, il faut prouver que le n\u0153ud peut r\u00e9ellement supporter l'attaque. Voici deux orientations recommand\u00e9es : la simulation de trafic DDoS et le test d'attaque CC.<\/p>\n Tests DDoS<\/strong>Il est pr\u00e9f\u00e9rable de trouver un fournisseur avec lequel travailler. Des fournisseurs l\u00e9gitimes de haute d\u00e9fense tels que CDN5 et 08Host permettent aux clients de lancer des attaques simul\u00e9es pendant la p\u00e9riode de test (bien s\u00fbr, vous devez prendre rendez-vous \u00e0 l'avance). Leurs ing\u00e9nieurs garderont un \u0153il sur le panneau de trafic pour vous aider \u00e0 analyser l'effet de nettoyage. Ne vous battez pas \u00e0 l'aveuglette, surtout les t\u00e9m\u00e9raires qui ach\u00e8tent un VPS et ouvrent hping3 - attention au risque d'\u00eatre bloqu\u00e9 par le segment de r\u00e9seau de l'op\u00e9rateur.<\/p>\n Concentration lors des testsVariation de la latence et perte de paquets<\/strong>. Lors d'un nettoyage normal, les visites sur le site devraient \u00eatre presque insens\u00e9es, tout en surveillant l'arri\u00e8re-plan pour voir le trafic de nettoyage monter en fl\u00e8che. Par exemple, la derni\u00e8re fois que j'ai mesur\u00e9 le n\u0153ud 08Host, une inondation UDP de 200G par seconde a frapp\u00e9 le pass\u00e9, la latence de l'entreprise n'a augment\u00e9 que de 20ms, c'est vraiment efficace.<\/p>\n Test d'attaque CC<\/strong>C'est plus adapt\u00e9 pour se faire plaisir. Utilisez un outil pour simuler un grand nombre de requ\u00eates normales, comme l'analyse fr\u00e9n\u00e9tique d'une page dynamique :<\/p>\n Pr\u00eatez attention \u00e0 la courbe QPS et au code de statut renvoy\u00e9 par la console CDN. Si un grand nombre de requ\u00eates retournent directement \u00e0 la source ou si le CPU de la source monte en fl\u00e8che, cela signifie que les r\u00e8gles de CC ne sont pas en vigueur. Une bonne protection devrait \u00eatre capable d'intercepter les requ\u00eates malveillantes directement au niveau des n\u0153uds p\u00e9riph\u00e9riques, et m\u00eame de renvoyer les d\u00e9fis CAPTCHA.<\/p>\n Voici une petite id\u00e9e : les r\u00e8gles CC de certains fabricants ont des sensibilit\u00e9s par d\u00e9faut ridiculement basses et il faut les mettre \u00e0 rude \u00e9preuve avant qu'ils n'acceptent de les ajuster. Il est donc pr\u00e9f\u00e9rable d'y aller fort lors des tests et d'aller jusqu'au seuil de d\u00e9clenchement pour bien faire les choses.<\/p>\n Une action sordide en prime : la r\u00e9tro-propagation des chemins d'attaque avec les logs SSH<\/strong><\/p>\n Si votre serveur source a activ\u00e9 SSH, allez directement dans les journaux \/var\/log\/secure (syst\u00e8mes Linux). Lors d'une attaque r\u00e9elle, si le CDN n'est pas en vigueur, vous verrez de nombreuses tentatives d'ouverture de session provenant de l'IP r\u00e9elle ; s'il est en vigueur, toutes les demandes ne devraient provenir que du segment d'IP source de retour du CDN.<\/p>\n Cette m\u00e9thode est plus pr\u00e9cise que l'examen des journaux d'entreprise, car les pirates balaient toujours le port 22 \u00e0 la main, et ce type de trafic n'est pas mis en cache et retournera certainement \u00e0 la source.<\/p>\n Le test n'est pas une op\u00e9ration ponctuelle<\/strong><\/p>\n Ce n'est pas parce que cela fonctionne aujourd'hui que cela fonctionnera demain. En particulier lorsque votre site web a chang\u00e9 de fonctionnalit\u00e9s ou d'architecture, il est probable que certaines interfaces contournent \u00e0 nouveau le CDN. Il est recommand\u00e9 d'utiliser la m\u00e9thode ci-dessus pour effectuer une v\u00e9rification compl\u00e8te tous les trois mois, notamment en ce qui concerne la r\u00e9solution DNS et le risque d'exposition du site source.<\/p>\n Une derni\u00e8re riposte :La profondeur des CDN \u00e0 haute d\u00e9finition n'est souvent pas dans la technologie mais dans l'entreprise<\/strong>. Certains vendeurs vous vendent 10G de protection, le r\u00e9el peut partager le pool de bande passante ; pr\u00e9tendant que toute attaque peut \u00eatre \u00e9vit\u00e9e, le r\u00e9sultat des r\u00e8gles CC doit ajouter de l'argent pour ouvrir. Les tests permettent non seulement de v\u00e9rifier l'effet, mais aussi de les forcer \u00e0 tenir leurs promesses.<\/p>\n Apr\u00e8s tout, vous payez pour la s\u00e9curit\u00e9, pas pour le confort psychologique.<\/p>","protected":false},"excerpt":{"rendered":" R\u00e9cemment, j'ai aid\u00e9 un ami \u00e0 v\u00e9rifier une station qui avait \u00e9t\u00e9 touch\u00e9e par un accrochage, et j'ai d\u00e9couvert que bien qu'ils aient mis en place un CDN \u00e0 haute d\u00e9fense, ils n'avaient pas v\u00e9rifi\u00e9 si la d\u00e9fense \u00e9tait efficace ou non. Une fois l'attaque lanc\u00e9e, l'adresse IP de la station source a \u00e9t\u00e9 directement expos\u00e9e, et le CDN est devenu un pi\u00e8ge. De nos jours, m\u00eame les CDN doivent \u201cpr\u00e9venir les co\u00e9quipiers\u201d - certains fournisseurs n'ont pas \u00e9crit leurs propres documents de configuration pour les comprendre. Le CDN haute d\u00e9fense n'est pas vraiment capable de mener le combat ? N'\u00e9coutez pas les vantardises des vendeurs, seul leur propre test compte. J'ai vu trop de gens penser qu'ils avaient achet\u00e9 le service pour \u00eatre tranquilles, les r\u00e9sultats de la premi\u00e8re vague de trafic sur le nu direct. Le chat d'aujourd'hui des deux m\u00e9thodes de test, est mes ann\u00e9es de marcher sur la fosse est sorti de l'exp\u00e9rience, et peut m\u00eame \u00e0 son tour forcer le fabricant \u00e0 ajuster la configuration pour vous. Tout d'abord, versez de l'eau froide : vous pensez que l\u201c\u201defficace\" n'est peut-\u00eatre qu'une illusion. De nombreux fournisseurs n'utilisent par d\u00e9faut qu'une partie du n\u0153ud pour ouvrir la protection, ou la politique de mise en cache est mauvaise, le trafic ne va m\u00eame pas jusqu'au n\u0153ud.<\/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-995","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\/995","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=995"}],"version-history":[{"count":1,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/995\/revisions"}],"predecessor-version":[{"id":1130,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/995\/revisions\/1130"}],"wp:attachment":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/media?parent=995"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/categories?post=995"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/tags?post=995"},{"taxonomy":"collection","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/collection?post=995"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}