Masquer l'IP de votre serveur d'origine

« Dois-je mettre un CDN devant ? » est la première question que se posent la plupart des gens après avoir acheté un serveur offshore, et elle n'a pas de réponse unique, car ce sont en réalité deux questions sous un même manteau. Absorber une attaque et rester introuvable sont des problèmes différents, avec des solutions différentes, et le montage qui règle l'un peut discrètement défaire l'autre.

La confusion coûte cher dans les deux sens. Certains mettent un grand CDN américain devant un contenu pour lequel ils avaient précisément choisi un hébergement DMCA-ignored, et remettent un service de plaintes entre les mains du type même d'intermédiaire qu'ils cherchaient à éviter. D'autres ne mettent rien en place, se font toucher par une inondation de couche applicative que le filtrage réseau n'a jamais été conçu pour voir, et en concluent que la protection DDoS était un mensonge. Ce guide sépare les deux problèmes, dit ce que chaque couche fait réellement, et consacre l'essentiel de son propos à la partie qui décide du résultat dans les deux cas : les six façons dont une adresse d'origine fuit quand tout le reste est pourtant bien configuré.

Deux problèmes qui n'en ont l'air que d'un

Tout ce que vous mettez devant un serveur remplit l'un de ces deux rôles : tenir une attaque à distance, ou tenir son adresse inconnue. Ils se recoupent assez pour être confondus, et diffèrent assez pour que résoudre le mauvais soit de l'argent perdu.

Lisez deux fois la dernière ligne, car c'est celle qui piège les gens. Tout le reste sur cette page relève de l'ingénierie. Pas cette ligne.

Ce que votre hébergeur fait déjà, et où cela s'arrête

Le filtrage de couche 3 et 4 est inclus sur chaque offre que nous vendons, sans coût supplémentaire, et il s'exécute en périphérie du réseau plutôt que sur votre serveur — le seul endroit où il peut réellement fonctionner, puisqu'une liaison montante saturée n'est réparée par rien de ce qui tourne derrière elle. La bande passante est illimitée, donc une attaque ne se transforme pas en facture. Pour la grande majorité de ce que les gens appellent « une attaque DDoS », c'est toute l'histoire.

Ce qu'il ne peut pas voir, c'est l'autre genre. Cinq cents requêtes par seconde vers un point de recherche, provenant de quarante mille adresses résidentielles, n'est pas du trafic malformé ; c'est du trafic. Des connexions Slowloris qui égrènent un en-tête toutes les quelques secondes sont, prises individuellement, polies. Un formulaire de connexion martelé de vrais corps POST est indiscernable, au niveau paquet, d'un lundi chargé. Aucun filtre de paquets n'aide, parce qu'il n'y a rien d'anormal dans les paquets.

Il existe un sens de trafic sur lequel nous agissons, et il vaut la peine de le dire clairement : les attaques et le spam massif provenant de notre réseau peuvent être null-routés pour préserver la santé du reste de l'infrastructure. C'est une mesure opérationnelle, pas une mesure de contenu — la distinction que détaille notre guide de l'hébergement DMCA-ignored.

Ce qu'un CDN masque, et le service abus que vous héritez

Le mécanisme est simple et réellement efficace. Votre domaine se résout vers les adresses du fournisseur, les clients s'y connectent, et le fournisseur va chercher le contenu sur votre origine. L'adresse réelle n'apparaît jamais dans la connexion d'un client, donc elle ne peut pas être attaquée par quiconque ne connaît que le domaine. C'est le même tour de passe-passe qui fait fonctionner le CDN fronting pour les proxies résistants à la censure : un censeur voit du trafic vers une adresse qu'il ne peut pas se permettre de bloquer.

Trois choses arrivent avec lui, et aucune n'est cachée dans les petites lignes :

• La périphérie termine votre TLS. Le trafic est en clair à l'intérieur du réseau du fournisseur, par conception — c'est ainsi que fonctionnent la mise en cache et le filtrage. Tout ce que tapent vos utilisateurs atteint un tiers avant de vous atteindre.
• Un canal d'abus qui n'existait pas avant. Des plaintes peuvent être déposées directement contre le CDN, et un CDN y répond : en vous les transmettant, en nommant votre hébergeur, ou en résiliant votre compte. Si votre raison d'être offshore est que les plaintes ne mènent nulle part, placer un intermédiaire américain devant reconnecte la chaîne que vous aviez payé pour rompre.
• Un compte. Adresse e-mail, moyen de paiement, souvent un numéro de téléphone, liés à votre domaine et conservés indéfiniment. Plus de détails plus bas, car c'est généralement le maillon le plus faible de tout le montage.

