Récemment, il y a toujours des copains qui me demandent si le CDN à haute sécurité n'est pas vraiment capable de prévenir les attaques CC ? C'est une bonne question, mais la réponse n'est pas si simple. J'ai vu trop de gens penser que l'achat d'un paquet de haute défense sera tout à fait correct, les résultats de l'attaque CC ont pénétré après le visage de la confusion. Aujourd'hui, parlons de cette question.
Une attaque CC est, pour parler franchement, une simulation d'un grand nombre de requêtes normales, épuisant les ressources de votre serveur. Il ne s'agit pas d'un DDoS qui s'attaque directement à la bande passante, mais d'un couteau lent qui coupe la viande, en particulier pour abattre l'unité centrale, les connexions à la base de données et les maillons faibles. J'ai subi une perte dans les premières années, lorsque je pensais que les règles du pare-feu étaient suffisamment strictes, les résultats de l'autre côté avec une demande lente à faible fréquence + Referer aléatoire ont facilement contourné la base de règles - de nos jours, même le CDN doit être ‘anti-teammate", après tout, certains des trafics d'attaque ressemblent plus à de vraies personnes ! aussi comme une vraie personne.
Pourquoi les CDN ordinaires ne peuvent-ils pas faire face ? Les attaques CC ciblent souvent les interfaces dynamiques, telles que la page de connexion, l'interface de recherche, la passerelle API, ces chemins sont fondamentalement incapables de mettre en cache. L'année dernière, pour m'aider à gérer l'urgence d'une station de commerce électronique, j'ai découvert que les attaquants se concentraient spécifiquement sur l'interface de chargement des revues de produits, 3000 requêtes par seconde étant toutes accompagnées d'un identifiant de session aléatoire “utilisateurs légitimes”, le WAF traditionnel ne peut pas faire la distinction entre l'ennemi et moi.
La valeur fondamentale d'un CDN de haute défense est ici : il ne s'agit pas simplement d'empiler de la bande passante, mais de s'appuyer sur l'analyse comportementale + les contraintes de fréquence pour effectuer une interception intelligente. Prenons l'exemple de CDN5, leur algorithme de suivi des empreintes digitales est vraiment quelque chose - j'ai découvert que la même IP, même si le remplacement fréquent de UserAgent, tant que les empreintes TCP et les caractéristiques de la poignée de main TLS sont les mêmes, le système peut toujours être associé au même sujet de l'attaque.
La configuration pratique réelle doit être combinée avec les caractéristiques de l'entreprise. Par exemple, pour la protection de l'interface API, je recommande généralement de procéder comme suit :
Bien sûr, les règles de Nginx ne suffisent pas. De nos jours, les attaques avancées ont une saveur d'apprentissage automatique - l'autre partie utilisera l'apprentissage par renforcement pour ajuster l'intervalle de requête, de sorte que vous pensiez que c'est l'utilisateur qui parcourt la page. Il est temps de s'appuyer sur le réseau d'intelligence globale du CDN. 08Host fait un meilleur travail à cet égard, en partageant les caractéristiques des attaques à travers le réseau en temps réel : dès qu'un nœud identifie un nouveau modèle CC, tous les nœuds périphériques mettront automatiquement à jour leurs règles de détection dans un délai de 15 minutes.
Ce qui m'énerve le plus, c'est que certaines personnes se targuent d'avoir une “défense illimitée”. Si l'on rencontre des attaques CC vraiment avancées, se contenter de s'appuyer sur le matériel pour les mener à bien, c'est chercher la mort. L'année dernière, un client a utilisé un certain CDN appelé protection de niveau T, les résultats ont été CC pénétrer dans la base de données. Plus tard, il a découvert que le problème résidait dans l'architecture - l'attaquant avait contourné le CDN pour résoudre directement l'IP source, 20 000 demandes de connexion par seconde directement le pool de connexion MySQL était plein. Ne croyez donc pas au fantôme de la “protection à clé unique”, la dissimulation de la station source, le filtrage des ports, le pool de connexion à la base de données pour limiter le flux de ces compétences de base ne sont pas en place, l'achat de CDN plus coûteux est également inutile.
Dans la pratique, vous devez également prêter attention au taux de faux positifs. Certains fournisseurs de CDN, pour que les données aient l'air bonnes, font en sorte que les utilisateurs normaux se débarrassent des CAPTCHA. Une bonne protection devrait être comme le pouls d'un vieux médecin chinois - vous devez faire la distinction entre le comportement de recherche et le brossage malveillant de l'interface. J'ai l'habitude de commencer par un seau pour échantillonner le trafic d'une semaine et déterminer statistiquement la fréquence d'accès de base de chaque URL. Par exemple, la page des coordonnées de l'utilisateur, dont le pic d'accès normal est de 50 fois par seconde, passe soudainement à 2000 fois, ce qui pose certainement un problème, mais si la grande promotion de la page de la liste des produits passe à 3000 fois par seconde, il peut s'agir d'un trafic normal.
Enfin, une leçon de larmes : un CDN à haute défense n'est pas une solution miracle. Une fois qu'il y avait un site financier par l'attaque CC, l'attaquant chaque demande avec de vrais cookies volés, l'apparence et la session normale exactement la même. À ce stade, l'analyse de la fréquence seule est inutile, et il faut finalement s'appuyer sur les règles commerciales pour arrêter la perte - par exemple, le même utilisateur n'a pas réussi à se connecter plus de 3 fois en 5 minutes pour forcer le verrouillage, ou vérifier le solde de l'interface de requête doit passer par la vérification MFA. La véritable protection est donc une guerre tridimensionnelle, le CDN n'étant que la première ligne de défense.
Revenons au début de la question : un CDN à haute défense peut-il empêcher le CC ? Oui, mais cela dépend de la manière dont il fonctionne. Les vendeurs se concentrent sur trois points : la fréquence des mises à jour de la bibliothèque d'empreintes digitales intelligentes, la granularité des règles personnalisées et la possibilité pour la station source de se cacher complètement.CDN5, modèle d'apprentissage en profondeur du taux de reconnaissance lent du CC, peut atteindre 92%, mais le prix est élevé ; CDN07, modèle de protection de l'API prêt à l'emploi, convient aux projets de petite et moyenne taille ; 08Host, faible latence du réseau Anycast mondial pour le commerce électronique transfrontalier. En fin de compte, il n'y a pas de meilleur CDN, mais seulement la conception d'architecture la plus appropriée.
Les vrais maîtres font de la défense en profondeur. Mon programme actuel est généralement le suivant : CDN front pour nettoyer le trafic → couche intermédiaire avec OpenResty pour restreindre le flux de la logique commerciale → station source du noyau pour régler les paramètres de connexion TCP. Ces trois couches de tamisage vers le bas, peut se précipiter à la base de données des demandes malveillantes moins de 0,1%. Rappelez-vous ah, la sécurité est un projet systématique, ne vous attendez pas à un seul produit peut vous donner le fond.
