Récemment, j'ai aidé un ami à vérifier une station qui avait été touchée par un accrochage, et j'ai découvert que bien qu'ils aient mis en place un CDN à haute défense, ils n'avaient pas vérifié si la défense était efficace ou non. Une fois l'attaque lancée, l'adresse IP de la station source a été directement exposée, et le CDN est devenu un piège. De nos jours, même les CDN doivent “prévenir les coéquipiers” - certains fournisseurs n'ont pas rédigé leurs propres documents de configuration pour les rendre compréhensibles.
Est-il vrai qu'un CDN de haute défense peut résister à une attaque ? N'écoutez pas les vantardises des vendeurs, vous devez le mesurer vous-même. J'ai vu trop de gens penser qu'ils avaient acheté le service pour être tranquilles, le résultat de la première vague de trafic sur le nu direct. Aujourd'hui, le chat des deux méthodes de test, j'ai marché sur la fosse au fil des ans a sorti de l'expérience, et peut même à son tour forcer le vendeur à vous donner la configuration.
Commençons par une douche froide : ce que vous pensez être “en vigueur” peut être une illusion.De nombreux fournisseurs n'activent la protection que pour certains nœuds par défaut, ou la politique de mise en cache est si mal définie que le trafic n'arrive même pas au centre de nettoyage. Le cœur du test tient en une phrase :Veiller à ce que tout le trafic d'attaque passe par le nœud de nettoyage du CDN, tandis que le site d'origine est totalement invisible.
Les deux méthodes ci-dessous, la première pour une vérification rapide et la seconde pour une simulation de haute tension, sont utilisées en combinaison pour une véritable tranquillité d'esprit.
Méthode 1 : Test de résolution DNS - basique mais mortel
Si vous ne faites pas cette étape correctement, tout sera inutile. J'ai constaté que plus de 30% des problèmes de configuration se situent au niveau de la résolution DNS. Beaucoup de gens changent le CNAME en pensant que c'était fini, mais ne connaissent pas le cache DNS local, la différence de temps TTL peut vous laisser courir nu pendant des heures.
N'oubliez jamais :Tout d'abord, utilisez dig ou nslookup pour vérifier les résultats de la résolution de votre nom de domaine.Idéalement, l'IP résolue doit être l'IP du nœud du fournisseur de CDN. Idéalement, l'IP résolue doit être l'IP du nœud du fournisseur de CDN et non l'IP de votre site source, comme avec cette commande :
Si le pop-up est votre IP source, dépêchez-vous de vérifier la configuration DNS. Ne riez pas, j'ai également rencontré un client le mois dernier, la valeur de l'enregistrement CNAME a été remplie avec la mauvaise lettre, la résolution retourne directement à la source, une “fausse protection” dure pendant trois mois.
Une mesure encore plus difficile à prendre seraitModifier le fichier Hosts local pour forcer la résolution vers le nœud CDN. Par exemple, vous pointez le nom de domaine vers l'IP de test fournie par le fournisseur de CDN, puis vous visitez le site web pour voir s'il est normal. S'il est normal, cela signifie que le lien de retour du nœud vers le site source passe ; s'il signale une erreur, il peut y avoir un problème avec la configuration du retour (comme l'en-tête de l'hôte ou le certificat).
Certains fournisseurs, comme CDN07, proposent un domaine de test dédié, de sorte que vous n'ayez pas à attendre que le DNS prenne effet pour vérifier l'état du nœud. Cette fonction est en fait très pratique, mais 80 % des vendeurs ne prendront pas l'initiative de vous le dire - après tout, mieux vaut plus que moins.
Méthode 2 : Test d'attaque simulée - Jouer pour de vrai est fiable
Il ne suffit pas d'analyser correctement, il faut prouver que le nœud peut réellement supporter l'attaque. Voici deux orientations recommandées : la simulation de trafic DDoS et le test d'attaque CC.
Tests DDoSIl est préférable de trouver un fournisseur avec lequel travailler. Des fournisseurs légitimes de haute défense tels que CDN5 et 08Host permettent aux clients de lancer des attaques simulées pendant la période de test (bien sûr, vous devez prendre rendez-vous à l'avance). Leurs ingénieurs garderont un œil sur le panneau de trafic pour vous aider à analyser l'effet de nettoyage. Ne vous battez pas à l'aveuglette, surtout les téméraires qui achètent un VPS et ouvrent hping3 - attention au risque d'être bloqué par le segment de réseau de l'opérateur.
Concentration lors des testsVariation de la latence et perte de paquets. Lors d'un nettoyage normal, les visites sur le site devraient être presque insensées, tout en surveillant l'arrière-plan pour voir le trafic de nettoyage monter en flèche. Par exemple, la dernière fois que j'ai mesuré le nœud 08Host, une inondation UDP de 200G par seconde a frappé le passé, la latence de l'entreprise n'a augmenté que de 20ms, c'est vraiment efficace.
Test d'attaque CCC'est plus adapté pour se faire plaisir. Utilisez un outil pour simuler un grand nombre de requêtes normales, comme l'analyse frénétique d'une page dynamique :
Prêtez attention à la courbe QPS et au code de statut renvoyé par la console CDN. Si un grand nombre de requêtes retournent directement à la source ou si le CPU de la source monte en flèche, cela signifie que les règles de CC ne sont pas en vigueur. Une bonne protection devrait être capable d'intercepter les requêtes malveillantes directement au niveau des nœuds périphériques, et même de renvoyer les défis CAPTCHA.
Voici une petite idée : les règles CC de certains fabricants ont des sensibilités par défaut ridiculement basses et il faut les mettre à rude épreuve avant qu'ils n'acceptent de les ajuster. Il est donc préférable d'y aller fort lors des tests et d'aller jusqu'au seuil de déclenchement pour bien faire les choses.
Une action sordide en prime : la rétro-propagation des chemins d'attaque avec les logs SSH
Si votre serveur source a activé SSH, allez directement dans les journaux /var/log/secure (systèmes Linux). Lors d'une attaque réelle, si le CDN n'est pas en vigueur, vous verrez de nombreuses tentatives d'ouverture de session provenant de l'IP réelle ; s'il est en vigueur, toutes les demandes ne devraient provenir que du segment d'IP source de retour du CDN.
Cette méthode est plus précise que l'examen des journaux d'entreprise, car les pirates balaient toujours le port 22 à la main, et ce type de trafic n'est pas mis en cache et retournera certainement à la source.
Le test n'est pas une opération ponctuelle
Ce n'est pas parce que cela fonctionne aujourd'hui que cela fonctionnera demain. En particulier lorsque votre site web a changé de fonctionnalités ou d'architecture, il est probable que certaines interfaces contournent à nouveau le CDN. Il est recommandé d'utiliser la méthode ci-dessus pour effectuer une vérification complète tous les trois mois, notamment en ce qui concerne la résolution DNS et le risque d'exposition du site source.
Une dernière riposte :La profondeur des CDN à haute définition n'est souvent pas dans la technologie mais dans l'entreprise. Certains vendeurs vous vendent 10G de protection, le réel peut partager le pool de bande passante ; prétendant que toute attaque peut être évitée, le résultat des règles CC doit ajouter de l'argent pour ouvrir. Les tests permettent non seulement de vérifier l'effet, mais aussi de les forcer à tenir leurs promesses.
Après tout, vous payez pour la sécurité, pas pour le confort psychologique.
