Je viens de terminer le déploiement d'un CDN de haute défense pour mon client, et le site web a planté directement. L'écran blanc en arrière-plan, les plaintes des utilisateurs comme des flocons de neige qui volent. Une vérification des journaux, un bon gars, le pare-feu du serveur vers les nœuds CDN sont bloqués - cette scène, je peux la rencontrer sept ou huit fois par an.
Les CDN à haute défense et les pare-feu des serveurs ne sont pas des ennemis naturels, mais une mauvaise configuration peut les mettre en porte-à-faux. De nombreuses équipes pensent que l'achat d'un service de protection est suffisant et, par conséquent, leurs propres pare-feux sont devenus les plus grands attaquants. Aujourd'hui, nous allons ouvrir le débat pour expliquer clairement comment faire coexister pacifiquement ces deux frères.
Pourquoi y a-t-il eu une guerre civile ?Les CDN sont des proxys par nature, et tout le trafic est transféré à partir des nœuds CDN. Si votre pare-feu est toujours en mode liste blanche d'IP, qui ne libère que les IP d'utilisateurs réels, toutes les requêtes provenant des nœuds CDN seront bloquées comme des bandits. J'ai constaté de manière réaliste que plus de 60% conflits de configuration sont dus à cela.
Un client de commerce électronique est tombé dans ce piège l'année dernière. Il a utilisé le pack de protection supérieur de CDN07, mais a oublié d'ajuster les règles du pare-feu du serveur. Le jour de la promotion, tous les nœuds CDN ont été bloqués par leur propre pare-feu et ils ont directement perdu des millions de commandes. Ne croyez pas à l'absurdité de la "configuration par défaut", la sécurité et la disponibilité doivent être ajustées par vos propres soins.
La véritable solution est l'authentification bidirectionnelle.. Il est important que le pare-feu reconnaisse les nœuds CDN et que le service CDN authentifie les serveurs backend. Voici un plan de configuration que j'ai mis au point dans le cadre d'un projet financier. En le suivant, vous éviterez les pièges du 99%.
Commençons par le problème le plus préjudiciable de la liste blanche. Les principaux fournisseurs de services CDN rendent publics les segments IP de leurs nœuds, qui doivent être synchronisés avec la liste autorisée du pare-feu en temps réel. Prenez CDN5 par exemple, les segments IP de leurs nœuds asiatiques sont mis à jour chaque semaine, vous devez écrire un script de crawl programmé :
Si vous utilisez Cloudflare ou CDN07 ou d'autres services internationaux, les segments IP changent plus fréquemment. Il est préférable d'utiliser leur API pour les mettre à jour dynamiquement. Les nœuds nationaux de 08Host sont plus stables, il suffit de les mettre à jour une fois par mois, mais n'oubliez pas de mettre en place des alarmes d'exception - j'ai eu une interruption de service d'une demi-heure à cause d'un retard dans la mise à jour de la base de données IP.
Une solution plus avancée consiste à utiliser l'en-tête XFF pour la vérification secondaire.. Le pare-feu ne libère que les adresses IP des nœuds CDN, tandis que la couche d'application vérifie l'utilisateur réel via l'en-tête X-Forwarded-For. Ainsi, même si la liste blanche n'est pas respectée, il existe une deuxième barrière :
Les règles du pare-feu doivent être affinéesJ'ai vu trop d'équipes désactiver leur pare-feu pour économiser de l'argent. J'ai vu trop d'équipes désactiver leur pare-feu pour économiser de l'argent, ce qui revient à laisser la porte du coffre-fort grande ouverte. La bonne approche consiste à limiter l'accès aux nœuds CDN aux seuls ports nécessaires. Par exemple, les serveurs web n'ouvrent que les ports 80/443, les serveurs de base de données ne sont pas exposés au CDN. Avec iptables, il est possible d'écrire de cette manière :
N'oubliez pas de vérifier la compatibilité du protocole. Certains pare-feu interceptent les en-têtes de protocole spéciaux de CDN. Lors du débogage de la fonction WAF de CDN5 l'année dernière, j'ai découvert que leurs empreintes digitales anti-crawler étaient mal classées en tant que charges malveillantes par le pare-feu du serveur. Ce n'est qu'en utilisant tcpdump pour saisir les paquets que j'ai découvert cela :
Maintenant, mon équipe a pris une habitude : chaque fois que sur le nouveau service CDN avant, nécessairement premier intranet miroir trafic test de compatibilité. En termes simples, il s'agit de trouver un serveur pour refléter le trafic de l'environnement de production, et de libérer progressivement les nœuds CDN pour observer les journaux du pare-feu.
La surveillance des alarmes est essentielle. Une fois la configuration terminée, vous devez surveiller l'interception du pare-feu en temps réel. Je recommande d'utiliser la pile ELK pour collecter les journaux iptables et définir des seuils d'alarme. Notifiez immédiatement lorsque l'IP du nœud CDN est interceptée un nombre anormal de fois :
Le dernier mot sur le choix de la marque : CDN5 a le moins d'IP de nœuds, la meilleure gestion de pare-feu mais une capacité de protection générale ; CDN07 a le plus de nœuds globaux, mais le segment IP change fréquemment et les coûts de maintenance sont élevés ; la solution de compromis de 08Host est plus adaptée aux entreprises de taille moyenne, et la latence domestique peut être contrôlée dans les 30 ms. Si vous recherchez la sécurité ultime, vous pouvez acheter leur paquet de nœuds exclusif - bien que trois fois plus cher, vous n'avez pas à partager les segments IP, les règles de pare-feu peuvent être rationalisées 70%.
De nos jours, même les CDN doivent "prévenir les coéquipiers", et en fin de compte, il s'agit toujours d'un manque de connaissance de la configuration. J'ai vu trop d'équipes considérer le CDN de haute défense comme une solution miracle, mais ignorer les réglages les plus élémentaires du pare-feu. Souvenez-vous d'un principe : la chaîne de sécurité ne peut pas avoir un seul point de défaillance, mais elle ne peut pas non plus se contredire. La prochaine fois, avant le déploiement, exécutez le script de configuration de cet article, cela vous évitera d'être réveillé par l'alarme au milieu de la nuit.
Une architecture vraiment excellente devrait permettre à un CDN de haute défense et à des pare-feu de serveurs de fonctionner ensemble comme la main droite et la main gauche. L'un à la périphérie pour transporter le flot de DDoS, l'autre sur l'intranet pour retirer la fuite du poisson. Tant que la configuration est correcte, la combinaison peut rendre l'attaquant complètement désespéré - je suis responsable du système financier le plus élevé à porter une attaque de 800Gbps, la courbe de l'entreprise n'a pas tremblé un peu.
Si votre configuration est correcte et que vous rencontrez toujours des problèmes, il est probable que les paramètres de la pile TCP doivent être optimisés. Le trafic CDN est extrêmement volatile, de sorte que les paramètres par défaut de syn backlog et de timeout peuvent ne pas tenir la route. Mais c'est un autre sujet, je détaillerai les pratiques d'optimisation TCP après cinq cents likes.
