À trois heures du matin, au milieu de la nuit, mon téléphone portable a vibré comme un fou. Le groupe d'alerte de surveillance a brossé trois écrans d'"anomalie HTTP 500 de la source" et de "bande passante en cours d'exécution 95%". Le cœur battant, j'ai saisi l'ordinateur portable connecté au VPN - l'arrière-plan de l'entreprise a été bloqué à l'ouverture, la charge du serveur source a grimpé à trois chiffres, les graphiques de trafic en temps réel montrent que le grill offshore est des milliers de demandes par seconde l'échelle de l'impact fou de nos services. Qu'y a-t-il de plus ironique ? Nous avons manifestement fait flamber l'argent d'un CDN de haute défense bien connu, et maintenant la console de protection est aussi silencieuse que si rien ne s'était passé.
Il s'agit d'une scène typique de pénétration d'un CDN à haute défense. Les attaquants ont contourné les règles de protection du CDN, ont touché directement votre IP source, et cette fois le soi-disant nettoyage de trillion, le WAF intelligent deviennent tous une pose. J'ai vu trop d'équipes dont la première réaction est de contacter le service client du CDN, de redémarrer le serveur ou même d'arrêter temporairement l'activité - ces opérations sont soit trop lentes, soit équivalentes à un suicide.
La discussion d'aujourd'hui ne porte pas sur des solutions théoriques, mais sur un manuel d'urgence pratique résumé après que j'ai personnellement mis les pieds dans le plat. La prochaine fois que vous constaterez qu'un CDN est une imposture, suivez les étapes ci-dessous et vous pourrez ramener votre entreprise dans la zone de sécurité en une demi-heure.
Étape 1 : Bloquer immédiatement le trafic provenant des stations sources directement connectées
La première fois que vous découvrez que vous avez été pénétré, ne vérifiez pas les journaux et ne cherchez pas la cause, sauvez d'abord votre vie. Le moyen le plus rapide est de bloquer l'accès à toutes les IP de retour non-CDN sur le pare-feu ou le groupe de sécurité du serveur. Prenons l'exemple de Cloudflare : le segment officiel des IP de retour est public, et d'autres fournisseurs tels que CDN5 et CDN07 fournissent également des listes exclusives d'IP de retour en arrière-plan. Blocage temporaire avec iptables :
Si vous utilisez un groupe de sécurité de plateforme cloud (comme AliCloud/AWS), il est plus rapide de modifier les règles directement. Remarque : veillez à confirmer à l'avance la plage d'adresses IP de retour du fournisseur de CDN, sinon le trafic normal risque d'être bloqué par erreur.
Étape 2 : Changement rapide des nœuds de haute défense et rafraîchissement de la résolution
Les CDN haute défense de nombreux fournisseurs proposent des nœuds de sauvegarde multi-lignes. Par exemple, le "Emergency Protection Mode" de CDN07 ou le "Resilient Shield Node" de 08Host, ces nœuds ont généralement des politiques de contrôle de fréquence et d'authentification plus strictes. Immédiatement après que la console ait changé de nœud, le TTL du DNS est ajusté à la baisse à 60 secondes (s'il était auparavant élevé) et la résolution est forcée d'être rafraîchie. Ne vous attendez pas à ce que le cache expire - les attaquants ne peuvent pas attendre que vous attendiez une demi-heure.
C'est là que l'on voit l'importance de la sélection. Je l'ai testé, et le réseau Anycast comme CDN5 permet de changer de nœud en quelques secondes, alors que certaines solutions moins chères nécessitent de lever manuellement des ordres de travail - attendre un ordre de travail au milieu de la nuit ? Attendez que la salle des serveurs fume.
Étape 3 : Remonter jusqu'à la personne qui a manqué l'IP de la station source
Après avoir comblé la faille, il est temps de régler les comptes. Quatre-vingt pour cent de l'exposition de l'IP source est due à des oublis de configuration. Les fuites les plus courantes sont les suivantes :
Recommandez une astuce : utilisez différents noms de domaine pour effectuer plusieurs résolutions DNS pour le même service, et observez quels domaines résolvent l'IP source. par exemple :
Si un nom de domaine se résout directement à l'IP source, cela signifie que la configuration de la résolution ne passe pas du tout par le CDN. J'ai vu une équipe sur DNSPOD avec CNAME, mais qui a oublié de supprimer l'enregistrement A précédent, ce qui équivaut à une porte dérobée pour l'attaquant.
Étape 4 : Renforcer la stratégie de furtivité du site source
Le CDN haute défense n'est pas une amulette universelle, le poste source lui-même doit être "furtif". Nous vous conseillons quelques astuces sournoises :
Partage d'une configuration Nginx que j'utilise moi-même pour intercepter automatiquement les requêtes non-CDN :
Étape 5 : Vérifier l'efficacité de la protection et la contrôler en permanence
Une fois l'opération d'urgence terminée, utilisez l'outil pour simuler l'attaque et vérifier que la protection est efficace. Nous recommandons deux widgets développés par nos soins :
Surveillez également le délai d'exécution et le taux d'erreur. Les CDN à haute défense peuvent tuer les utilisateurs normaux (par exemple, le CAPTCHA apparaît trop souvent) après avoir activé une protection stricte, vous devez donc ajuster la sensibilité en fonction de votre activité. Ne croyez pas à la "protection intelligente entièrement automatique" - je l'ai testée et au moins trois des modes intelligents sur le marché ne peuvent même pas empêcher les simples attaques CC.
Des tweets percutants sur la sélection des fournisseurs
De nos jours, le marché du CDN de haute défense est trop profond. Certains fournisseurs se vantent d'une "protection de 2Tbps", alors qu'en réalité ils utilisent les anciens nœuds de la pile matérielle ; il existe également des "pools de nettoyage partagés", une grosse attaque impliquant tous les clients. J'ai mesuré le trafic d'une attaque d'un petit fournisseur à 200 Gbps et toute la région s'est effondrée ; le service clientèle a même déclaré qu'il était "recommandé de passer à la version entreprise".
Comparez plusieurs fournisseurs de services courants :
Conseil sincère : ne vous contentez pas de regarder l'offre et les paramètres, construisez réellement un environnement de test pour jouer une vague de trafic à essayer. Un jour, un fournisseur m'a fait une démonstration de "protection réussie contre des attaques de 500 Gbps", et j'ai découvert par la suite qu'il s'agissait d'une donnée de brossage interne - de nos jours, même les CDN doivent "prévenir les coéquipiers".
Quelques derniers coups de gueule.
La pénétration du CDN haute défense n'est pas un problème technique, c'est le système d'exploitation et de maintenance et les capacités de réaction en cas d'urgence du miroir démoniaque. J'ai vu des équipes dépenser des millions pour acheter une protection, mais à cause d'une erreur de configuration DNS, toute la plaque s'est effondrée. J'ai également vu des cas où le CDN minimum + les règles auto-développées sont aussi stables que le Mont Taishan.
La solution vraiment fiable est toujours la suivante : supposer que le CDN doit être pénétré et que le site source doit être caché là où l'ennemi ne peut pas le trouver. Le principe de la confiance zéro est toujours vrai en matière de cybersécurité.
La prochaine fois que vous serez réveillé à minuit, j'espère que vous sourirez, que vous ouvrirez votre terminal et que vous ferez une série de combos, puis que vous vous rendormirez.
