Je me souviens que l'année dernière, il y a eu une plateforme sociale, parce que l'attaque CC a directement asséché le système de commentaires, j'étais un membre de l'intervention d'urgence, j'ai été appelé tard dans la nuit, j'ai regardé les graphiques de surveillance comme des montagnes russes, la charge du serveur a instantanément explosé, cette scène est vraiment acide.
Quel est le problème avec cette attaque du CC ? Il s'agit simplement d'un grand nombre de requêtes, n'est-ce pas ? Mais il faut savoir qu'il s'agit d'une attaque du ventre mou - comme l'interface de commentaires, où l'interaction avec l'utilisateur est fréquente, la base de données lit et écrit beaucoup, une fois le flot de fausses demandes inondé, la réponse est lente, ou tout le service est en panne, l'utilisateur maudit ce petit problème, la crédibilité de la marque détruite est la véritable fin de l'histoire.
J'ai constaté que beaucoup d'équipes pensaient que le CDN était sur un grand oreiller, les résultats de l'attaque CC sont arrivés, le CDN s'est d'abord agenouillé - parce que la configuration n'a pas bien fonctionné, le trafic n'est pas filtré proprement, mais il est devenu un complice. De nos jours, même le CDN doit être ‘anti-teammate‘, ne croyez pas que ces "protection à clé unique" des mots fantômes, la défense précise doit le faire vous-même.
La racine du problème réside dans le fait que les attaques CC simulent le comportement réel des utilisateurs, comme les soumissions de commentaires à haute fréquence et les rafraîchissements de pages, où les pare-feu traditionnels peuvent tuer par erreur le trafic normal, et où les stratégies de mise en cache CDN ordinaires ne peuvent pas bloquer les requêtes dynamiques. Les interfaces de commentaires de messages sont généralement des points d'extrémité d'API, tels que/api/comments/postLes attaquants utilisent un réseau de zombies pour envoyer des requêtes POST insensées, chacune contenant un peu de données inutiles, le serveur n'a plus qu'à traiter ces requêtes, le pool de connexions à la base de données est saturé, l'utilisateur normal est naturellement bloqué.
Par exemple, une fois j'ai aidé une application sociale à faire un audit, leur interface de commentaires ne limitait pas la vitesse, la même IP peut envoyer des centaines de commentaires en une minute, les résultats ont été piratés avec un proxy IP pool wild brush, le pic QPS (requêtes par seconde) s'est précipité à plus de 100 000, le serveur directement 503. En regardant les journaux après coup, la plupart des requêtes User-Agent sont forgées, l'IP source est partout dans le monde, mais Pattern est très cohérent - intervalles courts, petits paquets, objectif clair.
Le choix du CDN est la clé, j'en ai comparé quelques-uns - CDN5 dans la mise en cache intelligente et l'élasticité de l'expansion du taureau, particulièrement adapté au trafic soudain ; CDN07 WAF (Web Application Firewall) la base de règles est mise à jour rapidement, peut automatiquement identifier les caractéristiques CC ; 08Host cost-effective and flexible custom rules for teams with tight budgets. La base de règles du WAF (Web Application Firewall) est mise à jour rapidement, peut identifier automatiquement les caractéristiques CC ; 08Host cost-effective, flexible custom rules, suitable for teams with tight budgets. Mais quel que soit votre choix, la configuration doit être ajustée à la main.
La première étape consiste à définir la limitation du débit dans la console de gestion du CDN. Par exemple, pour/api/comments/**Le chemin, définir une seule IP jusqu'à 5 requêtes par seconde, au-delà du code de statut 429 de retour. L'interface de configuration de CDN5 est intuitive, je l'ai souvent ainsi définie :
Ne jamais fixer un seuil trop strict, sinon de vrais utilisateurs seront blessés par erreur s'ils publient des commentaires plus rapidement - j'ai déjà marché sur ce terrain, une fois le seuil fixé à 3, et en conséquence, lorsque l'événement a eu lieu, les utilisateurs ont follement aimé, et les demandes normales ont été bloquées, et le numéro de téléphone de la plainte a été mis à mal. Plus tard, j'ai retenu la leçon et je l'ai ajusté dynamiquement en conjonction avec le référentiel de réputation IP.
La deuxième étape consiste à activer le défi CAPTCHA. Pour un trafic suspect, tel qu'un grand nombre de requêtes provenant de la même IP pendant une courte période de temps, le premier pop-up CAPTCHA pour ralentir le rythme de l'attaque. CDN07 prend en charge cette fonctionnalité, la configuration de l'attention de ne pas affecter l'expérience de l'utilisateur : seules les requêtes POST prennent effet, la requête GET (comme la lecture des commentaires) de libération. Exemple de code :
Je l'ai testé et j'ai trouvé qu'il pouvait éliminer l'attaque CC facile de 90%, mais les attaques avancées utiliseront l'OCR pour craquer le captcha, donc il doit être associé à d'autres moyens.
Les attaques par CC utilisent généralement des hôtes en nuage ou des IP proxy, et la liste noire est mise à jour en temps réel grâce à des sources de renseignements sur les menaces telles que AbuseIPDB. 08Host permet de télécharger des listes d'IP personnalisées, et j'ai écrit un script pour les synchroniser régulièrement :
Le géoblocage est également très utile - si l'entreprise ne dessert que le territoire national, il suffit de bloquer les IP d'outre-mer. Mais attention à ne pas tuer accidentellement les utilisateurs de VPN, il est préférable de laisser un canal sur liste blanche.
La quatrième étape, l'optimisation de la stratégie de cache. Les ressources statiques (telles que les avatars, les CSS) ont un cache plus long, les interfaces dynamiques (telles que la soumission de commentaires) ont un cache court ou désactivent le cache, forçant le trafic à passer par la détection WAF. Les règles de cache cdn5 peuvent être adaptées de cette manière :
De cette façon, chaque demande de commentaire retourne à la source pour être détectée, ce qui augmente le temps de latence, mais la sécurité avant tout. Je suggère d'utiliser un traitement asynchrone - les utilisateurs envoient des commentaires et renvoient d'abord le succès, le traitement de la file d'attente en arrière-plan, afin de réduire la pression en temps réel.
La cinquième étape consiste à renforcer le back-end ; les CDN ne sont pas des boulets d'argent et, en fin de compte, la défense doit revenir aux serveurs ; ajoutez un module de limitation de flux à la couche Nginx, par exemple, aveclimit_req_zone：
Cette règle signifie que le nombre maximum de requêtes par IP est de 5 par seconde, la rafale est autorisée à 10, au-delà du paramètre direct 503. Le paramètre de rafale ne doit pas être défini sans discernement - je l'ai une fois défini trop grand, l'attaque est arrivée dans la file d'attente, la mémoire a explosé. Combiné à la surveillance des journaux, l'ajustement en temps réel.
Enfin, la surveillance et la réaction. Définir des règles d'alerte : notification par SMS en cas de dépassement du QPS, taux d'erreur 5xx dépassé. Outils tels que Prometheus+Grafana, exemple de configuration Kanban :
N'attendez pas que les choses tournent mal pour vérifier - faites un exercice hebdomadaire d'attaque et de défense pour simuler une attaque de CC et tester l'efficacité de la défense. Mon équipe avait l'habitude de faire cela tout le temps, de trouver un moment pour nettoyer l'interface et voir si les règles étaient déclenchées.
CDN5, CDN07, 08Host ont leur propre automne, mais l'idée de base est la même : une défense en couches, des règles précises, une surveillance en temps réel. N'oubliez pas que la sécurité est un processus, pas un produit. Les avis des utilisateurs sont peu nombreux, derrière le système de confiance, il est difficile de les réparer.
Agissez dès maintenant : vérifiez la configuration de votre CDN, la limite de débit est-elle réglée, la liste noire des adresses IP est-elle mise à jour ? Si vous ne l'avez pas fait, les pirates informatiques pourraient venir vous ‘saluer" ce soir. N'hésitez pas à laisser un commentaire si vous avez des questions - ne laissez pas l'interface de commentaires devenir une zone sinistrée.
