Comment défendre votre serveur contre les attaques CC, je vais vous dire ce que j'ai fait !

Je me souviens que l'été dernier, j'étais paralysée sur le canapé en train de brosser un drame, le téléphone portable s'est soudain mis à vibrer comme un fou - tous les serveurs se sont mis à sonner l'alarme, le taux d'utilisation du processeur a grimpé à 100%, le site s'ouvre aussi lentement qu'un escargot en train de ramper. J'ai maudit ma mère, mon cœur a compris : ces quatre-vingts pour cent sont une autre attaque de CC. Pour être honnête, après tant d'années de fonctionnement et de maintenance, j'ai vu beaucoup de scènes de ce genre, mais à chaque fois je peux être en colère avec les dents, parce que les attaquants aiment toujours choisir tard dans la nuit, vous forçant à rester debout toute la nuit pour éteindre l'incendie.

L'attaque CC, pour le dire crûment, est un groupe de “robots” déguisés en utilisateurs normaux, fous de rafraîchir votre page web ou de soumettre une requête, le but n'est pas de pirater le système, mais de vivre jusqu'à ce que les ressources du serveur se tarissent, de sorte que les utilisateurs réels ne puissent pas y accéder. J'ai testé et constaté que cette chose est particulièrement dégoûtante, parce que ce n'est pas comme le DDoS traditionnel comme un flux énorme, mais au lieu de simuler l'opération avec une personne réelle comme, beaucoup de pare-feu de base tout droit à l'arrêt, pensant à tort qu'il s'agit d'une visite normale.

Une fois, l'une de mes stations de commerce électronique était en panne, la page de commande était bloquée, le téléphone de réclamation des clients était presque décroché et le patron s'est précipité directement dans la salle des serveurs pour me demander si je faisais du minage.

De nos jours, même les CDN doivent être ‘à l'épreuve des mats", sans parler de ces astuces sournoises.

À l'époque, j'avais entre les mains un serveur dépouillé, et je comptais sur Nginx pour me porter à bout de bras, et j'ai été instantanément dépassé. J'ai réalisé que je ne pouvais pas le faire seul, je devais faire une combinaison de choses. Ci-dessous, je décompose les miettes pour dire comment j'ai construit pas à pas le système de défense, vous pouvez vous y référer, mais ne le copiez pas, parce que chaque scénario d'entreprise est différent.

Tout d'abord, il ne faut pas commencer à faire n'importe quoi, il faut savoir à quoi ressemble l'attaque. Je me suis immédiatement connecté au système de surveillance, j'ai regardé les journaux en temps réel et j'ai constaté qu'une IP avait envoyé en quelques secondes des milliers de requêtes à la page de connexion, ce qui n'est évidemment pas normal. J'ai parcouru rapidement la ligne de commande, et voici la commande :

tail -f /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -20

Cette ligne de code répertorie les 20 adresses IP les plus fréquemment demandées, ce qui permet d'identifier les suspects en un coup d'œil. J'ai donc déjà mis en place une règle d'alerte dans Zabbix qui m'envoie automatiquement un message texte si une IP est demandée plus de 50 fois par seconde. Ne croyez pas à ces absurdités du genre “la surveillance est facultative”, sans elle, vous êtes comme un aveugle qui se bat, mais passivement.

Après avoir identifié la source de l'attaque, ma première réaction est de bloquer temporairement l'IP, en utilisant iptables pour débrancher la prise, par exemple :

iptables -A INPUT -s Adresse IP malveillante -j DROP

Mais cette astuce traite les symptômes mais pas la cause première, et l'attaquant peut continuer à s'amuser avec un segment IP différent. Je me suis donc tourné vers la configuration de la limitation de débit dans Nginx, qui est la meilleure solution. J'ai ajouté ce paragraphe au fichier nginx.conf :

Ce paramètre signifie que chaque requête IP peut être envoyée jusqu'à 10 fois par seconde, plus d'une partie du premier cache 20, puis plus du retour direct 429 d'erreur.

J'ai testé, cela peut bloquer la plupart des attaques CC de bas rang, mais rencontrer le point avancé, le pool IP grand, ou la lutte. Une fois, j'ai ajusté trop fort, bloqué par erreur quelques crawlers de moteur de recherche, le trafic SEO a chuté beaucoup, le patron et me trouver du thé, de sorte que les règles doivent être ajustées lentement, ne pas couper à travers le tableau.

Ensuite, j'ai décidé de passer par un service CDN pour filtrer le trafic vers les nœuds de périphérie. À ce moment-là, j'en ai comparé plusieurs, et j'ai finalement choisi CDN07.

