Récemment, j'ai été confronté à un problème : la station de commerce électronique d'un client a manifestement accroché un CDN à haute défense, ou plus de 100 000 fausses commandes ont été balayées. Le journal a révélé que l'attaquant avait parfaitement falsifié l'adresse IP du nœud CDN et que la demande avait directement contourné le système de protection. De nos jours, même le CDN doit “prévenir les coéquipiers” - vous pensez qu'un bouclier sur la sécurité, mais vous ne savez pas que la vérification de la station source n'est pas bonne, le CDN de haute sécurité deviendra le tremplin pour les attaquants.
Les attaques par usurpation d'adresse IP ne sont pas nouvelles. Mais de nombreuses personnes pensent que le CDN sera tranquille, ce qui est en fait une grave erreur. Les attaquants commenceront par analyser le segment IP du nœud CDN, puis forgeront un en-tête X-Forwarded-For de ce type, afin de faire passer le trafic indésirable pour du “trafic CDN légitime” et de le renvoyer directement à la station source. J'ai testé trois fournisseurs de services CDN l'année dernière, deux des configurations par défaut permettent en fait à n'importe quelle IP de déclarer qu'ils sont des nœuds CDN, cette faille de sécurité est tout simplement plus qu'une fuite de la passoire.
La cause principale est que beaucoup d'opérations et de maintenance font aveuglément confiance à la liste d'adresses IP fournie par le fournisseur de services CDN. Mais les IP des nœuds CDN sont mises à jour ah brother ! La liste des segments IP qui vient d'être mise à jour la semaine dernière peut être invalide cette semaine. Sans parler des fournisseurs de CDN qui utilisent des services en nuage avec des IP élastiques, les IP des nœuds changent plus vite que les livres. Vous espérez maintenir manuellement une liste blanche d'adresses IP ? Autant envoyer une invitation aux attaquants.
Tout d'abord, la vérification de l'IP source. N'utilisez pas le “CDN IP Segment Book” téléchargé sur internet, il expire plus vite que la durée de conservation d'un yaourt. J'ai maintenant changé tous les projets pour utiliser un mécanisme d'authentification dynamique : dans le panneau de contrôle du CDN pour générer un Token unique, et ensuite par le biais d'un en-tête personnalisé passé à la station source. La configuration Nginx du site source est directement morte en écriture :
Cette astuce est impitoyable en quoi ? Même si l'attaquant a falsifié l'IP, il ne peut pas obtenir le jeton. Nous avons testé CDN5 et CDN07, avec une vérification personnalisée de l'en-tête, le taux d'interception des requêtes illégales atteint directement 100%. Toutefois, il convient de noter que le jeton doit faire l'objet d'une rotation régulière, il est recommandé d'utiliser le système de gestion des clés pour mettre à jour automatiquement le jeton.
Le token seul ne suffit pas. L'année dernière, nous avons rencontré un cas où l'attaquant a eu recours à l'ingénierie sociale pour obtenir le token (un employé a jeté le fichier de configuration sur GitHub), cette fois nous avons besoin d'une deuxième ligne de défense - le fingerprinting. Le principe de cette technologie est en fait très simple : à chaque nœud CDN légitime correspond un filigrane numérique, tout comme les badges d'identification délivrés aux agents.
J'ai essayé cela sur le nœud de 08Host : injecter un bout de code JS spécifique dans la configuration du CDN, et le site source confirme l'identité en détectant cette empreinte. Par exemple, faire en sorte que le nœud CDN l'ajoute automatiquement lorsqu'il renvoie une réponse :
Lorsque la station source reçoit la demande, elle utilise le même algorithme pour vérifier la signature et rejette la demande si l'écart d'horodatage est supérieur à 5 secondes. L'aspect le plus ignoble de ce système est que même si l'attaquant obtient la clé, elle est inutile parce que l'horodatage et l'ID du nœud changent dynamiquement. Une implémentation spécifique peut être intégrée dans OpenResty en utilisant des scripts Lua :
Parlons maintenant de la surcharge de performance. Beaucoup de gens entendent parler d“”authentification cryptographique" et pensent que cela affectera les performances. En fait, lors du test réel, l'augmentation du délai de vérification d'une seule demande est inférieure à 2 ms. Comparé au coût de la paralysie par un DDoS, ce surcoût est presque négligeable. Mais attention au choix des algorithmes de clés, ne soyez pas idiot d'utiliser RSA comme une arme lourde, ECDSA ou HMAC-SHA256 sont tout à fait suffisants.
Récemment, pour aider une plateforme financière à effectuer des tests de pénétration, j'ai découvert une attaque plus insidieuse : l'attaquant va d'abord accéder légitimement au nœud CDN, capturer les caractéristiques de l'empreinte digitale de l'en-tête de la réponse, et ensuite essayer de rejouer l'attaque. À l'heure actuelle, il ne suffit pas de s'appuyer sur la vérification statique des signatures, il faut ajouter un mécanisme de numéro aléatoire à usage unique (Nonce). J'ai vu dans le contexte de gestion de CDN07 que la dernière version de leur générateur Nonce a été prise en charge, rafraîchissant automatiquement la valeur de la graine une fois toutes les 10 minutes.
En fait, la solution la plus rentable consiste à utiliser directement le SDK du fournisseur. Comme le module Edge Auth de CDN5 encapsule un ensemble complet de logique d'authentification, la station source n'a qu'à ajuster une API pour vérifier l'authenticité. Mais ne vous fiez pas entièrement aux solutions de boîte noire - j'ai vu une vulnérabilité où le SDK d'un fournisseur était exposé à des clés codées en dur. Mon approche consiste désormais à utiliser une authentification hybride : j'utilise le SDK du fournisseur pour effectuer le filtrage initial et je mets également en œuvre un autre ensemble de logique de vérification de la signature.
En ce qui concerne les configurations spécifiques, donnons un exemple de Nginx en action. La configuration suivante met en œuvre la triple protection de la liste blanche des adresses IP, de la vérification par jeton et de la signature par empreinte digitale en même temps :
Enfin, certains petits fournisseurs de services CDN, afin de réduire les coûts, sont trop paresseux pour effectuer les contrôles de sécurité de base. La dernière fois que j'ai testé un CDN appelé “intelligent high defence”, j'ai découvert qu'il plaçait en fait la logique de vérification sur l'exécution JS du client - ce qui n'est pas évident pour dire à l'attaquant “vite pour me contourner ? ”C'est un message clair pour les attaquants. Par conséquent, lors de la sélection du type d'équipe technique, le programme de protection doit être testé sur le terrain, et il ne faut pas se contenter de regarder l'avant-projet promotionnel.
Un système de protection vraiment fiable doit être multicouche et dynamique. La vérification de l'IP source n'est que la base, l'empreinte digitale est l'armature, et elle doit être associée à une série de mesures telles que l'analyse du comportement du trafic (pour détecter les modèles de demande anormaux) et la limitation du débit (pour empêcher les attaques CC). Je déploie maintenant des solutions pour tous les clients, et j'exigerai au moins une fois par mois un test de simulation de contournement - en matière de sécurité, il n'y a pas de programme unique.
Pour être honnête, au cours des trois dernières années, le volume des attaques par falsification d'adresses IP a plus que décuplé. Les outils d'attaque ont commencé à intégrer l'empreinte digitale des CDN, et n'importe quel outil open source peut automatiquement identifier les fournisseurs de CDN et capturer les caractéristiques des nœuds. Si la défense est toujours bloquée à la “configuration d'une liste blanche au niveau de la réflexion”, la brèche n'est plus qu'une question de temps.
Enfin, j'aimerais partager une leçon tirée de mes larmes : ne jamais divulguer les détails de la validation dans le journal des erreurs ! J'ai vu un système qui renvoie “Signature expirée” et “Token invalide” lorsque la vérification échoue, n'est-ce pas comme tendre un couteau à un attaquant ? L'approche correcte consiste à renvoyer “404 Not Found”, de sorte que l'attaquant ne puisse même pas connaître la raison de l'échec.
Se protéger contre les attaques de falsification de propriété intellectuelle revient à jouer au jeu du chat et de la souris ; il n'existe pas de solution miracle. L'essentiel est de mettre en place un système de défense en constante évolution, car les méthodes de l'attaquant sont elles aussi en constante évolution. D'après mon expérience du combat, la combinaison d'un jeton dynamique et d'un système de signature cryptographique peut encore bloquer l'attaque de falsification 90% à la source.
