Je viens de terminer le d\u00e9ploiement d'un CDN de haute d\u00e9fense pour mon client, et le site web a plant\u00e9 directement. L'\u00e9cran blanc en arri\u00e8re-plan, les plaintes des utilisateurs comme des flocons de neige qui volent. Une v\u00e9rification des journaux, un bon gars, le pare-feu du serveur vers les n\u0153uds CDN sont bloqu\u00e9s - cette sc\u00e8ne, je peux la rencontrer sept ou huit fois par an.<\/p>\n
Les CDN \u00e0 haute d\u00e9fense et les pare-feu des serveurs ne sont pas des ennemis naturels, mais une mauvaise configuration peut les mettre en porte-\u00e0-faux. De nombreuses \u00e9quipes pensent que l'achat d'un service de protection est suffisant et, par cons\u00e9quent, leurs propres pare-feux sont devenus les plus grands attaquants. Aujourd'hui, nous allons ouvrir le d\u00e9bat pour expliquer clairement comment faire coexister pacifiquement ces deux fr\u00e8res.<\/p>\n
Pourquoi y a-t-il eu une guerre civile ?<\/strong>Les CDN sont des proxys par nature, et tout le trafic est transf\u00e9r\u00e9 \u00e0 partir des n\u0153uds CDN. Si votre pare-feu est toujours en mode liste blanche d'IP, qui ne lib\u00e8re que les IP d'utilisateurs r\u00e9els, toutes les requ\u00eates provenant des n\u0153uds CDN seront bloqu\u00e9es comme des bandits. J'ai constat\u00e9 de mani\u00e8re r\u00e9aliste que plus de 60% conflits de configuration sont dus \u00e0 cela.<\/p>\n Un client de commerce \u00e9lectronique est tomb\u00e9 dans ce pi\u00e8ge l'ann\u00e9e derni\u00e8re. Il a utilis\u00e9 le pack de protection sup\u00e9rieur de CDN07, mais a oubli\u00e9 d'ajuster les r\u00e8gles du pare-feu du serveur. Le jour de la promotion, tous les n\u0153uds CDN ont \u00e9t\u00e9 bloqu\u00e9s par leur propre pare-feu et ils ont directement perdu des millions de commandes. Ne croyez pas \u00e0 l'absurdit\u00e9 de la \"configuration par d\u00e9faut\", la s\u00e9curit\u00e9 et la disponibilit\u00e9 doivent \u00eatre ajust\u00e9es par vos propres soins.<\/p>\n La v\u00e9ritable solution est l'authentification bidirectionnelle<\/strong>.. Il est important que le pare-feu reconnaisse les n\u0153uds CDN et que le service CDN authentifie les serveurs backend. Voici un plan de configuration que j'ai mis au point dans le cadre d'un projet financier. En le suivant, vous \u00e9viterez les pi\u00e8ges du 99%.<\/p>\n Commen\u00e7ons par le probl\u00e8me le plus pr\u00e9judiciable de la liste blanche. Les principaux fournisseurs de services CDN rendent publics les segments IP de leurs n\u0153uds, qui doivent \u00eatre synchronis\u00e9s avec la liste autoris\u00e9e du pare-feu en temps r\u00e9el. Prenez CDN5 par exemple, les segments IP de leurs n\u0153uds asiatiques sont mis \u00e0 jour chaque semaine, vous devez \u00e9crire un script de crawl programm\u00e9 :<\/p>\n Si vous utilisez Cloudflare ou CDN07 ou d'autres services internationaux, les segments IP changent plus fr\u00e9quemment. Il est pr\u00e9f\u00e9rable d'utiliser leur API pour les mettre \u00e0 jour dynamiquement. Les n\u0153uds nationaux de 08Host sont plus stables, il suffit de les mettre \u00e0 jour une fois par mois, mais n'oubliez pas de mettre en place des alarmes d'exception - j'ai eu une interruption de service d'une demi-heure \u00e0 cause d'un retard dans la mise \u00e0 jour de la base de donn\u00e9es IP.<\/p>\n Une solution plus avanc\u00e9e consiste \u00e0 utiliser l'en-t\u00eate XFF pour la v\u00e9rification secondaire.<\/strong>. Le pare-feu ne lib\u00e8re que les adresses IP des n\u0153uds CDN, tandis que la couche d'application v\u00e9rifie l'utilisateur r\u00e9el via l'en-t\u00eate X-Forwarded-For. Ainsi, m\u00eame si la liste blanche n'est pas respect\u00e9e, il existe une deuxi\u00e8me barri\u00e8re :<\/p>\n Les r\u00e8gles du pare-feu doivent \u00eatre affin\u00e9es<\/strong>J'ai vu trop d'\u00e9quipes d\u00e9sactiver leur pare-feu pour \u00e9conomiser de l'argent. J'ai vu trop d'\u00e9quipes d\u00e9sactiver leur pare-feu pour \u00e9conomiser de l'argent, ce qui revient \u00e0 laisser la porte du coffre-fort grande ouverte. La bonne approche consiste \u00e0 limiter l'acc\u00e8s aux n\u0153uds CDN aux seuls ports n\u00e9cessaires. Par exemple, les serveurs web n'ouvrent que les ports 80\/443, les serveurs de base de donn\u00e9es ne sont pas expos\u00e9s au CDN. Avec iptables, il est possible d'\u00e9crire de cette mani\u00e8re :<\/p>\n N'oubliez pas de v\u00e9rifier la compatibilit\u00e9 du protocole<\/strong>. Certains pare-feu interceptent les en-t\u00eates de protocole sp\u00e9ciaux de CDN. Lors du d\u00e9bogage de la fonction WAF de CDN5 l'ann\u00e9e derni\u00e8re, j'ai d\u00e9couvert que leurs empreintes digitales anti-crawler \u00e9taient mal class\u00e9es en tant que charges malveillantes par le pare-feu du serveur. Ce n'est qu'en utilisant tcpdump pour saisir les paquets que j'ai d\u00e9couvert cela :<\/p>\n Maintenant, mon \u00e9quipe a pris une habitude : chaque fois que sur le nouveau service CDN avant, n\u00e9cessairement premier intranet miroir trafic test de compatibilit\u00e9. En termes simples, il s'agit de trouver un serveur pour refl\u00e9ter le trafic de l'environnement de production, et de lib\u00e9rer progressivement les n\u0153uds CDN pour observer les journaux du pare-feu.<\/p>\n La surveillance des alarmes est essentielle<\/strong>. Une fois la configuration termin\u00e9e, vous devez surveiller l'interception du pare-feu en temps r\u00e9el. Je recommande d'utiliser la pile ELK pour collecter les journaux iptables et d\u00e9finir des seuils d'alarme. Notifiez imm\u00e9diatement lorsque l'IP du n\u0153ud CDN est intercept\u00e9e un nombre anormal de fois :<\/p>\n Le dernier mot sur le choix de la marque : CDN5 a le moins d'IP de n\u0153uds, la meilleure gestion de pare-feu mais une capacit\u00e9 de protection g\u00e9n\u00e9rale ; CDN07 a le plus de n\u0153uds globaux, mais le segment IP change fr\u00e9quemment et les co\u00fbts de maintenance sont \u00e9lev\u00e9s ; la solution de compromis de 08Host est plus adapt\u00e9e aux entreprises de taille moyenne, et la latence domestique peut \u00eatre contr\u00f4l\u00e9e dans les 30 ms. Si vous recherchez la s\u00e9curit\u00e9 ultime, vous pouvez acheter leur paquet de n\u0153uds exclusif - bien que trois fois plus cher, vous n'avez pas \u00e0 partager les segments IP, les r\u00e8gles de pare-feu peuvent \u00eatre rationalis\u00e9es 70%.<\/p>\n De nos jours, m\u00eame les CDN doivent \"pr\u00e9venir les co\u00e9quipiers\", et en fin de compte, il s'agit toujours d'un manque de connaissance de la configuration. J'ai vu trop d'\u00e9quipes consid\u00e9rer le CDN de haute d\u00e9fense comme une solution miracle, mais ignorer les r\u00e9glages les plus \u00e9l\u00e9mentaires du pare-feu. Souvenez-vous d'un principe : la cha\u00eene de s\u00e9curit\u00e9 ne peut pas avoir un seul point de d\u00e9faillance, mais elle ne peut pas non plus se contredire. La prochaine fois, avant le d\u00e9ploiement, ex\u00e9cutez le script de configuration de cet article, cela vous \u00e9vitera d'\u00eatre r\u00e9veill\u00e9 par l'alarme au milieu de la nuit.<\/p>\n Une architecture vraiment excellente devrait permettre \u00e0 un CDN de haute d\u00e9fense et \u00e0 des pare-feu de serveurs de fonctionner ensemble comme la main droite et la main gauche. L'un \u00e0 la p\u00e9riph\u00e9rie pour transporter le flot de DDoS, l'autre sur l'intranet pour retirer la fuite du poisson. Tant que la configuration est correcte, la combinaison peut rendre l'attaquant compl\u00e8tement d\u00e9sesp\u00e9r\u00e9 - je suis responsable du syst\u00e8me financier le plus \u00e9lev\u00e9 \u00e0 porter une attaque de 800Gbps, la courbe de l'entreprise n'a pas trembl\u00e9 un peu.<\/p>\n Si votre configuration est correcte et que vous rencontrez toujours des probl\u00e8mes, il est probable que les param\u00e8tres de la pile TCP doivent \u00eatre optimis\u00e9s. Le trafic CDN est extr\u00eamement volatile, de sorte que les param\u00e8tres par d\u00e9faut de syn backlog et de timeout peuvent ne pas tenir la route. Mais c'est un autre sujet, je d\u00e9taillerai les pratiques d'optimisation TCP apr\u00e8s cinq cents likes.<\/p>","protected":false},"excerpt":{"rendered":" Je viens de terminer le d\u00e9ploiement d'un CDN de haute d\u00e9fense pour mon client, et le site web a plant\u00e9 directement. L'\u00e9cran blanc en arri\u00e8re-plan, les plaintes des utilisateurs comme des flocons de neige qui volent. Une v\u00e9rification des journaux, un bon gars, le pare-feu du serveur vers les n\u0153uds CDN sont bloqu\u00e9s - cette sc\u00e8ne, je peux la rencontrer sept ou huit fois par an. Les pare-feu CDN et serveur \u00e0 haute d\u00e9fense ne sont pas du tout des ennemis naturels, mais une mauvaise configuration peut les faire s'\u00e9touffer l'un l'autre. De nombreuses \u00e9quipes pensent qu'elles ont achet\u00e9 un service de protection et que tout ira bien, et par cons\u00e9quent, leurs propres pare-feu sont devenus les plus grands attaquants. Aujourd'hui, nous allons ouvrir la porte pour expliquer clairement comment faire coexister pacifiquement ces deux fr\u00e8res. Pourquoi y a-t-il une guerre civile ? L'essence du CDN est un proxy, tout le trafic est transf\u00e9r\u00e9 \u00e0 partir du n\u0153ud CDN. Si votre pare-feu est toujours ouvert en mode liste blanche d'IP, il ne lib\u00e9rera que l'IP r\u00e9elle de l'utilisateur, alors la demande du n\u0153ud CDN sera trait\u00e9e comme un bandit qui s'arr\u00eatera devant la porte.<\/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-1012","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\/1012","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=1012"}],"version-history":[{"count":1,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/1012\/revisions"}],"predecessor-version":[{"id":1113,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/1012\/revisions\/1113"}],"wp:attachment":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/media?parent=1012"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/categories?post=1012"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/tags?post=1012"},{"taxonomy":"collection","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/collection?post=1012"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}