Parce que leur protection intelligente n'est vraiment pas soufflante, peut automatiquement identifier les demandes malveillantes basées sur l'analyse comportementale, mais aussi avec l'accélération globale, le prix est également abordable. La configuration est également simple, je coupe l'analyse du nom de domaine à leur CNAME, puis ouvrir les règles de protection CC dans la console, le seuil est fixé à 100 demandes par seconde, plus que le défi du code de vérification. Après utilisation, la pression du serveur a immédiatement chuté de 80 %, la réponse du service client est également rapide, une fois au milieu de l'attaque de nuit, ils 5 minutes pour m'aider à ajuster les règles. De nos jours, un bon CDN est comme un garde du corps personnel, qui évite bien des maux de cœur.

Le CDN seul n'était pas suffisant, j'ai ajouté un Web Application Firewall (WAF) au niveau du serveur, en utilisant le logiciel libre ModSecurity.

Après l'installation, j'ai personnalisé certaines règles, comme la protection contre la force brute pour la page de connexion :

Cette règle vérifie les paramètres anormaux dans les demandes de connexion et les intercepte si le score cumulé est élevé. Je vous rappelle que les règles WAF ne doivent pas être copiées de l'Internet, vous devez les modifier lentement en fonction de votre propre activité. Une fois que j'ai ajouté une règle stricte, toutes les demandes d'API de mon propre APP ont été bloquées et les utilisateurs se sont retrouvés dans l'embarras, si bien que j'ai dû faire marche arrière du jour au lendemain. C'est une leçon de sang et de larmes que de passer par l'environnement de test avant d'aller en ligne !

J'ai également optimisé les ressources du serveur.

Par exemple, j'ai mis en cache les requêtes de la base de données et j'ai utilisé Redis pour stocker les données des hotspots afin de réduire la pression exercée par le fait d'appuyer directement sur MySQL. J'ai ajouté quelques réponses retardées au code pour renvoyer de fausses données pour les requêtes suspectes, épuisant ainsi les ressources de l'attaquant. Cette astuce est un peu dommageable, mais efficace, j'ai écrit un simple exemple de script PHP :

Cela ralentit la machine de l'attaquant, tandis que les utilisateurs normaux sont accélérés par le CDN et ressentent à peine le retard. Cependant, cette méthode doit être utilisée en conjonction avec la surveillance, sinon il serait désastreux de blesser accidentellement un ami.

En parlant de cela, je dois me plaindre, certains tutoriels aiment toujours recommander un “outil de protection en un clic”, en gonflant le ciel, j'en ai essayé quelques-uns, l'effet est inégal, et certains sont même accompagnés d'une porte dérobée.

Il n'y a pas de solution miracle pour se défendre contre les attaques CC, la clé est la profondeur multicouche : la couche réseau utilise le CDN pour transporter le trafic, la couche application utilise le WAF et le filtrage des limites de taux, et la couche données fait un bon travail de mise en cache pour réduire les effets négatifs.

Dans mon architecture actuelle, j'ai également ajouté des exercices réguliers, comme la simulation d'une attaque une fois par mois pour vérifier les vulnérabilités. Lors d'un exercice, j'ai découvert qu'une certaine interface API n'avait pas de limites et qu'elle avait failli devenir une brèche ; je me suis donc empressé de la corriger.

Enfin, parlons de l'état d'esprit. La défense, c'est un peu le jeu du chat et de la souris, les moyens d'attaque changent tous les jours, on ne peut pas se contenter de fixer les règles et de se coucher.

J'ai pris l'habitude de consulter les résumés des journaux tous les jours, de garder un œil sur les nouvelles informations relatives aux menaces et d'adapter les règles si nécessaire. Par exemple, l'année dernière, il y a eu une vague d'attaques sur les ressources statiques, j'ai donc limité la vitesse du répertoire d'images dans Nginx, et l'effet a été immédiat. En résumé, il faut rester vigilant et continuer à apprendre, ce qui est fondamental.

Après tout cela, mon serveur est maintenant solide comme un roc et n'a plus jamais été endommagé par une attaque CC.

Si vous venez d'entrer dans la fosse, rappelez-vous les points suivants : surveillance d'abord, réponse rapide ; couches de défense, ne pas se fier à un seul point ; outils à choisir fiables, tels que les fournisseurs de services CDN07 peuvent économiser beaucoup d'efforts ; enfin, c'est en forgeant qu'on devient forgeron, plus d'essais et plus d'ajustements.

Le chemin de la défense est long, mais si vous êtes prêt à le parcourir, vous trouverez toujours une méthode qui vous conviendra.