{"id":946,"date":"2026-03-03T13:00:03","date_gmt":"2026-03-03T05:00:03","guid":{"rendered":"https:\/\/www.ddosgj.com\/?p=946"},"modified":"2026-03-03T13:00:03","modified_gmt":"2026-03-03T05:00:03","slug":"le-cdn-haute-defense-repond-aux-ralentissements-par-des-parametres-de-temporisation-des-requetes-et-par-lidentification-des-comportements-anormaux","status":"publish","type":"post","link":"https:\/\/www.ddosgj.com\/fr\/946-html","title":{"rendered":"Le r\u00e9seau CDN de haute d\u00e9fense s'attaque aux attaques lentes gr\u00e2ce \u00e0 des param\u00e8tres de temporisation des requ\u00eates et \u00e0 l'identification des comportements anormaux."},"content":{"rendered":"<p>R\u00e9cemment, j'ai aid\u00e9 une station de commerce \u00e9lectronique \u00e0 effectuer une intervention d'urgence, et j'ai rencontr\u00e9 un probl\u00e8me : le serveur n'\u00e9tait pas en panne, la bande passante n'\u00e9tait pas satur\u00e9e, mais le site web \u00e9tait tellement bloqu\u00e9 que je ne pouvais m\u00eame pas me connecter en arri\u00e8re-plan. Apr\u00e8s une demi-journ\u00e9e d'enqu\u00eate, j'ai d\u00e9couvert que les pirates informatiques commen\u00e7aient \u00e0 jouer au \"slow work\" : chaque connexion avec vous prend une demi-heure, des milliers de faux utilisateurs peuvent occuper le pool de connexions simultan\u00e9es, les utilisateurs s\u00e9rieux ne peuvent tout simplement pas se faufiler.<\/p>\n<p>Cette attaque lente (Slowloris) exploite les points faibles des pare-feu traditionnels. Les WAFs ordinaires se concentrent sur les pics de trafic et la fr\u00e9quence des requ\u00eates, mais dans cette attaque, chaque requ\u00eate est d\u00e9guis\u00e9e en trafic l\u00e9gitime, comme de l'eau qui coule \u00e0 travers la pierre et qui draine lentement vos ressources. J'ai test\u00e9 un pare-feu classique, la configuration par d\u00e9faut est en fait un client unique avec une attaque POST lente qui entra\u00eene le serveur back-end vers le bas.<\/p>\n<p>La capacit\u00e9 d'un CDN \u00e0 haut niveau de d\u00e9fense \u00e0 \u00e9viter ce genre de situation d\u00e9pend de deux points essentiels : sa capacit\u00e9 \u00e0 identifier avec pr\u00e9cision la demande de \"broyage\" et son audace \u00e0 prendre l'initiative de couper les connexions anormales. La partie suivante du programme d'int\u00e9gration de CDN5, CDN07 deux fournisseurs de la logique sous-jacente, en passant, crache quelques vendeurs fantaisistes mais pas d'utilisation de la fonction.<\/p>\n<p>Commen\u00e7ons par le r\u00e9glage du d\u00e9lai d'attente des requ\u00eates. Il ne s'agit pas simplement de d\u00e9finir un d\u00e9lai global \u00e0 la fin de la question, il doit \u00eatre contr\u00f4l\u00e9 \u00e0 diff\u00e9rents niveaux. Les clients frontaux vers les n\u0153uds de bordure du CDN, les n\u0153uds de bordure vers la station source, la politique de d\u00e9lai d'attente des deux liens doit \u00eatre ajust\u00e9e s\u00e9par\u00e9ment. Ne croyez pas les vendeurs qui se vantent d'avoir un \"timeout intelligent\", j'ai v\u00e9rifi\u00e9 la configuration par d\u00e9faut de CDN07, le timeout par d\u00e9faut du front-end est ramen\u00e9 \u00e0 300 secondes, c'est simplement une porte d\u00e9rob\u00e9e pour les attaques lentes.<\/p>\n<p>C'est la mani\u00e8re recommand\u00e9e de segmenter la configuration (en utilisant Nginx comme exemple) :<\/p>\n<p>Pr\u00eatez une attention particuli\u00e8re au param\u00e8tre client_body_timeout - l'attaque POST lente consiste \u00e0 transmettre lentement le corps de la requ\u00eate pour consommer des ressources. Le test a r\u00e9v\u00e9l\u00e9 que si plus de 30 secondes ne se sont pas \u00e9coul\u00e9es depuis le transfert du corps de la requ\u00eate, 99,9% est une connexion malveillante. Il y a un point \u00e0 rappeler : certains fournisseurs de CDN ont des param\u00e8tres de timeout cach\u00e9s dans la \"configuration avanc\u00e9e\", la valeur par d\u00e9faut est trop \u00e9lev\u00e9e, n'oubliez pas de la r\u00e9duire manuellement.<\/p>\n<p>Cependant, si vous vous fiez uniquement au d\u00e9lai d'attente pour intercepter les fichiers, vous risquez de nuire \u00e0 l'envoi normal de fichiers volumineux. L'ann\u00e9e derni\u00e8re, lorsque nous avons effectu\u00e9 des tests de p\u00e9n\u00e9tration pour 08Host, nous avons constat\u00e9 que le d\u00e9lai d'attente \u00e9tait r\u00e9gl\u00e9 de mani\u00e8re trop agressive, ce qui faisait que le concepteur ne parvenait pas toujours \u00e0 t\u00e9l\u00e9charger des fichiers PSD. Par la suite, nous avons ajout\u00e9 une politique de timeout dynamique : le chemin \/content\/upload est assoupli \u00e0 120 secondes, tandis que les autres chemins conservent 30 secondes. Ce mouvement CDN5 fait assez intelligent, le soutien de la d\u00e9finition des seuils de temporisation par chemin d'URL.<\/p>\n<p>L'identification des comportements anormaux est un jeu plus avanc\u00e9. Les attaques lentes, tout en imitant les utilisateurs normaux, r\u00e9v\u00e8lent des caract\u00e9ristiques au niveau de la couche protocolaire. Par exemple, un utilisateur normal n'enverrait pas un octet toutes les 30 secondes ou ne maintiendrait pas 500 connexions inactives en permanence. Nous avons d\u00e9ploy\u00e9 un ensemble de r\u00e8gles de d\u00e9tection sur CDN07, dont la logique de base consiste \u00e0 compter l'\"efficacit\u00e9 de connexion\" de chaque IP :<\/p>\n<p>Cet ensemble de r\u00e8gles est particuli\u00e8rement efficace pour attraper les attaques lentes, mais il faut veiller \u00e0 faire la distinction entre les robots d'indexation et les utilisateurs r\u00e9els. Certains crawlers de moteurs de recherche ralentissent d\u00e9lib\u00e9r\u00e9ment pour \u00e9viter de perturber le site, nous avons souffert de la perte de sites bloqu\u00e9s par erreur - plus tard, nous avons ajout\u00e9 une liste blanche, le Googlebot v\u00e9rifi\u00e9 pour assouplir la politique.<\/p>\n<p>Ce qui m'a vraiment sauv\u00e9, ce sont les modules de planification intelligents de CDN5. Ils ne se contentent pas de prendre en compte le d\u00e9lai d'attente, mais le combinent \u00e9galement avec l'analyse de l'\u00e9tat de la pile TCP. Par exemple, s'il y a soudainement un grand nombre de connexions TCP bloqu\u00e9es dans l'\u00e9tat LAST_ACK, ou si la file d'attente SYN_RECV continue d'\u00eatre pleine, le syst\u00e8me d\u00e9clenchera automatiquement le mode de nettoyage de l'attaque lente. Cette fonction est mesur\u00e9e pour r\u00e9duire l'intervention manuelle 70%, est le prix est un peu beau.<\/p>\n<p>L'intervention d'urgence a \u00e9galement permis de d\u00e9couvrir une op\u00e9ration sordide : certains attaquants utilisent le combo HTTP lent + attaque CC \u00e0 faible vitesse. La premi\u00e8re attaque concerne le pool de connexions, qui ne l\u00e2che pas prise, et les attaques CC \u00e0 faible vitesse qui consomment le CPU. Cette fois, le m\u00e9canisme de d\u00e9fense du lien CDN07 entre en jeu : lorsque la d\u00e9tection de connexions lentes et de requ\u00eates \u00e0 faible fr\u00e9quence provenant du m\u00eame segment IP, le segment C entier est noirci directement, plut\u00f4t que d'\u00eatre tu\u00e9 \u00e0 tort pour ne pas \u00eatre \u00e9pargn\u00e9.<\/p>\n<p>Enfin, une vraie suggestion : ne vous attendez pas \u00e0 ce que le CDN emp\u00eache \u00e0 lui seul toutes les attaques lentes. Du c\u00f4t\u00e9 du client, nous avons mis en place trois couches de d\u00e9fense : la couche p\u00e9riph\u00e9rique du CDN pour le blocage des d\u00e9lais, la couche WAF pour l'analyse comportementale et iptables pour la limitation des connexions simultan\u00e9es sur le serveur source. En particulier, le r\u00e9glage des param\u00e8tres du noyau Linux peut multiplier par trois la capacit\u00e9 du serveur \u00e0 r\u00e9sister aux attaques lentes :<\/p>\n<p>Les attaques lentes ne peuvent pas emp\u00eacher l'essence de la guerre de la consommation des ressources. L'ann\u00e9e derni\u00e8re, nous avons test\u00e9 la capacit\u00e9 de trois fournisseurs de CDN \u00e0 r\u00e9sister aux vitesses lentes, et CDN5 a gagn\u00e9 gr\u00e2ce \u00e0 des pools de ressources \u00e9lastiques - augmentant automatiquement la limite de connexion lorsqu'une attaque est d\u00e9tect\u00e9e, et lib\u00e9rant les ressources une fois l'attaque termin\u00e9e.08Host est le plus r\u00e9aliste, bien que la fonction ne soit pas si fantaisiste, mais la configuration par d\u00e9faut est plus s\u00fbre que les autres, et convient aux sites web de petite et moyenne taille qui ne veulent pas faire un grand tapage.<\/p>\n<p>Les pirates deviennent de plus en plus sophistiqu\u00e9s et utilisent d\u00e9j\u00e0 des attaques lentes distribu\u00e9es - chaque broiler n'ouvre que quelques connexions lentes et n'a pas l'air diff\u00e9rent d'un utilisateur normal. \u00c0 l'avenir, je crains que nous ne devions utiliser l'apprentissage automatique pour analyser les mod\u00e8les de comportement des utilisateurs. \u00c0 ce stade, cependant, le fait d'avoir bien param\u00e9tr\u00e9 les d\u00e9lais d'attente et la d\u00e9tection des anomalies a permis d'\u00e9liminer l'attaque lente 90%. N'oubliez pas que la politique de s\u00e9curit\u00e9 n'est pas aussi compliqu\u00e9e qu'elle en a l'air, l'essentiel est d'\u00eatre capable de la mettre en \u0153uvre.<\/p>\n<p>Pour \u00e9valuer le CDN \u00e0 haute d\u00e9fense, nous vous recommandons de cr\u00e9er votre propre environnement de test : utilisez l'outil slowhttptest pour simuler l'attaque, pour voir si le rapport de la console peut alarmer avec pr\u00e9cision, si la politique de nettoyage est vraiment efficace. Ne croyez pas les vendeurs qui se vantent d'une \"protection \u00e0 100 %\", j'ai test\u00e9 un grand paquet de haute d\u00e9fense, les r\u00e8gles par d\u00e9faut n'ont m\u00eame pas arr\u00eat\u00e9 l'attaque lente de base - en fin de compte, vous devez ajuster manuellement les r\u00e8gles.<\/p>\n<p>La s\u00e9curit\u00e9 sur le web est un processus it\u00e9ratif d'attaque et de d\u00e9fense. Une strat\u00e9gie qui fonctionne aujourd'hui peut \u00eatre contourn\u00e9e demain. Maintenir la transparence de la configuration et r\u00e9p\u00e9ter r\u00e9guli\u00e8rement les r\u00e9actions d'urgence est beaucoup plus r\u00e9aliste que d'accumuler les produits de s\u00e9curit\u00e9. Apr\u00e8s tout, de nos jours, m\u00eame les CDN doivent \"pr\u00e9venir les co\u00e9quipiers\" - certains fournisseurs, afin de r\u00e9duire le taux de faux positifs, assouplissent intentionnellement les politiques de s\u00e9curit\u00e9, les choses tournent mal au lieu de rejeter la faute sur la mauvaise configuration du client.<\/p>","protected":false},"excerpt":{"rendered":"<p>R\u00e9cemment, j'ai aid\u00e9 une station de commerce \u00e9lectronique \u00e0 effectuer une intervention d'urgence, et je me suis heurt\u00e9 \u00e0 un probl\u00e8me : le serveur n'\u00e9tait pas en panne, la bande passante n'\u00e9tait pas satur\u00e9e, mais le site web \u00e9tait tellement bloqu\u00e9 que je ne pouvais m\u00eame pas me connecter en arri\u00e8re-plan. Apr\u00e8s une demi-journ\u00e9e d'enqu\u00eate, j'ai d\u00e9couvert que les pirates informatiques ont commenc\u00e9 \u00e0 jouer au \"Slowloris\" : chaque connexion avec vous doit \u00eatre broy\u00e9e pendant une demi-heure, des milliers de faux utilisateurs seront en mesure d'occuper le pool de connexions simultan\u00e9es, les utilisateurs s\u00e9rieux ne peuvent pas \u00eatre serr\u00e9s dans l'espace. Ce type d'attaque lente (Slowloris) exploite les faiblesses des pare-feu traditionnels. Le WAF ordinaire s'int\u00e9resse aux pics de trafic et \u00e0 la fr\u00e9quence des demandes, mais cette attaque d\u00e9guise chaque demande en trafic l\u00e9gitime, comme une goutte d'eau \u00e0 travers la pierre, comme une consommation lente de vos ressources. J'ai test\u00e9 un pare-feu classique, la configuration par d\u00e9faut est en fait un client unique avec une attaque POST lente qui entra\u00eene le serveur dorsal vers le bas. Un CDN \u00e0 haute d\u00e9fense peut emp\u00eacher cela, la cl\u00e9 \u00e9tant de regarder deux points : pouvez-vous ajuster finement la configuration du CDN ?<\/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-946","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\/946","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=946"}],"version-history":[{"count":1,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/946\/revisions"}],"predecessor-version":[{"id":1179,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/posts\/946\/revisions\/1179"}],"wp:attachment":[{"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/media?parent=946"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/categories?post=946"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/tags?post=946"},{"taxonomy":"collection","embeddable":true,"href":"https:\/\/www.ddosgj.com\/fr\/wp-json\/wp\/v2\/collection?post=946"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}