Rien de tout cela ne rend un CDN mauvais en soi. Cela en fait une décision à deux faces : excellente pour une boutique ou une application avec de vrais utilisateurs et une vraie pression de couche 7, activement contre-productive pour une publication qui attire les retraits. Notre propre réponse à cette question sur la page de l'hébergement DMCA-ignored a toujours été la version courte de ceci : pour résister aux retraits, utilisez le filtrage réseau que vous avez déjà et passez du CDN.

Les six façons dont une adresse d'origine fuit quand même

C'est la section qui compte, car la dissimulation n'est pas un produit qu'on achète — c'est une propriété qu'on entretient ou qu'on perd, généralement en quelques jours, à cause de l'une de ces six choses. Des origines sont retrouvées chaque jour derrière des configurations CDN par ailleurs impeccables.

• Les journaux Certificate Transparency. Chaque certificat publiquement reconnu émis pour votre domaine est publié en quelques minutes dans des journaux publics, permanents et consultables. Ils ne publient pas votre adresse ; ils publient vos noms d'hôtes — staging, mail, vpn, le sous-domaine que vous avez créé une fois en 2024. Chacun est un candidat à résoudre, et un seul enregistrement qui ne pointe pas vers la façade met fin à l'exercice.
• L'historique DNS. Les services de DNS passif archivent chaque adresse vers laquelle votre domaine a jamais résolu. Passer derrière un CDN par la suite ne dépublie pas ce qui a déjà été enregistré — la dissimulation doit commencer avant la première résolution du domaine, ou il vous faut une nouvelle adresse, pas une nouvelle façade.
• Les enregistrements qui ne peuvent pas être proxifiés, et ceux que vous avez oubliés. Les serveurs d'échange de courrier doivent pointer vers quelque chose de joignable. Tout comme un enregistrement AAAA laissé en place quand vous n'avez proxifié que l'IPv4, un vieux nom d'hôte FTP ou de panneau, un wildcard, ou l'hôte de développement « temporaire » qui a maintenant trois ans.
• Tout ce que le serveur envoie. Le courrier émis depuis l'origine porte son adresse dans les en-têtes Received — un message de réinitialisation de mot de passe est une divulgation en libre-service. Webhooks, récupérations d'images sortantes, aperçus de liens, pingbacks, vérifications de mises à jour et rapporteurs de plantage contactent tous l'extérieur depuis l'adresse réelle, et quiconque peut faire parler votre application à un hôte qu'il contrôle l'apprend.
• Le scan de l'internet entier. Chaque adresse IPv4 est scannée et indexée en continu par des services publics, et les résultats sont interrogeables en quelques secondes. Si votre origine répond sur le port 443 avec votre certificat, ou sert votre page d'accueil à n'importe quel en-tête Host, la faire correspondre tient en une requête contre un hachage de corps de page, une empreinte de certificat ou un hachage de favicon. C'est ainsi que la plupart des origines sont trouvées, et cela ne coûte rien à celui qui cherche.
• L'application qui parle d'elle-même. URL absolues et redirections contenant l'adresse brute, points de terminaison de statut ou de métriques laissés ouverts, traces de pile verbeuses nommant des hôtes internes, en-têtes qui révèlent le backend, et le virtual host par défaut qui sert joyeusement votre site à quiconque le demande par adresse.

Verrouiller l'origine pour que seule la façade puisse l'atteindre

Une dissimulation qui dépend du fait que personne ne devine l'adresse n'est pas une dissimulation. Le montage ne tient que si l'origine refuse de parler à quiconque hormis la façade, de sorte qu'une adresse qui fuit soit une nuisance et non un événement.

