Je me souviens que l'année dernière, un client m'a demandé de l'aide en cas d'urgence, il m'a dit que le site était soudainement touché par des temps d'arrêt, une vérification des journaux a révélé que l'adresse IP de la station source était précisément l'explosion - l'attaquant n'est tout simplement pas allé au CDN, directement à l'adresse IP de la station source de la sortie folle. Je lui ai demandé comment faire correspondre le CDN, il a justifié : “pas sur le nom de domaine CNAME au fournisseur CDN à l'adresse ? Les résultats d'un coup d'œil à la configuration, bon gars, le serveur source effectivement lié au nom de domaine résolution directe de l'enregistrement A, les règles de pare-feu ne restreignent pas le CDN retour au segment IP source. Ce type d'opération équivaut à l'émission d'un billet VIP par le pirate, en passant directement par le poste source.
En fait, l'exposition de l'IP de la station source à cette merde, neuf fois sur dix sont des omissions de configuration ou des biais de compréhension. Certaines personnes pensent que l'utilisation du CDN leur permettra de se reposer tranquillement, mais elles ne savent pas que le CDN n'est qu'une couche de bouclier, que le bouclier lui-même n'est pas bien couvert, mais qu'il deviendra une faiblesse. Les actes de mort les plus courants sont les suivants : le serveur source a ouvert un port de débogage à distance et un accès public, les enregistrements DNS restent dans l'enregistrement A de la source, l'application du certificat SSL laisse filtrer l'IP source, et même directement dans le code pour écrire l'API d'appel de l'IP source morte. --Il s'agit tout simplement d'une porte dérobée pour les attaquants.
J'ai testé trois grands fournisseurs de CDN et j'ai constaté que même pour le même fournisseur, les politiques de sécurité par défaut pour les différents packages peuvent être très différentes. Par exemple, l'édition Starter de CDN5 ne cache pas automatiquement l'en-tête du serveur source, alors que l'édition Enterprise est obligée de réécrire l'en-tête de la réponse. Il y a aussi un détail pitoyable : certains CDN dans la source de retour à l'échec de l'information d'erreur IP source sera jeté au client, ce qui est appelé “exposition de retour d'erreur”, spécialement pitché les utilisateurs blancs.
Pourquoi faut-il mourir pour cacher l'IP source, de nos jours les attaques DDoS sont industrialisées depuis longtemps, le coût de pénétration du CDN est de plus en plus élevé, mais si l'on touche à l'IP source, le coût de l'attaque diminue directement de deux ordres de grandeur. J'ai vu le cas le plus tragique d'une station de commerce électronique dont l'IP source a été exposée, qui a été paralysée par un déluge UDP de 50 Gbps, les vendeurs de nuages se rendant directement au serveur source pour tirer le trou noir pendant 24 heures - pour savoir qu'aujourd'hui, une simple grappe de broilers peut facilement créer un trafic de niveau T. Ce qui est encore plus dégoûtant, c'est qu'une fois que l'IP source est marquée, le balayage des ports, la détection des vulnérabilités et l'abus d'API suivent, ce qui est aussi difficile à nettoyer qu'un nid de cafards poignardé.
En ce qui concerne le transfert multicouche, il s'agit essentiellement de placer une poupée russe sur l'IP source. La première couche s'appuie sur le nœud de bordure du CDN pour acheminer le trafic, la deuxième couche utilise un proxy inverse ou une source intermédiaire pour isoler le trafic, et la troisième couche est la véritable station source. La clé est de permettre à l'attaquant de ne jamais voir que l'IP proxy la plus extérieure, et de renvoyer vers l'IP source toutes les communications intranet ou sur liste blanche. Je recommande vivement d'utiliser le programme de “source intermédiaire” : ne pas laisser le CDN retourner directement au serveur réel, mais insérer au milieu une couche de proxy (comme le cluster de proxy inverse Nginx), la couche de proxy et le CDN avec une ligne dédiée ou des interconnexions intranet, l'extérieur étant complètement invisible.
Plus précisément, prenons la configuration de Nginx comme un marronnier. Supposons que l'IP intranet de votre source réelle soit 192.168.1.100, que l'IP publique du serveur proxy de la source intermédiaire soit 203.0.113.10 (mais qu'il n'autorise que l'accès au segment IP du CDN vers la source), que le nœud de bordure du CDN vers la source pointe vers cette IP source intermédiaire :
Ne sous-estimez pas ces lignes de configuration ! J'aide une station financière à faire du renforcement, il suffit de s'appuyer sur cette architecture de source intermédiaire pour bloquer 70 % du comportement de balayage. Car même si l'attaquant choisit l'IP 203.0.113.10, il ne verra qu'une couche de proxy déguisée en CDN, et ne pourra pas toucher le vrai serveur 192.168.1.100. De plus, la source intermédiaire peut également être déployée avec un WAF, une limitation de débit, une vérification humaine et d'autres modules de sécurité supplémentaires - ce qui équivaut à la station source de la double assurance.
Parlons maintenant du choix des fournisseurs de CDN. Le point fort de CDN5 est qu'il y a de nombreux nœuds à l'étranger, mais la politique de sécurité par défaut est faible, vous devez ouvrir manuellement le “mode strict de retour à la source” afin de verrouiller la liste blanche ; l'accélération domestique de CDN07 est impitoyable, le support pour l'intégration native du transfert multicouche (ils l'appellent “architecture source bouclier”), mais le prix peut être plus cher que 40% ; 08Host route rentable. “Shield source architecture”), mais le prix peut être plus élevé que 40% ; 08Host cost-effective route, buy high defence packages to send intermediate source services, but node stability occasionally jerk. J'ai mesuré le test de pression, CDN07 dans 300Gbps DDoS peut encore maintenir le lien de source intermédiaire ne fuit pas l'IP réel, tandis que certains fournisseurs bon marché ont rencontré une grande quantité de trafic directement à la source de l'exposition - donc ne croyez pas que le "caché absolu" est un non-sens, la clé est de regarder la conception sous-jacente du réseau. L'essentiel est d'examiner la conception sous-jacente du réseau du fournisseur.
Il existe également une opération obscure d'imbrication avec plusieurs CDN. Par exemple, l'utilisation de CDN5 pour effectuer la première couche d'accélération en périphérie, le retour au cluster de source intermédiaire CDN07, et enfin le retour au serveur réel. Ce mode d'imbrication, bien que le coût soit doublé, a permis à une société de jeux vidéo de résister à une attaque hybride de 1,2 Tbps - l'attaquant n'a même pas pénétré l'IP Anycast de la première couche de CDN, sans parler de la traçabilité. Bien entendu, cette solution nécessite une programmation DNS fine et des configurations de maintien de session, sans quoi les utilisateurs risquent de subir une gigue de latence à travers les sauts CDN.
Enfin, j'aimerais jeter un peu d'eau froide sur le sujet : aucune solution ne peut garantir que l'IP source ne sera jamais exposée. Il y a eu des pirates qui ont indirectement déduit l'IP source par l'analyse du timing de la poignée de main du certificat SSL, l'empreinte de la pile HTTP/2, et même le mappage inverse du segment IP du nœud CDN, etc. Donc, en plus du transfert multicouche, vous devez travailler avec les opérations de base qui consistent à revenir régulièrement à l'IP source, à désactiver les réponses ICMP, et à fermer les ports non essentiels, etc. J'avais l'habitude d'utiliser Shodan tous les mois pour scanner les IP associées à mon domaine afin de vérifier toute exposition accidentelle des services - c'est mieux que d'attendre qu'ils soient exposés. J'ai l'habitude d'utiliser Shodan pour scanner les IP associées à mes propres domaines une fois par mois afin de vérifier si des services ont été accidentellement exposés. C'est bien mieux que d'attendre d'être touché et de pleurer.
En bref, la dissimulation de l'IP source est un projet systématique, qui ne se limite pas à un simple ensemble de CDN. Il faut accumuler les défenses à partir de trois dimensions : l'architecture du réseau, les spécifications de configuration et la réponse de surveillance. Maintenant, regardez mon année qui a été frappée par le client, il a ensuite dépensé le double du budget pour reconstruire l'architecture, mais a économisé dix fois la perte potentielle de temps d'arrêt - cette vague n'est pas mauvaise. Rappelez-vous : la sécurité est une question, plutôt que de la surconcevoir, ne la laissez pas au hasard, après tout, le chantage des copains peut être beaucoup plus que ce que nous avons roulé.
