Récemment, j'ai aidé une station de commerce électronique à effectuer une intervention d'urgence, et j'ai rencontré un problème : le serveur n'était pas en panne, la bande passante n'était pas saturée, mais le site web était tellement bloqué que je ne pouvais même pas me connecter en arrière-plan. Après une demi-journée d'enquête, j'ai découvert que les pirates informatiques commençaient à jouer au "slow work" : chaque connexion avec vous prend une demi-heure, des milliers de faux utilisateurs peuvent occuper le pool de connexions simultanées, les utilisateurs sérieux ne peuvent tout simplement pas se faufiler.
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équence des requêtes, mais dans cette attaque, chaque requête est déguisée en trafic légitime, comme de l'eau qui coule à travers la pierre et qui draine lentement vos ressources. J'ai testé un pare-feu classique, la configuration par défaut est en fait un client unique avec une attaque POST lente qui entraîne le serveur back-end vers le bas.
La capacité d'un CDN à haut niveau de défense à éviter ce genre de situation dépend de deux points essentiels : sa capacité à identifier avec précision la demande de "broyage" et son audace à prendre l'initiative de couper les connexions anormales. La partie suivante du programme d'intégration de CDN5, CDN07 deux fournisseurs de la logique sous-jacente, en passant, crache quelques vendeurs fantaisistes mais pas d'utilisation de la fonction.
Commençons par le réglage du délai d'attente des requêtes. Il ne s'agit pas simplement de définir un délai global à la fin de la question, il doit être contrôlé à différents niveaux. Les clients frontaux vers les nœuds de bordure du CDN, les nœuds de bordure vers la station source, la politique de délai d'attente des deux liens doit être ajustée séparément. Ne croyez pas les vendeurs qui se vantent d'avoir un "timeout intelligent", j'ai vérifié la configuration par défaut de CDN07, le timeout par défaut du front-end est ramené à 300 secondes, c'est simplement une porte dérobée pour les attaques lentes.
C'est la manière recommandée de segmenter la configuration (en utilisant Nginx comme exemple) :
Prêtez une attention particulière au paramètre client_body_timeout - l'attaque POST lente consiste à transmettre lentement le corps de la requête pour consommer des ressources. Le test a révélé que si plus de 30 secondes ne se sont pas écoulées depuis le transfert du corps de la requête, 99,9% est une connexion malveillante. Il y a un point à rappeler : certains fournisseurs de CDN ont des paramètres de timeout cachés dans la "configuration avancée", la valeur par défaut est trop élevée, n'oubliez pas de la réduire manuellement.
Cependant, si vous vous fiez uniquement au délai d'attente pour intercepter les fichiers, vous risquez de nuire à l'envoi normal de fichiers volumineux. L'année dernière, lorsque nous avons effectué des tests de pénétration pour 08Host, nous avons constaté que le délai d'attente était réglé de manière trop agressive, ce qui faisait que le concepteur ne parvenait pas toujours à télécharger des fichiers PSD. Par la suite, nous avons ajouté une politique de timeout dynamique : le chemin /content/upload est assoupli à 120 secondes, tandis que les autres chemins conservent 30 secondes. Ce mouvement CDN5 fait assez intelligent, le soutien de la définition des seuils de temporisation par chemin d'URL.
L'identification des comportements anormaux est un jeu plus avancé. Les attaques lentes, tout en imitant les utilisateurs normaux, révèlent des caractéristiques 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éployé un ensemble de règles de détection sur CDN07, dont la logique de base consiste à compter l'"efficacité de connexion" de chaque IP :
Cet ensemble de règles est particulièrement efficace pour attraper les attaques lentes, mais il faut veiller à faire la distinction entre les robots d'indexation et les utilisateurs réels. Certains crawlers de moteurs de recherche ralentissent délibérément pour éviter de perturber le site, nous avons souffert de la perte de sites bloqués par erreur - plus tard, nous avons ajouté une liste blanche, le Googlebot vérifié pour assouplir la politique.
Ce qui m'a vraiment sauvé, ce sont les modules de planification intelligents de CDN5. Ils ne se contentent pas de prendre en compte le délai d'attente, mais le combinent également avec l'analyse de l'état de la pile TCP. Par exemple, s'il y a soudainement un grand nombre de connexions TCP bloquées dans l'état LAST_ACK, ou si la file d'attente SYN_RECV continue d'être pleine, le système déclenchera automatiquement le mode de nettoyage de l'attaque lente. Cette fonction est mesurée pour réduire l'intervention manuelle 70%, est le prix est un peu beau.
L'intervention d'urgence a également permis de découvrir une opération sordide : certains attaquants utilisent le combo HTTP lent + attaque CC à faible vitesse. La première attaque concerne le pool de connexions, qui ne lâche pas prise, et les attaques CC à faible vitesse qui consomment le CPU. Cette fois, le mécanisme de défense du lien CDN07 entre en jeu : lorsque la détection de connexions lentes et de requêtes à faible fréquence provenant du même segment IP, le segment C entier est noirci directement, plutôt que d'être tué à tort pour ne pas être épargné.
Enfin, une vraie suggestion : ne vous attendez pas à ce que le CDN empêche à lui seul toutes les attaques lentes. Du côté du client, nous avons mis en place trois couches de défense : la couche périphérique du CDN pour le blocage des délais, la couche WAF pour l'analyse comportementale et iptables pour la limitation des connexions simultanées sur le serveur source. En particulier, le réglage des paramètres du noyau Linux peut multiplier par trois la capacité du serveur à résister aux attaques lentes :
Les attaques lentes ne peuvent pas empêcher l'essence de la guerre de la consommation des ressources. L'année dernière, nous avons testé la capacité de trois fournisseurs de CDN à résister aux vitesses lentes, et CDN5 a gagné grâce à des pools de ressources élastiques - augmentant automatiquement la limite de connexion lorsqu'une attaque est détectée, et libérant les ressources une fois l'attaque terminée.08Host est le plus réaliste, bien que la fonction ne soit pas si fantaisiste, mais la configuration par défaut est plus sûre que les autres, et convient aux sites web de petite et moyenne taille qui ne veulent pas faire un grand tapage.
Les pirates deviennent de plus en plus sophistiqués et utilisent déjà des attaques lentes distribuées - chaque broiler n'ouvre que quelques connexions lentes et n'a pas l'air différent d'un utilisateur normal. À l'avenir, je crains que nous ne devions utiliser l'apprentissage automatique pour analyser les modèles de comportement des utilisateurs. À ce stade, cependant, le fait d'avoir bien paramétré les délais d'attente et la détection des anomalies a permis d'éliminer l'attaque lente 90%. N'oubliez pas que la politique de sécurité n'est pas aussi compliquée qu'elle en a l'air, l'essentiel est d'être capable de la mettre en œuvre.
Pour évaluer le CDN à haute défense, nous vous recommandons de créer 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écision, si la politique de nettoyage est vraiment efficace. Ne croyez pas les vendeurs qui se vantent d'une "protection à 100 %", j'ai testé un grand paquet de haute défense, les règles par défaut n'ont même pas arrêté l'attaque lente de base - en fin de compte, vous devez ajuster manuellement les règles.
La sécurité sur le web est un processus itératif d'attaque et de défense. Une stratégie qui fonctionne aujourd'hui peut être contournée demain. Maintenir la transparence de la configuration et répéter régulièrement les réactions d'urgence est beaucoup plus réaliste que d'accumuler les produits de sécurité. Après tout, de nos jours, même les CDN doivent "prévenir les coéquipiers" - certains fournisseurs, afin de réduire le taux de faux positifs, assouplissent intentionnellement les politiques de sécurité, les choses tournent mal au lieu de rejeter la faute sur la mauvaise configuration du client.