• Refus par défaut, puis autorisation de la façade. N'acceptez les ports 80 et 443 que depuis les plages d'adresses publiées du fournisseur, et rafraîchissez cette liste automatiquement — les plages changent, et une liste périmée échoue ouverte ou échoue fermée au pire moment. Tout le reste, y compris SSH, doit passer par un tunnel ou une adresse de gestion, comme dans notre checklist de durcissement de la première heure.
• Authentifiez la façade. Des certificats client entre le CDN et votre origine — généralement appelés authenticated origin pulls — font qu'une adresse correcte plus un en-tête Host correct n'obtiennent rien sans le certificat.
• Mieux : aucun port entrant du tout. Un tunnel strictement sortant de l'origine vers la périphérie, qu'il s'agisse du connecteur propre du CDN ou de WireGuard vers un nœud que vous exploitez, fait que l'origine n'écoute jamais sur une interface publique. Le scan ne peut pas trouver ce qui ne répond pas, et c'est la version la plus solide du montage.
• Un seul virtual host, un seul en-tête Host. Le serveur par défaut ne doit rien renvoyer d'utile. Si votre site se charge par adresse, un scanner le repérera en moins d'une semaine.
• Sortez le courrier de l'origine web. Le courrier doit être joignable et doit s'identifier ; gardez-le sur sa propre machine, comme le suppose le guide du serveur mail.
• Vérifiez depuis l'extérieur. Chaque contrôle de cette liste est dénué de sens s'il est exécuté depuis le serveur lui-même. Testez depuis un réseau qui n'est pas le vôtre.

Votre propre nœud frontal plutôt qu'un CDN

La troisième option est souvent ignorée parce qu'elle n'a pas de budget marketing : un petit VPS en façade publique, un tunnel chiffré vers la machine qui détient les données, et nginx ou HAProxy qui fait transiter le trafic entre les deux. Vu de l'extérieur, cela ressemble à n'importe quel serveur web. Le vrai serveur est ailleurs, sans aucun port entrant.

Ce que vous obtenez, c'est une dissimulation sans personne d'autre dans le montage — pas de compte tiers, pas de service abus externe, pas d'inconnu qui termine votre TLS. Vous obtenez aussi une séparation des juridictions autrement difficile à obtenir : la façade là où sont les utilisateurs, les données là où la loi vous convient, à choisir parmi nos sept localisations. Et comme aucune identité n'a été rattachée à l'inscription, la façade est jetable — une adresse grillée se remplace en quelques minutes plutôt que de se négocier.

Ce que vous n'obtenez pas, c'est une capacité anycast. Un nœud n'a que la capacité d'un nœud, et si notre filtrage réseau le protège exactement comme il protège n'importe quel autre serveur, une attaque volumétrique réellement massive est un concours de bande passante que gagne un réseau mondial. La position honnête : un nœud frontal est la bonne réponse pour cacher un backend lourd ou coûteux — une baie de stockage, une machine GPU, un serveur mail, une base de données — et pour séparer les juridictions. Ce n'est pas un substitut à un CDN sous pression soutenue de couche 7.

Choisir, en un tableau

Le compte est généralement le maillon le plus faible

Considérez ce qui se passe quand l'infrastructure est parfaite et que la paperasse ne l'est pas. Le serveur a été payé en Monero, sans documents d'identité ni adresse e-mail — le montage décrit dans nos pages hébergement no-KYC. Puis un compte CDN est ouvert avec une carte, une adresse personnelle et un numéro de téléphone, mentionnant le domaine qu'il protège. Ce compte est un registre d'identité plus solide et plus durable que tout ce qui se trouve sur le serveur, détenu par une entreprise qui répond aux citations à comparaître, et il annule entièrement la confidentialité du paiement.

La correction n'est pas compliquée, seulement facile à oublier : si l'anonymat est l'objectif, soit la façade vous appartient, soit le compte qui se trouve devant elle est aussi jetable et aussi inattribuable que le serveur derrière elle. L'OpSec serveur traite correctement cette discipline, et notre réponse honnête sur l'anonymat offshore est sans détour sur les maillons de la chaîne qui cèdent généralement en premier. Ce ne sont presque jamais les maillons techniques.

Auditer votre propre exposition en dix minutes

Chaque point ci-dessous est quelque chose qu'une partie intéressée vérifierait dans les toutes premières minutes. Faites-le vous-même, depuis une machine qui n'est pas le serveur, avant d'avoir besoin des réponses.

