Récemment, j'ai aidé mon ami à enquêter sur un site web qui avait été touché par un accrochage, je me suis connecté à l'arrière-plan du CDN pour jeter un coup d'œil, bon gars, le trafic d'attaque est presque en train de franchir le niveau T, mais la stratégie de défense du CDN de haute défense est en fait comme une cuillère qui fuit et qui n'a pas arrêté quelques requêtes. L'activité réelle est paralysée depuis longtemps, mais la console montre également que “tout est normal”, ce qui est une image ironique qui peut être utilisée comme film de propagande sur la sécurité des réseaux.
De nos jours, même les CDN doivent “prévenir les coéquipiers”. La protection de niveau T annoncée par les fournisseurs semble bluffante, mais la configuration n'est pas correcte ou la compréhension est biaisée, ce qui vous expose à courir nu dans la fusillade de l'internet. J'ai testé le marché de cinq ou six services grand public de haute défense, et j'ai résumé cinq des raisons les plus courantes de l'échec des CDN de haute défense - certaines de ces raisons peuvent même laisser les fabricants de l'assistance technique se gratter la tête.
Tout d'abord, la station source IP leakage : vous pensez qu'elle est cachée, en fait, dans la station nue.
L'erreur la plus courante et la plus fatale. Beaucoup de webmasters pensent que l'ensemble du CDN sera tranquille, mais ne savent pas que les minutes de l'attaquant peuvent identifier l'IP réelle de votre serveur. Une fois que l'IP de la station source est exposée, le trafic d'attaque contourne directement le CDN à haute défense vers le serveur, ce qui est une protection est devenu un piège.
L'année dernière, j'ai aidé un site de commerce électronique à effectuer des tests de pénétration, et j'ai utilisé un outil d'empreinte digitale open source pour scanner directement l'IP source - simplement parce qu'ils avaient oublié de supprimer la source pointant dans l'enregistrement A d'un sous-domaine. Il est plus courant de passer par le serveur de messagerie, les anciens sous-domaines et même les informations du certificat SSL pour vérifier l'IP à rebours.
Solution :
1. isoler strictement le chemin d'accès à la station source et n'autoriser que le segment IP de retour du CDN à accéder au port du serveur. Un réseau backhaul privé comme celui fourni par CDN5 fonctionne très bien, et vous pouvez également personnaliser les tunnels cryptés ;
2. utiliser régulièrement l'outil pour auto-vérifier les risques d'exposition à la propriété intellectuelle :
3. une solution tierce distincte (par exemple, SendGrid) pour les services de courrier, jamais sur la même IP que l'entreprise ;
4. le pare-feu du serveur refuse tout trafic par défaut et n'ouvre que les ports nécessaires aux segments IP fournis par le fournisseur de CDN. une liste des IP des nœuds globaux est fournie directement dans la documentation de CDN07. n'oubliez pas de la mettre à jour une fois par semaine.
II. mauvaise configuration des règles de protection : couvercle ouvert ne signifie pas prêt à l'emploi
Le cas le plus scandaleux que j'ai vu est celui d'une entreprise qui avait acheté un pack de haute défense de qualité supérieure, mais dont le WAF n'avait même pas activé la protection CC de base - parce qu'elle pensait qu'elle était “activée par défaut”. En fait, la plupart des CDN d'aujourd'hui, afin de réduire le nombre de faux positifs, n'ouvrent que la base de règles de base par défaut, comme les attaques lentes, les abus d'API, qui doivent être configurés manuellement.
D'autres ont fixé des seuils de protection extrêmement agressifs : une seule adresse IP est autorisée à recevoir 1 000 requêtes par seconde, ce qui rend la protection CC pratiquement inexistante. Il est important de savoir que le pic du comportement réel des utilisateurs ne dépasse généralement pas 20 requêtes par seconde, sans compter que le “mode intelligent” de certains fournisseurs n'est en fait qu'un commutateur de seuil.
Solution :
1. la base de règles WAF est au moins ouverte au niveau “strict”, n'ayez pas peur d'être bloqué par erreur, c'est mieux que d'être frappé par la pendaison ;
2) Règles de fréquence personnalisées : j'ai défini des seuils par type d'activité. La passerelle API est limitée à 50 fois par seconde pour une seule IP, les ressources statiques sont limitées à 200 fois, et l'interface de connexion doit être activée moins de 10 fois ;
3. activer le mode de défi d'authentification humaine pour afficher directement le CAPTCHA en cas de trafic suspect. 08Host a fait un bon travail dans ce domaine et prend en charge plusieurs modes d'authentification non sensorielle et de défi JS ;
4. consulter régulièrement les rapports d'attaque : se concentrer sur les schémas d'attaque qui visent à contourner les règles, tels que des champs d'en-tête UserAgent ou XFF aléatoires.
Troisièmement, les problèmes de certificat et de compatibilité des protocoles : TLS peut également devenir une vulnérabilité.
Nous avons rencontré une situation particulièrement pitoyable : le client a acheté une petite usine de CDN haute-défense, les résultats de l'autre partie ne supportent pas le protocole TLS1.3. Le site a été contraint de rétrograder vers TLS1.2, et il s'est trouvé qu'il a été victime d'une attaque CC utilisant des failles du protocole, et le CPU a directement grimpé en flèche jusqu'à atteindre sa pleine capacité. Le plus souvent, la mauvaise configuration du certificat SSL conduit à ce que le CDN ne puisse pas avoir une poignée de main normale, le trafic retournant à la source du nu non chiffré.
Solution :
1) Testez la liaison entièrement cryptée avec Qualys SSL Labs :
2. s'assurer que la chaîne de certificats est complète et que les certificats intermédiaires doivent être déployés. Il est recommandé d'utiliser des services de gestion automatique des certificats, CDN5 et CDN07 fournissent tous deux un déploiement SSL en une seule étape ;
3. désactiver les anciens protocoles (SSLv3, TLS1.0) et forcer l'activation de l'extension SNI ;
4) Le lien vers la source doit également être crypté, n'utilisez pas le protocole HTTP pour renvoyer à la source - trop de gens ont été victimes de cette pratique.
Quatrièmement, la mauvaise configuration de la résolution DNS : l'angle mort du routage du trafic
Le CDN haute défense consiste essentiellement à planifier le trafic par le biais du DNS. Cependant, de nombreuses personnes ont mal configuré les enregistrements CNAME, ou la valeur TTL est trop élevée, ce qui entraîne une résolution tardive lorsque l'attaque est déclenchée. Dans le cas le plus extrême, le cache DNS peut durer plusieurs heures dans certaines régions, et l'entreprise s'est effondrée bien avant que la stratégie de défense ne prenne effet.
D'autres oublient d'appuyer sur la ligne de résolution du trafic en premier lorsqu'ils passent d'un CDN à haut niveau de défense à un CDN normal. Le résultat de la commutation directe des enregistrements DNS est que certains utilisateurs vont vers l'ancien nœud, d'autres vers le nouveau, et qu'il y a un écart dans la stratégie de défense.
Solution :
1. toujours CNAME le nom de domaine vers le nom de domaine protégé fourni par le CDN de haute défense d'abord, et ensuite le CDN vers la source ;
2) Régler le temps TTL plus court, 300 secondes pour une utilisation normale et 60 secondes pour une commutation d'urgence ;
3. utiliser la fonction d'analyse multilinéaire de DNSPod ou de Cloudflare pour envoyer les nœuds de haute défense individuellement dans la zone d'attaque ;
4. effectuer régulièrement des tests de pénétration DNS :
V. Conflits entre les caractéristiques des entreprises et les stratégies de protection
C'est le point le plus facilement négligé. Certaines entreprises ont elles-mêmes des caractéristiques de demande à haute fréquence (telles que la connexion longue WebSocket, le streaming vidéo), l'ouverture aveugle d'une protection stricte conduira à un grand nombre de faux positifs. Dans le cas d'une plateforme d'enseignement en ligne, le paquet vidéo Heartbeat est intercepté par les règles CC, ce qui entraîne une chute vertigineuse du nombre d'utilisateurs qui regardent la classe.
En outre, la protection de l'interface API doit être traitée séparément. Les caractéristiques de la requête POST au format JSON sont différentes de celles d'une requête de forme normale et nécessitent l'ajustement des règles de détection du WAF. La base de règles par défaut de certains fournisseurs a un taux de détection inférieur à 30% pour les attaques API.
Solution :
1) Avant la mise en service du service, vous devez effectuer le test de la liste blanche : enregistrez le trafic réel du service pour le lire et observez les règles de protection afin de neutraliser la situation ;
2. les services WebSocket et de connexion longue pour prendre un canal de transfert dédié, la politique de protection WebSocket de 08Host est optimisée séparément ;
3. les services API permettent des modes de protection spéciaux pour se concentrer sur les nouveaux vecteurs d'attaque tels que l'analyse approfondie JSON et l'injection GraphQL ;
4) L'analyse des journaux en temps réel doit être effectuée, avec la pile ELK ou directement avec les services de journalisation du fournisseur de CDN pour détecter les modèles anormaux de manière plus fiable qu'en s'appuyant simplement sur le WAF.
En conclusion
Un CDN à haute défense n'est pas un coffre-fort prêt à l'emploi, mais un système sophistiqué qui nécessite une mise au point permanente. Une défense vraiment efficace = 70% de configuration correcte + 20% de surveillance et d'alerte + 10% de réponse d'urgence. Ne vous fiez pas entièrement à la “protection automatique” du fournisseur, examinez la cartographie du trafic en temps réel et effectuez régulièrement des exercices d'attaque et de défense.
Si vous voulez vraiment recommander - CDN07 est rentable pour les petites entreprises, CDN5 est préférable pour les scénarios de trafic élevé avec Anycast Network, et vous pouvez regarder la solution de protection hybride de 08Host pour la recherche d'une personnalisation extrême. Mais n'oubliez pas qu'il n'existe pas de solution unique, mais seulement une stratégie de sécurité itérative et continue.
(Pas de problème après avoir vérifié ces éléments de configuration ? Envoyez-moi un message privé pour envoyer un rapport de diagnostic afin de déterminer si vous êtes victime d'une attaque malveillante)