• Listez chaque nom d'hôte que vous avez jamais certifié. Cherchez votre domaine racine dans un moteur de recherche Certificate Transparency et résolvez chaque résultat. Tout ce qui ne pointe pas vers la façade est une fuite, y compris les hôtes que vous n'utilisez plus.
• Lisez votre propre historique DNS. Une recherche de DNS passif montre les adresses vers lesquelles votre domaine résolvait avant le CDN. Si l'origine d'hier est encore celle d'aujourd'hui, la dissimulation n'a jamais été réelle.
• Interrogez l'origine directement. curl -sI --resolve example.com:443:198.51.100.10 https://example.com/ — si le site répond, votre pare-feu ne restreint pas l'accès à la façade, et quiconque dispose d'une adresse candidate peut le confirmer en une seule requête.
• Interrogez-la sans ménagement. curl -skI https://198.51.100.10/ ne devrait rien renvoyer de reconnaissable. Un virtual host par défaut qui sert votre page d'accueil est l'erreur isolée la plus courante de cette page.
• Vérifiez chaque type d'enregistrement, pas seulement A. dig +short AAAA example.com, dig +short MX example.com, et de même pour chaque sous-domaine révélé par les journaux de transparence. Un IPv6 laissé non proxifié est un classique.
• Envoyez-vous un e-mail depuis l'application. Déclenchez une réinitialisation de mot de passe et lisez la chaîne Received complète. Si l'adresse d'origine s'y trouve, elle se trouve aussi dans chaque message que vous avez jamais envoyé.
• Confirmez que les ports sont fermés. Depuis un réseau qui n'est pas le vôtre, nmap -Pn -p80,443 198.51.100.10 devrait afficher filtered, pas open.
• Cherchez dans les scanners. Recherchez l'empreinte de votre certificat et le hachage du favicon de votre page d'accueil dans un index public de scan d'internet. Si votre origine est indexée, c'est ainsi qu'elle sera trouvée.

Quand l'adresse est déjà grillée

Partez du principe qu'elle le restera. Une adresse apparue dans le DNS passif et dans des index de scan est un registre public permanent, et aucun changement de configuration ne le rétracte. La réponse est mécanique plutôt qu'ingénieuse.

• Réglez d'abord la fuite. Faire tourner vers une nouvelle adresse sans refermer la brèche reproduit la situation en quelques jours, et vous aurez dépensé une migration pour n'avoir rien appris.
• Puis faites tourner. Déployez un remplacement — dans une juridiction différente si la raison était légale plutôt que technique — restaurez, et basculez. Comme aucune identité n'était rattachée au premier serveur, c'est un nouveau départ plutôt qu'une négociation, ce qui est le bénéfice pratique et peu glorieux d'acheter des serveurs sans historique de compte.
• Préparez le basculement avant l'urgence. Un TTL DNS court, une configuration que vous pouvez redéployer depuis un dépôt et une restauration testée transforment un mauvais après-midi en vingt minutes. Personne n'organise cela pendant une attaque.
• Retirez proprement l'ancienne adresse. Ne laissez pas l'ancien serveur stationné sur l'ancienne adresse à servir le même contenu ; c'est une confirmation en direct pour quiconque observe, et cela maintient le registre à jour.

La version courte

Le filtrage au niveau réseau gère les attaques volumétriques, vient avec le serveur et ne coûte rien de plus. Un CDN gère la couche applicative et masque l'origine, au prix d'un intermédiaire qui termine votre TLS, répond aux plaintes et sait qui vous êtes. Votre propre nœud frontal achète la dissimulation sans l'intermédiaire, mais pas la capacité mondiale. La juridiction tranche la question légale et aucun des trois ne la touche. Et tous les trois sont défaits par un seul enregistrement non proxifié, un seul e-mail venu de l'origine, ou un seul virtual host par défaut.

Décidez selon l'objectif plutôt que par habitude, puis consacrez les dix minutes à l'audit — il révèle plus d'exposition réelle que n'importe quelle mise à niveau. Si vous voulez l'architecture sans le tiers, un petit VPS en façade et le vrai travail sur du matériel dédié derrière est le montage que nous observons le plus souvent chez ceux qui se sont déjà fait trouver une fois.